敏捷开发方法 - Scrum

价值目标

  • 交付最高的商业价值,通过尽量短的时间
  • 它强调的不是最短的时间,而是价值。我们关注的是如何在交付最高价值的前提下花费更少的时间。

框架

3-3-5-5模型

3个工件

product backlog

  • 产品清单

哪些需要纳入
哪些需要修改
哪些需要删除
哪些需要PBI优先级调整

  • 表现形式

scrum并没有要求PBI的表现形式,可以采用用户故事、用或者其他有意义的格式

  • 好的PB遵循DEEP原则

D. Detailed appropriately(详略得当)
近期要做的PBI粒度要足够小,能够放到一个冲刺中执行
越靠近PBL顶端的PBI要越详细且粒度越小
E. Emergent(涌现式的)
产品清单式动态的,可能受各种因素影响,修改、废弃、新增,因此PBL是个持续更新的动态需求池
E. Estimated(已估算的)
P. Prioritized(已排序的)

sprint backlog

  • 当前冲刺中开发团地需要完成的工作列表
    冲刺计划会议中,对PBI进行任务分解,细化为具体的工作任务,足以支撑实现这些PBIs,是DevTeam对实现PBI作出的承诺
  • 表现形式
    看板、电子表格、专门的在线系统进行记录和跟踪
    拆分后的任务和PBI的对应关系也要一同记录

produnct increment

  • 产品增量
    Potentially Shippable Increment,PSI 冲刺中所完成的所有PBI总和,未完成的部分不纳入
    增量是稳定的、可工作的产品组成部分

3个角色

product owner

  • 关键职责
    为Product Backlog负责
    为投资回报率负责
  • 关键属性
    是利益相关者和客户的代表
    只能由一人担任
    有绝对的决策权
    随时能够被团队找到
    决定产品发布日期和内容
    不能兼任scrum master
    根据业务价值和重要性为PBI排序
    能够决定sprint是否取消

scrum master

  • 关键职责
    促进scrum的进行,为开发团队移除障碍
  • 关键属性
    没有权利
    服务型领导

development team

  • 关键职责
    实现sprint的目标,在每个sprint结束交付可潜在发布的产品增量
  • 特征
    自组织
    跨职能
    具备交付产品所需要的所有能力
    同地协作
    T型人才,成员具备“一专多通”的特点
    没有头衔,大家都是平等的团队成员
    开发团队的成员必须全职参与
    人数范围3-9人:不宜过多或过少,过少的团队无法具备跨职能的要求,过多的团队降低沟通效率
    没有子团队:团队是平级团队,子团队增加了沟通成本

5个价值观

        勇气
            面对难题团队成员都有勇气做正确的事情和工作
        专注
            团队成员要专注于冲刺要完成的工作以及团队目标
        承诺
            团队成员对完成Sprint目标做出承诺
        尊重
            团队成员之间都尊重对方是有能力的、独立的人
        开放
            Scrum团队以及利益相关者对所有的工作以及完成工作所面临的挑战的开放性一致认同。

5个事件

sprint, 冲刺

  • 目标是完成可交付的产品增量
    是scrum的核心,也是scrum开发方法中的基本单元
    固定的时间盒
    是个容器,以冲刺计划开始,以冲刺评审和冲刺回顾结束

sprint planning, 冲刺计划

  • 确定当前冲刺所要完成的工作范围
  • 从PB中选择当前冲刺需要完成的PBI
  • 确定sprint backlog,以支撑所选的PBIs
  • 以两周冲刺为例,建议会议时间为4小时

daily scrum, 每日站会

  • 开发团队成员必须到场,PO和SM可选参加
  • 欢迎其他人参加,但只允许开发团队成员发言
    每天同一时间,同一地点
    准时开始,即使有开发团队成员缺席
    控制在15分钟以内
  • 会议基于三个问题
    昨天完成了什么
    今天准备完成什么
    遇到了什么障碍阻碍了自己或团队达成冲刺目标

sprint review, 冲刺评审

  • 本质是通过现场交流和演示,获得利益相关者对产品增量的反馈!反馈!反馈!
  • 不在于评价已完成产品增量的好坏
  • 更不在于在没有达到既定要求时的批判和追责
  • 主要内容
    审视已完成的工作以及已经计划但没有完成的工作
    向利益相关者展示已完成的工作(Demo)
    与利益相关者协作,进一步明确后续要做的工作

Spring Retrospective, 冲刺回顾

  • 本质是检视和调整,以期持续改进
  • 回顾已过去的冲刺
  • 识别持续改进的行动项并达成一致
    典型的会议内容
  • 三个主要问题
    在当前冲刺中,哪些做的好?
    在当前冲刺中,哪些做的不好?
    为了提高生产力,在下一冲刺中哪些需要改进?
  • 两周的冲刺,建议时间为1.5小时
    回顾会议由SM负责推进

工作流

scrum工作流.png
  1. 产品需求被汇总到Product Backlog,PO依据业务价值、重要性等对PBI进行排序。
  2. 冲刺会议标志着Sprint的正式开始,团队对输入的PBL进行选择,确定本次冲刺所需要完成的PBI。DevTeam基于所确定的PBI进行任务拆分,形成Sprint Backlog。
  3. DevTeam执行开发过程,交付潜在可发布的产品增量。

你可能感兴趣的:(敏捷开发方法 - Scrum)