干货｜敏捷实践重构
点击上方“中兴开发者社区”，关注我们
每天读一篇一线开发者原创好文
▎作者介绍
丁一：无线研究院敏捷教练，也是敏捷软件开发爱好者，致力于让管理实践和技术实践在团队中扎实落地。
叶卫军：优秀的团队Scrum Master，具有敏锐的洞察力，丰富的管理经验，打造了一只高效能的团队。
李会毅：专注于软件设计和开发，善于思考和总结，致力于通过敏捷软件开发技术与流程提升团队绩效。
我们接触敏捷软件开发也有一段时间了，但这其中的一些实践，比如“四会”、代码走查、结对编程等实践我们真正做“到位”了么？如果仅仅当成一种形式去开展这些实践，反而达不到预期的效果。时间长了，团队成员就会对敏捷开发动摇信心了。
在《重构》一书中，软件大师Martin Fowler以代码坏味道的方式给出重构建议。本文也以敏捷实践坏味道的方式展开叙述，结合作者们的实战经验对问题进行改进。这些实践在作者们的团队中都获得了不错的效果，在此和大家分享。
▶1.站会
坏味道：
- 拖沓、冗长
- 针对具体问题讨论发散
- 汇报会
重构方法：
- 可以买个小闹钟挂在看板上，设定好时间，超时就提醒。
- 团队成员讲解的时候，要面向大家，不要看着SM。发言内容仅限站会要求的三件事。
- 不讨论具体的细节问题，可以等站会结束后找相关人员单独讨论。
▶2.启动会
坏味道：
- 任务安排会
- 只评估开发的工作量
- 冗长
重构方法：
- SM首先整理出这个迭代的backlog（优先级已经和项目确认好）。
- 交付类故事需要在迭代前完成需求研讨，输出设计方案，如果没有方案，不能进入迭代。
- BA已经初步拆分史诗故事（可以独立交付、验收）。
- 启动会开始时，BA对方案进行讲解，大家提问，达成共识后，评估点数，包括开发、验收测试、自动化测试、UT等全部点数，拆分用户故事。
- 当全部故事评估完成后，根据总点数，看是否超过了团队的承受能力，如果超过，需要舍弃低优先级需求。
- 最后认领故事。
▶ 3.回顾会
坏味道：
- 回顾内容单一
- 改进措施跟踪不到位
重构方法：
最初的回顾会，就是传统的敏捷回顾会，讨论这个迭代做的well, less well, suggestion的地方。
当然这种方式并没有问题。但它忽视了软件交付过程的改进。
因此，除了上述的回顾方式，可以增加如下内容：
- 迭代度量数据解读。比如特性、史诗故事、用户故事的交付周期，代码覆盖率等度量指标，从中挖掘需要解决的问题。
- 故障复盘。这个可以说是我司传统保留活动，不解释了。
通过以上三种回顾方式，可以从文化、交付、团队等角度全面进行回顾。
针对回顾发现的问题，在wiki上建立了专门的backlog，然后把待改进点打印出来，贴在看板上，提醒实施人跟踪。
下次回顾会时，首先会对上次回顾会的改进内容进行讨论，看问题是否解决。
▶4.演示会
坏味道：
- 缺失
- 时有时无
- 提出的问题没有跟踪和反馈
重构方法：
- 演示会需要固定时间，比如在迭代完成后的第三天进行。提前确定主持人。
- 主持人提前整理演示的内容，一般从需求系统上导出交付的功能清单。用项目的集成环境进行演示。
- 主持人发邮件给用服、规划、开发、测试、项目经理等干系人。
- 演示过程有专人记录提出的问题。
- 演示后，主持人把演示过程和发现的问题记录在wiki上。
- 下个迭代，对问题进行改进并合入版本。在后续的演示会上，会对这些改进点进行演示，做到闭环。
5.代码走查
坏味道：
- 评审的同事对代码不熟悉，发现不了问题。
- 讨论发散。
- 只能走查部分同事的代码，其他同事的内容没有覆盖。
重构方法：
- 代码走查时间分两块：每天下午16:30--17:30，第二天09:05--09:30。如果当天下午能把全部内容走查完，第二天早上就不再进行走查。如果没有走查完，第二天早上就要继续走查。
- 走查前，会统计下几个人要走查，每个人大概要花多长时间。做好初步计划。
- 走查时，主讲人要对业务背景、代码意图进行介绍，让大家有整体了解。
- 引入主持人机制。主持人要有敏锐的洞察力，一旦发现大家讨论发散或者延迟，立即叫停。
▶6.看板
坏味道：
- 荒废了
- 故事卡移动不及时
重构方法：
针对看板，团队内部做过一次讨论。正好当时项目要统计迭代人力投入，为了能更准确、工作量小的完成这件事情，我们做了这样的约定。
- 迭代开始前，在团队backlog(excel文档)中更新任务，然后把故事卡打印出来，贴在看板上。故事卡进行分类：设计、开发、测试、故障、文档、沟通等。
- 站会开始前，每人检查自己的故事卡是否完整？如果不完整，补充故事卡。
- 站会开始时，每人在故事卡上划道道，最多两道（每道代表0.5天）。然后移动故事卡。
迭代完成后，SM收集故事卡，结合excel表格和卡上的道道，很容易就能统计出团队这个迭代的人力投入以及故事交付是否延迟？并且是相对精准的，也节省了大家的时间。
还有一个好处就是：团队的任务全部可视化，故事卡也能流转起来了。
▶7.自组织
自组织是大家为了目标能自发的做事情，检验的标准很简单：如果SM不在，这个团队的工作能否正常运转下去？
要实现自组织，一定让大家达成目标共识。
比如可以做了如下约定：
1. 每天早上8:50，自觉到看板前集合召开晨会。
2. 每天下午16:30，自觉到大电视前集合进行代码走查。
刚开始执行的时候，可能有些同学还不太习惯，需要有人叫一下。时间长了，大家养成习惯就按照这种方式自觉开展了。
另外，对于一些敏捷实践，比如回顾会、启动会、showcase等也不仅仅是sm的事情，通过认领的方式，让大家都能参与其中，同时也锻炼了个人的组织协调能力，一举两得。
▶8.需求研讨
坏味道：
- 没有需求研讨
- 计划会上SM或者BA简单澄清需求后开始认领故事
重构方法：
- N-1迭代BA组织完成N迭代的开发需求研讨；
- 研讨过程必须参与角色齐全：BA + TSE + QA + DEV（不一定全员）；
- 形成团队自己的需求场景清单，并在后续复盘改进中不断完善；每个需求研讨结束前对照清单逐一分析波及影响；
- 研讨完成后，计划会之前TSE和QA协商输出测试用例
▶9.无差别团队
坏味道：
- 团队一个萝卜一个坑，各人只扫自己门前雪
- 计划会无故事认领环节
- BA拆分好故事后，SM挨个指派任务
重构方法：
- 故事按照优先级排序，主动认领；
- 如果认领者认领了陌生领域卡片，SM可以安排一个熟悉的同事协助，但一定要认领者负起交付责任；
- 无差别建设过程中，团队营造一个开放的氛围，允许犯错；SM在考核或者语言鼓励上，给予成员足够的安全感；
- 如果团队现状不适合大规模无差别，建议逐步小范围开始，但一定要开始做起来。后续收益会超乎想象。
▶10.结对编程
坏味道：
- 大部分时间都在闲聊；
- 在结对中滥竽充数、心不在焉、得过且过；
- 都结对编程了，就不需要代码走查了；
- 结对过程中两人没有任何交流；
- 新人和老员工结对时，新员工一直默默的看着；
重构方法：
根据团队的实践经验，结对的方式是非常灵活的，结对编程应该是自由选择，不应是强制性的。
是否使用结对编程，需要具体问题具体分析，不可盲目。任何事手都有他的好与坏，结对编程也不例外，只有知道了好与坏，才可以更好的利用它。提升开发的代码质量和开发的效率，更好的知识共享，更好的团队氛围。
- 如果两个人都喜欢闲聊，就不要在一起结对编程，通过分别认领不同的任务。
- 不是所有工作都适合结对完成。架构设计和技术验证、简单的任务、已经有成熟的解决方案，这些都不适合结对。对于有挑战的问题，结对双方有不同的技术背景，可以通过结对达到技术互补或者碰撞找到更好的解决方法。
- 老练的程序员和新程序员结对，可以分享业务和技术经验，使新人更快的成长，同时新老结对也需要给新人独立完成任务的时间和机会。使新人有自己解决问题的思路和方案。通过结对-独立开发-结对，不断的乒乓来发现自己的短板。使团队人员能力达到提升。
- 结对编程不能没有代码走查，两个人有可能缺少同样的知识点，导致犯同样的错误。代码走查是必须的。
- 结对需要结对双方都要明白结对的意义，不是为了结对和结对。不能发挥结对的优势，那么需要果断的终止结对。
