级别： 初级 宁 德军, 高级技术经理, IBM
朱 育雄, 资深技术顾问, IBM
孙 昕, 资深技术顾问, IBM
2009 年 9 月 10 日
走进软件交付 2.0 的世界，IBM Rational 为业界提供了第一款 2.0 的软件交付平台Rational Team Concert（团队音乐会，RTC），它基于 Jazz 平台为开发团队提供了基于上下文进行实时的团队协作、自动化的任务和工件流转、建立全生命周期的可追踪性，透明的团队开发流程、计划、记录文档和报告等功能，它具备了 2.0 时代软件交付平台的典型特征。
我们推出了本书的 前言 和 第 2 章、第 3 章 及 第 5 章 供大家在线浏览。更多推荐书籍请访问 developerWorks 图书频道。
 | |
|
|
书名：奏响软件交付的爵士乐 —— Jazz 平台实践者之路
作者：宁德军、朱育熊、孙昕 等编著
出版社：清华大学出版社
出版日期：2009 年 8 月
ISBN：978-7-302-20719-1
购买：
中国互动出版网、当当网、卓越网
| |
推荐章节：
更多推荐书籍，请访问 developerWorks 图书频道。
欢迎您对本书提出宝贵的反馈意见。您可以通过本页面最下方的 建议 栏目为本文打分，并反馈您的建议和意见。
如果您对 developerWorks 图书频道有什么好的建议，欢迎您将建议发给我们。
|
|
|
“既不是最强的，也不是最聪明的，而是最能适应变化的生存了下来。” —— 达尔文
走进软件交付 2.0 的世界，IBM Rational 为业界提供了第一款 2.0 的软件交付平台 Rational Team Concert（团队音乐会，RTC），它基于 Jazz 平台为开发团队提供了基于上下文进行实时的团队协作、自动化的任务和工件流转、建立全生命周期的可追踪性，透明的团队开发流程、计划、记录文档和报告等功能，它具备了 2.0 时代软件交付平台的典型特征。
图 3.0 Rational Team Concert
团队音乐会的名字起的形象极了！下面让我们来对比一下真的音乐会和 RTC 的相似之处。
无地域限制的软件交付舞台
想一想是什么使整个音乐会能够按部就班，乐队中的每个人能够各司其职，默契协作呢？是明亮的舞台和乐谱。
明亮的舞台为乐队中的音乐家默契协作提供了基本的协作空间和环境。RTC 基于 Jazz 的协作能力，为整个软件交付团队提供了一个没有地域限制的虚拟世界的舞台。使团队成员无论身在何处，都像身处同一舞台，实现彼此的密切协作。在 RTC 的舞台上，通过各种 Web 2.0 的创新技术的应用，团队中的每个人都能够非常方便地了解整个开发团队的组织结构（Team Awareness），了解团队中每个人的角色和职责分工及任务分配状况，实时了解整个团队的工作进度和其他人的工作状况（虚拟世界中眼睛的能力）；通过 Feeds、Wiki，Blogs 等服务，当存储库中被关心的对象数据变化后（例如源代码发生变更、工作项状态发生变化等），Feeds 服务会主动根据订阅记录进行广播，让给所有相关开发人员能够在最短的时间内掌握最新动态，实现高效协作沟通和响应。通过与即时通信工具（例如 Jabber、Lotus Same、Goggle Talk 等）集成、开发流程的动态执行、工作任务和工件的自动流转，实现了开发环境中在线提示和实时通信的能力，可以通过谈话窗口发送各种 Jazz 对象链接（例如变更集、工作项等），在实际工作环境中实现有上下文关系的快速团队沟通与协作（虚拟世界中耳朵和嘴巴的能力）。
一场现代音乐会离不开技术的进步和创新。参观过首都音乐厅的人恐怕无不对其自动化水平和各种舞台技术的创新而瞠目。除了舞台的自动化以外，各种乐器也可以说是每个音乐家手中的自动化工具。否则，再伟大的音乐家也只能巧妇难为无米之炊。灯光布景等的自动化控制技术，都会为音乐会的精彩程度提供支持。
基于 Jazz 平台的创新技术，RTC 获得了数据的集中存储能力、流程感知能力、团队感知能力和协作能力，同时提供了各种基于 Web 2.0 创新技术的订阅、查询等服务的实现。在此基础上，RTC 实现了配置管理、工作项管理、构建管理、项目规划和报告五大核心能力。基于这些能力，在不同角色和工作环节间，工作任务能够进行自动流转，工件信息能够自动传递，工作数据和过程得以自动记录、自动收集和汇报，全生命周期的可追踪性得以自动建立。如图 3.1 所示为 RTC 的主要功能模块。
图 3.1 构成 RTC 的主要功能模块
综上所述，RTC 为软件交付团队提供了统一的团队协作开发平台，实现了软件交付全生命周期中的人、流程、项目和工具的整合。IBM 院士 Grady Booch 曾讲过，RTC 与 IBM Rational Jazz 平台，通过降低并减少团队中的许多日常行为，有助于提供一个“无阻力的开发平台”。应用 RTC 与 Scrum 等敏捷过程模板，为什么能克服许多困难原因中的一个方面，就是它能将敏捷计划与追踪开发工作进行融合。目前，如果您正使用当下流行的敏捷计划工具，您就不得不在敏捷计划工具与集成开发环境（IDE）之间不断切换，以定位工作，完成并报告它的进度。通过融合这些操作及其他的一些活动，RTC 提供了更大的可操控性、可追踪性、过程感知能力和团队协作，并且所有这些都集中于一个平台下，从而有助于提高开发效率及软件交付。
基于 Jazz 的软件交付 2.0 协作平台，RTC 不但在软件交付团队的协作、自动化水平的提高和透明地管控等许多方面，都带给最终用户以全新的感受，而且还为目前流行的敏捷开发提供了整合的工作平台。
团队音乐会主要场景说明
在以后的章节里，我们以一个虚拟的软件企业（SmartProject）为例，详细介绍该企业的某个产品项目团队在 RTC 软件协作开发平台上，遵循敏捷软件开发过程 Scrum，开发该产品一个新版的完整生命周期，展示 RTC 拥有的强大软件开发协作能力。
SmartProject 公司是我国国内一家专业软件公司，拥有大约 200 名员工，专注于面向中小型企业管理商业软件的开发工作。该公司规模虽小，但在软件开发过程和开发平台方面非常注意与国外成熟的软件开发技术接轨，旨在通过不断改进团队的软件交付能力，提高企业的核心竞争力；SmartProject 公司自 2005 年成立之初，就采用业界流行的敏捷开发过程 Scrum 进行软件开发，在软件开发工具方面，采用 Eclipse, CVS, Jira 等开源工具；2008 年 3 月，SmartProject 公司的软件工程专家注意到由 Eclipse 项目小组与 IBM 相关部门经过多年研发的 Jazz 平台和敏捷软件开发平台 RTC 在 jazz.net 社区网站上发布，他们经过仔细评估，决定从开源工具转向 RTC 软件开发平台。经过近两年的试用和推广，公司内部的所有项目组均采用 RTC 进行软件开发工作。
SmartProject 公司开发的灵巧项目管理软件 SmartProject v1.0 是基于 B/S 的三层架构应用软件，该软件自 2008 年 12 月首次投放市场以来，就受到了中小型企业广泛欢迎。为了满足客户不断提出的新需求，项目组决定在未来 4 个月内基于 v1.0 版本进行新版的开发工作，预计在 2009 年第二季度发布 v2.0 版本。
SmartProject v2.0 项目团队由 8 名成员构成，其中项目产品负责人 1 名、Scrum 主管 1 名、其他 Scrum 团队成员共 6 人。他们采用 Scrum 敏捷开发过程，开发平台采用 IBM Rational Team Concert v1.0.1.1（中文版），这是一个端到端的开发平台，开发团队的需求管理、工作计划与跟踪、配置管理、工作管理、构建管理等都由 RTC 提供支撑功能。
作为一个生命周期服务整合平台，Jazz 为 SmartProject v2.0 项目团队提供了团队上下文中实时协作能力和治理过程的定义及执行能力。实时协作能力能够为团队提供了透明的工作环境，使得团队中每个人都能够实时、方便地知道“谁、在何时、干什么、为什么”，有效加强团队协作，打造高效团队。而基于治理流程的定义及执行能力，开发团队首先可以基于自身项目特点，选择合适的开发方法 Scrum。然后，基于 Jazz 平台内置的 Scrum 过程模板进行简单定制，教会 Jazz 如何执行 Scrum 开发过程，从而指挥整个团队，通过有效的分工协作，完成开发任务。
如图 3.2 所示，基于 Jazz 平台治理流程的定义及执行能力，SmartProject v2.0 项目团队使用 RTC，方便定义出敏捷开发团队的开发流程。图中的数字为本书中讲解相应内容的章节号。
图 3.2 在 Jazz 平台上实现软件的敏捷开发
基于流程定义，整个软件交付生命周期主要包括以下六项主要活动：
（1）由管理员创建与配置整个 RTC 开发平台，为项目准备基本协作开发环境。
（2）由产品负责人定义项目的产品订单，并基于利益干系人和业务的具体要求，划分优先级。由 Scrum 主管在 RTC 环境中，快速创建 SmartProject v2.0 项目，并快速地选择已定义好的 Scrum 开发过程，并根据自己管理特色和项目具体特点进行简单定制。在 RTC 中，确定每个团队成员的角色、权限和整个项目的组织结构，并导入必须的项目数据，完成整个项目团队环境的准备工作。
（3）在召开冲刺规划会议之前，产品负责人要首先将制定好的产品订单录入 RTC，并和主要利益干系人、Scrum 主管一道，考虑项目的刚性需求，制定项目的发布规划，包括主要冲刺和里程碑。然后，由产品负责人和 Scrum 主管共同召开 Sprint 规划会议。在规划会议中，由团队讨论，最终产品负责人决定，确定当前冲刺要完成的产品订单。并由团队成员通过自组织的方式认领相应的产品订单项，制定出为完成指定的产品订单项要进行的任务分解。每个任务的工作时间不应超过 16 小时，而且任务本身应该是可分配、可度量、可管理。Scrum 主管使用 RTC 的工作项管理功能，将指定任务分配给团队成员。
（4）团队成员接受任务分配，通过紧密的团队协作，开展开发工作。这期间团队将使用 RTC 完成工作项管理、配置管理、持续构建等团队协作工作。整个过程中，RTC 将基于预定义的过程，启发式地提示整个团队执行指定的开发过程任务。
（5）在整个项目执行过程中，Scrum 主管将通过 RTC 管理变更、监控工作项的完成情况、监控每个人工作健康状况、监控迭代健康情况，同时生成各种统计报表，包括冲刺的燃尽图和工作项的完成情况一览表和构建报告等，对整个项目进度和健康情况实现实时可见性。
（6）在每个冲刺结束时，Scrum 主管会组织召开冲刺回顾会议，讨论在过去的冲刺过程中，哪些过程工作得好，哪些需要改进，以实现敏捷开发过程的持续改进。如果团队一致认为某个过程运作的非常好，管理员可以帮助团队将这一过程转变成为新的软件开发过程模板，从而固化团队的最佳实践和经验教训。
在此，想特别说明的是，Jazz 平台和 RTC 工具本身是平台中立的，它支持各种开发过程的自动化执行。如图 3.3 所示，即使企业采用的是传统的瀑布开发模型，基于 Jazz 平台治理流程的定义及执行能力，我们同样可以方便定义出适合开发团队的瀑布模型，为整个团队提供全生命周期的协作开发管理能力。在下一节我们会对 RTC 的开发过程支持能力进一步介绍。
图 3.3 在 Jazz 平台上实现软件交付的瀑布模型
音乐会的主旋律 —— Scrum 方法简介
在乐队中，乐谱使团队中的每个人明确：谁、在什么时间、演奏什么、前后的曲子都是什么；在软件开发团队中，是软件开发流程定义了开发团队中的谁、在什么时间，做什么事情，以及输入和输出。RTC 被设计可以理解并支持各种类型的开发过程，包括从小型的敏捷（Agile）风格的项目，到大型的并带有复杂遵从需要的企业级项目。具体操作时，开发团队既可以实现用 RTC 内置的目前流行的开发过程方法模板，像敏捷开发过程、Eclipse Way、Scrum，OpenUP 等，也可以根据自身项目管理的特点为自己量身定制出合适的开发过程（包括迭代开发过程、RUP 或瀑布模型等），能够适应不同的企业环境。因此，Jazz 平台本身对开发过程的支持是中性的，它没有绑定特定开发过程，但却可以支持任何流程。
本场音乐会的主旋律将采用 RTC 内置的 Scrum 过程模板。在软件交付过程的执行过程中， RTC 会基于它启发式的指导团队成员执行过程，自动地预告流程的下一环节，帮助开发人员基于 Scrum 方法，密切协作，减少发生错误，高效地交付软件。当 Scrum 过程被错误地执行时，它还会主动发生作用，解释错误的原因和提出相应解决办法。正是 RTC 的流程感知和执行能力，使整个软件交付团队能够基于 RTC 演奏的节奏而翩翩起舞，不断创造精彩。
下面我们将详细介绍作为本音乐会主旋律的 Scrum 方法，以方便大家更好地理解整个团队的协作过程。
术语 Scrum 来源于橄榄球活动，在英文中的意思是橄榄球里的争球。在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时，他们奋力争球。1995 年，在奥斯汀举办的 OOPSLA '95 上，萨瑟兰和施瓦伯首次提出了 Scrum 概念，并在随后的几年中逐步将其与业界的最佳实践融合起来，形成一种迭代式增量软件开发过程和敏捷项目管理方法，并在 2001 年敏捷联盟（Agile Alliance）形成后受到了更多欢迎。
Scrum 是一种灵活的软件管理过程，它提供了一种经验方法，可以帮助你驾驭迭代，实现递增的软件开发过程。这一过程是迅速、有适应性、自组织的，它发现了软件工程的社会意义，使得团队成员能够独立地集中在创造性的协作环境下工作。
Scrum 采用了经验方法，承认问题无法完全理解或定义，关注于如何使得开发团队快速推出和响应需求能力的最大化。因此，Scrum 的一个关键原则就是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。
Scrum 作为软件开发过程框架，它包含的主要最佳实践包括以下几个方面。
迭代式软件开发：通过将整个软件交付过程分成多个迭代周期，帮助团队更好地应对变更，应对风险，实现增量交付、快速反馈。
两层项目规划（Two-Level Project Planning）：基于远粗近细的原则和项目渐进明细的特点，通过将概要的项目整体规划和详细的近期迭代计划有机结合，帮助团队有效提高计划的准确度、资源管理能力和项目的按时交付能力。
整体团队协作（Whole Team）：通过关注保持整个团队可持续发展的工作节奏、每日站立会议和自组织的工作分配，实现团队的高效协作和工作，实现提高整个团队生产力的目的。
持续集成：通过进行更频繁的软件集成，实现更早的发现和反馈错误、降低风险，并使整个软件交付过程变得更加可预测和可控，以交付更高质量的软件。
Scrum 是一个包括了一系列实践和预定义角色的过程框架。任何软件开发过程框架都可以由最基本的三个要素组成：角色（人）、活动及其输入输出的工件。Scrum 框架主要包括以下内容：
-
角色；
-
产品负责人（Product Owner）；
-
Scrum 主管（Scrum Master）；
-
团队成员；
-
活动；
-
冲刺规划会议（Sprint Plan Meeting）；
-
每日站立会议（Scrum Daily Meeting）；
-
冲刺复审会议（Sprint Review Meeting）；
-
冲刺回顾会议（Sprint Retrospective Meeting）；
-
工件；
-
产品订单（Product Backlog）；
-
冲刺订单（Sprint Backlog）；
-
燃尽图（Burndown Chart）；
-
新的功能增量。
下面我们就从角色、活动和工件三个维度对整个 Scrum 过程进行简单介绍。
Scrum 中的角色
Scrum 定义了许多角色，根据猪和鸡的笑话可以分为两组，猪和鸡。
一天，一头猪和一只鸡在路上散步。鸡看了一下猪说：“嗨，我们合伙开一家餐馆怎么样？”。猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”。鸡想了想说：“餐馆名字叫火腿和鸡蛋怎么样？”。“我不这么认为”，猪说，“我全身投入，而你只是参与而已”。
“猪”角色：是全身投入项目和 Scrum 过程的人，主要包括代表利益干系人的产品负责人，同项目经理类似的 Scrum 主管和开发团队。
产品负责人（Product Owner）：代表了客户的意愿，这保证 Scrum 团队在做从业务角度来说正确的事情。同时他又代表项目的全体利益干系人，负责编写用户需求（用户故事），排出优先级，并放入产品订单（Product Backlog），从而使项目价值最大化的人。他利用产品订单，督促团队优先开发最具价值的功能，并在其基础上继续开发，将最具价值的开发需求安排在下一个冲刺迭代（Sprint）中完成。他对项目产出的软件系统负责，规划项目初始总体要求、ROI 目标和发布计划，并为项目赢得驱动及后续资金。
Scrum 主管（Scrum Master）：负责 Scrum 过程正确实施和利益最大化的人，确保它既符合企业文化，又能交付预期利益。Scrum 主管的职责是向所有项目参与者讲授 Scrum 方法，正确的执行规则，确保所有项目相关人员遵守 Scrum 规则，这些规则形成了 Scrum 过程。Scrum 主管并非团队的领导（由于他们是自我组织的），他的主要工作是去除那些影响团队交付冲刺目标的障碍，屏蔽外界对开发团队的干扰。“Scrum 主管是保证 Scrum 成功的牧羊犬”。
开发团队：负责找出可在一个迭代中将产品待开发事项（冲刺订单）转化为功能增量的方法。他们对每一次迭代和整个项目共同负责，在每个冲刺中通过实行自管理、自组织，和跨职能的开发协作，实现冲刺目标和最终交付产品。一般由 5~9 名具有跨职能技能的人（设计者，开发者等）组成。
“鸡”角色：并不是实际 Scrum 过程的一部分，但是必须考虑他们。敏捷方法的一个重要方面是使得用户和利益所有者参与每一个冲刺的评审和计划并提供反馈。
用户：软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”。
利益所有者（客户，提供商）：影响项目成功的人，但只直接参与冲刺评审过程。
经理：为产品开发团体架起环境的那个人。
如图 3.4 所示为 Scrum 方法中的主要角色。
图 3.4 Scrum 方法中的主要角色
Scrum 活动
Scrum 的活动主要由冲刺规划会议（Sprint Plan Meeting）、每日站立会议（Sprint Daily Meeting）、冲刺复审会议（Sprint Review Meeting）和冲刺回顾会议（Retrospective Meeting）组成。Scrum 提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（Disciplines），这些有助于创造自我组织的团队。
冲刺规划会议：冲刺开始时，均需召开冲刺规划会议，产品负责人和团队共同探讨该冲刺的工作内容。产品负责人从最优先的待开发事项中进行筛选，告知团队其预期目标；团队则提出在接下来的冲刺内，评估预期目标可实现的程度。冲刺规划会议一般不超过 8 小时。在前 4 个小时中，产品负责人向团队展示最高优先级的产品，团队则向他询问产品订单的内容、目的、含义及意图。而在后 4 小时，团队则计划本冲刺的具体安排。
每日站立会议：在冲刺中，每一天都会举行项目状况会议，被称为 Scrum 或“每日站立会议”。每日站立会议有一些具体的指导原则：
-
会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款、做俯卧撑、在脖子上挂橡胶鸡玩具等）。
-
欢迎所有人参加，但只有“猪”类人员可以发言。
-
不论团队规模大小，会议被限制在 15 分钟。
-
所有出席者都应站立（有助于保持会议简短）。
-
会议应在固定地点和每天的同一时间举行。
在会议上，每个团队成员需要回答三个问题：
-
今天你完成了那些工作？
-
明天你打算做什么？
-
完成你的目标是否存在什么障碍？（Scrum 主管需要记下这些障碍）
冲刺复审会议：一般 4 个小时，由团队成员向产品负责人向其他利益相关人展示 Sprint 周期内的产品开发情况，并决定下一次 Sprint 的内容。
冲刺回顾会议（Retrospective Meeting）：每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在 4 小时。
如图 3.5 所示表示 Scrum 方法中的主要活动和交付件。
图 3.5 Scrum 方法中的主要活动和交付件
Scrum 工件
产品订单：产品订单（Product Backlog）是整个项目的概要文档，它包含已划分优先等级的、项目要开发的系统或产品的需求清单，包括功能和非功能性需求及其他假设和约束条件。产品负责人和团队主要按业务和依赖性的重要程度划分优先等级，并作出预估。预估值的精确度取决于产品订单中条目的优先级和细致程度，入选下一个冲刺的最高优先等级条目的预估会非常精确。产品的需求清单是动态的，随着产品及其使用环境的变化而变化，并且只要产品存在，它就随之存在。而且，在整个产品生命周期中，管理层不断确定产品需求或对之做出改变，以保证产品适用性、实用性和竞争性。.
冲刺订单：冲刺订单（Sprint Backlog）是大大细化了的文档，用来界定工作或任务，定义团队在 Sprint 中的任务清单，这些任务会将当前冲刺选定的产品订单转化为完整的产品功能增量。冲刺订单在冲刺规划会议中形成，其包含的不会被分派，而是由团队成员签名认领他们喜爱的任务。任务被分解为以小时为单位，没有任务可以超过 16 个小时。如果一个任务超过 16 个小时，那么它就应该被进一步分解。每项任务信息将包括其负责人及其在冲刺中任一天时的剩余工作量，且仅团队有权改变其内容。
燃尽图：燃尽图（Burndown Chart）是一个公开展示的图表，纵轴代表剩余工作量，横轴代表时间，显示当前冲刺中随时间变化而变化的剩余工作量（可以是未完成的任务数目，或在冲刺订单上未完成的订单项的数目）。剩余工作量趋势线与横轴之间的交集表示在那个时间点最可能的工作完成量。我们可以借助它设想在增加或减少发布功能后项目的情况，我们可能缩短开发时间，或延长开发期限以获得更多功能。它可以展示项目实际进度与计划之间的矛盾。
新的功能增量：Scrum 团队在每个冲刺周期内完成的、可交付的产品功能增量。
Scrum 过程说明
在 Scrum 项目管理过程中，一般产品负责人获取项目投资，并对整个产品的成功负责。他会协调各种利益干系人，确定产品订单中初始的需求清单及其优先级，完成项目的商业价值分析和项目整体规划，并任命合适的 Scrum 主管开展项目工作。如图 3.7 所示表示 Scrum 方法的全景图。
图 3.6 Scrum 方法全景图
在 Scrum 软件开发项目中，每个冲刺就是一个为期 30 天的迭代。在每个冲刺开始时，产品负责人和 Scrum 主管通过召开冲刺规划会议和“两层项目规划”的最佳实践，制定冲刺订单（类似于迭代计划），明确将在本次冲刺中实现的需求清单，相应的工作任务和负责人。在每个冲刺迭代中，团队强调应用“整体团队协作”的最佳实践，通过保持可持续发展的工作节奏和每日站立会议，实现团队的自组织、自适应和自管理，高效完成冲刺工作。在每个冲刺结束时，团队都会召开冲刺复审会议，团队成员会在会上分别展示他们开发出的软件（或其他有价值的产品），并从产品负责人和其他利益干系人那里，得到反馈信息。
在冲刺复审会议之后，团队会自觉召开冲刺回顾会议，回顾整个项目过程，讨论那些方面做得好，哪些方面可以改进，实现软件交付过程的持续、自发的改进。
小结
本章带领各位一起走进了团队音乐会的舞台（RTC），参观了音乐会的主角 SmartProject 2.0 团队，说明了作为团队协作主旋律的 Scrum 敏捷项目管理方法和过程，详细说明了 Scrum 方法中涉及的主要角色、活动和工件，使您对即将上演的 Jazz 音乐会有个全面的了解和知识储备。第 4 章我们将为奏响团队音乐会的序曲。
本章的主要知识点包括：
-
团队音乐，RTC 的主要功能简介；
-
音乐会主要场景说明；
-
什么是 Scrum 方法，它包含哪些角色、活动和工件；
-
Scrum 方法的整个工作过程。
读者反馈
欢迎您对本书提出宝贵的反馈意见。您可以通过本页面最下方的 建议 栏目为本文打分，并反馈您的建议和意见。
如果您对 developerWorks 图书频道有什么好的建议，欢迎您将建议发给我们。
参考资料 学习
获得产品和技术
讨论
作者简介 | 
| | 宁德军，现任 IBM Rational 中国区高级技术经理，PMP。有超过 15 年的软件工程经验，曾为数十家公司提供过软件工程管理和项目管理的咨询服务。目前专注于软件过程改进、敏捷开发过程、项目管理和架构技术等的研究。 |
| 
| | 朱育雄，现任 IBM Rational 资深技术顾问，PMP。有超过 10 年的软件开发和管理经验，曾经为华为、ZTE、中国移动、南航、深圳软件园等多家单位提供过软件管理技术服务。目前专注于软件过程改进、软件项目管理、软件配置管理和面向对象分析设计等技术的研究。 |
| 
| | 孙昕，硕士。现任 IBM 中国有限公司软件部资深技术顾问，PMP。加入 IBM 之前，在国内外多家大型企业任职，从事软件开发和管理工作，超过 10 年的软件工程实施和咨询经验，对于软件工程方法、理论、工具有着非常深刻的理解和认识。 |
对本文的评价
| 
