敏捷精灵日记5

[敏捷精灵日记]

• Sprint 评审会议不是让开发团队做成果“演讲”——会议上不一定要有PowerPoints 图片文件，通常会议不会需要超过30 分钟的准备时间——这只是简单的展示工作结果，所有与会人员可以提出问题和建议。
• 在Sprint 评审之后,开发团队会进行Sprint 回顾。有些开发 团队会跳过此过程, 这是不合适的,因为它是使Scrum 成功的重要方法之一。这是提供给开发团队的非常好的机会，来讨论什么方法能起作用而什么不起作用，并一致通过改进的方法。Scrum 开发团队，产品所有者和ScrumMaster 都将参加会议，会议由外部中立者主持；一个很好的方法是由ScrumMaster 互相主持对方的回顾会议，可以起到各团队间信息传播的作用。
  
• 敏捷回顾不是一场没有主题的讨论会，大家坐下来，七嘴八舌漫无目的的一阵“乱弹”，这样的形式对于项目进展没有任何帮助。
• Scrum回顾会议的议程：
  1、在白板上写上主要指导原则；
  2、在白板上画上一个至少三页纸连在一起长的时间轴；
  3、在白板上写上“我们的成功经验是什么”；
  4、在白板上写上“有什么能够改进”；
  5、在白板上写上“谁负责”，然后分成两个区域——“团队”和“公司”。
• Scrum回顾会议的最高指导原则。即‘无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。'
• 在项目过程中，处理问题越早，那么付出的代价与成本就越小。问题是，当我们在紧张的开发任务中，有时候 很难发现这些错误，更加意识不到这些错误会带来严重的影响。通过回顾会议，利用团队成员互相善意地“敲击”对方，或者反复“锻炼”开发过程与方法，就能够 让每一 位成员都炼就“火眼金睛”。
• 进行Scrum回顾时，发现问题仅仅是第一步，我们还要在回顾会议中合理分析这些问题出现的原因、所属类别，并因此划定问题的“责任田”。我们要明确这些问题是团队内部的，还是由于外在因素导致的，也就是说要明确“责任田”的归属，指定处理人和处理时间。
• 在每个Sprint开始的时候，我们都必须要明确这个Sprint结束的时候我们需要Review的是 哪些东西。很多时候，如果一个Scrum开展不是很顺利，在Sprint Review的时候我们常常会听到这样的理由，“因为某些原因，这个功能我没有办法展示给你，但是这个功能是有了的，我只需要改动小小一点东西就可以了。 ”或者是“这个部分与另一个系统相关，我代码已经写好了，但我要一起改好了你才可以看到。”如果放任的话，这些理由到后期会泛滥成灾。我们所能做的，除拒 绝通过这些相关的 User Story之外，在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint Review上看到什么东西。强调我们重视的是可交付的版本，而不是一个口头上的功能增加。