SCRUM敏捷开发基础及失败成功案例分析

SCRUM敏捷开发基础及失败成功案例分析什么是敏捷开发措施？什么是SCRUM？有人在这个字面上下功夫，说敏捷就是反应要敏捷，动作要快捷；有人还在字面上进行延伸，说敏捷就是又好又快，或者就是多快好省；有人说敏捷就是光写代码不写文档；有人觉得敏捷就是没有制度，管理松散的工作方式；有人觉得只要敏捷了，就代表高软件交付水平。那么，敏捷这个词究竟由何而来呢？在九十世纪中期，涌现了一批软件行业的激进人士，他们反对那些以过程为本的重型软件开发措施（例如：老式的瀑布开发方法）。在，17位软件业界的专家们齐聚一堂，讨论正在兴起的轻量级开发措施（Lightweightmethods）。专家们给此类轻量级的措施学起了一种新的名字叫做敏捷，并公布了敏捷开发者宣言。敏捷措施强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，常常使用反馈进行思索、反省和总结，不停的进行自我调整和完善。敏捷开发措施是这些轻量级措施的总称，它旗下有诸多详细的开发过程和措施。重要的有：极限编程（XP）、特性驱动软件开发（FDD）、SCRUM开发措施等等。SCRUM开发措施是由JeffSutherland在1993年创立，Jeff也是制定敏捷宣言的17位专家之一。SCRUM借用了橄榄球运动中的术语——一种团体拿球向前冲。严格的说，SCRUM是遵照敏捷措施的一种软件开发框架。在SCRUM框架中，融入敏捷开发的精神和思想，就被称作SCRUM开发措施。SCRUM是一种什么样的开发框架呢？简朴说，它由三个角色（Role），三种会议（Ceremonie），三项工件（Artifact）构成。·角色（Role）：产品主管（ProcuctOwner），他负责项目的商业价值；SCRUM师傅（ScrumMaster），他负责团体的运转和生产；以及自组织的团体。·会议（Ceremonie）：迭代计划会议，每日晨会（dailyscrummeetings），迭代回忆会议。·工件（Artifact）：用来排列任务的优先级和跟踪任务。待开发任务列表（productbacklog），迭代任务列表（thesprintbacklog），进度图（burndownchart）在敏捷刚出现的时候，极限编程（XP）一直是主流。不过，在敏捷措施开始在全世界流行的今天，为何最红火的却是SCRUM？这是由于SCRUM更轻易普及和推广。其实极限编程包容了SCRUM措施。我们从工程学的角度，可以把软件开发提成两部分：过程（分解任务，排列优先级和迭代计划）和代码实现（高质量的代码和自动化的代码保障体系）。其中最难的就是代码，最有直接商业价值的是过程。SCRUM则回避了最难的部分，加强和创新了最能直接体现商业价值的过程部分。这就是SCRUM！失败案例分析我们这里借用SCRUM实行调查中的两个词“成功”和“失败”。其实，我们很难定义成功和失败。在实行调查中，失败可以理解为使用SCRUM不妥，没有到达预先的期望，直至最终团体放弃了SCRUM。成功是意味着大家还在继续使用SCRUM，从某种程度上说，就是SCRUM到达了团体的预先期望，至少是可以接受的期望。我们先看第一失败案例：某著名大型互联网企业，被采访者是一种叫David的工程师。他是这样总结失败的原因：“有些高层错误理解了Scrum和Agile，导致歪曲了某些东西，使得Agile变得形式化”他们在项目中尝试使用了SCRUM中的一种实践：每日SCRUM会议。下面是David描述不理解SCRUM的项目经理，怎样使用这个实践的：“项目经剪发现这个东西挺好，就单独把DailyScrum拿来进行推广；成果，这个经理并不理解什么是Scrum，他把DailyScrum变成了DailyReport：每个员工都要在早上固定期间开DailyScrum，然后把当日的任务告诉给他，让他来决定工作是不是饱满。而其他Scrum的精髓部分都没有推广。”有的网友分析，得出结论说失败是由于“这家大型互联网企业的制度和文化的问题”。当然，失败肯定是跟这有关系，但我觉得还没有直接上升到整个企业的制度和文化。理解SCRUM的人，都会很清晰。他们对SCRUM的应用很初级，也只用了一种SCRUM中提到的晨会（其实，在其他诸多的软件开发措施中均有这个实践）。我们可以看出，他们的问题就是：项目经理主线不懂得什么是SCRUM。也许连自己在开发中碰到了重要问题是什么都还不清晰？就到处寻药，甚至就给自己下了一种处方。我们就以每日晨会为例，在SCRUM中，明显的提到，在会议中每个人只可以说三件事情：1.我昨天做了什么2.我今天准备做什么3.我在工作中碰到了什么障碍。每日晨会，目的有二点：1.加强团体交流和信息共享。互相理解彼此都在做什么工作，完毕了什么任务。这样，每日的信息传递，可以让每个人可以更多的理解整个项目的业务和技术状况。并且假如在工作中碰到障碍或问题，也可以在这时候提出来，祈求大家的协助（其实，一般在敏捷团体中，碰到问题，都会当场就提出来，或直接去找有关的同事，问他们有无处理过类似的问题，或者有无某些提议）。2.促使每个人在早上做好一天的工作计划。这样，每个人一天的工作就会有明确详细的目的。这会直接提高一天的工作效率。因此，上面的这个失败项目主线谈不上是在使用SCRUM。连基本的SCRUM框架还没有弄明白，就更谈不上敏捷的精神和思想了。第二个失败案例是一种离岸开发的某创业型企业。虽然团体比较特殊（离岸开发团体），但这个失败案例却非常经典和普遍。“某一天，国外的PM忽然发来几种链接，一看讲的是一种闻所未闻的词，就是Scrum了。仿佛就给了一两天的时间去看Scrum的简介文档，然后就开Stand-upMeeting（站立会议）。”和第一种案例相比，这个案例的团体是真真的在推行SCRUM。从表明看，大家也是在按照SCRUM框架的方式工作：有对应划分的角色，有详细的分解任务，有会议，也有迭代（Sprint）。那又怎么会失败呢？显然，他们是在照搬照套了SCRUM的框架。他们是两个离岸的开发团体，由于地点、时区和语言的差异，很轻易就会导致沟通和交流不畅，这时候再生硬的引入SCRUM，无异是火上浇油。下面我们来看看他们是怎样使用SCRUM。1.每日晨会

“其实大家都懂得沟通进度的重要性，但我们双方7、8个小时时差，那边一上班这边就快收拾东西走人了，就这样还要讲自己今天要做些啥，碰到啥困难，一点意思都没有。很快Stand-upMeeting就成了形式。后来，我们又间歇性地在自己团体内部做Standup，但最终还是由于不能带给我们太大价值，流于形式，就放弃了。”其实，在敏捷的实践中，每日晨会是最轻易做，也是最有效果的实践之一。那为何最终会流于形式，而放弃了呢？一、会议的时间不好。中国团体快下班了，准备收拾回家。通过我们的实践，发现站立会议最佳的时间是早上。例如：9点上班，会议时间可以定在9：30。早上到公司之后，大家收个邮件，处理一下个人的事务。到点了，准时的举行晨会，然后全身心的投入到一天的工作中。这样，很自然，开发节奏很畅快。二、从上面的描述，明显可以看出来。大家对它是有抵触心理。或许是在抵触会议，或许是在抵触SCRUM，或许本来就已经上火，只是借此宣泄。三、这是最重要最重要的一点：团体的文化气氛。说详细一点，晨会不是每天的工作汇报，更不是项目经理进行工作检查，甚至考核。项目经理有责任营造一种安全（Safe）的会议气氛，让每个人都乐意说出真正发生的事情，就算是昨天碰到技术问题，没有任何的工作成果，也能得到谅解，而不是胆颤心惊。例如：我们在每天早上做站立会议的时候，可以端杯饮料，很轻松的围成一圈，说说笑笑，然后会议结束，就开始一天的工作。2.迭代任务

“在第一次使用ScrumWorks的时候，好歹ProductOwner还能来设置优先级，我估算时间，最终决定哪些故事放到下一种Sprint里面。到后来就只要是人，就能往Scrumworks上扔任务，也不懂得哪些重要哪些不重要，我们自己开发人员看着办，最终剩余几百个小时完不成再扔到下一种Sprint里面去”显然，大家的迭代过程很随意，松松散散，没有任何的约束。有的网友说这是企业制度的问题。无疑是在“头痛医头，脚痛医脚”。假如，这时还拿制度说事，明显是在和敏捷精神相悖。敏捷措施，表明看上去管理松散，没有规章制度。其实否则，它有诸多的准则，规定每个人可以自觉遵守，养成工作习惯，成为一种职业素质，最终目的是要形成一种自组织的团体。例如，谁可以往Scrumworks上扔任务？这明显是产品主管的职责。就算是开发人员想往上扔任务，也应当和产品主管以及整个团体讨论，明确任务的价值和优先级之后，再决定与否可以把任务放到目前的Scrumworks上。这是最的基本规定，这是每个团体组员默认遵守的原则，甚至可以认为这是一种开发者最起码的职业素质规定。我们从上面的描述可以再次看出，大家是在对SCRUM有抵触的。假如，到目前，推广者到还不能让大家理解、承认和接受SCRUM措施。那么，引入SCRUM，也绝不也许获得成功，甚至会直接拖垮整个项目。敏捷措施，需要有一种英明的领导（也许就是ScrumMaster），以身作则，带领着团体向前冲锋，大家齐心合力，以项目的成功作为最高奋斗目的。只有这样，才能发挥敏捷措施的威力，只有这样项目才也许获得成功。再回到迭代开发，它能给我们带来什么样的好处呢？一、明确的短期目的。假如让一种团体做六个月的详细工作计划，一定非常困难，但假如是2周，那就完全不一样样。假设，客户有100个东西要做，但团体在一种迭代（一般是2周左右）中，只能完毕20个东西。那么就明确的告诉客户，一种迭代的时间，我们只可以完毕20个东西，那么我们先开发其中20个最有价值的东西好吗？二、怎样懂得团体在一种迭代可以完毕多少任务呢？显然，迭代只有两周的时间，相对的计划会很精确，并且前面一种迭代的工作量，是这个迭代最佳的参照。假如是第一种迭代，根据团体的经验做好一种合理的2周计划应当不难。三、迭代结束之后，给客户演示工作成果，及早获得顾客反馈。同步团体在一种迭代结束之后，也会对整个开发的状况进行思索和反省，举行一种回忆会议，客观的讨论前一段时间的工作，哪些地方做的好，哪些地方做得不够好，对不好的地方，要能讨论出详细可行的处理措施。敏捷的团体就是用这种迭代的方式，增量的进行工作。小步前进，不停的思索、反省和总结，不停的进行自我调整和完善。让自己一步一步的变得优秀，走向卓越。综上所述，假如只是学了SCRUM的形，却没有敏捷的意，没有掌握敏捷的思想和精神，那么再怎么使用SCRUM，仍然只是在东施效颦。成功案例分析到此，也许你会吸取上面两个失败案例的教训，也认同文中的分析，觉得敏捷很实用、很有价值；也许此时，你却在紧缩双眉，由于敏捷的思想和精神，让你觉得有点理想化，不切实际。是的，思想和精神只可意会不可言传。这些只可以在每天的工作和问题中去领悟、体会和沉淀。在学习敏捷措施的时候，我们应当尽量多和深入的学习，并融会贯穿。在详细工作的时候，我们先要忘掉学到的条条框框。首先分析自己的上下文环境，找出最重要的矛盾，然后根据团体状况，通过学到的经验和措施将这些问题进行平衡和处理。下面我们看一下璎珞天色是怎样在项目引入SCRUM的。他们路线是这样：“我们不是采用纯粹的Scrum，而是将Agile中的诸多理念，包括XP的部分做法，然后结合既有的开发环境与规定，用Scrum的回忆不停地做改善，从而趟出自己的一条路。假如这个Sprint我们回忆时觉得自己代码Review（审查）做的不好，下个Sprint就会引入新的代码Review机制。这个Sprint觉得反复性的bug较多，下个Sprint就会引入缺陷防止机制。我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不停改善”他们的详细做法如下：“其实我们一开始并没有把Scrum这个说法拿出来。就是首先和业务一起商议什么时候上线，商议出来的成果是每月定期上线。于是就有了一月一种项目的进度（我们是线上服务，没有版本的概念，有一堆需求过来，对技术来说就是在这一种月以内完毕这些需求，把这一种月以内的工作叫一种项目）。然后为了管理，我们开始开晨会。然后为了改善，我们开始开项目总结会，把Productreview和Teamretrospective放在一起，既有产品经理简介现实状况，也有大家讨论成绩，局限性和挑战