书接上回～～～ 故事点燃尽图有什么用
为了能够得到团队的真实进度，我们应该采用故事点燃尽图来跟踪真实的复合DOD标准的进度。但是敏捷团队在转型初期，采用故事点来跟踪进度的时候，往往会发现故事点很难在迭代的早期下降，如下图：
虽然很努力的按照标准的形式开展了几个会议，但是每次到了迭代执行的时候，总是不能让故事点早一点开始下降。
可以说衡量一个团队是否真正的采用了敏捷的方式在工作，一个非常重要的标志就是团队的故事点燃尽图可以在迭代早期就进行下降。如下图：
看到这样的燃尽线，说明团队确实了理解敏捷中最最核心的一个思想，为客户尽早交付有价值的可工作的软件。到这个时候，基本上团队就可以自我成长和持续改进了。
那么，到底做什么、怎么做才能在迭代早期就让故事点下降，并且在进行中能够持续下降呢？有很多的团队苦苦挣扎，到处探索，终是不得要领。以至于到最后心里默默的会说，敏捷就是个形式，没有什么用处。
～～～～～～～～～～～～～～～ 分割线 ～～～～～～～～～～～～～～～～～
今天给大家看一个例子，来看看如何让故事点早点下降。
“小马，最近在做什么功能呀？”，“哦，教练，我们最近在开发一个新功能，正好来看看我们拆好的故事，怎么样？比之前拆得细多了吧 :) ”
＂额～，这是拆好了？＂，“是的，看看我们这次拆得怎么样？”
“这是什么功能呀？看起来很神秘的样子”，“哦，给你看看我们的界面，它长这个样子。我们只要把上面的任务做完，下面这个界面就可以用了”。
“嗯，一个好的用户故事，应该是能够看出他为用户提供的什么样的功能。能给我解释解释这个界面和拆好的任务之间是什么关系吗？”，“好的，我来给你解释解释”。～～～～一顿解释～～～～。
“哦，我明白了。这是一个三维大楼的模型，要对里面的一个个房间进行装饰材料的布置，对吧”，“嗯，是的。是这个功能。不过由于房间里面有很多的墙呀／梁呀／柱子呀／板子呀还有踢脚线呀，所以得设置好它们的关系”
“原来是这样，那这个用户故事得改改，改成用户能看懂的描述，那么你的这个功能的用户是谁呀？”，“哦，是预算员，做工程预算的”。
“OK, 那比如说子任务里面有一个柱布置，那用预算员能听懂的话来描述这个功能，怎么说呢？”，“我想想，～～～，描述成这样？＂
作为预算员，我希望对当前房间内的柱子进行统一的墙面装修
“哦，这样。那做了这个功能对于预算员有什么用呢？”，“哦，是这样。原来预算员要对每一面墙、柱子什么的一个个的把装修材料布置上去，一栋楼里面其实有很多相同的户型，装修其实差不多的，这样预算员就的做好多的重复劳动，所以就提出了这个功能来帮助他们。”
“了解了，能用一句话描述下这个功能对预算员有什么价值吗？”，“我试试，应该说是减少重复劳动？”
“也可以，减少重复劳动反过来怎么描述呢？”，“那叫做加快完成速度？”，“～～，再想想”，“那要不就说提高工作效率？”，“也可以，不过有点太文绉绉的了。想想站在预算员的角度，对他个人有什么好处”，“嗯～～～，那就是他可以早点完成大楼的装修工作”，“差不多，那把这个价值加到用户故事的最后面吧。”
作为预算员，我希望对当前房间内的柱子进行统一的墙面装修，以便可以快速完成装修布置任务
“哦，我好像有点明白了，这就可以做为一个用户故事，有用户，有功能，还有价值，而且用户还能看懂”。
“是的，这就是敏捷里的神器，通过用户故事来描述功能，让用户／产品经理／研发同学都能弄懂是什么意思。研发同学围绕着用户故事来组织开发任务，这样才可以用一个语言描述同一个事情”，“哦，了解”。
“你再看看你上面最初拆解好的任务表，看出差别了吗？”，“～～～，～～～，～～～我们研发能看懂”。“再看看”，“嗯，站在预算员的角度肯定不好懂了”，“那产品经理呢？”，“他们需要我们给解释解释就对应上了”，“这就是差别！，多一次信息的转换就会损失一层含义。所以才要使用用户故事来对外沟通，对内管理好研发任务”。
“教练，我理解了这个含义了。不过用用户故事怎么能管理好开发任务呢？你看看这个界面，左边是不同的房间，中间是每个房间里面不同构件的分类（墙梁板柱），下面是这些房间和分类的具体属性，右下角还有一个各种构件是否需要统一布置的一个配置界面。刚才那么写故事好像不对呀”。“嗯～那你觉得怎么写才合适呢？”
“我觉的应该这样”
左边的房间定义一个故事，就叫做：房间和房间属性的管理
中间的构建定义一个故事，叫做：房间内构件和属性的管理
右边的构建的配置也定义一个故事，叫做：布置设置
“这样才能和研发的任务对应上！所以前面的那个故事应该拆成这三个才对”。
“原来你是这么想的呀，如果这样的话，比如说我们把你拆好的第一个故事房间和房间属性做完了，对于用户－预算员来说有什么价值吗？”，“当然有啦，预算员可以定义和管理房间了呀”。
“再想想，我们发掘出来的用户价值是？”，“是快速完成装修布置任务”。
“那么，可以管理房间这个功能对于预算员完成装饰布置有直接的价值吗？”，“直接价值？那还不行，只是完成了第一步。还要选构件，进行构建设置，然后才能一个个房间去布置装修材料”
“所以呀，这个只能算一个开发任务，而不能算用户故事，因为它对于最终用户没有产生价值，也没有办法拿去找真正的客户做验证，你总不好意思拿着一个半成品功能去验证吧。”，“那倒是，可以这么想的话，要对用户有价值，那我就得把所有的这些房间装修布置的功能全部做完才能算作一个用户故事了。这么大一个故事怎么可能在迭代前几天就完成呢？”
“嗯，你前面的想法是正确的，我们做功能要想着做完以后能够拿去给用户去演示，也就是代表着用户故事是要有用户价值的才算一个真正用户故事。在这个前提下，要想做到迭代内尽早交付，就需要想各种办法对这个故事进行拆分”
“哦，那其实前面我们已经拆分过了，把房间里面的构件拆出来变成一个个故事，比如可以把柱子的装修和踢脚的装修功能单独定义”
作为预算员, 我希望将当前房间内所有的柱统一进行墙面装修, 以便提高房间内所有柱的墙面装修布置效率
作为预算员, 我希望将当前房间内所有的柱统一进行踢脚装修, 以便提高房间内所有柱的踢脚装修布置效率
“不错，是这个套路”，“那教练，还有一个配置的界面是不是要单独写一个故事呢？像下面这样”
“这还是要回到业务，预算员在对房间内的各个构件到底怎么布置都需要在这个界面进行配置，但是单独配置完对于用户来说，算是完成了装修布置任务了吗？”，“那不算，可这块功能背后的规则也很复杂呀，不算故事的话，放到哪个故事里也太大了呀？”
“我们还是要想办法在保证用户故事对于预算员有价值的前提下，进行拆解。来看看上面这配置界面里面包含了各种构件类型，我们能不能把它们一一拆解出来，合并到其他故事里面去。比如，界面里面有关于柱的配置（第六行／第七行），我们把它单独拆出来放入到下面这个故事里面去”
作为预算员, 我希望将当前房间内所有的柱统一进行墙面装修, 以便提高房间内所有柱的墙面装修布置效率
－柱构件窗口功能（构件的增删改查）
－柱构件属性功能（属性的调整）
－配置窗口里面柱的配置（其他配置先不显示或灰掉）
“怎么样，这样一个用户故事就和他的几个开发任务紧密关联起来了”，“这样做也可以，但是对于研发来说，我们之前都是一块块开发的，这样不符合开发习惯。”
“那么这样做可以行的通吗？”
“可以是可以，但是就是感觉有重复工作量，本来一个窗口，开发完就完了，这么拆的话，要来来回回的在这里改代码，还有重复测试，感觉浪费了呀？”
“～～～你再想想，这样做真的是浪费了吗？～～～”
要开会了～，欲知后事如何，且听再下回分解。