关于敏捷的探讨

 

下面是我对CSDN上面一个学生写的《学生使用极限编程进行团队开发的方案》的评论：原文地址：http://blog.csdn.net/AimarC/archive/2005/06/01/385279.aspx我的评论如下：与其讨论XP的开发方法，我更愿意讨论敏捷开发。敏捷最终要的是什么，就是拥抱变化，所以在没有具体项目的情况下，定出的原则或是方案都有点之上谈兵的感觉。一定要时时刻刻记得，不管采用什么办法，客户需要的，才是我们应给贡献的。为敏捷而敏捷或者为极限而极限都不是一个好的开始。不要一味的去否定传统的瀑布模型。正如Martin Fowler在演讲中说的那样，CMMI对敏捷也是友好的。采用什么样的开发方式必须取决于所做产品的本身。如果“不知道如何组织一个团队，不知道如何分工合作，以及如何开始一个项目”那么不管采用什么样的开发方式都是失败的。在敏捷开发社团里，很强调coach的作用，一个好的导师或者一本好的手册，都是团队取得成功的巨大因素。下面再具体说说你所划分的四个阶段所存在的问题：系统规划阶段：在敏捷开发过程中，我更愿意把这个阶段称之为需求开发，这不应该成为一个独立的阶段，而应该贯穿于开发的整个生命周期。因为在敏捷开发原则中认为，客户的需求总是不断变化的。现场客户是个不错的主意，不过UML并不是必须的。采用用例分析的方法不一定要参考什么书，关键点在于必须使用用户能够理解的语言。比如说使用story card，把功能点从用户提出的概念分解成用户能够理解的具体操作流程。我想强调的是必须始终进行需求的开发，在每一次版本构建完毕后，都必须取得用户的积极响应和支持，与用户交流，采纳或者修改用户的意见和想法。迭代设计阶段：Oops，其实这个阶段只需要做一件事情，把前面搜集的用户需求整理优先度，首先去完成那些最紧急的部分迭代编码阶段：很可惜对于测试，你只是一句话带过。如果你使用XP的话，最好使用结对编程，这样可以发挥出XP的最大优势和潜力，尤其是当你们的编码能力不太强的时候，结对编程有一种互补的效应。如果使用你所谓的“接力棒”的方法，那么完整注释和高度一致的编码规范就是必须的，其实这两点其实比结对编程更加难以实施——接力棒缺乏简单有效的沟通——反而容易变成推卸责任的好借口。然后说说测试，要使用好的敏捷开发，必须测试先行，光测试用例是不够的，最好先写出你的自动化的单元测试类（这就是我说为什么过程语言很难实现敏捷的原因），并在测试类运行的前提下进行重构和增量开发。系统整体测试阶段：这个时候，应该是至少alpha版或者beta版了吧，如果还需要在代码级的基础上做重构的话，我只能说“恭喜你，你的项目失败了”。欢迎讨论。