📄 beyondextremeprogramming.html
字号:
<head><title>Beyond Extreme Programming</title></head><body><h1><img src="logo.gif"> Beyond Extreme Programming</h1><strong>C'mon all you questioners! I built this page for you to raise alternative process components for comparison with XP. Pitch in! Or if you don't like this page as a start, write the one you like!</strong>
<p>A little help here. Often people question whether they could use XP because they, or their management, believe in, or use, various techniques. "We use Hypertensive Planning, could we use XP with or instead of that?"
<p>Are there practices or processes that you'd like to compare and contrast with XP? If so, please list them here. Thanks! --<a href="RonJeffries.html">RonJeffries</a>
<hr>
Many development projects use even less "formal" process than XP, and the challenge is to get them to use any at all. However, some groups or companies are already using some pretty standard process components. Let's talk here about some famous process components that might be in use, and how they relate to XP. Please offer practices that you'd like to talk about, and comments on the ones that show up here. --<a href="RonJeffries.html">RonJeffries</a>
<hr>
<DL><dt><strong>Code Reviews</strong>:<dd>A formal or semi-formal process whereby, at intervals, developers come together to go over some part of the program. Most often these reviews cover the work of one developer at a time. The practice may call for reviews of all code, or just critical code. The most common approach allows reviewers to raise issues, but not to propose changes, and allows the developer to answer questions but not defend the work. Code Reviews cover standards conformance, defects, what else?
<p></DL>Two <a href="ExtremeProgramming.html">ExtremeProgramming</a> practices bear most directly on the practice of Code Reviews: <a href="PairProgramming.html">PairProgramming</a> and <a href="UnitTests.html">UnitTests</a>.
<p><a href="PairProgramming.html">PairProgramming</a> can be seen as a kind of live, two-person review of code that is coming into being from the review. If I had developed my code with a partner, I would feel much more comfortable going into a review that the code would meet standards and do what it was supposed to do.
<p>XP's <a href="UnitTests.html">UnitTests</a> are written during development of each feature - ideally before the development. An XP-written object has unit tests for all of its behavior that could possibly fail. If I had developed my code with <a href="UnitTests.html">UnitTests</a>, I would feel much more comfortable going into a review that the code would do what it was supposed to do.
<p>Used well, code reviews would track review effectiveness, in terms of standards violations found, defects found, and so on. Most review processes classify the things they find as to whether they are important or not.
<p>One of the biggest drawbacks to code reviews is that they take place after a relatively large amount of code has been produced. The changes the review proposes can be somewhat disruptive to the development process. While reviews surely save money compared to letting the problems go further downstream, even better would be process improvements upstream.
<p>Suppose that a team instituted <a href="PairProgramming.html">PairProgramming</a> and <a href="UnitTests.html">UnitTests</a> upstream from reviews. Might the problems found by reviews reduce so far in number and importance, that the reviews were no longer economic?
<p>--<a href="RonJeffries.html">RonJeffries</a>
<p><a href="http://c2.com/cgi/wiki?BradAppleton">BradAppleton</a> raises <a href="http://c2.com/cgi/wiki?IssuesOnReviews">IssuesOnReviews</a>.
<p>I have been pushing PP for some time at work, and pointed people to the research by <a href="http://c2.com/cgi/wiki?LaurieWilliams">LaurieWilliams</a>. However our Quality Manager was unconvinced and asked if there was any research comparing the effectiveness of PP against code reviews. I had to admit that there was none that I knew of. Has anyone done an experimental comparison? -- <a href="http://c2.com/cgi/wiki?DaveKirby">DaveKirby</a>
<p><p><hr>
<DL><dt><strong>PERT Charts</strong>:<dd>PERT, Gantt, and other "program management" tools are often used as part of the planning process. In many cases, the schedule shown by these tools bears little relation to the actual schedule. <em>Especially welcome here would be comments on where these tools have actually helped.</em>
<p></DL>I (<a href="RonJeffries.html">RonJeffries</a>) have used, directly or with my project administrators, several generations of these planning tools. They had several drawbacks: they were time-consuming to keep up; they would fall out of synch with reality very rapidly; they seemed to be more true than they were, all printed so nicely; often we couldn't make the program display what we really thought would happen because of limitations in the software.
<p>XP uses the <a href="PlanningGame.html">PlanningGame</a>, with <a href="http://c2.com/cgi/wiki?CommitmentSchedule">CommitmentSchedule</a> to show the overall look of things, and <a href="http://c2.com/cgi/wiki?IterationPlan">IterationPlan</a> to show the next few weeks. It is trivial, literally, to change the plan: pick up a card and move it from one place to another on the table.
<p>Could some way of recording what the plan is, and how progress is being made, either replace your favorite PERTGanntHarvard standard, or feed into it to generate company standard reports? This way you could have a combination of both worlds: you could know what was really happening, and you could print out the reports people have come to respect. It'd be more expensive than just doing XP's planning, but most of the rest of the work could be done outside the mainstream planning and development, so it needn't slow things down.
<p>--<a href="RonJeffries.html">RonJeffries</a>
<p>Here's how one project <a href="http://c2.com/cgi/wiki?GotaHandleOnStatus">GotaHandleOnStatus</a>. --<a href="http://c2.com/cgi/wiki?BradAppleton">BradAppleton</a>
<p><hr>
<p>A story I've heard several times over the years is that <strong>Pert</strong> was devised during the construction of the Polaris submarine not as a tool for managing
the project,
but as tool for distracting attention away from the project.
By giving government oversight bureaucrats a big chart with lots of boxes that needed to be kept up-to-date,
the bureaucrats where keep out of the way of the people who were doing the real work.
<p>Urban Legend? --<a href="http://c2.com/cgi/wiki?DaveSmith">DaveSmith</a>
<p><hr>
Let's suppose you're using XP to develop software. What should you do if upper management or the company that hires you mandates that you deliver Pert or Gantt charts so they can track your progress? XP doesn't track dependencies between user stories so this will be difficult to do. Any suggestions? --<a href="http://c2.com/cgi/wiki?AlejandroGoyen">AlejandroGoyen</a>
<p><em>I haven't actually gotten XP started yet, but here's an idea. You could create tasks that are related to <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a> and use MS Project to do resource leveling and come up with the schedule. Don't put any dependencies between the tasks, you don't need to. You can create a summary task for completed stories and outstanding stories; then when you finish a story, mark it as 100% complete and move it under the 'completed stories' task. The only dependency would be an artificial one that says incomplete stories is dependent on completed stories.</em>
<p><PRE> V===Completed Stories===V
[Story1] |
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -