📄 extremeprogrammingboundaryconditions.html
字号:
<head><title>Extreme Programming Boundary Conditions</title></head><body><h1><img src="logo.gif"> Extreme Programming Boundary Conditions</h1>There are so many pages of discussion about <a href="ExtremeProgramming.html">ExtremeProgramming</a> that I would like to see a considered discussion of what its boundary conditions are. My hope is that on this page we can set out what we feel must be present for it to be applicable, or what, if present, would make it inapplicable. --<a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<p>So far, I hear/see
<UL><li> less than 15 people total, sitting in one room together
<li> using Smalltalk
<li> single target system (one project)
<p></UL><em>Also, perhaps</em>
<UL><li> in-house development (one customer)
<p></UL><hr>
<p>Request permission to brainstorm a moment. Removal of this section constitutes refusal of permission. --<a href="RonJeffries.html">RonJeffries</a>
<p>Against:
<UL><li> death-march management mentality
<li> strongly politicized / polarized customer-developer relationship
<li> prima-donna shop (or leadership)
<li> imposition of all or part of a BIG methodology (e.g. giant CASE tool, huge requirements docs, etc)
<li> staff unwilling / afraid to publish estimates
<p></UL>I would try to use the approach on a non-Smalltalk project. The cycle times for things like "<a href="ContinuousIntegration.html">ContinuousIntegration</a>" might have to change; more change control might be called for, etc. But the philosophy, I believe, would hold. Having been (put) through it, I feel that XP is what most top developers are trying to do anyway.
<hr>
<p>I am interested in doing something like (or adopting part of) Extreme Programming on a Java based enterprise-wide, distributed multi-tier (buzz word alert) project. But, (and I am sure I am missing a BIG POINT about XP here -- so many Wiki pages, so little time) I can only see it working within the confines of pure application programming in a <em>rich</em> development environment (Smalltalk w/ something like Gemstone?)
<p>I have three <em>groups</em> of developers: User Interface (usability, visualization), Biz logic (domain experts) and System (architectural support).
<p>I can't effectively argue why I have the UI group separate from the Biz group: it just felt right--the Biz group is full of people that understand how to code the complex business rules that define the client's finely tuned process and the UI group deals directly with usability issues that the Biz group aren't prepared to address. (Besides, the two groups constantly cross-pollinate and their division is a blur. <em>The User Interface IS the application, the biz logic IS just support code</em>.) I am not convinced that having Biz developers do <a href="SpartanUserInterface.html">SpartanUserInterface</a> development is the right way to go (but that is another discussion).
<p>I see XP fitting within the Biz logic group (this is where I see the XP focus on the Wiki pages), but how does it deal with the need for system support code? What about frameworks? Not the kind that slips into <a href="YouArentGonnaNeedIt.html">YouArentGonnaNeedIt</a>, but the support frameworks that you need so the Biz code has a nice, clean playground to tumble around in? Stuff like <a href="http://c2.com/cgi/wiki?EnterpriseJavaBeans">EnterpriseJavaBeans</a>, GemstoneJ, and <a href="http://c2.com/cgi/wiki?WebLogic">WebLogic</a> Tengha are helping, but they haven't created a seamless environment yet. How does XP address this need? Does XP assume that all of the system support libraries and frameworks are in place?
<p>-- <a href="http://c2.com/cgi/wiki?ToddCoram">ToddCoram</a>
<p><UL><li> Briefly, we made a strategic decision to use <a href="http://c2.com/cgi/wiki?GemStone">GemStone</a>, and another to retain an IO framework from the archives. One of these decisions was correct. Other systems things we built along the way, such as a new interface to our tax package. This entailed primitives in the virtual machine, stuff like that. We did some of these with outside "experts" with mixed results. Our practice now is to bring in the expert, work with her to hack the changes in, then reimplement them in our style, thus truly learning how to do it and making sure it's done our way. Non-briefly, feel free to email for offline discussion. --<a href="RonJeffries.html">RonJeffries</a>
<p></UL><a href="http://c2.com/cgi/wiki?HowToDevelopFrameworks">HowToDevelopFrameworks</a>
<hr>
The trick is how far to generalize. Is Smalltalk critical? Is payroll critical? Are Chet and Rich critical? Was starting from a dead project critical?
<p>I believe that the principles of XP are very widely applicable, and that the specific practices are widely applicable.
<p>For example, even on a one-million-man project, I believe:
<p><OL><li> running suites of <a href="UnitTests.html">UnitTests</a> very frequently will let development go faster than otherwise.
<li> Having <a href="FunctionalTests.html">FunctionalTests</a> will help you know whether you're done better than if you don't have them.
<li> Writing simple code will help you get done sooner and more flexibly. (<a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>)
<li> Working on what you do need instead of what you might need will keep the system cleaner and get you done sooner (<a href="YouArentGonnaNeedIt.html">YouArentGonnaNeedIt</a>).
<li> Having all your <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a> (use cases) broken down into small enough bites to estimate, and adding up the estimates, will give you a better <a href="http://c2.com/cgi/wiki?CommitmentSchedule">CommitmentSchedule</a> than whatever most projects are doing now.
<li> Breaking down all <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a> into <a href="http://c2.com/cgi/wiki?EngineeringTask">EngineeringTask</a> s and having developers estimate those tasks (and tracking them) will give you a better <a href="http://c2.com/cgi/wiki?IterationPlan">IterationPlan</a> than whatever most projects are doing now.
<li> <a href="ProgrammingInPairs.html">ProgrammingInPairs</a> will give you faster development, higher quality, and better cross-training.
<li> More to come ...
<p></OL>On a large project, you might not be able to do these things all <em>as a group</em>. But everyone on the team can readily do them, and they'll work better than the Level 1 process most people have now.
<p>Please list below XP principles and practices that might NOT be useful on other (specified) kinds of projects. Offer some reasoning, please.
--<a href="RonJeffries.html">RonJeffries</a>
<hr>
Not in the list above, but mentioned elsewhere on XP pages are de-emphasising documentation and discouraging code ownership. These might not be useful on a project aiming at re-use over long time-periods in a distributed environment. See <a href="http://c2.com/cgi/wiki?JeffMcKennaForces">JeffMcKennaForces</a>.
<hr>
Separating business logic, UI, and infrastructure people defeats XP, no question. XP is good at creating applications out of situations where the optimum system must track a dialog between what is possible and what is desired, where the development of the system changes both what is possible (as developers learn) and what is desired (as the system and the world change the business environment and the users). The best way I have found to reconcile the possible and the desired is to distribute responsibility for such reconciliation across the entire team and the entire life of the project.
<p>There is a small role to play for technology specialists, if they share the values of the rest of the team. That is, you can't have all the application people trying to do really simple things, and have the nerd-meister downloading new betas of the reusable libraries every couple hours and using every last bit of it. This marks me as a technology conservative- so be it.
<p>I would never separate the UI and business teams. I would give up too much learning as the two worlds rubbed up against each other. You have to learn as fast as possible. It is at the edges that learning happens most (idea stolen from PermaCulture<a href="http://c2.com/cgi/wiki?edit=PermaCulture">?</a>). Make the most edges you can. If I'm working on UI in the morning and business logic in the afternoon, and everybody else is too, then I can't imagine more edges than that.
<p>--<a href="KentBeck.html">KentBeck</a>
<p><hr>
Kent, I worked on a project where developers would work on the UI in the morning and business logic in the afternoon and it was a nightmare. It was difficult for those less experienced with OO techniques to seperate the two. This especially caused a problem because we wanted to reuse the business logic in different applications.
<p>However, we were not doing <a href="ExtremeProgramming.html">ExtremeProgramming</a>. I think a combination of <a href="PairProgramming.html">PairProgramming</a> and <a href="http://c2.com/cgi/wiki?EgolessProgramming">EgolessProgramming</a> would have solved the situation. <a href="http://c2.com/cgi/wiki?EgolessProgramming">EgolessProgramming</a> would have meant that the developer working on the UI and business logic would readily admit when he/she made a decision that compromised the desired ArchitecturalQualities<a href="http://c2.com/cgi/wiki?edit=ArchitecturalQualities">?</a> of the system. <a href="PairProgramming.html">PairProgramming</a> would have meant the situation might have been corrected as (even before) it happened.
<p>-- <a href="http://c2.com/cgi/wiki?HankRoark">HankRoark</a>
<p><hr>
Some things that have <em>not</em> gotten us to XP.
<p>We decided to do a generic framework in an unfamiliar domain area as our first OO project, and did not hire anyone with expertise in the area.
<p>We tried <a href="PairProgramming.html">PairProgramming</a>, but implemented it very badly.
<UL><li> Project leadership decreed that all of the senior developers would concentrate on the next set of risk areas, while the junior staff paired to build the well-understood functionality from cookbooks,
<li> The pairing was assigned and permanent for three weeks,
<li> Tasks were assigned to the pair, who did have the option of working seperately, but had joint reponsibility,
<li> Since the junior staff members are located in small cubicles, both partners could not reach the terminal at the same time. Instead, one person would type, while the other sat back a few feet away and watched.
<p></UL>At the end of six weeks, the staff revolted. Comments such as, "I will never work with <insert partner's name here> on a project again" were heard in a developer's meeting.
<p>We do not have ready access to the organization which needs the code. Instead, the project leader defined all of the requirements himself, had the analysts write them as use cases which were reviewed internally and then reviewed with the customer, who was only available for about one day every two weeks. Since the project leader had his own agenda, many of the requirements and priorities were not congruent with customer needs.
<p>On the plus side, those few of us who have learned refactoring have found doing it in Java to be quite easy, and have found <a href="PairProgramming.html">PairProgramming</a> and <a href="UnitTests.html">UnitTests</a> to be a major benefit. Whether we will be able to reinstitute some of these practices in a new project remains to be seen.
<p>--<a href="http://c2.com/cgi/wiki?RussellGold">RussellGold</a>
<hr>
I ask some questions about this scenario in <a href="http://c2.com/cgi/wiki?PairProgrammingTheWrongWay">PairProgrammingTheWrongWay</a>. --<a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<hr>
Having read much of the XP stuff, I have seen frequent reference to the notion that "ya gotta wanna". If you're developer's don't want to do it, you won't. What about the inverse though? How much buy in do you need from above? How much of a grass roots effort can XP be? I would be really curious how other developer types have gone about getting their organization (esp. at the muckety-muck levels) to tolerate/accept/promote XP?
<p>What if your group is not necessarily project centric? IOW, our software team exists because we always have work and an undying unending stream of projects. We were not formed to work on one single project. In fact, at current, there are 3 material products that we are developing software for. Can XP scale to this kind of situation? One of the ideas we have been toying with, and even tried once or twice is flip-flopping. Traditionally, we have cut the work up into different products and parcelled them out to different individuals. Lately, with <a href="PairProgramming.html">PairProgramming</a>, we've taken a couple of cracks at the team all working on one product for a little while, and then on the day boundary, flipping to another. This seems like the only good boundary to flip-flop on, because it provides a natural time to take a break, let the mind clear, and version existing stuff. --TravisGriggs<a href="http://c2.com/cgi/wiki?edit=TravisGriggs">?</a>
<p><hr>
<p>In my experience, things don't come to a round conclusion on day boundaries. Aside from that, which means we might version at 10 AM, I'd try individuals flipping when they complete their story. If I wanted to flip the whole team, I might try doing it at the end of an iteration, and I'd probably go to a one-week iteration. Please keep us informed on what you try and how it seems to work out! --<a href="RonJeffries.html">RonJeffries</a><hr><a href="http://c2.com/cgi/wiki?edit=ExtremeProgrammingBoundaryConditions">EditText</a> of this page (last edited March 11, 1999)<br><a href="http://c2.com/cgi/wiki?FindPage&value=ExtremeProgrammingBoundaryConditions">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 + -