敏捷项目管理模式(第五章)

合集下载

Jira敏捷项目管理工具使用教程

Jira敏捷项目管理工具使用教程

Jira敏捷项目管理工具使用教程第一章:Jira简介Jira是一款流行的敏捷项目管理工具,它被广泛应用于软件开发和项目管理领域。

Jira提供了丰富的功能和灵活的配置选项,可以有效地帮助团队进行任务跟踪、问题管理以及项目进度监控。

本章将对Jira的概念和基本功能进行介绍。

第二章:Jira安装和配置在开始使用Jira之前,我们需要先进行安装和配置。

本章将详细介绍Jira的安装过程,并介绍如何进行必要的配置,包括创建项目、定义问题类型和工作流等。

第三章:Jira项目管理Jira提供了强大的项目管理功能,能够帮助团队跟踪和管理项目进度。

本章将介绍如何创建、分配和跟踪任务,如何使用看板视图来管理工作流程,并讲解如何设置优先级、截止日期、任务关联等功能。

第四章:Jira问题管理问题管理是Jira的核心功能之一,它能够帮助团队有效地记录和解决问题。

本章将介绍如何创建和管理问题,如何设置问题的属性和字段,以及如何进行问题筛选和查询。

第五章:Jira报告与分析Jira提供了丰富的报告和分析功能,能够帮助团队了解项目的进展和问题的状况。

本章将介绍如何生成各类报表,如任务统计报告、团队工作量报告等,并讲解如何使用Jira插件来扩展报告功能。

第六章:Jira集成与扩展Jira可以与其他工具进行集成,扩展其功能。

本章将介绍如何与常见的版本控制工具(如Git)和持续集成工具(如Jenkins)进行集成,以及如何安装和管理Jira插件。

第七章:Jira最佳实践和注意事项在使用Jira的过程中,有一些最佳实践和注意事项需要注意。

本章将总结一些Jira的最佳实践,包括如何组织项目、如何设置权限、如何管理用户等。

第八章:Jira在敏捷开发中的应用Jira是敏捷项目管理方法中常用的工具之一。

本章将介绍如何在Jira中应用敏捷开发方法,如Scrum和Kanban,并讲解如何使用Jira的敏捷看板、迭代和冲刺管理等功能。

结语Jira作为一款强大的敏捷项目管理工具,在项目管理和问题追踪方面有着广泛的应用。

项目管理敏捷化指南

项目管理敏捷化指南

项目管理敏捷化指南随着市场竞争的加剧,企业需要更加敏捷地应对市场变化和客户需求。

因此,敏捷项目管理成为了越来越多企业的选择。

敏捷项目管理是一种以迭代、增量和协作为核心的项目管理方法,它能够帮助企业更快地响应市场变化和客户需求,提高项目交付的质量和效率。

下面是一些敏捷项目管理的指南,可以帮助企业更好地实施敏捷项目管理。

1. 确定项目目标和范围在开始项目之前,需要明确项目的目标和范围。

这可以帮助团队更好地理解项目的需求和目标,从而更好地规划和执行项目。

2. 制定项目计划敏捷项目管理强调迭代和增量,因此需要制定一个可行的项目计划。

这个计划应该包括项目的迭代周期、每个迭代的目标和交付成果等。

3. 建立团队合作敏捷项目管理需要团队成员之间的紧密合作和协作。

因此,需要建立一个团队合作的文化,鼓励团队成员之间的交流和合作。

4. 采用迭代开发模式敏捷项目管理采用迭代开发模式,每个迭代都是一个完整的开发周期。

这种模式可以帮助团队更好地控制项目进度和质量,同时也可以更好地响应客户需求。

5. 采用自组织团队模式敏捷项目管理强调自组织团队模式,即团队成员自主决策和执行任务。

这种模式可以帮助团队更好地适应变化和快速响应客户需求。

6. 采用持续集成和持续交付模式敏捷项目管理强调持续集成和持续交付模式,即在项目开发过程中不断进行集成和交付。

这种模式可以帮助团队更好地控制项目进度和质量,同时也可以更好地响应客户需求。

敏捷项目管理是一种以迭代、增量和协作为核心的项目管理方法,它能够帮助企业更快地响应市场变化和客户需求,提高项目交付的质量和效率。

企业可以根据上述指南,更好地实施敏捷项目管理。

软件工程实践中的敏捷开发与迭代开发模式4

软件工程实践中的敏捷开发与迭代开发模式4
对比传统开发模式的优劣
敏捷开发的优势
快速响应变化的需 求
敏捷开发能够灵活应对客户需 求的变化,提高项目适应性
提高客户满意度
高质量的软件产品
提升团队合作与沟通 效率
通过持续交付高质量软件产品, 满足客户需求
敏捷开发强调持续集成和自动 化测试,确保软件质量
通过每日站会等实践,促进团 队合作与信息流畅
Scrum框架
断的实践来实现。
团队协作与沟通
敏捷团队中的沟通 模式
团队协作中的挑战 与解决方案
协作工具的运用
包括面对面沟通、使用协 作工具进行远程沟通等方

团队成员地域分布、文化 差异等可能导致的挑战, 需要通过沟通和协调解决
团队可以使用Slack、 Microsoft Teams等工具
提高效率
团队绩效评估与优化
软件工程实践中的敏捷开发与迭代开 发模式
制作人: 时间:2024年X月
目 录
第1章 软件工程实践与敏捷开发 第2章 敏捷开发中的用户故事 第3章 敏捷团队与团队协作 第4章 敏捷开发的风险管理 第5章 敏捷开发中的质量保障
第6章 总结与展望
●01
第1章 软件工程实践与敏捷开发
介绍软件工程与敏捷开发
新兴技术和方法
未来可能出现的新技术
挑战应对
面对未来的挑战
结语
感谢观看,如果有任何问题或想要讨论更多 内容,欢迎随时联系我们。
结语补充
在软件工程实践中,敏捷开发与迭代开发模式起着 重要作用。通过本章的学习,我们可以更好地理解 这两种开发模式的优势和应用场景。希望本章内容 能为您的软件开发实践带来启发和帮助。
风险管理与迭代改进
实例分析
持续改进策略

项目管理技术与方法研究及在实际项目中的应用分析

项目管理技术与方法研究及在实际项目中的应用分析

项目管理技术与方法研究及在实际项目中的应用分析第一章:引言作为一种优化资源利用、提高项目成功率的管理方式,项目管理近年来受到越来越广泛的关注。

项目管理技术和方法的不断完善以及在实际项目中的应用不断积累,成为支撑项目管理的核心。

本文将重点探讨项目管理技术和方法的研究现状和实际应用情况,以帮助企业实现在复杂多变的市场环境中对项目进行有效管理。

第二章:项目管理技术和方法的研究现状2.1 传统项目管理方法传统项目管理方法最早起源于20世纪50年代美国,是对制造业的开发和生产过程管理的一个简单延伸。

传统项目管理方法通过明确的计划、固定的工作量和路径、看板式进度控制等方式来管理项目进度和完成质量,并且强调任务和时间的可预测性。

然而,随着信息化和互联网技术的发展,传统项目管理方法在快速变化的市场环境中已经无法满足现代项目管理的需求。

2.2 敏捷项目管理方法敏捷项目管理方法诞生于1990年代的软件工程界,是一种更开放、快速、用户导向的项目管理方式。

敏捷方法注重协作、迭代和让用户参与进来,确保项目团队快速响应变化并及时进行调整,同时强调快速交付高质量的可用成果。

敏捷方法的出现使得项目管理能够更好地适应快速变化的市场环境。

2.3 其他项目管理方法除了传统和敏捷项目管理方法之外,还有一些其他的项目管理方法,如渐进式项目管理方法、精益项目管理方法、六西格玛等。

这些方法各有特点,适用于不同的项目类型。

第三章:项目管理技术和方法在实际项目中的应用分析3.1 项目管理技术和方法在快速变化的市场环境中的应用在快速变化的市场环境中,使用传统项目管理方法的企业会遇到一些困难,如计划的不确定性、需求变化频繁、人员流动等。

因此,此类企业应尝试采取敏捷项目管理方法,通过持续的反馈和改进来快速适应变化,对设定的目标进行评估和逼近,并通过共同探索帮助团队更好地理解项目目标。

3.2 项目管理技术和方法在大型项目中的应用大型项目一般拥有庞大的团队,复杂的管理体系,以及一系列的协调工作。

敏捷开发方法学习与实践指南

敏捷开发方法学习与实践指南

敏捷开发方法学习与实践指南第一章:敏捷开发方法简介1.1 敏捷开发的概念和目标敏捷开发是一种以快速迭代和灵活性为基础的软件开发方法,旨在提高团队效率和客户满意度。

1.2 敏捷开发的优势和适用场景敏捷开发可以帮助团队更好地应对需求变化和市场竞争,适用于复杂、动态和高风险的项目。

第二章:敏捷开发方法的实施步骤2.1 项目准备阶段明确项目目标和范围,确定敏捷开发团队成员,制定项目计划和迭代周期。

2.2 需求管理与分析与客户密切合作,收集和整理需求,制定用户故事,优先级排序和计划发布。

2.3 迭代开发与管理每个迭代周期内,团队完成需求开发、单元测试和集成测试,持续交付可工作软件。

2.4 持续集成与交付团队借助自动化工具和流程,实现软件的频繁集成和交付,及时反馈项目进展和质量问题。

2.5 风险管理与质量保证敏捷开发注重风险管理和质量保证,通过持续集成、自动化测试和代码审查等方式降低项目风险和提高软件质量。

2.6 客户反馈与持续改进在每个迭代周期结束后,团队与客户进行回顾会议,总结经验教训,及时调整和改进工作方式。

第三章:敏捷开发方法的关键实践3.1 Scrum框架介绍Scrum框架的核心概念和实施步骤,包括产品负责人、Scrum团队和Sprint Planning等。

3.2 Extreme Programming (XP)介绍XP在敏捷开发中的应用,包括测试驱动开发(TDD)、持续集成和重构等。

3.3 Kanban方法介绍Kanban方法的原理和实施步骤,通过可视化管理工作流程和限制工作进程来提高团队效率。

3.4 DevOps实践介绍DevOps的核心原则和实施步骤,包括自动化部署、持续集成和持续交付等。

3.5 用户故事和敏捷统计介绍用户故事的编写和管理方法,以及如何使用敏捷统计工具追踪项目进展和团队绩效。

第四章:敏捷开发方法的实践案例分析4.1 互联网项目开发案例分析以某个互联网公司的产品开发为例,详细介绍其采用敏捷开发方法的实践过程、挑战和成果。

实例解析:敏捷开发项目管理五步走

实例解析:敏捷开发项目管理五步走

实例解析:敏捷开发项目管理五步走不少创业公司的产品经理需要兼顾项目经理的工作,并且全职测试角色。

这篇文章讲产品经理如何进行高效的敏捷开发项目管理。

一、背景交代背景,利用公司原有的项目管理方式,产品无法按时上线,产品质量难以保障。

老板决定把项目管理交由产品经理主导,务必保证后续产品的质量并按时上线。

首先,我组织项目组成员总结原有项目管理过程中存在的问题,主要有两点:项目进度不可见,产品经理对项目失去掌控,开发每日进度不可见,老板也不知道大家每天在做什么。

效率低下,项目延期,成本增加。

测试周期与开发周期分离,不能及时有效处理中间开发出现的偏差。

开发实际结果与产品期望结果偏离,质量不过关,开发人员重复工作。

针对以上的问题,结合领导给出的敏捷开发项目管理要求,我对公司的项目开发管理过程进行了重新梳理补充。

最终提出了敏捷开发项目管理5步走的方法,并在后续项目管理过程中得以有效利用。

相比于之前项目管理方式,新的方式把团队工作效率提高30%以上。

以下过程只针对项目开发过程,不包括需求分析,UI设计,原型设计等过程。

这些模块在此之前已经完成。

敏捷开发项目管理过程,主要分5个步骤(以某小程序项目开发为例)。

工时评估,列出功能清单与完成开发工时评估计划排期,列出里程碑计划与开发计划,具体到功能模块责任到人阶段测试,功能模块完成开发,开始阶段测试项目管理过程中需求变更处理完成综合测试,项目上线三、具体步骤1. 工时评估,列出功能清单与完成开发工时评估产品经理梳理好要做产品的功能清单,找项目组对应的开发负责人进行工时评估,评估完成之后找技术主管确认,确认无误,完成工时确定。

此外,测试周期另找测试主管评估即可。

开发工作量评估完成,具体如下图(1.0):(1.0)2. 计划排期,列出里程碑计划与开发计划,具体到功能模块责任到人如何排模块时间点,基于功能清单工作量评估结果,产品定功能模块开发截止时间,与开发人员一起开会确认。

敏捷项目管理(AGILE

敏捷项目管理(AGILE

敏捷项目管理(Agile Project Management,APM)包括4个主要部分:敏捷革命创建的机遇及其对产品开发所带来的影响、推动敏捷项目管理的价值观和原则、具体体现原则和帮助整个组织(不仅仅是项目小组)实现敏捷的具体做法。

第1章,“敏捷革命”,介绍产品(从手机到软件)开发领域中出现的变化以及这些变化如何推动试验成本的降低,从而从根本上改变新产品开发的管理方式。

本章概述了敏捷项目管理的商业目标,以及企业如何适应无序的世界。

第2章~第4章,介绍推动敏捷项目管理的价值观和原则。

一些主要的敏捷价值观在《相互依赖声明》和《敏捷软件开发宣言》中都有明确表述。

本书将其简要概括为:交付价值胜过满足约束、领导团队胜过管理任务和适应变化胜过遵循计划,并分别用一章的内容加以介绍。

第5章~第10章,讲述敏捷项目管理的流程架构及具体做法。

第5章介绍敏捷企业架构(包括项目治理、项目管理、迭代管理、技术措施)和敏捷流程架构(包括构想、推测、探索、适应和结束)。

第6章~第10章定义了敏捷流程架构中每个阶段并讲述其具体做法。

第8章讲述高级发布计划包含一节价值点计算的内容。

第11章,“敏捷项目扩展”,结合实例查证说明如何运用敏捷原则,如何将敏捷项目管理扩展到大型项目和大型团队中。

包括组织层面和产品相关的实践。

第12章,“治理敏捷项目”,以敏捷项目转换到敏捷组织为起始,主要围绕项目管理讨论领导和管理问题,并提出需要把治理从交付活动中剥离出去。

第13章,“超越范围、进度和成本:评估敏捷绩效”,继续把重点放在敏捷组织。

提出了基于范围、进度和成本的评估体系应该改变。

并把第1章中介绍过的敏捷三角形原则当作一种新的评估敏捷绩效的方式进行了详细地查证。

第14章,“可靠的创新”,强调敏捷项目管理如何帮助解决新产品开发的易变本敏捷项目管理(第2版)质,总结敏捷项目经理应该扮演的角色,并提出在实施敏捷项目管理和开发时需要具备的坚定信念和勇气。

Scrum敏捷项目管理介绍

Scrum敏捷项目管理介绍

敏捷看板还可以用于展示风险 和问题,帮助团队更好地应对 和解决潜在问题。
敏捷估算技术
敏捷估算技术是一种估算项目工作量 的方法,可以帮助团队更好地预测和 管理项目进度。
敏捷估算技术还可以用于评估风险和 不确定性,帮助团队更好地应对潜在 问题和挑战。
敏捷估算技术包括故事点、理想时间、 相对估算等,可以帮助团队更好地评 估任务规模和工作量。
跨职能团队(Cross-functional Team):团队成员具有多种技能,可以完成从需求分析、 设计、开发、测试到支持的所有工作。
事件
冲刺(Sprint):一个时间盒, 通常为1到4周,在这个时间段 内,团队会集中精力完成一部分
产品待办事项。
冲刺计划会议(Sprint Planning Meeting):在每个 冲刺开始时举行,讨论这个冲刺
确定迭代周期和冲刺计划
确定项目的迭代周期和每次迭代的冲 刺计划,明确每个迭代的目标和任务。
执行流程
任务分配和每日站会
根据冲刺计划,将任务分配给团队成员,并通过每日站会跟踪任 务进度和解决问题。
开发与迭代
按照迭代周期进行产品开发,不断优化和调整产品待办事项列表, 以满足项目目标和客户需求。
跨职能协作与信息透明
详细描述:造成项目超预算的原因可能包括需求变更频 繁、人力资源成本上升、技术难度预估不足等。为了解 决项目超预算问题,可以采取以下措施 建立预算调整机制,根据实际情况及时调整预算。
优化资源分配,合理利用外部资源降低成本。
项目范围变更
总结词:项目范围变更是敏捷项目管理中不可避免的问 题,可能导致项目进度和预算受到影响。
等角色。
Scrum工具包括Scrum框架、 Scrum指南、Scrum模板等,可
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

本书的第1版重点介绍了敏捷流程架构的几个主要项目阶段。

然而,在过去5年中,敏捷方法已经开始广泛应用于较大型的项目和组织中,因此构建一个较为全面的敏捷企业架构显得尤为必要。

例如,在大型跨国组织中,其项目并非都是敏捷项目,即使都是,某些地区可能使用不同于其他项目的敏捷方法。

一个机构地区用Scrum,一个用极限编程(Extreme Programming,XP),而另一个使用功能驱动开发(Feature Drivern Development,FDD),这种情况一点也不稀奇。

并且,应该鼓励使用这种多样性的方法!因为很有可能的情况是,在中国的项目可以得到Scrum的良好支持(如培训、辅导等),而澳大利亚的项目得到FDD支持会更好些。

敏捷开发的信条之一是适应不同情况。

《相互依赖宣言》的6个原则之一是:通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。

因此,很难在一个跨国组织中,只使用单一的标准化敏捷方法。

然而,使用一个共同的架构,而且能在其中选择各自不同的敏捷方法,对于较大型组织来讲,无疑具有很大的吸引力。

第5章敏捷项目管理模式5.1 敏捷企业架构敏捷企业总体架构如图5-1所示。

投资组合治理层提供一些常见的检查点;项目管理层对各种项目的管理提供指导。

项目管理层和迭代管理层不同,其差异可以洞察运行项目、制定发布计划和日常短期迭代管理的不同。

最后,区分迭代管理层和技术做法层,有助于把核心技术做法融合到几个项目或者迭代管理方法中去。

投资组合治理项目管理迭代代理技术实践图5-1 敏捷企业架构这个结构有利于组织采取混合的敏捷方法,即每层使用不同的敏捷方法,以满足组织的特定需要。

该架构倡导底层(技术实践层)具有较大灵活性,上层(项目管理层)灵活性较小。

这种结构认同没有哪一种敏捷方法适合所有层次。

事实上,组织中使用的所有敏捷方法都是混合型的。

例如,一个组织的项目管理层可能采用APM(和部分PMBOK 的组合),迭代管理层用Scrum, 而在技术层选用XP做法。

通过汲取几种敏捷方法的优点,公司可以构建高效的混合方法,或者可以为组织的不同部分构建几种不同的组合方法。

5.1.1 投资组合治理层大公司拥有数以百计(如果不是数以千计)的项目。

其中,有的敏捷,有的传统;有的使用这种敏捷方法,有的使用另外一种;有的使用敏捷和传统的混合方法。

即使一个组织已经决心向敏捷组织转变,在维期几年的转变期间,将会混合使用各种方法。

主管们需要的就是一个通用的架构,可以用来评估所有项目。

这个架构涉及主管们所关心的主要问题——投资和风险。

主管们想知道项目的价值(及投资回报率)和获取该价值的确定性和不确定性。

他们不会真的关心需求文档是否完成了。

他们想了解项目进程、投资57敏捷项目管理(第2版)和风险。

因此无论项目是什么类型——敏捷或是其他,都需要创建一个管理机制,解决这两个关键的代表项目属性的指标。

第12章将会详细讨论投资组合治理层。

5.1.2 项目管理层许多人认为项目管理即是与核心小组的外围利益相关者打交道,而迭代管理与核心小组的内部利益相关者打交道。

这的确是两者差异的一部分,但只是一半。

另一个很大的不同是一个是管理发布,一个是管理迭代。

一个完整的项目发布计划(见第7章和第8章),涉及构建产品和团队构想、开发项目范围、设定边界和制定全面的功能发布计划。

项目管理还包括与核心小组外围的利益相关者和供应商合作。

因此,项目管理层关注全面的项目/发布活动,协调多功能团队和管理项目外围事件。

除此之外,像风险分析、合同管理等凡是对项目有用的做法,无论敏捷与否,都属于这个管理层的管理范畴。

(这些做法可能来源自美国项目管理协会的PMBK)。

需要指明的是项目管理和迭代管理是可以是同一个领导者,也可以是不同的领导者,取决于项目的大小。

例如,一个有4个团队的大项目可能每个团队有一个迭代经理,整个项目有一个项目经理。

5.1.3 迭代管理层迭代管理层关注每个短期迭代的计划、执行和团队领导。

本章最后一节会概述一下区分迭代和项目管理层的原因,基本上区分的是发布和迭代工作,以及项目内部和外部的管理活动。

5.1.4 技术实践层软件项目中的技术实践,包括从持续集成到结对编程,从测试开发到重构等做法。

硬件项目可能采用一系列工程做法,从电子到机械不等。

虽然本书的重点是其他三层,但是项目有效执行的基础在于技术领域。

在各种各样的组织中,变革技术实践是实施敏捷方法的关键。

例如,持续集成和自动化测试是不能忽略的核心敏捷软件做法。

分离出技术实践层的另外一个原因是,使敏捷项目管理更适合各种项目和产品类型。

尽管我很难做到让电子工程师或者机械工程师准备结对编程,但是事实证明,敏捷58第5章敏捷项目管理模式软件的等值做法在各种产品开发领域都很有价值。

此外,除了硬件项目中可能存在较长时间的迭代外,投资组合治理层、项目管理层和迭代层适用于想要把敏捷方法应用于非软件项目的公司。

5.2 敏捷交付架构流程也许不如人那么重要,但它绝非不重要。

在敏捷圈内,流程被指责为静止的、常规的和难以改变的。

就流程本身而言,不应该是负面的,它必须同企业目标联系起来。

如果目标是重复性的制造,那么常规性流程是完全合理的;而如果目标是可靠的创新,则流程架构必须是有组织的、灵活的和容易适应的。

敏捷交付架构需要体现前几章描述的原则,除了支持企业目标之外,该架构还需要:●支持构想、探索、适应文化;●支持自我组织、自律的团队;●根据项目的不确定性程度,尽量提高可靠性和连贯性;●保持灵活和易于适应;●支持流程的透明化;●合并知识;●囊括支持各个阶段的做法;●提供管理检查点。

敏捷项目管理模式的结构:构想—推测—探索—适应—结束,重点在交付(执行)和适应(如图5-2所示)。

它基于Adaptive Software Development(海史密斯,2000)一书提出的一个模式。

59敏捷项目管理(第2版)60构想故事清单推测构想适应探索发布计划结束适应性行动最终产品完成的故事图5-2 敏捷项目管理交付架构该架构中各阶段的命名与传统的阶段命名(如开始、计划、定义、设计、构建、测试)完全不同,其意义重大。

第一,“构想”代替较传统的“开始”,指出构想的重要性;第二,推测阶段代替计划阶段。

每个词都传达一定的意义,而各个意义来自他们长期的系统用法。

“计划”一词已经与预测和相对确定性相关联,而“推测”表示未来是不确定的。

许多面临不确定未来的项目经理仍在试图“计划”排除该不确定性。

我们必须学会推测和适应,而不是计划和建造。

第三,敏捷项目管理模式用探索代替通常的设计、构建和测试阶段。

以迭代交付的方式,很明显探索是非线性的、并存的、非瀑布式的模式。

在推测阶段提出的问题需要“探索”。

鉴于结果不能完全预测,推测暗示着灵活性的需求基于现实。

敏捷项目管理模式强调执行以及探索性而非确定性。

实施敏捷项目管理的团队密切关注构想、监控信息,从而适应当前情况,这就是适应阶段。

最后,敏捷项目管理模式以结束阶段收尾,这个阶段的主要目标是传递知识,当然它也是一个庆典。

总之,敏捷项目管理的5个阶段是:●构想:确定产品构想、项目目标和控制要素、项目社团以及团队如何共同工作。

●推测:制定基于性能和/或功能的发布计划,确保交付构想的产品。

●探索:在短期内计划和提供它经测试的功能,不断致力于减少项目风险和不第5章 敏捷项目管理模式61确定性。

●适应:审核提交的结果、当前情况以及团队的绩效,必要时做出调整。

● 结束:终止项目、交流主要的学习成果并庆祝。

图5-2展示了所有的阶段和工作流程;图5-3表示的是两个主要的合作周期(构想周期和探索周期)中的相同活动。

构想周期包括构想和推测阶段(产品构想、项目目标和约束、发布计划);而探索周期包括探索和适应阶段(迭代计划、开发和审核/调整)。

图5-3强调周期而不是流程,说明在整个项目中,全部或者部分构想周期可能会多次执行。

例如,可能(应该)每次或者每两次迭代就需要构建一个修改后的发布计划。

在费时较长的项目中,可能会定期修正整个构想周期的结果。

构想周期产品构想 发布计划 项目范围 和界限 审查和适应 开发产品:模拟、模型、实际产品、工程面包板、关键中间件 迭代计划探索周期图5-3 敏捷项目管理的构想和探索周期5.2.1 阶段:构想构想阶段为客户和项目团队创建构想,该构想包括什么、谁提供提供和如何提供。

如果没有构想,其他的项目启动活动都是无用之功。

用商业用语来说,构想是项目早期“成功的关键因素”。

首先,我们需要构想提供什么,即产品及项目范围构想;其次,我们需要构想参与者都有谁:客户、产品经理、项目团队成员和利益相关方组成的社团;最后,项目团队成员必须构想他们打算如何共同工作。

5.2.2 阶段:推测“推测”一词首先让人们想到的是不计后果的冒险,但实际上字典上它的定义是“根敏捷项目管理(第2版)据不完全的事实或者信息猜测某事”,这正是这个阶段要做的事情1。

“计划”一词具有确定和预测的含义,至少对于探索性项目来说,计划的更有用的定义是基于不完全的信息推测或者猜测。

肯·德科尔评论道:“人们认为制定计划就是引进确定性,但事实并非如此。

他们带来的只不过是衡量绩效的东西,而一旦这个衡量尺度与现实出现偏差,他们又不能重新计划。

”敏捷项目管理包括的构想和探索比计划和执行要多,它迫使我们面对这样的现实:不稳定的商业环境和变化多端的产品开发环境。

推测阶段包括:●收集初始的、广泛的产品要求;●将工作量定义为一个产品功能清单;●制订一个迭代的、基于功能的交付计划;●把风险降低策略纳入计划;●估计项目成本,并生成其他必要的行政管理和财务信息。

5.2.3 阶段:探索探索阶段交付产品功能。

从项目管理的角度看,这个阶段有3个关键的活动区域:第一,通过管理工作量和使用适当的技术方法和风险降低策略,按计划交付产品功能;第二,建立协作的、自我组织的项目社团,这是每个人的责任但需要由项目经理和迭代领导者推动;第三,管理团队与客户、产品经理和其他利益相关方的相互交流。

5.2.4 阶段:适应控制和纠正是这个周期阶段常用的术语。

计划制订了,结果监控了,纠正也完成了:这个流程意味着计划是正确的,而如果实际结果与计划不同,则表明计划是错误的。

适应意味着修改或改变而不是成功或失败。

如果项目是以《敏捷宣言》的价值观“适应变化比执行计划更重要”,则将失败归罪于对计划的变动是没有成效的。

非常特别的流程并不能从错误中吸取教训,而吸取教训是敏捷项目管理的关键部分。

在适应阶段,需要从客户、技术、人员和流程绩效,以及项目状况等方面对结果进行检查。

该分析将会对比实际结果和原计划结果,但更重要的是,要根据项目得到的最1. 摘自微软的电子百科全书中的世界英语词典,该书1999年和2000年版权属于微软公司。

相关文档
最新文档