2007年7月21日

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

阅读详细......

2007年7月14日

敏捷精灵日记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来跟踪细分任务的完成情况,可以在项目进程的任何时间点都能够看到项目进展状况,而不是每周或者项目完成之后,从而保证了开发进度处于可控制的状态。

阅读详细......

2007年7月7日

敏捷精灵日记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)

阅读详细......