Breaking tasks down is not a matter of simply lopping them up into tinier pieces. Task breakdown is as much an art as it is a science. Working in the small means we’re getting feedback constantly, and we’re building our features as we go instead of doing a big bang release. Working in the small means breaking tasks down into their smallest components so they can be built easily and still show some value. Generally speaking, we want to keep iterations as short as possible because the secret of iterative development is that it gets you into the discipline of working in the small. Therefore, improving the requirements process can significantly increase a team’s overall productivity. Requirements are also one of the largest contributors of bugs to a system. Requirements consume a significant amount of resources to gather, write down, and then later read, interpret, and build. Building to quarterly releases is just long enough that it demands requirements to be written down then later read and interpreted. The shorter the iterations, the less infrastructure is needed to support development. This is a big improvement over annual release cycles, which is how many companies operated in the past, but it’s still not ideal. Iterations generally last from one to four weeks. Then the next batch of work is planned, executed, and reviewed, and so on. It is not a race but rather a process so I prefer the XP term iteration over the Scrum term Sprint.īoth iterations and Sprints are examples of time boxes where work is done within fixed time intervals and then it’s reviewed. That’s not how I view iterative development. I am not a big fan of the term Sprint because it connotes the idea of hurrying through. Both Extreme Programming (XP) and Scrum have the notion of time boxing.
0 kommentar(er)
