[若有所悟]传统与敏捷的结合

    今年，从一个很正规的项目到一个敏捷管理的项目，严格来说，不完全是敏捷项目，只是项目的负责人有着敏捷的血统，所以难免在一个传统的项目里，掺杂了自己敏捷的思想方法。刚开始进入类敏捷项目，看什么都不顺眼。文档呢？流程呢？这么明显的现象，领导一定看在眼里，为什么没有责难发飙呢？这一定是有缘由的，开始我还不知道这就是敏捷管理，于是决心观察领导的每一个管理细节，以下是一点心得。

    ■安抚敏捷项目里的强驴

      如果要敏捷管理，项目组里的人最好要么是新人，要么是高明的高手。新人是一张白纸，他不会有抵触心理，他觉得这是理所应当；而高手，有超强的个人管理能力，有超强的编码能力，条条框框反而会限制发挥。但是，如果敏捷项目组里有从传统项目组里出来的人，他会对敏捷项目做一大番批评，这里不好，那里不规范。我也这样过，毕竟要看透一个项目的管理手段，需要一点时间。所以，对实行敏捷管理的项目来说，切记要安抚每一个从传统项目出来的人，这类人可能会自以为有一套完整的管理体系，但是这些体系往往与敏捷是背驰的，安抚好这些强驴，灌输你的敏捷思想，是不可或缺的工作内容。

    ■敏捷不等于没有规范

      敏捷也需要规范。毕竟不是所有的项目都是由一群大牛组成的，身经百战自然对于任何规范都能瞬间接收，而项目里如果有新人，没有规范的话，就会似黄河泛滥，一发不可收拾。敏捷建立在信任的基础上，但是你敢去相信初出茅庐的新人写的代码吗？不可能的。所以规范的约束好比河道，如果说带有大量文档，大量规范的河道是钢筋混凝土筑构而成。那么敏捷里的规范就是轻掘黄沙，引流而已。

    ■弱队需要强头

      项目里如果很多新人，那就需要一个十分强大的头，这个头能以一己之力承担大部分的需求理解，新人在不理解需求的时候，找到头咨询，并且快速获得回答。这样才能发挥敏捷的力量，而如果没有这么一个强大的头，大部分的需求疑问都需要找到客户确认，那开发速度将会大幅下降。对于一般的项目，如果对技术力要求不大，管理者可以从编码中脱身，全力去理解需求。这样的敏捷固然快速，但是也是十分有风险的，一旦头牺牲了，项目将会陷入不可挽救的地步。所以，这种敏捷会把一个人一直困在项目里，如果项目周期短，还能承受。如果项目周期长，随着时间的推移，人的记忆会遗忘，没有文档的佐证，项目也会陷入停滞。

    ■敏捷与传统的结合

      其实对于多数项目，最佳的方案是敏捷与传统的结合。重量级的传统开发过程细致到每一个细节，而敏捷又对人的依赖很大，对于质量要求比较高的项目，最佳的组合应该是传统项目的开发过程与敏捷的快速之间的结合，至于如何实施，当然要求管理人员熟悉敏捷与重量级开发过程之间的异与同。

转载于:https://www.cnblogs.com/alephsoul-alephsoul/archive/2013/03/29/2989355.html