hundredpersonproject.html

来自「极限编程 Extream Programing」· HTML 代码 · 共 160 行 · 第 1/2 页

leaves a small project then the damage is even greater, but you can work
harder to make sure that nobody leaves and you have a good chance of
keeping them all.
<p>
Large groups produce more code than small groups.  The small project
produced half as much code as the large project, but it seemed to me
that their system did at least as much, if not more.  The small project
had a more sophisticated design at its core, and built simple designs
for things that were not at its core.  The larger project had a less
sophisticated design for the core business objects and had a more sophisticated
design for technology objects that did things like persistence and workflow.
I think this was because the designers on the big project had a harder time
figuring out what the core problem was, so they would carve out pieces that
they understood and work hard on them.  Even though the small project was
not really following <a href="ExtremeProgramming.html">ExtremeProgramming</a>, in this case it was following
<a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>.
<p>
It is an exaggeration to say that a <a href="HundredPersonProject.html">HundredPersonProject</a> is a ten person
project with lots of overhead, but sometimes it is true.
<p>
-<a href="http://c2.com/cgi/wiki?RalphJohnson">RalphJohnson</a>
<hr>
Brooks in The <a href="http://c2.com/cgi/wiki?MythicalManMonth">MythicalManMonth</a> talks about overhead in large projects. He also points out that good programmers can be 10 times as productive as average ones. (I've known programmers whose productivity was negative.)
-- <a href="http://c2.com/cgi/wiki?DaveHarris">DaveHarris</a>
<hr>
Seems to me that &quot;Client presence&quot; is important enough to be &quot;<a href="http://c2.com/cgi/wiki?ClientPresence">ClientPresence</a>&quot; and warrants some explanation of its own.
<p>
I got into a bit of a disagreement this morning with another developer about XP and the minimal requirements documents it advocates, and I don't think I really convinced him.  If anyone could provide some more background on why <a href="http://c2.com/cgi/wiki?ClientPresence">ClientPresence</a> is superior to a BloatedRequirementsProcess<a href="http://c2.com/cgi/wiki?edit=BloatedRequirementsProcess">?</a> I, and probably others, would find that very helpful.
-- <a href="http://c2.com/cgi/wiki?DavidRosenstrauch">DavidRosenstrauch</a>
<p>
Actually, after further reading, it looks like <a href="ExtremeProgrammingMayScaleUp.html">ExtremeProgrammingMayScaleUp</a> provides some ammunition against a BloatedRequirementsProcess<a href="http://c2.com/cgi/wiki?edit=BloatedRequirementsProcess">?</a>.
-- <a href="http://c2.com/cgi/wiki?DavidRosenstrauch">DavidRosenstrauch</a>
<hr>
OK, lets work the numbers.  <a href="http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation">ChryslerComprehensiveCompensation</a> was using traditional methodogies, 18 months invested we were 1/2 functionality complete.  <a href="KentBeck.html">KentBeck</a> and <a href="RonJeffries.html">RonJeffries</a> came in and we started over using <a href="ExtremeProgramming.html">ExtremeProgramming</a> methodology.  It took 9 months to get to functionality complete.  But wait, we used half as many people including overhead (non-combatants).  But wait again, the rewrite used some information collected during the original go.  I would say about 1/3 of the total effort was saved. But wait yet a third time.  That 9 months also included training of all the people in a new methodology, which was also changing as we went along too.  I would estimate we back out 1 month.  Now lets do the math.
<p>
((18months x 2 functionality) x 2 head count) / (9 months + 3 scavenging - 1 training) = 6.5
<p>
Each person on the project (including overhead people) resulted in about a 6.5x performance gain.  This number is not inconsistent with <a href="http://c2.com/cgi/wiki?TomKubit">TomKubit</a>'s experiment on the <a href="http://c2.com/cgi/wiki?VcapsProject">VcapsProject</a>.  The same functionality was added to two systems.  One Built extreme, one built traditional.  Tom showed a 10x improvement, but that did not include overhead.
<p>
So now take your 100 person project and divide by 6.5.  We can do it with about 15 people and that includes overhead.--<a href="DonWells.html">DonWells</a>
<p>
I think that Extreme Programming is a confession that &quot;traditional&quot; design methodologies don't work, yet XP doesn't solve the problem either.  If you had a real workable technology for designing a software system, it would result in a flexible, reuseable and extendible program. If you get lost using a map, you make a better map, you don't start out in whatever direction looked the simplest.	--GregFoxx<a href="http://c2.com/cgi/wiki?edit=GregFoxx">?</a>
<p>
<em>And how do you make a map?  Travel the terrain and record what you encounter!</em>
<p>
''No, you take pictures from a satellite.&quot;
<p>
In what way does XP not solve &quot;the problem&quot;? I presume the map thing is an analogy suggesting that you can't write quality software by <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>. That suggests that you haven't tried it it yet. Those of us who propound it have tried it. And we're serious guys. Or we're hallucinating. Get an XP person to hang with and try simplcity. We think you'll like it.  --<a href="RonJeffries.html">RonJeffries</a>.
<p>
P.S. When lost in the woods, walk downhill. It tends to lead to a river. When you reach a river, walk downstream. It tends to lead to a town. Hmmmm ...
<p>
The &quot;better map&quot; suggestion makes perfect sense if you know what is going to happen. In the case of uncertainty about the future, you are better off going in a promising direction that you can easily change. The greater the uncertainty, the greater the value of fancy footwork and the greater the risk of relying on maps. --<a href="KentBeck.html">KentBeck</a>
<p>
<hr>
<p>
There seems to be a hidden assumption on this page - that a <a href="HundredPersonProject.html">HundredPersonProject</a> is going to have <a href="http://c2.com/cgi/wiki?WorseManagement">WorseManagement</a> than a ten-person project.
<p>
<hr>
From above: <em>No, the way to deal with a 100 person project is to fire the bottom 90% of the staff. </em> Good point! Programming productivity shows the 80/20 (or 90/10 if you prefer) rule in action. The other thing to note is that there always is the productive 10% -- even when the stars are gone, someone else rises to the challenge. When the JCL can't just be duped anymore, someone will learn JCL!
<p>
<em>only one problem - the people who decide who gets fired are usually a significant fraction of those that need to be fired (i.e. the overhead and management)</em>
<p>
<hr>
Another way of thinking about why projects are better broken down...Small-World network theory. In this theory, the distance across graphs stays small as we scale up when we have mostly nodes in small clusters and a few random non-local links. Think of teams as clusters, and the links as communication channels, and you can see that breaking down the 100-PP into 10x10-PP might actually be a sensible and even optimal approach.
<p>
For more links on small world theory see <a href="http://www.santafe.edu/sfi/organization/annualReport/econSocial.html">http://www.santafe.edu/sfi/organization/annualReport/econSocial.html</a>
<p>
I'm just waving my hands here. But it may be a justification for the
10-person approach. In my own company we have CentresOfExcellence<a href="http://c2.com/cgi/wiki?edit=CentresOfExcellence">?</a> for
various technology areas. This sounds good on paper but in practice it
means we have formed IslandsOfExcellence<a href="http://c2.com/cgi/wiki?edit=IslandsOfExcellence">?</a> all over the country with little
communication going on. With this setup it is virtually impossible to
form a 10-PP to complete a large project - you cannot gather the diverse
skills required in a single physical location. Drives me nuts. -- <a href="http://c2.com/cgi/wiki?BrianEwins">BrianEwins</a>
<hr>
<a href="http://c2.com/cgi/wiki?edit=HundredPersonProject">EditText</a> of this page (last edited February 6, 2001)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=HundredPersonProject">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>