敏捷不能当饭吃

喜欢敏捷的很多想法，喜欢它务实的态度。我说“敏捷不能当饭吃”，当然不是说敏捷无用，相反，我倒是挺推崇敏捷的。之前有两篇文字都涉及到一些对敏捷的看法。一篇是 与神对话 ，另一篇是 对敏捷的一些想法 。只是看到很多人好像敏捷是他爷爷写的一样，龟孙子似地迷信和追捧敏捷，把工作一条一条跟书上描述的对照，一旦工作中实际操作跟书上有不一致，口诛笔伐，吐沫拳头无影腿就一齐上来了，那就太过了。敏捷跟太极拳一样，是一种思想精髓，它的一招一式体现在实际工作中灵活运用敏捷原则，敏捷并无特定套路。Scrum等流程是敏捷的一种成功案例，这个案例在特定环境下工作得非常好，但那只是特定环境而已。敏捷大师们自己也总提醒，很多项目采用敏捷开发，仍然一塌糊涂，是因为应用敏捷并不简单。

Kent Beck是敏捷的发起者之一，很多敏捷的发起者后来都写了关于敏捷的书，但Kent Beck的书是最有影响力的，它的Extreme programming explained – embrace change可以在这篇博客 中找到。这本书主要阐述敏捷的一系列理念，对实践描述的并不具体。scrum之类讲敏捷流程的书，对实践操作的环节就会讲的很具体。先了解并接受敏捷的理念，再去看敏捷流程的话，比较容易理解流程背后的用意是什么 ，只有深刻理解了敏捷精神，才能比较好的实践敏捷。而现实情况很多时候不是这样，直接学习流程总是比较省事儿，于是scrum就被当成圣经直接拿来就用了，人家mc hotdog早就说过，“照单全收的盲从，就像在吃屎”。我相信通常情况下，scrum的实践在一个项目组，只有一小部分能用得上，当然，这已经是件很伟大的事情了。在一些常见的工作环境中，有些scrum的想法并不适用。

一个方面是，scrum强调“全功能团队”，每个人了解产品的每一个feature；团队人数在敏捷中是有限制的。但如果一个负责某个产品的团队就是有12，3个人，那么怎么办？ 再拆成两个敏捷团队以适应敏捷对人数的要求？垂直划分feature提供了细化团队的机会，但产品不总能清晰地一刀切成两半，尤其还要考虑各个程序员有不同的专长，甚至根本用的不是同一种编程语言，如果团队只有一个c程序员，一个js程序员，一个pl/sql程序员，其他做java，那么切分项目组的方式是跟c有关的一组，跟js有关的另一组？底层架构和公共模块都不容易竖切。如果产品比较大并且不易细分，大家都了解每个feature是很难做到的。如果产品使用的技术比较繁杂，pl/sql, js, java, c样样都用，全功能团队怎么实现？js的程序员跟c程序员也讲不到一块儿去啊。我可以理解scrum的想法，也认同它的道理，但是在实际工作中，如果确实人数对不上敏捷的要求，或者程序员的技术特长分散在不同层面，这很难照搬scrum的实践。人多开会费时间，效果又不好，鸡同鸭讲，各说各的。写c的人才不关心js有什么技术瓶颈呢。

还有，scrum想了个招儿，用打扑克的方式沟通需求和帮助定schedule。这是建立在全功能团队的基础上的，上面已经论述过了，如果产品比较大，程序员没法兼顾所有story，那成本太大了，打扑克也只能流于形式，尤其术业有专攻，唯一的c程序员的工作只有他自己估计才有意义。更实际的问题是，当你知道story具体需求的时候，还不足以估计出时间，程序员必须知道“怎么做”才能估出来比较靠谱的时间。很多时候需要做一些research的工作以及一点儿prototype才好估时间 ，在这样的情况下，你非逼我出张牌，我只能出“问号”。 有时候，虽然我不需要做prototype, 但我确实也不能在5分钟之内理清思路, 知道用什么approach更合理，那么我怎么办，告诉大家容我想想，等我一会儿？技术问题本来也不应该规定在5分钟之内出个计划，非逼我出计划倒也没问题，但是随后我就得重做计划。还有一个问题，大家一起打牌，A知道这工作十有八九落在B头上，A可能出于好心多估时间，B可能为了面子少估时间，这些人为因素如何排除掉？

敏捷强调单元测试，这肯定是没错的。问题是，各个团队之间容易开始攀比覆盖率，其实程序员心里都明白，覆盖率的欺骗性很强，单元测试的有效性更重要 。如果单元测试又没贡献于驱动开发，也没贡献于质量保证（简单的api，诸如getter/setter之类的api就是这样，不用测试驱动直接就知道怎么写了，写了手动测试一遍就知道写的没错，code以后也不可能改），那么就没必要写这种单元测试，写这种单元测试的唯一好处是，成本低，比较容易贡献覆盖率。麻烦在于，太多弱智这么说，咱们敏捷了，单元测试覆盖率应该向某某弱智team看齐，于是人在江湖，身不由己，开始对付覆盖率。好吧，scrum其实也没说具体百分比，这不是scrum的错。

我绝对不想抨击敏捷或者scrum，我觉得这都是很出色的想法。只是听了太多“这不是敏捷”这种话，是不是敏捷根本不重要，能优化流程，让工作更有效才重要 。我喜欢敏捷的地方在于，敏捷强调以人为本，尊重程序员的各种诉求。正视design不能一蹴而就的现实。承认长期计划不靠谱。强调优先级，决定优先级的时候从性价比的角度考虑。scrum的很多实践也很实用，比如backlog应该包含的内容等等不一一罗列。敏捷不是一门玄奥难懂的技术，不需要花钱找培训机构受教育。敏捷的出发点就是务实，用务实的态度拥抱敏捷就足够好。套用二八原则，scrum的实践在实际中也许只需要吸收20%，却能取得80%的效果，剩下那20%要靠基于敏捷精神的创造力。