最近一段时间，整个团队的工作效率都不是很高。私下里也总结过一些原因，是个人能力不行吗？是团队总体能力不行吗？是团队协作不积极吗？是工作方式有问题吗？难道是整个团队都在偷懒吗？？！我想做出改变，但是发现要么无从下手，要么力不从心。我们都很努力的在工作，但是进度就像是老牛拉车一样缓慢。问题的根源到底在哪呢？前几天刚接触了《DevOps实践指南》这本书，里边恰巧有一小部分是分析工作中的恶性循环事件的，看了很有感触，于是就总结了以下几点感触：
1，开发目标不明确，分两方面讲
a，开发之前目标没有明确，现想现开发，导致开发不流畅，随时返工，一被打断得话，影响比较严重，需要重新整理思路。即使写了设计文档，设计文档中对于当时不明确的事，也是写的模棱两可，没有经过细致的评审就开干。
b，开发之前目标已经明确了，但中途被各种原因改变。导致返工，重新设计。再因为，改代码没有写代码有意思轻松。导致效率低下
2，为了赶工期，会以实现功能为主，忽视代码质量，导致遗留下技术债务
在人员、时间已经无法改变的情况下，质与量的衡量选择就变得异常的困难。
即使不赶工期，有多少人在开发功能时，会坚持保证代码质量？90%以上的人不会吧。所以更应该借助于代码代码质量扫描工具来协助我们(sonar link)。
对于一个需求的理解程度有多深？工期评估是否合理？工期的评估中是否留够了buffer？好多时候，是因为自己对工期的评估不准确，导致时间紧迫，赶工期，然后留下一堆技术债务。
然而你觉得留够了buffer，那只不过是你觉得。一个任务真正需要完成的时间是2个小时，我们可能会遇到不可预测的困难，所以我们留个足够的buffer，时间翻倍，我们评估4个小时可以完成。当你开始着手开发的时候，实际情况是这样的：客户突然的袭击，来帮我定位个生产问题。同事突然来袭：来请教一个问题。领导突然来袭：来，这有个临时任务比较紧急，需要处理一下。。。一切完毕之后，6个小时已经过去了，终于可以继续自己的任务开发了。。。
所以，buffer怎样才算留够了，还要视自己近期的工作状况来定。杂事比较多的人，就多留一点buffer，杂事比较少的，留个两倍buffer足够了。前提是，对自己的开发任务要理解清楚，要不然评估的不准，导致时间不够，再去赶工期，再留下技术债务，那这个债务到底应该谁来买单？
不管是哪方面原因导致的技术债务，最终都会是整个产品的技术债务。
我们总是承诺，一有时间，我们一定会处理这个烂摊子，但是这个时刻永远都不会到来
3， 技术债务还没有还完，此时又有了新的需求需要开发，再原有的技术债务上，又产生了新的技术债务
欠的债，迟早都要还的。技术债务越多，托的时间越长，最终还债的时候，利息也会越多。
老债没还完，又来新的开发需求了，赶紧放下手头的还债任务，去开发新需求。以上几点问题没解决的话，依旧会产生新的技术债务。
此时我们又承诺，一有时间就处理这次产生的所有问题
4，《DevOps实践指南》中指出，恶性循环三部曲，第一步是产生技术债务，第二步是，原有债务没还完，又产生新的债务。最后的第三步便是，再前两步的影响下，所有的事情和工作都变得更加的困难-------所有人都越来越忙，工作消耗的时间越来越多，沟通变得更加缓慢低效，工作积压的越来越多。由于技术债务越来越多（包括代码缺陷、包括文档缺失、包括基础设施缺陷等等），使我们的工作耦合的更加紧密，即使是很小的行动或者改动，都会导致较大的事故，都会造成较大的沟通成本和协调。
造成的后果就是，团队工作效率越来越低，沟通成本越来越高，工作质量持续恶化。车轮还能勉强维持着不散架，稀里哗啦的缓慢移动。我们团队的每个成员都需要付出成倍甚至成几倍的努力，才能维持一个正常的进度
我们在做DevOps，DevOps的思想中，对于日新月异的市场竞争，我们需要快速的做出响应。但是反过来思考，快速响应只是DevOps思想的其中一项，比起快速响应，稳定、可靠、安全也是很重要的几点。
最终用户，用的顺手，他才会认为你做的这个东西有价值。最终用户认为有价值，才是真的有价值。我说我什么都有，但是没有一样用着没毛病，那其实就是在说，我什么都没有。
其实写了这么多，还是在想着能有个机会，把遗留的技术债务偿还一下。我们就像是一个跳远运动员，一直在目不斜视的盯着前方，思考着怎么跳的更远，却不曾回头看一看，往后退几步，来个助跑，可能跳的更远。
