一个100个点的Story的故事

（真实场景改编）

　　这个迭代开始的时候，团队急急忙忙跑来找我，说遇到了一个紧急的问题，看看有什么办法没有。

　　我问：“什么问题呢？”，团队的Master回答说：“你还记得之前那一个１００个点的Story吗？”。

　　我想起了两个迭代前，团队接到了一个大需求。当时团队采用敏捷的故事拆分方式尝试着拆了一下，感觉用这样的拆分方式开发人员有很多的重复工作。于是又采用瀑布的方式把所有的开发测试任务一口气拆出来，评估了一下感觉总体进度可以提前而且没有重复的工作。于是团队就决定这个大需求就用一个故事来描述，然后就开始开发一直到现在了。

　　团队Master接着说：“我们遇到麻烦了，前两天开发自测的时候发现了一个新的场景，结果和PO确定完后，PO说现在实现的原则和需求不符，需要进行调整。这一下新的原则实现又要十天，这样的话这个迭代我们就又交不了什么Story了。之前两个迭代开发基本上吧所有的开发工作完成了，使用了一个算法把所有的场景都覆盖了，按计划这个迭代我们完成测试和自动化工作以后就要完成这个Story的，结果需求这么一来这个迭代我们肯定交不了了。而且，更有风险的是，要是到了后面PO又有原则需要调整的话，我们的Story就又要往后延迟了。现在可怎么办呀？”

　　看着Master焦急的面容，我不禁想起了两个迭代前的情景。当时团队经过计划会议以后，决定采用这个１００点的Story进行后续的开发。当时询问团队Master这么做的原因时，团队的Master说：“我们比较过两种拆分的方法了，多个Story工作量比一个Story的大很多，开发还有很多的重复工作，浪费时间。所以我们经过讨论就是用一个大Story不拆分了”。后来过了一个迭代后，再去与团队Master面谈的时候，团队Master还强调：“我们的开发就觉得拆成多个Story的方式有重复工作，前面做完的简单场景到了后面实现复杂场景的时候还要重做或者推翻，从来没有见过这么拆任务的”。于是这样一个大Story就这么产生了。

　　现在和团队Master一起的还有两个开发代表，其中一个说：“现在这个Story拖了这么长时间，中间发现需求可能会改来改去的，这就和我们之前做的另一个功能一样，需求调来调去，用了前后三年时间才真正完善。照这样下去，我们这个Story就永远也交不了了。怎么办呢？”

　　我刚要说话，团队的Master接着说：“现在虽然开发任务基本都完成了，但是测试的用例还没有完全写完，也没有开始测试呢，自动化也没有开始。这样的需求变更（要求的细化）让我们的测试用例也得返工。我们是等着这次的变更全部做完再测试好呢，还是有什么其他办法？”

　　说到了测试，我想起上次和团队Master见面时和他们说起的一个观点：“对于这么大一个Story，把所有的开发任务做完以后再做测试任务，相当于把开发测试任务串行起来了。对于开发来讲，任务没有重复工作量变小了，但是对于整个Story来讲，由于开发测试任务没有能够并行，整体的交付时间反而是拖长的。”，团队的Master当时认可这个观点，但是觉得还是不好拆分。

　　所以，趁着这次开发代表也在，我就和开发讨论了一下实现的细节，看看重复的工作量的大小和可能的拆分方法是否可行。讨论过后，开发认可了虽然开发有些重复的工作量，但是对于整个团队来讲交付时间可以缩短，而且风险可以提前暴露。这样的工作量还是值得的。

　　这时Master又说：“现在这样的做法，自动化一点忙都没有帮上，用户故事总是完成不了，测试没法开始，自动化工作一直等在那里。需求一改，测试就只能再全部测试一遍。这哪里是节省工作量呀”。

　　听到这话，我很欣慰。上次和团队Master见面的那次谈话看来还是给他们留下了深刻印象了。上次和团队Master们说道自动化工作因为大Story总不能开始时，就提到：如果把Story拆小，比如先做简单场景，那么简单场景的测试和自动化工作都可以很早就完成。后面做复杂场景时，就算代码实现上要全部重写一遍（一遍也没必要），但是简单场景已经被自动化覆盖了，可以节省很大一部分测试工作量。前面的场景都一个个的被自动化覆盖，那么就算后面的场景对前面的场景有影响，也很容易识别出来。就不需要测试进行重复的测试，这样又节省了整体团队的工作量，又做到了风险前移。

　　此时，两个开发也表示认同这样的观点。表示应该要想办法去拆分一下Story。站在团队的角度考虑，尽早交付，尽可能把风险前移，更好的响应需求变化，因为需求变化是不可避免的。他们还说：“当时估算１００个点的任务时，把所有的开发任务都拆出来了，有很多每一项都进行了估算。但实际上做了这么两个迭代发现有好多的任务都没必要拆或者合并到其他任务里捎带手就做了，这样的计划执行到现在已经非常不准确了”。“计划倒是本来就不准的，不过这些没必要的任务还占用了不少当时的计划会议的时间吧。”我补充道。“是，是这样的，其实现在看起来没必要拆那么多任务”三个人点头道。

　　于是，商量了一下后续的策略，把能拆的Story尽量都拆出来。尽早交付一些，以便应对后续的变化。

　　就这样，一个大的Story经过了两三个迭代的团队尝试，终于在团队的脑海中被拆除掉了。总结一下，给后来的团队。

拆分Story的好处

　　１、开发、测试、自动化工作可以并行开展，从而缩短整体交付周期

　　２、测试可以尽早测试已经完成的功能，做到风险前移

　　３、自动化覆盖完毕后，可以节省后面重复测试的工作量

　　４、可以更好的应对需求变更，做到从容不迫

　　５、可以在迭代燃尽图上展示真实的进度

　　６、开发必须进行不断得重构，从而提升架构的稳定性并提升个人技能

　　７、避免了过度计划

拆分Story的坏处

　　１、开发需要细分场景，会造成重复的工作量

　　２、整体的开发计划看起来比较长

一个Story的好处

　　ａ、简单直接，没有重复开发工作，符合瀑布思维习惯

　　ｂ、任务总体完成时间看起来短（未考虑并行与变更）

一个Story的坏处

　　ａ、过度拆分，浪费计划时间

　　ｂ、任务串行拖长了交付周期

　　ｃ、风险后置（测试在开发全部完成后才能开始）

　　ｄ、无法及时响应需求变化（重复测试、延后交付）

　　ｅ、无法体现真实进度（可工作的软件）