图1. 项目成功率和项目持续时间的关系图
(横坐标为项目持续时间(多少个月);纵坐标是项目成功的比率)
图3. 产品中要求的功能点在实际中的使用情况
图4. 瀑布模型及其高风险示图
随着越来越多的证据证明了瀑布模型的高风险和高失败率之后,瀑布模型自身也发生了一些变化,以致继续有人采用这种模型的变体来进行项目开发。正如我以前写过的一个文档,这个模型一般来说不适合于是软件开发上。
图5. 瀑布模型的变动性的总体代价
图6. Push 模式中的一个片段
学过控制理论的人都知道一个最简单的道理,“没有反馈(feedback),就没有控制”。反馈的基本原理就是把输出反馈给输入,如果偏差很大,就得调整控制过程,最终使得输出满足输入的需求。总体上看,软件开发的输入是客户,输出是软件产品,控制过程是软件项目的开发过程。如果只是一次性地把软件产品交付给客户,显然就是没有反馈。其过程是线形的: “客户 --> 项目实施--> 客户”这样一个过程,风险很大,所以应该与客户协作,多进行几此这样的过程,让整个开发过程自适应化,最终交付成功得产品。如图7.所示:
图8. 迭代过程示意图
每个迭代过程都是具体而微的“需求-设计-实现-测试”,通过这样多次的小步迭代,逐渐构筑成一个完整的系统。如图9.多次的迭代,系统增量式地完善起来。
图10. 迭代过程中引入变化的总体成本走势
每个实践都值得去研究。对于有争议的地方,寻求个妥协方案出来,总比没有方案好。我就不细说了。可以对比图15.看一下这些实践的实施:
图15. Xp的反馈
|
|
实践
|
描述
|
整个团队协同工作,或者现场客户参与
|
The whole team—programmers and customers—work together in a common project room. One or more customers sit more-or-less full time with the team; they are expected to be subject matter experts and empowered to make decisions regarding requirements and their priority.
The customer contribution includes detailed explanation—to the programmers—of the features briefly summarized on story cards, Planning Game participation, clarification, and writing acceptance tests in collaboration with a programmer.
The purpose is in response to the consistent project failure research indicating that more customer involvement is paramount to successful projects.
The first release of XP spoke of only one onsite customer; this has been recently revised to emphasize a group of customers.
|
小型而频繁地发布
|
Evolutionary delivery. Not applicable to all projects. Not to be confused with organizing one release cycle into many short iterations.
|
测试
:
验收测试和客户测试 |
Testing practices in XP are very important. All features must have automated acceptance (functional) tests. All tests (acceptance and unit) must run with a binary pass/fail result, so that no human inspection of individual test results is required. The acceptance tests are written with collaboration of the customer—they define a testable statement of what acceptance means. This is called Customer Tests in XP.
|
测试
:
测试驱动开发和客户测试 |
Unit tests are written for most code, and the practice of test-driven development (and test-first development) is followed. This includes the practice that the unit test is written by the programmer before the code to be tested. It is a cycle of test Õ code, rather than code Õ test. Usually, the open-source XUnit testing framework family (such as JUnit) is applied (see
www.junit.org
). All acceptance and unit tests are automatically run repeatedly in a 24/7 continuous integration build and test cycle.
See p. 292 for a detailed example.
|
发布计划游戏
|
The Release Planning Game goal is to define the scope of the next operational release, with maximum value (to the customer) software. Typically a half-day one-day session, customer(s) write story cards to describe features, and developers estimate them. There may also exist story cards from prior exploration phase work. The customer then chooses what's in the next release by either 1) setting a date and adding cards until the estimate total matches the time available, or 2) choosing the cards and calculating the release date based on their estimates.
|
迭代计划游戏
|
The Iteration Planning Game goal is to choose the stories to implement, and plan and allocate tasks for the iteration. It happens shortly before each new iteration (1–3 weeks in length). Customer(s) choose the story cards for the iteration. For each, programmers create a task list (on cards or whiteboard) that fulfill the stories. This is followed by a volunteering step in which the programmers choose a set of tasks. They then estimate their task lengths. If tasks are not estimated in the half-day to two-day range, they are refactored.
|
简单设计
|
Avoid speculative design for possible future changes. Avoid creating generalized components that are not immediately required. The design should avoid duplicate code, have a relatively minimal set of classes and methods, and be easily comprehensible.
|
结对编程
|
All production code is created by two programmers at one computer; they rotate using the input devices periodically. Pairs may change frequently, for different tasks. The observer is doing a real-time code review, and perhaps thinking more broadly than the typist, considering tests and so forth.
Certainly, team productivity is not simply a function of the number of hands typing—it is more nuanced. The XP claim is that the combination of cross learning, the peer pressure of more disciplined practice observance and more hours actually programming than procrastinating, defect reduction due to real-time code review, and the stamina and insight to carry on when one programmer is stuck, all add up to an overall team improvement.
|
频繁重构
|
Refactoring in the XP context is the continual effort to simplify the fine-grained code and larger design elements, while still ensuring all tests pass. That is, cleaning the code and design, without changing functionality. There is supposed to be "lots" of refactoring in XP. This practice is also known as continuous design improvement.
The goal is minimal, simple, comprehensible code. It is achieved by small change steps, verifying tests after each, and ideally the use of refactoring tools, now available in some IDEs.
|
代码归集体所有
|
Any pair of programmers can improve any code, and the XP value system is that the entire team is collectively responsible for all the code. The value of "it's her code, and her problem" is not endorsed; rather, if a problem or chance to improve is spotted, it's the spotter's responsibility. A related goal is faster development by removing the bottleneck associated with change requests in an individual code ownership model.
The obvious danger of modifying code one did not originally write is ameliorated in XP by some of the other practices: The guaranteed-present unit and acceptance tests running within an automated continuous integration build process inform you if you broke the code, your pairing partner brings another set of eyes to the change, and common adherence to coding standards ensures all the code looks the same.
|
持续集成
|
All checked-in code is continuously re-integrated and tested on a separate build machine, in an automated 24/7 process loop of compiling, running all unit tests and all or most acceptance tests. There are several open-source tools for this, built on the ubiquitous Ant technology, including CruiseControl and Anthill.
|
平稳的工作节奏
|
Frequent overtime is rightly considered a symptom of deeper problems, and doesn't lead to happy, creative developers, healthy families, or quality, maintainable code. XP doesn't support it—rather, it promotes "no overtime."
|
站立会议
|
With collective code ownership, frequent refactoring, and regular swapping of pair programming partners, everyone needs to follow the same coding style.
|
系统隐喻
|
To aid design communication, capture the overall system or each subsystem with memorable metaphors to describe the key architectural themes. For example, the C3 payroll system was described in terms of an assembly line of checks with posting rule "machines" operating on them, extracting money from different "bins."
Many have reported this the least necessary practice.
|
|
·
现场客户代理
— Many groups wishing to apply XP cannot find full-time "ultimate" customers to work in the project room. For example, consider a new internal system for (very busy) commodity traders. And this problem is common for commercial products for an external market. The common solution is to designate customer proxies that do join the team in the project room, have good (though not as ideal as true customer) knowledge of the domain and requirements, and that represent the ultimate customers. If proxies are used, it is important that the true customers at least participate in end-of-iteration demos, and preferably, in the Planning Games.
·
随时联络客户
— When the onsite customer is not present, arrange matters so that the customer representative is committed to fast access, such as via a mobile phone.
·
拥抱变化
— The overarching attitude that XP promotes is to embrace rather than fight change, in the requirements, design, and code, and be able to move quickly in response to change.
·
完全自愿地
(
接受任务
)— Tasks are not assigned to people. Rather, during the Iteration Planning Game, people choose or volunteer for tasks. This leads to a higher degree of commitment and satisfaction in the self-accepted responsibility, as has been explored in [DL99].
·
非常轻量级地建模
— XP encourages programming very early and does take to "extreme" the avoidance of up-front design work. Any more than 10 or 20 minutes of design thinking (e.g., at the whiteboard with sketches or notes) before programming is considered excessive. Contrast this with Scrum or the UP, for example, where a half-day of design thought near the start of an iteration is acceptable.
·
最少或
“
刚刚够的文档
”— With the goal of getting to code fast, XP discourages writing unnecessary requirements, design, or management documents. The use of small paper index cards is preferred for jotting brief descriptions, as are verbal communication and elaboration. Note that the practice of "avoiding documentation" is compensated by the presence of an onsite customer. XP is not anti-documentation, but notes it has a cost, perhaps better spent on programming.
·
度量
— XP recommends daily measurement of progress and quality. It doesn't mandate the exact metrics, but to "use the simplest ones that could work." Examples include numbers of completed tasks and stories, and number and success rate of running tests.
·
墙壁图表
— The collected metrics are daily updated on wall graphs for all to easily see.
·
跟踪和每日跟踪者
— The regular collection of task and story progress metrics is the responsibility of a tracker. This is done with a walk-about to all the programmers, rather than email; commenting on this—and very telling of the XP attitude—Ron Jeffries (one of the XP founders) said, "XP is about people, not computers." Test metrics can be automatically collected by software.
·
递增的基础结构
— XP recommends (as do the other iterative processes) that the back-end infrastructure (for example, a persistence layer) not be the main focus of implementation in the early iterations, but rather, only enough is implemented to satisfy the user-functional requirements of each iteration.
·
公用项目工作室
— XP projects are run in a common project room rather than separate offices. Pair programming tables are in the center of the room, and the walls are clear for whiteboard and poster work. Of course, people may have a private space for private time, but production software development is a team sport in XP.
·
每日站立会议
— As in Scrum, there is a daily short stand-up (to keep it short) meeting of status.
·
理想工程小时
(IEH)— Task estimates—and possibly story estimates—are done in terms of IEH, or uninterrupted, dedicated, focused time to complete a task.
·
故事评估
— To estimate larger stories, some XP practitioners recommend using only coarse values of one, two, or three week durations rather than IEH or day-level estimates.
|
图16.是极限编程项目过程总览
下图是XP迭代过程。
下图是XP的开发图
图18. XP的Deveopment图
-----------------------------------------------------
下图是XP的集体代码所有图,其实讲的是如何合作开发。
图19. XP的集体代码所有图
图21. 每日10分钟的站立会议
篇幅太大了,看个重要的链接