下载掌阅APP，畅读海量书库
立即打开
组织变量应该与首选的开发方法相匹配，否则项目将很难成功。需要注意的4个组织变量是：
· 组织结构；
· 文化；
· 项目团队；
· 经验和认同感。
组织结构
组织结构的范围很广，从层级式结构到矩阵式结构再到扁平式结构。层级式结构有很多管理层级，而且职能通常是孤立的。这种类型的结构通常具有稳健的策略和过程，并且不同职能间的沟通和交互可能是受限的。在这样的结构中做项目，使用瀑布开发方法比敏捷开发方法好。例外情况是，如果有一个或一组特定的职能，如IT，采用敏捷开发方法。
扁平化的、对变更和调整灵敏的组织，是适应型项目管理实践的“沃土”。审批层级更少，开发也更为灵活。
混合选项：
敏捷开发方法在官僚主义环境中的效果不佳。然而，敏捷开发方法的意义在于，你仍然可以使用其中的一些方法和技术，如每日站会和任务板。
也有一些组织在某些领域（如IT）中采用敏捷开发方法，而在其他领域中主要采用瀑布开发方法。如果你的项目中有习惯于不同开发方法的团队成员，那么你可以混合使用各种开发方法，并让你的团队了解每种开发方法的好处。
文化
企业文化是选择最佳项目管理方式的一个重要决定因素。使用敏捷开发方法的项目基于信任的氛围，团队被授权对项目做出许多决策。他们构建了属于自己的关于工作、沟通、故障排除等的方式。敏捷团队通常是自组织的，没有特定的领导。这种工作方式在高度官僚化或“命令和控制”式的环境中行不通。
相反，一个需要大量文档、决策签字、严格流程等的项目，在一个层级分明的环境中会执行得很好，但在扁平化的组织中就不太适合了。许多组织在实施敏捷开发方法中挣扎或失败的原因之一是企业文化与敏捷的工作方式不匹配。
混合选项：
除非你正在进行组织转型，否则改变企业文化以采用不同的项目工作方式可能不属于你的项目范围。但是，你可以从不同的方法中引入一些技术。例如，在瀑布环境中，你可以为原型和实验安排任务。在敏捷环境中，你可以囊括里程碑、状态报告，甚至可能讨论发布的关键路径。通过从不同的开发方法中引入一些实践，你可以减少不同工作方式所受到的阻力，并帮助人们看到采用不同的方法是卓有成效的。
项目团队
项目团队成员的数量和位置会影响开发方法的选择。敏捷开发方法最适合5～10人（在同一空间）的团队。虽然你可以在更大的团队或虚拟团队中应用敏捷开发方法，但这更具挑战性。敏捷团队有每日站会，他们的大部分合作都是一对一的对话——最好在附近有一块白板来捕捉创意。当你的团队成员超过10人或者在不同的位置时，特别是当他们在不同的时区或国家时，这些实践会更具挑战性。
大型团队则更适合在瀑布项目中工作。这样能少开很多会，很多文档都是电子版的，分散的团队成员也并不少见。
混合选项：
对于想要使用敏捷实践的大型团队，你可以采用一种规模化敏捷方法，如SAFe（Scaled Agile Frameworks）、LeSS（Large Scale Scrum）或SaS（Scrum at Scale）。你还可以放弃一些对于大型或分散的团队更具挑战性的实践，如每日站会。另一种选择是将团队会议室中通常可见的大部分数据（如任务板和燃烧图）电子化。
在有多个可交付物的大型项目中，你可能会发现这样做会很有用，那就是使用瀑布框架管理整个项目，并且团队成员中有的使用适应型过程，有的使用瀑布型实践。
经验和认同感
最后一个变量是团队和组织的经验与认同感。具有管理项目的特定方法的经验和认同感的团队与组织可能难以采用新的工作方式。即使团队有经验并认同以某种方式工作，如果与组织的经验和工作方式不一致，这将是一段艰难的旅程。另一方面，如果一个组织想要尝试一种新的工作方式，如投资于敏捷实践，但团队不参与，这将是一场斗争。
混合选项：
与组织变量中的其他变量一样，一个好的选择是一次引入一些替代实践，让团队和组织习惯它们，并看到它们是有效的。你也可以指出实践之间的相似之处。例如，敏捷中使用的回顾与瀑布开发方法中使用的总结经验教训异曲同工。你可以混合经验教训的实践和回顾来模糊界限。你还可以混合一些估算实践，如在多点估算中使用计划扑克中的估算值，或者在瀑布项目中使用计划扑克来进行估算。通过小步快跑并证明其有效性，你可以打开通往混合环境的大门。