minimalmethodologies.html

极限编程 Extream Programing

<p>
-- <a href="http://c2.com/cgi/wiki?KielHodges">KielHodges</a>
<hr>
The only loss-of-life project I ever worked on had as its purpose the loss of life.  I guess that's not in the spirit of Alistair's comments, much less in the spirit of essential humanity.
<p>
As for loss of essential moneys (or is it monies), been there, done that.  The Oak Tree / Cold River Veritax product hit the wall when the entrepreneur decided he had spent enough.  Several of the <a href="ExtremeProgramming.html">ExtremeProgramming</a> principles would have helped a lot:
<UL>
<li> <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> would have kept our focus on essential functionality, leading us to a complete, if smaller, product.
<li> <a href="YouArentGonnaNeedIt.html">YouArentGonnaNeedIt</a> would have had us refuse to implement features, like networked distribution of updates, that would only become important if the rest of the product became successful.
<li> Stronger <a href="UnitTests.html">UnitTests</a> and <a href="FunctionalTests.html">FunctionalTests</a> would have let us move faster, get more done, have a better shot at commercial success.
<li> More <a href="PairProgramming.html">PairProgramming</a> sooner would have sped us up and increased reliability.
<li> <a href="SpartanUserInterface.html">SpartanUserInterface</a> would have left us a lot more precious time to work on the real problem, computing people's taxes quickly and correctly.
</UL>
As I look back on my history of mistakes, and I have made most of them, loss of essential moneys is usually a result of delivering too little too late.  (Technical failure is another possibility, but in my experience it is much more rare.)  Lighter-weight methodology with the concomitant focus on the real point of the project (delivery) would very often have shifted those projects closer to success.
<p>
At the same time, I'm not sure that the big problems were in the development process at all.  Were the real roots of failure perhaps 
<UL>
<li> in communication up and down the chain of command, or 
<li> in the willingness to accept a death march mentality, or 
<li> in the desire to be seen as a team player and thus signing up for an impossible deadline?
</UL>
I think perhaps they were.  The software process could have helped, but the real roots probably lay elsewhere.  --<a href="RonJeffries.html">RonJeffries</a>
<hr>
see also <a href="http://c2.com/cgi/wiki?DeveloperOnlyXp">DeveloperOnlyXp</a>
<hr>
The other comment that I wanted to make is that Scaling IMHO is a pseudo-issue.  The problem with scaling is almost always due to bad partitioning.  The loss of productivity in large projects is due to an ever increasing communications overload and this is at least partly due to two factors: 1) complexity and 2) bad partitioning.  Complexity is unavoidable ... it WILL cause you to expend more time more inefficiently.  Bad partitioning, which is usually, but not always, partitioning along lines with high coupling instead of low or weak coupling increase bug-incidence and and communications overhead both oral, managerial (meetings and what not) and written -- especially construction and inspection and approval of interface documents.   --Ray Schneider
<hr>
This is my first attempt to 'speak' rather than lurk.
My Boss has said that we will grow our way through the Capability Maturity
Model. It strikes me that the whole essence of of Extreme Programming 
(and what I am reading in Surviving OO Projects) is a solid sense of community with full communication amongst the members. With regard to the communication
burden, is dicing the project into subTeams who at least once a week show
their stuff to all Project Members ( aka ?codeReview? ) useful??? Our
problem has been Lip Service...  -- Scott Jackson
<p>
<em>In brief, it'd be better than nothing.  Unless the project is way too large, closer is better.  The C3 team of 12 or 14 people are all in one room.  The customers are over one divider in the next space.  Believe it or not (I didn't) it works wonderfully.  </em>
<p>
<em>Generally speaking CMM and XP are horses of two different planets.  CMM is a very heavy-duty methodology, and XP is the lightest one we could imagine.  We can teach a team XP in a week and get them reasonably good at it in a couple of months at most.  It takes years to make it through the levels of the CMM, and very few organizations ever make it to the top.  --<a href="RonJeffries.html">RonJeffries</a></em>
<hr>
I beg to differ. The CMM is NOT a methodology. It simply describes the practices which need to be present in order for an organization to possess a certain level of capabilities. That said, XP could probably be shown to be compliant with some level of the CMM (perhaps even Level 3) since it implements many of the CMM Key Process Areas (KPAs), albeit in very integrated and mutually-dependent ways.  --<a href="http://c2.com/cgi/wiki?KenBoyer">KenBoyer</a>
<hr>
The <a href="http://c2.com/cgi/wiki?ScrumMethodology">ScrumMethodology</a> seems to fit into this category of <a href="MinimalMethodologies.html">MinimalMethodologies</a>
as well.  Its externally maintained feature list and other process rules
seem to make it 
more formal than <a href="ExtremeProgramming.html">ExtremeProgramming</a>. But it appears it ought to work better
when the users are not &quot;just over the wall.&quot;  --<a href="http://c2.com/cgi/wiki?MarkSwanson">MarkSwanson</a>
<hr>
More and more of <a href="http://c2.com/cgi/wiki?ScrumMethodology">ScrumMethodology</a> users are including XP as a practice methodology. Scrum addresses product management, the workings of development teams, and the interactions of the two.  XP addresses what the development teams do. --KenSchwaber<a href="http://c2.com/cgi/wiki?edit=KenSchwaber">?</a>
<hr>
I have a few questions:
<p>
<OL>
<li> Why is complexity associated with more time and money spent? In fact, what is complexity? IMHO, there is no such thing as a complex system, just a system badly partitioned into subsystems. So the only reason for costs and time growing with project size are project management mistakes determined by the stress generated by higher responsibility (and the lower qualification of the people managing large projects). In a normal world, costs and time whould grow linearly with project size.
<li> OK, XP, but how about the persistency of an organization using XP in an extreme way? What if half of the crew decides to quit, and an entire small to average project remains completely un-covered by people knowing the source code? Maybe I didn't get it right, but what I read above should elliminate documentation completely, at least for small to medium projects.
<li> Doesn't a team of ten programmers seem too big to you other people reading this page? Over time, I found out that the size offeering the highest efficiency is aboout five. Has anybody else had similar epxeriences?
<p>
</OL>
--Anonymous
<hr>
<a href="http://c2.com/cgi/wiki?edit=MinimalMethodologies">EditText</a> of this page (last edited March 22, 2001)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=MinimalMethodologies">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>