• Scrum开发模式


    名词解释

    Scrum: Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色(ScrumMaster)负责维护过程和任务,产品负责人(PO, Product Owner)代表利益所有者,开发团队(Team)包括了所有开发人员

     

    一、为什么Scrum是有效的开发组织方式

    (一)   经验型流程VS预定义型流程

    如果所需实现的对象清晰,技术准备充分,则适用于预定义型流程.如果所需实现的对象模糊,技术准备不充分,则适用于经验型流程.

    在这里,流程不仅仅是软件开发中的流程,这是一个广义的定义,包含各个行业生产中产生的流程.对于预定义型流程,很经典的例子就是造汽车.比如造一辆奥迪A6,工作人员只需要拿到图纸,根据图纸上提供的信息去裁割钢板,定型,组装.在预定义型流程下,一辆A6将很快的开下生产线.对于经验型流程,如果还是以汽车为例的话,那就可以放在如何降低汽车的风阻?如何降低油耗?如何使驾驶人更舒服?这些事情,在以前可能做过,也可能没有做过,这就需要根据我们以往的经验去考虑问题,但这里经验起的作用只是一本字典,更多的事情,需要我们在经验的基础上去升华解决.

    对于Scrum,适合的是经验型流程.在较短的迭代中(2周左右),需要我们快速的整理好PO提出的用户情景(User Story)(PO提出的需求在这里称作用户情景),然后选定技术(这个技术也可能是新技术)进行快速开发.

    (二)   软件项目中的两个复杂度

    简单项目=熟悉的技术+固定的需求;复杂项目=技术不确定+变更.

    试想,在我们以前做过的项目中,有多少是”简单项目”呢?因此,Scrum在不断迭代的过程中,屏蔽或者减少了需求的不确定性以及不确定技术带来的弊端.

     

    (三)   案例分析

    假如公司希望迁移SharePoint服务器,并和当前流行的社交网站如FaceBook进行集成.

    你觉得会有哪些问题?

    1、  我们有哪些可用的技术?

    2、  如何使用这些技术来实现所需功能?

    3、  对于目标,我们要实现到何种程度?

    4、  最糟糕的,PO并不清楚他需要什么!

    解决方式:

    1、  缩短迭代;

    2、  增加与PO的沟通频率;

    3、  将技术调研和实现放在不同的迭代中进行。

     

    (四)   经验型流程控制

    1、  需要通过检查和适应来改进流程(需要很好的透明度来支持)

    2、  透明度的实现需要企业文化的支持

    在Scrum模式中,团队的规模应控制在5~9人之间,充分发挥每个成员在团队中的作用。在应用Scrum模式进行开发过程中,需要建立人与人之间的信任,充分调动团队成员的积极主动性,也就是注重每个团队成员在团队中发挥的作用,而不是下派、监控这种不是以人为本的模式。那么在这种情况下,就需要很好的透明度来支持,要让团队成员知道ScrumMaster都和哪些人说了什么,PO提出了新什么需求,面临着什么新问题,甚至是上级的压迫也要上团队成员知道。

     

    二、计划质量

    (一)   Scrum是否需要计划?

           无可置疑,在Scrum中,需要更多的计划。在这里介绍一下戴明环。

          

           作为帮助我们做出进一步决策的迭代型方法,戴明环通过4 个简单的步骤来验证所获取的经验,以便帮助我们做出更好的决策。

    (二)   质量和成本的关系

    1、  关注质量将会最终降低成本并提供更好的质量

    2、  关注成本,将会牺牲质量同时远期成本反而增加

     

    那么该如何提高质量呢?

    停止使用通过检查来提高质量的方式,而通过完善的计划在产品开发的一开始就构建质量。理解起来可能稍微有点难以接受,但是集合上面的两点并结合戴明环,不难理解,质量应该是一个度,一个高度,一个保证,因为你不能保证你生产的家电永远不会坏掉。

    (三)   来看Scrum的计划(Plan)和执行(Do)

     

    Scrum通过在迭代中不断的计划和执行来推进,通过不断的计划,不断的完善计划,相应的质量也会随之提高,相比传统的(计划——执行——稳定)具有更高的可操作性和可控性。

     

    三、Scrum”以人为本”的体现

    我们可以来做一个实验来证明Scrum的优越性。

    情景一:有N个小队,每个小队有一个队长,所有小队的成员成矩形聚拢在一起(很紧凑),然后每个小队的队长给队员发号施令(在矩形内移动30步,然后移动出矩形)。

    情景二:有N个小队,没有队长,每个小队的成员成矩形聚拢在一起,然后每个小队成员在矩形内移动30步,然后移动出矩形。

     

    四、Scrum角色介绍

    (一)   ScrumMaster:

    1. 保证Scrum团队可以遵守Scrum的价值,实践和规范
    2. 帮助Scrum团队和组织采用Scrum模式进行项目流程组织
    3. 指导并带领团队变得更加高效,实现更高质量
    4. 保护团队不要受到外界因素的干扰
    5. 保证各个不同角色之间的良好写作,消除障碍
    6. 帮助PO更好地利用团队的能力
    7. 不要管理团队

    给ScrumMaster的一些建议:

    1、协助甄选PO人选,并帮助PO了解其职责; 如果PO不了解 如何很好的利用团对的价值,ScrumMaster需要承担负责

    2、ScrumMaster 永远不能同时担任PO

    3、ScrumMaster 可以由团队的成员来担任,但是在这种情况下他将有很重的负担

    如果打破了第二点,ScrumMaster同时兼任PO,那么就打破了Scrum的价值和规范,因为ScrumMaster+PO=PM。而在Scrum中是没有PM这个概念存在的。

    (二)   产品负责人PO

    1、PO 是一个人并只能由一个人来担

    2、负责管理产品待办事项表(Product Backlog)并保证其 对于客户和团队保持透明度

    3、对产品代办事项表进行优先级排序

    4、与团队一起来进行工作量估算

    5、对于项目的成功负责并保证投资回报率(ROI)

    给PO的一些建议:

    1、  客户项目:最佳的PO人选应该由客户的代表来担任

    2、  内部项目:最佳的PO人员应该由业务经理担任

    3、  PO可以由团队成员担任,但永远不能由ScrumMaster担任

    (三)   团队Team

    1、  最佳团队大小:5-9 人

    2、  多功能团队:程序员,测试人员,设计师,数据库管理员和架构师

    3、  保证团队成员全职参与开发

    4、  自我管理,没有头衔之分,不组建子团队

    5、  成员更替只能在迭代之间进行,最佳方式是在发布之间进行

    需要注意的是,第三点提到的全职参加是指完成了分配到的任务额即为全职参加。并不是指全程参加。

     

    五、在每次迭代过程中包含的内容

    (一)   每日站立会议

    1、  站立进行

    2、  在固定的时间,固定的地点

    3、  问题:

    你昨天完成了哪些工作?你今天要完成哪些工作?遇到了什么困难?

    4、  仅仅作为信息沟通用途,不解决任何问题

    5、  不向任何人汇报

    6、  15分钟

    (二)   发布计划会议

    进行产品规划

    1、仅对启动项目所必须的内容进行规划

    2、在开发过程中适时进行进一步的规划

    可交付物

    1、  针对产品特性和功能的整体规划

    2、  下一个发布的目标

    3、  主要任务

    4、  按优先级排序的产品待办事项表

    (三)   迭代计划会议

    1、进行迭代规划

    2、PO向团队介绍产品待办事项表

    3、团队在PO的协助下充分了解产品待办事项

    4、确定迭代目标和迭代合约

           迭代合约包含的内容有:

    1)       团队组成(成员列表、角色分配)

    2)       完成规范

    3)       团队对迭代目标的承诺

    4)       迭代长度

    5)       迭代代办事项的估算

    6)       迭代评审和下一次计划会议的时间和地点

    5、对产品待办事项进行细分并创建迭代待办事项

    (四)   迭代

    解释:团队用来实现迭代目标(可发布产品)的时间区间。

    时间区间:1-4周,最佳2周。

    关键词:时间长度决定何时结束迭代,而不由工作量的完成来决定。

    优点:为团队提供保障。

    (五)   迭代评审会议

    1. 团队展示完成的功能并收集反馈
    2. 对未完成的功能进行描述并说明原因
    3. PO接受/不接受当前迭代
    4. 邀请所有人,包括客户参与
    5. 4小时

    (六)   迭代回顾会议

    1. 那些做的好?
    2. 那些做的不好?
    3. 那些可以改进?
    4. 仅团队成员参与
    5. 4小时

    六、定义需求

           用户情景应该包括:作为……我需要……从而……,以及用户接受标准。

           用户情景应该理解为用户+情景,不能仅仅考虑用户本身,所有的用户情景都应该从某类用户开始。

           用户情景最佳实践:

    1、  纵向分配原则-对于采用分层设计的业务用例实现尽可能 由一个开发人员完成所有的层次的组件实现(界面/逻辑/数据)

    2、  任务的划分粒度到1个工作日内完成

    3、  对于任务而言,只有完成和不完成两种状态

    4、  业务用例的工作量使用的相对值,表明的是一种对于用例工作量和评定

  • 相关阅读:
    windows 2008 64位在指定的 DSN 中,驱动程序和应用程序之间的体系结构不匹配
    uva 11552 dp
    A*搜索算法
    Dalvik虚拟机总结
    J2SE基础:5.面向对象的特性2
    Linux/Android——input_handler之evdev (四)【转】
    Linux/Android——input子系统核心 (三)【转】
    Linux/Android——输入子系统input_event传递 (二)【转】
    【Android】Android输入子系统【转】
    Linux/Android——usb触摸屏驱动
  • 原文地址:https://www.cnblogs.com/outtamyhead/p/2797406.html
Copyright © 2020-2023  润新知