1
“敏捷是靠人的，短期之内人是不能快速成长的。”
“预算是固定的，没有办法协调更优质的资源。”
这种观点并不鲜见。
不过出发点是以限制为界限，限制了思考。因此能够得到的解决方案也就有限。
套用一个流行的句式，这种问题就是团队的才华无法支撑ScrumMaster的梦想了。那么ScrumMaster的梦想是什么？团队的才华为什么无法支撑这些梦想的时候，又该如何做呢？
首先，我们来看敏捷宣言。ScrumMaster的梦想不管其表现形式，万变不离其宗的还是这几句敏捷宣言。
而团队如果无法满足上面的要求，其表现形式往往是：
●估算需要的时间比预期要长
●变更发生的时候表现抵触
●和客户的沟通不够及时有效
●问题发现的时机比较靠后
●质量问题层出不穷
●进度比预期慢了
●需求理解不到位
等等，不一而足。
那么是否这些问题真的是无法短期之内奏效的呢？有没有能够立竿见影的方法来解决这些问题呢？
如果目光集中在这些问题上，似乎得出的结论就是团队不够优秀，所以，无法满足ScrumMaster的期望，而短期之内通过培训、辅导是无法达到迅速提升的。毕竟编程功底这事儿是个日积月累的过程。但是如果能够跳出这个框框限制，那么就可以发现一片新的天地，豁然开朗。
就我的经验来看，下面几个问题可能是常见的因为上述问题的原因，而且是无需通过大量培训、辅导或者训练就能够奏效的。这些也是经过实践检验的。
2缺少并行作业
【现状】
开发必须要等需求说明到很详细的程度才能够开始，否则未来发生变更的可能性非常大，而团队比较抵触。
因此，需求和开发之间采用的是瀑布式作业，仍然是上下游关系，缺少并行作业机制。
需求描述如果是用户故事，对于开发来说，这是一个open命题，无法接受。开发需要就此用户故事的的明确的界面设计，异常处理的描述才能够开始。也不能在只有少量用户故事的情况下就开始，需要整体图，才能理清各个模块以及各个实体之间的关系。这是一个重要的前提。
因此PO提出来的需求形式，最终仍然是呈现为Specification差不多的感觉的文档。
【问题分析】
开发需要的并不是一份完整的文档描述，而是更清晰的逻辑关系。最好是能够指导开发编码的文档形式。这个描述需要保证全面性、可映射性（可以转化为代码的能力）、以及便捷性（能够很容易的描述出来）。
【可行的方案】
决策矩阵
决策矩阵是一种用来帮助开发团队能够更好的梳理需求的各种条件组合的一个工具。它容易描画、覆盖全面、可以直接映射为代码。可以有效地加速从需求转化为代码的过程。
比如，有这样一个需求（我们不讨论其合理性）。
●作为公司的一员，我可以对其他同事的行为进行拍照，并且增加描述从而提起一个举报。
●作为一个被举报人，我可以申诉，证明自己的清白。
●作为一个被举报人，我可以接受举报。如果接受举报，则扣分，而举报人加分。
●作为一个被举报人的上司，如果员工申诉，我可以进行二次申诉，证明自己员工的无辜。
●作为一个被举报人的上司，如果员工申诉，我可以接受举报，如果接受举报，则扣分，而举报人加分。
●作为审理委员会，如果接到二次申诉，我们有权判断该举报是否被采纳。对于采纳的情形，举报者有奖励，被举报者有惩罚。对于被否定的情况，举报者有惩罚，被举报者不做惩罚，也没有奖励。
这里面有若干个角色，有若干个流程步骤。传统的方式是描述为流程图。让开发团队根据流程图开发，然而，流程图当中并没有细节，比如奖励多少分，扣掉多少分。而且对于判定条件，什么时候由什么人来进行什么操作也是需要详细的描述才能够进行的。这是因为流程图给开发工程师带来的信息就是这样的，引导了开发工程师的思考往这个方向走。
因此开发工程师编程的时候按照需求描述的方式书写代码，采用了大量的if-else来处理整个流程，代码复杂度也就自然上升了很多。
而决策矩阵则给开发工程师完全不同的信息。下图是就上述需求的决策矩阵。
上述矩阵，左侧为该业务中的所有状态，顶部为所有的操作按钮。中间的矩阵部分是，哪个按钮可以操作，哪个按钮不可以操作。具体的操作后的动作也在矩阵中进行了描述。绘制这样一个矩阵只要几分钟就可以了。而它覆盖了所有的情形，流程图的形式会有一个重要的遗漏，就是那些业务描述中“不可能发生的”情况。
在实际业务中，还有一种情况，就是并发操作。当一个人打开了他可以操作的数据之后，离开座位，这时候他的浏览器认为这个数据是当前的状态A。另外一个人在自己的电脑上也打开了同一条数据，然后进行了某个操作，这时候数据变成了状态B。然后第一个人回来之后接着操作，上述矩阵中的“-”部分就在这种情况下出现了。而如果采用流程图的描述形式，由于隐藏了这部分的信息。代码中的处理就会有遗漏，从而产生了bug，在测试阶段中暴露出来。这是常见的问题之一。
上述决策矩阵采用了过去式描述各种状态，这样读者也不会因此而产生歧义。
那么决策矩阵是如何和代码映射的呢？
简单的说：每个状态映射为一个类，每个按钮操作映射为类的一个方法。
比如上述的矩阵就可以作如下映射：
默认的处理都是不能操作，只有少数能够操作的部分才有对应的代码。剩下的都交给基类来处理就可以了。然后每个按钮配套一个is~Available方法，比如： isAppealAvailable，这样该按钮是否显示，点击之后是否能够处理，就由对应的类做出判断和处理。
由于上述例子中需要处理的部分很少，因此这段代码也就个把小时之内可以完成，而且它的可变更性、可扩展性、可读性以及代码质量本身都远高于基于流程图书写的if-else式的代码。
3拥抱变化能力不足
当上述代码写完之后，PO提出，按钮是否可以用是和角色挂钩的，不是每个角色都可以看到该按钮的。基于if-else风格的代码需要遍历所有的按钮，每个都要书写一遍条件，包括：按钮的显示部分，按钮的提交部分的处理。万一有个遗漏就是Bug。而且这种复杂业务，会很容易有遗漏。
而采用决策矩阵为依据的代码需要增加角色判定的时候，只要在每个is~Available方法中补充对应的条件即可。
4有太多的等待
正如前文所说，由于需求的描述方式的差异，采用流程图的描述需要等待很久才可以开始理解，理解透彻了才能够开始编码。而采用决策矩阵的形式，无需等待，可以立即编写，每个方法的长度都不超过10行，因此，也不存在理解上的障碍。
引入决策矩阵之后，仍然是原来的团队，没有做深度技能提升，团队的生产率却达到提升了，代码质量也得到了显著的改善，代码的维护成本也大幅度缩减了。
资深敏捷教练王洪亮的《高级代码训练营》，通过实战的方式，经过一个虚拟项目，帮助团队更好的梳理需求，加快交付，提高质量，还有更多的实用工具助力敏捷团队迅速成长。
