硝烟中的 Scrum 和 XP（笔记二）

继续笔记一的内容，写一些《硝烟中的 Scrum 和 XP》的后面几个章节的读后感和总结。

6. 怎样布置团队房间

办公环境设置其实是一个很重要的工作，根据工作流程设计工作环境往往会收到超过预期的效果。
让团队坐到一起，哪怕只挪动几米也会有立竿见影的效果。其实这也不仅仅是书中的建议，在我们现实中研发活动也是的最佳实践之一。
书中也提到几点比较反直觉的观点，PO、教练和SM既要贴近团队，也要跟团队保持一定距离，目的是为了让团队逐步形成自组织性。
最后陪一个书中的布局图，一个比较有意思的地方是除了sprint wall，还有一个Design wall，这个比较符合我的期望，设计确实是工作的基石，只有管理视图应该是不够的。

办公布局图

7. 怎样进行每日例会

这个没有什么可以多讲的，书中给了两个例子如何迟到和处理团队有人反馈不知道做什么的情况，这基本属于是管理问题了，SM需要有一些办法。

8. 怎样进行 sprint 演示

Sprint 演示（有人也叫它 sprint 回顾）是 Scrum 中很重要的一环，却常为人们低估。

完全同意书中这个说法，演示确实是一个非常好的促进团队干净地完成工作的手段，做演示会迫使团队真正完成一些工作，进行发布（即使是只在测试环境中。演示也是对外交互的一个重要途径，工作成果来源团队外部，演示可以让其他人可以了解你的团队在做些什么，也可以吸引相关干系人的注意，并得到重要反馈。

• 关于演示需要注意的问题，也有几点印象比较深刻的：
  1.确保清晰阐述了 sprint 目标。
  2.不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。
  3.让演示关注于业务层次，不要管技术细节。
  4.对于处理“无法演示”的工作，实际上即使是一些技术性的内容也是能被演示的。

9. 怎样做 sprint 回顾

Scrum 中第二重要的事件（最重要的是 sprint 计划会议），因
为这是你做改进的最佳时机！

管理方法上强调要做PDCA，敏捷的四会实际上可以理解为是PDCA的一个实例化的实践过程。前面看过一个说法是，人学习有三种途径，一种是书本上学，一种是向身边的人学，还一种是向自己过去的经验和教训学习。柳传志也推荐过一本书叫《复盘》。回顾或者复盘对于能力提升很重要。相比而言，计划的重要性大家都比较容易理解，而复盘的重要性却不那么明显，所以我个人更倾向于把复盘列入最优先需要做好的事情。

9.1 书中对回顾会也给了一个方法，图上分为三列分别是：

• Good： 如果我们可以重做同一个 sprint，哪些做法可以保持。
• Could have done better： 如果我们可以重做同一个 sprint，哪些做法需要改变。
• Improvements： 有关将来如何改进的具体想法。

9.2 我们自己的实践中，教练引入了一个海星图(Starfish Diagram)作为回顾会的工具：

Starfish图

1. Keep Doing：做的好的，需要继续做的事情。
2. More of：团队成员不一定能完全说明白，但是认为可以多做可以提升或改进当前实践活动的事情。
3. Start Doing：希望做的一些新事情，这些事情可能是做的不够好的地方，也可以是让事情变得有活力或有趣。
4. Stop Doing：停止那些显然没有太大帮助或者不能增加价值的工作。
5. Less of：有价值，但是价值不大，可以少做一点去做其他事情

9.3 回顾会的目标是为了在下一个sprint中做的更好，在回顾会上，还有一些实践的方法和注意点：

1. 换一个不受干扰的舒适场所，最好不要在原团队房间。
2. SM对sprint backlog做总结。团队成员在不被打扰的情况下轮流提出自己想法，哪些是好的，哪些可以做的更好，哪些在下一个sprint中改变。
3. 对预估生产率和实际生产率做比较，差异大会分析原因。
4. 团队成员通过头脑风暴得出所有的想法，写在便贴纸上，然后成员投票选出几项需要改进的工作。

• 不过也不要想一口吃成个胖子，这一点很重要。每个 sprint 只关注几个改进就够了。

9.4 其他

• 在团队之间传播经验，可以通过“桥梁”式的人去实现
• 不是每一个问题都需要去解决，在引入变化之前，可以先考虑什么都别做，寄希望于问题自动消失（或变小）

10. Sprints 之间的休整时刻

你需要在冲刺的间歇休息。如果弦总是绷得那么紧，实际上收到的成
效反而不好。

• 我们会力求保证不在同一天举行 sprint 回顾和下一个sprint 计划会议。在启动新的 sprint 之前，每个人都应该至少度过一个不需要考虑 sprint 的夜晚。
• sprint的结束安排在周五是一种推荐的安排，有一个周末可以思考和总结。
• “实验日”（你爱叫什么都行）算是一种方式。目前我们每个月有一次实验日，放在每月的第一个星期五。

11. 怎样组合使用 Scrum 和 XP

Scrum 注重的是管理和组织实践，而XP 关注的是实际的编程实践。这就是为什么它们可以很好地协同工作——它们解决的是不同领域的问题，可以互为补充，相得益彰。

有些 XP 实践直接被 Scrum 解决掉了，可以被视作二者的重叠。如“整体团队”，“坐在一起”，“故事”和“计划游戏”。

还有一些重要实践：

1. 结对编程：这算是一个反直觉但是确实在不少场合非常有效的手段，至少在我们核心代码重构过程中，这个实践大家反馈的效果很好。
2. 测试驱动开发（TDD）：TDD 是很难，但是在一开始没有用 TDD 进行构建的代码库上实施TDD……则是难上加难！
   这一段介绍很接地气，我们在实践中也遇到了同样的问题，苦不堪言。书中介绍的方法也很有启发：

学到的一课：如果你深陷手工回归测试的泥潭，打算让它自动化执行，最好还是放弃吧（除非做起来特别简单）。首先还是应该想办法简化手工回归测试。 然后再考虑将真正的测试变成自动化执行。

3. 持续集成：不多说了，有专门的书可以看
4. 代码集体所有权：反直觉的一个问题，跟“代码责任田”这个同样著名的观点有点冲突，我们目前选择了后者，这可能也是一种价值观和文化差异点。
5. 充满信息的工作空间：看了不少敏捷团队铺天盖地的宣传海报和满墙的便利贴，确实很有震撼感，我对办公空间的设计看板印象比较深刻，光有管理信息是不够的，信息应该多样化和实用化，而不仅仅是提供仪式感（当然这也有用）。
6. 代码标准：这个我觉得不算是XP的实践，算是研发普世价值观吧，不过推荐下阿里最近的代码规范IDE插件P3C，把规范融入开发过程而不是事后检查效果更好。
7. 可持续的开发速度/精力充沛的工作：不多说了，劳资纠纷的关键点

12. 怎样做测试

12.1 Scrum团队的测试职责和测试人员定位

按Scrum的方法论，我们可能会听到：
• “很明显啊！ Scrum 团队应该是跨职能的！”
• “Scrum 团队应该是没角色的！我们不能把只做测试的人放到里面来！”
• “应该开发自测”

作者澄清了一个概念：“测试人员”指的是“主要技能是测试的人”，而不是“只做测试的人”。开发人员常常都是很差劲的测试人员。尤其是他们测试自己代码的时候。

• 那么是否需要一个专职测试人员呢？如果没有任何事情需要测试，那测试人员该做什么？

1. 测试人员就是“验收的家伙”，去检查DoD的结果（QA）。
2. 可以完美地担当组织 sprint 演示的职责。
3. 他应该要为测试做准备。包括编写测试规范，准备测试环境等等。
4. 如果团队在做 TDD，他也应该跟测试人员或开发人员结对。
5. 在 sprint 计划阶段花上一些时间来找出非编程性任务，测试先生就有机会来做出大量贡献，即使他不会编程，当前也没有测试工作要做。
6. 测试先生确实在团队中有一个特定的角色，不过他仍然可以做其他工作，其他的团队成员也可以做他的工作。

12.2 两个话题

1. 验收测试应该作为 sprint 的一部分么？
   分歧较大。有些团队把验收测试当成了 sprint 的一部分。但大部分团队都没这样做。
2. 在每个 sprint 中少做工作来提高质量

12.3 Sprint 周期 vs. 验收测试周期

实际就是一个核心问题，一个sprint后，出现大量的bug要怎么办？
首先，还是全力提高 Scrum 团队发布的代码质量。对于依然存在的泄露问题，有如下几个实践：

• 方式 1：“在旧版本可以产品化之前，不构建新特性” --这个作者不推荐，会破坏Sprint的节奏，不过这个跟精益思想有点冲突了。
• 方式 2：“可以开始构建新东西，但是要给‘将旧功能产品化’分配高优先级”
• 糟糕的方式——“只关注构建新东西” --反模式
• 别把最慢的一环逼得太紧

12.4 小结

本章开始，Henrik Kniberg说：“这是最困难的部分。我不知道它到底是只是 Scrum 中最困难的部分，还是在软件开发中通常都是最困难的部分。”
本章最后，Henrik Kniberg说：“其实，我们也没有做到。”
感觉上Henrik Kniberg对质量和测试也没有把握，好消息是我们还有机会在质量上为Scrum的拼图做自己的贡献。

总结

这本书可以说是一个开发主管在用开发的视角在讲述开发的实践故事，对我们这些干研发的人而言还是可以发现很多可以产生共鸣的点。
Scrum从敏捷价值观而来，构建了一个框架，强调实践，在实践中引入不同的工具和方法，学Scrum有时候觉得新鲜，有时候感觉熟悉，一个Scrum的落地方案也可能是包罗万象和高度定制化的，这也可能正是Scrum可以流行的原因之一。
Henrik Kniberg讲的很多实践感觉也很实用，好书确实离不开作者的实力，不少直接就可以套用。不过实施效果可能短期也很难度量，所有工具背后隐含了一些方法论甚至价值观的东西在里面，有些感觉不容易理解或者反直觉的内容或许来源于经验和价值观的冲突。
敏捷教练经常会提“痛点驱动”的观点，药到病除固然很吸引人，我个人倒是觉得或许全面引入，实践中改进工具方法或许更好，这也正符合敏捷迭代的思想。

最后重温一下敏捷宣言：

Manifesto for Agile Software Development

• 个体和互动高于流程和工具
• 工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划