×

只需一步,快速开始

扫描二维码登录本站

标签: 暂无标签

#整理及翻译:林伟丹(Wand),校对:姚冬,刘伯英

#本文翻译自martinfowler.com上的The Agile Fluency Model白皮书( by James Shore & Diana Larsen),仅供个人学习及交流用途.


前言


敏捷方法已经成为主流并为多数人所接受,但尽管敏捷很受欢迎,它并不是不存在问题。组织的领导者抱怨,他们没有得到预期的收益。这篇文章提出了一个流畅度(fluency)模型,来帮助您最大限度地从敏捷思想中获益。流畅度的演进经过4个不同的区域,每个区域有它特定的收益、需要的能力水平及关键的度量。


内容索引:

   模型介绍

   选择您的区域

   获得流畅度

   失去流畅度

   组织的流畅度

    聚焦层团队产生业务价值

    交付层团队基于市场节奏交付

    优化层团队引领市场

    增强层团队让组织更强壮

   应用敏捷流畅度模型

   结论









自从90年代后期,我们一直在领导与帮助团队向敏捷开发模式转型。在那时候,我们看到了敏捷运动蓬勃发展,从以程序员为中心的怀揣激情的热心者与创新者,发展成为一个正在接管软件世界的庞然大物。


尽管取得了这样的成功,或许也正因为这个原因,敏捷方法并不总是达成人们预期的结果。对此敏捷的大咖们发表了一些文章,如Martin Flower发表了《松弛(flaccid)的Scrum》(2009)。对咨询机构的抱怨正在增加,说它们通过强制推行刻板的、不敏捷的流程来牟取利益。组织的领导者担心,他们并没有获得他们本应获得的收益。


在我们帮助敏捷团队的这些年中,我们学到了很多,关于怎么样才能以敏捷通往成功,以及为什么这么多组织没有看到它们预期的结果。2012年,我们把学到的这些东西,总结为敏捷流畅度模型,并在这里发布了出来。在过去的6年中,对这个模型的应用,又教给了我们更多的东西。现在,我们更新这篇文章,来纳入我们的最新发现。


使用这篇文章,来理解从您的敏捷团队中预期得到哪一种的收益;需要做出什么投资,来获得这种收益;当您的团队没有交付您需要的收益时,如何来分析。这有点像一面镜子。

模型介绍


我们观察到,当敏捷团队持续学习时,他/她们可以通过这4个区域。每一个区域都带来特定的收益:


1、聚焦层(Focusing)团队产生业务价值

2、交付层(Delivering)团队基于市场节奏交付

3、优化层(Optimizing)团队引领市场

4、增强层(Strengthening)团队让组织更强壮


每个区域依赖于一系列的敏捷能力水平(proficiency)。敏捷能力水平是可观测的行为,例如“团队与能提供业务视角和期望的业务代表一起工作”,这些行为促成这个区域的收益。


在敏捷流畅度模型中,我们对流畅的能力水平最感兴趣,即在任何时候、甚至在压力下都能表现出能力水平的一种习惯。课堂上讲授的很多方法,在那个容易聚焦的环境下,任何人都能够遵循;真正的能力水平是娴熟的、信手拈来的,当您的注意力被其他事情分散的情况下,依然能够坚持。


敏捷开发是一个团队运动,因而流畅度是一种团队特征,而不是个体团队成员的特征。在实践中,有些能力水平会在所有团队成员身上体现出来,而有些则是一些个体的专长。不管哪种情形,团队流畅度都来自于团队成员的自组织能力,从而这些个体技能可以在合适的时机应用到合适的问题上。


团队在一个区域达到流畅,意味着它在这个区域的所有能力水平上都达到流畅,也包括在前序的区域上达到。尽管团队可以以任何次序开发这些能力水平,甚至同时开始多个区域,我们的观察是,很多团队倾向于以一个可预测的次序来获得区域流畅度。如果需要一个可执行的概览,请跳到最后的“结论”章节。

选择您的区域


每个流畅度区域都带来新的收益,因而看起来这个模型应该被当作一个成熟度模型,以达到最大的成熟度为目标。那是一个错误。不像成熟度总是越高越好的成熟度模型,流畅度模型描述了不同的选择的集合。每一个区域代表了一个完全成熟的选择,每一个都带来价值。


可以把流畅度想象为乘坐大巴。当您登上大巴时,您买了一张车票,去往您想去的某个区域。去一个更远的区域,并不总是理所当然地具有更多价值;它只是消耗更多的代价,需要更长的时间去到那里。有时候您会买一张大巴车票去往郊区,因为您想去一个大卖场。有时候您会买一张车票去往中心城区,因为您想要去看一场演出。这两者都不是理所当然地更好,完全取决于那天您需要什么。

 

类似的,每一个区域都具有价值,每一个区域都会带来挑战。做出超过您所需要的投资,有可能招致组织的强烈反弹,甚至有可能从整体上扭曲人们对于敏捷思想的看法。

 

对您团队合适的区域,取决于您所在组织。交付层或者优化层通常是最佳的目标,但聚焦层和增强层也是不错的选择。

 

   聚焦层区域代表了敏捷的基本原理,在透明性和团队协作方面,流畅的团队提供了令人瞩目的收益。尽管聚焦层的流畅度并未包含可持续的技术实践,它已经是一个用以展现成功很棒的方式,并为进一步的投资创造认可度。这也很适合像数字化开发的一些团队,因为他们并不打算长期维护这个软件。

 

   对于那些需要改动与增强其软件超过几个月时间的团队,交付层流畅度通畅是一个更好的选择。这个区域代表了敏捷的可持续性。交付层团队有较少的缺陷、较高的生产率,并对业务需求有很好的响应性。这里的流畅度对大部分团队来说是一个有价值的飞跃。

 

   对于期望在它们的市场中引领变革节奏、或者看到了行将出现的颠覆式市场威胁的组织,将会从选择优化层区域中获益。优化层代表了敏捷的前景:创新式的业务敏捷。尽管它可以带来巨大的回报,它也需要组织架构上的颠覆式的变革。做出这些变革,对于小的敏捷组织来说,通常更容易一些。

 

   对于希望在管理理论和实践上有所创新的领导者,特别是在小型到中型规模的组织中,可能会发现增强层区域最适合他们的团队。这个区域是敏捷的可能的未来。前沿的敏捷实践似乎在往这个方向移动。但是,留心注意的是,这个区域需要研究前沿的管理理论并投资新的工作方式。


就算在单个的组织内部,不同的团队也可能适合不同的流畅度区域。在这篇文章的后面,我们会描述每一个区域涉及到的投资和收益。当您阅读这些区域时,记住每一个区域有它自己的代价和权衡。仔细思考对您合适的权衡取舍,而不是简单地假设越多越好。

获得流畅度


相比于技能(skills),流畅度更多的是一种习惯(habit)。尽管培训可以讲授相关的这些方法,技能的娴熟自如与内在流畅的能力水平,需要刻意设计的、深入思考的、日复一日多个月的练习。这来自于对从实践中学习(learning through practice)的有意识的投资。


后面层级的能力水平,比起更前层级的能力水平,倾向于需要花费更多的时间。团队越早开始着手某个区域的能力水平,团队将越早在这些能力水平上达到流畅。敏捷各能力水平之间,也是互相支撑的。因而,最好是选择一个您想达到的流畅度区域,然后同时开始实践这个区域以及所有前序区域所需的所有能力水平。

 

(当然,您也总是可以改变您的想法。从某个区域开始,然后切换到以另一个区域为目标,这并没有什么害处,只是需要花费更长的时间。)

 

当团队实践它的能力水平,流畅度会随之逐渐提高。流畅度的发展,相对于从一个区域到下一个区域的秩序井然的进步,它更可能横跨所有区域并行地提高。您可能很快能看到一些鼓舞人心的信号,但真正达到精通及可靠的流畅度,可能会进展缓慢、甚至令人沮丧。能力水平的稳定平台(plateau),会上下波动,并且以不同的速度发展。

 

影响团队流畅度的最大的因素之一,是组织的支持。我们继续以大巴作为隐喻,团队必须乘坐大巴以去到他们的流畅度区域。没有人能够替他/她们做到这一点。但组织需要购买大巴车票。如果一个组织期望达到流畅度,但又不提供必要的支持,结果注定是会令人失望的。甚至更糟的是,不充分的支持,可能引起人员流失,以及导致一种怀疑的文化,使得改进受阻。在着手您的流畅度旅程之前,确认您的组织准备好了提供这趟旅程所需的支持。

 

组织需要做出最大的投资之一,是时间。真正的流畅度,需要花费比任何人预期或想要的都要长的时间。在我们指导团队的经验中,团队需要花费2~6个月,来达到聚焦层区域的流畅度。达到交付层流畅度,需要花费另外的3~24个月,取决于代码技术债务的多寡。达到优化层流畅度,需要花费额外的1~5年,取决于组织的信任度及改变汇报结构的意愿高低。


区域

收益

投资

学习自

流畅所需时间

聚焦层

对团队工作更好的可见性;调整方向的能力

团队的发展,工作流程的设计

Scrum, Kanban, XP非技术实践

2-6个月

交付层

低缺陷和高生产率

技术技能学习期间的生产率变低

XP, DevOps 运动

+3-24个月

优化层

更高价值的交付,更好的产品决策

将业务决策与专业技能转移给团队所花费的社交资本

精益软件开发,精益创业,超越预算

+1-5年

增强层

跨团队学习,更好的组织决策

发展组织管理的新方式的时间及风险

组织设计,复杂性理论

未知

失去流畅度


稳定的团队自己失去流畅度的比较少见。在我们的经验里,多半是外部的破坏导致流畅度的丧失。

 

流畅度丧失的最常见的原因是,新的管理者决定,敏捷方法不匹配他们的愿景。没有组织的支持,没有条件继续实践他们所学的东西,团队的流畅度就会迅速削弱。这通常伴随着专业人才的流失,这些不满意的团队成员会寻找新的岗位。

 

人员流失是与流畅度丧失有紧密关联的原因。一个团队如果新进或者流失过多的成员,在维持它所学实践上就会遇到麻烦。对一个为每个项目招募新成员的组织而言,这是一个典型的问题。

 

快速的增长和强加的流程,也可能导致流畅度的丧失。成功的创业企业常常遇到这个麻烦。当它们还小时,创业企业通常天生地运作在优化层乃至增强层。(他们不一定在每一项能力水平上都非常流畅,但他们的本性推动他们朝着那些区域前进。)一旦创业企业开始快速增长,它们常常就会引入官僚主义和流程,看似无心的破坏了使能流畅度的原始流程和文化。

 

同样的,已经在单个团队成功应用敏捷思想的公司,有时候也会在他们的团队中强加一个规模化的框架。大多数的这类框架,设计上仅仅支持聚焦层的流畅度,有些设计更多的是为了迎合管理层的诉求、而非敏捷的卓越。这使得发展和维持更高层区域的流畅度变得困难。

 

那也并不是说,原始的增长就是正确的答案。增长、规模化与流畅度的关系,是一个复杂的话题,值得另外写文章来阐述。现在,我们只说一点,要达到规模化的流畅度,您必须在每一个单个团队中都拥有流畅度。当您评估规模化选项时,需要考虑您所做的选择是如何支持或阻碍你所要区域的流畅度的。

组织的流畅度


在一个敏捷组织中,组织的工作由多个团队来完成,这些团队由拥有共享目标与相互依赖工作的人员协作式地组成。结果就是,流畅度源于团队。个体或者组织可能对团队的流畅度有贡献,但它们自己不拥有流畅度。

 

尽管组织本身不拥有流畅度,但确实有必要讨论组织如何使能流畅度。团队流畅度依赖的,不仅仅是团队成员的技能,它也依赖于管理架构、相互关系、组织文化以及更多的东西。不要犯谴责个体这样的错误,认为他/她们导致了团队的流畅度缺失,或者假设一个技能高超的个体可以保证流畅度。组织的上下文,通常影响要大得多。

 

当团队在流畅度发展上遇到路障,典型情况下,他/她们挣扎在一些能力水平上。有时候问题是缺乏知识或者技能,这时培训和辅导就是所有团队所需要的。

 

更常出现的是,团队的发展实际上被组织的限制困住了。您可以通过在几个团队中施行一个流畅度诊断程序,来检查组织的限制。(敏捷流畅度项目提供了诊断选项,参见agilefluency.org。)如果多个团队都在同样的一些能力水平上遇到麻烦,那这就是一个系统性的议题,需要组织层面进行投资和变革。

 

在下面的章节中,我们描述了每个区域所需要的能力水平以及所需的组织投资。当您阅读时,思考一下哪个区域是您的组织准备好要使能的,以及哪个区域当前组织的设计会对其造成阻碍。


“聚焦层”团队产生业务价值

概要:

敏捷的基本原理

收益:

对团队工作更好的可见性;调整方向的能力

投资:

团队发展,工作流程设计

学习自:

Scrum, Kanban, XP非技术实践

时间:

2-6个月

作为一支有凝聚力的团队,流畅的聚焦层团队拥有共享的目标。他们会考虑干系人、客户和用户能够从软件中看到的收益,以此来思考和计划。这与刚刚开始敏捷之旅的团队形成了对照,后者倾向于从技术考虑(例如软件分层)的角度来思考,他/她们常常作为个体贡献者,工作在分配给个体的任务上。

 

Scrum, Kanban和XP非技术部分的实践,是团队用来达到聚焦层流畅度的敏捷方法的一些例子。用户故事是团队采用的最常见的方法。其他的方法包括待办事项列表、回顾会议、时间盒(例如Sprint)和团队任务板等。聚焦层团队也关注个体间交互的概念,例如心理安全、团队章程、集体学习与同行反馈等。

 

这个区域的团队流畅度,会至少每月一次的,展现他们工作在什么上面,以及从业务价值视角工作的进展如何。这是聚焦层团队的核心度量:这并不是您从一个流畅团队预期得到的唯一收益,但这是检验团队是否流畅的一个简单、快速的方法。如果您对团队的业务优先级不具有可见性,或者这些优先级不能反映出团队实际在做的东西,那么这个团队就还称不上流畅。

预期收益

透明

核心度量:

至少每个月一次,团队展现他们工作在什么上面,以及从业务价值的视角工作的进展如何

降低风险:

当团队在构建错误的东西、或者工作没有进展时,管理者可以知晓并有能力进行积极的干预

成效

提高生产率:

团队定期反思、调优和调整它的工作习惯,以提供更多价值

提高ROI

团队聚焦在他/她们被告知的处于对业务最重要优先级的工作上

提高ROI

每个月团队根据业务优先级取得增量进展

协同

提高生产率:

协作式的沟通降低了团队成员间的误解与移交延迟

聚焦层的收益来自于有效的沟通、协作式团队合作与持续的团队改善。在这些方面流畅的技能水平并不是一种技术挑战,对一些人来说,团队文化的转变也是很困难的。团队成员必须学习基于业务成果来制定计划,而不是基于技术。他们需要学习对整个团队的成功承担责任,而不仅是做出个体的贡献。经理们必须学习支持团队协同工作,而不是个体的奖赏和任务分配。


区域技能水平


响应业务需求

团队与提供业务视角及期望的业务代表一起工作

业务干系人可以指望团队基于业务代表的意见(确定下一件最有价值的事情)工作

团队以业务代表能理解及评估价值的分块,来计划工作并展示进展

团队的业务代表至少每月能看见并能改变团队的方向

管理者使能团队在一个地点工作,允许他们响应不确定的业务需求

有效团队协作

团队产生自己的日常任务和计划(基于业务代表的需求)

团队成员视他/她们的计划为团队的工作,而非个人的工作

团队成员共担完成他/她们的计划的责任

管理者视计划为团队的工作,而非为个人分配责任

追求团队卓越

团队拥抱并持续改善他/她们联合工作的方法

团队意识到团队成员的相互关系如何影响到他/她们成功的能力,并积极尝试改善

团队意识到工作环境如何影响到他/她们工作的能力,并积极尝试改善

投资/价值权衡:对于一群独立的个体贡献者来说,需要花费2~6个月的实践来转变到一种协作式、基于团队的工作风格。他/她们的流畅度不光取决于其努力,也取决于组织的投资。正如我们前面所说的,团队可能驱动他/她们的流畅度大巴,但组织需要先购买大巴车票。


对于许多经理和组织来说,最有挑战的投资是非金钱的。使能团队作为一个真正的团队有效工作,需要改变管理者的行为,分配专属、全职的成员到团队中,并重新设计工作空间。具体来说,经理们必须从管理个体贡献者,转变为管理工作系统,即指引团队流程、工作习惯、技能与上下文,以便团队可以在没有管理层直接介入的情况下做出正确的决策。


我们看到很多组织选择不做出这些投资,但仍然期望团队达到流畅度。在这些例子里,团队能力水平发展缓慢,很少能够达到完全的流畅度。如果您的组织不能做出这些必要的投资,那敏捷方法会让您失望。


常见的组织投资

选择有适当技能、背景及协同工作意愿的团队成员。把他/她们的人力100%分配给团队

创建一个聚焦于生产力的共享工作空间,强烈建议物理的团队空间。如果物理的团队空间不可行,提供一个可以紧密交互的虚拟工作空间来替代,并接受其有效性的降低

确保在业务优先级与客户价值方面的专业人员是可用的、并担任团队的业务代表

移除有效协同工作的阻碍,例如竞争性的评级、个体奖励、分布式团队等

指导与培训团队掌握聚焦层的的能力水平

培训经理们创建环境支持团队协同工作、以及如何管理工作系统而不是管理个体贡献

作为这些投资的回报,您将能够获取对您的团队工作的更好的可见性,您将能够指引他/她们用20%的工作付出提供80%的价值回报。

“交付层”团队按市场节奏交付

概要:

敏捷的可持续性

收益:

低缺陷和高生产率

投资:

技术技能学习期间的生产率变低

学习自:

XP, DevOps 运动

时间:

+3-24个月

流畅的交付层团队,不仅仅聚焦在业务价值上,他们还意识到根据市场的接收需要尽可能频繁交付的价值。这称为“基于市场节奏交付”。交付层团队有别于聚焦层的团队,不光在于他们交付的能力,更在于他们按需交付的能力。

 

极限编程(XP)倡导了很多为交付层团队所用的技术实践,它在今天依然有很大的影响力。几乎所有的流畅团队应用了它的主要创新,例如持续集成、测试驱动开发和“无情的”重构。

 

近年来,DevOps运动将极限编程的想法扩展到现代的基于云服务的环境。这场运动倡导的持续交付和持续部署技术,被大部分的交付层团队所使用。其他有用的技术,包括演进式设计、集体所有权、结对编程或蜂拥式开发(Mobbing)等。

 

交付层的团队流畅度生产出低缺陷的软件,基于组织预期尽可能地频繁发布。如果一个团队不能按需发布,他/她们就还不够流畅。

 

预期收益


透明

核心度量:

团队能够以最小的风险和代价,在业务期望的任何时候,发布最新的工作

降低风险:

生产生命周期中的系统性缺陷,能够被及早发现

提升满意度:

团队能够按需向经理和客户提供有用的发布预测

成就

提高生产率:

团队拥有低缺陷率,更少的时间被浪费在修复缺陷上,更多时间被投资在市场改善上

提高生产率:

团队的代码库技术欠债少,使得变更成本更低、速度更快

提高ROI

团队基于市场节奏交付,根据市场可忍受程度尽可能频繁地捕获价值

协同

提高生产率:

低缺陷与低技术负债对职业满意度与士气有益,改善员工留存率与生产率

交付层是技术最密集的流畅度区域。有很多可以学习的技能。有些(例如测试驱动开发)是易学难精的变量。团队成员学习与实践XP、DevOps及敏捷软件质量大师们描述的这些技术,并从中受益。经理需要确保团队的人员配备上协作式地拥有所有所需的专业技能,同时他/她们也需要与干系人一起工作来建立这样的预期,即认真雕琢的工作,比短期的权宜之计更有价值。

 

区域能力水平


响应业务需求

团队的产品相关的代码是生产级别的,所有最新产出最少每日提交到与生产环境相似的环境上

团队的业务代表可以按需发布(或者有其他方式使能发布)团队的最新产出

团队向业务代表提供关于需求的有用的版本预测范围

团队与业务干系人协调,以可维护、不昂贵、非预定义的方式来开发代码及其他工件

有效团队协作

程序员将代码和类似的工件视为属于团队而非个人,他/她们对变更与改善代码共享职责

团队设计、开发、交付、监控、维护团队工作的所有日常所需技能,团队都可立即获取到

追求技术卓越

当工作在代码和类似工件上时,团队成员在离开它时,对比刚打开它时,技术质量至少有少量改善

生产发布被自动化,人工开销不超过10分钟

团队不需要一个手工测试的阶段,就能产出生产级别的代码

所有团队成员意识到他/她们的专业技能如何影响到达成团队目标、降低维护成本的能力,他/她们积极寻求途径改善那些技能

投资/价值权衡:发展团队成员的技能以达到流畅度,需要花费时间和不小的开销。典型来说,交付层流畅度需要在聚焦层流畅度之后,花费3~24个月来达到,取决于团队接受到的指导的量和他们代码库中的技术负债。有着庞大数量技术负债的大型系统,甚至需要花费更长的时间。

 

培训课程可以介绍一些交付层流畅度所需的概念,但学生们常常很难把课堂范例套用到他/她们真实世界的问题上。在很多案例中,流畅度也需要引入技能娴熟的技术教练,在团队的真实世界的项目上与他们一起工作。另外,当团队学习新技能及偿还现有代码的技术负债时,时常会出现生产率的下降。

 

常见的组织投资

提供时间给团队学习新技能及伴随的生产力下降

集成非开发的技术规范(例如测试和运维)到团队中

提供敏捷技术实践的培训

引入技能娴熟的技术教练,在团队的真实世界工作中辅导团队

尽管有代价,交付层流畅度可以带来的收益是巨大的。流畅的团队生产出低缺陷的软件,并保持最小的技术负债,这意味着他们可以有更多的时间交付新特性。偿还已经存在的技术债务并看到效果需要时间,但一旦他们做到了,您将能看到更快的开发时间、更高质量的软件、以及显著改善的响应力。

“优化层”团队引领市场

概要:

敏捷的前景

收益:

更高价值的交付,更好的产品决策

投资:

将业务决策与专业技能转移给团队所花费的社交资本

学习自:

精益软件开发,精益创业,超越预算

时间:

+1-5年

流畅的优化层团队理解市场需要什么、业务需要什么、以及如何满足这些需要。或者,在一个创业环境里,他/她们知道需要学习哪些东西以及如何去学习。与交付层团队对比,优化层团队不仅有能力面向市场交付,他们也知道应该交付什么给市场。

 

大多数的敏捷方法,被设计来帮助团队达到聚焦层或者交付层的流畅度。为了赢得优化层区域的流畅度,请以交付层的基础(例如Scrum + XP + DevOps,Kanban + XP + DevOps,或者就是简单的XP + DevOps)出发,然后在这些基础上叠加上以产品为中心的一些方法。

 

精益创业与精益软件开发都是可以开始采用的好实践;这两者尽管名字类似,但它们是不太一样的方法。经理也将从熟悉“超越预算”实践中受益。至此,准备好寻求一些聚焦于产品的方法,有用的方法例如客户探索、持续产品探索、设计思维、用户故事地图、适应性计划等。

 

流畅的优化层团队对市场有很好的理解。它们知道为什么他/她们要构建这些东西,而不仅是他/她们要构建什么东西。至少,从与流畅的交付层团队的交流中,能够感知到关于他/她们产品在市场上的地位的头脑清晰的观点。

 

如果团队缺乏这种对产品与市场的理解,或是生产出来的价值小于他/她们的机会成本,他/她们就还没有达到优化层的流畅。作为必然的结果,流畅的优化层团队会与管理层协调、来取消(或调整方向)低价值的产品和提案。

 

预期收益


透明

关键度量:

团队描述他/她们的产品在市场上的地位,以及他们将如何提高产品的地位

降低风险:

团队与管理层协调以及早取消(或调整方向)低价值的项目

成就

提高ROI

团队交付的产品满足业务目标与市场需要

提高ROI

团队从市场反馈中学习,以预测客户需要并创造新的业务机会

提高ROI

团队包含宽泛的专业技能,以促进最优的成本/价值决策

协同

提高生产率:

团队宽泛的专业技能消除移交,并加速决策制定

提高生产率:

团队与组织间的相互信任促进快速、有效的协商

使能优化层流畅度的最大的挑战之一,是关于团队对于它的产品方向的真正控制。优化层团队和交付层团队之间的差异在于,在团队章程的约束之内,优化层团队对于为什么提供资金、及工作聚焦于哪里,可以做出它自己的决策。经理们需要把这个权力授权给团队,这对组织来说常常是一个困难的变革。

 

当然了,要拥有这些决策,团队需要拥有做出正确决策的洞察力,或者至少知道什么样的实验能够帮助他们探索正确的决策。获得那样的专业技能通常涉及到吸纳非开发人员作为全职的团队成员。常见的例子包括产品经理、业务分析师以及领域事务专家,但也可能包括来自于市场、销售或者客户支持的职员。

 

这些组织架构变化,需要来自于组织高层的许可。做到这一点可能会很困难。尽管您有意雇佣新的职员来填补这些空缺,但通常更有效的方式是吸纳已经理解您的业务的独特优先级与约束的现有员工。

 

开发和测试人员,特别是那些在公司里有资历的人,也可能是令人意外的产品专业人士的有用来源。当您寻找人员为团队带来业务专业技能时,别过高估计给资深技术人员培训业务技能的可能性。销售电话与客户拜访,也是提供新的视角的很棒的方式。

 

区域能力水平


响应业务需求

团队以与管理者联合定义的业务成效度量,来描述它的计划和进展

团队视需要与内外部利益干系人协作,以决定版本预测何时及是否能够拥有最佳的投入产出比

作为可信赖的自组织团队工作

团队与管理者协调,来理解与梳理他/她们在实现业务战略中的角色

对于实现他/她们与管理者一同定义的业务成效,团队共同承担责任并共同接受问责

管理者给团队提供他们自组织实现业务成效的资源和授权

管理者确保团队用以理解市场并实现业务成效的所有日常技能,都能在到全职团队成员身上体现

追求产品卓越

团队与客户及市场紧密互动,以理解产品需要与机会

团队创建关于业务机会的假设,并进行实验来测试它们

团队以这样一种方式计划及开发工作,假设在一个月之内收到变更,他/她们可以完全地、没有浪费地变更计划

投资/价值权衡:给予团队制定决策的权力以及相应的专业技能,对于现存的组织架构是一个挑战。它可能需要花费几年的时间,不是因为需要的这些技能,而是因为在做出影响他/她们的权力、控制与其熟悉的工作方式的变革之前,经理和组织领导者必须学习信任他/她们的团队应用敏捷思想。

 

投资在这些变革上,需要理解积极的政治技能,并对价值回报深信不疑。倡导者们将需要付出他/她们的社交资本,来让这件事情发生。经理们可能需要一些指导以支持高绩效的敏捷环境,伴随着他/她们的工作变化,从战术性的决策制定,改变为定义团队方向及统筹跨组织的协同。

 

常见的组织投资


分配100%的专属团队负责特定的产品或市场

吸纳业务与领域事务专家作为全职的团队成员。别假定一个人是足够的。

赋予团队对于预算、计划和结果的责任;用结果来评判他/他们,而不是对计划的遵从度

使能并要求经理们进行跨组织的协同工作,来移除影响团队绩效的障碍

为经理们提供关于高绩效、自组织的敏捷团队改变管理工作的性质的指导

优化层流畅度降低沟通成本,消除官僚的移交,使能对变化的业务环境的快速响应。它的投资打破了现状,因而对任何组织来说都会引起不适。但是对于那些期望在市场上引领变化的组织来说,在优化层流畅度上的投资,是值得考虑的。

“增强层”团队让组织更强壮

概要:

敏捷的未来

收益:

跨团队学习,更好的组织决策

投资:

发展组织管理的新方式的时间及风险

学习自:

组织设计,复杂性理论

时间:

未知

优化层团队有能力理解及实现市场需要,增强层团队也在他们的组织中扮演了影响更大的角色。

 

增强层团队在以下三个方面对组织产生贡献:

 

首先,他/她们理解他/她们是如何作为一个更大的系统的一部分的。他/她们理解,他/她们的目标是如何与其他团队的目标协同进而达成一个更大的战略。他/她们积极努力,来让这个战略更加成功。

 

其次,他/她们有意识地在组织内传播专业技能。他/她们寻找机会来为其他团队贡献技能,并从其他团队身上学习。

 

再次,组织在团队中分散方向性决策的制定。领导者精心设计组织架构,以精炼多团队的集体洞察,并引导他/她们施行组织改进。

 

我们看到了增强层的实践在全世界组织中的尝试和闪光。诸如ValveSoftware、Semco、Zappos、和AppFolio等公司,正在这个空间上进行实验。我们也看到,像团队自选择、开放空间战略会议这样的前沿方法增强了领导敏捷团队的附着力。那也就是说,这些区域是带有投机性的。我们认为它可能是敏捷的未来,但实际上我们并不确切地知道它会长什么样子。


尽管我们不完全确定这个区域会形成什么样的样貌,我们已经看到足够多的样例,来得出流畅团队所能提供的收益的结论。

 

预期收益


透明

关键度量:

团队在业务其他提案的上下文中描述它的工作,允许产品之间彼此平衡

降低风险:

团队及早提出并帮助解决跨组织的瓶颈与问题

成就

提高ROI

团队参与多团队活动,以优化组织价值流

提高生产率:

团队识别他/她们何时能对其他团队的工作有所贡献,并且当那些工作更为重要时,调整其工作以帮助之

协同

提高生产率:

团队与其他团队及组织中其他部分进行“异花授粉”,分享观点、上下文、学习与创新

这个区域对于拥有希望探索前沿管理理论与实践的领导者的组织来说,是最合适的。它需要工作在前沿的管理理论上,投资新的工作方式并应用到敏捷团队上。

 

如果您关心这个区域,研究一下复杂性理论(例如Cynefin与人类系统动力学)以及在组织设计方面的新思路(包括可替代的治理架构,例如开放空间敏捷性、社会政治与独裁政治等)。

 

就算您并不渴望这个区域的流畅度,在这个空间发展出来的有些方法也值得考虑一下。正如一个流畅的交付层团队会拥有交付层实践的某些能力水平,您也能从增强层实践中受益。团队自选择和开放空间战略会议,是两个我们直接经历过的实践,它们都值得尝试一下。

 

对大多数组织来说,增强层流畅度可能最好是作为一个远期的主意先放在一边,至少等到优化层流畅度已经触手可及。但是,对于已经强调精益原则与系统思考的小一些的组织而言,它们已经倾向于把决策制定分散给团队、并且重视有远见的方法与创新性的流程的价值,增强层区域提供了一个大胆的挑战及一个引人入胜的谜团。

应用敏捷流畅度模型


正如George Box所说,“所有模型都是错误的,但有些模型是有用的。”敏捷流畅度模型是真实世界的一个简化的视图。尽管它做了简化,但我们发现它准确地映射了大部分组织的需要。虽然它可能并没有完美的匹配现实,但我们所描述的收益、投资与能力水平,都是有用的讨论主题。

 

您可以用如下三种途径来应用这个模型:


第一,应用它来看清您的组织需要做出哪一种敏捷投资。不充足的投资,不仅导致缓慢的进展,它还滋生了持续的怀疑和忿恨。我们太多次看到过这样的失败,应用这个模型来确保您的期望与投资是协同一致的。

 

第二,如果您没有看到期望的流畅度,这个模型能帮助揭示什么地方出了问题。进行一次诊断程序,来探知团队在哪些能力水平上遇到困难,然后提供培训和支持。(敏捷流畅度项目在aglilefluency.org上提供了一些诊断选项。)如果多个团队都在同样的一些能力水平上遇到麻烦,那问题就可能是系统性的,需要考虑一下组织变革。

 

最后,这个模型是可用于协同关于不同敏捷方法的讨论的有用方式。对不同敏捷思想的讨论容易陷入泥沼,争论具体的方法、工具和实践。更好的做法是,应用这个模型,来促进人们关于想达到什么以及如何使它成为可能的讨论。


您可以使用及调整敏捷流畅度模型图,放入您的演示材料中。您也可以分享这篇文章,来建立关于团队能力水平与组织需要的讨论。对于衍生性的工作,例如重新发布能力水平的列表,请您与我们联系来获取许可。

 

如果您需要人帮助应用这个模型或者诊断流畅度挑战,敏捷流畅度项目上有联系信息及附加资源。可访问agilefluency.org来获取更多资料。

结论


在我们与敏捷团队与组织一起工作的过程中,我们看到了团队在施行他/她们理解的敏捷方法上依循的典型的发展进程,以及他/她们的组织获取的收益。我们把这个发展进程归纳为四个流畅度区域。每个区域的特征被概括为独特的收益与面临的不同的挑战。

 

第一个区域,聚焦层,需要团队学习协同工作,以聚焦在创建业务价值上而不仅仅是完成技术任务上。回报是,组织获得对团队工作更大的可见性,并有更多的机会来影响那些工作朝着积极的方向前进。这个区域体现了敏捷的基本原理。

 

第二个区域,交付层,需要团队投资在学习宽泛的软件开发技能上。这个区域体现了敏捷的可持续性。这些技能来之不易,但如果有时间及充足的组织支持,团队可以构建能力,来基于市场接收需要,尽可能频繁地创建与发布低缺陷软件,这给予组织新的机会来实现软件开发投资的回报。

 

第三个区域,优化层,代表了敏捷的前景:一个舞蹈着与转动着的团队,快速响应市场环境,协同负责构建您的投资所能产出的最好的产品。实现这个区域的流畅度,意味着业务专家必须作为全职的贡献者加入团队,并且,虽然组织架构的变化是有挑战的,在团队服务您的业务方面的能力提升上,可以得到回报。

 

第四个区域,增强层,代表了敏捷的未来。增强层团队与其他团队一些协作,来改善他/她们的整个组织。触达这个区域,需要创新的思想及积极的实验意愿。

 

所有的这些区域都提供了收益,每一个区域都是对某些团队而言的合适的区域。应用这个模型,来启发关于您的组织希望支持哪个区域的讨论。一旦您选择了您的区域,考虑达到流畅度所需的投资,并完全地承诺做出那些投资。

 

团队需要时间来发展他/她们的能力水平。他/她们将逐渐发展这些能力水平,上下波动,并达到某个稳定平台。从一开始就实践尽可能多的能力水平。流畅度区域代表了自然的稳定平台,在其上您会看到不同的收益与需要克服的挑战。

 

意识到组织中某些可能阻碍流畅度的上下文。留心注意以同样的方式影响到多个团队的系统性的问题这通常是需要采取某些组织变革的征兆。

 

我们看到了很多团队一次又一次地历经这些流畅度区域。通过跟您分享我们的经验,我们希望您将在关于施行敏捷方法的可能性、以及关于对它们所面临挑战的更好的理解方面,获得更好的洞见。祝您和您的团队,实现更高的流畅度,取得更大的成功。


区域

收益

投资

学习自

流畅所需时间

聚焦层

对团队工作更好的可见性;调整方向的能力

团队发展,工作流程设计

Scrum, Kanban, XP非技术实践

2-6个月

交付层

低缺陷和高生产率

技术技能学习期间的生产率变低

XP, DevOps运动

+3-24个月

优化层

更高价值的交付,更好的产品决策

将业务决策与专业技能转移给团队所花费的社交资本

精益软件开发,精益创业,超越预算

+1-5年

增强层

跨团队学习,更好的组织决策

发展组织管理的新方式的时间及风险

组织设计,复杂性理论

未知

致谢


作者们感谢Arlo Belshee、Lisa Crispin、Jutta Eckstein、Martin Fowler、Steve Holyer、Ron Jeffries、David Lokietz、MaryPoppendieck、Justin Redd、Linda Rising、Nancy VanSchooenderwoert、Rebecca Wirfs-Brock和Woody Zuill对于这篇文章2012年版本早期草稿的富有洞见的反馈。他们也感谢EllenGottesdiener、Jakob Wolman、JuttaEckstein、Lisa Crispin、Martin Fowler、MatteoVaccari和Ramakrishnan Sitaramnan 对于这篇文章2018年版本早期草稿的富有洞见的反馈。


(全文完)


微软DevOps技术社区持续招募中



我们的DevOps社区仍然继续招募中,希望加入的小伙伴可以扫描下面的【DevOps社区运营助手】二维码添加好友并申请入群。



77949.jpg
DevOps

写了 3 篇文章,拥有财富 0,被 1 人关注

www.XinBIM.com
转播转播 分享淘帖 踩!踩!
回复

使用道具

评论

使用高级模式,上传图片!
您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

返回顶部