敏捷开发 回顾
2009-10-13 10:29
302 查看
那该怎么做Sprint回顾呢?
第一点是找出在上一个Sprint中做得好的地方,并继续保持。分析那些导致成功的流程是非常重要
的,这样我们才能有意识地保持下去。只有团队中的每一个
成员都清楚什么才是最佳实践,才能有效地鼓励和保持这些实践。除了可以鼓舞士气外,还可以避免把回顾会议变成消极的抱怨会议。
第二点是找出
上一个
Sprint中需要改进的地方,以及对应的改进措施。回顾的目标就是持续不断地改进,这也是敏捷开发的主要理念之一。让我们想一想如何才能在下一个
Sprint中更加有效率,想一想在哪些方面如何做才能跟上一个Sprint不同。可以收集任何可以量化的数据,以便于做定量分析,推动改善。
其
他一些什么事情是要特别注意?
首先,一定要明确这样一个最高指导原则。即“无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能
力、可用的资源,以及手上的状况,我们理解并
坚信:每个人对自己的工作都已全力以赴”。
对团队成员的绩效评估,当然不能采用这样的指导原则。我们现在谈论的是
Sprint回顾,回顾的最终目的是学习,而不是审判。如果敏捷回顾没有确定这样的
“指导原则”,倡议团队成员信任自己的伙伴,就会让回顾会议成为互相攻讦、互相推诿的批斗大会,脱离了我们召开回顾会议的初衷。
“指
导原则”就是为回顾会议竖立一个标杆,那就是在项目开发中没有破坏者,没有替罪羊,没有关键人物,只有整个团队的利益。虽然某个人或许在上一次迭代中
出现了错误,但我们会善意地相信此人之所以犯下错误,并非有意为之或者消极怠工,而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误,并试
图总结出最佳实践以避免在下一次迭代中犯下同样的错误,而“指导原则”则能够消除因为错误的指出而给成员带来的负疚感,消除同事之间可能因此出现的隔阂与
误解。换句话说,回顾会议提出的所有批评都应该“对事不对人”。
组织Sprint
回顾的最简单方法是找个白板纸,在上面注明“哪些项工作顺利”,“哪些项不成功”或者“哪些项可以做得更好”,然后让与会者在每一类别下增加一些条目。当
条目重复时,可以在该项旁边计正字累计,这样普遍出现的项目就一目了然了。最后团队成员共同讨论,找寻这些条目出现的根本原因,就如何在下一个
Sprint 中改进达成一致意见。
敏捷回顾的主要工作就是明确目标、持续改进、处理问题。
敏捷开发之所以采用迭代的方式,实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一
个个小目标,会给予团队成员更大的信心,并且能够更加清晰地明确目标。而每次迭代后的回顾,则使得团队成员可以更加清晰地明确我们在这个征途中,已经走到
了哪里,未来还有多远的路程,就像印第安人那样,等待自己的灵魂,否则就会不知身在何处了。
第一点是找出在上一个Sprint中做得好的地方,并继续保持。分析那些导致成功的流程是非常重要
的,这样我们才能有意识地保持下去。只有团队中的每一个
成员都清楚什么才是最佳实践,才能有效地鼓励和保持这些实践。除了可以鼓舞士气外,还可以避免把回顾会议变成消极的抱怨会议。
第二点是找出
上一个
Sprint中需要改进的地方,以及对应的改进措施。回顾的目标就是持续不断地改进,这也是敏捷开发的主要理念之一。让我们想一想如何才能在下一个
Sprint中更加有效率,想一想在哪些方面如何做才能跟上一个Sprint不同。可以收集任何可以量化的数据,以便于做定量分析,推动改善。
其
他一些什么事情是要特别注意?
首先,一定要明确这样一个最高指导原则。即“无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能
力、可用的资源,以及手上的状况,我们理解并
坚信:每个人对自己的工作都已全力以赴”。
对团队成员的绩效评估,当然不能采用这样的指导原则。我们现在谈论的是
Sprint回顾,回顾的最终目的是学习,而不是审判。如果敏捷回顾没有确定这样的
“指导原则”,倡议团队成员信任自己的伙伴,就会让回顾会议成为互相攻讦、互相推诿的批斗大会,脱离了我们召开回顾会议的初衷。
“指
导原则”就是为回顾会议竖立一个标杆,那就是在项目开发中没有破坏者,没有替罪羊,没有关键人物,只有整个团队的利益。虽然某个人或许在上一次迭代中
出现了错误,但我们会善意地相信此人之所以犯下错误,并非有意为之或者消极怠工,而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误,并试
图总结出最佳实践以避免在下一次迭代中犯下同样的错误,而“指导原则”则能够消除因为错误的指出而给成员带来的负疚感,消除同事之间可能因此出现的隔阂与
误解。换句话说,回顾会议提出的所有批评都应该“对事不对人”。
组织Sprint
回顾的最简单方法是找个白板纸,在上面注明“哪些项工作顺利”,“哪些项不成功”或者“哪些项可以做得更好”,然后让与会者在每一类别下增加一些条目。当
条目重复时,可以在该项旁边计正字累计,这样普遍出现的项目就一目了然了。最后团队成员共同讨论,找寻这些条目出现的根本原因,就如何在下一个
Sprint 中改进达成一致意见。
敏捷回顾的主要工作就是明确目标、持续改进、处理问题。
敏捷开发之所以采用迭代的方式,实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一
个个小目标,会给予团队成员更大的信心,并且能够更加清晰地明确目标。而每次迭代后的回顾,则使得团队成员可以更加清晰地明确我们在这个征途中,已经走到
了哪里,未来还有多远的路程,就像印第安人那样,等待自己的灵魂,否则就会不知身在何处了。
相关文章推荐
- 敏捷开发历程回顾
- [转]敏捷十年简史回顾——影响敏捷开发历程的27件事
- 敏捷开发历程回顾
- 101与金根回顾敏捷个人:(13)敏捷个人和敏捷开发
- 淘女郎团队敏捷开发实践2011上半年回顾
- 敏捷开发历程回顾
- 一个敏捷回顾-游戏开发
- 敏捷开发历程回顾
- 敏捷开发-回顾会议
- 9个月,回顾一下敏捷开发的得失
- 敏捷开发:如何通过回顾保持学习状态
- 敏捷开发:如何通过回顾保持学习状态
- 项目管理---敏捷开发---到底要不要写文档?
- 敏捷开发:IT人应该做的创新与变
- VS2010 中的敏捷开发
- 11、Windows驱动开发技术详解笔记(7) 基本语法回顾
- JAVA wed 开发知识回顾
- 我对各敏捷开发方法的大致理解
- 转载 C#中敏捷开发规范
- 敏捷开发绩效管理之四:为团队设立外部绩效目标(目标管理,外向型绩效)