敏捷实践敏捷开发与项目管理敏捷战事

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

2019-02-24  本文已影响40人  edwardzhq
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的最小完整流程的故事与验收标准。

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

但是在技术实践方面

.....

(注: 我发现许多人还不明白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的分解系列课程，帮助更多的人从零到入门，从原理到如何实际操作。

上一篇下一篇

猜你喜欢

热点阅读