勇气

周四晚上的SM CoP活动内容是试点团队SM现身说法，讲解敏捷转型项目启动以来这一个多月团队的变化、取得的进展、和将来的改进方向。总的结论是敏捷是有效的，团队取得了比较大的进步，虽然还不完美。

一个多小时的交流中并没有说什么理论，参加的同事也积极参与了交流，很真实。希望对所有参加的团队能够起到一些激励作用。一起进步，一起砥砺前行，改变现状并不容易，需要勇气。

对敏捷的理解

关于对敏捷的理解，SM提到了3点是自组织团队、PDCA持续改进和团队任务细化跟踪。自组织团队是个长远目标，团队现在是没达到的，不过团队已经在往这个方向前进了；PDCA的戴明环，这个不多说，肯定是正确的，母公司的教练在导入培训最后的总结也是持续改进；团队任务细化跟踪，说的是团队在计划会时做了比较细致的计划，形成了团队共同目标，每日站会上会对进展情况进行跟踪，及时发现和干预风险。

一百个人有一百种对敏捷的理解，不会完全一样，也不会完全不一样。SM的理解和我的理解不完全一致，不过如陈春花老师说的，管理不问对错，只问是否有效，只要团队感觉到有帮助，有进步就是好事情。德鲁克说管理是一种实践，敏捷始终强调的也是实践。Scrum本身是易于理解但是难于精通的，不同团队的落地方式都不一样，团队结合自己的实际情况，通过实践摸索出来的心得体会是最重要和真实的，对其他团队的借鉴意义也更大。

团队落实的实践

团队这一个多月来落地的实践，包括Scrum的四会、团队共同遵守的DoD，用户故事拆分、单元测试、测试用例前置、团队内部的开发返工度量、ZTP测试用例规范、测试用例风格统一等。这些介绍的比较具体，大家问的更具体，SM都一一给予了答复，讨论和交互比较热烈。当然团队开始运行时并不是一帆风顺的，发现了一些问题，踩过了一些坑，在教练的指导下每个迭代都有回顾和改进，才能取得一些成绩。SM在介绍时至少四次提到教练的名字，这里要感谢ThoughtWorks各位教练的悉心指导。

团队的变化

说到团队的变化，有几个方面比较明显。

首先是固定时间盒和团队共同承诺让大家真正成为了一个团队，SM说到在迭代2中团队确定了需要完成的任务，并且约定如果能够在工作日按约定的质量标准完成所有任务，整个团队在周六就不用来加班了，但如果有一位成员的任务不能按时完成，则所有团队成员要一起到公司加班，因为，这是团队的共同目标。有位一年多的同事，自己的任务可能存在延期风险，为了不拖团队的后腿，下班后自己主动在家里每天加班到十一二点，最终大家真正实现了一个周六不加班的目标，对团队士气是一个比较大的激励，之前团队默认的作息制度已经是周六要加班了。

这里提到了激励，其实激励未必需要是物质上的，团队一起达成了共同的目标，并赢得了一个不加班可以陪家人的周末，就是很大的激励。谁说产品研发团队没压力？没有合同项目的外部压力，通过固定时间盒的方式，大家可以自己给自己压力，并把它转换成动力。

第二个变化是代码质量更高了，由于测试提前，开发人员要自己进行测试，同时还要写单元测试用例，另外增加了代码走查机制，所以大家是感觉代码质量变高了，不过尚需要合同项目的检验，现在的还只是团队成员的主观感受。

我自己觉得SM说的是版本质量的提升，因为敏捷强调质量内建，通过PO写用户故事的AC，测试人员提前设计测试用例，开发人员进行测试验证，代码走查、单元测试这些手段，已经完成的这些用户故事的质量相信是有保证的。

第三个变化是各个角色协作更加顺畅，效率更高。在转型之前是抛接式的工作，从看板上能够明显的看到瓶颈是测试环节，卡片都堆积在测试这里，测试人员无所适从，不知道先测试哪一个；等到测试出故障找开发人员解决时，这个改动很可能是开发人员一两个月前完成的，现在要想回忆清楚前因后果都要想好久，这种来回的切换隐含着巨大的浪费。现在是大家齐心协力完成团队目标，是协作式的工作，开发人员努力做到一次通过，当然现在还没能做到，内部返工虽然有减少但还是存在较大改进空间。每天站会上如果有测试打回给开发的任务，会在看板的任务卡片上画上红叉叉，开发人员会很难过有愧疚感。测试提前后，测试人员有一定余力进行自动化测试用例的补充工作，所以在迭代过程中能够为研发中的故事补充一些自动化用例，达到冒烟测试的效果，当然这还远达不到完美的程度，没法把所有用例都变成自动化的。考虑到自动化用例设计的成本，现在能做到同步增加自动化测试用例，已经是比之前进了一步。同时开发和测试的比例是4:1，测试人员的工作压力仍然比较大，开发人员会主动的帮测试人员多承担一些，逐步的模糊开发和测试的界限，向着自组织的目标在前进中。

第四个变化是因为有了回顾会，团队成员有了表达的渠道，大家愿意说话了，会主动在回顾会上提出迭代中做得好的和做得不好的地方，推进团队持续改进。团队虽然还没达到自组织，不过已经是在向着这个方向前进了，我个人觉得这其实和SM个人的能力和努力也是分不开的。王大爷说过，如果Scrum中只能保留一个会议，那么他会保留回顾会，以推动团队持续的成长和改进。

有哪些经验和教训

首先是四会中取得的经验和教训，如计划会时间过长、站会时间过长，变成汇报会等，这些是团队导入Scrum时的常见问题，团队学习和纠正的很快，就不多说了；

然后是看板上的DoD列出来之后，站会上挪动卡片时会需要提醒DoD是否达成了，现在大家已经形成了习惯，不太需要经常提醒了；

第三是任务单超期的预警。因为在计划会上已经明确了测试用例完成时间、开发完成时间、测试完成时间这三个时间点，所以站会上一眼就能看到哪些是超期存在风险的；

最后是自动化单元测试和自动化ZTP测试。没有完备的自动化测试，回归测试就没法快速高效的完成，在推进单元测试和ZTP测试的时候有一些弯路和经验教训，因为时间关系，SM说后面再进行专题交流。

前进的方向

后续会在工程实践和习惯上继续加大投入，包括CI纪律&代码提交规范，代码走查习惯的培养，TDD实践的落地，测试用例分层，对迭代中的故事点进行预估，形成团队的迭代速率指示器，最终把团队打造成有激情和活力的自组织团队。

敏捷之旅没有终点，一旦启动了持续改进就不会停止。为团队高兴，为团队喝彩，为团队加油，我们会越来越好的。

---

我是有底线的