|
Overview
These advices are for software developers and managers who want to get
greater outcome and pleasure from work. There are two significant questions,
answers to those may solve the most of your project related problems,
save a lot of time and build up better relationships with your customers.
Those questions are: "Why to plan?" and "How to plan?".
Why should we plan?
From day to day software developers have a lot of benefits from planning
just like as problems from refusing to plan.
Firstly, predictable results increase transparence of your work what is one
of the most important factors in order to gain customer trust. Moreover,
if you don't have any plan, then your goals may be unclear even for you.
The scope always consists of major and minor tasks. Significance revelation
reduces a risk to be tardy with functionality desired by your customer.
80 / 20 rule reads as follows: 80 percents of profit is brought by 20 percents
of investment. Start from those 20 percents of tasks which will bring maximal
profit to your customer as soon as it possible.
Planning exerts strong influence on quality of the product.
Often we disregard very important practices such as
automated testing and review of code. It occurs because we remember
about tasks which we haven't done yet and it seems that these tasks have
bigger priority then refactoring, testing and additional verification.
Sometimes we just don't put enough resources to follow best practices.
But one well-done task is better then two badly or half-implemented.
Remember that code causing bugs is awful issue wasting time of your
team-members and your own. Therefore, include all these expenses into estimation
and it will pay for itself soon.
When you know that you are doing exactly what you should do at the given chunk
of time, you perform your work unhurriedly. It saves your emotions and greatly
improves quality of your job. Good mood and satisfaction with results enhance
average productivity in long term.
|
|
How to plan?
The whole team should be responsible for planning, not only one person, be it the most
talented architect, project manager or somebody else. It is the main aim of planning
determined by the next reasons:
-
Collaboration reduces incomprehension. One person can't observe all tasks.
-
If a developer says that task will be completed, probability of successful
completion appreciably rises because this task is under personal control from a moment.
-
Difference of opinions regarding estimation is the worst thing in any project.
During the planning team comes to agreement about a scope of tasks which should be done.
-
Tasks shouldn't be assigned to people without assent. Mutual consent in assignment is the
key factor in planning. It also assists in selection of proper developer for each piece of work.
Attitude towards tasks is also very important. Focus your attention only on one task at a moment.
Try to stand with it until it is completely finished. Turning your mind in direction to solve
any task usually takes a lot of time. Switching between tasks is useless wasting of time.
To facilitate this approach, tasks should be small enough to finish in one gulp and large enough
to avoid unnecessary detailing.
When the end of iteration coincides with the end of working week,
it doubles stress on your team. Therefore,
finish iteration on Thursday to have Friday for clean-up and other non-critical items.
Start iteration from planning on Monday.
It is acceptable to spend whole the Monday in order to obtain detailed and well thought-out plan.
Guide to action.
Keeping in mind all ideas described before, let's figure out some practical receipts.
If you have from 4 to 8 developers in your team working on Agile project,
then these principles should bring profit to you.
-
Determine the length of iteration. Usually 2 weeks is the best choice.
-
Start Monday from planning.
-
Take user stories prepared by analyst, customer or manager.
These high level stories should not be very detailed.
For instance: "User turns the button A on, thus lamp B lights up".
Each developer should briefly look through all these stories.
-
The whole team stays behind white board and gives initial estimation in abstract
points to each story. The result is a map between user stories and numbers reflecting
relative complexity of each story. Planning poker is useful for this purpose.
-
Everyone takes stories he wants to accomplish.
It is possible to allocate stories approximately in equal parts.
-
Each developer breaks taken stories into the tasks.
Task should take no less then 1 hour of time and no more then 2 days to be completed.
For example: "Make Button A", "Make lamp B", "Implement switch and bind it with controls",
"Write unit tests". For all of these tasks responsible developer fills small cards consisting
of identifier, title, description, identifiers of influencing tasks and estimation in real hours:
-
Team gathers in front of white board again.
It is possible to rearrange tasks at this moment if somebody has taken
too much to accomplish or remove some user stories at all if scope is too big.
Otherwise everyone posts prepared cards in initial state.
There are 4 states for each task: To do -> In progress -> On review -> Done.
-
Move cards from one state to the next one to reflect current progress.
React immediately if something goes out of plan.
-
Have all tasks in 'Done' state on the last Thursday.
-
In case of successful completion of all tasks, spend Friday on internal
trainings aka "Geekly Weekly", retrospective meeting and other important activities.
In the course of planning each team encounters with dozens of details.
Only experimental approach gets possibility to find the most effective practices.
Try to apply new methods to the process of software development established in your team.
Summarizing, I only want to emphasize that success is always determined by people but not by processes.
|
