自然之道——“SCRUM”

williams

    众所周知，10年前，敏捷联盟发布了四大宣言之后，渐渐延伸出现在的12条原则，12条原则充分展现敏捷在软件开发方面的团队优势，因此敏捷逐渐走进我们的视线。
    敏捷是一种方法论和实践集合，将优秀的实践与理论相结合，通过不断“理论——实践——理论”的反复迭代形式， 整合一些适合敏捷团队的能力提高、团队建设等的规范和标准。
                   下面，我将敏捷中一种迭代和增量的流程方法与大家分享。
                   SCRUM是敏捷开发一种，在最近两年中流行起来，SCRUM的起源是来自英式橄榄球活动，讲究团队配合及教练的游戏原则，在橄榄球游戏中，每个人角色都很重要，所有人都是为了胜利而战，SCRUM软件开发也同样如此，大家要在SPRINT中获得胜利（完成SPRINTBACKLOG也就是我们常说的TASK）。我们把一个迭代周期成为SPRINT周期，一般一个SPRINT周期大约是30天或者是更短（有例外，微软\IBM等国际公司的有些项目迭代周期有可能达到一年，当然这是他们在由完成可控环境的情况下，比如CI方式或者TDD方式）。我们就是要在迭代周期完成后保证会产生一套可以交付软件。
                   我们可以为了项目去建立SCRUM的游戏规则，也可以为团队建立SCRUM规则，但是不管怎么样，SCRUM游戏规则中有一条基本元素_SCRUM TEAM.当我们建立这个团队的时候，我们要保证SCRUM TEAM拥有明确目标、所具备实践和技术、紧密的合作、有效进程这四个属性。SCRUM TEAM 只是SCRUM游戏规则执行者之一，除此之外 我们还有PO\SCRUM MASTER这两个角色，PO是负责产品线的一个人员，只针对产品的需求（product backlog）利益负责。 SCRUM MASTER是负责制定SCRUM原则，解决SPRINT产生问题、决策重要事项的人，也是我们通常说的敏捷的教练或者叫顾问。
                   当我们明确产于SCRUM项目的人员的时候，我们该讲讲简单SCRUM的过程：

                    •将整个产品的backlog分解成Sprint Backlog,这个SprintBacklog是按照目前的资源环境可以完成的。
                    •召开sprint planning meeting，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的  
                     任务是以小时计算的，并不是按人天计算。
                   •进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。
                   •整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner.
                   •团队成员最后召开Sprint retrospective meeting，总结问题和经验。
                   •这样周而复始，按照同样的步骤进行下一次Sprint。
                   以上就是一个SCRUM事件流的描述，这里指的注意的是。product backlog分解（或集合）SPRINTBACKLOG的人员是由SPRINT TEAM来完成，而PO 需要帮助项目确认BACKLOG的优先级来保证尽早交付BACKLOG是拥有最大商业利益的产品。SPRINT MASTER在SPRINTS中指导SCRUM TEAM 按照游戏规则去做，并帮助主持各种meeting。在meeting中，要保证会议方向，而去具体问题是靠TEAM来解决的，MASTER只是辅助和指导。
下面我们来看一下在MEETING中 ，我们应该关注什么？
                 SCRUM活动中，我们常常会关注三个会议：sprint planning meeting、Daily Scrum meeting、Sprint review meeting。
                 Sprint planning meeting：一般要召开一天，根据参与者和议题的不同，分为两个阶段
                   1、上午
                   • 参与者：Product Owner Scrum Master Scrum Team
                   • 主题：  确认product backlog分解后任务优先级，并回答Scrum Team的关于故事点的疑惑或问题。
                   • 输出：  选择后确认的product backlog
                   2、下午
                   • 参与者：Product Owner Scrum Master Scrum Team
                   • 主题：  将product backlog翻译成sprintbacklog，分配成员任务、确定目标。（考虑编码、测试、代码评审细节）
                   • 输出：  sprintbacklog
                 Daily Scrum meeting：每天上班后的15分钟至30分钟左右
                   • 参与者： Scrum Master Scrum Team
                   • 主题：   What TO DO;Plan TO DO;Block
                   • 输出：  新的 sprintbacklog
                 Sprint Review meeting：Sprint 的TASK完成后
                   • 参与者： Scrum Master Scrum Team Product Owner
                   • 主题：   按照Backlog展示结果，功能是否符合要求，是否存在困难，新想法？等
                   • 输出：   sprint结果和产品的状态。
                   （那么一般确定后的SPRINTBACKLOG是尽量不修改的，如果有需求变化（故事点修改），可以重新建立一个新的SPRINTS的活动，或者再下个SPRINT PLANNING的召开中增加进去，目的就是保证sprint周期能够准确饱满的执行，另注，就像上面所说我们来任务分给TEAM的时候按照小时为单位，可想而知，在既定计划中，我们要以“冲刺”概念去执行，如果随便更改SPRINTBACKLOG或者强制增加到此SPRINT周期中，团队将无力完成任务，试想，当人们以极限的能力去负重的话，在添加任何重量 都会导致失败）

  针对AGILE 或者SCRUM ，我还有许多要说的，如果有问题请提出来，我将在以后的问题中选择主题来回答问题。

                  给大家留个题，有时间回一下贴：
                  1、公司实施敏捷后，取的了什么样的效果；
                  2、敏捷的实践，你工作做到什么程度，请举例说明。

          如果有任何问题可以跟帖与我联系！





上一篇：敏捷讨论
下一篇：敏捷开发 故事卡片

漂在生活

我就是喜欢挑人少的帖子回，如果帖子沉了，我就很有成就感，感觉是自己搞沉的；但若是帖子火了，我也很开心，因为我占了靠前的位置。

这简直就是稳赚不赔的生意嘛！

ljaabb44

不管会的人是多是少，先顶了再说。

漂在生活

我不会啊，期待楼主手把手教一下。

jane

我身边发生的，同个团队的效果对比不太清楚，但团队之间的对比倒是有的。
现状是，通常大家花好多时间在需求讨论，优先级确定上；然后在开发的过程中还是会有需求变更。这让人不爽的是前期的大量投入，换来的还是不断的变化。
还有个比较难操作的是，任务的分解、分配、评估。这事情说起来挺容易的，但是做起来，似乎都在走形式。效果不理想。
在SCRUM中，唯一比较好操作的是晨会，就这个活动，看似还比较靠谱点。
不知道对上面的这些感触，楼主有什么好的建议没？

williams

回复 jane 的帖子

   
    首先，谢谢你问题，你问题概括而言——2条，第一条，需求变更和优先级怎么操作？ ；第二，在SPRINT周期中，BACKLOG的从计划到实现的不可控、不协调。根据以上情况，帮你分担一下：
    首先，大家要明确一下AGILE或者说SCRUM核心思想，在CMMI中，大家讲需求不断分析细化，一般是按照自顶向下逐层细化的，最后细化到可实现为止；RUP中将需求作为对象模型分解成若干集成体，然后通过自低向上的集成来完成需求；SCRUM 在获取需求是先将需求分解到每个需求都是可实现情况为止，也就是说SCRUM需求从实现基础上都是独立和拥有同样的地位，而CMMI 和 RUP的需求都不注重需求的可持续实现，从这种角度就延伸出一个问题，既然SCRUM需求都是一样的，为什么要划分优先级呢？
   （插入：1、从根本而言，完成需求就是我们服务于组织和客户的目的，所以以上我所说的需求完成就是指项目完成；
               2、自顶向下与自低向上，在一个项目实施过程中，有很多的都是结合应用的，我只是针对质量体系特征和项目实施的情
    况而言的通常惯例描述，所以大家不要误解为什么CMMI要自顶想下 为什么RUP要自低向上。）
    SCRUM有几个基本原则和做法，比如PO角色，PO角色就像某个橄榄球俱乐部的老板一样，他和他的董事会再雇佣教练和选择团队的时候他们就会向教练和队员描述俱乐部在这年要实现什么目标。实际上，他就是为了俱乐部服务的，他的需求就是为了符合某个利益。所以PO角色总体的责任就是要负责PRODUCT LINE的利益，那么最为团队和教练就不应该也没有能力去决定什么样的需求最高优先级的，因此，在敏捷中，一定要注意,PO决定需求优先级，不要让团队和教练参与进去,确定需求优先级一切责任和义务交给PO.这样，才能提高一个SCRUM团队的效率。
   需求的变更—— 在本贴文中，我提到了需求的变更问题,这里通过另一个角度的两个方面来帮你解决疑惑，我们为什么说在一个SPRINT Cycle中基本是不允许变更BACKLOG的？首先上节我们说的需求要分解到可是实现为止（需求可实现中需求未必是最小可实现的需求颗粒），那么我们在SPRINT PLANNING MEETING中分配任务的时候就已经对工作量和规模进行估计，并准备SPRINT Cycle进行冲刺，什么叫冲刺，冲刺就是尽全力在短时间内完成到达终点，如果在一个冲刺阶段，你变更需求，相当于你百米冲刺的时候多加了跨栏，那么能在规定实现完成任务嘛，所以这是一个较大风险会很大导致项目的迭代目的失败。从另一方面说，一个项目有无数次的冲刺，按照计划初始的时候 你为项目终极目标设定了每个冲刺所需要力量（资源 技术 环境）。但是突然在一个冲刺阶段 添加一个或多个跨栏，那么就算你再上一个SPRINT Cycle中按计划达到目标，但是已经透支体力，你怎么保证下个SPRINT Cycle 你力量去完成目标呢。所以在一个SPRINT Cycle中不断更改目标是导致SCRUM失败主要原因。
     （插入：为什么说SCRUM中，控制风险制度很高，原因是需求颗粒小，周期短促迭代降低风险系数以及团队的互补增减团队成
     员之间的监督，所以在PO出具P-BACKLOG的时候，我们将他分解成SPRINTBACKLOG的时候尽量将SPRINT CYCLE之于可控可
     估状态）
     那么，上段说了需求不要再一个SPRINT PLANNING MEETING后变更，站在PO角度说 ，我们响应客户的，要尽早创造最值钱的产品，所以BACKLOG必须更改，那么听到这些话，SCRUM可以要求重新开SCRUM PLANNING MEETING来确定优先，来制作完成最高的优先级故事点，或者这个新需求挪到下一个SPRINT再作出修改。

    回答第二条问题：
    我要知道SCRUM是迭代形式交付可工作的软件，在软件特征上，是要与上一个迭代的产品的功能集成或者是修复上一次迭代没有解决的软件问题，也就是我们常说增量。那么说到迭代我们就要知道迭代形式起源来自WATERFALL,是针对WATERFALL缺点而眼生出来的，有实现软件的目标一致，交付手段不同，那么在迭代开发周期中是由许多小WATERFALL组成，为什么WATERFALL现在还有用的 因为她有一条很重原则，就是有层次性，没有上一个产品或产品组件（或称为活动）输出必然指导一下相关产品输入，就像软件没有做出及没有办法通过测试活动来验证功能一样，就像你不能拿着需求规格说明书 设计说明说去做测试验证一样。现在就映射到SCRUM团队中针对一个sprint cycle 中活动来，常规WATERFALL开发要求文档是为了承诺和记录以便最后评估结果和过程检查，在SCRUM由于有了DAILY SCRUM MEETING、及团队集体工作环境、故事墙和白板等工具 环境 所以导致“个体”交互是非常强烈的，这就是为什么要求SCRUM的团队基本特征必须有以上情况才可以的缘故，所以你说的sprint cycle过程中总会出现不可控情况的原因就是 团队虽然有SCRUM特征 但是却没有真实SCRUM内涵，那是出现在沟通机制不完善，SCRUM MASTER的游戏规则不准确，SCRUM TEAM不积极 等缘故，这是团队内部建设的问题。以后要注意这点。（另外，我可能以后会针对SCRUM团队建设讲解几点）

（另外：我们不要认为拥有SCRUM基本特征就是掌握了SCRUM规则，不是的，取决一个SCRUM团队是否真实，在于我们团队成员的决心和毅力——“SCRUM ：和谐为主，以人为本”）

arfeng

敏捷开发不论是XP也好，SCRUM也好，最核心的是敏捷式地估算与规划，这也是敏捷实施的难点，只要将这两处难点解决后，其余的只是形式了。

lanj

溜达过来了～～

啊舟-XL

你好 lz 我想问个问题 为什么敏捷中用story points来进行估算 为什么不用传统的人时呢？用story ponits 估算有什么好处？项目组都习惯了用人时来估算。谢谢

思步网

啥也不说了，楼主就是给力！

扣费

看帖看完了至少要顶一下哦~

端木若希

不错 支持下下

太阳雪下

很有借鉴意义，先收藏了，谢谢楼主。

影子旧人。

路过 帮顶 嘿嘿

炙年

学习下我只是路过，不发表意见……