敏捷反思之一: "车祸" - 操之过急,揠苗助长

image.png

最近一周犯了一个常见的错误,操之过急和揠苗助长。也与我一向宣导的原则相违背。在这里分享出来,一是引以为戒;二是帮助ScrumMaster们避免掉进相同的坑。

公司基于业务方面和技术层面考虑,决定启动一个新项目。

业务方面的目标: 通过这个项目把一个业务产品化,用于支持多个产品的某一个共同的关键业务,提升交付能力和减少重复工作。

技术方面的目标: 希望为公司的技术架构探索一个新的方向,微服务化,提升公司的架构水平;为其他团队提供一个有单元测试、一致代码规范、良好的工作过程实践的范例。

两个目标都达成方能算是真正的成功。

这个项目成立了一个Scrum团队,团队内部的人员要求由我担任ScrumMaster来引导他们。团队的成员之前已经在另一个团队与我有过一段时间的合作(这一点恰恰是我自己坑自己地方)。

正式启动之前,我都会帮助团队认识,什么是ScrumMaster,ScrumMaster不做什么,做什么。Scrum中的各项工作,是哪些角色的范围。让大家达成一致的认知:

  • ScrumMaster是没有权力的角色。
  • ScrumMaster不是保姆,什么都干。
  • 交付是团队的范围,不是ScrumMaster的。
  • 质量是团队的范围,不是ScrumMaster的。
  • 会议是团队的范围,不是ScrumMaster的。
    .....

为了限制强技术背景型ScrumMaster(我),不自觉的干涉团队,我给团队一个重要约定, 也是对自己的一个紧箍咒:

  • 团队有权决定做什么,ScrumMaster无权强迫与干预的团队决定。
  • ScrumMaster可以给出建议,团队决定是否采纳,甚至可以当场怼回ScrumMaster "你在胡说八道, 回去喝茶吧"。
  • ScrumMaster 承诺为项目过程中的一切技术实践问题提供帮助和培训和解决。
  • 如果团队采纳ScrumMaster的某项建议,ScrumMaster 必须负责兜底。
  • ScrumMaster 负责给团队提供一个安全的空间,挡住各种干扰。
  • 团队对项目的结果负责。

接下来便是和团队形成工作约定, 并且确保每一条都当场认可的。

团队达成如下工作约定

  1. PO 编写用户故事

  2. 团队编写验收标准,PO负责审核

  3. 用户故事满足DoR方可进入Sprint
    DoR:

    1. 故事粒度满足 INVEST, 可实现故事
    2. 故事已经拆解AC,并通过PO审核确认
    3. 必要时,附上原型图,设计图
  4. 团队交付必须满足 DoD
    DoD:

    1. 故事的每一个AC都必须已实现,并验证通过。开发人员为首要验证人员。
    2. 至少在API级别提供相应的测试用例代码
  5. Sprint 1的开始时间为下个星期一 (如果我记错,请纠正)

  6. Sprint 周期为两周,10个工作日。

  7. Stand Meeting 为每日上午 10:20

  8. 团队尝试采用物理白板来可视化状况

  9. 团队的速率(Velocity), 用 AC 数量进行度量

  10. 团队作为一个整体进行考核,不单独考核某个个体。团队需要的是内部合作,而不是内部竞争。

  11. 代码提交必须采用 Pull Request 方式, 测试代码是提交内容的重要部分之一。

  12. 提交的PR, 必须满足 ESLint 的检测,和测试用例的通过,方可合并。

陷阱之一:
约定是否能遵守,取决于成员的认知水平、能力、廉耻程度
不会的可以问、可以学,不明白的可以动手尝试。
但是对于面对一点困难就各种理由各种现实客观因素的,告诉你这"不可能" 那"做不到",又不愿承认自己做不到并不代表其他人也做不到,就属于廉耻问题了。
教练能解决认知、能力。解决不了廉耻问题,也不建议费力去解决。

团队的单一个体,有一些经验和技术,在公司中算不错,按照我的标准(我的标准较高),还达不到优秀的程度。但作为一个整体运作,却属于比较初级。

由于上面提到的,这个项目除了有交付的目标,还有技术实践的目标。
团队连微服务的本质都不甚了解,还只是浮于从网上获取的表面的认识。DDD, Bounded Context, Aggregate, Hexagonal Architecture 是什么鬼?

由于各方的这个项目有着过高的期望。作为ScrumMaster,太过于想要确保这个团队能成功,因此发出太多声音。

如何需求拆解成一个个独立的可交付故事,如何再从一个个独立的故事中,识别出完成整个完整的业务流程的最小化故事,如何继续从最小化故事中,识别出验收标准,并通过验收标准来指定Sprint规划。确保每个sprint都能交付完整流程的交付。

MVP

图片取自 Scrum中文网 资料库中的 玩转MVP不要错过这四个案例

PO比较nice, 按照引导调整做事方式,识别出Sprint1的最小完整流程的故事与验收标准。

团队也接受编写验收标准,一开始能写的多好不是最关键的,从零到壹已经是一个值得赞扬的进步,这也为马上要做的自动化验收标准测试提供了基础。


但是在技术实践方面

  • 开发团队对需求还是不够重视,还是以旧有的习惯,做到哪再理解到哪。
  • 领域模型都还没整理清楚,急于交付,就投入到细节实现。
  • 拿着个MVC框架就当是微服务。
  • 认为质量就是测试人员的事。
  • 单元测试属于不现实,甚至连接口级别的测试都不愿意写,认为这些都是属于测试人员该干的事情。
  • 对 Pull Request 的作用与价值和基本使用方法不愿去了解。
  • 压根不用考虑什么 Code Review。
.....

(注: 我发现许多人还不明白Pull Request为何在团队协作中非常重要、价值之大。既然如此,我也不打算免费教大家了,未来我会设计一个付费课程,专门解读 Pull Ruquest 的作用和价值,以及在工作如何用它来如虎添翼。)

作为ScrumMaster,应当引导团队自己去学会钓鱼,安安静静的喝茶,静待团队慢慢的改变。

我违背了这个原则,发现他们学不会钓鱼,操之过急,便直接给鱼他们。
人的差别在于认知高度的不同,当团队缺乏相应的高度,又不愿意不敢面对这一点的时候,直接建议他们该如何做,是没有效果的,并且会得到反弹。

幸好,我在一开始,给自己上了一个紧箍咒、保险:
我只能建议,不能强迫;团队可以决定不听,坚持自己的做法。
如果团队认为SM的一些做法,是给团队制造障碍,SM必须立刻停止。

尽管我一再强调,我只给建议,不是要求,更不是命令,不需要感到有压力,甚至可以不理会。对于不认同的,只需公开说,"我不认同", 便不会继续。

但随着我的建议越多,团队依然感到压力越大,却不敢公开表达 (勇气何在?)。正得益于上面的"保险",一周左右,终于反弹,不承认一开始的那些约定,理由:“不现实", "不可能"。

这便造成,操之过急,揠苗助长的想把团队提升一个level,违背团队意愿的"车祸"。

出现状况,作为SM

1. 主动向团队认错,改变做法。除非团队主动求助,否则,不再直接给任何建议与解决方案。

   严格遵守赋予团队的权力。团队甚至可以要求 SM 离开团队。

2. 允许并鼓励团队修订约定,把认为是障碍的约定项,统统删除。

   有意思的是,居然没有一个成员敢于在这个项目组里,说出要移除哪些约定项。
   好吧,既然PR是个无用的,拿掉,所有人直接push代码;
   API级别测试用不愿做,拿掉,反正我是不做任何要求;

   但是,有一点,只要大家没有把"团队写验收标准"这一条拿掉,我便强要求做 
   "自动化验收标准测试", 因为这个是我和测试人员做,不是开放团队做。

3. 同CTO与PO进行沟通,把情况说明,降低与平衡好期望。

  能MVC这把刀耍好就不错了,不要奢望一步到位的微服务。

4. 分离职责:交付的要求与期望,归PO承担,PO对交付结果负责;技术实践要求和指标,归CTO; SM不需要再承担交付于技术实践的要求,回归SM的领域,对过程负责,对团队愿意改进的部分提供支持。

  SM之所以操之过急的一个根源,也是因为SM承担的职责过多。

这也是团队发展的四个阶段中一个阶段,震荡期(或叫冲突期),实际上,也正是通过这个时期,才能形成真正的规范与行为。

团队的行为模式背后有一个严重的根源: 主要成员认为 Scrum 就是竞争,成员与成员之间的交付竞争,比谁产出多,产出最少的,有给干掉的风险。所以,怎么快怎么整。

这个问题一开始就存在,我问过他们,为何有这种理解,他们说他们以前经历的Scrum团队,就是竞争模式。 即使我一再强调我们要的是协作而不是竞争,甚至专门在工作约定中单独写明这一点,并承诺在公司层面确保这一点。依然没能很好的消除他们心里的担忧。

团队与团队之间,可以有竞争。但是,团队内部竞争,只会是灾难。

回顾:

1. SM可以引导团队的节奏,但不可以试图掌控团队的节奏。

2. SM尽量避免直接给鱼。

3. SM不要太过于想要为团队保驾护航。要根据团队的个性来定,团队作死,就看着他们死。

4. SM避免去过多承担团队的职责,过度保护。

5. SM要因人而异,对于认知层级低且固执的人,不要试图去改变他。

6. 知识与经验是有价的,主动免费提供,反而不受重视。

7. 牛不喝水,你按不下它的头。强按,当心牛角。

8. 保持更多的耐心,安心喝茶,静待花开。

9. SM也会犯错, 发现了,必须第一时间公开承认错误,并纠正。不要太在意面子,越追求面子,越容易被打脸。


下一步,我会以实践的经验,设计一个付费 Scrum的分解系列课程,帮助更多的人从零到入门,从原理到如何实际操作。

推荐阅读更多精彩内容

  • 敏捷读书之重回根本:《Scrum指南》100问 作者/分享人:glenwang 本文是对Scrum指南的解析,以展...
    glenwang真北敏捷阅读 2,538评论 0 13
  • Scrum指南的目的 Scrum是用于开发和持续支持复杂产品的一个框架。本指南包含了Scrum的定义,其中包 括S...
    iceinto阅读 1,340评论 0 10
  • 10月23日 面 对 刚回来的那两天,我感觉自己的能量低到了极点。从...
    四月天_2cbc阅读 8评论 0 0
  • 1 欣叶和顾彬终于在一起了。 欣叶说,一直在等待爱情,相信爱情,当他向我表白的时候,我无比感动,那种幸福是从未体验...
    蓝黛li阅读 257评论 0 4
  • 营销服务业包含的上市公司总共有26家,经营情况参差不齐。采用ROE>15的指标进行筛选,就只剩下分众传媒、印纪传媒...
    _咫尺天涯_阅读 148评论 0 2