从去年开始参与公司的敏捷中心，到今年参与到部门的敏捷教练团队，跟了好几个”敏捷团队“的交付过程，最大感受就是技术工作者非常不好忽悠。。。

作为技术工作者一员，也一直在思考如何给技术人员去讲解敏捷的价值观给交付过程实际带来的好处呢？ 别给我扯敏捷宣言，也别给我扯敏捷原则，来点实际的。

自认为对敏捷体会还不够深，估计得一直在学习的路上。毕业是不可能的了，这辈子都不可能毕业的，大道理又不会说，只能扯一些其他的来忽悠一下大家这样子。正面没的聊，咱们就只能从反面聊聊看。以下说说我认为的传统交付模式下的一些”反模式“。

模式一：各司其则

这本来是个褒义词，但是如果过度强调”各司其则“，往往就会演变成”各扫自家门前雪“了。交付团队区别于由各个交付成员自由组成的交付团体的主要原因就是团队会利用团队的优势，达成交付个体自由结合无法达成的效果。举个简单的例子，现在交付团队中一般都会有自动化测试的工作，因为涉及到”测试“，所以大多数交付团队会把这个工作完全交给测试人员来完成。但是自动化测试不同于普通的功能测试，需要依赖一些工具或者框架的支撑，而测试人员的优势往往是在业务而非代码，这个时候如果开发人员能够共同参与，结合测试人员的业务能力和开发人员的代码能力，相信这个工作一定能够达到事半功倍的效果。类似的还包括开发人员和运维人员之间存在的隔阂。

最直接影响：交付能力平庸

模式二：我们以前一直是这么做的，没感觉有什么不好的

对不起，你的感觉错了。遇到比较多的就是开发工作和测试工作的衔接问题，都没完全开发完，我怎么能测试呢？这里有必要和大家探讨一下”测试“的概念，私以为所有对最终交付物质量有提升的工作都可以归类为”测试“，对设计的评审，对文档的堪误，对代码的走查，都是”测试“的范围，所以为什么一定要等到把交付物完全封装好才能测试呢？是否可以先”测试“交付物的其中一部分呢？我们都知道，缺陷发现越晚，修复成本是越高的。为什么要限制在以前的做法里无法自拔呢？

最直接影响：交付能力停滞不前

模式三：我也不知道这个文档有什么用，但是感觉有必要写

对不起，你的感觉又错了。如果一个过程产物连交付团队都不理解有什么作用的话，还能指望客户买单吗？交付团队可能会说我们并不会要求客户为文档买单啊。但是你得明白，交付团队的主要职责并不是为了满足过程的一些标准，规范，最终目标都是为了让客户心甘情愿的买单，所以在交付过程中的任何工作，都可以理解为是需要客户买单的。所以，请你仔细回忆一下，你现在每个版本交付过程中写的那些文档，到底是起到什么作用？这里给出一些选项，有一类文档是为了指导当前工作的，比如我需要完全照着这个文档来进行后续的工作，还有一类文档是为了以后的工作做得更好的，比如我希望能够根据这个文档找出我之前做得不好的地方，从而在之后的工作中改进，你的文档属于这两类之一吗？

最直接影响：交付成本浪费

模式四：需求文档上没写的东西完全不知道怎么开发测试

随着时间的推移，目前这种现象已经越来越少了，但是仍然存在。软件交付与其他行业的交付不太一样，不确定性是必然存在的，而且文档存在一个最大的问题，承载的内容始终有限，永远无法把需求的方方面面都写进文档。所以测试工作的难点其实也体现在这里，如果给你一份非常完善的文档，细致到用户使用的各种场景，各种输入都考虑完全，测试设计工作完全没难度，那个时候测试的能力要求可能只是需要阅读能力过关即可了。这点对开发人员也适用。我们没办法奢望一份完善的需求文档，有一个愿意和你随时沟通的产品人员就已经非常不错了。

最直接影响：交付结果无法满足预期

模式五：邮件才是工作沟通的正规方式

提测邮件，第一轮测试完成邮件，缺陷修复完成邮件，测试通过邮件，甚至过程中的缺陷评定，例如某一个缺陷需要否决，也需要经过缺陷管理系统的一通操作才能完成。和之前模式三的文档一样，这些邮件通常只发一遍，后续完全不会回过头查看。所以，邮件这种方式真的好吗？如果测试过程中，测试人员直接坐开发人员旁边，是不是这些信息也能正常传递，并且在降低了沟通成本的同时，信息失真的可能性更低？

最直接影响：交付成本浪费

模式六：总结的改进措施永远无法验收

希望需求文档更明确一些，希望开发人员更仔细一些，希望测试人员测试更全面一些，类似这样一些期望在传统交付模式下的总结会上经常会听到。但是回头想想，你觉得这些改进措施做到了吗？估计很难评判。这都是因为这些期望都是定性的，缺乏定量指标，所以似乎随时回过头来看，这些措施貌似完成了，貌似又没完成，逐渐就都不care了。

最直接影响：改进无法落地

暂时吐槽这些，因为接触的项目不多，有失偏颇的地方请大家留言批评，否则看不到听不到我是不会改的。至于这些”反模式“在敏捷实践里有没有，就仁者见仁智者见智了。欢迎留言补充。