Scrum 实操流程

原创
2020/08/31 14:21
阅读数 1K

    Scrum 是用于开发、交付和持续支持复杂产品的一个框架,是一个增量的、迭代的开发过程。

     

    敏捷的原则和方法 必须在每天的实践中落地,对人和管理要求高。所以有scrum master

     

    为了适应变化,敏捷的迭代周期短

     

    特征

    1. 迭代开发 :这意味着你应该重复开发过程。

    2. 增量交付 :意味着你应该一步一步地创建产品的“可用”子集,而不是在项目结束时一次性交付。

     

    原则

    • 迭代是受时间框限制的,也就是说即使放弃一些功能,也必须结束迭代。

    • 每次迭代结束的时候让产品达到可交付状态十分重要, 每次迭代都以一个可运行的产品的公布而结束。

    • 迭代开发是在变与不变中寻求平衡,在迭代开始的时候寻求变,而在迭代开发期间不能改变,以期集中精力完成已经确定的工作。由于一次迭代的时间并不长,所以就使稳定性和易变性得到很好的平衡。经验证明:4周是非常好的时间。

    • 能否每个Sprint生成满足质量定义的PSPI      是Scrum 执行效果的试金石。

     

     

    角色
     
     

    product owner

    作为产品负责人,PO清楚地知道产品的愿景,需要对产品待办列表的梳理、优化、优先级排序等负责。PO决定Why和What,一般可以对应为我们理解的产品经理和业务分析师的角色。
      

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

     

    Scrum master

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍, 一般可以对应为我们理解的项目经理的角色。

     

     

    Scrum team

     

    主要负责软件产品在Scrum规定流程下进行开发工作。每位成员可能负责不同的技术方面(开发、测试),要求团队有很强的自组织能力,能够交付一个端到端的真正对客户有价值的产品。

    • 曾经需要由经理或者lead来分配任务的团队,现在需要自己评审,估算,制定故事点数来管理BUG,然后再自己承诺在一个sprint中要解决的问题。

     

    • 开发小组的工作

      • 作为一个整体工作 :开发团队、测试团队、客服团队和product       owner一起工作

      • 按短迭代周期工作       :大部分是 2~4周,在 Scrum中采用的是 30个日历天,也就是 4 周。

      • 每次迭代包括:分析、设计、编码、测试,变成可交付的软件(称之为功能增量)

      • 关注业务优先级:按照PO制定的优先级交付功能

      • 检查与调整 :每次新迭代开始,敏捷小组都会结合上一次迭代中获得新知识做出相应调整。

     


     


    概念/工具

    • 产品代办列表      Product backlog

      • 使用产品Backlog来管理产品的需求,       产品backlog是一个按照商业价值排序的需求列表

      • PO首先将需求按照优先级进行排列,产生一个Product       Backlog。作用类似于传统开发中项目经理确定需求文档

      • 用户故事 user       story :尽量减少依赖

     


     

    • 冲刺代办列表 Sprint      backlog

      • 先有product       backlog

      • 产品经理和项目团队紧密协作,一起定义目标、梳理产品需求清单。清单中通常会包含产品特性、修复bug、非必要功能需求以及其他要在交付时完成的工作。

      • 当研发团队制定了迭代清单后,除了团队成员外,任何人都不能再加入需求。

     

    • 看板

      • 工作流可视化

      • 高度可视化的调度系统

    • DOD

      • 用户故事完成dod

      • 迭代完成dod

      • 发布完成dod

     

    • CI/CD 持续集成/部署

    一次集成要做哪些事情呢?它至少包括:获得所有源代码、编译源代码、运行所有测试,包括单元测试、功能测试等;

     

     

    会议

     

    • Sprint计划会议, sprint      planning meeting

     

    • 每日站会 Daily      scrum meeting, 短期会议固定的日常循环下,每一位团队成员都回答三个问题:

      1. 上一次会议我完成了什么?

      2. 达到我的目标碰到了什么障碍?

      3. 下一次会议之前我需要做些什么?

     

    调整,优化次日工作。

     

    • Sprint 评审会议

    检验发布目标的进展,优化下一个sprint

    • Sprint回顾会议

    回顾已经完成的sprint, 并且确定做出什么改善使下个sprint更高效,快乐,满意

     

     

    流程


     


     

    1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

     

    2Scrum Team根据Product Backlog列表,做工作量的预估和安排;

     

    3、有了Product Backlog列表,我们需要通过 Sprint Planning MeetingSprint计划会议)来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

     

    4Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

     

    5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn downSprint燃尽图);

     

    6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

     

    7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

     

    8、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

     



本文分享自微信公众号 - PM吃瓜(wu_lian_club)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
2 收藏
分享
加载中
只讲what,不讲why,犯教条主义错误
2020/09/01 18:47
回复
举报
更多评论
打赏
1 评论
2 收藏
0
分享
返回顶部
顶部