关于敏捷

1、我和敏捷的渊源

第一次听到敏捷这个概念，是六年前，加入一家只有3个半程序员的创业初期公司。

老板给我发了两本电子书，一本叫《精益创业》，另一本关于敏捷的，名字不记得了，因为我只看了第一本。

书看了一半，只觉得气血翻涌，就裸辞去赶那波万众创业的浪潮了，浪没赶上，就被拍在了沙滩上，狠狠的摩擦。

真正对敏捷提起兴趣，是加入现在的公司以后，老板任命我作为团队的敏捷负责人。

2、先讲讲历史

我想故事要从一道“瀑布”说起，很久很久以前，有个傲来国，傲来国里有一座花果山，花果山前啊，有一道瀑布。

跑题了，我们故事里的“瀑布”，是指传统的软件开发流程，我们称为“瀑布模型”。它形象的描述了从系统需求分析，到原型设计、产品开发、测试（单元测试、集成测试、用户验收测试）、发布、维护的一整套流程。

“瀑布”模型自有其优势，但也有局限性，这主要与其本身的特点有关：

• 需求：需要明确的需求范围和实施方案，需求分析时需要对业务和系统有较深刻的理解，对BA有较高的要求。
• 工期：时间上串行，一个阶段的工期延误，连锁反应式的影响此后的环节，“瀑布”项目要做到按时交付，对PM有较大挑战。
• 文档：为了管理一个瀑布项目，每个环节需要产出大量的文档。我想是因为从立项到结项，往往经历半年甚至更多时间，在中间过程中除了文档，是没有其他可交付物的。作为甲方或者监理方，甚至乙方自身的管理者，想要控制风险，就不得不依赖于过程文档了。至于文档有多少？呵呵，我做监理的时候，一个300万的信息系统开发项目，各类文档一式三份打印装订出来，能堆半人高。
• 变更：另一个作为瀑布项目难于管理的点在于，变更管理。项目开发时间跨度长，中间需求方可能连负责人都变了几波了，需求难免发生变化。开发好的功能模块，突然被掀翻重来，有时甚至给你底层框架彻底颠覆。见过很多计划开发半年交付，最后2年还没结到尾款的烂尾项目，大多也是因为这个原因。

3、为什么敏捷？

痛数了瀑布的弊端后，为什么要敏捷，也就显而易见了。因为瀑布太“痛”了，敏捷恰好是“止痛药”。

先来看下敏捷宣言：

• 个体和互动 高于 流程和工具
• 工作的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划

敏捷的12条原则：

• 1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

• 2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

• 3、经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

• 4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。

• 5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

• 6、不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

• 7、可工作的软件是进度的首要度量标准。

• 8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

• 9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

• 10、以简洁为本，它是极力减少不必要工作量的艺术。

• 11、最好的架构、需求和设计出自自组织团队。

• 12、团队定期地反思如何能提高成效，并依此调整自身的举止表现。

光是看看就觉得优秀，且大为赞同和认可，不是吗？

是的，正如大多数公司的领导们一样，几乎在听到敏捷这两个字的时候，就兴奋不已了。

毕竟真的懂敏捷的领导少，但是扯嗓子喊“怎么实现我不管，反正明天我就要上线”的“敏捷”型甲方领导哪哪都有。

4、敏捷，不止于快

但是，敏捷，不止于“快”。而且单单的快，也不一定是”敏捷”。

敏捷强调的一点是“价值导向”。

后互联网时代，时间就是商机。

人力有限的前提下，哪些需求优先级更高，哪些功能必须在当前版本迭代上线，哪些只是在“镀金”？

尤其是在产品的第一个版本，要追求MVP（minimum viable product，最小化可行产品），更快的触达用户，获取反馈。

敏捷“拥抱变化”。

互联网运营的打法，可谓日新月异，有多少需求做着做着，就发现市场上行不通。

是坚持把半成品做完（即便它没有市场价值，但为保持该版本需求范围稳定，下一版本再改）？还是及时调头。

我的理解是，如果团队认可这个变化是必须的，那么立刻调头，考虑沉没成本是愚蠢的决定。

当然，如果你不太确定现在快做完的A方案，还是想要改变的B方案哪种更适合，想看市场反馈再做决定，不妨继续把A方案做完，用灰度发布的方式，去收集市场的反馈。再做决定。

敏捷追求“小步快跑”

比起瀑布模式下的大版本形式，敏捷更提倡“小步快跑”，持续的交付可工作的软件。

我们目前团队以2周为一个常规的版本周期，在这个固定时长的时间盒内，按需求池（产品经理维护Backlog）中的需求价值排序，评估需求人力，根据版本容量决定版本内将哪些需求列入开发池中。

在有条件的团队里，PO角色一般由BA或者产品经理担当，和开发团队紧密结合在一起。这样可以确保目标一致，开发团队认同在开发需求的业务价值。

我经历过太多“失败的”项目，规划了很多大而全的功能，却一直不动手去做。总想着尽善尽美以后再动手实践，最后错过了时机，项目中途不了了之，不成熟的idea胎死腹中。

敏捷强调的”小步快跑“，用框定的时间盒和人力池，来反向框定需求范围，确保在时间盒结束时，有一个可交付的可工作的产出物。快速验证，及时反馈调整。

敏捷讲究团队自驱动、自组织

踩一脚滚两圈的单车，和自带小马达的电驴，谁能跑的更快，不言而喻。

给团队一个愿景，提供必要的环境和支持，辅以信任，让他们自己朝着愿景去前行，远比传统的极端管理模式下，统计开发提交的代码量，统计测试发现bug数来考核工作量要有效的多。

见过很多团队，前两年很“能打”硬仗，打着打着，队伍就打没了。除了该走的没走，不该走的全走了。其实无非就是人心散了，队伍不好带了。

程序员是一群有理想的活生生的人，而不是冷冰冰的开发工具。走上程序员这条路的，多半还是有些Coding改变世界的理想主义情怀的。

见过一些外行管理内行的女老板（申明：不是针对女性，只是遇到的几位反面案例恰好都是女老板而已），明明对开发流程一窍不通，却控制欲极强，对量化管理拥有着无法想象的执念。制定了一系列的量化指标来考核开发的工作量，其中不乏看似可笑的加班时长、代码量、bug数等。甚至还有要求穿正装上班，不得穿拖鞋，早晚打卡，加班免费但迟到扣钱等严重让程序员”心态崩掉“的制度。就当我开个玩笑，不要对号入座。

我的理解是，必须让业务和开发拧在一起，目标一致。有的公司组织架构上把业务和开发独立成两个事业部，如果各自有不同的考核标准，那么很难做到开发团队自驱动。

敏捷中提到的”业务人员和开发人员必须相互合作，项目中的每一天都不例外。“，以及”不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。“其实也暗示我们，在公司组织架构设计的时候，最好把业务和开发捆绑在一起；在职场规划工位的时候，也尽量安排在同一片区域。

敏捷不要求繁琐的文档

就像今年疫情期间宣导的”把论文写在祖国大地上“一样，我理解的敏捷，是把文档在写可工作的交付产品上（并不能理解为完全不需要文档，必要的文档留存，我觉的也有助于沉淀和提升）。

如果在一块白板上就能画出原型，何必让产品经理再转成PRD文档？甚至在我理想的“约定大于配置”的状态下，团队思维模式就应该是一体的，有一种默契，你不用多说，但是我都懂。太理想了，当我没说，但是我曾有幸在这样的团队工作过。

如果产品交互足够人性化，有清晰的指引和所见即所得，何必一定要写用户手册？你可没见过微信有300页纸的使用说明书吧。

…

敏捷要求团队自组织，自提升

战者，靠将还是靠兵？自古有争论。

“兵熊熊一个，将熊熊一窝。将帅无能，累死三军。”所以将更重要；

“有制之兵，无能之将，不可败也；无制之兵，有能之将，不可胜也。”所以兵更重要。

我的理解是，软件开发的仗要打赢，将和兵各司其职，各自做好该做的事。将帅掌舵把握好方向，如果方向都不对，越努力离目标越远；士兵重执行，攻一城下一城，攻一国下一国。

我见过一个管理700号人团队的团队长亲自在前线指挥大家如何执行，亲自带着大家一起加班997的，一年后这个团队被连打带消的解散了。我的理解是部门长的作用主要是规划方向、协调资源和向上管理。但绝对不包含指导一线产品经理如何写PRD，程序员如何写代码，测试如何跑用例。

放权，让一线的兵自己决定仗该怎么打。你就告诉他你想打下那座城（描绘愿景），你提供登墙梯、迫击炮（协调资源），只有深入战场一线的人更知道战场上突发情况该如何应对。

好的团队与项目是相辅相成，互相成就的。一个成功的项目离不开一个英雄的团队。

我最喜欢的动漫是《七龙珠》，最佩服悟空的不是他的屡战屡胜，而是他的屡败屡战，越战越强。同一个招式是不会打败他两次的。

好的团队也是如此，随着产品的迭代而不断的自我提升。

实践中，每1-2个版本迭代的最后，会开一次敏捷回顾会，吸取经验，反思教训。只要不掉在同一个坑里两次，那么这个坑就踩的值。