Today ’ s goals ❚ How can we plan and schedule the project activities? Planning and risks ❚ What are the biggest risks in a software project? How can we mitigate them? 1-2 1 Announcements Problems with proposals ❚ Too vague (e.g., “ Study xyz ” ) Extra credit: ❙ Can ’ t tell if task has been done - at each lecture we vote MVP ❙ Tasks too big - answering questions on Piazza ❙ Too much creativity ❘ Copy game, don ’ t design game ❚ Too small Homework 1 due at 5pm tomorrow, Jan 9 th ❙ Make bigger, but prioritize tasks so you can WA0 due at 4pm in class, next Tue (Jan reduce scope (watch for “feature creep”) 13 th ) CS361 02-3 CS361 02-4 Planning in XP How to plan ❚ Planning Game ❚ Make a list of everything you have to do ❚ Customer / Developer ❚ Decide when you will do each thing ❙ How long will it take? ❚ User stories, estimates ❚ Make sure you have what you need for ❚ Iteration planning meeting each task ❚ e.g., Microsoft is very supportive to assist with software/books for their technology CS361 02-5 CS361 02-6 1
How long will it take? Scheduling ❚ Compare with other tasks you have done Determine list of tasks ❚ If too hard to estimate, break into smaller Determine needed resources for each task steps ❙ people ❚ Get several people to estimate ❙ computers, testing system Schedule tasks ❚ Asking the manager to make the plans does not work very well in practice ❙ some tasks depend on others ❙ some tasks compete for resources CS361 02-7 CS361 02-8 PERT Charts 5 8 Develop parser ❚ http://en.wikipedia.org/wiki/ 3 14 3 17 0 3 6 Program_Evaluation_and_Review_Techniq 9 3 Integrate Define ASTs Develop type ue 3 checker 14 11 Develop code generator ❚ Critical path - path that takes longest ❚ Slack - extra time for task ❚ Only optimize steps on critical path CS361 02-9 CS361 02-10 Gant Charts Project tracking http://en.wikipedia.org/wiki/Gantt_chart ❚ Keep track of when each task is finished ❚ Compare plan to reality Jan Feb Mar April May Big task ❚ Tasks are either finished or not Task 1 ❚ Forbid “ 75% finished ” - decompose tasks Task 2 Task 3 CS361 02-11 CS361 02-12 2
Schedule When is a task finished? ❚ List of dates, and the tasks to be finished ❚ Must be objective (or started) at each. ❙ E.g., “ Design passed review ” not “ Design is reusable ” ❙ Excel ❙ E.g., “portable because we got it to run on 3 ❙ Task & date, sorted by date platforms” ❙ Separate column for actual completion date ❚ Different tasks are evaluated differently ❙ In XP, a programming task is not finished until all unit tests run correctly. ❙ In RUP, writing a document is a separate task from reviewing it. CS361 02-13 CS361 02-14 Risks What can go wrong? Problem harder than we thought. ❚ Product risks We waste time, take too long. ❚ Project risks Customers don ’ t know what they want. ❚ Business risks System is too slow. Stock options become worthless, developers quit. ❚ Success does not require winning big, but Developers get bored and quit. avoiding failure. Developers like new technology. It doesn ’ t work. Customers run out of money and kill the project. CS361 02-15 CS361 02-16 Risks Biggest risks Process should address biggest risks: Projects get killed for same old reasons. ❙ Wrong requirements Use database of problems to identify risks. ❘ iterative development ❘ work closely with customer http://smad-ext.grc.nasa.gov/rmo/riskdb/ ❙ Constantly changing requirements ❚ Assess risks. ❘ manage changes ❚ Avoid risks. Contain. Mitigate. ❘ keep schedule up to date ❙ Inadequate schedule ❚ Monitor risks you can ’ t avoid. ❘ keep schedule up to date ❘ reduce scope CS361 02-17 CS361 02-18 3
Risk management Class activity ❚ Risk assessment: a document listing risks, their likelihood, and their severity ❚ e.g., Amazon - What are the main risks for your class project? How are you managing them? ❚ Decide whether you are going to try to avoid this risk or just to monitor it CS361 02-19 CS361 02-20 Different ways of Managing risk in XP managing risk ❚ Iteration ❚ Risk: later iterations need more ❚ Do the simplest thing that could possibly sophisticated design than first ones work ❙ XP: keep design clean and simple and change ❚ Customer picks most important stories it if necessary ❙ RUP: elaboration phase should consider all ❚ Developers estimate time. Stories that use cases and should select ones that are they can ’ t estimate (or that have long risky to do first estimates) are risky. Developers must work (prototype) to make reliable estimate. CS361 02-21 CS361 02-22 Different ways of managing risk Waltzing with Bears ❚ Risk: As developers leave the project, new ❚ Managing Risk on Software Projects ones must learn the system. ❚ Tom DeMarco and Timothy Lister ❙ XP: Use pair programming to teach new ❚ Dorset House Publishing developers the system and to make sure that knowledge of the system is spread as widely as possible. ❙ RUP: Document the architecture and key use cases. CS361 02-23 CS361 02-24 4
Why people don’t manage risks ❚ Risk management is not the same thing as ❚ Don ’ t be a negative thinker! worrying about your project ❚ Don ’ t raise a problem unless you have a ❚ Core risks: solution for it ❙ Schedule flaw ❚ Don ’ t say something is a problem unless you can prove it is. ❙ Requirements inflation ❙ Turnover ❚ Don ’ t raise a problem unless you want to ❙ Specification breakdown be responsible for solving it. ❙ Underperformance CS361 02-25 CS361 02-26 Discovering risks Management tips ❚ Think of catastrophic outcomes: “ What is ❚ Assign a project manager your biggest fear? ” ❚ Have a single person responsible for each ❚ Scenarios item. ❚ Root causes ❙ “ If everyone is responsible, no one is responsible ” ❚ Have a plan (agenda) for each meeting ❚ Make everything public ❙ Plans, actuals, metrics, … CS361 02-27 CS361 02-28 XP user stories (HW1) XP user stories (HW1) User stories describe the features of the ❚ Games have one use case: user plays software (WHAT), not the implementation game (HOW) As a <role>, I want <goal/desire> ❚ For use cases to be good requirements ❚ E.g.: Search for customers document, more detail is needed. ❙ As a user, I want to search for my customers ❙ Use lower-level goals (e.g., tower shoots by their first and last names. monsters, hoarde creates monsters) User stories don’t contain GUI details CS361 02-29 CS361 02-30 5
Recommend
More recommend