构建之法读后感

Posted 暖旧

tags:

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

团队的特点:

1.团队有一致的集体目标,团队要一起完成这个目标。一个团队的成员不一定要同时工作。

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

软件团队的模式:

1.主治医师模式

首席程序员“主刀”(负责处理主要模块的设计和编码),其他成员“为主刀医师服务”(从各种角度支持他的工作)。

2.明星模式

主治医生模式运用到极致,可以蜕化为明星模式。

3.社区模式

社区很多志愿者参与,每个人参与自己感兴趣的项目,贡献力量,大部分人不拿报酬。

4.业余剧团模式

个人在团队中听从一个中央指挥的指导和安排。

5.秘密团队

软件团队进行一些秘密的软件项目。

6.特工团队

软件行业的一些团队由一些有特殊技能的专业人士组成,负责解决一些棘手而紧迫性的问题。

7.交响乐团模式

家伙多,门类齐全;各司其职,各自有专门场地,演奏期间没有聊天、走动等现象;演奏都靠谱,同时看指挥的;演奏的都是练习过多次的曲目,重在执行。

8.爵士乐模式

不靠谱;没有现场指挥;人数较少。

9.功能团队模式

具备不同能力的同事们平等协作,共同完成一个功能。

10.官僚模式

几个人报告给一个小头目,几个小头目报告给中头目,依次而上。

开发流程

写了再改模式适用于以下任务:

1.只用一次的程序

2.看过了就扔的原型

3.一些不实用的演示程序

瀑布模型适用于以下情况:

1.如果产品的定义非常稳定,但是产品的正确性非常重要,需要每一步的验证

2.产品模块之间的接口、输入和输出能很好地用形式化的方法定义和验证

3.使用的技术非常成熟,团队成员都很熟悉这些技术

4.负责各个步骤的子团队分属不同的机构,或在不同的地理位置,不可能做到频繁的交流

第6章主要是讲敏捷流程,敏捷流程是一系列价值观和方法论的集合。

敏捷流程相较于传统的软件模型来说,更加注重个人和交流,软件的可用性,与客户的合作和响应变化。

敏捷开发的原则:1.时间尽早;2.响应变化;3.持续更新;4.共同合作;5.有上进心;6.面对面交流;7.有指标;8.可持续;9.关注更新;10.简化;11.自我管理;12.提高效率。

敏捷流程概述:

1.找出完成产品需要做的事情--Product Backlog。

2.决定当前的冲刺(Sprint)需要解决的事情--Sprint Backlog。

3.冲刺(Sprint)。

4.得到软件的一个增量版本、发布给用户。然后在此基础上又进一步计划增量的新功能和改进。

敏捷对团队有三个要求:自主管理、自我组织、多功能型。

敏捷流程的经验教训

1.敏捷宣言表明的是一些优先级,不必当作圣旨或者教条来争论。

2.Scrum Master不是一个官,而是一个没有行政权力的沟通者,就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master,大多行不通。

3.一些项目需要很多暗箱操作和政治角力才能搞定,Scrum会把这些矛盾都摆到明处。这有好处,也有风险。

4.在复杂的项目里,让一线团队成员做决定。

5.创业公司的团队其实经常是运行在Scrum的模式中(只不过大家太忙,没工夫论证自己到底有多么Scrum)

6.在Scrum计划阶段的估计不是一个“合同”,领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint,这样即使不准的估计也不会有大的损害。

7.不要和管理层谈“流程”,他们只关心“结果”。

8.在大型团队、跨地区的团队,或者复杂项目中,Scrum并没有非常完美的答案,Scrum的创始人也承认这一点。

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

《构建之法》读后感

《构建之法》读后感

《构建之法》读后感

《构建之法》读后感

《构建之法》读后感

《构建之法》读后感