1. Chapter 7 The Practices: dX

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

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

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

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

6. 6 Iterative Development: The Initial Exploration (2/2) Sit down with the customer and talk over what the system has to do. Sit down with the customer and talk over what the system has to do. As we discuss the system we identify use-cases. 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. 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. 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. This exploration process never ends.

7. 7 Iterative Development: Estimating the Features (1/2) Write an estimate on each user story card. Write an estimate on each user story card. The unit is not important. The unit is not important. Make the estimates based on a previously implemented story. 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. 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. A story should never be longer than three or four days worth of effort for the whole team.

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

9. 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. Planning is simply a matter of using the current velocity to figure out which stories will be done each iteration. First release: First release: six iterations or about three months 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). 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. In six iterations we can get 300 man days of work done.

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

11. 11 Planning: Planning Iterations (1/4) On the first day of each iteration, we create a plan for that iteration. 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. 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. Stories are then broken into tasks.

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

13. 13 Planning: Planning Iterations (3/4) Sign up for tasks Sign up for tasks Each developer keeps a budget in the back of his or her head. 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. 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. A developer can continue to sign up for tasks until his budget is zero.

14. 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. 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. Remove stories if there are still tasks left on the board.

15. 15 Planning: The Midpoint Assume that we settled on 20 story points for the iteration. Assume that we settled on 20 story points for the iteration. In the midpoint of the iteration, we should have 10 story points done. 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 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. If we got 15, we ask the customer to add more stories so that the total is 30.

16. 16 Planning: Velocity Feedback At the end of the iteration, we recompute our velocity, and plan the next iteration with the new velocity. 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. This is how we continuously calibrate our estimates.

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

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

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

20. 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. 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. 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. On average, each programmer spend about half his time working on the tasks he signed up for. Does this cut productivity in half? Does this cut productivity in half?

21. 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. 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 were delivered to the programmers before the iteration is half over. These tests are the true requirements documents. These tests are the true requirements documents.

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

23. 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. 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. 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. We incorporate refactoring, the act of improving a program’s structure without changing it’s behavior.

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

25. 25 What’s in an Iteration: Open Office The best environment for dX is an open office or laboratory. 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. 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. 26 What’s in an Iteration: Continuous Integration The source code control system used in dX is non blocking. 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. 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. First one to check in wins. Second one to check in merges. Rule about checking in: Rule about checking in: must first demonstrate that all of the unit and acceptance test pass must first demonstrate that all of the unit and acceptance test pass

27. 27 Conclusion UML is a notation. Java is a programming language. They are irrelevant to the practices. 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. 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. In a dX project, the only diagrams produced are the ones that are needed right now.