开发团队的效率

luoyjx · 2015-07-25 10:13 · 1768次阅读

几个非常典型的开发方式

  • 软件开发中的“锁”
  • 接力棒式软件开发
  • 保姆式软件开发
  • WatchDog软件开发
  • 故障驱动式软件开发

软件开发中的“锁”

  • 技术能力上的锁。有一个项目需要在不同的地方做开发,这些模块用到不同的技术,比如:Java, C/C++, Python,Javascript,但是,这个团队里的每一个开发人员就只懂一门语言,于是,需要配合,需要任务排期,同步互斥锁就很多,于是,一个本来只需要2个人干3周的的工作变成了8个人干两个月。
  • 负责模块上的锁。同理,不同的人负责不同的模块,于是一个项目要动好多模块,那么你就需要把这些模块的人找过来,和上面一样。每个人都有自己的时间安排,人越多,锁越多。于是,一个来来只需要2个人干2两周的事,变成了7、8个人干一个多月。

我上面并非瞎扯,这都是事实。我们可以看到,

  • 时间锁、进度锁。这堆有不同技能或是负责不同模块的开发人员有锁,有锁你就要等,他们有自己的安排,所以,要协作起来,你就需要排期,去同步。而参与的人越多,你的锁就越多。你协调他们的时间就更复杂。
  • 沟通锁、利益锁。而且,最恐怖的事情是,他们之间的沟通成本巨大。他们会花大量的时间在讨论,一个功能是实现在你那边,还是我这边,每个人都有自己的利益和算盘。无形中增加了很多推诿、官僚和政治上的东西。

解决方案

一个程序员应该能够掌握多个语言,也能够负责多个模块甚至不同的职责。如果一个程序员觉得多学习一门语言,多掌握一个模块是件很困难的事,那么这个程序员本质上是不合格的。

“接力棒式”软件开发

在有各种“工作锁”的软件开发团队里,一般都无法避免“接力棒式”的开发。也就是说,底层的C程序员干完了,交给上层的Java程序员,然后再交给更上层的前端程序员,最后再交给运维人员。这就是接力棒式的开发。

解决方案

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

“保姆式”软件开发

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

“保姆式”开发一般会进化成“保安式”开发。

  • 因为你的团队开发人员的能力不行,设计不行,Code Reivew/UT不做,你就只能找堆QA看着他。
  • 因为Dev/QA只管功能不管运维,所以,还得找堆运维人员看着他们。
  • 因为你的技术人员不懂业务,不懂需求,需要再找个BA,找个产品经理来指挥他。
  • 因为你的技术人员不会管理项目,所以,再搞个项目经理,找个敏捷教练、以及SQA来管着他。

解决方案

  1. 不要招只会写代码的“码农”,要招懂“需求”,注重“软件工程”和“软件质量”和“软件维护”的“工程师”。
  2. 最好的管理,不是找人来管人,而是自己管自己。
  3. 组织和团队中支持性工作的人越少越好,最好不要。
  4. 服务化。我服务于你并不代表我要帮你干活,而是代表——我要让你干活干得更爽。

陈浩微博上的话: 运维要用“云服务”的思路去做。如果一个公司内的运维团队开发出一堆工具,让做应用开发团队可以很容易地申请机器、存储、网络、中间件、安全等资源,并很容易管理、监控和部署应用,并提供运维资询。而不是帮应用开发团队干活擦屁股当保姆。那么,这个公司就会不经意地做出一个云计算平台来了。

“WatchDog式”软件开发

什么是WatchDog?就是说——为了解决某个系统的问题,我要用一个新的系统去看着它。

  • 我的系统架构太复杂,出了问题不好查找。咋办?那就搞个专门的特殊的监控系统吧……
  • 我的系统配置太复杂,容易配错了。咋办?那就加一个配置校验系统吧……
  • 我的系统配置和真实的情况有时候可能会不一性。咋办?那就加一个巡检系统吧……
  • 我的系统测试环境和线上环境有时候会搞混了。咋办?那就为线上环境加一个权限控制系统吧……
  • 我的系统有单点,那就加个负载均衡器吧,负载均衡器的单点呢?那就再加个等价路由器吧……

解决方案

  1. 设计想好了再做,多评估几个设计没坏处,简化,简化,简化。
  2. 残酷无情地还债,就算是CEO来了,也无法阻止我还债的脚步。

“故障驱动式”软件开发

WatchDog式的软件开发通常来说都是“故障驱动式”软件开发的产物。这种开发方式其实就是在表明自己智力和能力的不足。以上线为目的,上了线再说,有什么问题出了再改。

解决方案

  1. 基础知识和理论知识非常重要。多多使用已有的成熟的方案是关键。
  2. 对技术要有一颗严谨和敬畏的心。想清楚了再干,坚持高标准,Design for failure! 很多事情都急不得。

其它开发方式

  1. 配置管理上的问题。对于源代码的配置管理,其实并不是一件简单的事情。配置管理和软件和团队的组构的结构非常有关系。我看到过两种非常没有效率的配置管理,一种是以开项目分支的方式来做项目,同时开很多分支,分支开的时间还很长,导致merge回主干要花大量的时间去解决各种冲突,另一种是N多的团队都在一个代码库中做修改,导致出现很多复杂的问题,比如某团队的改动出现了一个bug,要么所有的团队的功能都得等这个bug被修复才能被发布,要么就是把所有的改动回滚到上一个版本,包括其它团队开发的功能。很明显,软件模块的结构,软件的架构,以及团队的组织形式都会严重影响开发效率。
  2. 人肉式的软件开发。大多数的软件团队和主管都会用“人手不够”做为自己开发效率不够的借口,而大多数故障发生的时候,都会使用更重的“人肉流程”来弥补自己能力的不足。他们从来没有想过使用“技术”,使用更“聪明”的方式来解决问题。
  3. 会议驱动式开发。人多了,团队多了,想法也就多了,沟通也就多了,于是需要不停得开会开会开会。

总结

  1. 软件工程师分工分得越细这个团队就越没效率,团队间的服务化是关键的关键。不管是从语言上还是从软件模块上的人员分工,越细越糟糕。服务化不是我要帮你做事,而是我让你做起事来更容易。
  2. 你总需要在一个环节上认真,这个环节越往前就越有效率,越往后你就越没效率。要么你设计和编码认真点,不然,你就得在测试上认真点。要是你设计、编码、测试都不认真,那你就得在运维上认真,就得在处理故障上认真。你总需要在一个地方认真。另外一篇文章你可以看一下——《多些时间少写些代码》
  3. “小而精的团队”+“条件和资源受限”是效率的根本。只有团队小,内耗才会小,只有条件或资源受限,才会逼着你去用最经济的手段做最有价值的事,才会逼着你喜欢简单和简化。
  4. 技术债是不能欠的,要残酷无情地还债。很多事情,一开始不会有,那么就永远不会有。一旦一个事情烂了,后面只能跟着一起烂,烂得越多,就越没有人敢去还债。
  5. 软件架构上要松耦合,团队组织上要紧耦合
  6. 工程师文化是关键,重视过程就是重视结果。只重视结果的KPI等同于“竭泽而渔”和“饮鸩止渴”。

本文是从以下出处摘出来的。

本文来自陈浩的《开发团队的效率》酷壳

收藏

暂无评论

登录后可以进行评论。没有账号?马上注册