正在“部署敏捷”的你是不是“真敏捷”?
2018-06-11 来源:
作者:CA Technologies高级技术总监Doug Dockery
时至今天,相信大家都已经听说过“敏捷”这个词。许多公司甚至很可能已有专门的敏捷团队。大多数软件驱动的公司希望通过从事敏捷(doing agile)开发来协助解决重大的业务和组织结构问题:诸如各种未兑现的承诺、不尽如人意的质量、缺乏可视性、成本过高、协作性差,以及创新进度缓慢等等。但很可惜,有许多公司发现他们并没有从敏捷投资中得到预期的结果。事实上,“部署敏捷”,尤其是在团队层面,与“变敏捷”即成为一个敏捷企业完全是两回事。坦白来讲,仅仅部署敏捷并没有多少实际价值。
其实这并非敏捷团队的错。公司战略与执行不一致,导致团队成果与预期南辕北辙是见惯不怪的事情。这些公司一般在组织架构中存在巨大的“脱节”。那些知道如何弥补这一脱节的公司可以确保正确的投资,并以正确的方式组建。但更重要的是,他们可以定期以较低成本改变正在创建的产品,以紧跟市场需求,在开发过程中创造最大价值。这是在规模上实现精益/敏捷对于打造真正的敏捷企业的保证。但要如何实现呢?
对Scrum的迷惘
在提供企业咨询时,我通常会提出以下三个问题:1)你的团队结构怎样?2)团队的工作流程怎样?3)你会怎样计划?典型答案都会关注团队数量、角色、技术、流程、估算故事价值、sprints长度等等。我们总能改善团队层面的行为准则,但那又如何?每家公司都可以有Scrum团队,但绝对不可以迷信Scrum框架会解决公司所面临的重大问题。事实上,如果你所做的一切只是依赖这些单独的Scrum团队,其结果可能比瀑布开发模式更糟糕。
让我们潜心思考一下。如果你的敏捷团队的成员认为用瀑布开发模式更好,其中可能的原因就是:在瀑布模式中,当我们对工作所知甚少时,我们会预先作出决策。经验告诉我们项目将会推迟且超出预算,但我们会知道构建的内容,因为范围是固定的。与之相比,被称为“自然法则下的Scrum”(Feral Scrum) 的优化团队能够快速交付软件,而他们则只在Scrum模式下埋头做着自己的工作。有时,他们与组织的唯一联系就是唯一一个跟其他模式共享的产品负责人。他们投入许多资源进行开发,但我们不知道他们要交付的产品是否就是我们目前真正所需要的。
首要问题
我们先不谈出色的团队执行未能解决我们的业务问题,让我们来看一下如何计划工作和安排人员。这时候,我们就要谈到项目章程、业务案例、资金和资源审批。我们会讨论他们计划的频率、参与人员以及需要花费的时间和精力。
一位客户曾告诉我他们的年度计划批准了商业智能团队的71个项目,并且该71个项目目前全部仍处于活跃状态,“因为管理者需要看到整个系统进展”。其中有一半的项目是从上一年度顺延下来的。更致命的是,他们告诉我预期今年内不会有一个项目能够完工!
通过实施看板方案,我们能够解决这个进行中的工作问题。按照对业务的价值划分项目优先等级,列出项目必须完成的步骤,以及限制“正在进行中”的工作量。只有在当前的工作完成后,团队才能接新的工作。一转眼,项目交付变成可预测了,我们只构建最具有业务价值的部分。我们已经解决了我们的问题,对吗?答案当然是否定的。
成为敏捷企业
市场每天千变万化,新的客户需求层出不穷。一家公司的生存有赖于能够定期、以较低的成本改变项目组合,以紧追新的业务变化。想要缩短企业选择最佳方案的时间,并不断交付予客户,我们就需要解决战略与团队工作之间的脱节问题。
答案就是如何细分举措,让团队与不断变化的优先重点保持一致、自动化进度报告和选择能够推动持续改善的指标。其中的核心就在于季度小组计划活动Big Room Planning,它让团队和领导共同构建每个人可以交付的共享、可实现的发布计划。由现在开始,每个团队的工作与战略变化将会保持一致,Scrum团队可以“查看”以了解他们正在建模背后依据的基本原理,以及他们的工作如何推动公司战略的实施。但是,我们还需要具备另外一个条件。
培养企业的敏捷文化
一个敏捷企业必须深谙只有将战略、能力及文化结合起来,才能实现真正的机构转变。文化产生于人们的互动方式,因此我们寻求能够促进不断学习和改进的互动,而回顾和良好的绩效指标能派上用场。
最后,我们不应只是“做敏捷”,更应真正“变敏捷”(being Agile)。我们已具备所有解决重大问题所需的一切条件:包括出色的团队执行、按价值划分的优先等级、从战略到执行的连接,以及满足我们协调、沟通和改进文化需要的平台。我们应专注于为客户创优增值,而非只是创建过程。我们已经弥补组织中的缺口,现在我们可以积极引导我们的公司响应市场变化,真正成为一个敏捷企业。
版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。