Prioritization. Summary. Planning. risk is a factor when prioritizing features. Risk. Risk. Value. Value. velocity-driven

Transcription

1 Prioritization! Risk-value relationship for features: Prioritization! Risk-value relationship for features: Risk high low low high risk low value low risk low value Value high risk high value low risk high value high risk is a factor when prioritizing features Risk high low low avoid do last Value do first do second high! what order to develop features? Planning! Two-phase funding:! request funding in two phases! initial inception iterations to refine Summary! Two-level planning: velocity-driven! revision planning! given stories/points, estimate project duration! determine/schedule time boxes! iteration planning! break down work into tasks accepted by members! get estimated task durations Release Plan Iteration Plan planning horizon months 1 to 4 weeks items in plan stories tasks 69 estimated in story points hours 70

2 Agile Planning! Ideas:! just enough planning! e.g., avoid detailed task plans for months in advance Agile Planning! Discussion: high high start low! iteration planning more than one iteration?! what is the goal of the iteration?! coordinating multiple teams?! relation to Scrum! choose product backlog items for sprint backlog 71! team expands sprint backlog items, has daily scrums Ends Uncertainty (What) low Means Uncertainty (How) end [Laufer, 1996]! how to navigate uncertainty space? 72 Agile Planning! Discussion:! How would you organize user story cards on a wall to reflect:! level of progress! estimated story points! planned iteration! priority all at once?! Quote:! Project teams detest progress reports because it manifests their lack of progress.! anything else? 7 74

3 ! Goal:! tracking progress and productivity! done with the aid of the team! provides feedback loop for future planning! helps to gain trust and credibility! what measures would be useful to track?! can use these measures to help in predictions! Measuring velocity:! story points completed by team in the iteration Story R1 R4 R5 Velocity Story Points 4 75! what about partially completed stories? 76! Measuring velocity:! count only points for completed stories! difficult to determine what percentage is done for partial stories (last 10% not really 10%)! incomplete stories do not represent anything of value to the customers or users! incomplete stories may be an issue of stories being too large! Example planned versus actual velocity: Velocity initially, better than planned actual originally planned don t predict trends until after a few iterations how to predict? Iterations 78

4 ! Predicting future velocity:! look at actual observed values! e.g., 25, 26, 0! consider the range! e.g., 25 to 0 predicted! or consider averages! e.g., average of worst, recent, etc.! Predicting future velocity:! or divisors for velocity ranges Iterations Done Low Divisor High Divisor or more ! or consider the average with some cushion! e.g., 27 ± 15% = 2 to 1 predicted 79! applies the cone of uncertainty distribution [Cohn, 2006] 80! Velocity-driven:! bring stories to closure so their points are counted in the velocity! avoid having many stories nearly done, with only a few actually done! lots of loose ends may be a symptom of lacking teamwork or poor integration! understand how decisions could impact the velocity! Example planned versus actual cumulative story points: Cumulative Story Points actual originally planned less completed functionality than planned? don t assume the gap will be made up by higher velocity later! drives the product toward periodic releasable Iterations states 81 82

5 ! Example release burndown chart: spinning out of control? Story Points Remaining burnup reflects both progress and changes to story points (e.g., added new stories) finish on time? 5! Example progress and changes: Remaining story points at start of iteration Completed story points during iteration Changed estimates on existing stories Story points from new stories Remaining story points at end of iteration Iterations = ! Corresponding release burndown chart:! Iteration burndown chart: 150 Story 100 Points Remaining 50 how to express both progress and changes separately? Task Hours Remaining daily time accounting of work remaining in an iteration Iterations 5 85 time remaining (versus time expended) Days 86

6 Task create HTML page generate results page write servlet to perform search create sample data Total Task Hours Left Who JD JD AJ AJ Estimated Hours (Left) on a whiteboard, each team member revises their estimate as a task is done or! High task visibility (versus preplanning)! task boards! daily stand-up meetings (scrums)! what tasks did you work on yesterday?! what tasks will you work on today?! what obstacles stand in your way?! min work increments! guards against goldplating! developers adding unplanned features to wow the customer, make their mark, or ease the production pressure at the end of the day 87 88! Using task hours expended:! after a few iterations, can use the actual hours expended on tasks in the previous iteration to help predict the team s capacity to commit to tasks in the next iteration! e.g., 6 people x ays x 8 h per day = max 480 h, but team expended about 60 h in tasks! iteration planning! more commitment than velocity driven! hours versus story points 89! Feedback:! defined process control! planning and prediction beforehand! empirical process control! measure and adaptive during project! visibility of the intermediate steps in the process! inspection to evaluate immediate results! adaptation to make adjustments in the process 90

7 Tasks! Dependencies:! tasks may have dependencies among them! what is first?! what is next?! what is concurrent? Tasks! Dependencies:! given task A (predecessor) and task B (successor)! finish-start! A must finish before B can start! even before considering resource constraints 91! finish-finish! A must finish before B finishes! does not matter which starts first 92! e.g., training must finish before system is finished Tasks! Dependencies:! start-start! A must start before B can start! does not matter which finishes first! e.g., study expected data before designing the data dictionary PERT/CPM Charts! CPM! Critical Path Method! tasks on the nodes, critical path in bold! start-finish! A must start before B is finished! e.g., beta-testing must start before the system is finished 9! consider task and resource dependencies 94

8 PERT/CPM Charts! PERT! Program Evaluation and Review Technique! activities on transitions, events on nodes, horizontal critical path PERT/CPM Charts! Critical path:! path from the start to end of a project where any task that is delayed will delay the entire project! longest duration path! mathematically derived! critical tasks (on the path) have no slack Critical Path! Considering slack (float):! earliest start date, earliest finish date! latest start date, latest finish date! working back from a deadline! for tasks on the critical path, a late start implies a late finish Critical Path! Notes:! critical path may change, as non-critical tasks use up their slack time (e.g., delayed start or finish)! speeding up a non-critical task has no effect on the project s duration! realistically, most tasks in an actual project are not on the critical path 97 98

9 PERT/CPM Chart Gantt Chart! Exercise:! create a CPM chart for the tasks in your next iteration! derive the critical path ID Task/Subtask project management needs analysis specify system select server select software select cables Duration 1 Jan Feb Mar Apr 7 purchase 8 write manuals 1 9 wire offices 20 d 10 set up server 11 develop training 1 12 install software 1 connect network 14 train users test accept Gantt Chart Gantt Chart! Notes:! visualize start/finish times of tasks/subtasks! can also show planned/actual times, milestones, dependencies, people/resources ID Story Iteration 0 Iteration 1 R1 R4 Duration 1 Jan Feb Mar Apr 2 Iteration 2 planned start actual start planned finish actual finish milestone event (no duration) R2 R Iteration! adapt chart for agile methods?! [Cohn, 2006] 101 release plan 102

10 Gantt Chart! Variations:! instead of listing tasks, list people Project Problems! Failure:! space shuttle Challenger disaster ID 1 2 Person JD AJ TC Feb Mar! technical and management causes! go fever! management override! inadequate risk evaluation ! Idea:! a commonly occurring solution, with decidedly negative consequences! Discussion:! What can go wrong when managing a project?! many management-related antipatterns! e.g., indecisive management, perfectionism! lots to manage! requirements, qualities, complexity, change control, resources, technology churn, etc.! varying impact at application, system, enterprise, and industry levels

11 ! Project management:! blowhard jamboree! opinions of so-called industry analysts influence technology decisions! analysis paralysis! striving for perfection or complete knowledge leads to project gridlock! viewgraph engineering! developers become too stuck on preparing diagrams instead of developing software! Project Management:! death by planning! excessive upfront planning (rather than a pragmatic initial plan and incremental re-planning)! fear of success! worrying obsessively about things that might go wrong! corncob! difficult people obstruct or divert the software process, by political manipulation ! Project Management:! intellectual violence! someone who understands a certain technology uses this knowledge to intimidate! irrational management! habitual indecisiveness leads to chronic development crises! smoke and mirrors! management, eager for business, encourages customer misconceptions and scope creep! Project Management:! project mismanagement! inattention to the software process (monitoring, control, follow-up)! throw it over the wall! designs intended as suggestions are taken literally, and given undue weight! fire drill! months of boredom, followed by demands for immediate delivery

12 ! Project management:! the feud! personality conflicts between managers is reflected in the attitudes and actions of their employees! is dangerous! useful, but may not be appropriate for certain topics and sensitive communications! Project management:! detente! a discrete subprocess assumes a larger than necessary importance in comparison to others! nirvana! decision maker focuses on avoiding conflict rather than resolving issues (e.g., between two differing technical solutions) References! Software Development for Small Teams! G. Pollice et al.! Addison-Wesley, 2004! More About Software Requirements! K. Wiegers! Microsoft, 2006 References! User Stories Applied! M. Cohn! Addison-Wesley, 2004! Agile Estimating and Planning! M. Cohn! Prentice Hall,

13 References! Scaling Software Agility! D. Leffingwell! Addison-Wesley, 2007! Software Project Survival Guide! S. McConnell! Microsoft, 1998 References! Painless Project Management! P. McGhee and P. McAliney! Wiley, 2007! 10 Steps to Successful Project Management! L. Russell! ASTD, References! The Instant Manager! Cy Charney! Stoddart, 2000 References! Project Management for IT Professionals! CompuMaster, 1998! 10 Minute Guide to Project Management! J. Davidson! Macmillan, 2000! On Time Within Budget! E.M. Bennatan! Wiley,

14 References! Object-Oriented Software Engineering! B. Bruegge & A. Dutoit! Prentice-Hall,