构建之法第五周感想 敏捷流程和MSF

这周我学习的是敏捷流程和MSF的知识。敏捷流程是一系列价值观和方法论的集合。敏捷开发的原则是:1.尽早并持续交付有价值的软件以满足顾客的需求2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势。敏捷流程的步骤是:第一步,找出完成产品需要做的事;第二步,决定当前的冲刺需要做的事情;第三部,冲刺;第四部,得到软件的一个增量版本;第四步,放松一下,总结上一次的经验教训,争取下一次做的更好。所以敏捷流程的经验教训是:敏捷宣言表明的是一些优先级,不必当作教条来争论;在复杂的项目里,要让一线团队成员做决定;不要和管理层谈流程,它们只关心结果。

MSF即微软解决方案框架,也就是微软推荐的软件开发方法,MSF基本原则:推动信息共享与沟通,为共同的远景而工作,充分授权和信任,各司其职对项目共同负责,重视商业价值提供渐进的价值,保持敏捷预期和适应变化、,投资质量,学习所有的经验,与顾客合作。在MSF团队模型中,任何技术项目都必须达到特定的关键质量目标,才能够被认为是成功的项目。任何一个角色无法实现其目标,都将危及整个项目。

时间: 2024-12-29 09:31:59

构建之法第五周感想 敏捷流程和MSF的相关文章

四渎《构建之法》——计划估计、敏捷流程、项目经理和用户场景

本周再次打开<构建之法>,这次我阅读时重点在于学习敏捷流程.项目经理和用户场景等相对较为宏观的内容. 第六章开篇即简单地介绍了敏捷开发的流程:Product Backlog->Sprint Backlog->Sprint->软件的增量发布.同时提出了一些敏捷开发的特色之处:团队成员自己主导任务的估计和分配,使其能动性得到较大的发挥:通过每日"例"会进行面对面的交流,报告工作进度.今日要工作的内容.遇见的问题:通过燃尽图或看版图展现项目进度.这是一种和我们之

构建之法(第六章 敏捷流程)

第六章主要讲了    1.1敏捷流程及其原则,Backlog,Burn-down,Sprint,Scrum方法论    1.2什么时候选择敏捷的开发方法,什么时候选择其他方法.   1.敏捷的流程:"敏捷流程"是一系列价值观和方法的集合.    1.1敏捷开发的原则: 1. 尽早并持续地交付有价值的软件以满足顾客需求 2. 敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3. 经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4. 业务人员和开发人员在项目开发过程中

构建之法第六周感想 需求分析

这周我学习的是需求分析.软件团队通过以下几个步骤找到软件需求:获取和引导需求:分析和定义需求:验证需求:在软件产品的生命周期中管理需求.而软件的需求也分为几类:对产品功能性的需求,对产品开发过程的需求,非功能性需求,综合需求.软件产品的利益相关者有用户.顾客.市场分析者.监管机构.系统.软件团队.获取用户需求即用户调研,用户调研可以通过焦点小组方法,找到一群目标用户的代表加上项目的利益相关者来讨论用户想要什么.:深入面谈,通过详细的面谈,广泛而深入地了解用户背景.心理.需求等,效果取决于主持面谈

构建之法 第五周

本章为团队和流程,主要介绍了典型的软件团队模式和开发流程以及它们的优缺点.TSP.MVP.MBP.RUP. 团队有以下共同特点:有一致的集体目标,团队要一起完成这目标:一个团队的成员不一定要同时工作,例如接力跑:团队成员有各自的分工,互相依赖合作,共同完成任务. 软件团队的模式:1.主治医师模式:这样的软件团队中有首席程序员,他负责处理主要模块的设计和编码,其他成员从各种角度支持他的工作(后备程序员.系统管理员.工具开发.编程语言专家.业务专家).2.明星模式:主治医师模式运用到极点,可以退化为

构建之法第八周感想 典型用户和场景

在产品的开发过程中,经常需要描述一组典型的用户.典型用户不再是一个抽象的概念,而应该是一个活生生的人物.一个典型用户往往描述了一组用户的典型技巧.能力.需要.想法.工作习惯和工作环境.典型用户的模板可以包括名字.年龄和收入.典型场景.工作情况.定义完典型用户后,不能开始写程序,因为典型用户只是设想,我们还要和典型用户的代表交流,理解用户,理解他们的工作方式和需要,然后再修改,细化典型用户.当完善了典型用户的定义后,就要进入创立场景阶段,创立场景就是我们深入理解用户需求的过程.对于每一个目标,列出

构建之法 第五章 团队和流程

典型的团队开发模式和流程,完全是新的内容:涉及到更多的术语和有意思的策略性东西 1.团队模式[我比较认可的] 主治医师模式 由首席程序员(相当于首席医生)负责整个工程,周围人员各司其职,配合支持中心人物的工作: [我认为这种模式适合于有着杰出程序工程师的规模略小的团队] 社区模式 我非常心水的linux社区就是最大的成功案例之一. 社区并不意味着"随意",而是有着严格的复审和质量控制 交响乐团模式 [不适用于创新型的项目,反而是对于稳定的.种在执行的项目的效率比较高] 门类齐全,各种任

构建之法第五章团队和流程

1.团队模式和团队的开发模式有什么关系? 答:    首先我来解释一下这两个名词: 我查资料了解了一下,团队模式,更偏向于多人合作的那种,而且我理解的"团队"会是一种多人合作的情况下,长期磨合后的一个组织,他们是相互了解的,是拥有巨大的默契存在的. 对于团队的开发模式我并没有查到具体的解释,但对于开发模式,是有查到几种开发模式,比如瀑布开发模式.快速应用开发模式等等,我们在其他的课上有学过这些模式,所以我在这里认为开发模式是更偏向于后边的"模式"两个字的,更注重方法

通读构建之法提出五个问题

我是通过`软件工程课`认识这本书的.老师要求读一遍构建之法.自己偷懒,其实没读完,大致翻了翻.翻看粗读后,初步有一下感受: 1. 这不是一本传统的教材,没那么多晦涩的概念. 2. 排版挺好看的,文章穿插图表,很精致. 3.语言幽默好懂. 在没读此书之前,只是觉得为什么软件工程里还会有这么多方法,软件工程不就是一些人合作做个项目就好了嘛?但现实远远没有想象的那么简单.<构建之法>一书一共有17章.每个章节讲述不同的重点.构建之法的每一章都是独立的子章节,并且涵盖了测试.项目经理.开发人员.用户体

构建之法---初识篇(团队、流程和敏捷流程)

这周主要是看了第五章和第六章,主要内容包括团队和流程以及敏捷流程. 首先来说什么是团队?团队有一个集体的目标,团队要一起完成这个目标,一个团队的人,不一定要同时工作,团队成员有各自的分工,互相依赖合作,共同完成任务.此外,团队的模式也是多种多样的,我觉得不管什么样的流程,只要有一个合理的机制,有一个合理的规则就是可以的,我觉得还是要有一个人去领导整个团队,其实对于现在的我来说,我更喜欢主治医师模式.但是必须保证大家不是打酱油的,要每个人都有贡献. 关于开发流程,瀑布模型是单项的,不可逆的生产过程