NVIDIA 初创加速计划,免费加速您的创业启动 了解详情
写点什么

初用敏捷:必须从组织架构入手吗?

  • 2014-12-17
  • 本文字数:2196 字

    阅读完需:约 7 分钟

当一家公司决定采用敏捷开发方式时,其组织架构往往需要做出变动。敏捷的工作方式同时会伴随着团队和管理方式的新实践,并且往往会影响到组织架构文化及心态。这些方面都是相互关联的,但对一个公司来说,同时改变各个方面的挑战太大。因此,问题归结到当开始向敏捷迁移时,首要关注点在哪里:文化、实践还是组织架构?下面让我们探索一下当从改变组织架构着手时会发生些什么。

Mike Cottmeyer 分享了他的文章关于大型公司向敏捷迁移的想法。他在文章中说道,在实施敏捷的过程中,公司文化、开发实践和组织架构都是相互关联的。

敏捷宣言第一行说:我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。敏捷的实施方式应该在敏捷宣言的价值观和原则指导下随着时间推移而不断地调整变化。其中挑战在于,如何用敏捷价值观及原则来指导实践和组织架构的调整。想要成功地实施敏捷方法,我们需要一套交付体系和相应的开发实践来体现敏捷原则和价值观。

Mike 给自己提出的问题是如何在复杂的大型公司中推行敏捷方法,是否应重点关注公司的企业文化?先引入敏捷的新实践还是先改革组织架构?

很多人觉得“大且复杂”就是症结所在,敏捷需要的是“小而简洁”。这观点我同意,但这些公司的实际情况就是它们确实巨大且复杂,因此问题转变成如何帮助它们向小而简洁转变。仅仅告诉他们“太大不好,你们应当变小一点”是毫无用处的。如何变?从 A 到 B 的路怎么走?采纳一个敏捷价值体系够不够?即便在正确的价值体系引导下,正确的实践和交付体系会自动产生吗?即便在正确的实践中,能对端到端的交付体系产生影响同时改变企业文化吗?

Tirrell Payton 发表了一篇博文采用敏捷时五个普遍问题,他提到的其中一个问题就是现有的组织架构阻碍敏捷施行。

最大的陷阱就是公司的领导层会试图扭曲敏捷制度使其适应当前已存在的组织架构和层级制度,以下列举几个常见可能性:

  • 由经理们担任敏捷教练角色,他们仍然习惯用下达命令的方式管理项目组成员;
  • 成员个体各自为政,没有团队意识;
  • 产品负责人被推到这个岗位上,但并不了解相应的角色、职责以及时间承诺;
  • 敏捷教练被管理者们过度干预。

在 Tirrel 看来,要改变公司的组织架构以适应敏捷,管理层的支持必不可少:

  • 管理层要明白,向敏捷迁移是公司层面的大变动,而不仅仅是项目层面。因此公司的各个支持部门都需要协助敏捷迁移。
  • 在转向敏捷的过程中可能需要管理层的大量协助和支持,将变更从上到下推行,持续关注进程,同时扫除时不时出现的障碍。

Alok Kumar、Frank Castagna 和 ohn Maher 在敏捷联盟网站上发布了一篇文章企业采用敏捷的挑战和顾虑。一家公司要采用敏捷,就要改变其组织和管理的方式。

当前,很多公司重视精益开发和敏捷方法,想借此满足客户的期望,同时在行业竞争中保持领先。这需要业务、体制、运营三者之间高效协作来快速有效地交付创新的解决方案。敏捷为如何填补业务和开发之间的隔阂提供了基础概念。然而,要将这些概念运用到项目上还需要在具体操作时改变原有思维模式 _。_

他们认为要采用敏捷,各个层次都需要接受从上到下的系统培训,从企业文化到组织架构都需要调整:

由于敏捷是精益思想的一种,各级管理层接受精益思想的管理理念对他们管理方式的转变至关重要。通过发展敏捷文化并在角色及组织上做出必要变更,基于这些形成一个能自我引导的团队环境将极大改善各个层面上的混乱状况。

Mike Cottmeyer 在他的博文中说,采用敏捷方式应当从改变公司的组织架构开始:

我十分确信敏捷文化和敏捷实践是保持长期稳定的组织敏捷性的关键,他们说,我不相信你能仅靠培训和信念就成功实现敏捷。我认为应当建立一个基于团队的组织架构设计方案,敏捷价值观在各团队之间通过一个合适的管理模块来管理,基于精益 / 看板法原则,其中‘正在进行中的工作’数量有限、开发能力和需求能保持平衡、能及时识别并处理瓶颈,并且管理团队能投入资源改进整体交付系统。只有在这样的组织架构中,敏捷文化和敏捷实践才能发挥最大作用。

按他的观点,首当其冲的就是组织架构调整,其次是实践,最后是企业文化。

我建议先集中精力在你们的商业目标上,制定策略来创建一个基于团队的组织架构模型,该模型基于迭代和递增的交付原则,即采用敏捷和精益方法论指导交付和管理,但同时又遵循其现有的政策及架构中运作方式和文化的限制。

Tirrel Payton 认为不调整组织架构会阻碍敏捷进程:

千万不要勉强把敏捷塞进现有的组织架构中,事实上,许多公司都是这么干的,这是最大的陷阱。

Alok Kumar、Frank Castagna 和 John Maher 建议采用敏捷时先制定一个迁移计划:

“制定计划然后按计划行事,” CMM 和 CMMI 之父 Watts Humphrey 说,“如果你不知道自己正去往何方,你可以选择任何一条路。” 这意味着各实施机构正迅速沦落到要重新理解其咨询对象,重新设定内容同时扫除障碍的处境中。

他们倾向于在条件允许的情况下调整公司组织架构。

如果公司能简化组织结构就尽量简化。如果不行,就在项目层面规划好各交互应用间的整合,以尽早减少相互依赖,不要等下分到各开发小组之后再做整合。

采用敏捷时,你们是从组织架构入手的吗?

查看英文原文 Adopting Agile: Should We Start with the Structure?


感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014-12-17 01:242190

评论

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

【架构师训练营 1 期】第十周学习总结

诺乐

架构师训练营第六周作业

xiaomao

CAP原理

幸福小子

分布式 CAP原理

第十周作业

solike

架构师训练营第六周总结:

xiaomao

week6 技术选型(二) 作业和学习总结

杨斌

第十周 模块分解总结

蓝黑

极客大学架构师训练营

9 性能优化(三)课后练习

ABS

目标检测之WBF(Weighted Boxes Fusion)

Dreamer

目标检测

第十周学习总结

熊桂平

极客大学架构师训练营

架构师训练营2期 第六周总结

月下独酌

极客大学架构师训练营

Week_10 总结

golangboy

极客大学架构师训练营

与前端训练营的日子 --Week05

SamGo

学习

架构师训练营 - week10 - 作业

lucian

极客大学架构师训练营

模块分解

wing

极客大学架构师训练营

架构师训练营第2期 第六周课后练习

月下独酌

极客大学架构师训练营

学习总结之分布式数据库

幸福小子

架构师训练营第 10 周课后练习

叶纪想

极客大学架构师训练营

架构第十周作业

Geek_Gu

极客大学架构师训练营

第六周作业总结

hunk

极客大学架构师训练营

CAP原理

皮蛋

CAP CAP原理

git 在未保存,add,commit,push下撤销的方法?收藏后再也不用找了

小松漫步

架构师训练营第十一周作业

Geek_4c1353

极客大学架构师训练营

CAP 原理简述

jorden wang

第 6 周作业

Steven

极客大学架构师训练营

面试被问Mybatis底层实现:你连这个知识点都说不明白?

小Q

Java 编程 程序员 架构 mybatis

【架构师训练营 1 期】第十周作业

诺乐

架构第十周总结

Geek_Gu

极客大学架构师训练营

10 模块分解课后练习

ABS

模块分解-微服务,组件设计原则,领域驱动开发

garlic

极客大学架构师训练营

架构2期-第六周作业(1)

浮生一梦

极客大学架构师训练营 2组 第六周作业

初用敏捷:必须从组织架构入手吗?_技术管理_Ben Linders_InfoQ精选文章