阿里、蚂蚁、晟腾、中科加禾精彩分享 AI 基础设施洞见,现购票可享受 9 折优惠 |AICon 了解详情
写点什么

关于《规范敏捷管理人员指南》的问答

  • 2017-11-16
  • 本文字数:5950 字

    阅读完需:约 20 分钟

本文要点

  • 所有生意都是软件生意
  • 各行各业正在被敏捷企业打乱节奏
  • 规范敏捷(DA)框架能够一览全局,从开发到 DevOps 再到 IT,最后到敏捷企业
  • 规范敏捷框架在进程中起着“举足轻重”的作用,它展示部分是如何聚合为整体的
  • 每个团队、每个组织都面临独特的情况——规范敏捷采用轻量方式帮你选择最佳策略

《管理人员规范敏捷指南》解释了规范敏捷在不同组织层面发挥的作用。它提供了一个原理和实践结合的框架,通过语境相关的方式帮你实现信息科技和商业过程的简化。

InfoQ 读者可以下载《管理人员规范敏捷指南摘要》。

InfoQ 采访了 Scott W. Ambler 和 Mark Lines,询问了规范敏捷框架的宗旨、规范 Devops 思维、如何解决遗留系统的技术债、规范敏捷企业在实践中表现如何、怎样通过敏捷变革取得成功以及如何实现企业持续增长。

InfoQ:你们写这本书的初衷是什么?

Scott W. Ambler: 我们发现许多组织都存在敏捷问题。一个开发团队变得敏捷相对容易,但是一旦超出软件开发的范围,组织将很难理解并处理随之而来的困境。我们一直在帮助一些企业,它们现在在所有 IT 领域或整个组织中采用规范敏捷战略。我们感到是时候和更多人分享我们的经历了。

Mark Lines: 这是我们关于规范敏捷的第三本书。从 2012 年我们出第一本开始,规范敏捷已经发生了演变。我们的目的是写四本书,作为一个系列,更新之前的内容,以及从不同角度探讨规范敏捷,这四本书包括管理人员概要(即本书的主题)、团队规范敏捷交付(DAD)、IT 规范敏捷(DAIT)和规范敏捷企业(DAE)。

InfoQ: 这本书写给哪些人?

Ambler: 简言之,领导。这本书写给那些有勇气着眼大局的人,坦率地讲,大局实际上往往不怎么让人愉快。写给那些愿意通盘考虑组织结构的人以及那些认识到 IT 是业务敏捷的使能器的人。写给那些认识到语境重要性、每个人都面临着独特的场景且以其独特的方式表现出敏捷、一个流程并非放之四海而皆准的人。写给那些意识到尽管他们处于独特的情况中,但其他人也曾遇到过类似的情况且想出了各种对策,所以他们可以采用、改良——他们可以复用他人的学习过程,把精力放在机构中主要商业价值领域的人。

Lines: 许多人试图把敏捷简化成可在二十分钟内读完的执行“摘要”指南或者白皮书。而事实是软件开发、DevOps、IT 以及组织运作是非常复杂的问题。因此我们认真地为决策者写了这本书,解释敏捷如何在组织不同层面发挥作用。我们认为本书连贯且一致地概述了企业各种制度的相互关系。

InfoQ: 什么是业务敏捷?

Ambler: 业务敏捷需要一个适应性强、精益的、快速反应和学习型的组织。业务敏捷通过长期艰苦努力才会出现——没有捷径,没有良方,也没有解决你问题的流程框架。业务敏捷需要真正的、整个 IT 的敏捷,不仅仅是软件开发或者是能够利用 IT 能力的规范敏捷企业(DAE)。此外,随着时间推移,你的组织运行环境也会随之变化,同时你的竞争者和合作伙伴也在改变,业务敏捷在实践中证明是一个运动的目标。

InfoQ: 规范敏捷框架是什么?它的目标是什么?

Ambler & Lines: 规范敏捷(DA)过程决策框架提供轻量指导,帮助组织精简 IT 和商业流程,同时保持对语境的敏感度。这一目标的实现途径是通过展示多种活动,例如解决方案交付、运营、企业架构、投资组合管理、金融、安全、法务及其它工作如何结合起来发挥作用。该框架还描述了这些活动需要处理的问题,提供了一系列解决问题的选项,同时描述了每个选项相关的权衡。实际上,规范敏捷提供了业务敏捷的流程基础。

规范敏捷框架有四个层次:

  1. 规范敏捷交付(DAD)。DAD 通过简化方式解决了所有解决方案从开始到结束的交付问题。这包括开始建模和计划、组建团队、资金保障、持续架构、持续测试、持续开发、整个生命周期的管理。框架包括对多个交付生命周期的支撑,包括但不限于基于 Scrum 的基础 / 敏捷生命周期、以 Kanban 为基础的精益生命周期、两个持续交付的现代敏捷生命周期,以及基于精益启动的探索生命周期。
  2. 规范 DevOps 。这是 IT 解决方案开发和 IT 运营活动、附加企业 IT 活动的流程化,以给企业带来更多有效成果。
  3. 规范敏捷 IT(DAIT)。DAIT 解决了如何在 IT 各个方面采用敏捷和精益策略。这包括 IT 层面活动,如 IT 运营、支持、数据管理、重用工程学及其它能力。
  4. 规范敏捷企业。规范敏捷企业能提前预测市场变化并作出迅速反应。这一目标是通过组织文化和架构达成的,这样的组织文化和架构能够促进组织在所处环境中的变革。这种组织需要在主要业务和基础精益和敏捷过程中具备学习型心态,以驱动创新。

InfoQ: 规范敏捷框架一个重要原则是“变得更棒”,这是什么意思?

Ambler & Lines: 谁不想变得更棒?谁不想进更棒的组织,进更棒的团队,成为更棒的成员,去做更棒的事情呢?我们都想如此。近来 Josh Kerievsky 普及了一个概念,现代化的敏捷团队让人们更棒,当然我们想要更棒的团队和更棒的组织也算不上觊觎了。无独有偶,Poppendiecks 发现参与感强、善于思考的人可以获得可持续性的优势。帮助员工成为更棒的人很重要,因为正如 Virgin Group 的 Richard Branson 所说,“照看好你的雇员,他们会照看好你的生意。”

作为个人,若要成为更棒的人,你可以做这么几件事情:

  • 赢得同事的尊重和信任——可靠、诚实、开放且尊重他们。
  • 愿意同他人协作。有人请教时要跟他们分享信息,即使它还不那么全面。当别人需要帮助时伸出援手,助人者人皆助之。
  • 成为一个积极的学习者。学会精通你的技能,要不断寻找机会测试、学习。走出专业界限去了解更多软件程序和业务环境。成为 T 型“通才”,你就会重视其他人的成长过程并能更高效地和他们互动。
  • 绝不要让团队失望。不错,有时在所难免,但是好的团队可以理解并原谅你。

InfoQ: 另一个原则是“企业意识”。为什么企业意识重要?

Ambler: 当员工有企业意识的时候他们会主动去考虑整个组织的需求,确保他们对组织目标的实现起积极作用而不是仅仅盯住团队小目标。这是整体优化精益原则的一个例子,在这个案例中,“整体”就是组织,高于团队层面的局部优化。

企业意识通过一些重要方式积极改变员工的行为:

  • 他们更倾向于同企业专家一起工作并向他们寻求指导。这些人如企业架构人员、产品经理、金融专家、审计和高级管理人员决定公司业务和技术战略,决定公司整个愿景的演变。
  • 有企业意识的人更能利用和改进现有企业资产,与管理这些资产(如数据、代码、证实的模式或技术)的人协作来实现这一目标(规范敏捷宣言中的一个原则)。
  • 他们更易采用和遵守公共指南,在需要的时候进行修改,从而提高整体的一致性和质量。
  • 他们更易在团队中分享学习心得,从而加速整个组织的全面提升。事实上,规范敏捷框架优势之一,就是持续改进,即帮助员工分享学习心得。
  • 具有企业意识的人愿意工作更透明,尽管他们仍期望从别人那里获利。

InfoQ: 什么是规范敏捷 DevOps 思维?

Ambler: 规范敏捷 DevOps 思维有几个关键点:

  • 一个团队。我们是一起工作支撑我们利益相关者的一个整体团队,而不是分开的开发、运营、数据管理、安全……团队。
  • 你创建,你运行(支持、演化……)。这使团队集中于寻求高质量、可持续、可支持的解决方案。
  • 跨职能员工构成跨职能团队。选择跨职能和通才组建团队可以促进团队内协作,因为员工更能欣赏别人的工作。跨职能团队可以减少职能变革,因而可以减少产生缺陷的概率、可以缩短推向市场的时间和整体成本。
  • 架构韧性。生产过程会出事——若系统可以经受住困难甚至纠正问题,就会提高质量、带来运营上的成功。
  • 透明。团队之间越透明,越能加强成员间信任、促进合作、高效管理。
  • 持续改进。作为个人、团队或者组织,我们都要努力不断进步。
  • 从实验中学习。从来没有“最佳实践”,只有在某些背景下运作良好但不是普适的实践。发现实践是否起效最好的方法是尝试,在实践中观察,如果可能的话测试一下然后来确定实践或策略是否在你面临的情境中发挥作用。
  • 不断精益你的工作流程。不管你多优秀,你都能变得更好。
  • 整体优化。高效团队都有企业意识,能够认识到他们是更大的组织一份子。因此他们应该努力做对组织有益的事,而不是对他们自己而言更方便或者“最简单”。
  • 自动,自动,还是自动。够了!精益求精!
  • 清除技术债。如果想要对市场做出快速反应,我们需要毫不含糊地偿还技术债,最好把它完全还清。
  • 好东西重复利用。减少推向市场的时间、提高质量以及减少技术债(至少不增加)的一个重要策略就是如有可能我们就重复利用高质量资产。好的策略有 Web 服务、微服务、框架等。

InfoQ: 如何偿还遗留系统的技术债?

Ambler: 这是近几年来我们大量撰写的一个主题。事实上,我合作开发了数据库重,这是偿还数据库技术债的关键技术。

在框架规范敏捷交付(DAD)部分,我们明确提出以下解决技术债务的策略:

  1. 提前一步考虑问题,避免产生新的技术债。
  2. 团队组织要有一个能够看到长远影响的架构领导。
  3. 要有企业意识,做对组织有益的事。
  4. 通过重构解决掉技术债。
  5. 不断进行回归测试确认新注入问题。
  6. 自动化代码 / 模型的分析。
  7. 度量技术债,使你能够了解挑战有多大。
  8. 明确掌控技术债,如此高层领导可以支持你的方案。
  9. 降低技术债应该成为文化的一部分。
  10. 转移资产前解决技术债(尤其是外包时候显得更重要)
  11. 接受一部分技术债,但是要明确是哪些。

最近我们做了一项技术债和敏捷团队的研究。我们发现虽然有八分之七的团队在某种程度上拥有遗留资产,但会积极偿还技术债的还不足一半。这可不是个好兆头。

InfoQ: 实践中规范敏捷企业是什么样子?

Ambler: 每个规范敏捷企业都不同而且在不断演变。

咱们从 DAE 的几个基本概念出发:

  1. 你的组织和员工必须敏捷。尽管本书讨论的重点是高效流程,而事实是组织文化才是业务敏捷成功最关键的要素。你需要这样的员工,他们努力通过企业意识行为协作、满足客户并且不断进步变得更棒。几乎没有敏捷组织整体运作的任何建议,这也正是我们在本书特别讨论解决的一个问题。全局方案的连贯性至关重要——如果团队人员方向不一致,如果他们不以敏捷方式开展工作,就会拖累整个组织。
  2. 关键是价值流。你的组织采用一条或多条价值流给客户。价值流实际上是一条穿过整个组织(潜在合作伙伴组织)、员工协作盈利的线。要想设计最能让客户满意的价值流,一部分工作就是优化你的工作流,使其能够对客户需求做出反应。
  3. 没有一个确切的答案。因为每个组织情况不同,并且都在不断演变;因为具体情境才是问题关键,所以你必须确定一个适合你自己的方法。规范方法令人向往,因为你们似乎可以直接学习采纳。事实是你需要选择反映你实际情况的策略,这才是最有效的——选择很重要。当然实用主义会左右你的选择,不要苛求“敏捷”。
  4. 你需要意识到这点并作出反应。做个年度计划或者三年五年规划的时代已经一去不复返了。规范敏捷企业(DAEs)采用一个自适应、成果驱动的方法,然后探测 / 感知环境,随后作出反应。
  5. 必须成为一个学习型组织。不管在什么样的组织领域工作,每个人都要学习和分享技能。因为当前市场以变化莫测的方式快速演变,你必须要测试并且不断改变策略来优化价值流。此外,知识和知识性工作在现代化企业中变得越来越重要,足以说明需要不断地学习。
  6. 自组织团队需要能够快速接触到资源。让团队拥有权威和责任,以此来满足客户。高层领导必须帮助团队获得人力、资金、帮助及其它需要的资源来对市场机会作出快速反应。提供操作的边界以及运营资源的内部市场。你的目标是要使资源和主流客户需求匹配——意思是说,一些员工才能可能没有完全发挥出来,但是这一小部分才能却能对战略工作起到巨大作用,比如学习、进步。

InfoQ: 你对通过敏捷变革取得成功有何建议?

Ambler & Lines: 我们发现下面这些内容很重要:

  1. 改进是一段历程,不是终点。真正的改进需要几年的努力付出、支持和指导——而不是几天的训练,也不是几周的指导,更不仅仅只是采用一个新的工具。
  2. 许多进步过程始于变革项目,但是最终会变成一个长久的过程。在很多组织中仍然有一个项目思维,想当然的认为你可以很容易进行一个短期变革项目然后说“好,你现在已经敏捷了!”采用项目为基础的方法你很可能会有很多错误的开始,直到你最终发现改进是一个长期过程。
  3. 每次历程都是独一无二的。每个组织都是独一无二的,有它自己的挑战和优势。你必须根据自己所处的环境修正方法,没有哪种方法适合所有情况。
  4. 你的目标不是敏捷,而是更好的服务客户。你的改进要集中在变得更加敏捷或者精益上,但是真正的目标应该是用来提高你的价值流。
  5. 改进很难并且需要变化。如果改进很容易那么我们就都完美了!每个人,包括经理和高管,都必须拥有不断改进的想法。
  6. 采取拉而不是推的策略。如果你把改变强加到员工身上,如果你硬塞给他们,他们将会抵抗并且很有可能颠覆你的改变。如果员工意识到了挑战,意识到了可能的改进,愿意为了可能的改进去进行实验(把改变拉入他们的流程),改进就更容易长久。
  7. 你改进的努力需要同时解决员工(个体及互动)问题、流程和工具问题。虽然你会在帮助员工上投入的更多,但这样做的过程中你会发现同时你在帮助他们优化流程、改进需要的工具来支持这一流程。

InfoQ: 要想在企业中不断改进该怎么做?

Ambler & Lines: 实际上有很多。在书中我们解决了如何从变革策略变成持续改进策略。在“变革”阶段,你需要投入很多在训练、指导和教育上,从而能够启动组织内部的敏捷过程。然后,当新文化和工作方式把你、你的焦点带到一个更加自我维持、不断进步的策略时就不需要太多(但还要一些)投入了。

支持不断改进的策略包括:

  • 实验。团队需要进行实验来验证哪个方法在实践中更管用。规范敏捷以目标为导向的方法可以帮助你的团队确定合适的实验对象,从而加速改进流程,但是你仍需要实验来确定一项技术是否真的适合你。
  • 敏捷训练。你会发现需要对新人进行训练,或者对现有员工进行新课程培训。
  • 技能训练。员工需要不断进行测试、协作技巧、编程、数据库开发、金融等等的技能训练。
  • 实践社区(CoPs)协会。设立一些自组织团体,供员工在一起互相帮助、学习、提高。
  • 卓越敏捷 / 精益中心(CoE)。尽管在变革阶段之后敏捷 / 精益指导将会减少,但是你会发现经常需要时不时地对新员工或新组建的团队进行指导。

关于本书作者

Scott W. Ambler Scott Ambler + Associates 高级顾问合伙人,同全球各大组织合作帮助其提高软件流程。他在项目和组织层面进行规范敏捷和精益策略的训练、指导和辅导。Ambler 是多个敏捷方法论的(联合)创始人,以及多本著作的(联合)作者。

Mark Lines 是 Scott Ambler + Associates 的管理合伙人。他是一位敏捷讲师、规范敏捷框架联合创始人、多本著作的联合作者。Lines 是一位“规范”敏捷讲师,帮助全球各大组织实现从传统到敏捷方法的转型。他给众多出版社撰稿,也经常在行业峰会上进行发言。

查看英文原文: https://www.infoq.com/articles/book-review-executive-guide-disciplined-agile

感谢冬雨对本文的审校。

2017-11-16 17:141364

评论

发布
暂无评论
发现更多内容

TiDB 在 2021 易车 818 汽车狂欢节的应用

TiDB 社区干货传送门

实践案例

TiDB for PostgreSQL 学习指南

TiDB 社区干货传送门

实践案例 管理与运维

TiDB K8S 删除备份阻塞问题排查

TiDB 社区干货传送门

TiDB 底层架构 管理与运维

TiDB 集群跨平台在线迁移方案(离线环境下从 x86 节点迁移到 arm64 节点)

TiDB 社区干货传送门

管理与运维

TiDB 集群 TiKV 节点内存占用较高问题排查

TiDB 社区干货传送门

故障排查/诊断

TIDB:分布式事务算法Percolator学习笔记

TiDB 社区干货传送门

TiDB 底层架构

【TiDB 最佳实践系列】海量 Region 集群调优

TiDB 社区干货传送门

实践案例

【精选实践】58 集团的数据库技术选型思路

TiDB 社区干货传送门

数据库架构选型

使用 TiCDC 实时同步 TiDB 数据到备用逃生环境的实践

TiDB 社区干货传送门

实践案例 安装 & 部署

SQL上线引发的血案

TiDB 社区干货传送门

TiDB SQL 自动重试调研

TiDB 社区干货传送门

TiDB 底层架构

【TiDB CPU使用率过高之一】Scheduler worker CPU

TiDB 社区干货传送门

实践案例

干货分享丨携程国际业务动态实时标签处理平台实践

TiDB 社区干货传送门

实践案例

【SOP 系列 19】region 分布不均问题排查及解决不完全指南

TiDB 社区干货传送门

管理与运维

SQLserver迁移TiDB场景的实践

TiDB 社区干货传送门

迁移 管理与运维

TiDB K8S 定时备份状态异常问题排查

TiDB 社区干货传送门

管理与运维

社区资源这么丰富我们怎么抄作业

TiDB 社区干货传送门

TiDB集群的GC不回收案例(案情二)

TiDB 社区干货传送门

故障排查/诊断

生产环境 TiDB V5.0.3 集群部署

TiDB 社区干货传送门

实践案例

TiDB和MySQL的锁一些分析比对

TiDB 社区干货传送门

实践案例 TiDB 底层架构

TiDB 集群跨平台在线迁移方案(离线环境下从 x86 节点迁移到 arm64 节点)

TiDB 社区干货传送门

管理与运维

伴鱼数据库之性能大盘

TiDB 社区干货传送门

从TiDB中学习代码提交规范的重要性

TiDB 社区干货传送门

TiDB 底层架构

TiDB在X86和ARM混合平台下的离线部署和升级

TiDB 社区干货传送门

安装 & 部署

TiDB 对大事务的简单拆分

TiDB 社区干货传送门

性能调优

TiDB 入门运维基础教程(二)--生产环境安装

TiDB 社区干货传送门

安装 & 部署

TiDB 配置参数修改与系统变量修改步骤

TiDB 社区干货传送门

实践案例

都是空格惹的祸

TiDB 社区干货传送门

DM 2.0 小试牛刀

TiDB 社区干货传送门

TiDB SQL调优实战——索引问题

TiDB 社区干货传送门

性能调优 实践案例

扩容TIKV节点遇到的坑

TiDB 社区干货传送门

管理与运维

关于《规范敏捷管理人员指南》的问答_研发效能_Ben Linders_InfoQ精选文章