第2章 传统与敏捷方法论

2.1  传统泛瀑布软件开发模式

2.1.1  瀑布模式

1.瀑布模式简介

2.瀑布模式特色

3.瀑布模式缺点

2.1.2  渐增模式

1.渐增模式简介

2.渐增模式特色

3.渐增模式缺点

2.1.3  雏形模式

1.雏形模式简介

2.雏形模式特色

3.雏形模式缺点

2.1.4  螺旋模式

1.螺旋模式简介

2.螺旋模式特色

3.螺旋模式缺点

2.1.5  统一开发过程模式

1.RUP模式简介

2.RUP模式特色

3.RUP模式缺点

2.2  敏捷方法论

2.2.1  Scrum

1.Scrum定义

(1).轻量的(Lightweight)

(2).简单易懂(Simple to Understand)

(3).难以精通(Difficult to Master)

2.Scrum理论

(1).透明(Transparency)

(2).检视(Inspection)

(3).调整(Adaptation)

3.Scrum基本价值观

(1).专注(Focus)

(2).尊重(Respect)

(3).承诺(Commitment)

(4).勇气(Courage)

(5).公开(Openness)

4.Scrum团队

(1).开发团队(Development Team)

(2).Scrum大师(Scrum Master)

(3).产品负责人(Product Owner,PO)

5.Scrum过程

6.Scrum仪式

(1).冲刺规划(Sprint Planning)

(2).每日Scrum(Daily Scrum)

(3).冲刺审查(Sprint Review)

(4).冲刺回顾(Sprint Retrospective)

7.Scrum的产出

(1).产品待办列表(Product Backlog)

(2).冲刺待办列表(Sprint Backlog)

(3).可交付的增量成果(Incremental Deliverable)

(4).燃尽图(Burn Down Chart)

2.2.2  XP

1.XP的13个实践

(1).全队(Whole Team)

(2).规划游戏(Planning Game)

(3).小的发布(Small Release)

(4).客户测试(Customer Test)

(5).编程标准(Coding Standard)

(6).程序代码共同拥有(Collective Code Ownership)

(7).持续集成(Continuous Integration)

(8).隐喻(Metaphor)

(9).持续步伐(Sustainable Pace)

(10).测试驱动(Test-driven Development)

(11).结对编程(Pair Programming)

(12).简单设计(Simple Design)

(13).重构(Refactoring)

2.XP团队队员

(1).程序员(Programmer)

(2).测试员(Tester)

(3).教练(Coach)

(4).客户(Customer)

2.2.3  精益

1.精益的7原则

(1).消除浪费(Eliminate Waste)

(2).强化学习(Amplify Learning)

(3).尽可能晚做决定(Decide as Late as Possible)

(4).尽可能尽快交付(Deliver as Fast as Possible)

(5).授权团队(Empower the Team)

(6).建构完整性(Build Integrity in)

(7).着眼整体(See the Whole)

2.2.4  看板

1.看板方法的主要原则

(1).从既有过程开始(Start with Existing Process)

(2).同意增量渐进的改变(Agree to Pursue Incremental,Evolutionary Change)

(3).尊重当前角色的头衔和职责(Respect the Current Process "Role" Responsibilities and Titles)

(4).鼓励各层级的领导行为(Leadership at all Levels)

2.看板方法的核心价值

(1).尊重

(2).勇气

(3).专注

(4).沟通与协同合作

(5).整体与系统化的改变

3.看板实战

(1).工作过程可视化(Visualize)

(2).限制进行中的工作(Limit Work in Progress,Limit WIP)

(3).管理流(Manage Flow)

(4).提供明确的政策(Make Policies Explicit)

(5).落实反馈循环(Implement Product-feedback Loop)

(6).根据经验改善协同合作(Improve Collaboratively,Evolve Experimentally Using Models and the Scientific Method)

2.2.5  动态系统开发方法

1.DSDM团队成员必须决定的事

(1).必要的(Musts)。

(2).应该要的(Shoulds)。

(3).可以要的(Coulds)。

(4).不要的(Won‘t Have)。

2.DSDM团队的核心原则

(1).用户的积极参与对项目至关重要。

(2).团队必须有权作出决定。

(3).团队必须专注于频繁的交付产品。

(4).已批准的交付产品必须都符合验收标准。

(5).必须以迭代的方式进行,且每个迭代都有增量产品。

(6).开发过程中,任何改变都必须可复原。

(7).产品需求是站在高阶思维,不是低阶的改变。

(8).全声明周期都要进行产品测试。

(9).团队经由协同合作来沟通。

2.2.6  功能驱动开发模式

杰夫?德?卢卡,提出功能驱动开发(FDD),产品功能都是在以两周为一个迭代的周期交付,并专注于下列工作:

(1).创建模型。与客户初步沟通后,确定项目范畴,并建立模型。

(2).开发功能列表。以相同的样板描述要开发的功能。

2.2.7  水晶家族

1.水晶家族的价值观

(1).高包容性(High Tolerance)。

(2).专注于人和沟通。

2.水晶家族的适用规则

(1).用渐进式开发,最长不要超过4个月。

(2).项目前后都要举办检讨会议,也可以在期中增加一次检讨会议。

2.2.8  精益与敏捷的关系

2.3  通用敏捷框架

2.3.1  敏捷项目管理模式结构

吉姆?海史密斯,提出敏捷项目管理模式结构(Agile Project Management Model Structure,APM),包括5个阶段:

(1).构想(Envision)

(2).推测(Speculate)

(3).探索(Explore)

(4).调整(Adapt)

2.3.2  敏捷通用过程

迈克?格里菲斯,提出的敏捷通用过程(Agile Unified Process,AUP),将敏捷开发分为5个阶段:

(1).可行性研究(Feasibility)

(2).启动(Initiation)

(3).发布规划(Release Planning)

(4).迭代(Inside Iteration)

  (5).收尾(Close Out)

时间: 2024-10-27 08:20:58

第2章 传统与敏捷方法论的相关文章

传统瀑布式&敏捷开发

---传统瀑布式 瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求.分析.设计.编码.测试的步骤顺序进行. 步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等. 瀑布式的主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂. 瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的. 有论文统计他是造成70%软件开发失败的原因. 大体分为这几个阶段:需求分析.设计.编码.测试.维护. ---敏捷开发 敏捷

第三章 传统加密技术

1 对称加密模型 对称加密防范的五个基本成分: 明文:原始的消息或是数据,是算法的输入 加密算法:加密算法对明文进行各种代替和变化 密钥:加密算法的输入,密钥独立于明文和算法,算法根据所用的特定密钥产生不同的输出 密文:算法的输入 解密算法:是加密算法的逆运算.输入密文和密钥,输出原始明文. 传统密码的安全使用满足如下两个要求: 机密算法必须足够强:即使对方拥有一定数量的密文和产生这些秘文的明文,他也不能破译密文或是发现密钥 发送者和接受者必须在某种安全模式下获得密钥并且必须保护密钥的安全. 对

敏捷项目管理:基础知识与应用实务 目录

拜读许秀影博士的<敏捷项目管理:基础知识与应用实务>一书,收获满满的,干货满满的,无论是对传统项目管理还是对互联网项目管理,都有了较深入的理解.基于对本书的阅读和摘录,为了系统的了解该书相关知识,整理了以下目录: <敏捷项目管理架构(APMF)> <第1章 敏捷思维—“互联网+”知识工作者必备的DNA> <第2章 传统与敏捷方法论> <第3章 敏捷项目管理概述> <第4章 立项与项目启动> <第5章 发布循环> <第

敏捷软件工程和传统软件工程的比较

敏捷软件工程和传统软件工程比较 (注:博文中加粗的正文部分为引用部分) 1.引言 敏捷软件开发从被提出之后就收到了广泛的关注,其从传统开发中剥离开自成一体,逐渐占据软件工程学界的半壁江山,与传统软件开发分庭抗礼.在长期的软件工程发展中逐步形成敏捷型和传统型软件工程相辅相成,并渐渐被软件开发团体认可并运用于实际中. 2.步步为营--传统型软件工程 传统型软件开发是基于"瀑布模型"的开发方式,以软件架构为核心,采用结构化设计以及分析方法将软件生命划分期限,并且开发进度按照从上而下的顺序相互

敏捷软件开发与传统软件工程——因果篇

因--差异之源 近来秋将尽,京中阴霾好几日不见好转,更有几天雨水扰人心烦.幸得一日周末,又逢雨过天晴,秋高气爽,捡得几番文笔来细述敏捷软件开发与传统软件工程之异同. 从字面看来,二者无非是"敏捷"与"传统"一词之差.然而这两个词又同属修饰之词,因此就这两个词之差自然就是两种开发方法的差别所在. 敏捷一词,自然是好理解.正如众人所云如游侠身手之敏捷,为称赞游侠反映之迅速,应对变化之机敏.此处用以修饰软件开发,我们亦可套用迅速应变之意,也就是在软件开发过程中能迅速应对需

传统开发模型vs敏捷开发模型——过程模型的变革

一.概念框架 在了解一个新概念的时候,最好的方法就是把它插入到原有的概念体系中.在不仅有助于对概念的记忆,更利于深刻地认识概念的本质.精髓.下图说明了"敏捷开发"在软件工程理论体系中的位置. 为什么需要软件工程?很简单,为了让我们更好地生产软件.这里的"好"包含多重含义,有成本上的"好".维护上的"好"等等.但是我们知道,不可能坐着想"我要写好软件",然后就软件就能写好了.我们需要一套系统化.理论化.工程化

敏捷21天打卡-敏捷项目管理(终章)

软件项目管理的两大主流管理模式:传统项目管理(预测型项目管理).敏捷项目管理: 传统项目管理(预测型项目管理):瀑布式.部分迭代开发模式,要求在项目一开始,需求足够明确.文档足够规范.迭代过程需求变更越频繁,其对项目造成的遭难往往越大.相信很多IT团队都尝试过,这里不赘述. 敏捷项目管理作为新兴的项目管理模式,简化了传统项目的流程,从繁琐的流程和详尽的文档中解脱出来.但并不代表敏捷不做计划,有很多人的观念“敏捷不做计划”这是错误,否“probacklog.scrum.看板.燃起图.燃尽图.用户故

构建之法5.5-6-7章观后感

第5.3章,讲了一下软件工程的一些模型,有瀑模型.螺旋模型等 第6章,讲敏捷流程,敏捷流程” 是指价值观和方法论的集合. 第7章,msf,没有像敏捷那样搞一个宣言,但是它也是有一套思想框架--9条基本原则.MSF团队模型,产品管理.项目管理.开发.发布管理.测试.用户体验,共同推演,交流.最终产生一个大家都接受的产品.MSF过程模型,是从传统的软件开发瀑布模型和螺旋模型发展而来的,它把瀑布模型基于里程碑的规划优势与螺旋模型中增量迭代的长处结合起来. MSF过程模型的基本元素是阶段和里程碑.还讲了

Project Management: 敏捷开发纵横谈

摘要:在IT界中,“敏捷”是一个很酷的词汇,“敏捷”的相关理论可谓铺天盖地.“敏捷”一词实质没有统一定义,各家有自家的说法,本教程将让你了解“敏捷”的来龙去脉,抓住“敏捷”本质,并能在工作中实践“敏捷”. 特别声明:如需转载此文,请给出指向本网站的连接,如下:作者:张传波摘自:http://www.umlonline.cn如不能按此要求,请不要转载此文. 大纲:“敏捷”陷阱为什么会有“敏捷”这个说法?极限编程敏捷开发RUP敏捷开发的实质是什么?如何才能敏捷起来? 正文: “敏捷”陷阱 小甲想到某