内容简介：敏捷管理咨询10步法
通过多年的咨询实践，笔者发现为了能有效的助力敏捷实施落地，企业的敏捷管理咨询应该遵循一定步骤，即10步法，从而高效的开展咨询活动：
步骤一：确定企业的敏捷实施目标
只有清晰的了解企业想要采用敏捷的原因，明确其目标，才能制定出有针对性的实施方案，所以确定敏捷实施目标是所有咨询活动的重要开端。
通常与敏捷管理咨询接洽的是企业敏捷转型负责团队，咨询顾问需要和这个团队的负责人和其它重要的干系人沟通，了解为什么要采用敏捷？从而确定敏捷实施目标。
当某些业务部门单独提出来转型需求，就需要与这些业务部门负责人沟通；若是高层（CEO、CIO等）直接提出来转型需求，这就需要与这些C-level的高层沟通。
一些企业的敏捷实施目标并非单一的，例如下面是一家国外银行敏捷实施的目标：
-
建立敏捷的工作方式。
-
在组织结构方面，确立具有适应性的组织和清晰度。
-
采用DevOps 的方法和IT中的持续交付，能够更频繁地发布新的软件版本——每两周一次，而不是像过去一样每年进行五到六次“大型发布”。
-
更好的激活创新的能力，能使我们成为当地第一大移动银行。
而有些企业的敏捷实施目标可能相对简单，例如只是想重点实施XP的实践或是提升产品内建质量。
下图是VersionOne最新发表的敏捷状态调研报告中统计出来的采用敏捷的原因分类图，可以在确定敏捷实施目标时进行参考：
步骤二：确定敏捷试点范围
造成很多敏捷管理咨询效果不佳的原因之一是没有采用试点方法，从而导致项目、团队及企业组织的配合节奏失调，使敏捷推进步履维艰。因此在确定敏捷实施目标后应该圈定试点范围，由小入手层层推进。
确定敏捷实施目标时可以想的大些，所谓的Think Big，真正开始实施咨询时，需要Start Small, Move Fast的思维，这与敏捷的小批量快速交付理念一致。所以，可以先从最适合采用敏捷、能最快从敏捷中获益的业务来试点，让大家看到采用敏捷的好处，促进敏捷的快速推广。笔者咨询过的几家企业，均采用在大目标的指引下，先从移动互联网产品、数字化转型项目开始敏捷试点；对于那种稳定性很强、变化不大、市场增长率低的项目，敏捷转型可以暂缓 。通过这种方式，几家企业的敏捷实施均能够快速展开并获得良好的效果。
下图是选取敏捷试点项目的参考规则：
根据笔者的咨询经验，刚开始试点时，为了试点质量和效果，一般1个咨询师最多同时带3个左右的试点团队。扩展敏捷团队时，有内部教练的协助和标杆团队的示范，咨询师带的团队可以逐渐多一些，不断3到4个的扩展。
步骤三：访谈敏捷试点团队
确定好敏捷试点范围后，咨询师在接口人的协调下，首先举行一个简短的启动会，向员工传达整体的战略，形成一致的目标，达成共识，避免执行时出现各种偏差。然后组织项目的相关人员进行访谈，了解项目的背景、现状及痛点等。
访谈的人员角色包括业务代表、需求分析人员、项目经理、开发Lead、开发代表和测试代表等，每个角色尽可能都覆盖到。每个团队的访谈时间建议控制在2到3小时内。访谈的内容大纲可以根据AMM的评估项和敏捷实施目标建立，并在访谈后总结长项和弱项及痛点 。
除了访谈AMM相关内容之外，最基本的项目背景信息也需要了解，包括：
-
团队组成和地理分布。
-
产品愿景。
-
业务现状、发布情况、用户反馈、产品之间依赖关系。
-
技术栈。
-
业务的发展方向。
访谈的具体方式应当多样化。除了在会议室的面对面交流之外，咨询师还需要到开发现场实地查看——所谓的Go See方式——看看团队工作的场地、产出物、 工具 平台等，更客观的了解现状。
步骤四：组建敏捷试点团队
接下来的活动是组建适合的敏捷团队，这对敏捷咨询的高效实施非常重要。敏捷团队的组建方式有多种，常见的是：依照地域划分和依照产品发展阶段划分。
依照地域划分，可以组建同地共置的敏捷团队和分布式敏捷团队：
同地共置
所谓同地共置就是隶属于不同的职能部门的业务人员 、用户体验设计师、开发和测试人员等各种角色的人在同一个地方工作。
Product Owner和Scrum Master这两个角色很重要，咨询顾问和管理人员应当一起挑选合适的人选。他们对敏捷实施有热情、学习能力强、并且具备专业知识。Product Owner和Scrum Master相当于团队的“将”，“将”有问题，敏捷实施的风险和波折就很大。还有CI Owner角色，对于加速推动持续集成和持续交付也非常重要。
在这种方式下咨询师协调让团队成员尽可能坐在一起，加强面对面交流，建立作战空间。在办公空间这个环节，建议将传统的隔断式的办公空间改造成敏捷开放办公空间。笔者咨询的不少企业，陆续开始改造办公空间，与敏捷工作方式相适应。
分布式团队
分布式团队就是不同角色的人员，分布在不同的地理空间。
因为团队成员分布范围比较大，所以除了Product Owner、Scrum Master和Team三个角色之外，还需要在开发团队建立一个BA的角色，他与Product Owner的职能一样，作为Product Owner与团队的沟通桥梁，并协助Product Owner的工作。同样，几个关键角色的选取很重要，咨询顾问都需要与管理人员一起挑选和面试。
在工作模式上应采用Always-On虚拟协同模式——每个Site购置大屏幕VC设备，帮助分布在不同地点的团队成员虚拟的面对面沟通，及时解决问题。
不管是同地共置团队还是分布式团队，都要是全功能的，各个角色紧密衔接协同作战。但长远来看，建立国内的敏捷团队时应当尽量减少分布式模式，而把业务端到端的实施人员尽可能集中在一个区域，不同地域负责不同的业务线。如西安公司负责移动端产品的研发，深圳公司负责硬件相关产品的研发。
笔者咨询过的一些企业很难一下打破传统职能矩阵式结构，先采用了将各个职能部门的人员组成一个全功能产品团队的方式（特别是测试部门，把测试人员分散到不同的敏捷团队，测试前移，完全与业务和开发一起并行工作）；而部分企业则进行了颠覆式的组织结构变革。例如一家国外银行，他们参考了Spotify的敏捷组织结构形式，打破了传统的Silo模式，形成了十几个所谓的部落包括约300多名9人的“小队”，并且也改造了办公室。
依照产品的发展阶段，可以建立标准的Scrum团队和精益创业团队。
标准的Scrum跨职能团队
对于稳定的产品或是拓展期的产品，实施敏捷时可以建立标准的Scrum跨职能团队。
精益创业团队
对于创新产品，则需要组建精益创业团队－ 低成本、跨职能小团队。
因为在还没有获得足够的证据来支持某种业务及其经济模型时，不应该在任何工作上进行过多投资，并且这种探索必须由小的跨职能团队在一个有限的“跑道”内完成，并且团队完全是自组织、内在激励的。
步骤五：制定敏捷实施方案
根据访谈结果和敏捷团队结构，咨询顾问制定有效的敏捷实施方案，并与试点团队沟通，达成共识。
通常的敏捷实施方案有以下几种：
1) Inception ＋ Scrum/Kanban ＋ XP ＋ CI／CD 针对独立的产品
2) EDGE＋ Scrum/Kanban ＋ XP ＋ CI／CD 针对大型投资组合系统
3) Lean Innovation ＋ Scrum/Kanban ＋ XP ＋ CI／CD 针对创新产品
这三种方案主要是在前期快速启动时，根据产品的不同发展阶段和产品规模不同，选择了Inception、EDGE和Lean Innovation三种不同的业务梳理切入方式，进入交付阶段后基本都一样。前期的快速启动，是ThoughtWorks敏捷咨询很特别的地方，因为敏捷开发理论并没有告诉业务问题如何解决，而敏捷的成效最后归属于业务受益，所以敏捷实施必须从业务问题梳理切入 。笔者咨询过的一个客户发出这样的感慨：“作为业务方，我们是敏捷的最大收益方，所以业务会全力投入，各位咨询顾问多支持我们。”，所以前期以解决业务问题为出发点的快速启动很重要。
敏捷实施一定离不开技术实践，所以管理咨询顾问不仅在访谈时需要与技术咨询顾问结对访谈，在制定敏捷实施方案时也需要与技术咨询顾问紧密合作。
步骤六：开展敏捷松土培训
真正实施敏捷之前，咨询顾问需要给敏捷团队全员进行1到2天的敏捷导入培训，打造知识体系。而后在实施过程中根据团队的执行情况，还会增加一些专题培训，比如：用户研究、用户故事拆分Workshop、BDD、敏捷测试等。
除了团队成员的敏捷导入培训之外，还必须包括给中层管理者的敏捷适应性领导力培训。因为企业在变革过程中，推动变革的中坚力量是中层管理者，大量中间层管理者在企业响应力的提升以及责任承担方面起着举足轻重的作用。从组织级角度，咨询顾问需要帮助这些中层管理者提升其敏捷适应性领导力。
笔者咨询过的一些企业中有负责培训的培训部门，纳入了Agile Awareness 2小时的敏捷扫盲培训及Agile Foundation 2天 Workshop形式的敏捷高阶培训，还有Scrum、Kanban、DevOps等系列专题的内训课程，对后续的新员工培训及辅助教练做培训非常有帮助，形成持续造血的机制。也有些企业有专门的敏捷学院，有不同层次的不同形式的课程，全面推行敏捷方法，比如：某国外金融企业由CIO亲自牵头成立了敏捷学院（Agile Academy），通过集中的分享学习帮助各级管理者理解敏捷开发的术和道，成为内部的造血工厂，大大降低了转型中由于人员思想观念束缚带来的阻力。ThoughtWorks在印度有ThoughtWorks大学，为刚毕业的新人，提供为期5周的内训，持续深入理解精益敏捷的精髓和文化，并且通过项目模拟，亲自实践精益敏捷的实践(刻意练习)，回到项目团队能够切实落地使用。
步骤七：启动敏捷导入活动
敏捷导入活动依据产品的不同发展阶段会有所不同，可以分为一下几类：
-
探索新业务——新产品已经开发一段时间后，需要采用敏捷的方式继续开发。
-
拓展已验证业务——产品的第一个MVP发布后（仍处于产品的拓展阶段），需要采用敏捷的方式把产品做大做强。
-
优化成熟业务——产品已经发布并处于稳定增长期，需要采用敏捷方式对后续功能进行开发。
针对上述三类产品，在敏捷启动阶段应当通过关键干系人以工作坊形式对产品的价值体系进行再认识和梳理，建立达成共识的价值模型，并且对当前需求以敏捷的方式进行定义，排序，制定出启动迭代的初期计划。下图是具体的敏捷导入的一些代表活动：
- 企划一个新产品，将采用敏捷方式开发。
对于一个新产品，敏捷导入活动可以采用ThoughtWorks的2周左右的Inception。Inception是通过业务和技术部门的互动协作、结合产品策略、体验设计、技术架构、交付计划的敏捷软件交付项目启动实践。它为高效进入开发，奠定坚实基础。
- 开发一个创新产品
对于创新产品，可以采用Lean Innovation的启动方法——Discovery Workshop + Inception Workshop. 
- 大型投资组合管理
对于大型项目集投资组合管理(Program Portfolilo Management)，可以采用EDGE的启动方法。EDGE是ThoughtWorks提出的一套基于组织的愿景和目标进行投资分配和监控的决策系统，立足于寻求企业投资组合管理价值最大化。它使得企业可以快速响应市场机遇，有效的将组织的战略目标与执行能力紧密的联系在一起。通过明确商业愿景、制定产品策略、专题分析和组合管理、制定最小可行产品、精益交付以及持续衡量价值来提升业务响应力。
步骤八：试点迭代正式启动
进入交付阶段，试点迭代采用1+1+1模式：第1个迭代，顾问指导；第2个迭代，顾问反馈；第3个迭代，顾问评估。至少通过三个迭代形成团队的敏捷迭代开发节奏、可视化项目管理能力和团队协作意识及沟通能力。有些团队可能会慢一些，需要历练5-6个迭代。
为了让团队对迭代活动有个全景了解，迭代活动日历是个很好的展现方式，下面是一个案例，并且帮助团队建立好节奏。
试点初期的度量主要考虑迭代燃尽图、迭代速率(迭代产能)、持续集成的频率、持续集成的故障修复时长、发布周期、业务响应力。后期逐渐增加自动测试覆盖率、业务的需求价值成效指标分析等。
笔者在咨询中经常碰到团队对迭代各项会议的抱怨，主要是对会议的目标、过程、产出不明确，特别是前期准备工作不足，导致会议低效。咨询顾问辅导后，特别是对Scrum Master进行各类会议的Workshop 培训后，迭代管理不断提升。
在迭代过程经常遇到的另一个方面的问题是技术实践相关的障碍。技术实践花费的时间会比较长。对于持续集成，如果各方面的环境能准备好，并且持续集成工具也确认可用了，CI Owner能在教练的辅导下积极搭建CI，3个迭代内差不多能搭建好，但是持续集成流水线中的自动测试会慢一些。要想让自动测试落地，需要设定好演进目标和路线。
笔者在推动自动测试中，也采用了敏捷的方法：
-
每个迭代让Tech Lead和技术人员一起选择最值得做和能做单元测试的故事，先让一部分人尝试做起来，技术教练结对辅导，并且集成到CI中，让团队看到收益。
-
下个迭代，再选取一些能做单元测试的用户故事，扩展到一些没做过单元测试的开发人员，他们可以向已经做过单元测试的人员请教，也可以和技术教练结对，这样单元测试就一个个迭代小批量的做起来了。
-
几个迭代后，所有的开发人员都尝试做过单元测试了，能力慢慢培养起来了，也不惧怕单元测试了。
-
接下来逐渐再扩展API自动测试和契约测试。测试人员UI级别的自动测试，也可以小步快跑的计划去做。
对于重构或技术改进，鼓励技术人在每个迭代中提出技术故事，并且进行优先级 排序 及工作量，技术和业务同步成长。
步骤九：季度性的评估改进
敏捷试点一个季度之后，应当用AMM评估模型进行评估，看看效果和问题，以便持续改进。
评估需要遵循两条原则：
-
由第三方评估 - 这里第三方指“外聘的咨询公司顾问”或“内部合格的教练”，保持客观。
-
现地现物 - 由评估者前往团队的实际工作场所，通过以下几种方式了解真实发生了什么，据此进行评估。
方法一：观察实际工作。比如参与团队的迭代关键活动（需求讲解、估点、迭代计划、站会、评审演示、代码审查、回顾、SoS会议等），了解团队实际的工作情况。
方法二：面对面访谈。比如和产品负责人PO/业务分析师BA，Scrum Master，开发测试骨干，持续集成负责人等面对面交流。为了有趣或挑战，面对面访谈可也以做成答辩的形式。
方法三：检查过程产出物。比如物理板/电子板，产品待办清单、故事、测试案例、缺陷等，CI流水线、构建任务和历史、单元测试、自动化测试案例、知识库，概要设计、接口设计、原型图及其他相关产出物。
方法四：查看度量数据。
每个评估问题可以采用0-5分的打分再加上权重，得出最后的分数：
每个问题，也可以采用答案形式的回答，每个答案有一个记分规则。
评估的结果通常以雷达图的展现方式，下面是几个案例：
评估完成后，需要与关键的角色详细沟通评估的结果，达成共识。Scrum Master也需要安排时间给团队成员逐条讲解评估的结果，让团队成员了解现状，共同改进。
因为是阶段性的大评估，可以在外部教练或内部教练的引导下，和团队一起制定大的专题改进，可以采取Improvement Kata的方式。
对一些专题项目，比如：CI／CD、微服务等，可以进行更细化的专题评估，ThoughtWorks都有对应的CIMM，CDMM，MSMM(微服务成熟度评估模型) 评估模型。
阶段性的评估报告非常重要，需要向高层领导汇报，看看敏捷实施目标的达成情况。最好能总结成案例故事。
步骤十：扩展敏捷团队范围
当敏捷试点团队至少经过1个季度的刻意练习，并且已经从敏捷中获益，能做为标杆，能给其他团队带来正面影响时，可以考虑扩大敏捷团队。扩大敏捷团队时，依然需要结合敏捷实施目标和参考选取敏捷试点项目的参考规则，优先选取最适合和最需要敏捷的项目。
扩展敏捷后，敏捷实施的方法稍有不同，让敏捷标杆团队发挥带动作用，鼓励和引导敏捷标杆团队中的关键角色展示案例并且培训新的敏捷团队。
总结
总而言之，企业的敏捷管理咨询过程中会遇到各种各样的问题，通过上述的10步活动，咨询顾问可以结合企业中项目的具体实践情况灵活的采用各种敏捷手段解决这些问题，从而获得良好的咨询效果。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Beginning XSLT 2.0
Jeni Tennison / Apress / 2005-07-22 / USD 49.99
This is an updated revision of Tennison's "Beginning XSLT", updated for the new revision of the XSLT standard. XSLT is a technology used to transform an XML document with one structure into another ......一起来看看 《Beginning XSLT 2.0》 这本书的介绍吧!
