planninggame.html

极限编程 Extream Programing

Frankly gents I <em>like</em> Ideal Weeks, because I can estimate in Ideal Weeks, other developers can too, and it gives us a nice conservative way to start dealing with <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a>. Why fix it if it ain't broke? --<a href="http://c2.com/cgi/wiki?PeterMerel">PeterMerel</a>
<p>
Why not use money in stead of IdealWeeks<a href="http://c2.com/cgi/wiki?edit=IdealWeeks">?</a> (you can even display it in U.S. Dollars, Euros, or Yen at the current exchange rate on a web site) and assume there is no problem distributing the project among n developers. I am only half fidding - it might make management accountable to finance. --TurlochOTierney
<p>
The broken-ness is that it is so tempting to play with the <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> to make the final date come out &quot;right&quot;. I heard a story of a project that had the developers scheduled for 4.3 hours of productive work a day. The schedule started to slip so they changed the factor to 5.3. Problem solved! For a month.
If you can resist this temptation, there's nothing wrong with IdealEngineeringTime<a href="http://c2.com/cgi/wiki?edit=IdealEngineeringTime">?</a>. --<a href="KentBeck.html">KentBeck</a>
<p>
Just as Kent says, Peter. The scenario is that you do a schedule, it shows a date that management doesn't like. They say &quot;What's this 3? Make it 2.5 and it will all work out.&quot;  Towards the end, maybe you have data. But the IP factor doesn't convert to the CS factor even then.  It's hard to resist saying &quot;we'll try&quot;.  --<a href="RonJeffries.html">RonJeffries</a>
<p>
With respect then, I think you're fixing the wrong thing. You've said all along that <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> is supposed to be a measured property, not a specified one. It's a metric, right? You can no more ramp up a metric by dictating than Canute could order back the tide. You can tell your developers, &quot;work harder, work longer, do it for the gipper, I want to see that <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> move, damn it!&quot;, but you can't tell them, &quot;the <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> is now 1. Good Day gentlemen.&quot; any more than you can tell them, &quot;It is now summer. Bermuda shorts are required to be worn in office hours.&quot;
<p>
But if your organization is telling you that they can't abide your process, and you still have the faith in your process that I think you have, then maybe you need to move your development process some place where it is appreciated. In other words, stick to your guns, damn it. --<a href="http://c2.com/cgi/wiki?PeterMerel">PeterMerel</a>
<p>
Easy to say, Peter, but as we all know, very hard for developers to do. Management can be really good at making developers feel guilty for being human. Nonetheless, I prefer the ideal days formulation, as I discuss in <a href="http://c2.com/cgi/wiki?GummiBearsConsideredHarmful">GummiBearsConsideredHarmful</a>.  --<a href="RonJeffries.html">RonJeffries</a>
<p>
What's so ideal about an ideal day? It's just a day devoted to development without interruption. We only use it because it is what comes to mind when a developer is asked to either recall past effort or estimate futures. Think about where the extra time goes. I don't count time spent making obvious corrections in ideal time because developers don't remember it as such. That doesn't mean we don't fix bugs. It means we count bug fixing against our &quot;productivity&quot; as measured by load factor. Same with doing backups, or clearing printer jams, or catching up on office politics. By &quot;ideal&quot; we mean idealized in our memory. It's how we think when scheduling, not how we work or even want to work. -- <a href="http://c2.com/cgi/wiki?WardCunningham">WardCunningham</a>
<p>
In my experience it helps to present ideal time in hours.  Seven people for three weeks at a load factor of 0.5 is 17 ideal days or 136 hours.  People just don't seem to query the figure presented as hours: I'm not sure if this is because the arithmetic isn't so obviously strange, or because of the pseudo-precision of three significant figures. -- <a href="http://c2.com/cgi/wiki?DaveCleal">DaveCleal</a>
<p>
<em>How do you get 136 hours from seven people for three weeks at 0.5?  I can think of a lot of ways to calculate an answer, but none of them that come up with 136 hours.  (This is a serious question, there must be something I'm missing.) -- <a href="http://c2.com/cgi/wiki?RandyKramer">RandyKramer</a></em>
<p>
Another thing: we use a variant of the <a href="PlanningGame.html">PlanningGame</a> with great success.  One thing that led us to it is that for us, <em>Business</em> is actually lots of independent Players with conflicting priorities.  We always use <a href="http://c2.com/cgi/wiki?DateDriveCommitment">DateDriveCommitment</a>, allocate each player some ideal time, and then invite them to negotiate with each other.  Getting out of this crossfire is valuable to us poor developers.
<p>
We also allocate the developers around 10% of the ideal time. I've seen elsewhere that the C3 team have dedicated whole cycles to developer-selected work: for us it works to do it in background.  -- <a href="http://c2.com/cgi/wiki?DaveCleal">DaveCleal</a>
<hr>
Each story should take no more than 3 weeks of ideal time to implement or else it is too complex to plan and build and should be split into two or more simple stories. How do we do this when the story is already on the most simple level that 'Business' wants to understand? For example the system I'm working on has a whole lot of database and interprocess communication that is pretty much a requirement of the first piece of actual functionallity. It would take more than three weeks to build that, but a user story needs to do describe a piece of useful functionality, not building the infrastructure doesn't it?
<p>
-- It may be that the infrastructure counts as ToolsAndLibraries<a href="http://c2.com/cgi/wiki?edit=ToolsAndLibraries">?</a>. Thus, you, the programmers, are the clients of that SubProject<a href="http://c2.com/cgi/wiki?edit=SubProject">?</a>. That you may also be the providers is an interesting excercise in reflection and introspection.
Thus, maybe you could run the highly technical up-front work as a separate SubProject<a href="http://c2.com/cgi/wiki?edit=SubProject">?</a> that you specify as (technical) users. Unfortunately, the scheduling and implementation of something like ToolsAndLibraries<a href="http://c2.com/cgi/wiki?edit=ToolsAndLibraries">?</a> isn't as amenable to <a href="ExtremeProgramming.html">ExtremeProgramming</a> as a vanilla business system.
<p>
<hr>
&quot;Ideal time&quot;, as I've interpreted it is a measure of &quot;work&quot;: how much work is the implementation of a story.  But is this interpretation correct, or is &quot;ideal time&quot; something else instead? --LarryWinkler<a href="http://c2.com/cgi/wiki?edit=LarryWinkler">?</a>
<p>
See: <a href="http://c2.com/cgi/wiki?GamesVsPatterns">GamesVsPatterns</a>, <a href="http://c2.com/cgi/wiki?ExtremeTimeSpans">ExtremeTimeSpans</a>
<p>
<hr>
<p>
In a side-comment on one of the sessions at Xp2000, Kent suggested that there's a <a href="http://c2.com/cgi/wiki?PlanningGameNameChange">PlanningGameNameChange</a> in the offing.
<p>
<hr>
<p>
A <a href="PlanningGame.html">PlanningGame</a> flow chart:
<p>
<img src="http://www.karneim.com/XP/PlanningGame/PlanningGameFlowChart.gif">
<p>
<hr>
<p>
How do you do the <a href="PlanningGame.html">PlanningGame</a> when your people have very different skill sets?  For example, we have some coders who know only HTML/ASP, and some who know only C++.  We're trying hard to stick to the <a href="PlanningGame.html">PlanningGame</a>, but we often find ourselves with a commitment that doesn't have enough stories that require HTML/ASP work, or one that doesn't require enough C++ work.  I know <a href="PairProgramming.html">PairProgramming</a> is supposed to fix this, but do you really expect an HTML/ASP coder to learn C++ by pairing?  I've thought about dividing it into two completely different commitment schedules, but the trouble is that almost all of our stories require both HTML/ASP and C++ work.  --<a href="http://c2.com/cgi/wiki?RayPingree">RayPingree</a>
<p>
<em>Are you saying that at some point either the HTML/ASP or C++ people will have nothing to do?  If they are required to work together, it seems to make sense that they plan together.  Someone signs up for a particular story and is responsible for hunting down a HTML/ASP or C++ coder(s) as necessary to fulfill the tasks.  I'm not sure if there's anything more to this. --<a href="http://c2.com/cgi/wiki?JasonYip">JasonYip</a></em>
<p>
The real problem with people not having enough to do is justifying this process to upper management.  Of course they want everyone to have something to do.  Anyone writing paychecks would.  Maybe the real problem is that we haven't yet planned more than one commitment at a time.  If we knew what was going to be in the next commitment already, people could go ahead and start on that.  But then that throws off the <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> calculations at the end of that next iteration, because people would have been working on things before the beginning of that iteration...  Don't you see how it's all unraveling? --<a href="http://c2.com/cgi/wiki?RayPingree">RayPingree</a>
<p>
Let me try to answer my own question... I don't see a way to involve resource usage in the <a href="PlanningGame.html">PlanningGame</a> unless you do it at the estimating level.  So we estimate the ideal days of C++ time and the ideal days of HTML/ASP time for each story separately.  We can't commit to a story until it has both kinds of estimates.  Either estimate can be zero to indicate that it doesn't require that type of work.  Then in planning we have a certain number of HTML/ASP ideal days in each iteration and a certain number of C++ ideal days, because we have a certain number of C++ coders and a certain number of HTML/ASP coders, and we have separate load factors for the two groups.  It's still <em>possible</em> to get a commitment where people have nothing to do, but at least you can see it happening as you build your commitment.  --<a href="http://c2.com/cgi/wiki?RayPingree">RayPingree</a>
<p>
<em>The main thing to learn here is something about choosing an architecture that requires specialized programmers: it leads to inefficiency. Given that for some reason you <strong></em>like</strong><em> inefficiency, probably the best thing is to estimate against several dimensions of resource, as you suggest, so that cards show &quot;3 C++&quot; and/or &quot;3 HTML&quot;, and compute velocity independently as well. Then presumably the customer can bring in the right amount of each. But doctor, it hurts when I do this ... --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
A.) This is a serious barrier to adopting XP, because if it's going to happen at a company it'll happen on the first XP project they undertake, and it makes management distrust the process.
B.) It's very unlikely that someone learning about XP by reading would forsee this problem.  It's like how sand dunes line up either against or along with the average wind direction, depending how variable the wind is.  It's a consistent rule about how the system behaves that you can't learn by studying the parts.  
C.) Knowing about the problem may allow you to work around it, as long as you know before your achitectural spike.  
--<a href="http://c2.com/cgi/wiki?RayPingree">RayPingree</a>
<p>
There are two things that I'm not seeing addressed in any of these discussions (though I'm sure many have had to deal with it). 
<p>
The first is the issue of data modelling. I can see this as perhaps a standard, built-in &quot;user story&quot; that all database applications must include. Going with the XP principle that it doesn't need to be complete (it gets fleshed out anyway throughout the various releases and iterations), but so much can be learned about the business system being modelled from doing a more-or-less complete data model, that I'm wondering how to incorporate this into the planning game. As a database application programmer, I also see the data model (and the physical database) as the foundation upon which the rest of the system rests.
<p>
While engaging in an e-mail discussion of this issue with AnthonyScilipoti<a href="http://c2.com/cgi/wiki?edit=AnthonyScilipoti">?</a>, I realized that the data model/database can be thought of as an object with the absolute worst, most tightly coupled API that you could imagine - one that none of us would ever intentionally create. This makes the entire system subject to instabilities introduced by even modest changes to the database schema.
<p>
The second issue is the project that is re-writing an existing system, or systems. The incremental deployment (and incremental abandonment of the old system) that seems to be an integral part of XP can be difficult when existing data needs to be converted from the old system and integrated with existing data in the new system. <a href="http://c2.com/cgi/wiki?SteveSawyer">SteveSawyer</a>
<p>
<hr>
<a href="http://c2.com/cgi/wiki?TopicGlossaryXp">TopicGlossaryXp</a>
<hr>
<a href="http://c2.com/cgi/wiki?edit=PlanningGame">EditText</a> of this page (last edited December 20, 2000)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=PlanningGame">FindPage</a> by browsing or searching<p>
<font color=gray size=-1>This page mirrored in <a href="index.html">ExtremeProgrammingRoadmap</a> as of March 31, 2001</font>
</body>