图15. Xp的反馈
这么多的实践,要由人督促指导实行这种方式。所以刚开始实行XP的团队都配备一名教练。更重要的使让大家认同这种方式。孟夫子说“无恒产者无恒心!”。斗胆小辈我加一句“人无价值信念无恒心”。一个开发团队,一种开发模式要建立起一个信念,一种价值观,下面是
XP的价值观,也是XP最看重的:
· 交流
交流的重要性不言而喻,但仍然要鼓励再鼓励。项目组成员的每天10分钟站立式会议,了解当天的任务和项目的状况。开发人员之间的即刻交流做设计和编码等。客户的参与与促进同客户的沟通,其方式为编写验收测试和计划游戏。总之,没有交流就没有软件开发。意义够大了吧。
· 简单性
简单性是指“做刚好够用的事”。简单性不仅指设计的简单,也指需求、项目管理工具等。比如说项目文档,你三五个人的团队,有时间维护质量上层的文档吗?尤其我要说是设计文档,重中之中是详细设计文档。认为XP不用详细设计是误解,它在领到user-stories之后,编码之前的时间来简单设计。XP不排斥文档,只不过认为它是一种开销,XP坚信(文档化的)代码是最好的文档。并不是懒不想写文档,是维护这个文档要花费三倍甚至以上的时间:我在白板上画好了商量后的草图,要先抄下来,再写成标准的word或openoffice文档,碰到图还得画图,UML还得再画。所以把它简单化:草稿,行,存档!白板,行,拍照存档。充足的人员和时间偷偷会给你吗?在项目产品化阶段的知识共享和培训时再完善文档!把存档的草稿正式化。另外设计师总倾向于采用精巧的,复杂的设计,好象不这么做就不是好的设计师似的;这种复杂性还给交流和理解带来问题,更可能影响到其他简单设计就可以足够应付的地方配合你“精巧设计”要做复杂更改的问题。
· 反馈
反馈保证了质量和自适应。客户编写user-story-card时,程序员立刻就可以进行评估,这样客户就知道工作量。测试先行有反馈,小步迭代有反馈,持续集成有反馈。项目跟踪人员每日得到user-sotries-list上完成情况的跟踪记录反馈,客户每个迭代结束得到重要反馈等。
· 勇气
面对一堆代码,即使你是你写的,你敢做变动吗,你做了变动之后有信心说不会有问题吗?再进一步,你敢做重大的变动吗?没有前面的价值信念和实践,你肯定不敢说有信心。我们的信念和实践现在已经做了很多事:单元测试,验收测试,持续集成,经常性的重构代码,一致的编码规范。有了这些保证,你跟以前相比勇气大多了:)。勇气除了面对激进的代码变动,还包括探求新知。面对新技术,要保持一颗年轻的心哦!
XP的生命周期:
· 试探阶段
目的:- 充分评估第一次迭代的story-cards
- 可行性保证
活动:- 建立原型(20%的需求就是最重要的基础架构性的,前面论述过了)
- 技术等方面的试探性论证
- sotry-cards的编写和评估
· 发布计划游戏(Release Planning Game)
目的:- 对第一次迭代的日期和story-cards达成共识
活动:- 发布计划活动
- 故事卡片(story-cards)的编写和评估
· 迭代计划游戏(Interation Planning Game)
目的:- 明确本次的迭代任务
活动:- 用户从user stories中确定最有价值的特征作为本次迭代的目标
- 加入上次迭代未通过验收测试的user-stories
· 迭代开发
目的:- 在一个迭代周期内实现user-stories
活动:- 简单设计、测试、结对编程、重构、迭代期验收以及在需求细节上与客户不断沟通协作
· 发布
(如果没有完成发布前的工作,返回到迭代计划游戏阶段)
目的:- 产品化,发布产品
活动:- 产品文档、技能培训和团队知识共享,排除项目中的“知识孤岛”现象(其实轮换配对减少了知识孤岛的存在,知识孤岛让开发人员都不知道软件其他部分,这对维护期是个灾难)
- 发布产品
· 维护期
(略)
XP的工件、角色和实践:
➢ 工件(没有文档,除了软件,项目产生了其他什么吗?)
1)story-cards - 记录简明特征需求(非use-case和场景)的纸质卡片,预示着需要进一步与客户讨论具体细节,粒度2-10天。XP是特征驱动不是用例驱动。
2)任务列表 – 每次迭代中针对story编写的任务列表卡片或白板上的表格,任务粒度1-2天。
3)可视化图表 - 用于便于沟通。
➢ 角色
客户
- 编写故事(stories)和验收测试
- 挑选用于发布和迭代的故事
开发-程序员
- 编写测试、设计、和代码
- 重构
- 确定、领取任务和估算
开发-测试员
- 帮助客户编写和开发测试
管理-教练(有经验的XP团队可不设置)
- 过程辅导
- 过程定制
- 干预和培训
管理-项目跟踪者
- 收集度量情况
- 报告进度
- 根据简单的估算进行反馈
其他-顾问等
- 技术咨询和指导
➢ 实践
对应到需求:(谁说XP不做需求,而且是持续获取需求!)
- 计划游戏
- 现场客户
- 验收测试
设计:
- 系统隐喻
- 频繁重构
- 简单设计
实现:
- 频繁重构
- 编码标准(一致的风格、文档化(如doxygen)注释,这可以是最好的设计和实现文档)
- 结对编程
- 代码的所有权归团队
测试和验证:
- 验收测试,客户测试
- 测试先行的开发单元测试
- 现场客户
项目管理:
- 计划游戏
- 小版本发布
- 平稳的工作进度
- 站立短时间会议
配置并改变管理环境:
- 持续继承
- 公用房间
- 计划游戏
核心实践和描述:(摘自Craig Larman Agile and Iterative Development: A Manager's Guide)
不翻译,看点原味的吧。
实践
描述
整个团队协同工作,或者现场客户参与
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的集体代码所有图
4. 我们的方向和要重点研究的几个问题
首先明确的是类瀑布模型肯定不适合软件开发。XP也不是黑客的编写边改方式。借鉴迭代模型和敏捷开发方法势在必行,并且在过去的项目上曾经使用过全部或者部分重要方法和实践(我所知道的是Swork Cao & Robin Qiu的项目上)。其实分解开来,这些重要实践是每个方法或多或少都包含的。
明确了敏捷软件开发的方向,就要对其中几个地方进行探究和学习,比如如何开展商务谈判、合同签定;如何让客户或其代理加入开发团队或者随需可以及时交流;如何做发布计划游戏;如何做迭代计划游戏;如何进行短时间的站立会议;如何进行简单设计;测试驱动和编码以及重构(Refactoring);如何进行自动化的单元测试和持续集成;验收测试,以及产品化过程学习和知识共享。
总的来说,在这样的团队中,项目成员能够得到锻炼和知识积累,而不象在Push模式下单纯接受任务的coder这样一个枯燥,缺乏交流和自信,缺乏勇气和疲于应付Bugs的局面。从而可以进入到一种积极向上的,心情轻松的,良好交流的、具合作氛围的、不断克服困难后得到成就感的良好循环。
软件开发中有苦闷也有快乐。我的一个同时曾经独自一个人对付一个子项目,三个月闷头干活,至见到计算机就要吐的地步,毫无乐趣,枯燥乏味,项目也没怎么完成好。身为程序员的我们要会找点乐子自娱自乐。比如Sunwah最合格的程序员Daniel Cao就play violin,过去是驴叫,现在应该有旋律了吧?!。
5. XP的场景和样板
XP有样板工程,但我没去进一步查看能获得那些信息。
我没能搜集到更多的图,下面是一些,还有一个重要链接,大家务必看一下,如果全部复制过来,篇幅太大了。
开发现场,图20.所示。看过Microsoft的一个广告的人都知道,会议室的墙壁上,走道甚至室玻璃窗上都画满了各种图表。这个图没Microsoft的夸张。
图20. 常见的开发现场,空出所有的墙面备用
站立会议,图21所示。其实我们也是这么开会的:)坐着开会容易跑题,时间也不好控制,站着,时间一长就累,都想着散会。
图21. 每日10分钟的站立会议
篇幅太大了,看个重要的链接
XP Team Room (http://www.scissor.com/resources/teamroom/),我给出一张图,引起大家的兴趣先!
图22. XP团队工作室一角
6.附录
敏捷软件开发宣言
· 个体和交互胜过过程和工具
· 可以工作的软件胜过面面俱到的文档
· 客户合作胜过合同谈判
· 响应变化胜过遵循计划
也就是说,虽然也具有价值,但我们认为左边的项具有更大的价值。
敏捷软件开发的原则我们遵循以下的原则:
1)我们最先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
2)即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3)经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
4)在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
5)围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
6)在团队内部以及团队之间,最有效果并且最富有效率的传递信息的方式,就是面对面的交谈。
7)可以工作的软件是首要的进度度量标准。
8)敏捷过程提倡平稳的开发。
9)发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
10)不断地关注优秀的技能和好的设计会增强敏捷的能力。
11)简单——使未完成的工作最大化的艺术——是根本的。
12)最好的架构、需求和设计出自于自我组织的团队。
13)每隔一定的时间,团队会在如何才能更有效地工作方面进行反省,然后相应地调整自己的行为。
7.参考资料
Craig Larman - Agile and Iterative Development: A Manager's Guide
Auer, K., and Miller, R. 2002. - Extreme Programming Applied: Playing to Win. Addison-Wesley.
Kent Beck, Cynthia Andres - Extreme Programming Explained: Embrace Change, Second Edition
Ambler, S. 2002. - Agile Modeling, John Wiley & Sons
Larman, C. 2001. - Applying UML and Patterns: An Introduction to OOA/D and the Unified Process, 2nd edition.
Mike Cohn - User Stories Applied for Agile Software Development
Ivar Jacobson, Grady Booch, and James Rumbaugh, Rational Software - The Unified Process
http://www.extremeprogramming.org
http://www.xprogramming.com
Paul Hamill - Unit Test Frameworks
David Astels - Test-Driven Development: A Practical Guide
Martin Fowler - Refactoring: Improving the Design of Existing Code
Robert C. Martin - Agile software Development: Principles, Patterns, and Practices
8.后记
本来只想写个关于瀑布模型和迭代模型对比的文章,后来觉得既然有相关的资料可以引用,还是多介绍一些敏捷软件软件开发和极限编程方面的内容,敏捷方法中我个人比较欣赏XP的做法,所以很多部分都是XP方面的内容。
写文档很花时间,我也没有工夫认真地一一重画图表,于是就复制过来。觉得还有许多地方可以做得更好,还有很多地方可以并且需要扩展开来。现阶段,我们的现状是要把文档篇幅扩展;大家熟悉了这些过程之后,就可以提纲挈领,做到纲举目张的效果。也就是把文档变薄。
一句话:
拥有一个复杂的思想比较容易。
拥有一个简单的思想难上加难。
—— Carver Mead
2005-10-18
Robin Qiu于 SWHSS