热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

敏捷成熟度评估模型AMM评估管理实践与技术实践

 管理实践AgileMaturityModel实践一:SharedResponsibility–职责共享ThemeLevelStateDescriptionReferenceImp

 

管理实践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

 
推荐阅读
  • 在Qt框架中,信号与槽机制是一种独特的组件间通信方式。本文探讨了这一机制相较于传统的C风格回调函数所具有的优势,并分析了其潜在的不足之处。 ... [详细]
  • spring boot使用jetty无法启动 ... [详细]
  • 长期从事ABAP开发工作的专业人士,在面对行业新趋势时,往往需要重新审视自己的发展方向。本文探讨了几位资深专家对ABAP未来走向的看法,以及开发者应如何调整技能以适应新的技术环境。 ... [详细]
  • 函子(Functor)是函数式编程中的一个重要概念,它不仅是一个特殊的容器,还提供了一种优雅的方式来处理值和函数。本文将详细介绍函子的基本概念及其在函数式编程中的应用,包括如何通过函子控制副作用、处理异常以及进行异步操作。 ... [详细]
  • 本文介绍了如何通过C#语言调用动态链接库(DLL)中的函数来实现IC卡的基本操作,包括初始化设备、设置密码模式、获取设备状态等,并详细展示了将TextBox中的数据写入IC卡的具体实现方法。 ... [详细]
  • 本文将从基础概念入手,详细探讨SpringMVC框架中DispatcherServlet如何通过HandlerMapping进行请求分发,以及其背后的源码实现细节。 ... [详细]
  • 处理Android EditText中数字输入与parseInt方法
    本文探讨了如何在Android应用中从EditText组件安全地获取并解析用户输入的数字,特别是用于设置端口号的情况。通过示例代码和异常处理策略,展示了有效的方法来避免因非法输入导致的应用崩溃。 ... [详细]
  • Docker安全策略与管理
    本文探讨了Docker的安全挑战、核心安全特性及其管理策略,旨在帮助读者深入理解Docker安全机制,并提供实用的安全管理建议。 ... [详细]
  • 本文详细介绍了如何在Spring框架中设置事件发布器、定义事件监听器及响应事件的具体步骤。通过实现ApplicationEventPublisherAware接口来创建事件发布器,利用ApplicationEvent类定义自定义事件,并通过ApplicationListener接口来处理这些事件。 ... [详细]
  • Maven + Spring + MyBatis + MySQL 环境搭建与实例解析
    本文详细介绍如何使用MySQL数据库进行环境搭建,包括创建数据库表并插入示例数据。随后,逐步指导如何配置Maven项目,整合Spring框架与MyBatis,实现高效的数据访问。 ... [详细]
  • 对于初学者而言,搭建一个高效稳定的 Python 开发环境是入门的关键一步。本文将详细介绍如何利用 Anaconda 和 Jupyter Notebook 来构建一个既易于管理又功能强大的开发环境。 ... [详细]
  • 本文介绍了SIP(Session Initiation Protocol,会话发起协议)的基本概念、功能、消息格式及其实现机制。SIP是一种在IP网络上用于建立、管理和终止多媒体通信会话的应用层协议。 ... [详细]
  • 本文详细介绍了如何在 Vue CLI 3.0 和 2.0 中配置 proxy 来解决开发环境下的跨域问题,包括具体的配置项和使用场景。 ... [详细]
  • 本文详细介绍了如何在 Node.js 环境中利用 Nodemailer 库实现邮件发送功能,包括环境配置、代码实现及常见问题解决方法。 ... [详细]
  • 本文详细记录了腾讯ABS云平台的一次前端开发岗位面试经历,包括面试过程中遇到的JavaScript相关问题、Vue.js等框架的深入探讨以及算法挑战等内容。 ... [详细]
author-avatar
LKD2008_561
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有