构建之法五、六章读后感

在本周我主要学习了构建之法的第五章和第六章,第五章主要讲述团队和流程,第六章主要讲述敏捷流程;

软件团队的模式有:主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式;

开发流程包括:写了再改模式、瀑布模型、瀑布模型的变形(生鱼片模型、大瀑布带着小瀑布);

Rational Unified Process统一流程(RUP):包括业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理、环境;

RUP的四个阶段包括:初始阶段、细化阶段、构造阶段、交付阶段;

老版驱动的流程;渐进交付的流程;

MVP:最小可行产品,又称最小功能集;MBP:是指最美最强产品;

TSP(Team Software Process)的原则:1.使用妥善定义的流程,流程中的每一步都可以是重复的、可以衡量结果的;2.团队中的各个成员对团队的目标、角色、产品都有容易的理解;3.尽量使用成熟的技术和做法;4.尽量多的收集数据(也包括对团队不利的数据),并利用数据来帮助团队做出理性的决定;5.制定切合实际的计划和承诺,团队计划要由负责具体执行的角色来制定(而不是从上级而来);6.增加团队的自我管理能力;7.专注于提高质量,争取咋软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题);

敏捷流程是一系列的价值观和方法论的集合。

敏捷的步骤:第一步,找出完成产品需要做的事情——Product Backlog。第二步,决定当前冲刺(Sprint)需要解决的事情——Sprint Backlog。第三步,冲刺(Sprint)。第四步,得到软件的一个增量版本,发布给用户。然后在此基础上又进一步计划增量的新功能和改进;

敏捷对团队的要求:自主管理,自我组织,多功能型;

通过这两章的学习,让我对团队和流程以及敏捷流程有了一定的了解,希望接下来的学习能让我有更进一步的了解。

时间: 2024-10-29 10:47:47

构建之法五、六章读后感的相关文章

构建之法第六章学习心得

这周我学习了构建之法第六章敏捷流程,本章主要介绍了敏捷流程及其原则,Backlog.Burn-down.Sprint.Scrum方法论.以及什么时候选择敏捷的开发方法,什么时候选择其他方法..敏捷开发的原则是尽早并持续地交付有价值的软件以满足顾客需求敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势经常发布可用的软件,发布间隔可以从几周到几个月,能短则短业务人员和开发人员在项目开发过程中应该每天共同工作以有进取心的人为项目核心,充分支持信任他们无论团队内外,面对面的交流始终是最有效的沟通

构建之法第五六章读后感

邹欣老师的这本书,写得形象生动,第五章用体育运动等团队例子引出软件开发团队的形式.软件团队形式多样,适用于不同的人员与需求.团队可能会演变的模式有:主治医师模式.明星模式.社区模式.业余剧团模式.秘密团队.特工团队.交响乐团模式.爵士乐模式.功能团队模式.官僚模式等.开发流程模式有:瀑布模式.瀑布模型的各种变形.统一流程.老板驱动的流程.渐进交付的流程等.在过去的学习生活很少有团队合作的时候,看了本章很期待后续与大家团队合作,肯定会遇到很多困难,但只有把学到的运用到实际,知识才会学得更牢靠. 看

0405构建之法第四章--读后感

<构建之法>这本书的第4章讲的是关于两人合作的内容,对于书里所说的两人的关系就和驾驶员.领航员类似,通过结对合作,令我意识到了编写程序不仅仅要自己能明白,也要便与他人查看和理解自己的程序. 代码规范性,我们编写代码时要注重代码风格规范和代码设计规范,无论是类名,对象名,缩进还是行宽什么的,在结对子编程时都要有所规定,不然到后面出现的类或是对象多了,就很容易混乱,分不清楚谁是谁.要学会封装,编写函数,将功能模块具体化,减少主方法里面的代码,避免大规模的出错. 代码的复审,在平时编程程序时,我也会

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

身为本科计算机专业二年级的学生,在老师的推荐下阅读了<构建之法>,这几天读了这本书的一部分,发表一下自己的感受,这本书让我对自己的专业有了更加深刻的了解. 在第一章中讲述了学生和老师的关系,老师在课堂上也有所提及,要我们学好软件工程,并应该努力的去编程,老师起到的作用就是督促我们,给我们学习的压力,这样才能在软件工程的道路上越走越好,越走越稳.而大多数人在编程的路上总是被懒惰所打败,不愿意去做认为是枯燥的,或者认为自己做不到,老师布置的作业也总是糊弄完事,在读了一部分这本书之后,或许会有另一种

《构建之法》6-7章读后感、问题及对Scrum的理解

第6章读后感: 看完第六章后了解什么是敏捷流程.“敏捷流程”在软件工程的语境中是一系列价值观和方法论的集合. 我觉得敏捷是比较人性化而且让人比较轻松的的一种方法吧,它会比较注重交流,而不是硬性的规定和要求,比如用户与开发者之间的交流,团队内部成员的交流等等,分工合作等会比较公平,而且会比较注重效率,会经常更新自己做的软件,会有长期的一个规划,有计划的去完成任务,团队进步会很快. 第7章读后感: 本章主要说了MSF的原则,MSF团队模型和开发模式,MSF和CMMI.MSF的基本原则是推动信息共享与

构建之法第十一章读后感

本周进行了构建之法的第十一章软件设计与实现的学习: 第十一章主要讲了典型的开发流程,常见的分析和设计方法:ERD,DFD,UML,开发阶段的一些管理方法:每日构建,小强地狱,构建大师: 分析和设计方法包括以文字为主的文档,以图形为主构造的模型,用数学语言的描述,用类自然语言+代码构造的描述,原代码加注释也能描述: 图形模型和分析方法:1表达实体与实体之间的关系如思维导图,实体关系图,Use Case Diagram.2.表达数据的流动.3.表达控制流.4.统一的表达方式. 其他的设计方法包括形式

《构建之法》6-7章读后感

第六章:  “敏捷流程”这个词首先脑子里想的是快速,敏捷,有效率的流程.看完第六章,书中详细的介绍了“敏捷流程”,原来“敏捷流程” 是指价值观和方法论的集合.例如流程.流程的问题和解法等,而作为一个敏捷的团队又应该怎么做.敏捷不是万能,有时候也会出现很大的错误像用敏捷的方法开发登月火箭控制程序,挂了很多宇航员.这时候就要求不同的思想. 敏捷开发以用户的需求进化为核心,采用迭代.循序渐进的方法进行软件开发.很需要技术能力和交流能力的,我们要在实践中学会根据我们每个人的能力分配给每个人不同的任务已保

【软件工程】《构建之法》6-7章读后感

书中第六章主要讲了敏捷流程,主要包括了三大步骤:第一步,找出完成产品需要做的事情——Product Backlog:第二步,决定当前的冲刺(Sprint)需要解决的事情——Sprint Backlog:第三步,冲刺(Sprint). 敏捷开发以用户的需求进化为核心,采用迭代.循序渐进的方法进行软件开发.很需要技术能力和交流能力的,我们要在实践中学会根据我们每个人的能力分配给每个人不同的任务已保证能够取得更高的效率. 第七章讲到了微软公司的MSF基本原则,MSF微软解决方案框架,其实也是一个方法论

构建之法第六章、第七章观后感

第六章 敏捷流程 敏捷流程 “敏捷流程”是一系列价值观的方法论的集合.那么什么敏捷?敏捷是一种一人为核心.迭代.循环渐进的开发方法.是拥抱变化的开发流程. 敏捷开发的原则:    1.尽早并持续地交付有价值的软件以满足顾客需求. 2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势. 3.经常发布可用的软件,发布间隔可用从几周到几个月,能短则短. 4.业务人员和开发人员在项目开发过程中应该每天共同工作. 5.以有进取心的人为项目核心,充分支持信任他们. 6.无论团队内外,面对面的交流始

构建之法前三章读后感

一. 软件作为一个产品,在提供用户使用前经历了许多工序,我们用工程的方式将开发软件的工序,过程加以工程化,系统化.成立了一套完整的体系后,有利于帮助我们开发软件,乃至于大型的系统. 软件具有一定的特殊性,使得软件工程师们做开发提升了一定的难度,但软件工程有助于软件系统的开发,帮助工程师们设计,构建,测试和维护软件.所以,软件工程的最终目的是帮助工程师们创造“足够好”的软件,提高软件的质量,用户满意度,可靠性,可维护性等. 第一章问题:怎么才算是一个真正的软件工程师? 二.   一个优秀的软件,通