构建之法读后感第三篇

同敏捷开发同样具有影响力的是微软的MSF开发模式,他有着一下几个基本原则:

一、推动信息共享与沟通

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

这样确实有很多好处,首先,信息都保留了下来,其中更是对的,错的都有。

这一方面当我们想查询自己以前的程序时,可以很方便的找到程序,并且,我们可以不断的从自己的错误中积累经验。

二、为共同的远景而工作

这里 “共同的远景” 是指产品的远景,在同一时段,团队里的人的目标应该一致,这样才能真正的齐心协力,把软件开发好。

三、充分授权和信任

关键在于 “授权” 。

在一个高效的团队里,所有成员都应该能得到充分的授权,他们有权在职权范围内按照自己的承诺完成任务。

同时,他们也充分信任其他同时能实现各自的承诺。

类似的,团队的顾客也认为团队能兑现承诺,并进行相应的规划。

四、各司其职,对项目共同负责

团队中的每个角色都有自己的职责,如果出了问题,这个角色就要负责任。

五、重视商业价值,提供渐进的价值

六、保持敏捷,预期和适应变化

软件工程,唯一不变的是变化。

七、投资质量

八、学习所有的经验

九、与顾客合作

以上就是MSF的九项基本原则。

MSF同样还支持敏捷开发模式和CMMI开发模式。

软件之所以诞生,就是为了解决现实社会和生活中的各种问题。那么软件团队想要找出需求具体有下面的几个步骤:

一、获取和引导需求

二、分析和定义需求

三、验证需求

四、在软件产品的生命周期中管理需求

  软件产品的利益相关者:用户、顾客、市场分析者、监管机构、系统/应用集成商、软件团队、软件工程师

  那么,怎么获取用户需求呢?-----用户调研

1.焦点小组  2.深入面谈  3.卡片分类  4.用户调查问卷  5.用户日志研究  6.人类学调查  7.眼动跟踪研究  8.快速原型调研  9.A/B测试

  做一个软件,不仅要能做好他,还要能在做软件之前,很好的预估做好软件的时间。那么怎么能够提高我们的估计能力呢?

1.参考前人的经验  2.运用公式计算  Y=X+(-)X/N  (Y代表实际用的时间,X代表估计的时间,N代表该程序员做过类似此项目的次数)

  在学程序语言的时候,我们知道,在解决大型问题的时候,解决的最好方法是分而治之。

同样的,对于一个大型的项目,我们同样应该采用分而治之的方法来解决问题。

  对于我们学软件的学生来说,可能我们只知道开发和测试,但实际上,在公司里还有一类人,他们做着开发和测试之外的事情,那就PM,人称项目经理。

具体做的事情有:1.和客户交谈,组织用户调查,发现用户需求  2.了解和比较竞争对手的产品  3.怎么让软件变得可用、有用  4.怎么改进团队的流程等等。

简而言之,PM做开发和测试之外的所有事情。

并且,PM还要学会风险管理。

那么,PM的能力要求和任务是什么?

一、观察、理解和快速学习能力

二、分析管理能力

三、一定的专业能力

四、自省的能力

下面讲讲作为大学生,如果想要做PM,需要准备着什么?

1.参加各种社团并组织一些活动,最好是草根的活动,而不是由上而下规定的活动;

2.选修各种相关学科的课程

3.争取在实际的企业中实习

4.和小伙伴一起,搞点小生意、小创业

  

时间: 2024-10-29 19:06:18

构建之法读后感第三篇的相关文章

构建之法读后感(三)

构建之法的第八章主要是讲述了需求分析开发团队是主要为用户着想,在开发项目之前进行用户分析: 讲述软件需求的4个步骤,(1)获取和引导需求(2)分析和定义需求(3)验证需求(4)在软件产品的生命周期中管理需求 . 讲述了9种用户调研方法:(1)焦点小组(2)深入面谈(3)卡片分类(4)用户调查问卷(5)用户日志研究(6)民族志/人类学调查(7)眼动跟踪研究(8)快速原型调研(9)A/B测试 通过这些方法可以帮助我们更好的了解用户的需求,开发出用户喜欢的软件: 第九章主要是讲述了项目经理和其他经理的

构建之法读后感第四篇

使用软件的人叫做用户.那么,想要编出一个好软件,就必须要清楚的知道自己的用户是什么样的. 于是乎,典型用户和典型场景的分析就变得尤为重要. 那么,怎么定义典型用户呢? 定义典型用户的模板可以包括以下内容: 1.名字(越自然越好) 2.年龄和收入(不同年龄和收入的用户有不同的需求) 3.代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例比较少,但是影响大,所以更重要) 4.使用这个软件的典型场景 5.使用本软件/服务的环境(在办公室/家里/沙发/床上/公共汽车...) 6.

阅读构建之法读后感第三章

养成一个优秀的程序员必须做到的: 1.代码规范 首先我们需要了解的是我们的代码不只是给机器看的主要还是给人看的,那么我们就需要将我们的代码写的清清楚楚. 代码风格规范:主要是文字上的规范,看似表面文章实际上非常重要.代码风格的原则就是简明,易读,无二义性. 1.缩进,使用tab键,4个空格的距离看着正好. 2.行宽,必须限制行宽. 3.括号,括号清楚的表示逻辑优先级. 4.断行与空白{}行. 5.分行,不要将多条语句放在同一行. 6.命名,必须分清楚类,变量,关键字的命名方式. 7.下划线,用来

《构建之法》阅读梳理篇读后感

我通过老师发的链接读了“<构建之法>阅读梳理篇”,我从中懂了很多,我懂了软件与程序的区别,明白了作为一个程序员是要掌握的基本能力,更明白了一个软件或项目是由一个团队完成的,个人的能力再强也强不过一个团体.在这篇文章中我明白了很多,同时我也对我日后可能要做的工作有了更全面的了解,也令我看清了程序员这个工作的前景和工作方式,更令我看清了自己的缺点和不足.我要以这篇文章里的要求去要求自己,向真正的程序员努力. http://www.cnblogs.com/lwr-/p/5199030.html?fr

构建之法阅读笔记三—结对编程

构建之法阅读笔记三——结对编程 何谓结对编程,结对编程就是程序员肩并肩,平等的,互补的进行开发工作,他们使用同一台电脑,编写同样的程序,一起分析,一起设计,一块交流想法. 然而我以前却并不是这样做的,我以前喜欢在没人打扰的环境下写代码,我觉得有人在我身边看着,会影响我的思路,还有我个人自尊心比较强,不太喜欢被人指指点点,所以每次都是,我写完代码之后,自己先找自己的bug,每当自己实在找不到之后,才会请教大神,但是有时候可能由于自己的能力不足,往往一个很简单的问题,我自己发现就会花费很久的时间,让

构建之法读后感----第1章 绪论

首先,文章对于程序.用户需求.工程等等概念用了阿超给儿子编写的一个出题程序来分别解释了个中的含义,尤其是程序和工程的区别,程序大概就是用很多语言或工具编写的一个简单能实现目标要求的一行行代码,而工程就是在这个程序的基础上不断满足用户的需求.修复程序的bug.提供后续维护等服务. 需求分析:梳理需求,逐步展开后续工作,如设计(软件架构).实现(写数据结构和算法),测试,发布软件 软件=程序+软件工程(软件企业=软件+商业模式) 软将工程的核心部分:构建管理.源代码管理.软件设计.软件测试.项目管理

《构建之法》第三章学习心得

这周我学习了<构建之法>第三章,讲述了软件工程师的成长.软件系统的绝大部分模块都是由个人开发或维护的.在软件工程的术语中,这些单个的成员叫做Individ-ual Contributor(IC).IC在团队中的流程是怎么样的呢?以开发人员为例,流程如下. 1.通过交流.实验.快速原型等方法,理解问题.需求或任务 2.提出多种解决办法并估计工作量 3.其中包括寻找以前的解决方案,因为很多工作是重复性的 与相关角色交流解决问题的提案,决定一个可行的方案 执行,把想法变成实际中能工作的代码,同时验证

《构建之法(第三版)》速读提问

<构建之法(第三版)>速读提问 1.什么是软件工程 软件工程学科诞生后,人们为软件工程给出了不同的定义,例如最早的定义是由F.L. Bauer给出的,即"软件工程是为了经济地获得能够在实际机器上高效运行的.可靠的软件而建立和应用一系列坚实的软件工程原则". 软件工程学科包含为完成软件需求.设计.构建.测试和维护所需的知识.方法和工具. 软件工程是一门交叉性的工程学科,它是将计算机科学.数学.工程学和管理学等基本原理应用于软件的开发与维护中,其重点在于大型软件的分析与评价.规

20179215 《构建之法》第三章

<构建之法>第三章 读书笔记 ?本章为软件工程师的成长,主要介绍了评价软件工程师水平的主要方法,技能的反面,TSP对个人的要求. 一.个人能力的衡量与发展 ?软件开发流程:软件开发流程包括团队的流程,也包括个人的流程 ?软件系统的绝大部分模块都是由个人开发或维护的.在软件工程的术语中,我们把这些单个的成员叫做Individ-ual Contributor(IC).IC在团队中的流程如下. 通过交流.实验.快速原型等方法,理解问题.需求或任务 提出多种解决办法并估计工作量 其中包括寻找以前的解决