之后继续阅读了人月神话。
基于上一章的结论:更大的队伍不一定能带来更快的开发进度,那么,问题来了,什么样的队伍才是合适的呢,小团队固然高效,但是你不能指望一个 20 人的小团队在合理的时间内去开发一套完整的操作系统吧?作者在这一章里给出了解决方案:将大项目合理地划分成更小的系统,各个外科手术队伍分别开发这些更小的系统。当然外科手术队伍只是一个小团队的方案,具体细节我认为已经不再具有很大的参考价值,但是精干的小型队伍这一理念仍然很有价值。
这里我联想到大企业病的问题,企业规模的扩大必然会导致人浮于事、效率低下的问题,于是如今一些大企业都会将企业的业务分割给各个小团队来负责。
短小精干的队伍带来了新的问题,如何对大项目进行合理的分割?这依赖于一个很重要的前提:概念的完整性,具体而言是指在项目的开发过程中,应该有一个一以贯之的明确的目标和清晰界定的范围,否则随着人员的变动和时间的变迁,这个项目可能会逐渐演变成四不像(我最近在参与的一个项目就是如此,人员的变动导致了项目功能、技术栈的变迁,项目的周期被极大地拉长)。而如何产生概念的完整性呢?答案是贵族专制,少数人决定一个概念并厘清边界,然后据此分割执行,否则人多嘴杂,必然会导致项目在讨论中变成奇怪的样子。
之后是画蛇添足,这一章主要是告诫系统设计师们,不要过度设计,尤其是在第二个系统(第一个系统完成后开发的第二个系统)中,不要过度自信,保持警觉,避免初始的概念和目标得到充分的体现,而不让一些次要的功能喧宾夺主。
这本书已经40多年了,很难想象一本计算机领域的书能够畅销这么久。但是读完之后我发现畅销是有道理的,虽然书里很多概念、例子、技术都属于上古时期的遗迹了,但是书里介绍的软件开发的困难、管理的思路,仍然可以在今天的软件开发中找到对应的场景。
标签:读后感,神话,项目,系统,概念,队伍,团队 From: https://www.cnblogs.com/jm56/p/17384023.html