这是敏捷开发般若敏捷系列的第四篇。(之一,之二,之三,之四,之五,之六,之七,之八,之九)
敏捷开发中有几个地方相当创新,或者说尽管之前的方法中可能也有涉及,但却从来没有像敏捷开发这样提升为“根本大法”来对待。
一个是“拥抱客户价值,拥抱变化”,一个是TDD/结对编程/自动化测试为代表的开发与测试的融合,一个是“团队协作/结对编程/共同估算/代码共同所有制等自组织团队实践”,还有一个则是认为协作重于流程,沟通胜于文档。
传统开发的困局
在敏捷开发之前,尽管没有成文的说法,但客户与开发人员整体是个博弈的关系,双方要小心谨慎相处。比如需求要签字确认才能开发,计划要提前敲定并监督完成;而变更要走严格的变更流程……
开发人员与测试人员也基本上是两类人,有一个经典的考核方法足以让这两类人水火不容:“测试人员每发现一个Bug,开发人员扣N元,测试人员得N元”,这个对立的,零和的考核方法让这两个团队不可能坐在一起,讨论如何共同提高绩效。
传统的考核往往是考核个人,因而常常出现忙的忙死闲的闲死,键盘之声相闻,老死不相往来,一人离职,全队泡汤的情景;而敏捷开发倡导整个团队一起工作,以集体智慧共同解决问题,并以此获得生产力的提升。
敏捷破局
敏捷开发的这种破局,本人并不认为是对整个管理作出深刻反思的结果,相反是忽略一切没用的制度,全心全意“逐利”的自然结果。
需求开发和变更过程,无非是想通过向客户交付价值获得回报;开发或测试无非是想提高产品质量;考核无非是想提高生产率。
繁杂的文档让客户迟迟不敢签字,或把宝贵的时间精力花费在评估和抵制客户的变更上,并不能获得回报;开发人员与测试人员的博弈,无非是最终让开发人员开发出测试人员测试不出来的Bug留给客户发现;而针对个人的考核,反而导致实际团队总生产率的下降。
敏捷开发团队发现,若能突破我们(就是开发人员,敏捷开发的发明者),测试人员,开发/测试团队,乃至突破企业/客户的界限,将大家的利益统一考虑,效果不可思量。
这也就能看出为何敏捷开发认为协作胜于流程,沟通胜于文档。
流程与文档的很大目的,就是在于跨人/跨部门工作的时候,交接完整,责任明晰。
而协作与沟通则抛弃了交接、责任这些“多余的中间产物”,令责任始终同时处于大家一起负担的状态。
无我,无人,无众生
所谓无我,就是不能执着地认为自己的利益和绩效是要独立考虑的,可以独自提升。
所谓无人,就是不能把别人的利益与自己对立起来,而是要统一考虑统一提高。
所谓无众生,就是不能执着地考虑小团队的利益,也要不断扩展团队的概念;为谁考虑,谁就会积极回应,而大家的利益就可能共同提高。
这三者的基础是先要做到无我,所以这里把淡化自己、其他团队成员、团队乃至客户之间界限,将其共同利益作为出发点的心法,通称为无我。
这种无我不是形式上的,比如某些敏捷开发的程序员口口声声为客户价值负责,却不能为测试人员、产品经理的利益负责,就是只学到形式上的无我。
回报与不执着于回报
无我与不考虑自己的利益是两码事,而是说若能综合考虑全体的利益,自己的利益才能得到根本保证。
但若考虑全体的利益时,执着于自身得到回报,则是另一种我执(即执着于我)。
下一篇,还将谈到回报与不执着于回报间的辩证,尤其是那些“在本公司都无法得到回报”的情况。
点击下载免费的敏捷开发教材:《火星人敏捷开发手册》
如果觉得《敏捷开发般若敏捷系列之四:如何推广敏捷(上)(无我 无人 无众生)》对你有帮助,请点赞、收藏,并留下你的观点哦!