1. Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

2. Resumes – please email before Friday at 8am. Everyone needs to submit an informal resume List of CS courses taken Expected graduation date Interested in leadership position (yes/no) Interested in being a manager (yes/no) Programming skills: Languages Windows Programming Networks Databases

3. Managers Provide direction What are we going to do? Based on customer/market needs Manage personnel Keep the team productive Represent Business in the Planning Game Work with customers to determine needs Write performance evaluations

4. Team Leaders Provide technical leadership Principal Advisor to management Provides technical assistance to team members Makes important design decisions Represent Development in the Planning Game along with the rest of the development team Write performance evaluations

5. Programmers Represent Development in the Planning Game Design Write Program Code Write Test Refactor Write performance evaluations

6. Customers Me

7. Virtual Companies (Teams) Team 1Team 2Team 3Team 4 Adam LAdam N (M)David (M)Bernard Ashley (T)Derick (T)K.J. (T)Denise RachelEvanMikeKara (T) Sarah (M)MattWayneKirk (M) Mikey (M) Manager (T)Technical Lead * All assignments are subject to change.

8. What Latitude to do we have as a team? Can we give our team a new name? (Yes, please do. But use good taste.) Can we work on another project? (maybe) Can we switch team members? (maybe) Can teams cooperate? (probably, but get approval from the instructor first.) Can we write a web application? (no) Can we write in something other than C++? (no) Can we use a different software development process? (no) Make specific proposals. I will consider anything, but I reserve the right to say “no.”

9. Software Development Extreme Programming Relatively new software development process Very clearly defined roles for the development team (Development) and the management team (Business) Extreme Programming Explained – Embrace Change Kent Beck, 2000, 2005 An incremental software development process One of a family of “agile” development processes Less formal specification and design

10. Frequent Releases A release is software that is delivered to the customer In extreme programming (XP), releases are made frequently Releases consist of working code, but they are usually snapshots of works in progress. Releases allow the customer to see how the system is developing and react to problems at early stages

11. Iterations Releases are generally the result of a set of iterations. Most of the planning in XP happens between iterations. Releases are short, so iterations are even shorter. As often as one per week

12. The Planning Game Business and Development play the planning game to determine what to do next.

13. Stories Each system feature is broken down to 1 or more user "stories.” e. g., “a student drops a course,” “a use logs in,” “the system is asked to find a specific course that fits in a given schedule.”

14. Stories on Index Cards Stories are written on index cards just enough to remember what they are. We don’t want lots of details.

15. Index card contents name of the story date brief description of story number of "points" the story requires (cost) estimates are not in hours, they are in points that have a consistent value Notes Anything helpful

16. Stories are dynamic. rewritten broken up into smaller stories if they are too large combined with other stories if they are too small. discarded

17. Three Phases of Planning Game Phases are cyclical - you will move back and forth between the phases during the course of the game. Exploration Determine what new things the system might do. Commitment Decide what subset of all possible requirements to purse next Steering Update the plan based on what Business and Development learn

18. Exploration Determine what new things the system might do. Moves Write a story (Business) Estimate a story (Development) Split a story

19. Commitment Decide what subset of all possible requirements to purse next. Moves Business Sorts by Value Three piles Essential Significant business value Nice to have Development Sorts by Risk Three piles Cost estimates can be precise Cost estimates can be reasonably precise Cost estimates cannot be precise

20. Commitment Moves (continued) Set Velocity Development tells Business how fast the team can work. Choose Scope Business chooses the set of cards that will be included in the release

21. Steering Update the plan based on what Business and Development learn Steering Moves: Iteration Business picks one iteration worth of the most valuable stories to be implemented. Recovery If Development realizes that it has overestimated its velocity, it can ask Business to specify a smaller subset of the current stories.

22. Steering Moves (continued) New Story If Business realizes it needs a new story, Business removes stories with equivalent estimates and inserts the new story. Reestimate If Development feels that the plan no longer provides an accurate map of development, it can re-estimate all of the remaining stories and set velocity again.

23. Steering Moves (continued) Velocity The number of story points we complete each iteration is our "velocity." Our next iteration will use our current velocity for determining the number of points we can commit to for the next iteration. Release Planning Given velocity, Business gets good estimates of the cost of features Managers use both cost and priority to schedule the development sequence of features.

25. Players are just the programmers No management Stories are broken in tasks Tasks are recorded on index cards Programmers accept responsibility for tasks Programmers estimate the time required for each task (perfect programming days/hours) Programmers test and implement tasks using pair programming The Iteration Planning Game

26. Exploration Phase Write a task Split/combine a task Iteration Planning Phases

27. Commitment Phase Accept a task Programmer volunteers to accept responsibility for a task Estimate a task The programmer who has accepted responsibility for a task estimates the time required to complete it (usually in perfect days or perfect programming hours) Set load factors What percentage of the available time will you work on your tasks? Balancing Determine how well the available time matches the estimated task time for each individual – redistribute as necessary Iteration Planning Phases

28. Steering Phase Implement a task Use pair programming Use test-driven development Record Progress Keep track how much time has been spent on each task Recovery Reduce task scope of task/story Remove non-essential tasks Get more/better help Ask customer to defer some stories Iteration Planning Phases

29. Stories A sprite is placed on the screen (one point) Create a sprite path (four points) A sprite walks a path (four points) A user places a tower (two points) A player purchases a tower and places it on the screen (one point) A tower destroys a sprite (one point)