文档首页 > > 理论实践> 持续规划与设计>

冲刺计划最为关键

冲刺计划最为关键

分享
更新时间:2020/12/24 GMT+08:00

怎么判断一个团队是否真的在实施Scrum呢?

  • 迭代开发

    首先,要看是否采取了迭代开发的方式。多年来,业界一直使用迭代式的、增量式的开发,这似乎已经成为所有敏捷过程的基础元素了。如果不这样做,甚至都不能称为敏捷的软件开发过程。这是因为敏捷希望整个软件开发流程中的所有人都可以一起工作,大家都要对产品非常了解:无论是构建产品的人,测试产品的人,还是将会使用产品的用户。如果把过程分隔成“这里的这些人编写需求说明和规范,然后他们把文档交给负责构建软件的人,软件构建者再将软件转给测试人员,最后测试人员把软件提供给客户”。客户如果说那不是他们真正需要的东西,一切就要回到开头,再来一次。如此反复三遍的话,客户就会取消这个项目了。这就是为什么世界上有那么多项目被砍掉的原因。

  • 固定的迭代周期

    “你们有固定的迭代周期吗?你们的迭代是否以某个特定的时间开始并以某个固定的时间结束?”在诺基亚,迭代周期必须少于4周。如果不是这样做的,那么就没有进行迭代开发。

  • 可以工作的软件

    “在每个迭代结束的时候,你们有可以工作的软件吗?”如果不能给出可以工作的软件的话,那也就是没有进行敏捷开发。

  • 不需要细节完整的需求说明

    “你希望在结束时拥有可工作的软件,那么在可以开始迭代之前,你们的团队是不是必须要有一个细节完整的需求说明?”如果需要的话,那就不是敏捷开发。

  • 在开发过程中进行测试

    “要在迭代结束时拥有可以工作的软件,将测试作为迭代增量开发的一部分是非常重要的。你们在开发过程中进行测试吗?”。

Nokia的Scrum规则是什么?

  • Product Owner

    “你们是否有Product Owner?是不是有人可以代表客户与你们一起工作?”当团队在决定应该构建什么样的产品时,这个人就是他们要询问的对象,这个人代表着客户的需求与利益。这个人就像开车时,把握方向盘的人, 决定着团队前进的方向,他要为产品的成功负责!

  • Product Backlog

    “如果有Product Owner,他们是否拥有一个待开发功能的Product Backlog?此Backlog是否根据业务价值排定了优先级?是否已经对其进行了估算?”。

  • Burndown Chart

    “团队在开发过程中, 有没有使用Burndown Chart(燃尽图),来展示当前迭代中随着时间的推进,剩余工作量的变化,用以跟踪进度,并且能否基于燃尽图来推算团队的速度?”Product Owner可以根据团队整体速度来构建发布规划;同时团队可以根据它来改进流程。只有知道自己的速度如何,才有助于一个团队进行更好的估算,同时帮助他们在继续后续工作时提升速度。通过燃尽图,可以有效地预测团队是否能够按时完成当前Sprint计划的工作;如果不能,可以及时进行调整。

  • 自组织的团队

    Scrum团队依赖自组织的过程,这就意味着团队负责挑选工作、职责分配,并要找出最快交付工作的途径。所以,诺基亚的最后一条规则是:在迭代中,项目经理不能干涉团队工作,因为这会停止自组织的过程,并且得到解决方案的过程将不再是最优化的了。

关于Sprint计划会议

  • 成员

    Sprint计划会议除了你的团队成员和Product Owner外,还可以邀请更多的人参加。

    在Scrum框架下,没有“个人”的概念,Scrum依靠的是团队的力量。尽管Scrum Master在这个框架下的作用很重要,但这个人不是独裁者。做Sprint计划时,一定要让整个团队参加。

  • Sprint目标

    首先,你们要先定下来Sprint的目标,即作为一个团队,你们要完成什么,然后再决定完成多少。事先计算出在一个Sprint内,团队的可能工作时间。然后从产品Backlog中,按照优先级从高到低,选择出你们认为能在迭代内完成的条目,作为你们当前Sprint的Backlog。注意:选择的Sprint Backlog条目一定要强内聚、松耦合,这样你们才能不受或者少受外界的干扰,目标明确。任务细化之外,还有一个非常重要的部分:对于每个细化后的任务,都需要一个非常明确“完成(Done)”的定义。这一点非常重要,必须保证每一个人的理解是正确的、一致的。

    做Sprint任务细化时,一个最佳实践就是把每个任务控制在1~2天内完成。任务太细,会涉及更多的微观管理;太粗,估算就会不准确。

  • 认领任务

    下一步,就是让大家自己认领任务,而不是指派!这一点非常关键。

    首先,每个人认领任务后,实际上就是对整个团队有了一个承诺,更能保证按计划完成。其次,让每个人选择自己愿意做的事情,这样才会更有主动性,毕竟“做自己有兴趣的事情,才会真的做好”。这样,不仅满足了个人发展的需要,还可以达到快速的知识共享、团队技能的整体提高。

  • 会议日程

    此外,跟任何其他会议一样,对于计划会议,确定好会议日程非常重要。

    因为Sprint计划会议一定要基于Time-Boxed(时间盒),在规定的时间内,一定要结束,就像一个Sprint一样,同样要有紧迫感。

    Sprint计划会议必须在一个完整天内开完。

  • 任务工作量的估算

    可以采用Delphi方法进行任务工作量的估算。当进行任务细化的时候,

    每个人的估算是不一样的,如果最高估算值与最低估算值相差很多,二者就要沟通一下,看看为什么二者的理解相差这么多。沟通明白后,再重新估算。即使这样,还是会有分歧的,此时采用Delphi估算方法,简单讲就是进行一次加权平均。

    一些注意事项

    产品负责人(Product Owner)一定要参加。实在不能参加的话,也要指定一个人授权代理。否则,就不要开Sprint计划会议。

    虽然我们采用了Scrum,但即使不再采用甘特图,但是传统的风险依赖分析还是不要丢弃。在Sprint计划会议结束前,进行风险依赖分析,还是会帮助我们发现一些问题的,然后再稍微调整任务的优先级,更能保证Sprint的成功。

Scrum Master可以替代Product Owner吗?

首先,Product Backlog是Scrum的核心,从根本上说,它是一个需求或故事或特性组成的列表,并且按照重要性进行了排序,一定是客户想要的东西,并且用客户的语言进行描述。通常除了客户需求之外,还会包含技术性需求,譬如架构相关、性能相关的事情;还会包含Bug;还有探针Spike,这个属于探索性需求,是对未来的一个预研,不会真的发布给客户。此外,有的时候还需要把重构的事情也放进去,一起排序。

其次,在维护产品Backlog的时候,Product Owner(就是那个能代表最终客户发言的人)必须参加,由他排列优先级。Product Owner必须是离客户最近的人,你作为研发项目管理人员,不可能是离客户最近的人。如果没有这个角色,你们怎么知道哪个重要哪个不重要?和Product Owner交流,你们才可以得到一个有优先顺序的列表,把最重要的功能放在列表的前面。每一个条目应该有一个估算,这个并不需要很准确,只需要有一个大概的估算即可,这样才能够决定把多少工作放到一个Sprint里。

第一个Sprint后遇到问题,是否马上放弃Scrum转型?

只做了一个Sprint,不要着急下结论说Scrum适合或不适合。Scrum可以让你从另外一个角度来思考如何进行项目管理。找到窍门总是需要花些时间的。坚持这个流程,至少做完3个Sprint,然后再决定是否继续。第一次冲刺肯定会遇到问题的,你们可以回顾总结一下,把一些能操作的改进加到第2个Sprint中,逐步做出改善。这样,经过3个Sprint,你们才会真正地了解Scrum。

计划冲刺的要点

  1. Scrum注重的是管理和组织实践,XP关注的是编程实践,分别着重解决不同领域的问题。可以组合使用,互相补充。
  2. 一条可以实行的实践原则,会比长篇大论的理论有用许多,没有实践原则指导的方法论没有意义。Scrum因为缺乏有效的编程实践, 必须通过XP或其他方法来补充。
  3. 使用XP,可以使Developer(开发人员)成为更好的Developer,但Scrum方法能够迫使那些效率低的Developer变得更有效率。
  4. 诺基亚的Scrum标准如下
    • Scrum团队必须要有产品负责人(Product Owner),而且团队都清楚这个人是谁。
    • 产品负责人必须要有产品的Backlog,其中包括团队对它进行的估算。
    • 团队应该要有燃尽图,通过它了解自己的生产率。
    • 在一个Sprint中,外人不能干涉团队的工作。
  5. Scrum虽然强调文档、流程和管理的轻量化,但并不是意味着没有控制,没有计划,只是要做轻量的短期冲刺计划。强调的是每时每刻都要根据需求和开发情况对项目进行调整,从而达到提前交付
  6. Scrum Master与传统项目经理相比,必须从传统的控制者转变为引导者。
  7. Scrum中,对任务细分和时间估计,需要整个开发小组和Product Owner的参与。
  8. Sprint计划会议议程,根据迭代周期长短做调整。
    • 充实并讲解Product Backlog[Product Owner](20 分钟)。
    • 重新调整Product Backlog条目优先级[Product Owner](5 分钟)。
    • 设定Sprint目标[Scrum Team](5 分钟)。
    • 选择Product Backlog条目组成Sprint Backlog[Scrum Team](40 分钟)。
    • 会间休息(10 分钟)
    • 分成两个小组,进行任务细分,定义DONE,给出任务估算(40 分钟)。
    • 小组间互相评审,解决争议(20 分钟)。
    • 关键路径分析(10 分钟)。
    • 任务领取(10 分钟)。
    • 风险分析(10 分钟)。
    • 总结。

那些年,我们一起踩过的坑

敏捷路上各种坑,没踩过坑,你都不好意思说自己是在做敏捷。平平安安、一帆风顺的就把敏捷落地了的,恐怕你做的是假敏捷。

第一个冲刺经历的那些坑,例如不按优先级选取需求、指派任务、不是集体做出估算、过程不可见等都很常见。单以站会为例,就有时间不固定、人员迟到缺席、站会坐着开、不控制时间、讨论具体细节等诸多的坑。

历经踩过的坑,从坑里爬起来,分析总结持续改进的过程,是将敏捷固化,形成肌肉记忆的过程。

踩到的坑有大有小,有时甚至需要跨越鸿沟;转型的过程也并非一帆风顺,往往伴随一段时期的效率下降;要有心理预设,要给团队,甚至于给领导打预防针。如同跑步一样,习惯的养成需要时间,在此过程中,你会历经痛苦,会有疲劳期,但坚持过去, 才会脱胎换骨。回首过往,你和团队会惊诧于自己的改变,以至于无法接受再回到以前的状态,此时你的敏捷才算是初见成效。

先僵化,后固化,再优化

诺基亚的Scrum标准,是一个很典型的Checklist(检查清单)。每一个方法论,无论是Scrum、Kanban还是XP,都有一套规则,这些规则之间彼此紧密关联,背后是对敏捷原则的遵从。初识敏捷,在对原则和实践没有深刻理解的时候,建议先以一种方法论框架为基础,先僵化地遵循规则,固化沉淀到团队日常工作行为甚至工具平台上;真正跑过三个Sprint,对Scrum有了一定的理解之后,再考虑是否需要根据团队和项目的真实情况,进行适度的调整和优化。

需要注意的是,优化时始终要用敏捷原则进行检查,人是有惰性的,敏捷的很多实践在某种程度上是与人的天性相违背的;敏捷需要团队自律,甚至比传统的研发模式更强调纪律;因为惰性而偷工减料的,不是优化而是简化。

XP(极限编程)

我曾经坚持认为,XP就只是工程实践,重读了肯特·贝克(Kent Beck)的《解析极限编程》才意识到,极限编程的12个实践(计划游戏、小版本、隐喻、简单设计、测试驱动、重构、结对编程、集体所有权、持续集成、每周工作40小时、现场客户、编码标准),事实上囊括了计划、迭代、设计、架构、开发、测试、集成等较为完整的研发过程;虽然名为极限编程,事实上已经不只是工程类的实践而已。肯特·贝克(Kent Beck)作为敏捷宣言排名第一(按字母排序的)的大师,果然名不虚传,XP中测试驱动、持续集成、重构、集体所有权等实践,又进一步成为持续交付的核心内容,被捷兹·休伯(Jez Humble)在《持续交付》一书中继承。

要阅读经典,这是提升自己最直接的方式,是与大师精神相遇,思维碰撞的过程;而发现这些大师经典之间内在的关联,是真正理解方法论背后逻辑与模式的过程;梳理各方法论体系,尤其是彼此之间的差异与继承关系,是形成自己独立的方法论体系的过程。

  

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)。

  

分享:

    相关文档

    相关产品

文档是否有解决您的问题?

提交成功!非常感谢您的反馈,我们会继续努力做到更好!
反馈提交失败,请稍后再试!

*必选

请至少选择或填写一项反馈信息

字符长度不能超过200

提交反馈 取消

如您有其它疑问,您也可以通过华为云社区问答频道来与我们联系探讨

智能客服提问云社区提问
{{site}}{{lan}}
{{site}}{{language}}