精华内容
下载资源
问答
  • SCRUM框架

    2019-04-04 23:24:38
    Scrum是一个框架,它定义了高层次的管理流程。它并不涉及具体开发方法或者人员的有效沟通技巧等。这些没有涉及的领域需要和其他理论和技能互为补充,以确保项目的成功。  Scrum的核心价值观是:承诺、专注、...

    Scrum是一个遵循敏捷宣言价值观,它是一种采用迭代式、增量开发的软件开发过程。Scrum是一个框架,它定义了高层次的管理流程。它并不涉及具体开发方法或者人员的有效沟通技巧等。这些没有涉及的领域需要和其他理论和技能互为补充,以确保项目的成功。 
    Scrum的核心价值观是:承诺、专注、公开、尊重和勇气。它提倡自我管理、涌现机制、透明性和评估/适应循环的根本原则。 
    Scrum的基本假设是:开发软件就像开发新产品,无法一开始就能定义软件产品最终的规程,过程中需要研发、创意、尝试错误,所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队,有明确的最高目标,熟悉开发流程中所需具备的最佳典范与技术,具有高度自主权,紧密地沟通合作,以高度弹性解决各种挑战,确保每天、每个阶段都朝向目标有明确的推进。 
    Scrum的一个关键原则是承认客户可以在项目过程中改变主意,变更他们的需求,而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样,Scrum采用了经验方法– 承认问题无法完全理解或定义,而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。 
    Scrum提倡所有团队成员坐在一起工作,进行口头交流,以及强调项目有关的规范(disciplines),这些有助于创造自我组织的团队。 
    管理Scrum过程有很多实施方法,从即时贴、白板,一直到软件包。Scrum最大的好处之一是它非常容易学习,而且启动Scrum应用并不需要太多的投入。 
    SCRUM框架包括3个角色、3个工件、5个活动、5个价值
    3个角色
    1.产品负责人(Product Owner)
    2.Scrum Master
    3.Scrum团队
    3个工件
    1.产品Backlog(Product Backlog)
    2.SprintBacklog
    3.燃尽图(Burn-down Chart)
    5个活动
    1.Sprint计划会议(Sprint Planning Meeting)
    2.每日站会(Daily Scrum Meeting)
    3.Sprint评审会议(Sprint Review Meeting)
    4.Sprint回顾会议(Sprint Retrospective Meeting)
    5.产品Backlog梳理会议( Product Backlog Refinement)
    5个价值
    1.承诺 – 愿意对目标做出承诺
    2.专注– 把你的心思和能力都用到你承诺的工作上去
    3.开放– Scrum 把项目中的一切开放给每个人看
    4.尊重– 每个人都有他独特的背景和经验
    5.勇气– 有勇气做出承诺,履行承诺,接受别人的尊重
    相同点:SCRUM和XP都是 敏捷开发 的方法论,都体现了快速反馈,强调交流,强调人的主观能动性等基本原则,而且多数“最佳实践活动”都互相适用。

    不同点:Scrum 非常突出Self-Orgnization(管理 ),XP 注重强有力的工程实践 约束 。在具体的应用中可以将两者结合,在管理模式上启用Scrum, 而在实践中,创造一个适合自己项目组的XP(“start with Scrum and then invent your own version of XP.”)

    区别之一 : 迭代长度的不同

    XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.

    区别之二 : 在迭代中, 是否允许修改需求

    XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换, 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做 的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队收到干扰

    区别之三 : 在迭代中,User Story是否严格按照优先级别来实现

    XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活, 可以不按照优先级别来做,Scrum这样处理的理由是: 如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。 另外一个原因是,如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10.

    区别之四 :软件的实施过程中,是否采用严格的工程方法,保证进度或者质量

    Scrum没有 对软件的整个实施过程开出养个工程实践的处方, 要求开发者自觉保证 .

    但XP 对整个流程方法定义非常严格,规定需要采用TDD, 自动测试, 结对编程,简单设计,重构等约束团队的行为 。因此,原作者认为, 这点上,XP的做法值得认同的,但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, …等等”

    不难发现,这四个区别显见的是: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束。

    Scrum的四个会议
    Sprint计划会(Sprint Planing)
    每日站会(Daily Scrum)
    Sprint评审会(Sprint Review)
    Sprint回顾会(Sprint Retrospective)
    以下逐一拆解
    Sprint计划会:
    进行需求讲解。
    挑选PBI(product backlog item),也就是由客户选出重要的PBI。
    拆解PBI到SBI(sprint backlog item)。
    讨论每个SBI的工时。
    team挑选本次Sprint任务。
    每日站会:
    询问自己三个问题
    从昨天Daily Scrum到这一刻,我完成了什么工作?
    从这一刻到明天的Daily Scrum,我计划完成什么工作?
    是否有什么困难阻碍了我的进展?
    Sprint评审会:
    在 Sprint 结束后,大家一起评审本次 Sprint 的产出。每个人都可以自由发表看法,协助产品负责人对未来工作做出最终决定。并根据实际情况,适度调整产品待办事项列表。
    Sprint回顾会:
    在一次Sprint结束后,回顾一下团队在流程和沟通等方面的成效。大家一起讨论,哪些完成得好,哪些有待改进?
    敏捷开发十二原则
    在敏捷开发中,我们遵循以下准则:
    1.我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
    2.欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
    3.要不断交付可用的软件,周期从几周到几个月不等,且越短越好
    4.项目过程中,业务人员与开发人员必须在一起工作。
    5.要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
    6.无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
    7.可用的软件是衡量进度的主要指标。
    8.敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
    9.对技术的精益求精以及对设计的不断完善将提升敏捷性。
    10.要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
    11.最佳的架构、需求和设计出自于自组织的团队。
    12.团队要定期反省如何能够做到更有效,并相应地调整团队的行为。
    1、TDD:测试驱动开发(Test-Driven Development)
    测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论,TDD首先考虑使用需求(对象、功能、过程、接口等)
    主要是编写测试用例框架对功能的过程和接口进行设计,而测试框架可以持续进行验证。大行其道的一些模式对TDD的支持都非常不错,比如MVC和MVP等
     
    2、BDD:行为驱动开发(Behavior Driven Development)
    也就是行为驱动开发。这里的B并非指的是Business,实际上BDD可以看作是对TDD的一种补充,让开发、测试、BA以及客户都能在这个基础上达成一致,JBehave之类的BDD框架

    3.持续集成(Continuous Integration)简称CI,持续集成强调开发人员提交了新代码之后,立刻自动的进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。

    持续集成过程中很重视自动化测试验证结果,对可能出现的一些问题进行预警,以保障最终合并的代码没有问题。
    3.持续交付CD(Continuous Delivery)
    持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

    持续交付并不是指软件每一个改动都要尽快部署到产品环境中,它指的是任何的代码修改都可以在任何时候实施部署。

    这里强调的是

    手动部署
    有部署的能力,但不一定部署

    持续部署(Continuous Deployment)
    持续部署是指当交付的代码通过评审之后,自动部署到生产环境中。持续部署是持续交付的最高阶段。
    这里强调
    持续部署是自动的
    持续部署是持续交付的最高阶段

    展开全文
  • 对此,通常的解释是“对Scrum框架的错误应用,和对其原则的错误把握。”KenScheaber在“ScrumGuide”一文中对这两方面都提供了权威的阐述。本文的目的是在此基础上,提供更加明确的操作性的指导和检查工具。本文分成...
  • scrum框架 Scrum是实施小型敏捷的主要候选者,其原因很多,包括其受欢迎程度,开发人员的喜好,采用Scrum和项目交付的成功率高以及包括专注,勇气,开放,承诺和尊重的强大原则和价值观。 。 小型Scrum可以最好地...

    scrum 框架

    Scrum是实施小型敏捷的主要候选者,其原因很多,包括其受欢迎程度,开发人员的喜好,采用Scrum和项目交付的成功率高以及包括专注,勇气,开放,承诺和尊重的强大原则和价值观。 。

    小型Scrum可以最好地描述为“一个由人为本的框架,由小型团队定义(最多三个人),并为规划,开发和交付生产质量的软件解决方案提供支持。” 提议的框架围绕团队成员在任​​何项目中扮演多个角色的概念。

    小型Scrum十分有价值,因为它对遍布全球的组织中的小型分布式团队提供了强大的支持。 小型团队需要新的方法来满足客户对快速交付和高质量的不断增长的期望,Small Scale Scrum的准则和原则有助于应对这一挑战。

    small-scale-scrum-framework.png

    项目积压工作列出了项目中所需的所有内容。 它是在任何开发工作开始之前创建的,并由开发团队进行维护。 项目积压中包含开发任务和软件要求。 它取代了传统产品和冲刺积压。

    冲刺计划会议是有时间限制的(即提前设置指定的时间),并专注于即将进行的冲刺的计划工作。 会议由开发团队主持,需要预先计划以保持简洁。 冲刺计划是基于价值的。 在这一点上,将在即将开始的sprint中处理的需求应明确,并包含批准的接受标准。 不使用通常以速度衡量的容量; 相反,团队必须进行有根据的猜测。 仅在三个或更多的冲刺之后才出现速度,通常是在小规模Scrum项目完成之后。

    三人团队由开发团队和项目经理组成(大部分时间)。 预计开发团队将参与收集和阐明业务需求,进行开发工作,执行质量测试以及向客户发布软件。

    概念/演示证明是对冲刺中完成的小工作的展示,以展示开发进度。 在POC /演示中讨论任何偏差或不完整的工作。

    冲刺审核会议由开发团队和项目经理(如果参与项目)组织和运行,并由客户或客户团队参加。 冲刺审阅是有时间限制的,其中包含冲刺工作的演示以及工作完成/未完成,提出的错误以及已知和/或范围外的问题(如果有)的简短概述。 在演示结束时收集客户反馈,并将其纳入将来的冲刺中。 几乎不需要(如果有)准备就可以使会议简短而有条理。

    冲刺回顾会议由开发团队和项目经理(如果有)组织和运行,客户和/或客户团队可以参加。 冲刺回顾是有时间限制的,不需要事先准备。 由于开发团队的规模较小,并且sprint版本较少(交付的功能较少),因此这次会议的时间相对较短。 冲刺回顾会在冲刺审核之后和下一次冲刺计划会议之前进行。

    冲刺评审冲刺回顾冲刺计划可以合并为一个会议,我们称其为冲刺终止 ,持续约90分钟。 这些会议简明扼要,结构化(感谢提前准备),并且不得包含任何不必要/无关的讨论。

    一个/最终版本是项目的最终结果。 开发团队运行测试,验证完成的工作,确认修复,并在发行版本上签字。

    对于每个小型Scrum仪式, Scrum Guide推荐的每个仪式的时间盒指南都应视为有效。

    本文的相关版本最初发布在Medium上,并经许可重新发布。

    下载小型Scrum简介指南


    接下来要读什么

    翻译自: https://opensource.com/article/19/2/small-scale-scrum-framework

    scrum 框架

    展开全文
  • scrum 框架

    2011-02-14 11:05:46
    Scrum Master主持,参加人员为PM,Scrum Master,Scrum Team. (1)沟通PM选定重要性高的产品BackLog细节,理解需求无误; (2)将Product BackLog根据需求拆分城任务,估算时间; (3)Product Owner和团队根据可用人员...
    [b]关键词:[/b]
    
    Sprint: 项目中若干小的迭代周期中的一个
    Backlog: 按照商业价值排序的需求列表(每一项为user Story) ----PM(PO)负责产出
    Sprint BackLog: Sprint 经过回忆分析,讨论,估算得到的backlog
    Issue:议题

    [b]三个角色:[/b]
    Product Owner(Product Manager):定义开发目标,需实现的fetrue和优先级
    Scrum Master :保证团队高效而不受打扰的工作,优化工作条件和过程
    Scrum Team: 自组织完成项目开发,使用可行手段确保进度+质量

    [b]四个活动:[/b]
    Sprint计划会议(Sprint Planning Meeting)--(一下午):
    由Scrum Master主持,参加人员为PM,Scrum Master,Scrum Team.
    (1)沟通PM选定重要性高的产品BackLog细节,理解需求无误;
    (2)将Product BackLog根据需求拆分城任务,估算时间;
    (3)Product Owner和团队根据可用人员和BackLog进行估算,选入排入本次Print
    的BackLog
    (4)产出Print BackLog,任务板等......

    每日站会(Daily Scrum Meeting)(每天10-15分钟):
    参加人员为:Scrum Master ,Scrum Team
    (1)PrintBackLog的按任务未开始、进行中、已完成等状态进行归类,展示燃尽图
    (2)确认成员前一天的工作,今天的工作和工作中碰到的issue,更新人物墙
    (3)评估需求变更,视情况推迟其他重要性低的BackLog
    Sprint评审会议(Sprint Review Meeting):
    评审Sprint过程和结果,发现列举存在的问题

    Sprint回顾会议(Sprint Restrospective Meeting):
    参加人员为:PM,Scrum Master,Scrum Team
    (1)头脑风暴模式的,轻松讨论氛围,每次选中小于5个的问题进行解决
    (2)总结经验教训,反馈到后面的Sprint,持续改进工作方法

    [b]三种物件:[/b]
    产品backlog(Product Backlog)
    Sprint Backlog
    燃尽图(Burndown Chart)

    [b]特点[/b]
    1.简单开发流程
    2.需求迅速变化下迭代、增量开发开发系统的产品
    3.控制由利益和需求冲突变得混乱的流程
    4.改善交流,优化合作
    5.检测产品开发和生产过程中障碍并且除去障碍
    6.设计流程的总结
    7.最大化生产率
    8.能让每个参与者发挥最佳水平,并且为贡献感到自豪和骄傲

    [b]不同于传统开发模式:[/b]
    最显著的特点是:响应频繁的需求变更

    [b]适用场景:[/b]
    1.重量级导致开发环节复杂
    2.面向职责、面向任务的各司其职导致流程衔接不畅,项目进度掌控困难
    3.上面2个情况所产生的项目周期过长

    [b]原理[/b]
    1.目标驱动、统一的软件交付目标下组织团队
    2.Scrum 团队做出的评估计划 甚至是 设计、开发、测试
    3.项目基本开发属性:周期+质量(如果Bug数为B,周期为T,那么尽可能的减少T*B)

    [b]过程[/b]
    粗略:
    前期:Product Owner整理业务需求,产出Product Backlog
    执行:以Sprint Planning Meeting产出 printBackLog,以Spirnt为单位
    迭代完成sprint Backlog
    后期:每个sprint完成后,通过sprint回顾会议,发现问题和改进点,指定下一个
    Sprint要引入的新实践

    详细:
    Scrum Master主持Sprint Meeting:
    1.sprint 会议沟通PM选定重要性高的产品BackLog细节,所有人员确保理解需求
    2.将BackLog根据需求拆分城任务,估算任务时间
    3.PM和Scrum Team根据可用人员和Product BackLog进行时间估算.选入排入本次
    Print的BackLog
    4.Scrum Master于团队分派任务,指定Sprint计划
    ---一次Sprin周期2周,会议一下午

    执行:
    1.Spirnt内的BackLog按任务 未开始、进行中、已结束等状态进行归类,同时展示
    燃尽图
    2.每日早上例会,确认成员前一天的工作,当天的工作和工作中碰到的issue.更新
    任务墙
    3.评估需求变更,视情况推迟其他重要性相对较低的Backlog
    4.任何完成的BackLog都要掩饰给PM和QA后才能提交测试

    完成:
    1.Scrum Master召集、组织Sprint回顾会议
    2.头脑风暴方式Review Sprint过程和结果,发现列举存在的问题
    3.确定(投票方式)需要在下一个Sprint解决的1-3个问题,探讨解决方案,确定
    实践方式

    [b]其余活动[/b]
    Double Check:交叉检查项目制品是否达到要求(例如分析文档,核心代码等)
    CheckList: 总结经验教训、作为后续项目的检查项 (Scrum Master,Scrum Team)
    Tech Show: 技术交流(必须为短时间并且高频率的) (Scrum Team)
    守门员: 为团队创造安静条件,增加对项目的Focus程度.(Scrum Team)
    单元测试: 测试优先保证代码质量 (Scrum Team)
    结对编程(PP): 提高设计和代码质量,人员的经验共享和加强合作(Scrum Team)
    任务纸牌: 增加任务评估的客观性 (Scrum Master,Scrum Team)


    [color=red]最后4句话:
    个体于交互 重于 过程于工具
    可用软件 重于 完备的文档
    客户写作 重于 合同谈判
    响应变化 重于 遵循计划[/color]
    展开全文
  • Scrum框架及其背后的原则(上)——Scrum 框架的伪代码描述第一部分:Scrum 的框架Scrum并不是一个特定产品开发的流程或技术,而是一个容纳其它流程和技术的框架。作为一个迭代和增量的产品开发框架,Scrum本身十分...

    Scrum框架及其背后的原则(上)——Scrum 框架的伪代码描述

    第一部分:Scrum 的框架

    Scrum并不是一个特定产品开发的流程或技术,而是一个容纳其它流程和技术的框架。作为一个迭代和增量的产品开发框架,Scrum本身十分简单和明确。下面的一段伪代码,是对Scrum框架的完整表述。
    void run_scrum() {
    const int Sprint_Length = 10;
    int velocity = get_past_performance();

    // Scrum 中的三个角色
    Role team, product_owner, ScrumMaster;
    
    // Scrum 中的制品
    Product_Backlog     product_backlog;
    Sprint_Backlog      sprint_backlog;
    Burndown_Chart      sprint_burndown_chart,          release_burndown_chart;
    
    Product_Increment   product_increment;
    
    //开始项目的三个准备条件
    setup_team(team);
    define_Definition_of_Done(team, product_owner);
    initial_project(&product_backlog );  //标红的为输出参数,将带回值,下同
    
    //每一次while 循环为一次迭代
    while (!is_empty(product_backlog)) {
        run_sprint_planning_meeting(product_backlog, velocity, &sprint_backlog);
    
        //每一次for循环为一个工作日
        for(num_of_day = 1; num_of_day <=  Sprint_Length; num_of_day ++){
            run_daily_scrum_meeting(&sprint_burndown_chart);
            do_development_activity(sprint_backlog, &product_increment);
        }
    
        run_sprint_review_meeting(product_backlog, product_increment);
        run_retrospective_meeting();
    
        update_product_backlog(&product_backlog, &release_burndown_chart);
        update_velocity(&velocity);
    }  
    

    }
    这就是Scrum的完整框架,只有这些,很简单,我们下面将逐行解释。
    const int Sprint_Length = 10;
    int velocity = get_past_performance();
    Scrum是一个迭代开发模型。每一个迭代周期,团队完成一部分产品需求,交付可工作的软件。在Scrum中,迭代被称为sprint (本意为冲刺跑,一般不作翻译),典型的sprint长度是1到4周。值得强调的是,对于同一团队,sprint的长度是固定不变的。
    Sprint_Length – Sprint长度:这里以10个工作日(两周)为例,const常量修饰符,强调了其不可变性。
    Velocity – 团队开发速率:也即每个sprint 团队能完成多少量的用户需求,它是Scrum中计划和承诺的最重要依据。开发速率来源自过去实际产出结果,并在产品开发过程中不断修正。
    Role team, product_owner, ScrumMaster;
    以上的实体定义是Scrum 中的三个关键角色,在Scrum框架中也仅仅定义了这三个角色。
    Team – 团队:团队负责产品交付,规模一般为 5~9人,Scrum强调团队的多功能(cross functional)和自组织。多功能指的是,团队应该整体具备各个职能所需的技能,如系统,开发和测试技能,同时也具备各个组件的技能如数据库设计、协议开发和UI设计等。团队的多功能是短迭代开发的基础,只有做到这一点,独立的团队才可能在一个sprint 中交付对用户有意义的产品增量。自组织指,在目标清晰的前提下由团队自主决定完成目标的具体方法。
    Product Owner – 产品负责人: 多直接称为PO。PO 负责把握产品的方向,包括需求的收集、定义,优先级设定等。PO通过这些活动以及和团队的合作,最终确保产品ROI(return of investment, 投资回报)的最大化。
    ScrumMaster: 一般不作中文翻译,ScrumMaster并不直接负责产品交付,它向团队负责,确保团队按照Scrum的框架工作,具备良好的外部和内部工作环境,顺畅地交付产品,并不断的改进,提升交付的效率和质量。与传统意义上的管理者不同,ScrumMaster更多是起服务、协调和引领的作用。如果注意观察会发现,在这段程序中,ScrumMaster 是一个定义,但从未使用的变量,这也正反映了ScrumMaster的协调和支持的作用。
    Product_Backlog product_backlog;
    Sprint_Backlog sprint_backlog;
    Burndown_Chart sprint_burndown_chart, release_burndown_chart;

    Product_Increment product_increment;
    上面的结构变量是Scrum 中的核心制品,它们贯穿整个Scrum 操作过程,分别是:
    Product backlog – 产品待办事项:很多时候直接用英文表示,简称PB,是一份用户需求列表。其中的每一项都是一个具体的端到端的用户需求,如“用户可以完成登录”等等。Scrum 产品开发过程就是,通过一系列的sprint,每个sprint完成一部分“产品待办事项”,交付包含这些需求实现的产品增量,直至完成所有“产品待办事项”。Product backlog 的责任人是Product Owner,它在产品开发的初期生成,并在开发过程中不断更新完善。
    Sprint backlog – sprint待办事项:是一个sprint 中要完成的任务列表。其中的项目是为完成特定用户需求而要进行的设计、开发、集成、测试等具体任务,如“为模块A添加外部接口”等。完成sprint backlog中的所有任务,也意味着sprint 开发任务的完成,对应的用户需求可以交付。Sprint backlog,在spirnt 计划会议上生成,在开发过程中,可能会有所调整。
    Sprint burndown chart – sprint 燃尽图:以坐标图表示团队在一个sprint中工作进展情况,横坐标是sprint 已进行的实际天数,纵坐标是还剩余的任务需要的时间的总和。它直观的反应了sprint 实际执行与计划的比较,以及团队离sprint 的目标完成的距离。
    Release burndown chart – 发布燃尽图:以坐标图表示当前版本的需求完成进展情况,横坐标是已经进行的sprint 的个数,纵坐标是待完成的用户需求的多少。它直观的反应了产品需求的完成情况,以及团队离完成版本完全发布的距离。
    Product increment – 产品增量:Scrum 要求每一个sprint结束都产生用户可用的软件,也被称着“潜在可交付的产品增量”(Potential shippable product increment, PSPI),事实上交付与否还要受用户习惯的约束。能否每个sprint生成满足质量定义的PSPI 是Scrum 执行效果的试金石。
    setup_team(Team);
    define_Definition_of_Done(team, product_owner);
    initial_project(&product_backlog );
    上面代码中的三步操作是Scrum 执行开始的准备条件。
    Setup Team – 创建团队:创立和建设适合的团队是Scrum实施的第一步工作,团队应该满足上面定义的Scrum团队的基本属性,并形成自己的目标和愿景,理解Scrum工作模式。
    Define Definition of Done – 定义完成标准:完成标准,是指一个用户需求完成应该满足什么样的标准。它是Product Owner 和 团队之间的一个约定,有了这个约定,当团队说,这个需求完成了的时候,Product Owner 将明确知道这意味着什么,比如是否包含了针对这个需求的性能测试,或是否包含相应的用户使用手册等。在实际运用中,由于条件限制,团队在一开始可能无法做到sprint 结果可交付,而会剩余一部分工作在交付前完成,如性能测试等,这一部分工作被称为“undone”的工作。完成标准在特定时间是固定的,但随着团队成熟度提高,团队应逐步扩展自己的完成标准,使其逼近向客户交付的条件,undone的部分越来越少。
    Initial Project – 启动项目:项目启动,是项目进入开发阶段前的一系列准备工作,如:项目目标的设定,项目初始需求的定义和澄清,工作量的估计,风险的识别,关键设计决策的产生,开发基础设施的选择和构建等。一般由客户(如果可能),PO,团队以及相关干系人共同参与项目启动。项目启动最重要的是输出一个初始product backlog,它应该包含对其中条目的大小的估计和优先级别的设定。
    上面三个操作的结果是,有了合适的Scrum团队,团队和PO之间就需求完成的标准达成一致的定义,并生成了一份初始的product backlog。有了这三个条件便可以正式进入迭代开发了。
    While (!is_empty(product_backlog)) {
    run_sprint_planning_meeting(product_backlog, velocity, &sprint_backlog);
    ……
    每一次while循环代表一个sprint周期,直至product backlog中所有的需求被开发完成。
    Run sprint planning meeting – 进行sprint计划会议: sprint 规划会议规划这个sprint 目标和具体任务安排,它标志着一个sprint 的开始。在sprint计划会议上要依次完成以下的内容:
    团队决定在接下来的的sprint 中要完成的用户需求,如过对需求存在疑问,团队应和PO进行澄清和确认。团队必须按照PO设定的product backlog的优先级别,从高到低选择,如因实现上的依赖关系,要调整需求选择的顺序,也需要和PO进行确认,以确保团队始终工作在最有价值的需求上。关于承诺多少需求,也并非取决于团队或专家的主观判断,而是根据product backlog中对每一个需求的大小估计,以及团队过去的实际开发速率(velocity),承诺相匹配数量的需求。
    针对所选择需求的实现,进行简单和必要的沟通、分析。以确保第三步可以顺利的进行。
    分别将每一个需求,分解成设计、开发和测试等任务。并估计每一个任务所需的工作量(通常以小时计)。
    Sprint 计划会议由团队主导,但需要PO的贡献,特别是上面的第一条,需要PO的现场参与。其它条目,即使PO不在场,也应该随时可以提供远程的咨询。
    作为sprint 计划会议的结果,团队选择并承诺了接下来sprint 中要完成的product backlog中的用户需求,并且,将每一个需求分解成具体的多个开发任务。这些开发任务的列表被称为sprint backlog,它是sprint 计划会议的最重要输出,接下来的工作,就是完成这些开发任务,交付对应的用户需求。
    for(num_of_day = 1; num_of_day <= Sprint_Length; num_of_day ++){
    run_daily_scrum_meeting();
    update_burndown_chart();
    do_development_activity(sprint_backlog, &product_increment);
    }
    在这里,每一次for循环代表一个工作日,循环的次数也即sprint 的时间长度。
    Run daily scrum meeting – 进行每日Scrum 会议: Scrum 团队每天都会进行一次同步 – Scrum 会议。Scrum 会议被限定在15分钟之内结束,每一天在同样的时间,同样的地点举行,旨在沟通同步项目开发状态,建立团队对项目的整体认识,并发现项目中的问题。会议上,每一个人都向团队回答三个问题:我昨天做了什么?我今天计划做什么?在前进的道路上有什么障碍? Scrum 会议结束后,要更新sprint燃尽图以反映团队的工作进度,和离sprint目标的距离。
    Do development activity – 进行开发工作:Scrum强调团队成员间的紧密协作,原则上任务应该由团队成员主动认领,而非被分配。为此,团队需要形成相应的规则,如:在同一时刻,不应该并行开始过多用户需求开发,这样可以确保团队有明确的工作重点,也可以避免在sprint 结束时所有的需求都只是部分完成,而交付不了任何有价值的软件增量。随着开发进程的不断进展,软件增量得以生成、扩展和验证。
    run_sprint_review_meeting(product_backlog, product_increment);
    run_retrospective_meeting();
    Run sprint review meeting – 进行sprint评审会议:Sprint评审会议又称为sprint演示会议,一个sprint结束,团队构建了包含新的用户需求的产品增量,团队在这个会议上展示过去的一个sprint所构建的产品。sprint评审会议是开放的,应尽可能邀请相关人员参加,ScrumMaster、团队、PO、市场人员、客户、管理人员、维护人员、领域专家以及关联团队等。在会议上团队对照product backlog依次演示刚刚构建的用户需求,获取参与者的反馈,这些反馈将成为未来的产品设计和规划调整的依据,以使产品更好的满足客户的需求,更好的服务于组织的业务目标。
    Run retrospective meeting – 进行sprint团队回顾会议:在评审会议之后,团队进行回顾会议,评审会议是对产品的检查和调整,而回顾会议是团队对自身的检查和调整。Scrum 强调通过经验性的过程,逐步检查和调整团队的协作和工作模式,持续改善。回顾会议是Scrum 运行的十分重要的一环,其有效性是Scrum实施成功的保障。除非团队决定邀请额外人员,回顾会议一般只有团队参加,在回顾会议上,团队回顾刚刚过去的一个sprint,团队在哪些方面做得好,应该坚持;哪些方面有待改进,并挖掘其本质原因,定义具体的改进计划,以在下一个sprint去切实实施。为保证回顾会议的有效,组织和团队都应该承诺愿意做出适应性的改变。
    update_product_backlog(&product_backlog, &release_burndown_chart);
    update_velocity(&velocity);
    Update product backlog – 更新产品待办事项:sprint 结束,产品待办事项内的一部分需求被交付,应该更新其状态。此外,由于PO和团队获取了更准确和详细的产品信息,product backlog 也应该相应更新,例如在sprint 回顾会议激发了用户对优先级新的认识,在同PO确认后,product backlog 的优先级定义就需要做出相应的调整。更新产品待办事项的同时,发布燃尽图也需要相应更改,以反映最新的需求完成情况。
    Update velocity – 更新团队开发速率:前面提到,团队承诺多少需求的依据是团队过去的开发速率。每个sprint结束,团队的参考发速率都需要根据实际情况做修正,这将有助于更好地把握开发节奏,合理地计划未来的工作。
    至此,一个sprint 结束,潜在可交付的产品增量得以交付或演示,团队和PO获取了有意义的反馈, product backlog 得到了调整,团队对工作进行了反思并定义了改进方案。这时就可以进入下一个sprint,直至交付整个产品。
    总结

    Scrum框架为团队敏捷实施定义了一个简单和明确的边界。在边界之内,团队探索和完善相关的管理和技术实践。我们一般建议,开始尝试Scrum的组织最初应严格遵循框架的定义,这时常会引起过于教条和形式主义的争议,团队会提出“应该抓住Scrum的实质,而不是强调形式”。问题是,只有通过严格的基本实践的学习和应用,我们才可能掌握其原则,区分哪些是实质,哪些是可以调整的形式。Ken Schwaber对此的描述是,“对Scrum规则的修改,只有在ScrumMaster 确信团队足够深入的掌握了Scrum的运行原理,有足够的技能和思维来修改规则时才可以进行”。
    我们建议,那些准备实施Scrum 或者已经实施但还处于探索中的团队,可以打印出这段伪代码,对照自身的实际操作,任何与这段伪代码不符的地方,团队都应该认真思考其合理性。我们更加建议,团队在实施Scrum的过程中,深入理解和思考Scrum框架背后的价值观和原则,Scrum为什么可以和将怎样改进产品开发,为此我们需要做出哪些改变。对原则的理解和思考,有助于我们对实践的更好掌握,更快的从Scrum中受益。这也将是本文的第二部分要讨论的内容。(待续……)
    * 本文部分参考了“Scrum guide”和“Scrum Primer”

    展开全文
  • 5.敏捷软件开发框架 - Scrum框架.pdf
  • Scrum框架概述

    2020-09-11 10:41:04
    二、Scrum框架的结构(3种角色,5种事件,3种工种) 三、Scrum的理论 四、Scrum的工作流程 五、Scrum的5个价值观 一、Scrum是什么? Scrum的标准释义为:Scrum是一个框架,在这个框架中人们可以解决复杂的...
  • 前不久我在团队做过一段时间ScrumMaster,当ScrumMaster的实践过程中,曾经很浅略地做过一些关于迭代开发的思考和总结(《关于迭代的一些思考》,不过里面关于Scrum框架和敏捷开发大多是经验和直觉上的认知,缺少...
  • Scrum框架及其背后的原则(上)——Scrum 框架的伪代码描述 作者 何勉 发布于 2011年4月7日 上午12时0分 社区 敏捷 主题 企业级敏捷 标签 Scrum , 敏捷理论 Scrum是应用最广泛的敏捷开发方法.....
  • Scrum框架 转贴

    2019-09-26 18:53:23
    http://www.infoq.com/cn/articles/scrum-pseudo-code伪代码,是对Scrum框架的完整表述。voidrun_scrum(){constintSprint_Length=10; //迭代周期 以天算intvelocity=get_past_performance();...
  • 图(一)Scrum总体框架PPT格式大图下载链接为了说明这些原则与Scrum框架的对应关系,在图(一)中我们以Scrum框架为索引,列出了相对应的原则(见图中蓝色框),它们分别是:产品开发过程相关的原则高度透明不断反馈...
  • SCRUM框架.ppt

    2020-01-17 17:16:58
    28页文档,用友内部培训资料:Scrum 敏捷开发框架介绍。详细介绍敏捷软件开发全过程,附录Nokia的Scrum标准
  • Scrum框架之Sprint实践

    2011-07-21 14:02:22
    描述了Scrum框架之Sprint实践,使用初学者
  • 敏捷项目管理流程-Scrum框架最全总结.txt
  • 公司组织培训的资料《敏捷思维及Scrum框架》讲座,敏捷方面的内容基本都讲到了,没接触过敏捷的同学可以学习下,挺好。
  • 远离敏捷状态的 Scrum 框架

    千次阅读 2018-01-25 00:00:00
    本文来自作者 王宇 在 GitChat 上分享 「远离敏捷状态的 Scrum 框架」,「阅读原文」查看交流实录。「文末高能」编辑 | 哈比尽信书不如无书 ——《孟子·尽心下》敏捷入门,很多人一般都会选择 Scrum 框架进行...
  • SCRUM框架 Scrum框架的3个角色、3个工件、5个事件、5个价值: 3个角色 产品负责人(Product Owner): Scrum Master 开发团队 3个工件 产品Backlog(Product Backlog) SprintBacklog 产品增量(Increment) 5...
  • 7分钟揭晓Scrum的秘密(Scrum框架) 什么是Scrum Scrum 是用于开发和持续支持复杂产品的一个框架。其中包括 Scrum 的角色、事件、工件,以及把它们组织在一起的规则...Scrum (名词): Scrum 是一个框架,在此框架中...
  • 前面我们提到看板搭建、价值流分析,本文谈谈敏捷转型之Scrum框架实践。 从我们的敏捷转型之旅来看,我们的试点团队是从看板方法及每日站会搞了一阵子之后,才开始实践Scrum框架的。究其原因,主要是两个方面:一是...
  • Scrum入门基础系列之Scrum框架

    千次阅读 2014-11-18 13:32:29
    读过几本Scrum书的人,想必对于Scrum框架都可以如数家珍,如Scrum的3个角色,5个会议,3个工件。在展开这些内容之前,我想先介绍一下Scrum的价值观以及敏捷宣言。
  • Scrum框架及其背后的原则(上)——Scrum 框架的伪代码描述 http://www.infoq.com/cn/articles/scrum-pseudo-code 转载于:https://www.cnblogs.com/kevinlzf/archive/2011/04/08/2009358.html...
  • Scrum框架和規則

    2019-01-04 00:45:22
    Scrum框架 Scrum是一种管理项目的敏捷方式,通常是软件开发。使用Scrum进行敏捷软件开发通常被视为一种方法论; 但不是将Scrum视为方法论,而是将其视为管理流程的框架。 要做Scrum,我们所需要的只是16个必需品,即3...
  • 1 Scrum框架的概念 Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程.。在这个框架中,整个开发周期包括若干个小的跌代周期,每个小的的跌代周期称为一个Sprint,每个Sprint的建议长度2到4周。 在Scrum中,...
  • Scrum 框架讨论

    2011-04-14 13:38:07
    Scrum是应用最广泛的敏捷开发方法。同时,它的失败率却非常高,其创始人之一Ken Schwaber估计75%尝试...对此,通常的解释是“对Scrum框架的错误应用,和对其原则的错误把握。”Ken Scheaber 在“Scrum Guide”一文中...
  • Scrum 框架包括3个角色,5个会议,3套工具。3个角色: 1、SM:Scrum Master,Scrum 过程管理者,服务于PO、团队和组织。 2、PO:Product Owner,对产品 Roadmap 和 Backlog 负责,确保产品价值最大化。 3、Dev ...
  • 书接上回,今天咱们讲,Scrum框架 概述 Scrum不是标准化过程,不能保证你在有条不紊地按照步骤一步一步顺序执行后,就能在制定的时间和预算内产出让客户满意的高质量产品。(大白话,这东西,生搬硬套不好使。) ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 10,919
精华内容 4,367
关键字:

scrum框架