概述

作为本次大项目的项目经理，按照老师的要求我读完了《硝烟中的 Scrum 和 XP》这本书。在这本书中并没有介绍Scrum以及其相关的基本概念，所以如果缺乏这方面的基础知识，在读这本书之前，建议

• 在网上先将Scrum的相关术语了解一下
• 可以参考这个网站
• 了解过，或者是见过一个完整的软件开发过程

这本书虽然不厚，但作者很详细的介绍了我们在进行实际项目中，应该如何进行实践。如果你在读这本书之前，管理的经历并不愉快，那么这本书将会给你一种相见恨晚的感觉

感想记录

产品的backlog是开发的核心和基础

• 在软件开发的过程中，backlog是停留在业务层次上的待办事项的集合。我们需要对每个待办事项进行估计（包括成本，复杂度，风险，功能点）。优先级越高的待办事项的估算要越精确，所以一个准确完善的backlog决定了我们未来实现过程的规划，

• 需要注意的是，在软件实现的过程中，backlog并不是完全一成不变的。随着项目的推进，由于外部和内部因素的种种变化，我们待办列表的优先顺序有可能随之发生变化（对于那些很重要，并且可以快速解决的问题可以先做）。因此我们需要进程估算我们要经常做估算。

sprint贯穿开发的全过程

• sprint的开发周期

• 短的sprint代表有更灵活的随机应变能力，短的反馈周期使得我们学习和改进的速度更快，在错误方向上花费的时间更少
• 长的sprint可以给开发人员更多的时间去做更充分的准备，以及解决发现的问题，达成sprint的目标，而不用频繁的花费时间在sprint的相关事物上，
• 针对不同的团队来说sprint的开发周期是不同的，需要在实践中去摸索尝试。一般来说产品负责人会喜欢短一点的周期，而开发人员则喜欢长一点的。所以针对不同的项目开发，不同的实际情况，sprint的开发周期需要和团委成员一起协商讨论后决定。

• 准备sprint

• 在每一次sprint之前，我们一定要确保团队做好的准备。不然sprint只能是一种对于时间的浪费：
  • 产品的 backlog 必须存在并且完善
  • 只能有一个产品 backlog 和一个产品负责人
  • 所有重要的 backlog 条目都已经根据重要性被评过分，不同的重要程度对应不同的分数
  • 产品负责人应当理解每个故事的含义。他不需要知道每个故事具体是如何实现的，但是他要知道为什么这个故事会在这里

• 制定sprint计划

• 要有确定的sprint目标：

  • 其必须用业务术语表达，而不是技术词汇，因为每个sprint的目标是要求团队以外的人也可以看懂的。
  • 虽然sprint的目标是很重要的一个部分，但制定起来确实是很困难的，但在书中，作者告诉我们，即使我们像挤牙膏一样挤出来，那也是很值得的

• 要有可靠的团队成员名单，以及投入程度和分工

  • 可靠的团队在很大成功上决定了软件成功的可能性，如果出现团队成员罢工或者需要请假的情况，很有可能造成软件开发过程失败。所以在制定sprint的计划的时候，最好可以考虑一些意外情况下的补救措施
  • 而团队成员的分工需要均衡，如果任务分配的不平衡，那么也很难充分调动成员的积极性和提高工作的效率

• sprint backlog

  • 即 sprint 中包括的故事列表

• 确定好sprint演示日期

  • 演示是一个非常好的促进团队干净地完成工作的手段，做演示会迫使团队真正完成一些工作，进行发布（即使是只在测试环境中）。演示也是对外交互的一个重要途径，工作成果来源团队外部，演示可以让其他人可以了解你的团队在做些什么，也可以吸引相关干系人的注意，并得到重要反馈。
  • 确保清晰阐述了 sprint 目标
  • 不要花太多时间准备演示，尤其是不要做花里胡哨的演讲
  • 让演示关注于业务层次，不要管技术细节

• 确定好时间地点，供举行scrum会议

• 怎样让别人了解我们的sprint

• 宣传和演示，在公司内部，甚至是团队之间，演示都是一个很重要也很常用的方式去让其他人了解我们这段时期所做的工作

• 做 sprint 回顾

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

质量是开发过程中不能退让的一个重要的部分

在书中，一个软件的质量包含两个部分：

• 外部质量——系统用户可以感知的质量。运行缓慢，让人迷糊的用户界面就属于低劣的外住质量
• 内部质量——用户一般感知不到的质量，但对于系统未来的维护有很大的影响，如代码可读性，代码可维护性等。

• 对于外部质量的要求自然不用多说，外部质量决定了用户对于软件的使用体验，如果我们在外部质量上进行让步，那么就相当于我们自己主动提高了软件开发过程中的软件风险，及时我们按时完工，软件失败的概率也会相当的到。当然所有的开发团队都不是傻子，基本没有多少开发过程会主动在外部质量上进行让步。

• 但是内部质量却被很多开发团队，特别是人数不多的小团队所放弃。但是牺牲内部质量是一个糟糕透顶的想法。也许我们在初期开发的过程中牺牲内部质量可以节省下来一点时间，但是在后期的过程中我们就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，当我们在测试中发现问题，这些问题的修正和整改就需要耗费更多的精力，为了恢复质量了，我们甚至需要重新进行编码实现。而且很多情况，内部质量差，外部质量肯定也不会很好，毕竟在松散的沙滩上是很难建立起精美的阁楼的。

如何实现团队成员的管理

• 统一、公平而严格的规定，是实现团队成员管理的重要部分。对于违反规定，比如吃到的人，可以采用一些方式来处理迟到的家伙。
• 对于团队中的一些刺头，如果经常违反团队中的一些规定，那么团队的负责人就需要考虑是不是应该进行单独的谈话，如果还是不行，就需要针对他在团队中的重要性采取相应的措施。
• 在书中，作者还专门提到了如何进行团队成员的位置分配，以便与提高团队协作的工作效率

怎样组合使用Scrum和XP

• 结对编程：这算是一个反直觉但是确实在不少场合非常有效的手段，至少在我们核心代码重构过程中，这个实践大家反馈的效果很好。

• 测试驱动开发（TDD）：TDD 是很难，但是在一开始没有用 TDD 进行构建的代码库上实施TDD则是难上加难！

• 持续集成：不多说了，有专门的书可以看

• 代码集体所有权：反直觉的一个问题，跟“代码责任田”这个同样著名的观点有点冲突，我们目前选择了后者，这可能也是一种价值观和文化差异点

• 充满信息的工作空间：看了不少敏捷团队铺天盖地的宣传海报和满墙的便利贴，确实很有震撼感，我对办公空间的设计看板印象比较深刻，光有管理信息是不够的，信息应该多样化和实用化，而不仅仅是提供仪式感（当然这也有用）

• 可持续的开发速度/精力充沛的工作：

测试人员

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

总结

整本书读完，确实对于我们小组项目的开发有很大的指导意义，有很多值得借鉴的地方。例如：

• 如何处理团队中工作不饱和，手头没活干又不主动接任务的成员。
• 演示工作成果。
• 剔除不必要的成员，保持团队精简，控制团队规模。
• 使用计划扑克评估工期

作为敏捷开发实践的介绍书籍，其中的很多观点和方法对我们都有很大的指导性，但是，也像作者说的，这种方法目前也是还在不断尝试和改进中，至于是不是最好的方法，还是需要结合我们开发的实际情况来决定