构建之法—— 读书笔记(3)

第五章

5.1非团队和团队

团队特点:1.有一致的集体目标,要一起完成这目标。

2.团队成员有各自的分工,互相依赖合作,共同完成任务。

非团队特点:各自行动,独立把任务完成,有人不辞而别,对其他人无实质影响。

5.2软件团队的模式

1.主治医生模式(IBM System360项目)

2.明星模式(“翔之队”)

3.社区模式(开发和维护Linux操作系统的社区)

4.业余剧团模式

5.秘密团队(苹果公司在1980年代在研发Macintosh之后的系统)

6.特工团队(Y2K)

7.交响乐团模式(微软公司的Office软件)

8.爵士乐模式

9.功能团队模式

10.官僚模式

在大学里,很多情况下都是1和4。1中很多情况下会演变成一人干活,其他人打酱油。

5.3开发流程

1.写了再改模式(学校的作业)

2.瀑布模型

3.瀑布模型的变形:生鱼片模型 大瀑布带着小瀑布

4.统一流程(RUP):

业务建模 需求 分析和设计 实现 测试 部署 配置和变更管理 项目管理 环境

RUP的四个阶段

1.初始阶段

2.细化模式

3.构造模式

4.交付阶段

5.老板驱动的流程

6.渐进交付的流程,MVP和MBP

MVP——Minimum Viable Product,最小可行产品,又称为Minimal Feature Set,最小功能集

MBP——Maximal Beautiful Product 最强最美产品

7.TSP的原则

1.使用妥善定义的流程,流程中的每一步都是可以重复的,可以衡量结果的。

2.团队中的各个成员对团队的目标,角色,产品都有统一的理解。

3.尽量使用成熟的技术和做法。

4.尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。

5.制定切合实际的计划和承诺,团队计划要由负责具体执行的角色来制定(而不是从上下级而来)。

6.增加团队的自我管理能力。

7.专注于提高质量,争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。

时间: 2025-01-06 00:48:12

构建之法—— 读书笔记(3)的相关文章

构建之法——读书笔记(8)

<构建之法>第十&十一章 主要讲述了在软件设计前期的需求分析问题上的方法和实践经验,分为"典型用户和场景"以及"软件设计与实现". 其中第十章大部分内容包含: 用户的分类(典型用户可以包括以下内容: 1. 名字(越自然越好) 2. 年龄(不同年龄和收入的用户有不同的需求) 3. 收入 4. 代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要 5. 使用这个软件的典型场景 6. 使用本软件/服务的

构建之法读书笔记之五

今天我学习了构建之法的第五章——典型用户与典型场景.我们都知道,软件开发最终都是服务于用户,所以用户主导着我们的开发方向.软件开发离不开用户,所以能够搞清楚用户隐藏的要求也是软件开发过程中的的一个重要的课题,这就涉及到了典型用户. 典型用户,顾名思义,能够代表大部分用户的用户.很多时候,不考虑典型用户的话,软件的开发不可能把所有的方面都做的尽善尽美,开发人员不可能把所有的方面都能考虑到.这时候,典型用户就站了出来.但同时,典型用户也有两面性——受欢迎的与不受欢迎的.那些能够按照开发者期望进行操作

软件 = 程序 + 软件工程(构建之法读书笔记一)

在我正式开始阅读这本书之前,我对于软件工程这个词汇的概念还是模糊的,认为它只是停留在是一门学科,一个专业,或者是一大堆硬生生的理论知识,然而当我读完构建之法这本书的推荐序和第一,第二版前言开始,我就深刻意识到我之前对于软件工程的肤浅认识是多么错误. 我看书一般喜欢从从书的封面开始看起,或许这也是大多数人看书的习惯,·在本书的封面素描着一副鲁班锁,刚开始让人感觉有点奇怪,明明是一本讲软件工程的书,为什么要用鲁班锁做为封面图案呢?原来玄机深藏于鲁班锁的内部,这鲁班锁从外部看,是严丝合缝的十字立方体,

构建之法读书笔记

周末我抽空将<构建之法>第一章读完,感觉对软件工程又有了新的认识. <构建之法>开篇便写到:软件=程序+软件工程.我认为这是对软件的一种及其精炼的解释.程序即是指一行行代码,软件工程则包含了各种软件开发活动,包括构建管理.源代码管理.软件设计.软件测试.项目管理等等,是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护上的过程. 作为一名机械专业的学生,我认为软件设计是我们必须掌握的一门技能.机械行业,除了大家普遍所能看到的机械结构,每一个设备还包含有控制.软件等部分,一个

构建之法读书笔记_1

本周我快速地阅读了一遍<构建之法>,提出以下几个问题: 1在满足客户需要的同时,我们有些什么原则需要坚持. 2软件测试方法有什么?做软件测试只是找BUG吗? 3什么是敏捷流程?怎样去根据自己的项目选择开发方法? 4第三章中有提及考级的相关内容,但是在社会工作中,实践经验比证书更重要,我们应该如何平衡理论知识与实践之间的关系? 5当今市场对软件有哪些主要需求,安全软件并不能填满所有的漏洞,它的发展前景真的有那么好吗?

构建之法读书笔记之三

在学习了构建之法第四章,第五章之后,写一下我的感想. 代码规范一直是我们在学习过程中一个老生常谈的话题.专业技能过硬与否只是一方面,代码规范同样也是一个举足轻重的方面.比如最开始的注释,在我们写一些很短的代码十几行,几十行代码的时候,如果不写注释,说白了,那么短的代码,谁都能找得到.但是,万一代码量上了三位数呢.几百行的代码,找那么一个错误,难度可是不小.再加点难度,四位数,五位数,甚至做项目的时候呢.没有注释,八成项目经理都不要你了. 代码规范有很多方面,处了注释,还有缩进,行宽,括号,分行,

构建之法读书笔记之二

由于近几周进行构建之法的学习很少,所以这周一下子看了三个周期的内容. 既然选择了软件工程专业,就决定了我们将来要朝着软件工程师的方向发展.那么,问题来了,如何成为一名合格的软件工程师,在成为一名软件工程师的过程中,我们又有那些需要注意和学习的地方呢. 软件工程师的成长道路上,首先对我们自己的专业技能有很高的要求.所以第一步,我们要丰富自己的专业技能,并奇瑞要很好的衡量自己的能力.这样一来,就有涉及到了衡量我们能力的标准.这里又有一个问题,对于这些衡量标准,我们不能抱着仅仅不被OUT的态度,不能只

构建之法读书笔记3

软件开发流程: 写了再改模式:适合只用一次的小程序 RUP统一流程:将不同类型的工作划分为规程和工作流. 老板驱动的流程:老板在整个流程中占据领导地位. 渐进交付的流程:现发布一个版本,然后根据反馈进行修改然后再发布,不断反复直到用户满意或无法进行下去时停止.MVP:最小可行产品,即先做出一个实现了关键功能的很小的软件供用户使用体验,然后根据用户反馈继续开发.MBP:最强最美产品,即等到产品做得完美了后再进行发布. TSP原则:优秀的模式和流程的共同点的总结. 瀑布模型以及瀑布模型的各种变形:适

构建之法——读书笔记(6)

第8章 需求分析 8.1 软件需求 寻找需求: 1. 获取和引导需求(Elicitation) 软件团队需要找到软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出对软件的需求. 2. 分析和定义需求(Analysis&Specification) 这是指对从各个方面获取的需求进行规整,定义需求的内涵,从各个角度将需求量化(需求实现的最后期限,实现需求大致所需的时间和资源成本,各个不同需求的优先级,需求带来的收益,等等). 3. 验证需求(Validation) 软件团队要跟利益相关者沟

构建之法读书笔记01

第一章讲述了学生与老师的关系,很多内容都是老师上课所涉及到的,那就是如何让我们学好软件工程,在很多时候我们都是有惰性的,需要老师给与压力,也就是老师说的要想让我们真的学会游泳,就要下水,同时老师还需要踹我们一脚,不仅是在学士或者在游泳的过程中,都要让我们感到压力,那样才能激发我们求生的本能,同时能够让我们创造奇迹. 软件工程融汇了很多技术,书中更是列出了十多种相关科目,在感觉到博大精深的同时,有深深的感觉学习这门的压力,看到了软件工程的目标,就是创造“足够好”的软件,而足够好也是给我们纠正了,不