《构建之法》第六、七章学习总结

第六章讲的是关于敏捷流程的知识。在第一节中,对敏捷流程进行了简单的介绍——产品backlog、sprint backlog、sprint、软件的增量发布;第二节介绍了使用敏捷流程时可能碰到的一些问题和相应的解决方法;第三节则讲到一个敏捷的团队要做到自主管理、自我组织、多功能型;第四节则对敏捷流程进行了总结和评价并介绍了一些经验教训;第五节通过问答形式再次向我们详细地介绍了关于敏捷流程的一些知识点。

第七章介绍的是微软解决方案框架(MSF)。第一节介绍的是MSF的简史;第二节则介绍了MSF的基本原则:推动信息共享与沟通、为共同的远景工作、充分授权和信任等等;第三节和第四节分别介绍了MSF团队模型和过程模型;第五节简单介绍了在Visu Studio TFS中,MSF演化为两个分支——敏捷开发模式和CMMI开发模式以及MSF对他们的支持。

时间: 2024-08-17 11:41:44

《构建之法》第六、七章学习总结的相关文章

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

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

第六七章学习体会-----(第六次)

在这周我看了第六章敏捷流程跟第七章MSF.并有了以下学习总结. 敏捷这个词听起来就是反应灵敏迅速而有效,而在软件按工程里,敏捷不同于现有做法之处在于,敏捷的价值观和流程是个人和交流.可用的软件.与客户合作.响应变化,而现有做法的则是流程和工具.完备的文档.为合同谈判.执行原定计划敏捷的开发原则是尽早并持续交付有价值的软件以满足顾客需求.只有不断关注技术和设计,才能越来越敏捷.只有能自我管理的团队才能创造优秀的架构.需求和设计.敏捷开发的原则很多,其中印象最深的就是"经常发布可用的软件,发布间隔

构建之法第六七八章

第六章 敏捷流程 敏捷流程开发原则 1.尽早并持续的交付有价值的软件以满足顾客需求 2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4.业务人员和开发人员在项目开发过程中应该每天共同工作 5.以有进取心的人为项目核心,充分支持信任他们 6.无论团队内外,面对面的交流始终是最有效的沟通方式 7.可用的软件是衡量项目进展的主要指标 8.敏捷流程应能保持可持续的发展.领导.团队和用户应该能按照目前的步骤持续合作下去 9.只有

2018-2019-1 20189215 《构建之法》第三章学习总结

第3章 软件工程师的成长 教材学习内容总结 软件工程的术语中,单个的成员叫做Individual Contributor(IC). 软件开发流程不光指团队的流程,还包括个人开发流程,因为软件团队是由个人组成的,个人在团队中有独立的流程 IC在团队中的流程 通过交流.实验.快速原型等方法,理解问题.需求或任务 提出多种解决办法并估计工作量(其中包括寻找以前的解决方案,因为有很多工作是重复性的) 与相关角色交流解决问题的提案,决定一个可行的方案 执行,想法变成代码 合作,测试实现方案,修复BUG 发

构建之法(第七章 MSF)

第六章主要讲了 1.MSF的原则,MSF团队模型和开发模式,MSF和CMMI 2.各种软件工程原则的异同,如何在学生团队实施软件工程的原则 1.MSF的基本原则 1.1推动信息共享与沟通 所有信息都保留并公开,讨论要包括所有涉及的角色,决定要公开并告知所有人.当然,对牵涉到技术机密.安全性等信息要采取必要的把握措施. 使用Alert来提醒何事发生了变化:所有的信息都保留并公开,不能删除工作项. 1.2为共同的远景而工作 这个目标必须是明确的,没有二义性. 这个目标不是当前就能达到,必须是通过努力

《构建之法》第十三章学习总结

第十三章的内容是关于各种测试方法和测试的设计方法. 一个软件开发团队统一思想首先要从基本名词解释开始,第一节为我们解释了一些基本名词并进行分类(例:Bug是指软件的缺陷,可以分解为症状(Symptom).程序错误(Fault).根本原因(Root Cause)):在对这些基本名词进行分类时,可以按测试设计的方法分类(分为黑箱和白箱),也可以按测试的目的(分为功能测试和非功能测试)或者测试的时机和作用分类. 在第二节中,详细介绍了各种测试方法--单元测试.代码覆盖率测试.构建验证测试.验收测试..

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

本周的学习当中,我第一次接触到了MSF这个概念,它是微软所推荐的做软件的一种方法.它有9条基本原则,每条原则环环相扣,规划合理,并且并非一成不变,会随着学习而完善,所以可以适用于很多场景.沟通也是这个方法的一个重点,与团队沟通,与客户沟通.这样一个方法很显然也是要依赖于一个强劲的团队的.以下是本周的一些知识点: 一.MSF基本原则 1)推动信息共享与沟通 所有信息都保留并公开,讨论要包括所有涉及的角色,决定要公开并告知所有人.当然,对牵涉到技术机密.安全性等信息要采取必要的把握措施. 2)为共同

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

软件开发过程是痛苦的,但是完成之后并不是就结束了.经历了计划.设计.开发等阶段,达到了代码完成这一目标之后,团队内部还要学会去发现修正已有的缺陷之后才发布.但是我觉得软件的隐藏bug会随着时间的延迟发掘出来更多的.在此之中,我们就需要构造一个会症小组,小组内部成员最好就包括了各个团队的一员,因为不清楚具体的缺陷会发生在哪一块地方,如果需要重写或重构的时候有具体版块负责人在会方便很多.除此之外,我觉得还能进行用户内测,选择一部分用户进行软件测试,之后进行问卷调查,整合问卷调查内容,总结缺点,进行软

构建之法第六章学习心得

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

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

读<构建之法>第七八章有感 今天我读了<构建之法>的第七八章,对MSF模型和开发模式,以及需求分析有了进一步的认识. 其中第七章主要讲了一些MSF方面的知识.MSF是微软公司关于软件开发的方法论——微软解决方案框架,是微软推荐的软件开发方法.而且MSF有自己的基本原则.1>推动信息共享与沟通,这就是说把所有信息保留并公开. 2>为共同的远景而工作,要做到这一点,就要确定一个明确的目标,并且这个目标对成员每天的工作有指导作用 3>充分授权和信任,这就要我们团队成员之