Roles

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) (M) Manager 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 mostvaluable 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 newstory. • 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.

24. Iteration Planning

25. The Iteration Planning Game • 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

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

27. Iteration Planning Phases • 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

28. Iteration Planning Phases • 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

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)