《构建之法》第七章自习感想与知识点

本周的学习当中,我第一次接触到了MSF这个概念,它是微软所推荐的做软件的一种方法。它有9条基本原则,每条原则环环相扣,规划合理,并且并非一成不变,会随着学习而完善,所以可以适用于很多场景。沟通也是这个方法的一个重点,与团队沟通,与客户沟通。这样一个方法很显然也是要依赖于一个强劲的团队的。以下是本周的一些知识点:

一.MSF基本原则

1)推动信息共享与沟通

所有信息都保留并公开,讨论要包括所有涉及的角色,决定要公开并告知所有人。当然,对牵涉到技术机密、安全性等信息要采取必要的把握措施。

2)为共同的远景而工作

这个目标必须是明确的,没有二义性,不是当前就能达到,必须是通过努力才能达到的,并且不是空泛的,它应该对项目成员每天的工作都有指导作用。

远景一般是由“有远见的人”提出,然后公开讨论,在讨论的过程中,可以消除误解,凝聚共识。这是一个项目的关键,是项目第一阶段要达到的主要目标。

3)充分授权和信任

关键在于“授权”这个词,授权有两个意思:一是给某人权利和权威;二是给予某人更多自信和自尊。在一个高效的团队中,所有的成员都应该能得到充分的授权,他们有权在职权范围内按照自己的承诺完成任务,同时,他们也充分信任其他同事能实现各自的承诺。

4)各司其职,对项目共同负责

团队中的每个角色都有自己的职责,如果出了问题,这个角色就要负责任。每个角色的工作相互渗透依赖。

5)交付增量的价值

一个项目的商业价值只有在它被成功地发布并运行时才能体现出来,所以,MSF过程模式包括了开发和发布阶段。

6)保持敏捷,预期和适应变化

是预期变化,不是期望变化。

7)投资质量

对质量的重视,引起对质量的投资,引起对人、过程和工具的投资。

8)学习所有的经验

在学习过去的经验的同时,也要避免让过去的经验妨碍解决现在的问题。

9)与顾客合作

注重交流问题。

二.MSF团队模型

  

在MSF团队模型中,任何技术项目都必须达到特定的关键质量目标,才能够被认为是成功的项目。任何一个角色无法实现其目标,都将危及整个项目。因此,每个角色都被认为是同等重要的,重要的决定都要共同做出。

三.MSF过程模型

MSF过程模型是从传统的软件开发瀑布模型和螺旋模型发展而来的,它把瀑布模型中基于里程碑的规划优势与螺旋模型中增量迭代的长处结合了起来。

MSF过程模型的基本元素是阶段和里程碑。

四.MSF开发模式:1)MSF敏捷开发模式 2)MSF CMMI开发模式

  

时间: 2024-10-29 19:13:43

《构建之法》第七章自习感想与知识点的相关文章

《构建之法》第八章自习感想与知识点

第八章主要讲述的是需求分析一些相关内容及注意要点.看似简单其实注意的细节还是有很多的,首先是引导和获取需求,然后再是分析和定义需求,之后还要验证需求和在软件生命周期中管理需求.这一系列的事项仔细研究起来都是一门学问.以下为本周的一些知识要点:一.软件需求 1.准确而全面的找到需求的方法:获取和引导需求,分析和定义需求,验证需求,在软件产品的生命周期中管理需求. 2.软件需求从不同角度的划分:对产品功能性需求,对产品开发过程的需求,非功能性需求,综合需求. 二.软件产品的利益相关者 利益相关者包括

构建之法第七章学习心得

这周我学习了构建之法第七章MSF的介绍.MSF有9个基本原则,针对信息共享,团队内部运营,市场,还有客户.同样是强调效率,人性,灵活,还有前景. MSF对信息共享和沟通十分强调,对团队内部运营强调相互信任,各司其职.MSF敏捷开发模式分为两支,MSF敏捷开发模式和MSF CMMI开发模式.都是很人性,灵活,以及对自身有高要求的模式.结合上一章的敏捷流程和这次学习的MSF,在我看来相对比较迅捷,给人一种少了很严肃气愤的方法,个人还是比较喜欢.MSF的最大特性是商业化,并一直体现在项目的实施过程中.

《构建之法》第六章自习感想与知识点

本章的学习主要讲的是敏捷流程.敏捷流程从字面上来看敏捷就是快速的,同时透露出一种年轻化的感觉的流程.但在深入的学习了之后才发现要快速的完成有价值的软件并交付给客户是有很大的学问在里面的.同时,也不是所有的情况都适合这样的流程的,需要综合各项因素来决定.以下是本章的一些知识点: 敏捷流程的定义:是一系列价值观和方法论的集合 敏捷开发的原则:1. 尽早并持续地交付有价值的软件以满足顾客需求2. 敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势3. 经常发布可用的软件,发布间隔可以从几周到几

《构建之法》第四章自习感想与知识点

本章讲的是两人合作.其实在我过往的经历当中也有过合作,比如大一时候的短学期大作业.每个人的代码风格都是不一样的,有的人的代码写的非常有个性,以至于其他人读起来都非常的废力.在一个中大型的项目里,自己改起来也是非常的麻烦.这种时候,代码的规范性就非常的重要了.规范的代码看过去就是清清楚楚的,是什么就是什么,不会产生疑惑,也不会有原作者不在其他人就无法对其参考修改的情况.以后的大工程都是要至少两个人合作才能完成的,不能再随心所欲了.在以前编写代码的过程中我也是往往不注意注释以及清晰的变量名的重要性,

《构建之法》第一章自习之所感

在本周自学了第二章的内容后才发现了自己以往编程所忽略的很多事情,就拿测试来说,以往的编程我几乎是不会去进行测试的.以前只知道把编好的代码一通敲进去,然后点击执行,结果对了就成.其实这样的做法,小型的程序中可能体现不出什么问题,但一旦做到大型的程序就有可能包含很多的隐患.单元测试的进行可以使模块的质量得到稳定量化的保证,并且可以使自己负责的模块功能定义明确,模块内部的改变不会影响其他模块.回归测试则可以用来确保已经修复的bug没有再复发.再来就是效能分析,它能让我们的程序跑的又快又好等等.可以说这

现代软件工程构建之法 前五章阅读感想&困惑

第一章 第一节 新时代中国的IT产业市场规则不规范,书中提到社会上有个别软件公司的软件一定要卸载别家公司的软件才能运行,我这里感到疑惑---————是不是说如果 一间软件公司他能做出一个像微软操作系统那样的受大众十分喜爱的软件 那么他就可为所欲为 对一些不友好的软件公司进行屏蔽,从而决定了其他公司的生存??? 第二章 第一节 之第二部分 这里说到程序员作为该单元的开发者 必须亲自写开发单元 但如果遇到上头委派的一件又急又大型的项目 那么还要写单元测试?或者不能让别人写? 第三章 第二节 这里说的

构建之法第七章总结

微软解决方案框架-MSF,不像敏捷那样有宣言,但是他也有一套思想框架 (1)推动信息共享与沟通.所有信息都保留公开,讨论要包括涉及的所有角色,决定要公开并告知所有人.随着项目复杂度和团队规模的增加,信息共享和沟通可以让项目进度以及项目中存在的问题及时让所有人知道,保持敏捷,预测并适应变化. (2)为共同的远景而工作.这个共同的远景是指产品的远景,有团队的领导人要所有人同意并为之奋斗的项目的远景.做一个项目,要明确项目的目标是什么,项目没有二义性,必须通过努力才能达到,对团队成员每天的工作都有指导

构建之法第七章读后感

1.MSF没有像敏捷那样搞一个宣言,但是他也有一套思想框架--9条基本原则. 1)推动信息共享与沟通: 2)为共同的远景而工作: 3)充分授权和信任: 4)各司其职,对项目共同负责: 5)交付增量的价值: 6)保持敏捷,预期和适应变化: 7)投资质量: 8)学习所有的经验: 9)与顾客合作. 2. MSF 团队模型,任何技术项目都必须达到特定的关键质量目标,才能够被认为是成功的项目.任何一个角色无法实现其目标,都将危及整个项目.因此,每个角色都被认为是同等重要的,重要的决定都要共同做出. 3.

构建之法 第七章 MSF 读书笔记

MSF 9条基本原则: 1.推动信息共享与沟通 2.为共同的远景而工作 3.充分授权和信任 4.各司其职,对项目共同负责 5.交付增量的价值 6.保持敏捷,预期和适应变化 7.投资质量 8.学习所有的经验 9.与顾客合作 在一个高效的团队中,所有的成员都应该能得到充分的授权,他们有权在职权范围内按照自己的承诺完成任务,同时,他们也充分信任其他同事能实现各自的承诺.类似的,团队的顾客(包括内部和外部的顾客)也认为团队能兑现承诺,并进行相应的规划.