冬哥追乐夏 - 从后海大鲨鱼为何加入,谈敏捷项目试点 | IDCF

关于后海大鲨鱼加入乐队的夏天

去年夏天，是《乐队的夏天》。
冬哥喜欢摇滚乐队，打小就喜欢，所以乐夏第二季来了，冬哥一定会追。记得彭磊在夏日终曲那首歌结束时说，曾经邀请后海大鲨鱼的老曹客串吉他手，后者说打死也不会来。但是乐队的夏天第二季，后海大鲨鱼自己主动来了。小组PK赛刚进行了一场，还没轮到后海大鲨鱼这组。下轮到他们上场，势必会被问到这个问题。我猜测其答案，大概超不出以下几点：看到了节目组的专业性、真诚，并非一档单纯的娱乐节目，能够看到节目组对乐队的尊重，希望可以让乐队的夏天真正的来到，自己也能够参与助力。据说乐夏1结束后，收到了近1000支乐队报名，而首季节目组可是一个个打电话邀约。从0到1，永远是最难的，因为会有各种质疑，会有各种傲娇和骄傲，会担心翻车，会放不下摇滚乐队的坚持和矜持。有了第一季的打底，有痛仰、面孔、新裤子、旅行团、刺猬这样的老炮，有盘尼西林、九连真人、Click 15、斯斯与帆这样的新人，风格囊括了朋克、金属、FUNK、民谣、雷鬼、摇滚、电子。再没有一个乐队会傲娇地说，乐队的夏天与我无关；有了第一季的台阶，就更容易放下身段，去参与到一个略带比赛的娱乐节目中，毕竟痛仰、面孔这样接近30年的乐队老大哥都可以参与并乐在其中。所以，第二季来了很多重量级乐队，包括后海大鲨鱼。我想说，这就是榜样的力量。万事开头难，所以需要打个样板，所以需要榜样的力量。一旦成功达成从0到1的突破，从1到3的过程就会水到渠成，就会吸引到更多重量级乐队的目光。（当然也会有人来搭顺风车，所以讨论评委对水木年华的评价是否尖刻其实没有意义，毕竟这帮号称摇滚乐评委也要标榜自己的态度，最大的问题在于节目组。）在敏捷和DevOps转型中选择试点项目，也是一样一样的。

敏捷与DevOps如何选择试点项目

Small Win，积小胜为大胜，是敏捷和DevOps的行动指南，同样也适用于试点项目的选择。
敏捷试点与成功推广之间，存在着一道鸿沟，所以如何选取试点团队并保证成功，并且对未来的项目推广的影响，对敏捷转型而言至关重要。

影响试点项目选择的四个关键要素

Mike Cohn曾提出影响试点项目选择的四个关键要素。“不是每个项目都合适成为试点的。理想的试点项目需要综合项目大小、项目持续时间、项目重要性以及业务发起人的参与度。”

• 持续时间 — 小项目会让人怀疑敏捷只对小项目有用。如果项目过大，那么大家又将不得不等待很长时间才能评估实施的情况。Mike 建议理想的项目周期应该接近中值，也就是公司所有项目程序时间的平均值左右。
• 大小—试点项目应该小到只需要一个团队就能完成。这样就没有了多团队和跨越沟通的问题了，这也就让团队能更加关注到敏捷过程中去。
• 重要性—试点项目得是对公司很关键的。这会刺激团队很好地使用流程进行工作，从而确保项目的成功。一个不是很重要，风险也不高的项目通常只会变成演习项目。因此，试点要选择那些在企业业务的主航道上的项目。但是，不要选择那些最关键的项目，比如对企业生死攸关的项目、处于救火状态的项目，因为抛开敏捷转型因素不谈，一旦这些项目自身运作有了问题，大家会怀疑“是敏捷的错”。所以，要选择那些在企业的主航道上的中等重要程度的项目。
• 业务发起人的参与—高度参与的业务发起人能帮助团队在需要的时候去推动特定的业务流程、部门或者个人。业务发起人的参与时间和精力对项目的成功非常关键。很多企业的高管担心敏捷转型会影响项目的进度，因此喜欢选择那些内部产品，原因是内部产品的进度可松可紧，没有外部客户和市场的压力；或者倾向于选择那些不在公司的主航道上的项目，原因是如果这些项目失败或延期，对公司的核心业务没有影响。但是，在这样的项目里即使试点成功，对公司的主航道项目人员也没有说服力，因为大家会觉得这些项目不重要，他们有闲功夫来尝试，而我们没有时间。

微服务的四个特征

试点团队的选择，也可以参考微服务小独轻松的四个特征。

• 小：Small services；粒度小，且专注一件事情；由2-Pizza团队端到端负责1个或1组服务，大小是合适的；
• 独：Own process，单独的进程；
• 轻：Light weight mechanisms，轻量级通信机制；
• 松：Independently deployable，松耦合，可独立编译（无二进制接口依赖），独立部署（无部署顺序依赖），独立运行（无启动顺序依赖）。

每个微服务相对独立且松耦合，对其他团队较少依赖；能够完成一个端到端的服务，对于业务价值的衡量就尤为重要；较小的服务，以及团队规模，更容易在内部松土并尽快达成思想一致。

选择试点还需要考虑啥？

除了Mike Cohn的模型里提到的因素以外，还需要考虑以下因素：

• 团队最好坐在一起：尽量不要选择那些团队分布在不同的地区甚至国家的项目，除非这种分布式团队是企业的主流团队。
• 最好选择那些新产品开发的项目，而不是维护类型的项目：维护类型的项目往往不能够引入太多的变化，比如：你无法用敏捷的方式实践新的Idea从诞生到上线的整个过程。此外，一般来说，维护类型的项目遗留代码的包袱比较重，在遗留代码上尝试敏捷工程实践尤为困难。
• 纯软件项目优先：如果企业有软件、硬件集成的项目，要先选择纯软件项目来试点，试点见效后再考虑将硬件项目试点。虽然有很多报道、案例证实敏捷完全可以应用在硬件项目中，本人也做过硬件项目的敏捷辅导，但是，相对来说，软件的本质决定了软件项目更加适合敏捷，也更容易让企业看到变化。

再聊聊《乐队的夏天 2》中的那些新生代

除了重磅乐队，乐夏2出现了一票新晋乐队，例如Mandarin、福禄寿、傻白。
Mandarin和福禄寿顺利晋级，傻白遗憾被淘汰，但我相信傻白大概率会被捞回来，即便不是，也已经让我们记住了这个名字。这帮新生代实力满满，新意十足，不可小视，更重要的是，他们Nothing to lose。传统项目或者系统的转型，会有太多的历史包袱，不求有功但求无过的心态，是不适合做试点的，就像求稳的乐队注定走不长一样。新的项目，尤其是创新类项目，天生适合敏捷，因为创新就需要快速探索、快速试错，就需要小步快跑而不是大河东流浪淘尽时间和金钱。那么创新类项目，是否适合选取做试点项目呢？并非最佳选择。目的要单纯，创新类项目的目的是业务探索，不要把敏捷试点与业务试错掺杂在一起。创新就意味着大概率会失败，而试点项目的失败是难以接受，并且存在政治意义的。这会让原本应该及时止损终止项目的决策，因为考虑到试点项目的成败，而变得犹豫举棋不定。这不仅与创新探索的初衷相违背，同时也让敏捷试点失去了意义。

结语

总结下来，试点就是要找典型，即典型的团队规模大小，典型的项目周期时间，业务价值具备树典型（打样板）意义，天时地利人和兼备。
从0到1的试点，也不要贪心，每次只尝试少量必要的实践；从1到3将动作进行固化，并适应不同的团队和项目，并且适度对尝试的实践加以扩展。乐夏到第三季除了收割以外，一定会求变，大众的口味很容易审美疲劳。试点项目从3到N的过程，精化、深化和差异化是重点，一方面是要扩量，另一方面是要玩出新意，到那个时候，也许就是另一个维度的从0到1的过程，正如创新的第二条S曲线。乐夏2中，采访水木年华，问起来最近为何没有音讯，卢自嘲是因为过气了，而自己在搞电影另一位在搞助农。那么请问，为何李健没有过气？永远不要满足现状，持续去追寻新的增长曲线，做乐队如此，做试点和转型也是同样。参考材料

• https://www.infoq.cn/article/2009/11/pilot-project-agile-adoption
• 《敏捷转型-打造VUCA时代的高效能组织》王明兰

本周六11：00，【冬哥有话说】第21期，邀请到“硅谷大舅”谷歌总部资深产品经理/谷歌全球仅约50位中国人产品经理之一 BigJoe一起聊聊硅谷的产品经理。【福利】识别下图二维码，回复“硅谷大舅”进入课程，按照提示进行课程注册即可获得听课信息（先领券0元购买）