构建之法第五章学习

今天我学习了《构建之法》第五章 团队和流程。首先我了解了写了再改模式（Code-and-Fix）

史蒂夫·迈克康奈尔（Steve McConnell）在这里提到了不少开发流程。第一个提到的开发流程。这个流程也有好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。但是，要写一个有实际用户、解决实际需求的软件，这个方法的缺点就太大了。

然后我学习了瀑布模型 

当软件行业还在年幼的时期，它从别的成熟行业（硬件设计，建筑工程）借用了不少经验和模型。在那些“硬”的行业中，产品大多遵循 [分析→设计→实现（制造）→销售→维护] 这个流程。由于在“硬”行业中产品一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。因此这个模型描述了单向的、不可逆的生产过程。

在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题：又如，温斯顿指出，要让产品成功，最好把这个模型走两遍，先有一个模拟版本（Simulation of FinalProduct），在此基础上收集反馈，改进各个步骤，并交付一个最终的版本。

然后我又了解了老板驱动的流程

开发流程事实上是由行政领导主导，或者由公司的老板驱动，我们姑且把它命名为老板驱动的流程（Boss-Driven Process）

1. 存在的原理

当软件订单的获得不是主要靠技术实力，而是靠个人关系，或者暗箱操作的时候，老板的能力决定了一个团队是否能获得订单，既然软件的具体功能并不重要（或者哪个团队做水平都差不多），那么老板说做什么就做什么

在大型企业内部，软件功能往往由行政体系来决定

有些老板比一般技术人员更懂市场和竞争

软件团队尚未成熟，不懂得如何独立地进行需求分析，不懂得如何对行政领导有技巧地说“不”，也不知道如何说服利益相关者（Stakeholder）同意并支持正确的项目方向

既然不能驱动团队成员，那只能靠外力来驱动了

2. 存在的问题

领导对许多技术细节是外行

领导未必懂得软件项目的管理，领导的权威影响了自由的交流和创造

领导最擅长的管理方式是行政命令，这未必能管好软件团队或任何需要创造力的团队

领导的精力有限，领导很忙时，团队怎么办？