📄 extremeprogrammingsystem.html
字号:
<head><title>Extreme Programming System</title></head><body><h1><img src="logo.gif"> Extreme Programming System</h1><a href="ExtremeProgramming.html">ExtremeProgramming</a> is a discipline of software development based on values of Simplicity, Communication, Feedback, and Aggressiveness.
<p><a href="ExtremeProgramming.html">ExtremeProgramming</a> is expressed as a system of practices which balance each other to help keep projects on track.
<p>Via the <a href="PlanningGame.html">PlanningGame</a>, XP delegates to customers the authority to define all the requirements with <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a>, and to set the priority for those stories. XP also delegates to customers the responsibility to set priorities in such a way as to deliver <em>maximum business value</em> (<a href="http://c2.com/cgi/wiki?BusinessValueFirst">BusinessValueFirst</a>) within the resource constraints of the project, and to define tests that will determine when quality requirements are met.
<p>XP delegates to developers the authority to estimate, for each story, how long it will take to implement. XP also delegates to developers the responsibility to meet those estimates if at all possible, to measure their performance against their estimates, and to improve the accuracy of estimates over the course of the project.
<p>The practices that make up this delegation lead to a very stress-free flow of development.
<p>Because the customers have the task of defining the project elements, and because they have good information as to how long things will take, they can easily optimize the product delivered by putting in high-value low cost features.
<p>Because the developers have complete authority for estimating the time to implement each feature, they become almost indifferent, in a positive way, to the features that are chosen to make up the deliverable.
<p>Delegating priority setting to the customer, if done blindly, could lead to a choice of features, and an order of those features, that might leave some key product capability too late. If the system is supposed to be a distributed database, but the priorities didn't call for any work on distribution until the last week, something bad might happen.
<p>To balance priority-setting, XP has the rule <a href="http://c2.com/cgi/wiki?WorstThingsFirst">WorstThingsFirst</a>. This rule means that the entire team will consider and discuss the risks of the project. During this discussion, the team reaches agreement on risky areas, and defines efforts (think Technical Stories, though we don't use that term) that should be undertaken to reduce the risks.
<p>To accomodate learning and discovery of new risks or opportunities, XP has the practice of doing a <a href="http://c2.com/cgi/wiki?ReleasePlan">ReleasePlan</a>, an overview of the entire remaining development period, every few iterations. This provides a chance to surface new risks, bring forward capabilities that would add more value than the ones formerly contemplated, and to tune the plan in any other agreed way.
<p>Within this context, the practice remains solid that the customer sets the final priorities. The developers inform the customer of the risks, recommend what is to be done, and do what comes out. (I suppose that a really stupid customer might say "don't worry about performance". I suppose that a developer who seriously thought that was wrong should consider resigning. In practice, customers are almost always smart enough to see risks.)
<p>Once the <a href="http://c2.com/cgi/wiki?ReleasePlan">ReleasePlan</a> is in place, we do <a href="http://c2.com/cgi/wiki?IterationPlanning">IterationPlanning</a>. The customers select the <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a> to be worked on, developers determine the <a href="http://c2.com/cgi/wiki?EngineeringTasks">EngineeringTasks</a> to implement the stories, sign up, and estimate how long it'll take. We put into the iteration the amount of work we can do.
<p>During development, we may think of some class or method that would be useful later. XP has a rule, called <a href="YouArentGonnaNeedIt.html">YouArentGonnaNeedIt</a>. That rule says that we never implement that speculative class or method. We have that rule, and we state it so firmly, and we live by it so carefully because to do otherwise would be to violate the balance between customer setting priorities and developer estimating time.
<p>We have other rules during development. For example, we always <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>. That is, we choose the simplest approach to solving the problem, subject only to the proviso that it could work. We do that because it minimizes the cost of doing whatever we're doing.
<p>There are risks with the Simplest rule, mostly to the effect that the simplest thing might not hold up, and it might be hard to fix it later. These risks are balanced by some facts, and by some other XP practices. The facts relate to the characteristic of well-factored objects that they encapsulate behavior in a single place. Thus, when the behavior needs to be optimized or enhanced, there tends to be only one place to fix, making it not that difficult to fix. There is also the risk that the code might not be encapsulated, that by doing the simplest thing the system was left with redundant or ugly code. We balance that by our rule <a href="RefactorMercilessly.html">RefactorMercilessly</a>, which ensures that the objects are clean and that there is no duplication that gets in the way.
<p>I could, and in the fullness of time, will go on. The overall picture is that the XP practices have been defined to balance the forces acting on the project.
<p>XP is one prescription for a software process. There are many such prescriptions out there, and there are many other ad-hoc processes in place that people actually use. Development projects are free to choose whatever process makes sense to them.
<p>XP has one other rule: <a href="http://c2.com/cgi/wiki?TheyreJustRules">TheyreJustRules</a>. This is not license to break the rules: it is license to come together as a group and <em>change</em> the rules. If an XP team found that some rule, say YAGNI, didn't properly balance the project, they would change the rule, add one, or remove one, to bring the project into balance. The <a href="ExtremeProgramming.html">ExtremeProgramming</a> folks have worked for years to refine these practices, and we are confident that they are very close. But we continue to watch them in use and adjust if and when we actually need adjustment.
<p>We offer XP as one approach to consider, and we offer the rationale behind it to aid interested people in deciding whether XP applies to their situation. We are not saying it's the only way, we are not saying anything bad about any other way. We are saying XP works, it's consistent, it's lightweight, it's fun, it's worth considering.
<p>--<a href="RonJeffries.html">RonJeffries</a>
<hr>
In a word: <em>Outstanding!</em>
I like the above description enormously. It is (IMHO of course) clear and concise, with a confident yet honest and unpretentious tone. Keep this up and I might just have to retract all my previous complaints about the perceived tone/exclusivity in the descriptions of other XP practices. Nice work Ron! Thanks for being persistent. --<a href="http://c2.com/cgi/wiki?BradAppleton">BradAppleton</a>
<hr>
I've only recently been introduced to the concepts and practices of XP and find many of the principles behind it very interesting. I work mainly for corporate IT shops and most of my projects rely on sound database development. How could XP be used for this problem/issue without having a very un-normalized database? Constantly adding and updating data structures during the development could lead to a slow and unreliable back-end. If you have any references to help clarify this part of the development cycle it would be greatly appreciated. Thanks.
--<a href="http://c2.com/cgi/wiki?PatMcQuade">PatMcQuade</a><hr><a href="http://c2.com/cgi/wiki?edit=ExtremeProgrammingSystem">EditText</a> of this page (last edited September 6, 2000)<br><a href="http://c2.com/cgi/wiki?FindPage&value=ExtremeProgrammingSystem">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 + -