关于敏捷的探讨

 

下面是我对优快云上面一个学生写的《学生使用极限编程进行团队开发的方案》的评论：
原文地址：http://blog.youkuaiyun.com/AimarC/archive/2005/06/01/385279.aspx
我的评论如下：
与其讨论XP的开发方法，我更愿意讨论敏捷开发。
敏捷最终要的是什么，就是拥抱变化，所以在没有具体项目的情况下，定出的原则
或是方案都有点之上谈兵的感觉。一定要时时刻刻记得，不管采用什么办法，客户
需要的，才是我们应给贡献的。为敏捷而敏捷或者为极限而极限都不是一个好的开始。
不要一味的去否定传统的瀑布模型。正如Martin Fowler在演讲中说的那样，CMMI
对敏捷也是友好的。采用什么样的开发方式必须取决于所做产品的本身。如果“不
知道如何组织一个团队，不知道如何分工合作，以及如何开始一个项目”那么不管
采用什么样的开发方式都是失败的。在敏捷开发社团里，很强调coach的作用，一
个好的导师或者一本好的手册，都是团队取得成功的巨大因素。
下面再具体说说你所划分的四个阶段所存在的问题：

系统规划阶段：在敏捷开发过程中，我更愿意把这个阶段称之为需求开发，这不应
该成为一个独立的阶段，而应该贯穿于开发的整个生命周期。因为在敏捷开发原则
中认为，客户的需求总是不断变化的。现场客户是个不错的主意，不过UML并不是
必须的。采用用例分析的方法不一定要参考什么书，关键点在于必须使用用户能够
理解的语言。比如说使用story card，把功能点从用户提出的概念分解成用户能够
理解的具体操作流程。我想强调的是必须始终进行需求的开发，在每一次版本构建
完毕后，都必须取得用户的积极响应和支持，与用户交流，采纳或者修改用户的意
见和想法。
迭代设计阶段：Oops，其实这个阶段只需要做一件事情，把前面搜集的用户需求整
理优先度，首先去完成那些最紧急的部分
迭代编码阶段：很可惜对于测试，你只是一句话带过。如果你使用XP的话，最好使
用结对编程，这样可以发挥出XP的最大优势和潜力，尤其是当你们的编码能力不太
强的时候，结对编程有一种互补的效应。如果使用你所谓的“接力棒”的方法，那么
完整注释和高度一致的编码规范就是必须的，其实这两点其实比结对编程更加难以
实施——接力棒缺乏简单有效的沟通——反而容易变成推卸责任的好借口。然后说说测
试，要使用好的敏捷开发，必须测试先行，光测试用例是不够的，最好先写出你的
自动化的单元测试类（这就是我说为什么过程语言很难实现敏捷的原因），并在测
试类运行的前提下进行重构和增量开发。
系统整体测试阶段：这个时候，应该是至少alpha版或者beta版了吧，如果还需要
在代码级的基础上做重构的话，我只能说“恭喜你，你的项目失败了”。
欢迎讨论。