《火星人开发纪实：敏捷开发一千零一夜》第二个月：框架优先，还是故事群优先

（序言，之一，之二，之三，之四，之五）

 

先开发整个框架，还是先开发故事群？

         当用户故事的增删改查都还没做的时候，这个问题就被提了提出。

         最初曾经想：只做故事的显示功能，增删改都在数据库内直接操作，然后迅速进入“迭代计划”部分，把迭代计划大致弄出个样子来后，赶紧做燃烧图、故事板……

但是这个想法很快就被否定了，因为在此前做敏捷咨询的时候就曾经在用户项目里发现：如果把一个产品的所有“最重要的功能”单独提出来，不但不会生成一个最小的可用功能集合，反而会生成一个血肉模糊的四不像。

         所以就选择了把用户故事的功能尽量开发完整，再向前推进，这样的一个产品尽管缺少很多功能，但是已经有的功能却完整可用。我们还为这样一组相对完整地进行分析和交付的功能称为“故事群”。

但是在用户故事的增删改查全部完成的时候，这个问题又回来了：是继续开发用户故事排序、讲解、估算的界面，让“用户故事”相关的故事群更加丰满完整；还是转而开发迭代计划、燃烧图等其他模块的基本功能，先把架构搭起来？

架构优先还是故事群优先？这是个问题。

跟着感觉走

         还好不是第一天做项目了，不想坐在旁边让方法论打架；也不想依赖Google或者百度。我们的项目，我们做主。

         终于找到一个标准，作为判断的准则：那就是问自己，现在是更容易开发故事排序、讲解、估算的功能，还是更容易开发迭代与计划的功能？思考的结果，答案是后者。

         现在回忆起来，这就有点像走夜路，隔一段点亮个蜡烛，很令人不放心；但只停在一个地方修建个大灯塔，就连走路的基本感觉都没有了。不过在蜡烛和灯塔之间，有一个巨大的落差，要找到的是那种像“隔一段有一个路灯”一样的折中点。

每个产品每个项目，应该有自己不同的抉择点，不能固守成见。

迭代，故事？故事，迭代？

第二个月完成后，产品变成这个样子（这张图中的目录结构，是第三个月产生的）：

最左侧的是没有分配到迭代中的故事，右边的几列则是迭代中的故事。说实话，很丑，但是我们已经可以尽情地创建故事，并把故事分配到不同迭代去了。在项目开始后的第二个月，我们终于拥有了自己最基本的项目计划。

迭代计划的出现，也令另外一个与架构和故事群相关的问题浮上水面：是基于故事制定计划，还是基于计划挑出故事？这有什么区别吗？有。

前者先写好用户故事，然后向迭代中分配，若一个迭代完成不了，则挤到下一个迭代完成；每个迭代根据内部分配的故事，总结出一个简短的名字。这个是很传统的迭代方法。

后者则是相反，先制定每个迭代的目标，并与故事群大致对应（比如前三个迭代目标是“基本故事显示”“基本的迭代计划和燃烧图”“故事树和性能优化”），然后向迭代中分配相关的故事。若一个迭代中的故事未能做完（一般是最次要的故事没有完成），则也不推迟到下一个迭代中完成，而是暂时封存。这样每个迭代尽量保持在做迭代目标的故事。封存的故事有系统管着呢，反正不会被遗忘，最后再说。

后来我们选择了后者。

原因是如果说尝试每个迭代都把某个故事群“彻底做完”，几乎每次都会剩下点什么细枝末节的功能，扰乱下一迭代的完整性，是我们不想看到的。

一波三折

         总结一下第二个月的工作，可谓一波三折。

         在优先完善框架，还是先就一个故事群交付的事情上，多次思考的结果都各有不同。以至于无法总结出到底框架优先，还是故事群优先。

         如果真要写一句总结那就是：敏捷无有定法，每次都先找到自己的判断准则，然后跟着感觉走。

 

免费敏捷开发管理工具：火星人安装指南就绪