zoukankan      html  css  js  c++  java
  • 敏捷开发流程 3个角色、5个会议、12原则

    敏捷开发流程之Scrum:3个角色、5个会议、12原则

    本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。

     

    一、Scrum的定义和目的

     

    Scrum是一个用于开发和维护复杂产品的框架,是一个增量的、迭代的开发过程,目的是让开发人员像打橄榄球一样迅猛并充满激情,通过团队合作,提高工作效率。通过团队间的有效交互,为企业创造价值。

     

    二、敏捷宣言

     

    其实,在发表《敏捷宣言》之前,很多的敏捷实践都已经存在且使用了,比如:Scrum、XP、KanBan等。之所以发表《敏捷宣言》,是因为这些实践都是在单打独斗地推进敏捷开发,而不是以一个联合体的形式,且没有一个统一的指导方针。所以17位敏捷联合创始人决定发表《敏捷宣言》,共同在全世界推进敏捷开发运动。下面是敏捷宣言的4句话:

     

     

    三、Scrum中的人员角色

     

    3个角色

     

    Scrum中的人员分为3个角色:产品所有者(Product Owner), Scrum Master,开发团队(Team)。

     

    • 产品所有者:定义所有产品功能,决定产品发布的内容以及日期,对产品的投入产出负责,根据市场变化对需要开发的功能排列优先顺序,合理地调整产品功能和迭代顺序,认同或者拒绝迭代的交付。
    • ScrumMaster :ScrumMaster不是项目经理,他没有分配任务的权力,没有考核的权力,没有下命令的权力,他指导项目组的成员按照Scrum的原则、方法做事情,领导团队完成Scrum的实践以及体现其价值,排除团队遇到的困难,确保团队胜任其工作,并保持高效的生产率,使得团队紧密合作,使得团队个人具有多方面职能的工作能力,保护团队不受到外来无端影响。
    • 开发团队:经典团队拥有 5-9 人,团队成员包含程序员、测试员、用户体验设计等等,团队关系在一个迭代中应该是固定的,个人的职能可以在新迭代开始时发生调整,团队自我组织和管理(自组织,自驱动),团队成员都全职工作。

     

    四、Scrum的开发流程

     

     

    (图片源自网络)

     

    不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段,Scrum将整个开发过程分为多次迭代(称为Sprint,冲刺),一般为期2~4周,最常见的为2周。Scrum并非以一段时间集中完成一个过程,而是将所有过程中必须的每一部分集中在这段时间内完成。需求、设计、编码、测试、上线都必须在一个迭代中完成,每个迭代必须产生一个可以工作的软件。

     

    4.1 五个会议

     

    Scrum 整个开发过程分为五个会议:

     

    1)待办事项整理会议(Backlog Grooming Meeting)

     

    迭代计划会议开始之前3天召开,Product Owner与Scrum Master必须参加,关键开发者或架构师需要参加;时间控制在30分钟到1小时。

     

    由Product Owner将一批希望团队在下次迭代时实现的用户故事,按照实现顺序描述给在场的团队成员,Scrum Master与在场成员分析用户故事,明确指出团队认为需求不明确的地方,Product Owner现场记录,会后补全,Scrum Master与架构师,还有在场成员分析用户故事需要包含哪些技术任务,Scrum Master先把子任务建立,方便迭代计划会议的时候团队可以更准确地预估任务故事点。

     

    会议结束时,Product Owner确保在迭代计划会议开始之前团队提出的问题都能被解决,会议重点如果团队发现需要加强或是完善的地方,Product Owner还有两到三天的时间可以补强,而不是浪费迭代计划会议的时间去做这件事情。

     

    2)迭代计划会议(Sprint Planning Meeting)

     

    产品负责人建立产品功能列表(Product Backlog)。产品功能列表是一组条目化需求,它必须从客户价值角度描述,并按优先级排序。

     

    Scrum Master召集相关人员召开迭代计划会,迭代计划会在每个迭代第一天召开,目的是选择本次迭代的Backlog和估算本次迭代的工作量。

     

    产品负责人逐条讲解最重要的产品功能,开发团队共同估算Backlog所需工作量,直到本迭代工作量达到饱和。产品负责人参与讨论并回答和需求相关的问题,但不干扰估算结果。队员认领任务(或由组长协商分发),独立或与别人一起完成任务;会议时间控制在1-2小时内。

     

    3)每日站会(Standup Meeting)

     

    团队内部利用每日立会来沟通进度,15分钟结束,开发团队利用燃尽图来展示整体进度;如无特殊原因,迭代期内无变更,在每日站会上团队成员需要回答以下3个问题:

     

    • 昨天你做了什么?
    • 今天你将要做什么?
    • 你有需要帮助的地方吗?

     

    这些都是团队成员的彼此承诺。

     

    4)评审会(Retrospective Meeting)

     

    小组向产品负责人展示迭代工作结果,产品负责人给出评价和反馈。以用户故事是否能成功交付来评价任务完成情况。整个团队都需要参加,ScrumMaster、产品所有者、团队,可能还有客户,时间控制在1-2小时内。

     

    5)反思会(Retrospective Meeting)

     

    在每个迭代后召开简短的反思会,总结哪些事情做得好,哪些事情做得不好。做得好的保留,不好的摒弃。会议得出这样的结论:开始做什么、继续做什么、停止做什么,一般控制在15-30分钟。

     

    Scrum是一套开发流程,是敏捷的一种,实施主要还是看人,强调是自组织、自驱动的,只有不断的在实际应用中仔细体会,才能理解Scrum的真谛,把Scrum用好。

     

    4.2 12原则

     

    下面给出敏捷开发的12原则,这12原则作为敏捷开发对于软件开发流程的指导性纲领,也是对敏捷宣言进行了具有实际操作意义的解释,希望大家在实际应用中仔细体会。

     

    我们遵循以下准则:

     

    • 我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
    • 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
    • 要不断交付可用的软件,周期从几周到几个月不等,且越短越好。
    • 项目过程中,业务人员与开发人员必须在一起工作。
    • 要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
    • 无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
    • 可用的软件是衡量进度的主要指标。
    • 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
    • 对技术的精益求精以及对设计的不断完善将提升敏捷性。
    • 要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
    • 最佳的架构、需求和设计出自于自组织的团队。
    • 团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

  • 相关阅读:
    155. 最小栈
    160. 相交链表
    PAT 1057 Stack
    PAT 1026 Table Tennis
    PAT 1017 Queueing at Bank
    PAT 1014 Waiting in Line
    PAT 1029 Median
    PAT 1016 Phone Bills
    PAT 1010 Radix
    PAT 1122 Hamiltonian Cycle
  • 原文地址:https://www.cnblogs.com/Leo_wl/p/12375686.html
Copyright © 2011-2022 走看看