初用敏捷：必须从组织架构入手吗？
如题...
当一家公司决定采用敏捷开发方式时，其组织架构往往需要做出变动。敏捷的工作方式同时会伴随着团队和管理方式的新实践，并且往往会影响到组织架构文化及心态。这些方面都是相互关联的，但对一个公司来说，同时改变各个方面的挑战太大。因此，问题归结到当开始向敏捷迁移时，首要关注点在哪里：文化、实践还是组织架构？下面让我们探索一下当从改变组织架构着手时会发生些什么。
敏捷宣言第一行说：我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。敏捷的实施方式应该在敏捷宣言的价值观和原则指导下随着时间推移而不断地调整变化。其中挑战在于，如何用敏捷价值观及原则来指导实践和组织架构的调整。想要成功地实施敏捷方法，我们需要一套交付体系和相应的开发实践来体现敏捷原则和价值观。
有人提出的问题是如何在复杂的大型公司中推行敏捷方法，是否应重点关注公司的企业文化？先引入敏捷的新实践还是先改革组织架构？
很多人觉得“大且复杂”就是症结所在，敏捷需要的是“小而简洁”。这观点我同意，但这些公司的实际情况就是它们确实巨大且复杂，因此问题转变成如何帮助它们向小而简洁转变。仅仅告诉他们“太大不好，你们应当变小一点”是毫无用处的。如何变？从A到B的路怎么走？采纳一个敏捷价值体系够不够？即便在正确的价值体系引导下，正确的实践和交付体系会自动产生吗？即便在正确的实践中，能对端到端的交付体系产生影响同时改变企业文化吗？
Tirrell Payton发表了一篇博文采用敏捷时五个普遍问题，他提到的其中一个问题就是现有的组织架构阻碍敏捷施行。
最大的陷阱就是公司的领导层会试图扭曲敏捷制度使其适应当前已存在的组织架构和层级制度，以下列举几个常见可能性：
由经理们担任敏捷教练角色，他们仍然习惯用下达命令的方式管理项目组成员；
成员个体各自为政，没有团队意识；
产品负责人被推到这个岗位上，但并不了解相应的角色、职责以及时间承诺；
敏捷教练被管理者们过度干预。
在Tirrel看来，要改变公司的组织架构以适应敏捷，管理层的支持必不可少：
管理层要明白，向敏捷迁移是公司层面的大变动，而不仅仅是项目层面。因此公司的各个支持部门都需要协助敏捷迁移。
在转向敏捷的过程中可能需要管理层的大量协助和支持，将变更从上到下推行，持续关注进程，同时扫除时不时出现的障碍。
当前，很多公司重视精益开发和敏捷方法，想借此满足客户的期望，同时在行业竞争中保持领先。这需要业务、体制、运营三者之间高效协作来快速有效地交付创新的解决方案。敏捷为如何填补业务和开发之间的隔阂提供了基础概念。然而，要将这些概念运用到项目上还需要在具体操作时改变原有思维模式。
他们认为要采用敏捷，各个层次都需要接受从上到下的系统培训，从企业文化到组织架构都需要调整：
由于敏捷是精益思想的一种，各级管理层接受精益思想的管理理念对他们管理方式的转变至关重要。通过发展敏捷文化并在角色及组织上做出必要变更，基于这些形成一个能自我引导的团队环境将极大改善各个层面上的混乱状况。
Mike Cottmeyer在他的博文中说，采用敏捷方式应当从改变公司的组织架构开始：
按他的观点，首当其冲的就是组织架构调整，其次是实践，最后是企业文化。
Tirrel Payton认为不调整组织架构会阻碍敏捷进程：
Alok Kumar、Frank Castagna和John Maher建议采用敏捷时先制定一个迁移计划：
他们倾向于在条件允许的情况下调整公司组织架构。
采用敏捷时，你们是从组织架构入手的吗？
来源：infoQ
作者 Ben Linders ，译者：段珊珊
点阅读全文，来听听敏捷研讨会
关注 敏捷视界
微信扫一扫关注公众号
