敏捷成熟度评估模型-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

Lev