目前我们团队正实践 Scrum 框架看板管理,这边文章正是对我们自己的实践的记录。这里的记录并不是按照时间顺序进行的,而是按照我自己的针对实践目标的先后进行的。目前我们团队还没有完全实现以上所有目标,对 Scrum 框架 理解和使用也还在初级阶段,所以有很多不足的地方,并且还有很多地方还在聊胜于无的状态,欢迎大家指正。

我们现在正在进行的实践有:

  1. 统一团队对“完成”的定义
  2. 看板管理流程
  3. 每日晨会
  4. 迭代回顾会议
  5. 迭代计划会议
  6. code review

我们团队刚开始的时候管理、开发混乱完全没有章法,大家各种打架、各种撕逼、各种甩锅。没有哪一次迭代不通宵,没有哪一次迭代不延期,没有哪一次迭代质量过关,没有哪一次上线不出问题,这种状态持续了很长一段时间。我感觉不行了,再这样下去还能做个啥产品,开始寻找各种解决方案并且不断反思团队遇到问题的本质,后来学习了敏捷,接触到 Scrum 和 看板,里面的方法论和实践操作不正是我们团队需要的吗?于是坚决决定团队开始敏捷实践,当然正所谓:软件开发没有银弹,实践证明 Scrum 和 看板并不能解决我们团队所有问题,但是确实可以让团队慢慢变好。

团队目标一致:完成定义

虽然决定引入 Scrum 和 看板,但是从哪里开始呢?这么多团队问题,应该从哪个或哪几个问题开始引入解决呢?还是团队全面调整引入?这些问题是任何团队在开始引入的时候都会遇到的,但是我相信每个团队最后的答案都是不一样的。Scrum 框架建议团队全面调整和引入,这样团队提升效果最明显,但是这个需要团队和公司整体努力才能达到。通过沟通和分析我们当时的团队内外情况,全面引入条件还不成熟,所以只能逐步引入。通过分析我们团队自身情况,决定优先引入能最大化解决团队 撕逼和甩锅 情况的实践。这里我们选着了:

  1. 统一团队对“完成”的定义

在某次迭代完成过后,选在了一个下午时间,我们整个团队发起了《针对“完成”定义的讨论会议》,会议分成 5 个阶段:

  1. 说明会议原则

谦虚、尊重、信任原则

会议期间尽量不被“打扰”,手机或者其他任何事情

  1. 收集大家对“完成”的想法:

使用便签箱收集大家的想法,每个参会成员使用便签写下自己的想法,然后读出来,最后将便签投入便签箱中,可以是新想法,也可以是对别人的补充。便签箱不断在成员之间循环传递,就会有越来越多的想法,直到大家所有想法都收集完了,一般在 3 轮后基本就完了。

  1. 整理大家想法

将搜集到的想法全部贴在版本上,记住是全部并且最好能大家一起做,同时将重复的便签贴在一起。然后移动便签,将意思相近的便签挨在一起,这样就形成了初略的分类。

  1. 讨论“完成”

对白板上的便签和初步形成的分类进行讨论和提炼,在过程中不断调整分类和精炼完成解释

  1. 总结得到最新“完成”定义

总结大家对分类和完成的讨论,结果形成 SMART 目标

在整个过程中需要保持谦虚、尊重、信任的原则,这样才能保持平等公平,让团队在微小的声音都被听到。最总我们得出了我们对于迭代完成的定义:

团队信息透明:看板

为了做到团队信息透明,我们引入了看板方法,目标是尽量做到迭代过程中:所有人员对团队的任何信息“信息触手可及”。第一次引入看板我们没有进行全员参与,是由我直接给出了一个初始看板设计。

这里如果大家团队有时间建议还是全员参与看板设计,这样大家对流程理解会更清晰。如果做不到全员参与设计关系也不大,因为看板本身是跟着团队不断进化的,在你团队感觉他不合适的时候,再来改进也是可以的。比如我们团队现在看板是这样的(这个是在后来团队所有成员一起改进了 2 次后的)

及时有效沟通:每日晨会

每日例会我们称为晨会,因为我们是规定在早上进行。我们会选择一位主持人来主持晨会,晨会上每个人主要回答三个问题:

  1. 昨天做了什么?
  2. 今天计划做什么?
  3. 有没有遇到问题?

主持人也可以在这个3个主要问题之上加入自己的内容,主持人要引导大家回答出这3个问题。通过这样的方式让团队成员对团队做出承诺,并让团队监督你的承诺是否有被实现和你是否做出了过度承诺,同时也让团队人员思考团队其他人员是否需要帮助,我可以帮助哪些人。

现在我们晨会形式也有所改变,主持人逐渐改变成一个迭代统一一个主持人,而不是原来的一天换一个主持人。并且主持的形式也可以有第二种选择

主持人对看板上每一个 未完成 的任务进行询问一下问题

  • 任务现在什么状态?
  • 任务有无人在跟踪?
  • 有无阻力导致任务无法进行?
  • 完成任务还需要什么协助?

在每次晨会的时候,如果团队有发现需要改进的点(比如时间方法、沟通模式等),可以在会后来一个小的及时讨论,针对好的方案可以记录下来,留到回顾会议的时候详细讨论。

迭代质量提升:迭代计划会议

迭代计划会议我们现在是由迭代学习会议和迭代评估会议 2 个会议组成。

迭代学习会议

迭代backlog在我们开始一个迭代之前会由产品人员提前提取到迭代规划中(我们现在展现在TAPD中),并且和开发负责人确认好这个个迭代的开发范围。这个工作基本上是在上个迭代中后期完成的,产品人员在做的过程中需要和开发人员进行相关沟通,特别是开发负责人,所以这个时期的开发人员积极支持也是很关键的。在这个backlog里面,每个需求必须写明业务逻辑和验收标准,如果有必要还需要补充使用场景说明和功能的UI设计。

迭代评估会议

迭代计划主要是围绕迭代backlog进行,我们对迭代计划会议做了不少调整。我们首先在迭代计划中进行业务学习会议,在这个过程中我们要求每个开发人员和测试人员对本次迭代范围内的业务进行宣讲,其他没有参与宣讲的人员需要对宣讲人员的疑问进行解答,特别是产品人员。在这个过程中让我们每个开发人员对业务目标达成共识,识别迭代中的重点和难点。同时这个过程可以对迭代范围提出质疑,如果有质疑,团队则必须在会议中决策出迭代范围。然后我们会在业务学习会议过后,立即召开难点设计会议,这个会议目前主要是开发人员参与,在会议上开发人员要针对迭代中的难点和重点进行详细设计,这个过程中如果有必要会协调产品人员一起参与(如范围调整,实现复杂度导致业务功能的变化等),得出详细设计中需要的必要结果(如:ER图,流程图,时序图等),如果有需要会后形成详细的设计说明书,一般情况下将会议中形成的白板图形成文档即可。最后所有人员对业务目标和重难点的设计达成一致后,开发人员进行估算会议,我们现在才用的形式是卡牌游戏对任务进行评估,目前通过卡牌游戏可以在一定程度上规避个人经验主义和单点故障问题。进过迭代计划会议团队对整个迭代的业务范围和迭代时间做出承诺,当然这个迭代计划会议持续的时间会随着迭代范围和难度有很大变化,目前我们团队最长的一次时间是5个工作日。

迭代质量提升:code review

每日分享会我们之前叫做每日code review 或 集体代码解释(只有开发人员参与),但是由于近期产品人员和测试人员的参与,发现之前的名字已经不合适了,就改成了每日分享会。每日分享会紧跟在每日例会后进行,也像每日例会一样选定一个分享者(之前是2个)来完成一个30分钟的分享,并且对于开发人员做了特定规定只能做code review,目前规定这个主持人和每日例会主持人为同一人。并且在每日分享会过后,观察者(目前是项目负责人)有义务并且也是必须和当天主持人一起对当天他自己的表现做一个简单的评估和回顾,并做相关记录。这里不只是包括人员的技术,还包括人员的沟通、演讲等能力。

目前这个会议也在调整,之前一个分享者很多时候不能达到 30 分钟,并且现在团队的情况让产品、开发和测试一起做分享已经不再合适。

高效学习团队:迭代回顾会议

迭代会议必须准守 2 个基本原则:

  1. 无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及现实情况,我们理解并坚信:每个人对自己的工作都已全力以赴。
  2. 我们的目标是发现改进的机会,而不是去责备某个人

迭代回顾会议在整个迭代上线完成过后进行,迭代会议也和我们的晨会一样,选定一位主持人。主持人负责引导团队回顾在本次迭代中:

  • 团队实践回顾(这里有很多方法,如:时间轴法,团队情绪表等)
  • 团队做得好的地方;
  • 有哪些地方我们可以做得更好;
  • 我们可以做哪些实践来让我们改善。

在操作过程中我们会让团队所有人员对我们可以做得更好的事情,进行投票选举出团队认为最急迫、最重要的前面3个出来,我们进行讨论得出我们需要的实践。在得出实践的过程中,最重要的是团队可以看到实际可执行的实践,也就是这个实践最好有明确的结果和判断好坏的标准,能形成 SMART 目标最好。主持人在这个会议中,也可以加入自己的元素,但是需要遵守2个原则:

  • 不能偏离主题内容;
  • 必须是针对整个团队的内容。

以下是我们一次在迭代会议中进行的团队情绪表实践:

在这里回顾会议中 Master 角色的人(观察者)员需要记录会议全过程,并且需要把会议记录同步到所有人,一下使我们使用的记录末班

记录项 内容
记录 记录这次会议的内容
历史问题跟踪 前一次会议总结内容,需要提醒住持人让团队评估上次的目标是否完成
总结 记录这次会议得出的结论 和 目标
观察 观察这次迭代回顾会议本省的情况,并在会后主持人和团队交流可以改进的地方

迭代回顾会议可以让我们及时发现团队需要改进的地方,也可以让我们发现团队里面需要继续维持的地方,让我们不断调整团队步伐和实践,让团队里面正确的、好的事情不断发生。

未来

我们目前正在引入的实践

  • TDD(测试驱动开发)
  • 迭代演示
  • CI/CD
  • 迭代跟踪者

同时也在不断调整我们现在的部分实践,如完成的定义、团队卓越(高效绩)的定义和目标。这就意味着团队会是一个持续变化和持续学习的过程,同时团队所在的外界因素也在不断的变化,这就需要团队的每个人都需要做到“学习学习再学习,实践实践再实践”,让团队不断的成长来适应各种变化。

总结

管理方法论改变和进化的驱动力是项目利益的最大化,但是改变的本质是项目的沟通模式。沟通模式的改变可以是信息的展现形式、信息的载体、信息的传递方式、信息流转和反馈方式。这些改变都会对我们项目管理中其他方面产生直接影响,并且也直接影响到我们的管理模式。在项目进行过程中既需要一对一的精细沟通,也需要针对项目成功目标的宏观沟通。

我们上面谈到了项目沟通中模式的改变,其实由于沟通模式的改变,会引发项目中其他管理方面的改变。

在这个过程中团队负责人要保证团队是在正确的道路上,并且要让正确的事情不断的发生。及时识别团队的所处阶段,识别为团队引入变化的时机,及时引入变化;不断通过实践结果总结团队的失败模式和成功模式,促进成功模式不断出现,让团队在不断出现的失败模式中恢复。同时和团队一起不断提高自己,做好对自我掌控,定义好自己的成功,接受团队比自己更好的想法。

推荐给大家几本团队和管理方法的书:

  • 《Scrum 敏捷软件开发》
  • 《Scrum 实战:故事、模型与成功秘诀》
  • 《Scrum 精髓:敏捷转型指南》
  • 《敏捷软件开发实践:估算与计划》
  • 《敏捷教练:如何打造优秀的敏捷团队》
  • 《如何构建敏捷项目管理团队》
  • 《看板方法》
  • 《看板实战》
  • 《架构即未来》