📄 largeextremeprogramming.html
字号:
<head><title>Large Extreme Programming</title></head><body><h1><img src="logo.gif"> Large Extreme Programming</h1>See also <a href="ExtremeProgrammingMayScaleUp.html">ExtremeProgrammingMayScaleUp</a>, <a href="http://c2.com/cgi/wiki?ScalingExtremeProgramming">ScalingExtremeProgramming</a>.
<p><a href="ExtremeProgramming.html">ExtremeProgramming</a> is a methodology which tries to do only those things which really help get the product written. (The product, in many cases, is just the program. Often it's a program with a manual, with some documents, etc.)
<p>We focus on minimizing the process because this maximizes the resources you can apply to the things the customer really wants.
<p>As a "philosophy", I'd hope that few people would have difficulty with the idea that you should do only the necessary process to ensure that you deliver what is needed, on time, at the right quality level, within budget. It's not easy to agree on just what can be safely left out.
<p>People who actually do XP monitor how the project is going, using a few key measures: progress on functional tests (scope growth and quality); resources; stories completed (scope and time). We measure the rate at which we produce functionality, and when the ratios change we examine what is going wrong and fix it. (This usually amounts to getting back on track with doing the process as we know how to do it. Sometimes it involves coming up with a little bit of new process.)
<p>Since the XP meta-process is introspective and self-adjusting, we believe that we could morally undertake a project of any size while applying the philosophy. We wouldn't run the project into the ground blindly, because just like you, we don't do anything blindly, we try to keep our eyes open just like you do.
<p>We believe that the "philosophy" of minimal methodology with self-measurement can be effectively applied to all sizes of projects. Someday we'll have more experience with different sizes - and we'll have more to say about it.
<p>On this page, and related ones, we speculate about how XP might apply in the large. We freely state that we are speculating. --<a href="RonJeffries.html">RonJeffries</a>
<p><hr>
<p>I am all for minimal methodology and Listening, Coding, Testing, Refactoring, but I just can't see how <a href="ExtremeProgramming.html">ExtremeProgramming</a> scales up to larger projects, in other words, the systems that are so large and complex that you can't simply throw them away and start from scratch when business conditions change. Systems that have to involve hundreds of software professionals to get them finished in any reasonable timeframe, where many of the software professionals are not very talented because of the short supply and huge demand these days.
<a href="ExtremeProgramming.html">ExtremeProgramming</a> and minimal methodology do not meet the enormous communication and coordination requirements to keep 100+ people driving down the same road. And they certainly don't provide the concepts of good documentation and training that are vital to maintaining and properly using a large, distributed software product. Of course, neither do the mainstream methodologies of the day, which introduce road blocks and arbitrary productivity killers in the sake of implementing a "best practice" or 10. So, how do we scale the real best practices to large projects? Or maybe we just don't do large projects? -- <a href="http://c2.com/cgi/wiki?ToddLauinger">ToddLauinger</a>
<p><hr>
<p>Inside every <a href="HundredPersonProject.html">HundredPersonProject</a>, is a 10 person project struggling to get out.
<a href="RonJeffries.html">RonJeffries</a> and I just did a back of the envelope calculation of the <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a> of a 60+ person project we are familiar with. I worked out to about 1000. Lets say our calculation was an order of magnitude off, they still have a 6 person project with 54 people in their way. --<a href="http://c2.com/cgi/wiki?ChetHendrickson">ChetHendrickson</a>
<p><hr>
<p><a href="http://c2.com/cgi/wiki?WardCunningham">WardCunningham</a> once speculated with me about having four or five <a href="ExtremeProgramming.html">ExtremeProgramming</a> teams working together on "the same" project. I would have to be able to apply <a href="http://c2.com/cgi/wiki?DivideAndConquer">DivideAndConquer</a> in some reasonable way. I would start small and let the division take place as it wants to, both the functionality of the system and the team. I think with a group like this you could tackle about any project I know about, which doesn't include phone switches. -- <a href="KentBeck.html">KentBeck</a>
<p>It's the edges, always the edges. Could we do <a href="PairProgramming.html">PairProgramming</a> across the edges, an engineer from the (e.g.) GUI team and one from the model team, etc? Perhaps we'd have code ownership by team, instead of none at all? Could we still do <a href="ContinuousIntegration.html">ContinuousIntegration</a>? How much paperwork could we still not do? Above all, could it still be fun? -- <a href="RonJeffries.html">RonJeffries</a> (Can't remove this w/o loss of continuity, sorry.)
<p>Gui and model teams would be a recipe for disaster. Each team would have to be responsible to a different set of clients and work against a common set of interfaces, file formats, shared database, or socket protocol. Each interface definition has strengths and weaknesses for this kind of <a href="http://c2.com/cgi/wiki?DivideAndConquer">DivideAndConquer</a>.
<p>One way of combatting this might be IntegrationTeams<a href="http://c2.com/cgi/wiki?edit=IntegrationTeams">?</a>, which would form the internal nodes of a scaled XP project, with regular XP teams forming the leaf nodes. One integration team could play customer to 3-5 XP teams, say. And integration teams might play customers to other integration teams in a tree hierarchy. The practices might be different than a traditional XP team. For example, testing would play a very large part of the integration team's responsibilities. They would generate <a href="http://c2.com/cgi/wiki?AcceptanceTests">AcceptanceTests</a> for their sub-teams and <a href="UnitTests.html">UnitTests</a> (of sorts) for their own integration efforts. I've never worked on a project bigger than 4 programmers, so all of this is naive speculation, but perhaps others could elaborate with their own ideas? -- <a href="http://c2.com/cgi/wiki?RobHarwood">RobHarwood</a>
<p>If you had a problem that really couldn't be tackled with less resources, and the client was willing to pay 50 or 100 times as much for 5 teams as they did for one, yeah, sure, it could be fun. There would be more constraints, which would be less fun, but there could be more impact, which would be more fun. -- <a href="KentBeck.html">KentBeck</a>
<p>An often overlooked but still key part of XP is the revised relationship with management. By the time you have teams of XP teams you will also have invented <a href="ExtremeManagement.html">ExtremeManagement</a> (XM) which will have its own versions of familiar extreme principles. I set out once to construct exactly this (<a href="http://c2.com/cgi/wiki?WardAtIbm">WardAtIbm</a>) but found personality types and reward structures at both company and clients, well, unfavorable. Still, XM will happen in time. It will happen first among a small group of managers who are delivery oriented, have the confidence and knowhow to work from first principles, and find themselves working with teams that are already practicing XP. And it will be glorious. -- <a href="http://c2.com/cgi/wiki?WardCunningham">WardCunningham</a>
<p><hr>
<p><a href="ExtremeProgramming.html">ExtremeProgramming</a> advocates refactoring. Part of refactoring is that if a method gets too long, you break it apart. Ideally each part implements some discrete functionality.
<p>How does refactoring map to organization for large projects?
<p>I have a large (over say 30 people) team working on a very large project. I refactor the project into 6 smaller projects and assign 5 people to each. It seems to match the pattern.
<p>There is some aspect of inertia in organizations that seems to cause problems, though. The interfaces between the 6 smaller projects become static or at least less changeable. This seems to break <a href="ExtremeProgramming.html">ExtremeProgramming</a>.
<p>How do you provide organizational volatility that matches the software volatility? Or is it even necessary? --<a href="http://c2.com/cgi/wiki?WayneCarson">WayneCarson</a>
<p><em>If people can pair across teams, then you could "refactor people from one team to another" with ease. It would also dramatically increase the bandwidth inter-team interfaces, and make changes to inter-team interfaces easier. These would be good things. -- <a href="http://c2.com/cgi/wiki?JeffGrigg">JeffGrigg</a></em>
<p><hr>
<p>I am on record as separating the issue of "large teams" from "large problems". Large problems can sometimes be handled by small teams. XP addresses this matter - make everyone much more productive, and your small team can solve a larger problem than you thought possible.
<p>XP doesn't address large teams - those are necessarily communication-burdened.
<p>XP answers two questions:
<UL><li> How can I get 6-10 people to work as fluidly as 2?
<li> How can I get 6-10 people to deliver what I'd have thought would take 25?
<p></UL>--<a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<p><hr>
<p>Could the software for the space shuttle have been developed with XP? It has over 25 million lines of code and cost about 1.2 billion dollars to develop.
<p>The XP folks have said over and over again that XP is not a universally applicable methodology. Systems with draconian safety constraints are almost invariably the first category mentioned as NOT being XP candidates. That being said, there's no reason why some XP practices couldn't help improve the productivity for ANY software project. <a href="UnitTests.html">UnitTests</a>, <a href="FunctionalTests.html">FunctionalTests</a>, <a href="PairProgramming.html">PairProgramming</a>, <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> and <a href="RefactorMercilessly.html">RefactorMercilessly</a> should be almost universally applicable. -- <a href="http://c2.com/cgi/wiki?DonaldMcLean">DonaldMcLean</a>
<p>Maybe you could do XP in large by dividing the system into layers of subsystems and assigning separate XP teams to each subsystem and each layer so that the XP teams of the higher layers are "customers" of the subsystems that the layer needs. Thus the XP team for each layer is responsible for applying XP principles at that level and so the whole system will be developed using XP... What do you think about that?
<p><hr>
<p>As seen on the <a href="XpMailingList.html">XpMailingList</a>:
<p>What's the risk of having (too) fine-grained teams from the start?
<p><UL><li> Too slow evolution of interfaces
<li> Too large change of hidden duplication
<li> Too little team feeling
<li> Too little unity of vision
<li> Too much dispersion of customer attention
<p></UL>--<a href="KentBeck.html">KentBeck</a>
<p>In a small battle, with swords and spears and shields, the rule for a
soldier in a squad is you keep peripheral eye contact with other squad
members. Don't let the enemy draw you away from them with a feint, or
let them best your comrades when you don't notice and isolate you.
<p>In a large battle, each squad follows the same rules regarding the
squads to its left and right. They all form a unified front.
<p>--<a href="http://c2.com/cgi/wiki?PhlIp">PhlIp</a>
<p><hr>
<p>On a large project developing a new product for eventual sale through a channel, <a href="http://c2.com/cgi/wiki?WhoIsTheCustomer">WhoIsTheCustomer</a>?
<p><hr>
<p><em>Inside every <a href="HundredPersonProject.html">HundredPersonProject</a>, is a 10 person project struggling to get out.</em>
<p>I think this may summarize one of the key areas of disagreement. XP seems to take the approach that a software project is infinitely divisible. A large project can be divided down to be handled by a single team. This reduced project can then be further subdivided to have useful deliveries in 3 week increments.
<p>I am not sure how to bridge this gap. It appears you either accept the infinitely divisible concept or not.
<p><a href="http://c2.com/cgi/wiki?WayneMack">WayneMack</a>
<hr>
It seems to me that the problem of <a href="http://c2.com/cgi/wiki?ScalingExtremeProgramming">ScalingExtremeProgramming</a> is the same as the problem of scaling any methodology. The unit of work is a person and the problem of scaling is a communications problem not unlike the advocacy of high cohesion and weak coupling as a mandate for good programming, it is also a mandate for good partitioning of any large project. The key to scaling is finding a way to <a href="http://c2.com/cgi/wiki?DivideAndConquer">DivideAndConquer</a> such that communications requirements are minimized. Then in each of the resulting weakly coupled cells one can run that cell on XP. So XP will not scale by itself, it has to be combined with some kind of appropriate partitioning methodology that finds the right clumps of cohesion and defines interfaces which are weakly coupled in the right fashion.
<p>That is a whole lot easier to say than to do. Many integration failures are due to the fact that people thought they understood but really didn't so when it comes time for integration things don't work. This can happen at any scale, but at small scale it's only a small annoyance while at larger scale it kills the program. Hence the evolutionary emphasis of some.
<p>I am fond of saying that we need the software equivalent of a wire. This is not because a wire is a particularly good interface, but because it imposes acknowledged and universally understood constraints. UNIX streams, pipes etc. provided a little bit of that flavor and are a large part of the utility of UNIX. A set of simple, standardized, easily understood "wires" would do a lot for providing inherent scalability. Software is entirely too free and unconstrained to make that achievement easy or likely. --<a href="http://c2.com/cgi/wiki?RaySchneider">RaySchneider</a>
<p><hr>
<a href="CategoryExtremeProgramming.html">CategoryExtremeProgramming</a><hr><a href="http://c2.com/cgi/wiki?edit=LargeExtremeProgramming">EditText</a> of this page (last edited January 26, 2001)<br><a href="http://c2.com/cgi/wiki?FindPage&value=LargeExtremeProgramming">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>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -