关于敏捷

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个版本迭代的最后,会开一次敏捷回顾会,吸取经验,反思教训。只要不掉在同一个坑里两次,那么这个坑就踩的值。