1 / 21

The Capacity Constraint

The Capacity Constraint. Release Planning. What to Build: have a big list, choose the most important from it By when to build it: not too early that we flood our customers with releases and the overhead kills us not too late that they think us unresponsive Using how many people

aren
Download Presentation

The Capacity Constraint

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. The Capacity Constraint Lecture 4

  2. Release Planning • What to Build: • have a big list, choose the most important from it • By when to build it: • not too early that we flood our customers with releases and the overhead kills us • not too late that they think us unresponsive • Using how many people • usually fairly fixed for the next release. • For the next release, determine • What to build, • By when to build it, • Using how many people. Can we do all three? Lecture 4

  3. A geometric analogy p e r s o n s days 1 person-day The Capacity Constraint • A fundamental constraint that governs all planning activity. Lecture 4

  4. Features The Capacity Constraint • A fundamental constraint that governs all planning activity. A geometric analogy People Days A certain requirement A certain capacity Lecture 4

  5. features people days The Capacity Constraint • A fundamental constraint governs all planning activity. It’s ‘gotta all fit! Lecture 4

  6. Release Planning • What to build F • By when to build it T F  N x T • Using how many people N • Need to build an initial plan that respects the capacity constraint • Need to continuously update the plan to maintain its adherence to the capacity constraint. Lecture 4

  7. Most Common Problem • Comes from either • not knowing • knowing but hoping for the best (Yourdon Death March) (can happen initially or as we go) Lecture 4

  8. Add time Cut features Both Dealing with Issues as they Arise Developer leaves the team Lecture 4

  9. Other Happenings Lecture 4

  10. Organizational Issues • Management must appreciate that software development carries with it certain inherent risks. • The business of a software organization is to manage and adapt as possibilities continuously become reality. • Ranting and raving is unproductive • With good data, good managers will make good decisions. Lecture 4

  11. F = N x T N T The Quantitative Capacity Constraint • Post-Facto, the following relationship must hold. • But, it requires careful definition. We define carefully so that we know what it is we are trying to estimate, and how to compare actuals against estimates for post-mortem. Lecture 4

  12. Number of Workdays: T • The number of full-equivalent working days for fork to dcut. • Subtracts • Weekends • Statutory holidays • “Company Days” • Subtracts anything we know in advance that nobody is expected to work. Lecture 4

  13. Developer Power: N • The average number of dedicated developers per workday working during the T-day period. • Dedicated Developer? Lecture 4

  14. Work Time & Dedicated Time • Work Time or Body Time • Defined as 8 hours per workday • Excludes weekends, stat. holidays, vacation entitlement. • E.g., 9-to-6 with 1 hour for lunch. • Dedicated Time • Uninterrupted hour equivalents. • Time dedicated to adding new features to the release. • Uninterrupted Time • 4 hrs with 30 min. of constant interruptions • Not 3.5 hrs of dedicated uninterrupted time – more like 2 • 2 hrs with NO interruptions at all Lecture 4

  15. Examples of Dedicated Losses • Maintenance (tracking down and fixing defects) on previous releases • Other simultaneous projects • Team-leader duties (& helping others) • Meetings • Training • Unexpected, non-made-up days off (e.g., sick days) • Sales/marketing support • Loss of flow due to interruptions Lecture 4

  16. Measuring N • Assume each developer understands the concept of a dedicated uninterrupted hour. • Get each of the n developers to record how many dedicated uninterrupted hours they spent in total during the coding phase. • hi is what’s in the time tracking system for the ithdeveloper. Lecture 4

  17. Attributing N • diis the number of days available during the coding phase • vi is the number of vacation days they took during the coding phase • hiis as before Substitute to get back to: Lecture 4

  18. Example • Bob called in sick for 2 days: accounted for in h • Bob took an afternoon off, but worked on the weekend to make up for it: accounted for in h Lecture 4

  19. Features Features fk = dedicated hours / 8 it took to code the kth feature. Lecture 4

  20. Post-Mortem • Imagine a time-tracking system that could track • hi,k,d • dedicated (uninterrupted) hours spent • by the ith developer • on the dth day • doing coding work on the kth feature • each such quantum would appear on both sides of F= N x T constraining them to be equal. • See section 5.10 in book for proof. Lecture 4

  21. Example Release Plan • Sample Deterministic Release Plan Lecture 4

More Related