从优先级排序看敏捷开发的自相似性

       作者：陈勇

       出处：blog.youkuaiyun.com/cheny_com

      

自相似性是指一个事物的局部与其更大的局部乃至整体具有相似性。

从大的方面看，敏捷开发具有重视客户价值，提倡持续交付等思想。但一般而言，Product Owner常常具备相当好的客户价值意识，而一线开发人员则比较关注技术本身，所以一旦仅仅停留在思想层面，在实际工作的时候就会发现有所背离。因此应该从自相似性的眼光看待敏捷开发的整体思想与局部实践，从而做到年年月月日日事事均符合敏捷开发的思想。

本文只从“优先级排序”这一个敏捷开发思想来分析敏捷开发的自相似性。

“优先级排序？是不是就是Product Owner在开计划会前要做的事情？”是，也不是。

 

对Product Backlog的排序

这次排序的目的，是弄清楚哪些需求最重要因此可能在最近的一两次迭代中进行开发。参与排序的条目一般足够接近半年的开发工作量，但多数只有一个简短的名称，只有最高优先级的需求才会被真正细化，也就是近一两次迭代要开发的需求列表。这个需求列表其实有一个专门的名称：Willing List，“意向表”。

为什么要用意向表做缓冲，而不是直接形成下个冲刺的Sprint Backlog？因为在计划会之前估算都很粗略，其实没办法准确列出下个冲刺工作量的条目；而且Product Owner应该细化或至少是深入了解超过一个冲刺的开发项，才能使这个冲刺的开发具备一定的前瞻性。

对Willing List的排序

这个过程是在计划会上进行的，也可以说是按“优先级”从中挑选出本次冲刺要开发的条目的过程，也就是常说的Sprint Backlog。要完成这个选择其实不太容易，因为如果只是盯着“重要程度”这个排序依据，极有可能从很多功能模块中各自挑出最重要的需求，而这些需求凑在一起，只能形成一个四不像的版本。因此常常可以挑选最重要的功能模块中的多个条目，形成整体完整的一个“故事群”，这样无论开发、测试和演示环节，都有一个相对内聚的目标。

为了防止大家中途跑偏，常常给每个冲刺要都起一个简短的名称，比如：“本次迭代将发布一个具有电子节目单的版本。”

对Sprint Backlog的排序

Sprint Backlog也要排序？是的。有没有遇到某个重要的条目每次都被漏下完不成的情况？有没有遇到冲刺结束的时候发现一大堆条目都已经开工了但都没有完成的情况？有没有遇到Product Owner想用一个重要的变更来替代原来Sprint Backlog中的某些条目却发现这些条目都已经“开发中”了？有没有遇到团队争议每次都应该完成所有条目（这真的很难）还是只需要完成最重要的一些？这都是因为没有对Sprint Backlog排序的结果。

一般在迭代计划会上使用MoSCoW方法进行这种排序，Must：必须做的；Shoud：应该做的；Could：可以做的；Would not：不要做的。要按照这些顺序来做，保证Product Owner所需要的Must、Should完成，并力争Could能完成；在发生重要变更的时候，牺牲Could乃至Should保证变更。

对Story Wall的排序

任务都上故事墙了还要排序？是的。故事墙一般按照待开发、开发中、待测试、测试中、完成几列，但很容易出现越来越多故事进入了开发中、测试中，却很少进入完成。这是因为MoSCoW方法做虚了，没有真正执行好。故事板的一个重要功能就是监控“开发中的故事的数量”（这个笔者也是在一年前左右才刚听到），因此一般“开发中”这一列是最窄的，只能放下为数不多的条目，目的就是为了防止上一段开头提出的各种问题。

而且“待开发”这一列中的故事，一般也按M、S、C（W其实不会出现）三个级别排放，优先拿M，最后动C。如果愿意，可以用三种颜色的便签纸来表示。

对Version的排序

还有？是的，其实最开始漏掉了最大一个级别的排序：如果产品开发生命周期很长，每个版本应该顺序包含哪些内容呢？最好的答案是：按照商业步调计划版本内容，也就是每个版本出来后，都要满足某些需求、获取某些客户、打败某些对手、取代某些产品……

如果产品能迅速获取良好的市场反馈回笼资金，高层领导一般都会马上向项目投钱投人；反正他们会在推进和放弃项目之间纠结。很多项目经理热切期盼领导重视和投入自己的项目，却不知道其实命运其实就掌握在自己手中！

 

本文所提内容的相关细节，可在博主博客分类“敏捷开发”下找到。

 

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》