(第九周)读构建之法有感2

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了(第九周)读构建之法有感2相关的知识,希望对你有一定的参考价值。

 

第五章:团队与流程

第五章章节里面主要介绍了团队与非团队、软件团队模式以及开发流程以的各自的优缺点以及一些概念。对于现在的我们可能较为熟悉的开发流程是瀑布模型。对于团队模型我比较有兴趣了解的是功能团队模式。

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

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

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

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

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

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

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

以上是关于(第九周)读构建之法有感2的主要内容,如果未能解决你的问题,请参考以下文章

读构建之法有感

第九周读书笔记

读 《构建之法》有感

读《构建之法》第8910章有感

读《构建之法》有感

读《构建之法》有感