开发团队的汇海

　　而且，更糟糕的是，若是在引入了软件流程下，这种“接力棒的方式”真是会把你搞瓦解的。好比下游团队开发一个月，交给QA测试一个月，再交给运维分步上线一个月，然后，上游团队拿到下游开发的API后开发一个月，再交给自己的QA测试一个月，然后再交给自己的运维上线一个月，于是，半年就这样已往了。这是一个由一个一个小瀑布叠出来的一个大瀑布。

　　哦，你会说，这个好办啊，上下游不会先商定好接口么？然后做并行开发么？是的，这是其中的一个优化方式，可是需要很好的接口设计。可是，在现实历程中，你会发现（这时我并非信口开河，我说的都是事实），

若是这两个上下游团队在一起还好办，要是不在一起，那么，现实情形是，后面的团队会等到前面的团队提测了，才最先开发，本质上就是串行开发的。若是有更多的团队呢？好比：A团队 -> B团队 -> C团队 ->D团队呢。接口就变得很是地要害了。而在现实情形下，由于没有好的接口设计职员，以是，在开发历程经常性地修改接口，或者是由于接口欠好用也只得忍着。　　【解决方案】

　　我以前写过一篇叫《IoC/DIP实在是一种治理头脑》，对于这种接力棒的方式，应该反过来，若是营业应用团队是A团队，那B/C/D团队应该把自己的做成一个开发框架也好，服务化也好，让应用团队自己来接入。好比：前端做好一个前端开发框架，PE做好一个运维开发框架、种种工具，共享模块团队做好开发框架，让应用团队自己来接入，而不是帮他做。你会发现，在这么多团队各自P2P勾兑出来的很随意的接口的所带来的成本已经远凌驾一个统一尺度的协议。

　　“保姆式”软件开发

　　所谓“保姆式”软件开发就是——我只管用饭，不管做菜洗碗，就像——衣来伸手，饭来张口的“小天子”一样，身边有一堆太监或宫女，否则生涯不能自理。这种情形经常见于开发和测试，开发和运维间的关系。许多公司，测试和运维都成了开发的保姆。

　　我就能看到，许多开发快速写完代码后基本上都不怎么测试就交给QA去测试了，QA一测，我草，种种问题，而只会做黑盒的QA并不能马上就能确定是代码的问题照旧情况的问题，以是还要花大量时间清除不是情况问题，才给开发报BUG。许多问题，可能只需要做个Code Review，做个单测就可以发现了，硬要交给QA。运维也是一样的，开发出来的软件基础就没有思量什么运维的工具，由于有运维职员，以是我才不思量呢。

　　这和我们带孩子的原理是一样的，对于孩子来说，若是怙恃帮孩子做得越多，孩子就越以为理所应当，就越不会去做。

　　“保姆式”开发一样平常会进化成“保安式”开发。

由于你的团队开发职员的能力不行，设计不行，Code Reivew/UT不做，你就只能找堆QA看着他。由于Dev/QA只管功效不管运维，以是，还得找堆运维职员看着他们。由于你的手艺职员不懂营业，不懂需求，需要再找个BA，找个产物司理来指挥他。由于你的手艺职员不会治理项目，以是，再搞个项目司理，找个迅速教练、以及SQA来管着他。

　　就这样，你不行，我找人来看着你，看你的人不行，我再找人来看着看你的人……层层保姆，层层保安。于是，你就会发现，团队或部门里的职员越来越多，你整天都在开会，整天都在相互诠释，相互争吵，会扯淡的人越来越多。那另有个屁的效率。

　　网络上一个很是经典的图片，泉源不详，程序员在挖坑，其它人站在当监工

　　【解决方案】

　　1）不要招只会写代码的“码农”，要招懂“需求”，注重“软件工程”和“软件质量”和“软件维护”的“工程师”。

　　2）最好的治理，不是找人来管人，而是自己管自己。

　　3）组织和团队中支持性事情的人越少越好，最好不要。

　　4）服务化。我服务于你并不代表我要帮你干活，而是代表——我要让你干活干得更爽

 2/4   首页 上一页 1 2 3 4 下一页 尾页