软件工程《构建之法》第6,7章读后感

1、成功的变革不是完全自上而下或者自下而上,而是通过结合两者的变革相关要素。

2、如果我们不能预见到Scrum转型的结束状态,便无法确定当前状况和结束状态之间所有的差距。

3、变革与过去培训的内容往往产生冲突,软件开发人员很难在短时间适应这种变化,导致转型的失败。

4、人进行改变的能力是有限的,因此企业进行改变的能力也是有限的-———要求人们在同一时间内做太多改变,他们是无法承受的,毁坏性的压力和未来的冲击产生的迷惑会随之而来。加之,当代技术革新的速度之快,人们无法快速跟上,导致人们工作和交互方式根本性的变化与不同。

5、最佳实践是危险的。就像丰田创始人说道的一样“有一些事情称之为标准工作,但是标准是在不断变化的。相反,如果你认为这些标准工作对你来说已经是最好的,那么一切都结束了。如果我们把一些事情作为最好的可能方法,那么对于精益【持续增量的改善】的动力就消失了”。

时间: 2024-10-23 22:52:43

软件工程《构建之法》第6,7章读后感的相关文章

《构建之法》第四章读后感--软件工程

<构建之法>第四章读后感--两人合作 1.代码风格很重要,因为良好的代码风格,有益于两人的合作甚至多人的合作. 个人认为 : 良好的代码风格的培养就是 多去阅读别人的优秀代码 ,用于提高并且培养自己的代码风格. 2.关于结对编程的重要性 2.1 结对编程能提高设计质量与代码质量 2.2 结对有益于学习交流 3.如何结对编程 3.1 主动参与讨论,提出设计方案或者问题的解决方案 4.代码的复审 复审可以提高代码质量,优化项目性能.

构建之法五、六章读后感

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

《构建之法》第十七章读后感

通过阅读<构建之法>第十七章,不能说对我造成了什么深远的影响,但是还是感触颇深: 第一,工作分配的重要性,说道工作分配,不得不说我们个小组的组长们,组长不仅仅是一个团队的领导者,更是这个团队的灵魂.它不仅需要了解随时掌握各组员的动向,更重要的是,他需要了解各组员的能力,然后根据个人的能力,然后再去非陪相应的任务,只要这样才能做到“物尽其用”,才能更好的完成我们的项目,有时甚者能更创造出以外的效果,达到更完美的状态.这不仅是组长的能力  其实其无时无刻也体现着我们这个小组的团结力和创造力.当初选

读《现代软件工程--构建之法》1~5章的感受

1:看完书后的第一感觉: 晚上抽出时间看了软件工程这本书.刚开始的时候我也就凭着对作业的要求去看了1~5章,并没有深刻的去了解,甚至有的章节还就一眼带过,或者直接跳过,直到很随便的看完后,并没有了解到多少.说句心理话,这本书在我认为真的是很枯燥乏味,但能成为我们的学习课程之一,一定有它的好处,有它的知识值得我们去学习.之后带着想学知识的心理再重看了一遍,心里大概的了解到什么是软件工程,怎么有效的写出代码.若以后工作中,承当一个软件工程师的话,该如何做,才能在自己的工作团队中发挥到最有效的成果.

《构建之法》第三章读后感

软件工程包括了什么呢?第一章提到过: 软件工程包括了开发.运营.维护软件的过程中的很多技术.做法.习惯和思想.软件工程把这些相关的技术和过程统一到一个体系中,叫"软件开发流程",软件开发流程的目的是为了提高软件开发.运营.维护的效率,以及提升用户满意度.软件的可靠性和可维护性. IC在团队中的流程是怎么样的呢?以开发人员为例,流程如下: 1.通过交流.实验.快速原型等方法,理解问题.需求或任务 2.提出多种解决办法并估计工作量,其中包括寻找以前的解决方案,因为很多工作是重复性的 3.与

软件工程 《构建之法》 第四章读后感

在第四章我们进入了软件工程另一项核心的起步阶段——结队编程,所谓工程自然不是一个人便能完成的了所有的工作,而是一个集合了一个团队的合作完成作品的过程.在开始结队之前,需要达成共识的便是代码的规范性,这在编程界早已有了相应的通用准则且在随着整个行业的进步而不断更新着.作为合作的项目,个人能力上或许会有不同,但哪怕团队中有个别人才思敏捷却只按着自己的路子走,不贴合代码的规范,使其他人无法去阅读理解,这无疑是从一开始便失去了结队的意义. 故而我们要学会遵守代码的规范性,好的代码是可以方便队友一同阅读.

构建之法6、7章--读后感---软件工程

第六章:敏捷流程 在 6.2节中定义好任务究竟是什么?书上敏捷第三步中有个例子写道:”去你的,要改主意,也要等老子冲刺再说!“,这句话我不是很理解,万一产品负责人改变主意,重新确定好任务,那么程序猿还得将之前的任务继续“冲刺”下去吗? 第七章:MSF 随着信息时代的高速发展,MSF也具有它的基本原则: 1.推动信息共享与沟通: 2.为共同的远景工作: 3.充分授权的信任: 4.各司其职,对项目共同负责: 5.交付增量的价值: 6.保持敏捷,预期和适应变化: 7.投资质量: 8.学习所有的经验:

软件工程---《构建之法》第4章读后感

软件都是在相互合作中完成了,由不同的人完成软件的过程中,由于代码的风格规范不同,例如缩进.行宽.括号.断行等有所不同,阅读其他人的代码便会有代沟:除了这些风格规范外,当你完成的是某一个小的功能时,要处理好代码的逻辑关系,因为打出来的的代码是要给别人看的,如果代码的可读性不高,当别人使用你的代码的时候,因为结构混乱还得花时间去研究你的代码,这样一来,还不如自己重新实现一遍,说不定比研究你的代码的时间更短呢. 当自己完成代码后,还要进行代码的复审,最基本的复审就是同伴的复审.代码复审可以查找出一些小

构建之法 第6~7章读后感

第六章-敏捷流程 第六章主要详细介绍了敏捷流程,在软件工程范畴里,“敏捷流程”是一系列价值观和方法论的集合.这一章以敏捷流程的Scrum方法论而展开,而敏捷流程的精髓就是在于快速的交付. 敏捷开发的流程如下: 1.找出完成产品需要做的事情 - Product Backlog. 2.决定当前的冲刺(Sprint)需要解决的事情--Sprint Backlog. 3.冲刺(Sprint).在冲刺阶段,外部人士不能直接打扰团队成员.期间每日例会,向同伴报告进度,把问题摆在明面上.同时启动每日构建,让大

《构建之法》第8-10章读后感

第八章:需求分析 本章节讲述软件需求的4个步骤,(1)获取和引导需求(2)分析和定义需求(3)验证需求(4)在软件产品的生命周期中管理需求 .在软件工程中分析软件需求需要考虑相关者的利益关系,例如用户.顾客.市场分析师.监管机构.软件工程师等之间的关系. 讲述了9种用户调研方法:(1)焦点小组(2)深入面谈(3)卡片分类(4)用户调查问卷(5)用户日志研究(6)民族志/人类学调查(7)眼动跟踪研究(8)快速原型调研(9)A/B测试 第九章:项目经理 PM指的是项目经理 Product Manag