Beware, this is still a rough page, I intent to make some revisions in the nearby future
A big part of programming is making estimates. How long is it going to take to implement a certain feature, how long is it going to take to do a project. Questions that are asked very ofton. But how long is it going to take? How much people do you need? How can you speed up the process. All interesting questions. This page is about planning according to the extreme programming movement. Alongside some personal thoughs are discussed as well.
A lot of information on this page comes from the book: Planning extreme programming If you like this page, you probably like the book even better. The book comes with some nice examples that I will not discuss here ofcourse :-)
What is important about planning? The best lesson to learn about planning is not the plan. The best about planning is the planning itself. If you make the plan more important you have a lot of risk to live in an illusion. Therefore the plans needs to be the best possible reflection of reality. Do not make the plan a goal on itself, the goal is to create a software product. The mentioned book gives an interesting example of driving a car and compare it to software development..
There are a number of things you need to know about planning:
- What can you influence in the planning process? The best way to keep your project on track and keep delivering features is to change the scope. If you have to much to do, push over a story to the next iteration. Do not move the iteration end.
- What if there is to much to do? The best rule to learn, you never have to little time, you will have to much to do. So Priority what you have to do and only to the most important
- Plan according to yesterdays wheather, correct your planning and estimates. It turns out that your best estimation is to plan the way you really did it the last time. So if you did a simular story before take the historical data to create the new estimate.
- Scoping a planning for a project, divide into releases and iterations. A good duration for a Release would be about 3 months, iterations should last about 2-3 weeks and tasks about 1 or 2 days. These are indications, there are reasons a project should use longer or shorter iterations. It is good to go for a release date, but if some features must be in the release and are not there when we want to release think hard abotu your strategy.
- When to communicate? Allmost the complete time. You communicate with your pair programmer, with the customer, during standup meetings, release events, iteration breakdown sessions. So communication is very important.
Now how does this planning relate to gridshore, interesting question. The answer will follow soon, please come back later ...
(to be continued)