主题：【原创】闲聊敏捷开发——SCRUM（一） -- 哈酷

不考虑需求变更的时候，用传统方式往往有更高的效率（不要讨论文档，测试那些问题）。 在非agile项目里，我们接到一个任务一般是这样做。

1.招募一个核心牛人，以其为核心组建团队

2.牛人对任务进行分解，自己承担核心部分， 再把其他边角料分散给食物链各级人员。

这个模式的开发效率往往都比较高，只要找对了核心人员，就基本上成功了。

但是问题也很突出

1. 高风险性，牛人变成truck number。一旦闪失，整个项目就完蛋。

（虽然有cmm，有各种重过程各种文档，但是几十年下来大家还是发现，传统模型基本还是这个调子，那些文档和过程装饰性作用比较多）

这点对小公司可能无所谓，对大公司就是个大问题。大公司运营，关键考虑的是风险。当年我在某家公司做agile的时候，老板最满意的不是生产率，而是我解决了人员流动的风险。

2. 食物链低层人士得不得足够的成长机会，时间久了，流失难免。

项目经理只会考虑进度和质量，工作安排上只能尽可能考虑效率，不会太关心个人成长。

3. 牛人不的不长期担任核心工作，压力大，和团队人员梳理感也重，资历越老，加班时间和压力也更相应增加，过了一定年纪考虑再考虑家庭原因，很难长时间持续。再考虑到项目需求不断变更带来的压力，也往往就意味着更多的加班，更多的压力。

这种模式下，虽然有少数食物链底层可以凭自己能力出头，但是也基本摆脱不了做牛人的命运。我认识很多技术强人过了30就转行，主要不是钱的问题，还是做下去已经没有什么乐趣了。

但是要说生产率，那还真是不错，当年我年轻的时候高峰期一天要写2k代码，而且错误率很低。

现在做agile就不一样了。团队里理论上是没有金字塔结构的，人人平等， 一个任务接下来，如果你还按这种模式做，其他菜鸟就不干了，每次回顾的时候就会说，没学到东西，老板也会找你谈话。所以架构也要做，任务也要分解，但是这个过程中，你必须考虑到所有人的参与感。以前做设计，2个人核心人员讨论完了就完了，再另外找个人核心人员评审，这就算完了。现在不同，团队里所有人都要参与讨论，不懂得地方你还要耐心解释。设计弄完，开发的时候也是代码共同所有，谁都可以改，谁找你要求解释，你也必须回应。这么下来，效率怎么可能高？

但是回头来说， 其他人的成长机会就多了。 长期看，效率问题可以有所缓解，更重要的是项目风险降低了，因为责任不再由单纯的1，2个人承担了。另外这个过程中，因为交流沟通比较频繁，所以团队人员之间的关系会比较流畅，工作气氛也会比较好。比如自己年轻的时候，总是一个人带着耳机干活，现在基本上都和一些小孩子做pp，一天有说有笑的就过了。

而且这个过程，加班是不ok的，老板不能因为项目进度要求你加班。你说这么玩法，程序员能不喜欢么。所以现在搞agile的，叫的最欢的就是一些大公司。