敏捷项目管理框架 框架应用领域描述特性瀑布式项目管理串行的开发流程:需求定义、设计、开发、测试和部署。对于需求动态变化的项目不适用要求有前期的充分设计(big up-front design,BUFD)。通常依赖于项目的初始预期,如果发生变更,则通过严格的变更管理流程来加以修正Scrum项目管理和开发一种以最少的文档和高度的交互性来进行项目管理的框架。最为流行的一种敏捷框架每天举行不超过15分钟的scrum例会,让团队成员进行工作沟通。
每个成员回答三个问题:昨天完成了什么?今天预计的进展?当前的困难所在?极限编程(XP)开发一种编程方法,适用于很多敏捷模式结对编程:两名开发人员一起进行开发。已……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
敏捷项目管理框架
框架 | 应用领域 | 描述 | 特性 |
瀑布式 | 项目管理 | 串行的开发流程:需求定义、设计、开发、测试和部署。对于需求动态变化的项目不适用 | 要求有前期的充分设计(big up-front design,BUFD)。通常依赖于项目的初始预期,如果发生变更,则通过严格的变更管理流程来加以修正 |
Scrum | 项目管理和开发 | 一种以最少的文档和高度的交互性来进行项目管理的框架。最为流行的一种敏捷框架 | 每天举行不超过15分钟的scrum例会,让团队成员进行工作沟通。每个成员回答三个问题:昨天完成了什么?今天预计的进展?当前的困难所在? |
极限编程(XP) | 开发 | 一种编程方法,适用于很多敏捷模式 | 结对编程:两名开发人员一起进行开发。已经被证明是行之有效的,尤其在两个都是新手的情况下 |
Crystal Clear | 项目管理和开发 | 针对团队规模和项目风险等动态因素而设计的框架集合 | 根据团队规模和项目风险的不同,定义多重管理级别 |
自适应软件开发(Adaptive software development) | 一种思路 | 软件应该像产品一样通过思考、协作和学习的循环来持续改进和优化 | 一种全局的指导思想,几乎在所有敏捷框架中都有体现 |
功能驱动的设计(feature-driven design) | 项目构架 | 根据功能来进行系统建模:开发整体模型;编写功能列表;基于功能进行规划、设计和实现 | 根据功能来进行项目分解,然后进行增量式构建 |
测试驱动的设计(test-driven design) | 开发和项目构架 | 先写测试用例,针对用例编写最少的代码。同样能够用于项目构建时的高级测试,或者用于单元测试时的底层测试 | 针对实现的正确与否编写测试用例,然后以最少的代码来通过这些测试 |
动态系统开发方法(Dynamic Systems Development Method,DSDM) | 项目管理 | 迭代式的瀑布模式,在欧洲非常流行。大致可划分为三个阶段:项目准备期、项目中和收尾阶段。有四个步骤:学习(技术可能性和商务事宜)、功能建模、设计和实现、应用。在每个步骤中,团队所使用的交付方式可能不同。 | 偏重于时间和预算的控制,可以允许需求的变更 |
敏捷项目管理术语
迭代(Iteration):多个固定长度的时间区间,每个区间内完成某项目分块的创建和交付
敏捷(Agile):适应动态变化的能力
发布(Release):能够向用户交付的软件版本
产品积压(Product backlog):由product owner创建的客户需求列表
项目积压(Project backlog):由product owner或者project leadership就项目范围所定义的事项列表
迭代积压(Iteration backlog):一个任务列表,说明了团队在本次sprint中应该完成的工作
叙述(Story):敏捷项目的需求简述,以便使成员能够把注意力集中在客户及其需求上
叙述卡(Story card):用于提醒客户代表和开发人员对相应事项进行讨论并添加更多细节,而不是为了进行需求的深层次描述。通常是3x5的卡片形式,如果空间不够的话,那就说明你加入的细节太多了。
叙事(Epic or epic story):特性的总览描述,由此再细分成为多个story card。
节点(Points):评估不同规模(这是关键点)工作的方法。尽管可以根据其他因素来评估,但是通常用的方法是以规模、复杂度和工作的不确定性为依据。Points并不等同于小时数,后者应该是以points和velocity为变量的函数。也许不同的团队对于同一工作的评估会有极大的差别,但最重要的就是在评估时不要背离平时的方式。
比如,一个团队评估某项工作的points是8,能够在两个礼拜内完成,而该团队的velocity是8。另一个团队评估得出的points是21,同样也是在两个礼拜内能够完成,该团队的velocity是21。可见,尽管两个团队得出的points不一样(8和21),但是它们相应的velocity是和points成比例的。
Sprint:Scrum项目中的一个iteration。
Daily scrum:一个不超过15分钟的每日例会,在会上团队成员只回答三个问题:昨天完成了什么?今天预计完成什么?现在的困难是什么?会议的焦点是承诺和各自工作的相关性。
Time box:一段固定的时间。敏捷实践者用time box来控制所讨论细节的数量。对讨论进行时间限定可以聚焦团队的注意力,防止思维发散和无关话题。
Velocity:团队在特定时间内能够完成的工作量。Velocity随团队不同而变化,如果其成员发生了变动,那么相应的velocity就必须重新计算。而且,增加团队成员并不一定意味着velocity的上升。实际上,根据研究表明(Brooks' law),在项目后期加入人手将会拖慢工作进度。
相关推荐
-
ESI国际公司收购敏捷项目管理培训资料库
ESI 国际公司今天宣布,收购位于美国内布拉斯加州奥马哈的Agile Transformation公司旗下的敏捷项目管理/发展内容综合资料库。这项收购的条款细则尚未披露。
-
敏捷项目的质量保证
很难准确说明敏捷项目中的质量保证工作会有哪些改变,但是我们能够从敏捷的原则和开发方式中得到几个有用的提示。
-
敏捷项目管理案例经验
项目管理至少是新产品开发的项目管理呼唤变革。但是变成什么样呢?需要变得更加迅速、更加灵活、更加主动地回应客户要求。敏捷项目管理正好满足了这种转换需要。
-
ESI国际公司携手国家外专局联合主办项目管理高端讲座
ESI国际公司近日与国家外专局共同在京举办了2012年中国项目管理国际高端交流系列活动——项目管理高端讲座,并与参会代表分享ESI在项目管理领域的真知灼见。