Chapter 7 The Practices: dX

1. Chapter 7The Practices: dX

2. Outline • Iterative Development • Planning • Organizing the Iterations into Management Phases • What’s in an Iteration?

3. Iterative Development (1/2) • Process • a group of practices that a team can use to get projects done • dX • a lightweight process • a set of simple rules • The key dX practice is to do everything in short iterations.

4. Iterative Development (2/2) • Everything • requirements, analysis, design, implementation, testing, documentation, etc. • Short • two weeks

5. Iterative Development: The Initial Exploration (1/2) • The first dX iteration is an exploration of the requirements. • the only iteration that does not end in code • the only iteration that may be shorter than two weeks • The customer • responsible for requirements and priorities • may be the real customer or a team of business analysis

6. Iterative Development: The Initial Exploration (2/2) • Sit down with the customer and talk over what the system has to do. • As we discuss the system we identify use-cases. • Write the name of each use-case down on an index card, which is called an user story. • We are not trying to be complete or thorough just yet. We are just trying to get our arms around the overall system. • This exploration process never ends.

7. Iterative Development: Estimating the Features (1/2) • Write an estimate on each user story card. • The unit is not important. • Make the estimates based on a previously implemented story. • If you don’t have old stories, you can start estimating by using perfect programming days. • A story should never be longer than three or four days worth of effort for the whole team.

8. Iterative Development: Estimating the Features (2/2) • Split long stories, and merge short stories. • Spend two or three days doing a quick and dirty implementation of two or three interesting stories. • To calibrate our estimates • Find the initial velocity, which is the amount of work that can be done in one day.

9. Planning: Planning Release (1/2) • Planning is simply a matter of using the current velocity to figure out which stories will be done each iteration. • First release: • six iterations or about three months • Assume that we have 5 people. We can do about 50 man days per iteration (10 work days in two weeks). • In six iterations we can get 300 man days of work done.

10. Planning: Planning Release (2/2) • First release (cont.): • At our current velocity of 0.5, we can get 150 story points done. • The customer picks stories (most important and cost effective) with estimates that add up to 150. • This batch of stories becomes the release plan.

11. Planning: Planning Iterations (1/4) • On the first day of each iteration, we create a plan for that iteration. • According to the current velocity, the customer select stories from the release plan that add up to 25 story points. • Stories are then broken into tasks.

12. Planning: Planning Iterations (2/4) • A task is • much smaller than a story • a unit of work on the order of four to ten man hours in size • a simple unit of work that a single developer can take responsibility for • broken down with the help of the customer

13. Planning: Planning Iterations (3/4) • Sign up for tasks • Each developer keeps a budget in the back of his or her head. • This budget is the number of man hours the developer will spend actually working on tasks during this iteration. • A developer can continue to sign up for tasks until his budget is zero.

14. Planning: Planning Iterations (4/4) • Tasks are not assigned to a developer, but chosen by a developer. We also let each developer estimate the task they are signing up for. • Remove stories if there are still tasks left on the board.

15. Planning: The Midpoint • Assume that we settled on 20 story points for the iteration. • In the midpoint of the iteration, we should have 10 story points done. • If we only got 8 story points done, we ask the customer to remove a story or two so that the total is 16. • If we got 15, we ask the customer to add more stories so that the total is 30.

16. Planning: Velocity Feedback • At the end of the iteration, we recompute our velocity, and plan the next iteration with the new velocity. • This is how we continuously calibrate our estimates.

17. Question • How do you apply what you have learned so far in this chapter?

18. Organizing the Iterations into Management Phases • The Unified Process suggests that projects go through four management phases: • Inception • Elaboration • Construction • Transition • Each of the above phases consists of one or more iterations; and each produces working code.

19. What’s in an Iteration? (1/) • During the two weeks of iteration, we • analyze the requirements • design a solution • implement that solution • We restrict our scope to only the stories selected for the current iteration. • This leads to the best architectures, very flexible designs, and very little work.

20. What’s in an Iteration: Developing in Pairs • Two developers work together at a single workstation implementing a task that one of them signed up for. • We changes partners once per day. The owner of the task stays with his task. • On average, each programmer spend about half his time working on the tasks he signed up for. • Does this cut productivity in half?

21. What’s in an Iteration: Acceptance Tests • At the start of each iteration, the customer and QA folks work together to flesh the user stories into use-cases and to write executable acceptance tests. • These tests were delivered to the programmers before the iteration is half over. • These tests are the true requirements documents.

22. What’s in an Iteration: Unit Tests • We write unit tests first, before we write the code that passes them. • Technique: • Write a tiny fragment of a unit test. • Compile the unit test. • Write just enough production code to get the test to compile. • Then write another fragment to the test and start over.

23. What’s in an Iteration: Refactoring (1/2) • The ability to run some or all of the suite of unit and acceptance tests provides a simple way to determine if we’ve done something to break the system. • This means we can make changes to the code with near impunity. • We incorporate refactoring, the act of improving a program’s structure without changing it’s behavior.

24. What’s in an Iteration: Refactoring (2/2) • Every hour or so of active programming is followed by a period of refactoring. • We look at the code we’ve written and improve it. • The rule is: never let the sun set on bad code. • Recall that you’ve been taught to always keep you code bug free.

25. What’s in an Iteration: Open Office • The best environment for dX is an open office or laboratory. • The goal is to work together as a team, frequently interacting with each other, able to ask quick questions of each other, get quick advice, lean over and look at some code.

26. What’s in an Iteration: Continuous Integration • The source code control system used in dX is non blocking. • Anyone can check out a module, no matter who else might have it checked out. • First one to check in wins. Second one to check in merges. • Rule about checking in: • must first demonstrate that all of the unit and acceptance test pass

27. Conclusion • UML is a notation. Java is a programming language. They are irrelevant to the practices. • We need to use UML to create useful documents, but we don’t need them as part of a process. • In a dX project, the only diagrams produced are the ones that are needed right now.