|
2)残酷无情地还债，就算是CEO来了，也无法阻止我还债的脚步。项目管理者联盟
“故障驱动式”软件开发项目管理者联盟
WatchDog式的软件开发通常来说都是“故障驱动式”软件开发的产物。这种开发方式其实就是在表明自己智力和能力的不足。以上线为目的，上了线再说，有什么问题出了再改。项目管理者联盟
上面的老大或是业务方基本上会说，没关系，我们不一开始并不需要一个完美的系统，你先上了再说，先解业务的渴，我们后面有时间再重构再完善。而有的技术人员也会用“架构和设计是逐步演化出来的”这句话来证明“故障驱动”开发是值得的。项目管理者联盟
我同意逐步迭代以及架构演化论，但是，我觉得“系统迭代说”和“架构演化论”被彻彻底底地成为那些能力有限甚至不学无术的人的超级借口。项目管理者联盟
你们有没有搞错啊?你们知道什么叫迭代，什么叫演化吗?你们知道，要定位一个线上的故障需要花多大的力气吗?(看看这篇文章你就知道了)你们知道，随随便便去应付局部上你会快，但总体上来说你会慢。talent.mypm.net
虽然，我看到那些系统在一个又一个的故障后得到一点又一点的改善，但是我想说，为什么一开始不认真不严谨一点呢?我从来就没有见过一个精良的系统是靠一个一个的故障和失败案例给堆出来的，就算是Windows 95/98这样史上最烂的操作系统，如果没有设计精良Windows NT的补位，Windows也早玩完了(看看IE的下场就知道了)。项目管理者联盟
【解决方案】项目管理者联盟
1)基础知识和理论知识非常重要。多多使用已有的成熟的方案是关键。项目管理者联盟
2)对技术要有一颗严谨和敬畏的心。想清楚了再干，坚持高标准，Design for failure! 很多事情都急不得。项目管理者联盟
其它开发方式项目管理者联盟
其实，这样的事情还有很多。比如：bbs.mypm.net
1)配置管理上的问题项目管理者联盟
对于源代码的配置管理，其实并不是一件简单的事情。配置管理和软件和团队的组构的结构非常有关系。我看到过两种非常没有效率的配置管理，一种是以开项目分支的方式来做项目，同时开很多分支，分支开的时间还很长，导致merge回主干要花大量的时间去解决各种冲突，另一种是N多的团队都在一个代码库中做修改，导致出现很多复杂的问题，比如某团队的改动出现了一个bug，要么所有的团队的功能都得等这个bug被修复才能被发布，要么就是把所有的改动回滚到上一个版本，包括其它团队开发的功能。很明显，软件模块的结构，软件的架构，以及团队的组织形式都会严重影响开发效率。项目经理博客
2)人肉式的软件开发pmp.mypm.net
大多数的软件团队和主管都会用“人手不够”做为自己开发效率不够的借口，而大多数故障发生的时候，都会使用更重的“人肉流程”来弥补自己能力的不足。他们从来没有想过使用“技术”，使用更“聪明”的方式来解决问题。项目管理者联盟
3)会议驱动式开发training.mypm.net
人多了，团队多了，想法也就多了，沟通也就多了，于是需要不停得开会开会开会。项目管理者联盟
总结一下项目管理者联盟文章
综上所述，我有如下总结：项目管理者联盟
1)软件工程师分工分得越细这个团队就越没效率，团队间的服务化是关键的关键。不管是从语言上还是从软件模块上的人员分工，越细越糟糕。服务化不是我要帮你做事，而是我让你做起事来更容易。项目管理者联盟
2)你总需要在一个环节上认真，这个环节越往前就越有效率，越往后你就越没效率。要么你设计和编码认真点，不然，你就得在测试上认真点。要是你设计、编码、测试都不认真，那你就得在运维上认真，就得在处理故障上认真。你总需要在一个地方认真。另外一篇文章你可以看一下——《多些时间少写些代码》项目管理者联盟
3)“小而精的团队”+“条件和资源受限”是效率的根本。只有团队小，内耗才会小，只有条件或资源受限，才会逼着你去用最经济的手段做最有价值的事，才会逼着你喜欢简单和简化。项目管理者联盟
4)技术债是不能欠的，要残酷无情地还债。很多事情，一开始不会有，那么就永远不会有。一旦一个事情烂了，后面只能跟着一起烂，烂得越多，就越没有人敢去还债。项目管理者联盟
5)软件架构上要松耦合，团队组织上要紧耦合。项目管理者联盟
|
