开发团队的汇海

　　2）人肉式的软件开发

　　大多数的软件团队和主管都市用“人手不够”做为自己开发效率不够的捏词，而大多数故障发生的时间，都市使用更重的“人肉流程”来填补自己能力的不足。他们从来没有想过使用“手艺”，使用更“智慧”的方式来解决问题。

　　3）集会驱动式开发

　　人多了，团队多了，想法也就多了，相同也就多了，于是需要一直得开会开会开会。

　　综上所述，我有如下总结：

　　1）软件工程师分工分得越细这个团队就越没效率，团队间的服务化是要害的要害。不管是从语言上照旧从软件模块上的职员分工，越细越糟糕。服务化不是我要帮你做事，而是我让你做起事来更容易。

　　2）你总需要在一个环节上认真，这个环节越往前就越有用率，越往后你就越没效率。要么你设计和编码认真点，否则，你就得在测试上认真点。要是你设计、编码、测试都不认真，那你就得在运维上认真，就得在处置惩罚故障上认真。你总需要在一个地方认真。另外一篇文章你可以看一下——《多些时间少写些代码》

　　3）“小而精的团队”+“条件和资源受限”是效率的基础。只有团队小，内讧才会小，只有条件或资源受限，才会逼着你去用最经济的手段做最有价值的事，才会逼着你喜欢简朴和简化。

　　4）手艺债是不能欠的，要残酷无情地还债。许多事情，一最先不会有，那么就永远不会有。一旦一个事情烂了，后面只能随着一起烂，烂得越多，就越没有人敢去还债。

　　5）软件架构上要松耦合，团队组织上要紧耦合。

　　6）工程师文化是要害，重视历程就是重视效果。只重视效果的KPI等同于“竭泽而渔”和“饮鸩止渴”。

 4/4   首页 上一页 2 3 4