转载:

Scrum敏捷开发,是一种敏捷开发框架,是一个增量的、迭代的开发过程,具备可视、可集成和可运行使用的特征。与传统的瀑布式开发模式不同,它更倾向于对一个复杂系统的局部模块做短平快的版本迭代,快速响应预期的市场需求验证。
浅谈Scrum敏捷开发:4个输入/输出、3个关键物、3个会议 - 图1
从图中可以看到,主要流程如下:

  1. 产品分析用户需求,按照商业价值依次排序估算,输出计划产品功能列表。
  2. 经过计划会议讨论,按照计划面板梳理功能列表,输出产品版本迭代任务。
  3. 进入开发迭代周期,按照任务面板增量迭代开发,输出可交付的迭代版本。
  4. 进入评审验收环节,按照发布面板汇总问题原因,输出迭代周期报表数据。

从上述流程中可以看到有4个输入/输出,3个关键物,3个会议,下面的我们依次了解一下这些内容。

4个输入/输出

1.用户需求,分析转化,产品BACKLOG

这个部分的内容由PM具体负责,主要的工作内容如下:

  • 用户调研、需求分析,确定产品迭代功能,出具产品BACKLOG。
  • 决定产品的发布日期与发布内容,给迭代计划预设目标。
  • 根据RIO(商业价值/工作量)排序优先级,考虑必要风险。
  • 制定Sprint计划,根据实际情况调整功能与优先级。

    2.产品BACKLOG,Sprint计划会议,Sprint BACKLOG

    这个部分的内容主要由开发经理负责,主要工作内容如下:

  • 将产品BACKLOG拆分为在本次Sprint中可细化的Sprint BACKLOG。

  • Sprint BACKLOG中的开发任务以小时估算,预计1-16小时的工作量化。
  • 根据开发优先级管理Sprint BACKLOG,随时更新Sprint BACKLOG状态。
  • 每个团队成员都可以自主挑选任务,修改Sprint BACKLOG。

    3.Sprint BACKLOG,迭代开发周期,可交付的迭代版本

    这部分内容主要由开发团队共同推进,主要工作内容如下:

  • 依照Sprint BACKLOG,开始开发工作,更新工作任务面板。

  • 参加每日例会,明确各团队的整体开发进度与开发难点。
  • 保证整体开发进度不大幅度的偏离预设的Sprint燃尽图。
  • 高度的自我组织管理,保持良好的跨职能团队沟通,确保实现Sprint目标。

    4.验收发布版本,评审回顾会议,周期数据报表

    这部分内容主要由Sprint团队成员共同参与,主要工作内容如下:

  • 产品开发团队通过操作演示的方式展示Sprint中完成的功能与架构。

  • PM根据产品BACKLOG,验收开发交付的迭代版本,发布产品迭代版本。
  • 收集Sprint问题反馈,寻找根本原因,讨论解决方法,改善Sprint过程。

    3个关键物

    1.产品BACKLOG

    由产品负责人维护管理的一个已排序,已估算,可渐进的需求清单列表,可参考PRD文档中的功能模块记录列表或者产品需求池的记录列表。在一般的情况下,会根据功能模块对应的用户故事流程来表示BACKLOG条目内容。在每个Sprint结束或者临时需求变更时,都需要更新优先级的排列顺序。
    如图:
    浅谈Scrum敏捷开发:4个输入/输出、3个关键物、3个会议 - 图2

    2.Sprint BACKLOG

    由开发负责人维护管理的一个Sprint任务清单,根据产品BACKLOG细化而来,细化为开发过程中可用的产品功能任务,每个任务用小时估算时间,团队成员可自行管理任务,每天的任务进度会更新到对应的任务面板上。
    如图:
    浅谈Scrum敏捷开发:4个输入/输出、3个关键物、3个会议 - 图3

    3.燃尽图

    燃尽图是指在1个Sprint周期内,工时/工作量的二维图表,主要是为了让团队成员明白在Sprint截止时间点前剩余开发工作量的整体情况,通过实际燃尽图与理想燃尽图的线性对比,可快速调整开发节奏,降低Sprint版本交付存在的风险。
    如图:
    浅谈Scrum敏捷开发:4个输入/输出、3个关键物、3个会议 - 图4

    3个会议

    1.Sprint计划会议(明确目标,细化任务)

    在Sprint计划会议上,需要明确Sprint目标与Sprint BACKLOG,讨论时要考虑团队的接受力,开发的速度、技术水平和商业条件等,提前确定好Sprint交付日期,增量迭代开发任务,产品版本迭代内容等。

    2.Sprint每日例会(定点,定时,人齐,会短,高效)

    每日进行的Scrum会议是团队交流的形式,固定地点,固定时间点,团队成员都参与,会议维持在15分钟左右,发言内容围绕昨日进度、今日安排、所遇困难三个方面快速的梳理一遍任务面板上的工作内容,所遇困难在会后点对点进行讨论解决。每例会是在Sprint周期内(2-4周)的开发进度反馈,在这个周期内,会经常更新任务面板。
    任务面板是“任务状态/工作进程”的二维工作面板,便签颜色可代表团队成员,便签内容代表团队成员所负责的开发任务。任务状态一般可划分为:ToDo,Doing,Tested,Reviewed,Finished五个状态,在一块方形划分区域中贴满了颜色便签,随时更新任务面板状态,保证团队所有成员随时随地都可以了解Sprint周期内的整体开发进度
    如图:
    浅谈Scrum敏捷开发:4个输入/输出、3个关键物、3个会议 - 图5

    3.Sprint评审回顾会议

    Sprint评审回顾会议主要有两个部分的内容,一是做Sprint交付版本与计划版本的验收,二是总结和完善后续Sprint的开发建设。

    我眼中的敏捷开发

    在笔者的眼中,敏捷开发作为一种团队协作方法论,高效与清晰是两个特别明显的特点,保持敏捷开发的理念开始Sprint工作的团队,一定有正向的开发BUFF加成,我们需要面对的是如何将敏捷开发的流程执行到位,最大化的获取加成收益。我很认同敏捷开发对于精英团队的加成是最大化的,因为大家目标清晰,技术能力完善,执行力强,这是最理想的工作模型。但对于现实中的非理想工作模型,我们可以从以下几个方面去加强这种团队加成效果:

  • 产品BACKLOG的来源一定要尽可能的准确,最好是有明确的数据分析结果作为支持依据,Sprint BACKALOG的任务细化尽可能细致,保证在后续的Sprint迭代过程中,团队的工作目标清晰明确。因为没有人会希望自己的工作量最后转化为无用功,而不是KPI,这对于团队士气是一种相当沉重的打击。如果还是出现了这种情况,Sprint负责人也要积极转移大家的情绪,劝慰大家尽快投入下一个更加正确的Sprint周期中去。

  • 团队成员之间要形成积极沟通的氛围,保证各职能团队之间的信息沟通准确对称。为了保证开发过程中灵活性,敏捷开发往往为了高效而不会过多的对成员做工作流程上的束缚,需求在迭代过程随时可发生变动,开发任务清单可由团队成员自主选择,任务面板由成员自主更新,是一种以沟通为主的工作模式。
  • 对于中国特色社会主义建设的国内而言,非理想工作模型下,团队成员往往更愿意被动的选择工作分配。开发经理应该合理的根据团队成员的能力维度安排工作任务清单,尽可能避免团队成员因为能力失控导致进度延期、工作效率低、工作情绪泛滥等不利于团队建设的情况出现。
  • 团队成员的组成结构在Sprint周期内尽量保证不变动,尤其是核心主导成员更不能做人事变动。在一个Sprint周期内,团队整体的开发关注力是需要高度集中的,如果这时团队的头部成员发生更换,一定会存在沟通成本损耗,影响整体迭代效率。
  • Sprint开发过程,会议的频次与时长需要做适当的把控。笔者参加过蛮多工作会议,个人觉得有些会议的RIO并不成正比,耗时且没有正向的工作计划输出,这往往是蛮多人都吐槽且不喜欢参加会议的原因。每次最好由负责人主导会议,做好会议相关数据报表的输入输出,阶段性的展示成果,给予团队积极的正向会议反馈。

其他资源: