敏捷开发般若敏捷系列之四：如何推广敏捷（上）（无我，无人，无众生）

这是敏捷开发般若敏捷系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）

敏捷开发中有几个地方相当创新，或者说尽管之前的方法中可能也有涉及，但却从来没有像敏捷开发这样提升为“根本大法”来对待。

一个是“拥抱客户价值，拥抱变化”，一个是TDD/结对编程/自动化测试为代表的开发与测试的融合，一个是“团队协作/结对编程/共同估算/代码共同所有制等自组织团队实践”，还有一个则是认为协作重于流程，沟通胜于文档。

传统开发的困局

在敏捷开发之前，尽管没有成文的说法，但客户与开发人员整体是个博弈的关系，双方要小心谨慎相处。比如需求要签字确认才能开发，计划要提前敲定并监督完成；而变更要走严格的变更流程……

开发人员与测试人员也基本上是两类人，有一个经典的考核方法足以让这两类人水火不容：“测试人员每发现一个Bug，开发人员扣N元，测试人员得N元”，这个对立的，零和的考核方法让这两个团队不可能坐在一起，讨论如何共同提高绩效。

传统的考核往往是考核个人，因而常常出现忙的忙死闲的闲死，键盘之声相闻，老死不相往来，一人离职，全队泡汤的情景；而敏捷开发倡导整个团队一起工作，以集体智慧共同解决问题，并以此获得生产力的提升。

敏捷破局

敏捷开发的这种破局，本人并不认为是对整个管理作出深刻反思的结果，相反是忽略一切没用的制度，全心全意“逐利”的自然结果。

需求开发和变更过程，无非是想通过向客户交付价值获得回报；开发或测试无非是想提高产品质量；考核无非是想提高生产率。

繁杂的文档让客户迟迟不敢签字，或把宝贵的时间精力花费在评估和抵制客户的变更上，并不能获得回报；开发人员与测试人员的博弈，无非是最终让开发人员开发出测试人员测试不出来的Bug留给客户发现；而针对个人的考核，反而导致实际团队总生产率的下降。

敏捷开发团队发现，若能突破我们（就是开发人员，敏捷开发的发明者），测试人员，开发/测试团队，乃至突破企业/客户的界限，将大家的利益统一考虑，效果不可思量。

这也就能看出为何敏捷开发认为协作胜于流程，沟通胜于文档。

流程与文档的很大目的，就是在于跨人/跨部门工作的时候，交接完整，责任明晰。

而协作与沟通则抛弃了交接、责任这些“多余的中间产物”，令责任始终同时处于大家一起负担的状态。

无我，无人，无众生

所谓无我，就是不能执着地认为自己的利益和绩效是要独立考虑的，可以独自提升。

所谓无人，就是不能把别人的利益与自己对立起来，而是要统一考虑统一提高。

所谓无众生，就是不能执着地考虑小团队的利益，也要不断扩展团队的概念；为谁考虑，谁就会积极回应，而大家的利益就可能共同提高。

这三者的基础是先要做到无我，所以这里把淡化自己、其他团队成员、团队乃至客户之间界限，将其共同利益作为出发点的心法，通称为无我。

这种无我不是形式上的，比如某些敏捷开发的程序员口口声声为客户价值负责，却不能为测试人员、产品经理的利益负责，就是只学到形式上的无我。

回报与不执着于回报

无我与不考虑自己的利益是两码事，而是说若能综合考虑全体的利益，自己的利益才能得到根本保证。

但若考虑全体的利益时，执着于自身得到回报，则是另一种我执（即执着于我）。

下一篇，还将谈到回报与不执着于回报间的辩证，尤其是那些“在本公司都无法得到回报”的情况。

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》

转载于:https://www.cnblogs.com/JPAORM/archive/2011/11/18/2510399.html