西行漫记(11):数字化敏捷
来源:互联网 发布:烂电影知乎 编辑:程序博客网 时间:2024/04/28 10:10
今天做案例分析,分组讨论。一个问题是说,有个大项目第三期工程,时间大概是20个月。由于第二期狂赶进度,拉下很多技术债:糟糕的设计,重复代码,等等。现在要考虑,第三期要不要重新做架构,还是在第二期的基础上接着往上堆。
这种类似的问题在国内的论坛就已经讨论过很多次。主张继续堆的说,时间紧任务重,抓紧完成功能交货收钱是要紧;主张重新架构的说,勿在浮沙筑高台,深挖洞才好广积粮,更何况架构改好了代码重构了,开发效率也会提高,消耗的时间也能赶回来。双方都有理,谁也说服不了谁,架都是这么吵起来的。
今天的讨论,我们得到了一个数学模型。设第三期时间总长T,重新架构需要时间t,重新架构之前开发平均速率V1,重新架构之后平均速率V2。在最坏的情况下,重新架构会要求整个团队停下来等待,于是有:
T / (T-t) < V2 / V1
通俗的解释是,如果速率的提升能把耗费的时间找补回来,那么就值得重新架构。这个道理每个人都明白,但有了这个方程之后我们就可以代入变量去计算。现在已经知道T=20个月,那么如果我们花两个月重新架构,代入计算就是:
20 / (20-2) < V2 / V1
=> V2 / V1 > 10 / 9
也就是说,如果两个月的重新架构能换来超过11%的速率提升,就值得去做。11%的速率提升是什么概念呢?就是每天少用50分钟来奋战、调试、改bug等等。这个提升看起来比较合理,不过还是觉得有些偏高,那么一个月的重新架构换来每天30分钟的提升,我觉得就是比较合理的。同学问我,你怎么就知道这个合理呢?我没有证据,凭感觉猜的。但区别在于,我不是在猜20个月会怎么样,而是在猜1天能不能节约半小时,相比之下这个难度低得多了。
所以,我觉得自己学到两点。第一,像“重新架构”这种事情并不是非黑即白的,整条坐标轴上的任意一点都是可能的选项。第二,直觉很重要,但量化统计和计算可以缩小直觉的责任范围,让直觉更准确。敏捷方法之所以强调快速迭代和反馈,也是为了让客观数据多一些再多一些,让直觉判断准确一些再准确一些。
- 西行漫记(11):数字化敏捷
- 西行漫记(11):数字化敏捷
- 西行漫记(3):敏捷的奥秘
- 西行漫记(1):班加罗尔印象
- 西行漫记(4):周末
- 西行漫记(6):Diversity
- 西行漫记(10):加利福尼亚男孩
- 西行漫记(13):Show Time
- 西行漫记(14):慌神了
- 西行漫记(15):重构到模式
- 西行漫记(17):Holi-Day
- 西行漫记(19):毕业了
- 西行漫记(13):Show Time
- 西行漫记(17):Holi-Day
- 西行漫记(15):重构到模式
- 西行漫记(15):重构到模式
- 西行漫记(15):重构到模式
- 西行漫记(14):慌神了
- sqlserver 2000h 和 jdbc 的融合问题
- 假如战争如此美丽(组图)
- 软考的悲哀
- [开发总结]系统架构及数据模型----OpenGL模式显示及临时显示篇(二)
- web.config
- 西行漫记(11):数字化敏捷
- intel的新处理器,我喜欢!
- eclipse GUI 项目: visual editor 安装 (用Eclipse进行可视化Java界面设计)
- [开发总结]Cad系统架构及数据模型----OLE容器及嵌入篇(三)
- 文件夹无法删除
- [开发总结]Cad系统架构及数据模型----上线和导航篇(四)
- [开发总结]系统架构及数据模型----AutoDesk文件格式转换篇(五)
- [开发总结]Cad系统架构及数据模型----厦华电器项目二次开发篇(六)
- [开发总结]Cad系统架构及数据模型----哈空调项目二次开发篇(七)