AMM评估管理实践与技术实践

管理实践AgileMaturity Model

实践一：SharedResponsibility –职责共享

Theme

Level

State  Description

Reference  Implementations

3+

组织级结对

Organizational  Pairing

与业务人员实时结对；跨团队协作

Real time  pairing with the business; cross-team collaboration

3

跨域结对

Cross-Discipline  Pairing

跨角色结对以实现需求

Cross-role  pairing on requirements execution

2

有管理的结对

Pairing is  Managed

使用结对阶梯表以确保结对被经常轮换，整个团队以结对方式工作

Pair stairs are  used to ensure rotation; pair teams sign up for requirement execution

1

鼓励结对

Pairing is  Encouraged

有机会结对并且结对是受鼓励的

Opportunities to  pair are identified and encouraged

0

不受限访问

Unencumbered  Access

开发人员可以不受限制地访问开发产物

Developers have  unrestricted access to change development artifacts

-1

制度化，专业化

Institutionalized  Specialization

开发人员角色固定并且能力受限

Developers are  in specified roles with limited ability to make changes

•     评估指引：

–    -1：高度制度化下的分工体系，每人负责一块，并只对这块负责

–    0：员工只对自己团队的工作负责，但可访问其他团队代码

–    1：员工依然负责自己东西，但鼓励适当的跨团队结对开发

–    2：团队成员因内部团队间协作需要开展有管理的跨团队水平结对开发，内部团队责任界限不构成障碍

–    3：不同角色的垂直结对开发，进一步扩大跨团队职责共享，角色界限模糊

–    3+：不同项目，不同组织的互相串通开发，组织级团队职责共享

–    注：不同组织：跨产品线、部门

•     垂直结对，是指需求、设计、开发、测试等上下游角色之间的结对

•     水平结对，是指需求角色之间、设计角色之间、开发角色之间、测试角色之间的结对

实践二：Requirements–需求

Theme

Level

State  Description

Reference  Implementations

3+

独立

Independent

需求描述了交付团队需要完成的事项，是独立的，可执行的。估计和协商的方式可以改变。

3

可协商

Negotiable

需求是关注业务的，是在与业务人员沟通时获取的，而不是从正式的文档或流程提取的。并且需求是可以协商的。

2

增量价值，可测试

敏捷故事：需求是业务价值的体现，而不是待完成的技术任务。

1

短小，可估计

Short, estimable

需求会被进一步分解成可互相依赖的任务（技术需求）以提高估计的准确性。

0

概要，模糊，业务导向的表达

需求过大，表述概括。估计不准确，需求描述过于概括导致难以协商

-1

详细的，高度耦合

冗长的用例，缺乏完整背景的大段描述

•     评估指引：

–    -1：缺乏完整背景的大段描述需求

–    0：需求的描述比较模糊，概况而难以协商讨论

–    1：有相对详细的步骤、任务来描述需求

–    2：各内部团队接受的需求是独立的，可被拆成若干可实现的动作/任务。建立稳定的跨团队/角色的协作流程。

–    3：建立面向用户价值的高效需求开发和管理过程

–    3+：自发的与业务讨论出来的需求，而不是单纯从文档出来的需求

实践三：Responsiveness–快速响应

Theme

Level

State  Description

Reference  Implementations

3+

持续变更管理

流畅的变更决策

实现软件产品的持续交付

用户需求得到及时有效的响应，用户高度满意

3

持续业务参与

业务人员积极参与交付的每个阶段

用户代表能够积极协调研发团队、市场和用户的业务关系，用户满意度较高

2

迭代变更管理

新特性和优先级可在每个迭代调整

1

短交付周期

新特性和优先级可在每次发布调整

0

应激式变更控制，风格不统一

非正式的变更控制

-1

缺乏灵活性，长交付周期

极为正式的变更控制。变更控制导致或反映了对变更的抵抗。规范是冻结的。

•     评估指引：

–    -1：长交付周期，计划一定就不好修改，市场和研发极少沟通，处于割裂状态

–    0：应激式变更控制，已有变化就仓促应对，调整计划。团队可以接受市场反馈，但反馈滞后，缺乏有效管理，交付具有不确定性

–    1：短交付周期，将变化控制在一个短周期内，建立市场反馈的有效管理，有基本可信的交付承诺

–    2：迭代变更管理，将变化控制在一个迭代，建立起用户基本满意的沟通和交付机制

–    3：业务人员参与到迭代中，掌握市场和研发两边情况，调整变更优先级，积极协调研发、市场和用户的业务关系，用户满意度较高

–    3+：持续变更管理，将变更变成常态，成为可规划可管理的流畅过程。用户需求得到及时有效的响应，甚至引领用户需求，用户满意度高

实践四：ProjectManagement–项目管理

Theme

Level

State  Description

Reference  Implementations

流畅的计划内和计划外风险管理

3+

项目管理最大程度支持业务

存在统一机制以报告项目是否满足业务需求

3

自适应项目管理

项目计划是有业务人员参与的协作过程，每个迭代都会进行并可能得到更新。项目计划能够指明当前期望在哪个迭代交付哪些业务功能。

计划内和计划外风险在决策视角内得到关注

2

项目状态报告反映项目路径？

项目状态报告反映了项目路径，在业务层面传达目前为止已交付的功能

1

决策视角是迭代长度

决策视角是一个较短的时间窗，通常不超过3个星期。需求以能在此时间窗内完成的方式表达

应激式风险应对（对执行的关注胜过风险意识）

0

决策视角是发布长度

决策视角是一个较短的时间窗，通常不超过3个月。需求以能在此时间窗内完成的方式表达

计划内风险受管理，不容许计划外风险

-1

固定的项目计划，决策视角是项目长度

项目时间表作为计划，决策视角是项目长度，有可能几年。项目状态是以执行与计划的匹配程度来报告的。

•     评估指引：

–    -1：非常固定的项目计划，时间长，只关注计划内风险

–    0：通常可以3个月为单位知道项目进度，并制定基本的风险管理对策

–    1：通常在3~4周内知道项目进度，并制定风险管理对策

–    2：可快速根据项目报告得到项目具体进度，建立基本的可视化项目管理视图（如燃起图）

–    3：随时可得到项目进度状况，建立成熟的可视化项目管理（所有角色能够成熟地使用）

–    3+：随时知道项目进度是否满足业务需求，持续交付

–    注：

•     敏捷项目管理以估算为基础，以客户合作为重要保障

•     对项目的关键要素S（需求）、Q（质量）、R（成本）、T（时间）进行细分的、量化、可视化管理

•     风险是指所有SQRT相关的可能影响项目输出的不确定因素，风险管理质量是敏捷项目管理成熟度的重要参考

实践五：Communication–沟通

Theme

Level

State  Description

Reference  Implementations

系统性沟通

3+

企业级协作

与业务相关的活动对团队无侵入性；业务和开发组成统一团队

流畅沟通

3

协作执行

跨角色结对

沟通自动化

2

协作基础设施

面向所有涉众的交流（主动的、被动的）均有工具支持

结构化沟通体系

1

协作式专题讨论

有结构化、有规律的沟通和会议支持协作

双向沟通

0

定期会议

定期（通常是每周）小组会议以供团队成员讨论

单向沟通

-1

单向沟通

管理层向团队通报进度

不定期小组会议

各执一词的吵架会议

•     评估指引：

–    -1：管理通报进度，布置任务，下级无反馈和沟通

–    0：定期项目级会议讨论团队间协作问题

–    1：团队间定期讨论+专题讨论，但因人员工作地点、积极性、会议资源等问题使得会议成本和效率有待改进

–    2：高质量的会议资源支持团队间频繁沟通，比如：视频会议，基本无客观环境因素限制沟通质量和效率

–    3：团队不同角色结对，由团队成员自发形成

–    3+：组织型结对

实践六：SelfOrganization–自组织能力

Theme

Level

State  Description

Reference  Implementations

强化原则，弱化规则

3+

巩固

与业务成果挂钩

3

平衡

连通各个维度

2

操作

项目团队充分理解敏捷价值观和实践原则，并在部分项目级工作中得到有效遵循，以减少浪费

项目级团队有意识地减少或避免管理规范和要求对团队的侵入和干扰

研发活动、文档、度量、会议等得到简化或自动化，例如：自动收集的度量数据和指标，减少方所的手工收集和报告

记录、奖惩、考核、学习和分享等工作逐步由团队自主制定和执行

1

初始

项目工作开始接受敏捷实践原则，各团队根据自身情况反馈对项目的工作诉求，并可能获得支持

项目团队制定的工作要求得到各成员认可和支持的，以保证项目交付的质量和效率

缺乏明确的规则或原则

0

应激性的

项目层面工作无规范，团队间没有共同认可的纪律，经常因为工作混乱导致项目工作无法预测

规定的，基于规则的

-1

文过饰非

项目内各项工作表现为重量级的，障碍性的，便于出错时好有借口

•     评估指引：

–      关注敏捷价值观和原则如何应用到敏捷团队工作中

•       任何一项团队工作（决策准则）都表现为规范性和原则性之间的平衡，这种平衡体现出团队自组织能力的成熟度

•       可考察团队工作的任何领域，研发活动、文档、度量、奖惩、考核等

•       自组织能力的目标是发挥团队和成员的创造性，提升团队凝聚力，建立积极向上的敏捷研发文化

–      -1：基于重量级文档、规程、检查单等规范性工作产品，作为验证、追责标准

–      0：应激性管理

–      1：主要由领队决定，团队成员意见可供参考

–      2：在部分领域，团队基于对活动的价值分析进行决策。领队提供支持，必要时进行决策。最大限度降低相关活动对团队工作的侵入和浪费。

–      3：几乎在所有领域，团队都能够正确地运用敏捷价值观和原则进行价值分析和决策，及时回顾和修正团队决策

–      3+：端到端的双向追踪：实现从市场需求到产品交付全流程的自组织团队管理

–      注：即使到3+，团队工作的规范也是需求的，关键是规范的产生和执行是否符合敏捷价值观。

技术实践AgileMaturity Model

实践七：Build –软件构建

Theme

Level

State  Description

Reference  Implementations

3+

External  Gatekeeper

对外防御

Functional  testing tools (Watir, Selenium, Marathon Man) are integrated as gatekeeper  events to the build. Integration tests with external tools and products.

在构建过程中集成功能测试工具，并将其作为构建成功的条件。对与外部工具和产品的集成进行测试。

3

Internal  Gatekeeper

对内防御

Unit tests and  code characteristics are implemented as gatekeeper events that will

prevent a build  from completing.

在构建过程中集成单元测试和代码特征检查，并将其作为构建成功的条件。

2

Constant

频繁执行

Build velocity  is maximized - that is, build is happening with the maximum frequency. State  of the build the responsibility of the team.

建立良好的项目团队构建纪律并得到团队的认同和认真执行。

尽快构建即保持最高的构建频率。整个团队对构建状态负责。

1

Repeating

重复执行

Build is  repeatable and automated, but doesn‘t happen with maximum frequency

as permitted by  the technology. State of the build is a responsibility of the team.

构建过程是自动化的、可重复的，但受限于技术原因不能保持最高的构建频率：整个团队对构建状态负责。

0

Repeatable

具备重复执行能力

Build process is  repeatable and static, but still likely performed manually and infrequently;  the build may be owned by a specific member of the team.

构建流程是可重复的，但并不活跃，往往手动触发，而且频率较低。构建由团队中某个特定的成员负责。

-1

Custom

不可重复

Build is  manually performed, custom every time, and infrequently performed; it may be  owned by a specific member of the team

构建必须手动执行，每次执行都需要专门做一些配置，执行频率较低，构建由团队中某个特定的成员负责。

•     评估指引：

–    -1：项目级构建频度低于一周一次，集成构建无规律

–    0：项目级构建频度做到一周至少两次，每周至少有一次整体集成构建

–    1：项目级构建频度做到每天一次，构建每天一次

–    2：项目级构建做到完成一块提交一次，CI工具支持每次提交出发增量构建

–    3：所有内部开发团队达到构建3级，基本的功能冒烟测试加入到每次构建中，用以保证内部质量

–    3+：自动化集成测试加入到构建中，自动化部署和验收测试保证外部质量

实践八：Testing–测试

Theme

Level

State  Description

Reference  Implementations

Analysts are  part of test planning

分析师会参与制定测试计划

3+

Comprehensive,  Integrated

全面的、集成的

Owned by  QA/Dev/Analyst, complete integration with build, non-functional and

integration  testing in an advanced state

测试由需求规划、测试和开发人员共同负责。大部分测试集成进构建过程中。与产品应用场景基本一致的测试设计，且高度自动化（不一定完全自动化），故障泄露数量底，满足持续发布需要。

3

TDD, Integrated

Owned by  QA/Dev/Analyst, non-functional and integration testing undergo complete inspection  tests. Functional testing is integrated with the build. Developers practice  TDD.

测试由测试人员和Dev以及Analyst共同负责。非功能测试和集成测试由完整的审查过程来保障。功能测试被集成进构建过程中。

Developers are  part of testing

开发人员会参与测试

2

Shared by QA and  Development,

Integrated

测试与开发共享、集成的

Owned by QA/Dev.  Non-functional and integration testing undergo complete

inspection  tests, functional testing is integrated with the build.

测试由测试人员和Dev负责。非功能测试和集成测试由完整的审查过程来保障。功能测试则被集成进构建过程中。

1

Shared by QA and  Development测试与开发共享

Owned by QA/Dev.  Functional testing is not integrated with the build and may still be a full  inspection process. Non-functional and integration tests might be  incrementally integrated or End of Lifecycle

测试由测试人员和Dev负责。功能测试未集成进构建过程，由完整的审查过程来保障。

非功能测试和集成测试可能是增量集成的，或者是在软件开发周期的末尾阶段执行的。

Testing is a QA  problem

测试只是测试人员的事情

0

Independent,  Inspection

独立的，审查

Owned by QA.  Functional testing is full inspection and not integrated with the build.

Incremental  non-functional and integration tests are rudimentary inspection tests, or  performed only at End of Lifecycle.

测试由测试人员负责。功能测试是一次完整的检查，而未集成进构建过程中。增量的非功能测试和集成测试中仅包含基本的审查测试，或者这些检查仅在软件开发周期的末尾阶段执行。

-1

Independent, End  of Lifecycle

独立的，位于软件开发周期末尾阶段

Owned by QA.  Functional, Non-functional and Integration testing performed at End of  Lifecycle.

测试由测试人员负责。功能测试、非功能测试和集成测试仅在软件开发周期的末尾阶段

•     评估指引：

–    -1：测试部门统一测试，开发无测试，测试集中在项目后期

–    0：开发代码回顾，并做部分功能测试，但大部分在后期测试部门测试

–    1：版本提交测试前，测试人员与开发人员共享测试资源（工具、用例、测试环境等），分工比较明确，共同完成部分开发测试，但大规模测试依然在测试部门执行，测试人员参与需求分析，并确定测试设计的输入

–    2：项目内部软件开发团队达到测试2级，版本提交系统测试前代码经过单元测试以及部分功能测试保护

–    3：项目内部软件开发团队达到测试3级，大部分测试集成到构建过程中，测试部门只需少量保障性手工测试，包括功能和非功能测试

–    3+：完整全面的测试，没有专职的测试工程师，PO+测试+开发共同完成所有测试，并大量自动化

实践九：Simplicity–简单性

Theme

Level

State  Description

Reference  Implementations

高级技术风险降低

3+

JIT Re-use

即时重用

组件超市：“组件在可重用之前必须可用。”

Component  supermarket: ―a component must be usable before it can become re-

usable‖

高级技术风险降

3

JIT Design

即时设计

YAGNI文化（YAGNI大概意思是只需要将应用程序必需的功能包含进来）

关注简单性：可工作、交流、无重复、尽量少的晦涩片段

YAGNI culture

Focus on  simplicity: works, communicates, no duplication, fewest moving parts

有效的技术风险降低

2

Mature  refactoring

成熟的重构

有效地应用设计模式：支持重构的测试实践。

Effective  application of design patterns; testing practices support refactoring

技术风险降低雏形

1

Refactoring  introduced

引入重构

无纪律的重构，重构不充分；结对编程、每日站立会议、迭代回顾。

Undisciplined  refactoring is not sufficient; indicators of discipline include pair

忽视技术风险

0

Ad-hoc design

临时设计

应激性设计（“工作即可”）；拼凑组件。

Reactive design  (whatever works‖); component ―bazaar‖

预先假想所有技术风险

-1

Big up-front  design

大规模预先设计

花费大量精力预先设计框架；传统的企业级重用程序（如组件库）；误用SOA（如根据推理定义分类）；导致高耦合、脆弱的实现，降低响应能力。

Significant investment  in up-front frameworks; traditional enterprise re-use program (e.g.,  component libraries); SOA done wrong (e.g., speculative taxonomy defined);

实践十：ConfigurationManagement –配置管理

Theme

Level

State  Description

Reference  Implementations

3+

Enterprise CM

企业级配置管理

可以在多个提供商提供的解决方案之间协调配置管理。

CM is  coordinated across vendor supplied solutions

3

Coordinated CM

协调的配置管理

在同一个程序内协调多个项目的配置管理。

CM is  coordinated across projects within the same programme

2

Automatic CM

自动化配置管理

自动化的配置管理流程意味着更少的意外。乐观锁。通过构建和测试保证CM纪律。原子提交。

The ―code fairy  does not run free‖ state – automation of CM rules. Optimistic locking.

1

Integrated CM

集成配置管理

配置管理与IDE集成在一起。手动的代码管理方式意味着代码很难控制，（如果未遵守纪律，就可能出现意外）

CM integrated  with the IDE. Manual discipline means ―the code fairy runs free‖

0

Rudimentary CM  Strategy

基本的配置管理策略

基本的代码版本管理

Basic code  versioning

-1

CM is an  impediment

配置管理是一项负担

无规矩

版本信息只保存在每个人的心里

Wild west

Gatekeeper  approach (―pay the CM troll‖)

Tacit knowledge  in lieu of versioning