不久前，笔者曾经接手一个蹩脚的软件开发项目，这个项目曾一度处于失败的边缘，整个开发团队也是精神涣散。然而，他们的任务却很复杂：项目团队要开发一套复杂的银行管理系统并且项目交付时间迫在眉睫。

作为刚接手的项目经理，在和团队沟通之后，我把整个开发团队拉到一个离公司不远，但很僻静的小阁楼里，决定封闭开发，并让团队成员选择自己最喜欢的工作方法，同时我自己也加入这个团队，共同参与开发，由此开始了我的项目流程改造之路。

首先，我和助手把事先准备好的正反印有不同颜色的空白表格发给了每一个项目组成员，要求大家在不同的颜色面上写出自己认为在过去的项目中，能提高项目开发的事情，在另一面上写下延迟项目的行为。

然后，我们把所有表格进行分类，并根据的大家所写的，保留那些有益的流程，改变那些会延迟项目的行为，制定了一个全新的开发流程，剩下的事情就是，用实际的开发效果来检验和完善这个新的项目流程。在反复修改了近3个星期之后，项目终于走上了正轨，经过项目流程改造，不仅项目的开发效率提高了很多，而且团队之间的信任也加强了，最终挽救了整个项目，提前一个星期将项目交给了客户。

敏捷开发 把不同的事情交给不同的人

在上面项目中从上面的实例我们可以发掘出一点，就是在项目的进行中，我们采用了对不同的项目采用了不同用的流程和，采用不同用的工作秩序，甚至还可以是不同的人员，这恰恰遵循了。其实，敏捷开发就是意味着将不同的事情交给不同的人的核心思想。，但是，所有的敏捷开发方法都要有这些原则作保障：企业的股东要配合独立自主的开发团队工作；团队要有面对面地沟通甚至是争论；这些沟通和争论必须要围绕软件设计，测试以及重聚焦。笔者认为重聚焦是团队工作的有效工具，最低也可以提高工作准确率，缩短工期。

敏捷的提出以及其优势的体现，并不是偶然形成的，IT业的各种软件项目的失败、成本超支以及与其相伴的企业对传统IT设计和开发方法的低满意度是的敏捷开发倍受关注的重要原因。

在传统的软件开发程序下，流程由所有的的开发步骤和流程堆砌而成，需求分析、设计、实施、测试、整合、维护……而敏捷开发对这种"堆砌"的思想做了改变，正如我们上面说的敏捷属性--把不同的事情交给了不同人，项目所有步骤都是要根据项目的特点而设立，而非一成不变。

非敏捷开发项目的十个典型表现

眼下，有许多企业声称自己正在采用敏捷开发的方法。但是，笔者认为，叫得越凶越有可能没有采用敏捷的方法。以下是没有采用敏捷开发的十个典型表现，如果你的项目和下面吻合，那么，毫无疑问你的项目还没有采用敏捷开发。

1.在沟通时，"发送"和"接收"是正确的，但是没有被"存储"，以致需要再次沟通；

2.项目团队所使用的白色演示板始终是空白的；

3.作为项目经理，虽然项目已经花费近一半的时间，你还在怀疑，且还在测试你的团队；

4.作为项目经理，你始终搞不清企业股东对团队的影响；

5.你了解关键路径法（CMP），也知道它的用处以及如何使用，但基本上所有与项目有关的决策都以它为基础；

6.作为项目经理，你花费了很多的时间去管理项目的一些从属事宜，而不是交给其他人；

7.团队人员工作依然依赖于甘道图（英文：Gant Chart，谐音：Can't Chart）；

8.团队人员工作无联系，开发人员只是开发，测试人员只是测试，管理人员只是管理；

9.项目流程简化被认为是简单的工作；

10.常常参加一些不必要的会议，比如要更换一个项目控制演示版。

敏捷 打一记混合开发的组合拳

敏捷开发明显优于传统的软件开发，但是，如果企业可以采用一种以上的方法，效果会更好。因此，敏捷开发的方法并没有统一的模式，企业要按照自己的方式去实施敏捷开发。

目前世界上IT企业使用较普遍的方法有：Scrum, Crystal, Adaptive, Feature-Driven Development 以及Dynamic Systems Development Method (D

[1] [2] 下一页