首页 > 代码库 > 构建之法第五章学习

构建之法第五章学习

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

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

然后我学习了瀑布模型 

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

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

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

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

1. 存在的原理

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

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

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

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

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

2. 存在的问题

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

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

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

领导的精力有限,领导很忙时,团队怎么办?

构建之法第五章学习