2008年2月28日

Scrum介绍系列9--- 产品发布计划(release plan)

Sprint 持续直至产品所有者决定产品已经可以准备发布,此时会有“发布Sprint“来进行最后的整合和发布产品前的检测。如果开发团队一直贯彻很好的开发方法,不断地重构和持续集成,在每一Sprint 中的有效测试,就不会存在许多遗留问题需要清除。

有这样一个问题有时会被提到,是怎样在一个迭代的模式中产生长期的发布计划。在一个项目的起始阶段,开发团队会作出粗线条的发布计划;他们不可能预先得知工作的结果,其重点是创建一个大体的计划提供给项目发展一个大体的方向,并阐明交易决策如何形成(比如范围相对于进度表)。以此作为路标来指引你向目标迈进;在行程中你实际挑选的路程和所做的决策都是途中决定的。


有一些产品发布是以日期界定的;比如:“我们会在11 月10 日的产品展示会上发布我们项目的2.0 版。“在此种情况下,开发团队会在现有的可利用时间内完成尽可能多的Sprint(构建尽可能多的功能)。有些产品要求某部分构建完成才可以说明整个产品的完成,产品不会在这些要求满足前被发布,无论周期长短。Scrum 强调在每一Sprint 中都生产出可以随时交付的编码,开发团队可以进行中间的发布,使客户可以更快的收到产品的效益。


大多数产品所有者会选择一个发布方式,但是会通知其他的——比如,他们会决定发布日期,他们会与开发团队成员一起对Backlog 中项目的完成日期做一大体的估算。在“固定价格/固定日期/固定交货期”的情况下——比如,合同制开发——在这些变量中至少有一个内部存在缓冲区,可以容许不确定因素和变更;在此方面,Scrum 于其他的开发方法并无区别。
阅读详细......

2008年2月22日

Scrum介绍系列8--- 如何开始下一个Sprint

在Sprint 评审会议之后,产品所有者将提取所有建议,和在Sprint 中产生的新的优先权项目,并将这些项目合并于Product Backlog 之中;增加新的项目,现有项目进行了更改,重新排序或删除。当Product Backlog 的更新完毕,循环周期可以再次开始,以下一个Sprint 计划会议为开端。

许多开发团队感觉在每个Sprint 末期进行优先化的会议很有意义,和产品所有者一起对下一Sprint 中的Product Backlog 项目进行评审。除了给开发团队的一个机会提醒产品所有者其未注意的事项——技术维护,比如——此会议也开始了在Sprint 计划会议之前所需的初步想法。

在各Sprint 之间没有间隔期——开发团队通常在下午时间进行了Sprint 评审,第二天上午就进行下一Sprint 计划会议。Agile 开发的价值观之一是“可持续性“,只有在正常的工作时间和劳动强度下,开发团队才可以继续此周期的持续。
阅读详细......

2008年2月19日

敏捷精灵日记16

[敏捷精灵日记]


1。产品层次的Scrum-of-Scrums

议程安排:由每个团队的Scrum Master描述一下上次开会以来各自的团队都完成了什么事情,下次开会前计划完成什么事情,遇到了什么障碍。除了这些常规话题外,尤其应该交流跟跨团队协作相关的的问题,例如集成问题,团队平衡问题


2。团体层次的Scrum-of-Scrums

会议形式为:
1) 开发主管介绍最新情况。例如即将发生的事件信息。
2) 大循环。每个产品组都有一个人汇报他们上周完成的工作,这周计划完成的工作,及碰到的问题。其他人也会作报告(配置管理领导,QA领导等)
3) 其他人都可以自由补充任何信息,或者提问问题。


会议组织:

建议全体开发人员都来参加,让每个人了解其他团队在做些什么。主要以报告形式进行,由每个组的Scrum Master负责自己团队的报告。会议主持人要严格控制会议的时间,尽量避免出现真正的讨论。


3。 Scrum-of-Scrums的议程无关紧要,关键在于要有定期召开的Scrum-of-Scrums会议,进行沟通交流。


阅读详细......

2008年2月11日

Scrum介绍系列7--- Sprint 回顾(sprint retrsopective)

同学门,请注意!这个阶段也是Scrum的核心之一,只有回顾,才能真正做到六个西格玛里面的PDCA!

Sprint 评审之后,开发团队会进行Sprint 回顾。有些开发团队会跳过此过程, 这是不合适的,因为它是使Scrum 成功的重要方法之一。这是提供给开发团队的非常好的机会,来讨论什么方法能起作用而什么不起作用,并一致通过改进的方法。Scrum 开发团队,产品所有者和ScrumMaster 都将参加会议,会议由外部中立者主持;一个很好的方法是由ScrumMaster 互相主持对方的回顾会议,可以起到各团队间信息传播的作用。

组织Sprint 回顾的最简单方法是在墙上挂两张张贴画大小的白板纸,纸上注明“哪些项工作顺利”,“哪些项不成功或者哪些项可以做的更好”——让与会者在每一类别下增加些项目。当项目重复时,可以在该项旁边记正字累计,这样一些比较普遍出现的项目就一目了然了。然后团队成员共同讨论找寻这些项目出现的根本原因,同意在下一个Sprint 中的改进计划,并负责在下一个Sprint 回顾会议上评审项目结果。

另一种方法是让团队成员在每一类下的项目中,用“C”标记如果其根源是Scrum,或用“V”标记如果其是由Scrum 显现出来的(换句话说,无论Scrum 存在与否该项目都会发生,但是Scrum 使开发团队注意到了该项目的产生)。开发团队会在“哪些项目工作顺利”下发现许多的C 标记,在“哪些项目不成功”下有许多的V 标记;这是个非常好的现象,即使“哪些项目不成功“是比较长的列表,因为解决问题根本原因的第一步就是让其显现出来,Scrum 正是此作用的强有力的促进因素。
阅读详细......

2008年2月8日

Scrum介绍系列6--- Sprint 评审(sprint review)

在Sprint 结束后,将进行Sprint 评审,团队在此期间展示他们所构造的产品。出席此会议的有产品所有者,开发团队成员,ScrumMaster,加上客户,项目管理者,专家,高层人士和任何对此感兴趣的人。这不是开发团队做成果“演讲”——会议上不会有PowerPoints 图片文件,通常会议不会需要超过30 分钟的准备时间——这只是简单的展示工作结果,所有与会人员可以提出问题和建议。会议可以持续10 分钟,也可以是两个小时——会议目的只是对工作结果的展示和听取反馈
阅读详细......

2008年2月3日

Scrum介绍系列5--- 每日站立例会(Daily standup meeting)

每当Sprint 开始, Scrum 开发团队将会实施另一个Scrum 的重要实践方法:每日(站立)例会。这是在每个工作日特定的时间举行的短小(15 分钟)的会议,Scrum 开发团队的每一成员都将参与;为了保证其短小精悍,与会成员都保持站立(因此为“站立会议”)。以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍。

一个接一个,每个团队成员只可以向其他人汇报三件事情

  • 从上次会议之后完成了哪些工作,
  • 在下次会议之前准备完成哪些工作,
  • 在工作进行中存在哪些障碍。

ScrumMaster 将会把障碍内容记录下来,在会后协助团队成员铲除障碍。在每日的(站立)例会中不容许讨论,只是将以上三个重点信息做一汇报;如果需要讨论,将在会后进行。产品所有者,经理和项目管理者可以参加会议,但是他们应该在会议结束以前避免问问题或提出讨论——每一与会者应该清楚的是开发团队是在互相汇报和交流情况,并不是向产品所有者,经理或ScrumMaster 汇报。这个会议并没有标准形式,有些团队感觉邀请产品所有者参加并将其每日工作做一简要阐述,是对团队工作极其有意义的。

在会议结束后,开发团队成员将对其负责的Sprint Backlog 中的项目做剩余时间的更新。这些信息会记录在Sprint Burndown Chart 图表中(图示5)。它是用来显示每日直至开发团队完成全部任务的剩余工作量(以小时或天计算)。理想的情况下,抛物线轨道在Sprint 的最后一天应该接触零点。有些时候会是这样,但是大多数情况不是这样。重要的是它体现了团队在相对于他们的目标的实际进展情况——并不是目前花费了的时间的多少(对于Scrum 来说这是不太相关的事项),而是仍剩余多少工作量——开发团队仍距离完成任务多远。如果此曲线的轨道在Sprint 末期不是趋于结束,那么开发团队应该加快速度,或简化和削减其工作内容。此图表也可以使用Excel 表格管理,许多团队认为在他们工作室的墙上用图纸标明更为简单和有效,并可以用笔随时更新;这个技术含量不高的做法比电子表格更快速,简易和更可见。
Scrum 的核心原则之一是Sprint 的周期不可以延长——其结束于指定的时间不论开发团队完成任务与否。如果开发团队未完成其Sprint 目标,他们将在Sprint 的末期声明他们没有完成预期的任务。这个方法创造了反馈循环的可视性,并强制开发团队在Sprint 预期估算时做出更好的判断,并确保可以按时完成任务不会失败。开发团队通常在前几个Sprint 时试图完成许多任务,但实际上并不可以达到Sprint 目标;然后他们可能会过度小心而挑选较少的任务,结果会提前完成;在第三或第四个Sprint 时,开发团队通常会了解自己的工作效率,他们会按时完成Sprint 的目标。鼓励开发团队在某一Sprint 中挑选一个周期(比如两周)并且不经常变化——固定的周期可以帮助开发团队了解他们的实际工作效率,并且可以帮助其达到工作的节奏性(此指团队的统一“心跳”)。
阅读详细......