1 / 17

Release Planning Methodology Overview

Release Planning Methodology Overview. Release Planning Framework. Provide a software release planning framework that balances business concerns software development concerns provides better predictability of end-date delivered debugged feature set provides early notification of slips

Gabriel
Download Presentation

Release Planning Methodology Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Release Planning Methodology Overview Lecture 3

  2. Release Planning Framework • Provide a software release planning framework • that balances • business concerns • software development concerns • provides better predictability of • end-date • delivered debugged feature set • provides early notification of slips • allows for re-planning as events unfold • deals explicitly with uncertainty Lecture 3

  3. The Product Lifecycle Lecture 3

  4. Follow on Lifecycles Lecture 3

  5. ? Next Release Potential Requirements Eliciting Potential Requirements • Starts with a wish list • Stated as business requirements • Features or architectural enhancements Lecture 3

  6. Sizing Potential Requirements • Cost / Benefit analysis • Cost: financial + opportunity = person days • Sizing in ECDs • Inherent size of the work item • Who will work on it • The productivity of that person on that work item • Ensure units are well-understood (more later) Lecture 3

  7. Sizing the Available Resources • Who can work on the next release? • Must have skills and familiarity to contribute • For how long? • Must count workdays in the coding phase • Each resource available all that time? • Subtract estimated vacation • How dedicated to the next release • Work factor = w • Converts 8-hour (nominal, arbitrary) days to time available to code and unit test during the coding phase • E.g. w=0.6 means can dedicate 0.6x8 = 4.8 hours/workday • Accounts for • Other tasks, sickdays, meetings, weekends, ... • Range is 0 .. 9, usually 0.6 or so Lecture 3

  8. The Capacity Constraint • After all is done in a release Actual Resource Used == Sum of Actual Times for Features • This is always true. It is a constraint. • In planning, knowing that this must work out at the end, can estimate both sides and force the estimates to be equal Resource Estimate == Sum of Feature Estimates Lecture 3

  9. p e r s o n s days 1 person-day A Geometric Analogy - Capacity Lecture 3

  10. A Geometric Analogy - Requirement Lecture 3

  11. A Geometric Analogy - Capacity Constraint Lecture 3

  12. A Simple Release Plan Dates: Coding phase: Jul.1—Oct.1 Beta availability: Nov.1 General availability: Dec.1 Capacity: days available Fred 31 ecd Lorna 33 ecd … … Bill21 ecd total317 ecd Requirement: days required AR report 14 ecd Dialog re-design 22 ecd … … Thread support87 ecd total317 ecd Status: Capacity: 317 effective coder-days Requirement: 317 effective coder-days Delta: 0 effective coder days Lecture 3

  13. Non-Coding Time and Resource • In RP, we explicitly plan coding only. • Other • types of resources: • Testers, documenters, managers • phases: • Specification, testing • These are sized relative to the coding phase and the coding resource • Why? • Debugged code is the ultimate target • Can’t be 90% done on that and still ship intended feature set • How much time to devote to documentation? • How much time to devote to testing? • When is enough, enough? • How? • Establish ratios • Measure what works for ratios for a given product • Adjust next time around • Converges rapidly • Initial guess is usually pretty good Lecture 3

  14. Resource Ratios • Typical ratios I have used • Adjust to taste • Assumes availability throughout the (overlapping) release cycle. Lecture 3

  15. Phase Length Ratios • Typical ratios I have used • Adjust to taste Lecture 3

  16. Release Overlap • Overlapping release cycles smoothes resource utilization Lecture 3

  17. Shipping The Release • After dcut, proactive management is gone. • Can only watch defect arrivals and hope for the best. • If your ratios are off: forgetaboutit, Lecture 3

More Related