什么是敏捷开发方法?什么是SCRUM?(2)

　　下面我们来看看他们是如何使用SCRUM。

　　1. 每日晨会

　　“其实大家都知道沟通进度的重要性，但我们双方7、8个小时时差，那边一上班这边就快收拾东西走人了，就这样还要讲自己今天要做些啥，遇到啥困难，一点意思都没有。很快Stand-up Meeting就成了形式。后来，我们又间歇性地在自己团队内部做Standup，但最后还是因为不能带给我们太大价值，流于形式，就放弃了。”

　　其实，在敏捷的实践中，每日晨会是最容易做，也是最有效果的实践之一。那为什么最后会流于形式，而放弃了呢?

　　一、会议的时间不好。中国团队快下班了，准备收拾回家。通过我们的实践，发现站立会议最佳的时间是早上。比如：9点上班，会议时间可以定在9：30。早上到公司之后，大家收个邮件，处理一下个人的事务。到点了，按时的举行晨会，然后全身心的投入到一天的工作中。这样，很自然，开发节奏很畅快。

　　二、从上面的描述，明显可以看出来。大家对它是有抵触心理。或许是在抵触会议，或许是在抵触SCRUM，或许本来就已经上火，只是借此宣泄。

　　三、这是最重要最重要的一点：团队的文化氛围。说具体一点，晨会不是每天的工作报告，更不是项目经理进行工作检查，甚至考核。项目经理有责任营造一个安全 (Safe)的会议氛围，让每个人都乐意说出真正发生的事情，就算是昨天遇到技术问题，没有任何的工作成果，也能得到谅解，而不是胆颤心惊。比如：我们在每天早上做站立会议的时候，可以端杯饮料，很轻松的围成一圈，说说笑笑，然后会议结束，就开始一天的工作。

　　2. 迭代任务

　　“在第一次使用ScrumWorks的时候，好歹Product Owner还能来设置优先级，我们估算时间，最后决定哪些故事放到下一个Sprint里面。到后来就只要是人，就能往Scrumworks上扔任务，也不知道哪些重要哪些不重要，我们自己开发人员看着办，最后剩下几百个小时完不成再扔到下一个Sprint里面去”

　　显然，大家的迭代过程很随意，松松散散，没有任何的约束。有的网友说这是公司制度的问题。那无疑是在“头痛医头，脚痛医脚”。如果，这时还拿制度说事，明显是在和敏捷精神相悖。敏捷方法，表明看上去管理松散，没有规章制度。其实不然，它有很多的准则，要求每个人能够自觉遵守，养成工作习惯，成为一种职业素质，最终目标是要形成一个自组织的团队。例如，谁可以往Scrumworks上扔任务?这明显是产品主管的职责。就算是开发人员想往上扔任务，也应该和产品主管以及整个团队讨论，明确任务的价值和优先级之后，再决定是否可以把任务放到当前的Scrumworks上。这是最的基本要求，这是每个团队成员默认遵守的原则，甚至可以认为这是一个开发者最起码的职业素质要求。

　　我们从上面的描述可以再次看出，大家是在对SCRUM有抵触的。如果，到现在，推广者到还不能让大家理解、认可和接受SCRUM方法。那么，引入SCRUM，也绝不可能获得成功，甚至会直接拖垮整个项目。

　　敏捷方法，需要有一个英明的领导(也许就是Scrum Master)，以身作则，带领着团队向前冲锋，大家齐心协力，以项目的成功作为最高奋斗目标。只有这样，才能发挥敏捷方法的威力，只有这样项目才可能获得成功。

　　再回到迭代开发，它能给我们带来什么样的好处呢?

　　一、明确的短期目标。如果让一个团队做半年的详细工作计划，一定非常困难，但如果是2周，那就完全不一样。假设，客户有100个东西要做，但团队在一个迭代(一般是2周左右)中，只能完成20个东西。那么就明确的告诉客户，一个迭代的时间，我们只可以完成20个东西，那么我们先开发其中20个最有价值的东西好吗?

　　二、如何知道团队在一个迭代可以完成多少任务呢?显然，迭代只有两周的时间，相对的计划会很准确，而且前面一个迭代的工作量，是这个迭代最好的参照。如果是第一个迭代，根据团队的经验做好一个合理的2周计划应该不难。

　　三、迭代结束之后，给客户演示工作成果，及早获得用户反馈。同时团队在一个迭代结束之后，也会对整个开发的状况进行思考和反省，举行一个回顾会议，客观的讨论前一段时间的工作，哪些地方做的好，哪些地方做得不够好，对不好的地方，要能讨论出具体可行的解决办法。

　　敏捷的团队就是用这种迭代的方式，增量的进行工作。小步前进，不停的思考、反省和总结，不停的进行自我调整和完善。让自己一步一步的变得优秀，走向卓越。

　　总而言之，如果只是学了SCRUM的形，却没有敏捷的意，没有掌握敏捷的思想和精神，那么再怎么使用SCRUM，仍然只是在东施效颦。

　　成功案例分析

　　到此，也许你会吸取上面两个失败案例的教训，也认同文中的分析，觉得敏捷很实用、很有价值;也许此时，你却在紧缩双眉，因为敏捷的思想和精神，让你觉得有点理想化，不切实际。

　　是的，思想和精神只可意会不可言传。这些只可以在每天的工作和问题中去领悟、体会和沉淀。在学习敏捷方法的时候，我们应该尽可能多和深入的学习，并融会贯通。在具体工作的时候，我们先要忘掉学到的条条框框。首先分析自己的上下文环境，找出最主要的矛盾，然后根据团队状况，通过学到的经验和方法将这些问题进行平衡和解决。

　　下面我们看一下璎珞天色是如何在项目引入SCRUM的。他们路线是这样：

　　“我们不是采用纯粹的Scrum，而是将Agile中的很多理念，包括XP的部分做法，然后结合现有的开发环境与要求，用Scrum的回顾不断地做改进，从而趟出自己的一条路。如果这个Sprint我们回顾时觉得自己代码Review(审查)做的不好，下个Sprint就会引入新的代码Review机制。这个Sprint觉得重复性的bug较多，下个Sprint就会引入缺陷预防机制。我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不断改进”

　　他们的具体做法如下：

　　“其实我们一开始并没有把Scrum这个说法拿出来。就是首先和业务一起商量什么时候上线，商量出来的结果是每个月定期上线。于是就有了一月一个项目的进度(我们是线上服务，没有版本的概念，有一堆需求过来，对技术来说就是在这一个月以内完成这些需求，把这一个月以内的工作叫一个项目)。然后为了管理，我们开始开晨会。然后为了改进，我们开始开项目总结会，把Product review和Team retrospective放在一起，既有产品经理介绍现状，也有大家讨论成绩，不足和挑战。后来总结会上觉得质量不好，我们加入了单元测试和代码 Review机制。至于计划会议，一开始我们就采用的Scrum的方法。项目小，MS Project太难调。我们就更换了Scrum的Excel计划表，后来又换了Xplanner。”

原文转自：http://www.ltesting.net