zoukankan      html  css  js  c++  java
  • 浅谈Scrum敏捷开发:4个输入/输出、3个关键物、3个会议

    文章对Scrum敏捷开发流程进行系统的分析,希望借此文能够加深你对敏捷开发的认知,更好的展开产品工作。

    Scrum敏捷开发,是一种敏捷开发框架,是一个增量的、迭代的开发过程,具备可视、可集成和可运行使用的特征。与传统的瀑布式开发模式不同,它更倾向于对一个复杂系统的局部模块做短平快的版本迭代,快速响应预期的市场需求验证。

    从图中可以看到,主要流程如下:

    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结束或者临时需求变更时,都需要更新优先级的排列顺序。

    如图:

    2.Sprint BACKLOG

    由开发负责人维护管理的一个Sprint任务清单,根据产品BACKLOG细化而来,细化为开发过程中可用的产品功能任务,每个任务用小时估算时间,团队成员可自行管理任务,每天的任务进度会更新到对应的任务面板上。

    如图:

    3.燃尽图

    燃尽图是指在1个Sprint周期内,工时/工作量的二维图表,主要是为了让团队成员明白在Sprint截止时间点前剩余开发工作量的整体情况,通过实际燃尽图与理想燃尽图的线性对比,可快速调整开发节奏,降低Sprint版本交付存在的风险。

    如图:

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

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

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

    每日进行的Scrum会议是团队交流的形式,固定地点,固定时间点,团队成员都参与,会议维持在15分钟左右,发言内容围绕昨日进度、今日安排、所遇困难三个方面快速的梳理一遍任务面板上的工作内容,所遇困难在会后点对点进行讨论解决。每例会是在Sprint周期内(2-4周)的开发进度反馈,在这个周期内,会经常更新任务面板。

    任务面板是“任务状态/工作进程”的二维工作面板,便签颜色可代表团队成员,便签内容代表团队成员所负责的开发任务。任务状态一般可划分为:ToDo,Doing,Tested,Reviewed,Finished五个状态,在一块方形划分区域中贴满了颜色便签,随时更新任务面板状态,保证团队所有成员随时随地都可以了解Sprint周期内的整体开发进度

    如图:

    3.Sprint评审回顾会议

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

    我眼中的敏捷开发

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

    • 产品BACKLOG的来源一定要尽可能的准确,最好是有明确的数据分析结果作为支持依据,Sprint BACKALOG的任务细化尽可能细致,保证在后续的Sprint迭代过程中,团队的工作目标清晰明确。因为没有人会希望自己的工作量最后转化为无用功,而不是KPI,这对于团队士气是一种相当沉重的打击。如果还是出现了这种情况,Sprint负责人也要积极转移大家的情绪,劝慰大家尽快投入下一个更加正确的Sprint周期中去。
    • 团队成员之间要形成积极沟通的氛围,保证各职能团队之间的信息沟通准确对称。为了保证开发过程中灵活性,敏捷开发往往为了高效而不会过多的对成员做工作流程上的束缚,需求在迭代过程随时可发生变动,开发任务清单可由团队成员自主选择,任务面板由成员自主更新,是一种以沟通为主的工作模式。
    • 对于中国特色社会主义建设的国内而言,非理想工作模型下,团队成员往往更愿意被动的选择工作分配。开发经理应该合理的根据团队成员的能力维度安排工作任务清单,尽可能避免团队成员因为能力失控导致进度延期、工作效率低、工作情绪泛滥等不利于团队建设的情况出现。
    • 团队成员的组成结构在Sprint周期内尽量保证不变动,尤其是核心主导成员更不能做人事变动。在一个Sprint周期内,团队整体的开发关注力是需要高度集中的,如果这时团队的头部成员发生更换,一定会存在沟通成本损耗,影响整体迭代效率。
    • Sprint开发过程,会议的频次与时长需要做适当的把控。笔者参加过蛮多工作会议,个人觉得有些会议的RIO并不成正比,耗时且没有正向的工作计划输出,这往往是蛮多人都吐槽且不喜欢参加会议的原因。每次最好由负责人主导会议,做好会议相关数据报表的输入输出,阶段性的展示成果,给予团队积极的正向会议反馈。
  • 相关阅读:
    LeetCode 258 Add Digits
    LeetCode 231 Power of Two
    LeetCode 28 Implement strStr()
    LeetCode 26 Remove Duplicates from Sorted Array
    LeetCode 21 Merge Two Sorted Lists
    LeetCode 20 Valid Parentheses
    图形处理函数库 ImageTTFBBox
    php一些函数
    func_get_arg(),func_get_args()和func_num_args()的用法
    人生不是故事,人生是世故,摸爬滚打才不会辜负功名尘土
  • 原文地址:https://www.cnblogs.com/zhaoquanhua/p/8651912.html
Copyright © 2011-2022 走看看