我心中的敏捷(5)----SCRUM之项目分解与控制力

本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明: 本文可以不经作者同意, 任意复制, 转载, 但任何对本文的引用都请保留文章开始前三行的作者, 出处以及声明信息. 谢谢.

引言：
博闻而后智慧，勤学更要多实践。相比于以前，现在对于知识和信息的获取便捷程度，已有太大进步。但是，人的智慧却似乎正因为科技的日新月异而变得愈加退化。相比于春秋战国、先秦诸子时期的古人而言，现代的我们，无论在思想深度还是广度方面，都只能甘愿望其项背。很多东西，是一通百通的，我把这种一通百通能力叫作“开悟”。开悟，不仅仅在于你可以有很深的思想，还在于你可以把这些思想灵活运用于自己的工作和生活。对敏捷和SCRUM的理解也是一样，刚开始，我只把它当作一种纯技术层面的开发方式，后来我发现它的很多东西其实是一种方法论，再后来，我发现它的很多东西其实是一种生活和工作的态度。乃至于现在，我甚至将要把敏捷与佛教挂上勾了，这不是说我形而上学，而是，我发现了把思想用于实践、从实践进化思想的最大乐趣。

正文：

我们的团队和产品，在发展过程中，经历了很多个困难时刻，这些困难里，既有技术方面的，也有人员方面的，既有我们自己能克服的，也有靠我们自己的力量解决不了的。但是，从始至终，我们都抱着一个很强烈的信念：作产品，而不仅仅是作技术; 作团队，而不仅仅是作产品; 作好自己，而后再去影响和帮助别人。在我眼里，产品是我们生存下去的唯一希望，而团队则是作出产品的最核心因素。

啰嗦了这么多，其实，我是想说，不管你采用什么样的开发方式，其出发点和落脚点，都首先应该是：把产品作好。在想着把产品作好的前提下，再客观的分析团队、产品、公司的现状，而后决定你及你的团队所走的路。即使一个被别人吹得再神的开发方式，拿给你用时，你也需要从自己的实际出发，看看哪些东西是有利的、哪些东西是无用的甚至是有害的，你要时刻清楚你想要的是什么，而后再决定如何引进和采纳。

我知道，很多人都很明白我以上所讲的道理，只是，所有的问题最终可能都归于：大家尚没有足够的能力去判断哪些有益哪些有害，因而也就决定不了哪些应该引进，哪些应该舍弃。我想说，无论哪个团队，也无论哪个个人，在其成长的过程中，都必然经历过这样一个阶段，不同点在于，你站在一个什么样的角度去分析和处理这些问题。还是上面说的那句话：在这个时候，你需要从产品全局的角度再反复审视一下，哪样作对产品最有利，就采取哪样的作法。

请永远记住：产品第一！只有这一点，才是我们最根本的、也最实际的目标。有了这一点，其它所谓各种各样的开发方式，才有意义，否则，就是在浪费大家的时间，就是在教条化。

铺垫了这么多，现在让我们进入正题，看看我们是如何以SCRUM的方式来驱动一个网游项目的研发。

2006年8月，在我们的产品反复折腾了很多个回合----无任何大进展的回合后，公司高层想在我们产品组推动一种新的开发方式：SCRUM。

在整个SCRUM开发方式方面，我们把一个项目首先分成：若干个“重大版本”，把每个“重大版本”又分成若干个Sprint阶段。

每一个“重大版本”相当于以前我们经常所说的开发里程碑，而每个Sprint则是在“重大版本”这个相对较长的里程碑时间内对工作目标再细化，生成每两周一个的更加可控的开发内容和可发布的小版本。通常，一个“重大版本”的开发周期是两到三个月，而一个Sprint的开发周期则是一至两周。在“重大版本”和每个Sprint的工作目标里，都明确列出了每一阶段准备完成的内容。

此外，采用了SCRUM开发方式的团队，在每天早晨，都会一个很简短的晨会，我们团队也不例外，团队的每个成员在会上只说三句话：昨天完成了什么内容，今天准备完成什么内容，以及今天的工作需要找谁协调（如果有协调需求的话）。注意，在这个晨会上，我们特别强调每个团队成员到底在昨天“具体完成”了哪些内容，不能太笼统，不能太含糊其词，要明确，要具体，要能一说就让别人知道你在作什么以及已经作了什么。

由此来看，对于一个项目目标，我们大致采用了以下的分解方式：


一个完整的产品(12~18个月)
|
-------------------------------------------
| | |
重大版本1(2~3个月) 重大版本2 重大版本3
|
--------------------
| | |
Sprint(2周) Sprint Sprint
|
--------
| |
Scrum Scrum(每天)


在大家的日常开发中，我们通常都会遇到这样一种情况：当项目刚刚开始时，我们都能很详细的列出到哪个时间点作出哪些东西，而实际上，很多的项目，都不能按照预定的时间完成。那么，这是为什么呢？

这是因为，我们只在开始和结束两个端点对产品进行了控制，而没有对产品研发的漫长中间过程进行控制，或者说控制了但没有很好的效果。事实上，在结束时再进行控制已经晚了，我们真正应该发力的点恰恰是这个“中间过程”。那SCRUM有什么比较好的方式对中间过程进行控制吗？当然有，那就是：“逐层分解”，而且，是切实可行、易被贯彻、可见成效的“逐层分解”。

如果仅从对一个项目的进度控制粒度上来说，我认为SCRUM方式更好的在形式上保证了对项目进度在更细的粒度上进行更有效的控制，从而更好的保证产品可以成功：把一个开发周期在12到18个月的完整产品，先分解成2~3个月的研发短周期，进而又把这2~3个月的时间再细化，划分成2周粒度的Sprint目标，而具体到了每一天每一个人的开发任务上，又让每个人明确了自己今天和明天要作的事，同时大家也能明确知道未来两周自己的开发目标。

很多公司和很多团队，整天在喊我们没有执行力，我们一定要提高执行力。什么叫执行力？怎样才能提高执行力？我认为，如果保证了这样的控制力，就一定可以产生执行力。

如果从对整个项目的分解层次来看，SCRUM方式，很强调对于项目的控制力，同时，也很强调尽快推出版本的能力。作互联网产品，特别是作网游产品，绝大多数的团队由于水平、经验等诸多方面的原因，都无法保证自己作的东西就一定是符合用户需求和玩家喜好的，所以，我们需要在正式版本之前不断投放一些先期测试的版本，先行开放一部分功能给用户尝试体验，开发团队在这种反馈的基础上再对设计进行调整和完善。

我以前曾经说过，比起传统软件开发，采用了敏捷开发的团队，在研发理念和深层次思想上，已经有了太大的不同：传统软件开发方式，把一切都设想得太好，假定世界美好、用户需求相对稳定，所有事情按步就搬，缺乏活力和创新；而敏捷开发，很务实，它首先承认我们不可能弄出一个完美无缺的版本出来，然后提出了一系列如何把产品从不完美变得逐渐完美的方法，在这些方法里，“尽快发布最新可用版本”成为一种最为有效、务实的手段。

SCRUM作为敏捷方法论的一种实践方式，它自然也是朝着这个目标走的：尽快开发，尽快测试，尽快发布可用版本，尽快让用户体验，尽快让开发团队知道自己的不足，这样又反过来激励开发团队把产品作得更好。而产品作好了，公司可以赢利，团队就能生存下去，这些都是很实际的问题。

我们为什么这么强调“尽快发布版本”？从更深层次的思想上，是因为我们承认并坚信：用户，只有用户，才是对产品是否好用、是否有用的最有效裁判者，而不是设计者本身！作传统软件时，可能你的用户只是一两家企业，你可以整天泡在你的用户那里，把各方面的需求了解得清清楚楚、明明白白、真真切切，但是，互联网的用户动辄千、万计，甚至百万、千万、亿计，你无法靠一个设计者的脑袋去考虑清楚这么多人的需求和喜好，你只能尽快提炼出他们需求中最重合的、“你自以为有用”的需求，而后尽快把想法实现出来，把可测版本推到用户面前，去验证你的设计，然后再尽快推出新的版本来满足你从用户那里得到的新有效需求。

从某种意义上来说，这种开发模式下的软件形态，是一种周而复始、不断进化的过程，它甚至已经超越了我们以前所了解的传统软件生命周期模型。蓦地，这让我想起了佛学里所说的轮回，是的，只要这种开发方式下出来的产品走上良性循环，它的存在形式本身就是一种轮回。

下一篇文章，我将继续与大家分享我的敏捷和SCRUM体会，主题将是：如何具体规划每一天。