whenxpisunpopular.html

极限编程 Extream Programing

I find my mental "required evidence" threshold going up a notch.
<p>
More hard facts, please. In particular: large projects, projects with large legacies, projects using statically typed languages, any combination of these.
<p>
<em>There aren't a large number of XP projects to offer hard data from. Those who need to wait for more data must wait. To aid in understanding and predicting what might happen, we can talk about some of the boundaries, which probably aren't where any of us expect them to be.</em>
<p>
<em>What's a large project? XP hasn't been used on projects with large numbers of people. Since it relies on intensive communication, we might expect to modify some of the practices. C3 has over 2,000 classes, 30,000 methods. The project has been ongoing for 30+ months, in production for about 20. Is C3 large?</em>
<p>
<em>What's large legacy? C3 is a greenfield system in that all the code we support, we wrote. If a project were extending existing code, full of cruft and poorly tested, that team would have to do something to get it up to the standards XP requires. C3 connects to a very large number of legacy input files and database, and exports to a large number of output files and databases. It handles ASCII files, EBCDIC files, relational gateway, a connection to a commercial tax package written in COBOL, and a connection to a KBMS knowledge-based wage attachment system. Is that a large legacy?</em>
<p>
<em>I've used, among others, C and C++ extensively. It is my considered </em>
<strong>opinion </strong>
<em>that XP principles, and most of the practices apply just fine to those languages. Slower development cycles, the inability to test everything shortly after implementing - things like these are problematical, IMO.</em>
<p>
<em>Hard facts? Emphatically not. Worth discussing? Up to y'all. Start new pages with interesting names and see what happens.  --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
--<a href="http://c2.com/cgi/wiki?KeithBraithwaite">KeithBraithwaite</a>
<p>
<em>Point to such if/then statements please.  And see the article in the October DistributedComputingMagazine<a href="http://c2.com/cgi/wiki?edit=DistributedComputingMagazine">?</a>.  Thanks!  --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
The points above were culled from a quick scan over the pages returned by searching on <a href="ExtremeProgramming.html">ExtremeProgramming</a>. I don't have time to do a more thorough search, and don't want to either, since the aim is not to pan XP or it proponents, just to try to elicit some more solid evidence. 
<p>
I'm happy for you that your green-field, smalltalk IS project was fun and successful. But, if I wanted to start lobbying my management to let me try these techniques (and I might), I'm going to need more.
<p>
I'll have to hunt down DistributedComputingMagazine<a href="http://c2.com/cgi/wiki?edit=DistributedComputingMagazine">?</a>.
<p>
--<a href="http://c2.com/cgi/wiki?KeithBraithwaite">KeithBraithwaite</a>
<p>
<em>Thanks for the pointers. Most of them seem to be suggestions, possibilities, and beliefs, explicitly so labeled. It would be nice if there were hard data and hard answers. I was concerned that we might actually have asserted that something WAS true where we had insufficient reason.  On the other hand, all the crows I have ever seen were black.</em>
<p>
<em>As for trying things on projects, it's not like the techniques are so weird or risky that one would need piles of scientific evidence that they work. Perhaps getting permission (or forgiveness) to try them wouldn't have to be such a big deal?  --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
<hr>
<p>
I'd like to try <a href="ExtremeProgramming.html">ExtremeProgramming</a> on a project but the environment I work in isn't conducive to being extreme. 
<p>
We need to (try to) provide a formal charter of the work we are going to do before we start. This includes cost and schedule estimates, a very carefully managed specification of the requirements, and a statement of the criteria for the clients acceptance of the project. We work this way not because of any particular development practice dogma but because of the clients business practices. 
<p>
In this kind of environment it is hard to be Extreme. Maybe the reason <a href="http://c2.com/cgi/wiki?WhyXpIsUnpopular">WhyXpIsUnpopular</a> is because some developers are jealous that they can't work that way -- or am I wrong and is <a href="ExtremeProgramming.html">ExtremeProgramming</a> consistent with this environment?
<p>
-- <a href="http://c2.com/cgi/wiki?FabianLeGayBrereton">FabianLeGayBrereton</a>
<p>
<em>Fabian, you might like to think about what, for want of a better name, I'm calling the <a href="ExtremeUnifiedProcess.html">ExtremeUnifiedProcess</a>, an unholy wedding of XP, the <a href="RationalUnifiedProcess.html">RationalUnifiedProcess</a>, and the <a href="http://c2.com/cgi/wiki?MicrosoftSolutionsFramework">MicrosoftSolutionsFramework</a> that we're attempting at a division of GMAC-RFC called the <a href="http://c2.com/cgi/wiki?AssetResolutionDivision">AssetResolutionDivision</a> (ARD). I'll be putting up two docs describing XUP this evening.</em>
<p>
<em>In a nutshell, XUP is XP plus whatever parts of RUP you actually need to have the <a href="http://c2.com/cgi/wiki?SimplestBusinessThatCouldPossiblyWork">SimplestBusinessThatCouldPossiblyWork</a>. That means that XUP could be full-on ultra-heavy RUP if that's what you're forced to do by your <a href="http://c2.com/cgi/wiki?PowersThatBe">PowersThatBe</a>, but whatever you can get away with, you do, and you work explicitly to lead your business folk towards the XP end of the scale. MSF is kind of tacked-on at the moment, but since the <a href="http://c2.com/cgi/wiki?PowersThatBe">PowersThatBe</a> in my neck of the woods can't bring themselves to buy-in to anything that hasn't got an MS sticker on it, we figure it's better to have it in there than not.</em>
<p>
<em>Watch the skies.</em> --<a href="http://c2.com/cgi/wiki?PeterMerel">PeterMerel</a>
<hr>
<p>
I would suggest the following reasons for XP to be unpopular.
<p>
1. It offloads much of the traditional requirements analysis from the devleopment team to the customer.  In many situations, the <a href="OnsiteCustomer.html">OnsiteCustomer</a> is not possible; often a single representative of all customer types does not exist.  It is usually expected that requirements or <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a> will be determined by the development team during the analysis and design phase.  Finally, end customers are not technically savy enough to develop <a href="FunctionalTests.html">FunctionalTests</a>.
<p>
<em>If they aren't, how are they going to know it works?</em>
<p>
WM: The users begin using the system to do their job.  At that point they expect the new system to do nearly 100% of what they did with their previous manual procedures.
<p>
<p>
2. A lot of the terminology is not well defined.  It leaves a lot up to the worst fears or best hopes of the reader.  I don't feel I can adequately define what Refactoring entails nor the potential scope of <a href="UnitTests.html">UnitTests</a>.  I fear the amount of code to be developed for <a href="http://c2.com/cgi/wiki?UnitTest">UnitTest</a> may substantially out weigh the amount of application code to be developed.
<p>
<em>There's an entire book on Refactoring, that might be a place to start. </em>
<p>
<em>As for testing, it seems to be about equal in size to the real code. The way to learn how much to do is to do some amount. If too many defects creep out, do more. If it seems to be taking too long, do less.</em>
<p>
WM: This leads to part of my confusion.  Sometimes unit testing is defined as 100% testing and testing everything that could possible break (eqivilent statements?).  Other times it is presented as a subjective call, guess and add tests when and if needed.  Does this imply there is a trade off between level of effort and completeness of <a href="UnitTests.html">UnitTests</a>?
<p>
<p>
3. The benefits of XP to anyone outside the devleopment team are not well defined, nor (as mentioned else where) is there much objective data to rely on.  Many of us require more than <em>Try it, you'll like it.</em> as a justification.
<p>
<em>What objective data do you have on whatever you're doing now? And what part of predictable incremental delivery of code that is shown to meet requirements doesn't sound like a well-defined benefit?</em>
<p>
WM: (Predictable) I am still look for information which shows project tracking info.  What were the initial estimates and how did they change over time?  
<p>
WM: (Incremental Delivery) Incremental delivery is not always a benefit.  Our user sites are distributed across the country.  Deployment to a single site involves travel costs and time.  Deliveries with incomplete functionality also have little interest to our users.  They are trying to do their jobs and do not want to do double entry.
<p>
WM: (Meets Requirements) This gets back to my initial concern about requirements definition.  Basically, our client trusts us and expects us to tease out the requirements.  We need to deliver a system that simplifies our users' tasks.
<p>
<p>
4. The potential for personality conflicts seems overwhelming when using <a href="PairProgramming.html">PairProgramming</a> and <a href="http://c2.com/cgi/wiki?CollectiveCodeOwnership">CollectiveCodeOwnership</a>.
<p>
<em>&quot;Seems&quot;.</em>
<p>
WM: Perhaps I am the only one to have had projects involving people who don't always play well with others.  Sometimes I feel I spend more time developing tasking which keeps conflicting personalities apart than tasking to get the job done.  Any ideas not involving alcohol or head trauma about how to get people to work together?
<p>
<p>
This is not intended to be an indictment of XP, it is merely a plea for information.  I don't feel I have enough information to make an informed choice; I can only guess what XP <em>might</em> be.
<p>
<em>Have you read the books?</em>
<p>
WM: So far I have read the xpinstall.pdf download twice cover to cover.
<p>
<a href="http://c2.com/cgi/wiki?WayneMack">WayneMack</a>
<p>
<hr>
<p>
I've been following some of the XP discussions and I'm thinking &quot;what the hell kind of software are these guys writing&quot;. I'm working on vision systems for factory automation and I just can't see how we could start up an XP project here. I think XP arouses jealousy in people with a RealMenDontWriteBusinessSoftware<a href="http://c2.com/cgi/wiki?edit=RealMenDontWriteBusinessSoftware">?</a> attitude and instead of admitting it they try to put it down.
<p>
Andrew Queisser
<p>
<em>I've written real software as well as Business Software, and I'd use XP as it stands for things like compilers and database management systems. For factory automation, I'd start with XP but would expect to need something special to deal with concurrency. For vision, I don't know, never did it. I'd certainly expect <a href="PairProgramming.html">PairProgramming</a>, <a href="UnitTests.html">UnitTests</a>, <a href="http://c2.com/cgi/wiki?AcceptanceTests">AcceptanceTests</a>, and the <a href="PlanningGame.html">PlanningGame</a> to work just fine. What part of XP seems like it wouldn't work? --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
I agree that most the things you mention should work fine, <a href="UnitTests.html">UnitTests</a> maybe being the exception. This is mostly because meaningful tests are hard to set up, primarily because of concurrency, which you already mentioned. <a href="FunctionalTests.html">FunctionalTests</a> are even harder because the real functional test often can't
happen until the production line starts up. (This is when all the engineers stand close to the part they are responsible for while holding their breath and their hand over the E-Stop button.) But the biggest problem is in my opinion that there are simply not enough qualified software engineers in my field. That doesn't mean that they aren't talented or educated - they just happen to be mechanical, chemical, optical, you-name-it engineers. Programming is usually considered a necessary evil and I'm convinced that an XP project can really only be successful when the engineers are at least familiar with the basics of OOP.
<p>
I think XP's purist attitude (it's resistance to dilution) plus it's statement that high benefits are only achieved if it is adopted in its entirety, can make it too big a jump for (some) engineers and enginnering groups. If XP is an 'all or nothing' approach then that is going to make it unpopular. Gradual change is much easier than wholesale. If you are almost doing XP anyway then going the whole way isn't going to be a problem, but if you are nowhere near then you, like me, might wish to discuss <a href="http://c2.com/cgi/wiki?MigrationToXp">MigrationToXp</a>. <a href="http://c2.com/cgi/wiki?RichardDevelyn">RichardDevelyn</a>
<hr>
<a href="http://c2.com/cgi/wiki?edit=WhenXpIsUnpopular">EditText</a> of this page (last edited March 1, 2001)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=WhenXpIsUnpopular">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>