-- 阅读《人月神话》的小小感想
《Agile project management with scrum》
几年前，我还在大学，大二学习数据结构这门课程时候，任课老师推荐同学们去看看《人月神话》，尝试感悟学习其中的软件工程学的一些东西。记得当时我粗读一遍，浑浑噩噩般感觉到一些东西了，但算不上感悟。毕竟当时从未有过真实的工程项目开发经验，真的比较难感悟到那些项目管理那些东西，勉强只能算达到理解的感觉吧。
……
而之后好多年，至今参加工作快两年时间了（从开始实习算起），对于这些东西慢慢的有颇多的感悟了。只要日后还继续从事软件开发，估计这种类似的感悟会更多。
……
恰巧，前几天在网上“不小心”看到一篇文章，记载着一位博友亦是粗读《人月神话》的感觉，正如我当时感觉，哈哈，可惜我以前喜欢用手写笔记，若那时候我也喜欢在网上写博客记录自己的学习笔记，那么今天我一定可以翻出来（可惜木有）……而不必我今天再次燃起冲动整理这篇笔记（博客）。
没事儿，那就重新花点时间，归结几点吧，见下：
1.
一条Brooks提出的诡异定律：给推迟的软件项目增加人手将使得项目更加推迟。但是根据其书中描述的不无道理，很有道理。
如何将一份繁多复杂的工作分配给许多人，相关的培训和程序员之间的交流都需要额外的工作。而这些（工作量）代价很多时候比你想象还要巨大。
（个人认为，该点可排除有个别情况--增加人手即真的加快项目进度，尤其小型团队于中型项目。）
2.
在从事系统设计时候，需明确关键的一点是，也是最重要的，概念的完整性。
概念已统一的系统更容易建造和测试，很大程度缩减了培训与交流的代价。要保证概念上的完整性，其概念的设计应该由一个人或者观念一致的小规模小组完成，需要具有足够权威性和统一设计能力。
3.
巴别塔项目失败的原因是缺乏组织和交流。良好的组织与高效的交流是相辅相成的。
良好的组织促进交流的高效，而高效的交流影响下一次良好的组织。
4.
若想要尽量保证项目的进度不被大幅度地推迟，制订进度表很重要。
进度表由里程碑和完成的时间组成，里程碑必须具体、明确、可界定，不允许存在模糊概念如差不多，50%（不好判断百分比情况），基本完成等。
引用链接在这里。
附图：
没有评论:
发表评论