构建之法阅读笔记04-第五章

阅读笔记

第五章：团队和流程

团队有一些共同的特点：有一致的集体目标，成员之间有各自的分工，合作完成任务。团队一开始可能是"一窝蜂模式"，都想写出好的软件，但是没有各自的分工，一般不会这种模式不会存活太久。慢慢会演化成其他模式，比如"主治医师模式"，本来是不错的模式，但是在学生身上退化为了一个学生干活，其余打酱油的情况。还有比如明星模式，社区模式，业余剧团模式等，当然其中不乏一些好的模式，秘密团队，交响乐团模式，功能团队模式等。

学校里面的软件工程专业的学生可能是"写了再改模式"，因为作业是这么要求，但是这种开发方法的缺点特别大。

软件行业一开始也会使用"瀑布模型"，即分析-设计-实现-销售-维护的模式，但是对于软件工程来说，需要做很多次的回溯。但是慢慢发现回溯很困难等等的其他问题，需要在生产出产品之后才能知道产品的实用性，这是很头疼的问题。

后来根据"瀑布模型"提出了生鱼片模型，但是问题是：不知道上一个阶段什么时候结束。后来引入了子瀑布模型，但是难度相当大，用户只有到了最后才能看到结果，也不实用。

后来提出了Rational统一流程，即后面的统一建模，用精确的语言把用户的活动描述出来。流程为：业务建模，需求，分析和设计，实现，测试，部署，配置和变更管理，项目管理和环境。RUP分为四个阶段：初始，细化，构造，交付。

有一种流程为老板驱动的流程，这种流程有好处也有坏处。好处是老板比一般技术人员懂的市场和竞争；坏处是领导毕竟对于软件开发是外行，并且不一定能管理好软件团队。

还有渐进交付的流程，重复开发-发布-听取反馈-根据反馈做改进这个过程，直到完成迭代次数，或者客户满意。

 

过去的看法：

开发一个软件，只要能做出来就行了，过程什么的都是无所谓的。

这样为什么不好：

如果只是一窝蜂的去写代码，而没有一个好的分工，或者流程的话，可能一开始还行，但是慢慢的问题会越来越凸显，导致整个工程无法完成。

解决办法：

在进行开发之前，首先需要明确分工，确定每个人需要完成的工作，进而确定好开发流程，然后每个人完成需要做的事情，最后进行系统整合，并且需要重复开发-发布-听取反馈-根据反馈做改进这个过程，最终交付一个软件产品。