📄 fourvariables.html
字号:
<head><title>Four Variables</title></head><body><h1><img src="logo.gif"> Four Variables</h1>You ask your boss what he wishes you would do with the project. He answers, in his own words, "Use fewer people to get more done, increase quality, and get done sooner". You're sorry you asked.
<p>Resources, Scope, Quality, Time. Those are the dimensions of your project. Memorize those words and work from them every time you report status, and every time you think about what to do, or not do.
<p>Today I'm thinking about <a href="http://c2.com/cgi/wiki?FourVariablesUnderStress">FourVariablesUnderStress</a>. --<a href="RonJeffries.html">RonJeffries</a>
<hr>
On comp.object, I once saw someone write that you can draw a triangle for managers with the following labels on the vertices: cost-savings, quality, and fast-delivery. Then you ask them to draw a point in the triangle closest to the thing that they want the most, the implication being that you'll lose on proportionately on the other two. I'm glad that that scope is mentioned here. For in-house development, it is often more malleable than the other three.
<p>-- <a href="http://c2.com/cgi/wiki?MichaelFeathers">MichaelFeathers</a>
<hr>
Projects under stress often squeeze quality because no one can see it happening (until they release crap too late). I'll add something on that to <a href="http://c2.com/cgi/wiki?FourVariablesUnderStress">FourVariablesUnderStress</a>. --<a href="RonJeffries.html">RonJeffries</a>
<hr>
Why separate quality from scope, other than to emphasize quality?
Scope represents the cost or effort required to achieve an end.
Lowering quality levels below what is specified (assuming
that quality <em>is</em> specified) is a sneaky way of reducing scope
by swapping in a lesser-quality imitation. Raising quality beyond
what is required expands scope.
<p><em>We separate quality just because there's the sneaky way of reducing scope, thus sabotaging the project privately while looking good publicly. This isn't a good thing. I'm not convinced, OTOH, that raising quality expands scope. For sure, the XP Testing practices provide known and high levels of quality while actually speeding up development. But it seems to me that over reasonable levels of quality, the scope curve is pretty flat, and that it's more a matter of which quality practices one uses. Discussion, please. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>The "time people scope" triangle seems to me to be a more powerful metaphor for stability than a square.. --<a href="http://c2.com/cgi/wiki?DaveSmith">DaveSmith</a>
<p>I, too, prefer the triangle as a metaphor. But the hidden tradeoff is to lose quality while appearing to make time/people/scope. If I had to drop something to get a triangle, I'd drop Resources, since they're generally more fixed anyway. maybe we should think of it as if changing Resources moved you to a different tradeoff triangle for Time/Scope/Quality. --<a href="RonJeffries.html">RonJeffries</a>
<p>What about a tetrahedron (i.e. a three-sided pyramid) as a metaphor: Four corners and still proportional trade-offs? There is a nice extension to this metaphor: When you look flat on one of the triangular sides of a tetrahedron, the fourth vertex is hidden! --<a href="http://c2.com/cgi/wiki?HaskoHeinecke">HaskoHeinecke</a>
<p><em>Wouldn't it have to be an asymmetric tetrahedron, and probably one with curved faces? That is, the relationships between the vericese are not simple linear proportionalities.</em>
<p><em>In fact, now that I think about it some more, aren't we really talking about a region of a four-dimentional vector space with...no, I've thought about it too much now. Sorry</em>
<p><hr>
I find thinking about projects in terms of <a href="FourVariables.html">FourVariables</a> to be very helpful. This includes separating quality from scope, since it gives more of an explicit trade-off. But don't forget the difference between <a href="http://c2.com/cgi/wiki?InternalAndExternalQuality">InternalAndExternalQuality</a>.
--<a href="http://c2.com/cgi/wiki?MartinFowler">MartinFowler</a>
<hr>
A decline in internal quality is often a leading indicator for a future decline in external quality. The counter-argument from Marketing and Sales managers is often "If the customer isn't going to see a problem now, it isn't a problem now." Has anyone come up with effective arguments for spending time on internal quality?
<p><em>Don't argue for it, just do it. Producing internal quality as you go along is not a time spender, it's a time saver. <a href="RefactorMercilessly.html">RefactorMercilessly</a> is just one of our coding practices. We keep our nest clean because it makes us go faster. When we have failed to do this, we saw the problem first in our <a href="http://c2.com/cgi/wiki?LoadFactor">LoadFactor</a>, i.e. we were producing working functionality more slowly. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>Smalltalk and ENVY facilitate <a href="RefactorMercilessly.html">RefactorMercilessly</a>--you get rapid incremental recompiles, and distributing the results to the team is easy.
Unfortunately, many of
us are working in C++ environments. Given the current state of C++ tools,
particularly in the PC world, frequent refactoring in large, ongoing C++ projects
has a high cost (for a number of reasons, including compile times, the increased need for and difficulty of merging parallel changes made while the refactoring is underway, the need to jigger dynamic casts, etc.) It's a lot harder to "just do it" and hide the refactoring from interested onlookers. --<a href="http://c2.com/cgi/wiki?DaveSmith">DaveSmith</a>
<p>With lower internal quality changing and extending the software will be more time-consuming and hence increase <a href="http://c2.com/cgi/wiki?TimeToMarket">TimeToMarket</a>. Now. Does marketing want to sacrifice <a href="http://c2.com/cgi/wiki?TimeToMarket">TimeToMarket</a>? --<a href="http://c2.com/cgi/wiki?AndersChrigstrom">AndersChrigstrom</a>
<p>They want to defer paying <a href="http://c2.com/cgi/wiki?TechnicalDebt">TechnicalDebt</a> until after the next release. It's their version of XP. You Aren't Gonna Need That Internal Quality, so postpone it indefinitely.
-- <a href="http://c2.com/cgi/wiki?DaveHarris">DaveHarris</a>
<p><em>That's interesting. Why then is it right when we (development) do it and wrong when they do it ? Is it wrong when they do it ? Two conflicting XP processes ? Need to integrate them, take a larger view ? --<a href="http://c2.com/cgi/wiki?SimonMichael">SimonMichael</a></em>
<p>The problem with the business types practicing <a href="YouArentGonnaNeedIt.html">YouArentGonnaNeedIt</a> is that this concept only works in conjunction with <a href="RefactorMercilessly.html">RefactorMercilessly</a>. These two practices are yin and yang. When one practices <a href="YouArentGonnaNeedIt.html">YouArentGonnaNeedIt</a> without <a href="RefactorMercilessly.html">RefactorMercilessly</a>, one produces a lot of redundancy and unnecessary complexity. And how does marketing practice <a href="RefactorMercilessly.html">RefactorMercilessly</a>? --<a href="http://c2.com/cgi/wiki?RobMandeville">RobMandeville</a>
<p>Thing is, three weeks without keeping your house clean is long enough to start slowing down. Seriously, I wouldn't raise the issue with marketing any more than I'd raise the issue of team formatting style: it's technical's responsibility. And if it was raised, I'd just tell them that the approach we use has been shown to let us go faster than the alternatives. If they don't like it, they can get someone else. --<a href="RonJeffries.html">RonJeffries</a>
<p>I've seen some folks talk about 5 or 6 variables (more like "dimensions")
rather than just 3 or 4: Cost, Quality, Schedule, Scope, Staffing, & Resources (sometimes staffing & resources are lumped together) --<a href="http://c2.com/cgi/wiki?BradAppleton">BradAppleton</a>
<p>We lump cost, staff, resources under resources, break out under that heading. Similarly break out unit, functional, parallel tests under quality. Etc. --<a href="RonJeffries.html">RonJeffries</a>
<p>Anything more than two dimensions will confuse pointy-haired managers. ;->
Ask them how they want to trade off Time (Schedule), Cost (Staffing & tools), and Features (scope).
Quality is not negotiable.
As Schedule and Staffing are usually fixed, the only option is to vary Features / Scope -- which can be very effective.
-- <a href="http://c2.com/cgi/wiki?JeffGrigg">JeffGrigg</a>
<p><em>Perhaps, quality should not be negotiable, but often it gets squeezed. If a team (I'm talking about the whole team: supervisors, customers, whatever) continues to mention it in the negotiations then it may help members to point out to each other when and where the Quality squeeze is creeping in. </em>
<em>-- <a href="http://c2.com/cgi/wiki?EricHerman">EricHerman</a></em>
<p>Quality <strong>should</strong> be negotiable. If you make an FP error in an Ariane5, you lose a few billion euros. The same mistake in a space shuttle kills people. If you apply space shuttle quality standards to commercial software them Microsoft has cornered the market before you reach release 1.0. You might say that increased quality speeds up development, but only to a point. The graph has a U shape. Once you're on the wrong side of the U, then you need to <em>quantify and justify</em> the costs and benefits of the additional rigor. --<a href="http://c2.com/cgi/wiki?DaveWhipp">DaveWhipp</a>
<p>In many places I visit, they consider scope fixed, and feel they can only move the schedule or add people. It takes much work on my part to introduce them to the notion that they can hold schedule and reduce scope. --Alistair
<p><p>ScottAmbler<a href="http://c2.com/cgi/wiki?edit=ScottAmbler">?</a> in the ProcessPatternsBook<a href="http://c2.com/cgi/wiki?edit=ProcessPatternsBook">?</a> says that there are four "Estimating Factors" (Figure 4.6).
But I think they can easily be reduced to the Four Variables shown above:
<OL><li> Resources (<strong>People, Cost, Tools/Techniques</strong>)
<li> <strong>Scope</strong>
<li> <strong>Quality</strong>
<li> <strong>Time</strong>
</OL>-- <a href="http://c2.com/cgi/wiki?JeffGrigg">JeffGrigg</a>
<p>c.f. the <a href="http://c2.com/cgi/wiki?BalloonStory">BalloonStory</a>
<p>However, Quality is not independent from Time and Scope. If you reduce Quality, eventually development slows to a snail's pace as the programmers struggle with bugs and bad code, and so Time must be extended or Scope reduced.
<p><em>More scope takes more time, higher quality in same time reduces scope, more programmers change soope/time, etc. None of the variables are independent. Wasn't suggesting that they were.</em>
<p>Most current theory proposes an <em>inverse</em> relationship between quality and time and resources. Simply put, crappy code takes more time, effort, and manpower to get working. Scope is increased with good quality because of the reduction in time, effort, and manpower. What are the arguments contrary to this reasoning?
-- <a href="http://c2.com/cgi/wiki?WayneMack">WayneMack</a>
<p>Exactly! You can trade the other three variables off against each other by decreasing one of them to keep the other two steady or improve them. E.g. decrease scope to keep within budget and time, or increase time to maintain budget and scope. However, the opposite holds for quality. If you decrease quality, you soon <em>increase</em> the time requirements, reduce the scope, go over budget etc.
<hr><a href="http://c2.com/cgi/wiki?edit=FourVariables">EditText</a> of this page (last edited June 1, 2000)<br><a href="http://c2.com/cgi/wiki?FindPage&value=FourVariables">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 + -