0502,读《构建之法》第6~7章有感

《构建之法》第6和7章讲的是敏捷流程和MSF。大概了解了一些关于敏捷流程和MSF的一些基本概念。敏捷流程是一系列价值观和方法论的集合。敏捷流程同MSF同有着自己的基本原则。

先来说一说“敏捷流程”吧。

敏捷开发原则有12点,针对客户需求,市场竞争,软件自身的更新完善,还有就是开发团队自身以及开发团队和业务人员的关系。原则本身强调的是效率,人性,以及灵活。我个人感觉这套原则挺不错的。

敏捷流程分出了四步,Product Backlog,Sprint Backlog,Sprint,改进更新。就像名字一样,敏捷快速高效有质量。

敏捷对团队要求要求很简单:自主管理,自我组织,多功能模型,但是做到却不是很容易。

MSF有9个基本原则,针对信息共享,团队内部运营,市场,还有客户。同样是强调效率,人性,灵活,还有前景。

MSF对信息共享和沟通十分强调,对团队内部运营强调相互信任,各司其职。MSF敏捷开发模式分为两支,MSF敏捷开发模式和MSF CMMI开发模式。都是很人性,灵活,以及对自身有高要求的模式。

敏捷流程和MSF,在我看来相对比较迅捷,给人一种少了很严肃气愤的方法。个人还是比较喜欢。

时间: 2024-10-20 02:12:07

0502,读《构建之法》第6~7章有感的相关文章

读《构建之法》前三章有感

最近这几天一直下雨,我的心犹如构建之法一般的复杂,但是,听着雨声,仔细的思考后,感觉构建之法在我的心中慢慢的变得清晰了.这几天看了<构建之法>的前三章后,心有所感,在这里就粗略的讲一讲我的感想,首先是第一章,主要讲了软件工程师什么,软件又是什么,软件的各种要素等等,让我对软件有了一定的了解,同时深有所感的是,一个软件,不论好与坏,都是应人们需求所产生的,所有的软件都不是一天就可以完成的,有的需要很久很久,同时还需要一个团队的合作才能呈现出一个软件,软件工程这门学问不是一个理论的学问,更多的是一

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

第四章讲的只要内容是结对,也就是两个人合作,涉及到的理论和知识点有代码规范,极限编程,结对编程,两人合作的不同阶段以及影响他人的技巧.首先代码的规范性,一个不管再怎么牛逼的程序员,如果他写的代码杂乱无章,别人也不会认可他的.代码规范分两个部分,代码风格规范和代码设计规范,而风格规范中讲的是缩进,行宽,括号,断行,分行,命名,下划线及大小写.设计也包括11个内容. 接下来就讲了代码复审,写出来的东西一定要经过审核才能拿出来给别人用的,审核就是要找出我们代码的错误,发现逻辑错误,算法错误及一些潜在的

读构建之法之感

读构建之法之感,为什么迟迟没有发构建之法这本书的观后感,是因为想要细细的看,为什么老师这么要求我们这么做,为什么要刻意的去发微博,原因都在构建之法的这本书中.构建之法这本书和其它的软件工程的书不同,构建之法这本书讲的清晰有趣,容易理解,不像其它的软件工程的书籍,写的那么的枯燥和乏味,构建之法的每章都有很大的联系,让人逐渐的去深刻的理解.通过构建之法理解并懂得什么是软件工程,软件工程是系统的,有序的,可量化的方法应用到软件的开发,运营和维护中去.希望通过自己的努力以及软件工程的课能够让自己有一个小

第五次作业《读构建之法的心得》

<读构建之法的体会> <构建之法>这本书是软件大大神邹欣的作品之一,这本书体现邹欣老师的情怀,很简洁的讲述了软件设计的各个阶段,描述了一个微软软件大神对软件的理解.构建之法对我帮助挺大的,通过构建之法这本书使我对软件的构建很清晰的了解,让我对软件设计更加的清晰的认识,增加了我对软件的认识的兴趣,好了,现在来讲述讲述里面的内容,第一张讲概论:软件等于程序加文档,软件工程是什么,第二章讲 个人技术和流程 单元测试,效能分析工具,个人开发流程第三章讲软件工程师的成长 个人能力的衡量与发展

对读构建之法后提出的五个问题

读构建之法有以下几点疑惑: 1.如何使自己的开发思维更加敏捷? 2.如何分配好团队里面成员的任务,来达到最好的工作效率? 3.当面临用户的需求和优化后的软件起冲突时,用户的需求一定是最重要的吗?那么用户根本不了解优化的软件的好处,一定强制要求修改怎么办? 4.如何使自己的产品在市场上占有绝对的优势? 5.什么样的软件开发团队要开发什么样的软件才适合敏捷流程?

读《构建之法》第四章 、第十七章

第四章    两人合作 通过对于<构建之法>第四章的阅读使我对代码规范 . 代码复审 . 以及结对编程有了更加深刻的认识,所谓代码规范可以分为两个部分,代码风格规范和代码设计规范,代码风格规范的原则是:简明 . 易读 . 无二义性,代码书写的形式,变量命名的方法,注释程序如何工作都有详细的介绍,令我受益颇多.代码设计规范不光是程序书写的格式问题,而且牵涉到咸亨需设计 . 模块之间的联系 . 设计模式等方方面面,函数的设计,语句的使用,错误的处理,这些都是我们在进行程序设计的时候需要注意的地方.

构建之法1,5,17章读后感触

看了构建之法1,5,17章的内容,我对团队有了新认识.在一个团队中,不同成员来自五湖四海,为了一个目标,走到了一起.所以,需要的是全身心的投入.但人资历,成绩,口碑有差别,这就有了好/中/差,三等待遇,所以付出的努力不同,得到的待遇自然而然也就不同. 在我们这次软工中,我们需要一个真团队,高效的团队,来互相提升帮助我们完成这些任务.在这过程中,我们需要负担起身上的责任和要对伙伴负责.这样才能让团队走向成功

阅读《构建之法》第四章感想

课下阅读<构建之法>第四章,自己有以下一些感想. 1.我们写的代码最终都是要给人看的,所以代码规范化是一个优秀编程员必备的良好习惯,而且若是在团队里工作,那么代码规范更加重要.编程人员要遵循的代码风格的原则是:简明,易读,无二义性.以后自己要养成规范代码的习惯. 2.复审也是不可缺少的一个步骤,软件工程中最基本的复审手段就是同伴复审,找熟悉代码,有经验的人来进行复审. 3.当今时代,一个人能发挥的力量越来越小,团队的力量日渐重要,因此,如何合作,很关键.两个人合作,如何影响对方,要因人而异,因

阅读《构建之法》第四章、第十七章收获

阅读<构建之法>第四章.第十七章 阅读这一章的时候,我意识到了很多以前写程序没有注意到的地方,以前写程序就只知道能运行就好,根本不管自己写的程序占多少内存,运行的时间,是否有优化的空间,写代码的时候也不注意规范,有时候设计的函数根本用不上,造成代码冗余.同时也认识到结对编程的重要性,没读这本书之前就觉得结对编程就是两个人一人负责一个模块,然后合在一起,调试调试.但实则不然,真正的结对编程应该像书中那样,一个是驾驶人,一个是领航人,两个人有规律的进行编程.期间,一人编程一人复审,极大地提高了效率

构建之法五、六章读后感

在本周我主要学习了构建之法的第五章和第六章,第五章主要讲述团队和流程,第六章主要讲述敏捷流程: 软件团队的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式: 开发流程包括:写了再改模式.瀑布模型.瀑布模型的变形(生鱼片模型.大瀑布带着小瀑布): Rational Unified Process统一流程(RUP):包括业务建模.需求.分析和设计.实现.测试.部署.配置和变更管理.项目管理.环境: RUP的四个阶段包括:初始