玩排列的图和日用图

scrum在我们的公司内终于落地了。我喜欢它。

为了展示我们几个月来的实践，我觉得做一个ppt给大家看看。做的过程中，我想对比还是必要的吧，想起2003年我们曾经研究过的rup，2005年的cmmi等等。我想也许通过这样的对比让大家更加喜欢它。我决定弄些rup，cmmi之类的模型大图来看。

首先是rup的​​​​​​​​阶段图：把整个开发过程分为inception,elaboration,constrution,trnsition 四个阶段，在这四个阶段中需求，设计，实现，策划书，发布等在里面占有的份儿绘制出一个大白的波形出来。看上去真的优美。这是rup的标志图，提到rup，总是可以看到这一片美图：）。看起来一目了然，可是有什么实践价值呢？这张图到底是谁发明的呢?rational公司干的，具体是说，我说不上。在公司面前，个人的力量是不会特别表明的，除非商业需要。

然后是bhom的螺旋图：

很朴实的黑白图，看起来像是数学上的某个曲线，或者是一个蜗牛的壳子。有点学术化，不如rup的大图看起来有吸引力。不过也是复杂中透着细节，作者也花费了不少的精力吧。

再来一个瀑布，这个是软件模型的老祖宗了。也是被骂的厉害的。它的作者是《Royce, Winston (1970), “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON 26 (August): 1–9. 》。为什么说被骂的厉害呢？因为不管是rup，cmmi，还是某个宵小发明的一个新的软件模型，都会先把瀑布骂一顿：“老了，不合时宜了，没有考虑到xxx,失败案例非常的多”等等。这个模型在软件工程中的地位和C语言很有点类似——资格老，资源多，但是问题也多——看看近年来的新语言的发布是不是在说，"恩，是的，C语言问题有很多，用了我的语言，你的问题就不必考虑了，因为我解决了;你可以集中精力于自己的业务上，而不必考虑技术细节了"。不同的是，骂c语言的，同样包含着尊重，而瀑布模型就没有那么舒服了。为什么呢。

我发现C语言的发明人里奇还活着呢，还拿了图灵奖。而Royce Winston于1995年与世长辞！骂就骂了，你还能跳出来咬我一口？

再来一个v字模型。这又是一个我无法找到owner的图。我刚刚看到这张图的时候，觉得醐醍灌顶：要知道作为管理者，必须要知道瀑布模型的每个阶段在何时结束，我必须从大家的反馈中得到这个信息，而不是从开发者自己的一厢情愿出发。现在V模型让我知道其实需求分析的结束和成功与否应该有“验收测试”来决定，编码的完成应该有单元测试决定。现在我就可以不但从开发者，而且从测试的角度来看是不是完成了。就是说，开发者说完了，测试者说完了，我才会认为，OK，下一步。V模型是有价值的，尤其是对不了解细节的管理者而言更加如此。

可是V型也有麻烦，有人提出X模型（欣慰，x模型是有主的）。引用：“Marick对V模型的最主要批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等等”。  可惜看起来X模型不如V模型直观，文档也比较少，所有其实影响不大。

好了，就这么多了。有没有发现，尽管图形从黑白到花哨，从一维到两维，从单线到有弧度，其实并无本质变化。只不过把需求，开发，测试，发布这几个环节变来变去？不好意思，​我突然想起一个笑话：“春天来了，一群大雁向北飞，一回排成S形，一会儿排成B型”。我并无恶意，但是这些模型其实并无创见，知道就行了。

相比于这些拉拉杂杂、帮助理解的、​并无实用价值的图形，我认为只有贯彻整个软件的生命周期，并且每天都要看的图形更加有价值。而scrum的图就只有一张，并且每天都要看，这就是burndown图。我的一个同事提出了一个不敬的但是形象的说法，叫做爬行图。还真的有点像。下面这张图看起来好简单。

我稍微做一个解释，纵坐标表示剩余的小时，比如408小时是初始的团队总估计时间，​​​横坐标表示timeline，1-30表示一个sprint的30天。沿着日期的增长，剩余的任务小时通常应该是不但的降低的。当然实际的情况是这张图的曲线中间有些突起，这是正常的，可能是因为临时加入了任务，或者是估计的重新调整。在过去的两个月来，我每天都要看它，并且我们的团队成员在Daily meeting中也要看到它。这张图让我大致的知道，我们的进度是不是正常的。中间的每一个突起我都知道原因。这个过程配合我们的Daily meeting让交流更加顺畅，让每个人知道我们现在的状态，我们昨天完成了什么，在图形上是否有所贡献（你的工作是否让整个团队的剩余工作小时变得减少），下一步要做什么。​

 

这样的图是我们真正需要的。