敏捷精灵日记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上看到什么东西。强调我们重视的是可交付的版本，而不是一个口头上的功能增加。

阅读详细......

敏捷精灵日记4

【敏捷精灵日记】

• Scrum 团队强调自我管理，自我引导，这其实是管理的最高境界，如果团队里面的每个人都能够时刻关注公司的或者部门的business，那么整个公司的利益自然会最大化，但是现实往往不是这样的。那么设立Scrum master时，是不是可以让每个人在每个sprint里都有这样的机会来带领团队，并感受这种business的view呢？实际操作中这个是不是有难度呢？起码在我们现在团队中还不是轮换Scrum Master的，没准以后我们可以试试！

• 让Daily Scrum会议保持紧凑有效的指导原则：
  • 第一指导原则：主题明确，不能参杂其他无关的话题。
  • 第二指导原则：站立会议只允许“猪”说话，“鸡”不能讲话。
  • 第三指导原则：所有人站立围成一圈，不能围坐在一个桌子周围。
  • 第四指导原则：确保整个团队都要参加每日Scrum会议。
  • 第五指导原则：每日Scrum站立会议是团队交流会议，不是报告会议
  • 第六指导原则：每日Scrum站立会议应该控制在15分钟之内。
  • 第七指导原则：不要把每日Scrum站立会议作为一天的开始。
  • 第八指导原则：Scrum站立会议要在每日同一时间同一地点举行
• Scrum Master要及时解决Daily Scrum上提出的阻碍。这一点非常关键，Scrum Master必须要做到，否则会影响每个成员反应障碍的积极性。
• 利用burn down chart来跟踪细分任务的完成情况，可以在项目进程的任何时间点都能够看到项目进展状况，而不是每周或者项目完成之后，从而保证了开发进度处于可控制的状态。

阅读详细......

敏捷精灵日记3

【敏捷精灵日记】

· Scrum注重的是管理和组织实践，XP关注的是编程实践，可以分别解决不同领域的问题。可以组合使用，互相补充。

· 一条可以实行的实践原则，会比长篇大论的理论有用许多，没有实践原则指导的方法论没有意义。Scrum因为缺乏有效的编程实践，必须通过XP或其他方法来补充

· 使用XP，可以使开发人员成为更好的Developer， 但Scrum方法能够迫使那些效率低的developer变得更有效率。

· Nokia的Scrum标准

1. Scrum 团队必须要有产品负责人，而且团队都清楚这个人是谁。
2. 产品负责人必须要有产品的Backlog，其中包括团队对它进行的估算。
3. 团队必须要有燃尽图，而且要了解他们自己的生产率。
4. 在一个Sprint中，外人不能干涉团队的工作。

· scrum虽然强调文档、流程和管理的轻量化，但并不是意味着没有控制，没有计划，只是要做轻量的短期冲刺计划。强调的是每时每刻都要根据需求和开发情况对项目进行调整，从而达到提前交付

· ScrumMaster与传统项目经理相比，必须从从传统的控制者转变为引导者。

· scrum中，对任务细分和时间估计，需要整个开发小组和Product Owner的参与。

· Sprint计划会议议程

上午(2 Hours)

1)充实并讲解Product Backlog[Product Owner] (50 Minutes)
2)重新调整Product Backlog条目优先级[Product Owner] (10 Minutes)

休息(10 Minutes)

3)设定Sprint目标[Scrum Team] (10 Minutes)
4)选择Product Backlog条目，组成Sprint Backlog[Scrum Team] (40 Minutes)

下午(3-4 Hours)

1) 分成两个小组，进行任务细分， 定义"DONE"，给出任务估算. (60 Minutes)
2) 小组间互相评审，解决争议(20 Minutes)

休息(15 Minutes)

3) 关键路径分析(20 Minutes)
4) 制定资源计划(20 Minutes)
5) 任务领取(20 Minutes)
6) 风险分析(20 Minutes)
7) 其他事情(10 Minutes)

阅读详细......