BestPracticesInformationOverload

From SPA Wiki

- Write down specific questions of what puzzles you

- Listen for hidden requirements

- capture diagrams of key processes until you understand them (eg UML)

- Write things in your own words: When you've been looking at something new, write something down in your own words. Pretend that you are explaining it to someone else. Or actually paraphrase it to the person you are explaining it to. Maybe even document it for the team Maybe start a wiki as a possible form of documentation. Possibly rewrite documentation for yourself.

- Try to keep your focus on the project as a whole. Retain this awareness... Don't push responsibilities to the project manager. Don't just focus on understandning the architecture - spend time to understand the problem domain.

- Be patient. It takes time to settle in.

- If there are steps that need to be repeated (e.g. setting system), document them.

- Ask a lot of questions - even obvious ones.

- Keep notes

- Look at details before or while getting the big picture.

- drill down to specifics.

- Ask different people the same question

- Keep a list of the people in the project (or at least those relevant to you) with their name, contact details, and area of expertise in the problem (either specific to problem domain or technical aspects or both). Keep this information updated regularly.

- organize and facilitate a retrospective

- Ask for feedback on the work you have been doing

- Think of ways to test your understanding.

- Use analogies as a way of understanding things.

- Set small goals for the first days and evaluate how well you managed to reach them.

- Hold a mini personal retrospective at the end of the day.

Back to TechnicalAspects (1 level up)

Back to ProblemAspects (2 levels up)