磕磕绊绊的Scrum之行(八)Sprint 3开始

11月22日团队调整了一天,11月23举行了Sprint 3计划会议一,在会议中提出了以下计划:
1.定义冲刺周期:11.23~12.31
2.提出本次冲刺的目标:a.完成系统A alpha 版本发布,b.完成系统B alpha 版本发布;
3.人日投入计划;
4.简述两个系统的功能;
5.定义各个里程碑时间点。

11月25日开始Sprint 3计划会议二,对Sprint Backlog进行评估,Backlog由我提出,向一名团队成员讲解后一起填入。评估一共有四轮:

第一轮对Backlog进行删减,移除不需要的Backlog,决策者是技术总监,此次删减了3个,原因是涉及到关键利益,业务上要制造流程复杂性,故不实现信息化;

第二轮是进行指标度量,度量的指标有业务价值、需求不确定性、复杂度、风险、工作量。开始时,一名团队成员表示不理解什么叫“业务价值”,以及业务价值是应该站在开发的角度上进行衡量还是业务部门的角度上进行衡量。我和技术总监的回答是:按你的理解来评估。因为我们的目标是一步一步让开发团队向产品团队转变,这就需要开发人员能够从商业上理解自己做的程序功能。这轮的结果是大家整体上还是有共识。(下次的话,我准备不公开评估)

第三轮是任务分解和工时评估,将所有待做的任务定义出来。这轮遇到了不少的阻力,开发人员提出任务分解应由项目经理定义好后他们可以主动领取,我的理解是他们现在还不知如何着手定义任务。于是我在会议上开始单独定义任务。技术总监认为毕竟大家是每一次这样搞,有个适应期,可以继续试着让他们定义。最后的结果是我定义了绝大部分任务,剩下的由团队提出。此轮评估的结果是针对系统A的预估工时已经用完了Sprint 3的全部时间,于是大家一起讨论,最后与每位成员确认Sprint 3我们的新目标是仅交付系统A的alpha版本。在此轮中,有两项任务大家都无法预估时间,于是被标为“阻塞”,并在确定具体方案之前,不排入计划之中。另一个评估时间很长(70~84小时)的任务被分解成一组小任务再进行预估,经分解的最小估算是45小时。

第四轮是任务优先级安排和任务领取,比较顺利,也因此确定了下周的工作计划。

最后会议收尾,调整了一下计划会议一中定义的里程碑时间。

一个团队的效率取决于这些技巧:
1.在没有依赖关系的情况下,先做简单、费时少的任务;
2.衡量一个任务是否进入开发计划,请用SMART原则进行检查。

此外团队也有一些调整,在Sprint 3开始之前我手中的工作依然堆积得非常多,业务沟通、原型设计、功能说明、管理,都要抓起来。因此我开始安排组里的新手开始跟着我学习User Story的编写和原型的绘制,以分担一些任务,他在渐渐地上手并会负责整个界面开发。

一个团队的成长在于,有经验的人为后来者照亮道路,但绝不是铺平道路。

© 2018 Silent River All Rights Reserved. 本站访客数人次 本站总访问量
Theme by hiero