📄 planninggame.html
字号:
<head><title>Planning Game</title></head><body><h1><img src="logo.gif"> Planning Game</h1>Recast from <a href="http://c2.com/cgi/wiki?ExtremeScheduleNegotiation">ExtremeScheduleNegotiation</a>.
<p>Planning is an emotional minefield. Of course Development would like to program faster. Of course the project manager would like to be able to say exactly how fast Development can go. Of course Business would like to be able to say exactly what they want. Of course Business would rather not change its mind. When any of the participants in planning begin acting these wishes (or rather in accordance with the fears that lie behind each wish), then planning doesn't work well.
<p>The <a href="PlanningGame.html">PlanningGame</a> gains a little emotional distance from planning by treating it as a game (hence the name). The game has a goal, playing pieces, players, and rules for allowable moves.
<p><strong>Pieces:</strong> The basic playing piece is the Story. Each Story is written on an index card. Stories have a value and a cost, although this is a little tricky because the value of some Stories depends on the presence or absence of other Stories, and the values and costs change over time.
<p><strong>Goal:</strong> The goal of the game is to put the greatest possible value of stories into production over the life of the game.
<p><strong>Players:</strong> The players are Business and Development.
<p><strong>Moves:</strong>
<p><em>Write Story</em>. Business can write a new Story at any time. For purpose of the Planning Game, writing a Story just means assigning it a value (in practice, it has to have enough information for Development to assign it a cost).
<p><em>Estimate Story</em>. Development takes every story and assigns it a cost of 1, 2, or 3 ideal weeks. If the estimate is higher, Business splits the story. (This may result in the story being implemented over more than one Iteration.) If the estimate is lower, Business merges it with another story. (Sometimes we just batch small stories willy-nilly until they add up to at least a week, for estimation purposes. Don't try that at home.) We use a <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> (see <a href="http://c2.com/cgi/wiki?ProjectVelocity">ProjectVelocity</a>) of 3 real weeks per ideal week to convert the final schedule to real time.
<p><em>Make Commitment</em>. Business and Development work together to decide what stories constitute the next release and when it will be ready to put into production. There are two ways to drive the commitment, Story Driven and Date Driven.
<p><em>Story Driven Commitment</em>. Business starts putting the Stories for the next release on the table. As each Story is introduced, Development calculates and announces the release date. This move stops when Business is satisfied that the Stories on the table make sense as the next release.
<em>Date Driven Commitment</em>. Business picks a release date. Development calculates and announces the cumulative cost of Stories they can accomplish between now and the date. Business picks Stories whose cost adds up to that number.
<p><em>Value and Risk First</em>. Development orders the Stories in a commitment so:
<OL><li> A fully working but sketchy system is completed immediately (like in a couple of weeks)
<li> More valuable Stories are moved earlier in the schedule (<a href="http://c2.com/cgi/wiki?BusinessValueFirst">BusinessValueFirst</a>)
<li> Riskier Stories are moved earlier in the schedule (<a href="http://c2.com/cgi/wiki?WorstThingsFirst">WorstThingsFirst</a>)
<p></OL><em>Overcommitment Recovery</em>. Development had predicted they could do 150 units of stories between now and the deadline. Based on measuring <a href="http://c2.com/cgi/wiki?ProjectVelocity">ProjectVelocity</a>, they find and immediately announce that they can only do 100. Business selects the 100 units of Stories to retain, deferring the other Stories to a future release. (Or highly unlikely: Business decides to defer the deadline to get the extra 50 units done.)
<p><em>Change Value</em>. Business changes the value of a Story. In response, Development may change the order of Stories not yet completed.
<p><em>Introduce New Story</em>. Business writes a new Story. Development estimates it. Business defers Stories in the current Commitment whose cumulative cost is the cost of the new Story. Development re-evaluates Value and Risk First.
<p><em>Split Story</em>. Business splits a Story into two or more. Business assigns a value to each, and Development assigns a cost to each. Typically this is done because resources do not permit the whole story to be done soon enough.
<p><em>Spike</em>. Business can divert Project resources to do a throwaway Spike to fight a fire or prove a concept. If this Spike is anything more than a temporary fix, Business makes a <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a> to account for it. That Story is scheduled according to Value And Risk First. Regular spikes, especially fire-fighting ones, will affect the <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a>.
<p><em>Re-estimate</em>. Development estimates the remaining stories in the Commitment again. This can spark an <a href="http://c2.com/cgi/wiki?OvercommitmentRecovery">OvercommitmentRecovery</a>.
<p><strong>Other moves? Players? Goals?</strong>
<p>One we're finding useful at <a href="http://c2.com/cgi/wiki?WebSense">WebSense</a>:
<p><em><a href="http://c2.com/cgi/wiki?MotherhoodStory">MotherhoodStory</a></em>. Development looks at a <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a> and sees it's just the tip of an iceberg. The <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a>, or the principle it embodies, is declared to be a <a href="http://c2.com/cgi/wiki?MotherhoodStory">MotherhoodStory</a>. Developers suggest several <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a> that the <a href="http://c2.com/cgi/wiki?MotherhoodStory">MotherhoodStory</a> generates and tell them to Business. Business thinks hard and returns some or none of them as real <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a>.
<p>Important idea, and I personally like the terminology. Some kind of hierarchy and/or network of <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a> seem vital to me from past experience. Except in the olde days we didn't used to call them <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a> but <a href="http://c2.com/cgi/wiki?SuccessStatement">SuccessStatement</a>'s (sorry). These have definitely needed to be both decomposed and inter-linked through "solves" relationships in the early stages of customer discussion and development.
<p>It's a key matter of judgment to know when you have enough coherence in the system vision and enough detail in the 'leaf' stories to get on with implementation at least of the <a href="SpikeSolution.html">SpikeSolution</a> sort. <a href="http://c2.com/cgi/wiki?TomGilb">TomGilb</a>'s rule is: some time in the first week is fine. Sadly, this doesn't leave too much room for <a href="BigDesignUpFront.html">BigDesignUpFront</a>! --<a href="http://c2.com/cgi/wiki?RichardDrake">RichardDrake</a>
<p><hr>
<p><em><a href="http://c2.com/cgi/wiki?RefactoringIteration">RefactoringIteration</a></em>. Development recognizes that something is non-optimal with the <a href="SystemMetaphor.html">SystemMetaphor</a>. Fixing this will affect everything; if it weren't for the <a href="http://c2.com/cgi/wiki?TestingFramework">TestingFramework</a>, it would be unthinkable. A whole iteration is set aside to do this; the work is split up into <a href="http://c2.com/cgi/wiki?EngineeringTasks">EngineeringTasks</a>, not <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a>, and the whole schedule is on hold until it's done.
<p><em>Certainly <a href="http://c2.com/cgi/wiki?RefactoringIteration">RefactoringIteration</a>'s are done. Since adding an Iteration affects the entire schedule, usually not favorably, it's not clear to me that development can just fire one into the plan. I think I'd be more likely to use my measured load factor to note that we had slowed down, consider whether an iteration's investment to bring it back up was worthwhile. I feel this is a recovery technique, not a planning technique. --<a href="RonJeffries.html">RonJeffries</a></em>
<hr>
Some mention needs to be made of dependencies between stories. That can constrain their reordering. Also stories can require resources not under the control of any of the players (as when you need to buy new hardware or system tools which won't be available for another 2 months).
-- <a href="http://c2.com/cgi/wiki?DaveHarris">DaveHarris</a>
<p>One of the lessons I learned from <a href="http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation">ChryslerComprehensiveCompensation</a> was that I could ignore story dependencies for planning purposes. This came from two sources that I could identify. First, Business never asked for irrational stories, like insisting on reports even though they didn't want the stories that created the data on which the reports were based. Second, doing business value first meant that you would naturally do "Basic Paycheck" before you did "Enhanced Paycheck", since the basic one was far more valuable than the enhanced.
<p>I'm not sure this lesson is generally applicable, but it certainly proved so for us. And it is SO much simpler not having to track dependencies...
<p><em>I think what happens is that most dependencies amount to a lot of little things waiting on one big thing: "we can't do any of these until we get the new server". People seem to manage these just fine informally. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>The point about external resources is well taken. My general strategy is to cut back on requirements until there are no more external resources, or to pull them into the team. If this isn't possible, you would have to do something to manage them. Please suggest addtional rules, pieces, and players.
--<a href="KentBeck.html">KentBeck</a>
<p><em>Kent-- see what I did to Estimate Stories above, regarding <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a>, which we haven't mentioned here. --R</em>
<p><em>Ron-- I explain it now by saying that the estimates are in terms of tokens (I like gummi bears), and the team gets to say how many gummis they can produce per month. This keeps you out of crazy arguments about why you only engineer 1/3 of the time, which is not what the <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> is saying, it's just a ratio from one measure to another (the calendar). Do you like this better or your edits (which are fine)?</em>
<p><em>Kent-- I see the point about the load factor arguments being reduced, but I don't know how to tell someone how to estimate in bummi gears. Also they seem just a bit frivolous and as you know I am a serious person. Starting off on the first <a href="http://c2.com/cgi/wiki?CommitmentSchedule">CommitmentSchedule</a> I can say "estimate in ideal weeks" and they have a clue. How do we bootstrap bummi gears? Why not write it up the other way under the existing one, and let's see how it works?</em>
<p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -