转向敏捷管理时，最大的阻力是什么？

一个人的人生转变，是由其思想转变开始的；一个组织的转变，也是组织成员的思想转变开始的。所以，组织敏捷转型的源头应该是成员思想的转变。

敏捷转型是思维转变

敏捷首先是一种思维模式。深入了解敏捷，我们会发现其中并没有项目管理以外的全新、原创的内容。虽然过去20多年来软件产业频频用到敏捷这个词汇，但其中的行为实践只是一般管理方法中已有的优秀实践。

“敏捷”，不管我们谈到的是Scrum、看板、精益或是其它的许多敏捷框架，大部分是一系列有历史意义的优秀实践与指引的集合。这些实践和指引是由过去成功的领导者和商业案例所定义，然后用一套概念进行包装和宣传。“敏捷”并不是什么全新、未经检验的概念。当然其中存在不少误用、扭曲的理念，但其原则是稳固的，是基于大量经验的。

所以，当一个组织开始转向敏捷的时候，并不需要去发明什么或者创造什么，它只需要组织文化进行转变、组织成员认可并践行这种理念，去拥抱那些优秀的实践经验。

整个敏捷转型的过程，其实就是改变思想，再通过思想影响行为的过程，当团队中的人员思想慢慢改变，能力也在随之提升，所有人都能对什么是正确的事作出更好的判断，继而走向持续改进的道路。

从思想上接受敏捷

敏捷宣言的四句话用非常精简的文字表达出了敏捷在思想上所倡导的主张。它是敏捷开发的精髓，想要向敏捷管理进行转变，最好从思想上接受它，进而通过自己的思考、实践来形成组织自己的理解，最终形成组织自己敏捷管理的最佳实践。

1、个体与互动高于工具与流程

方法与工具是为了更好地达成所做事情的目的，人才是管理中最重要的环节。如果团队中没有优秀的成员，再强大的工具与流程都是摆设。

敏捷团队提倡跨功能的团队成员，他们是一个自组织的团队，一起工作，面对面的交流，一起做计划，一起探讨问题所在及解决方案。通过这种自组织的团队，可以自发地解决开发过程中遇到的各种问题。

虽然说个体和交互更重要一些，并不是说过程和工具就不需要了。合适的工具对于成功来说也是非常重要的。比如我们的IDE、版本控制系统、自动化测试的工具等等，对于团队的开发者来说这些都可以大大提升工作效率，但我们不能夸大工具在整个过程中的作用。

要知道：工具是死的，人是活的，工具只是可以更好的帮助我们完成工作而已。

2、可工作的软件高于详尽的文档

对于一个开发人员来说，最烦的可能就是写大量的文档了，想想我们的项目，有多少文档写了以后从来没人看？有多少项目文档和最终的实施是失之毫厘、谬之千里的？有多少文档和代码缺少同步、造成弥天大谎的？而这些文档对用户来说，是他们最关心的吗？

客户需要的是一个能够跑起来的软件，能够解决实际问题的软件，通过频繁的交付有价值的可以工作的软件，不仅可以更频繁的搜集产品和开发过程的反馈，还可以保证项目团队始终处理的都是最具价值的功能。提供的是一种检视与调整的契机。

虽然我们说可工作的软件更好，但并不是说文档不重要，更不是说不要文档。优质、贴合实际的项目文档对于项目来说非常重要。除此之外，高效、优质的交流，知识及时有效的传递、快速的反应也显得非常重要。

3、客户合作高于合同谈判

只要告知开发团队想要的东西，就能得到客户满意的反馈，应该是不存在的事情。首先要理解合作的本源是什么：项目开展的终极目标是什么？就是提供给客户满意的可交付成果，敏捷开发提倡客户与开发团队一起工作，及时反馈。通过高效互动可以提早项目中的暴露问题，便于开发团队发现客户需求，快速迭代，避免后期变更造成更大的损失与影响。

4、响应计划高于遵循计划

计划赶不上变化，而团队的应变能力，常常决定着一个敏捷项目的成败。在敏捷中，每个sprint周期都不会长，而且也不会制定长时间的复杂计划。

首先，事业环境因素很可能会变化，这会引起需求的变动。

其次，客户往往是看到系统后，才会发现哪些是他们不需要的，从而改变需求。

最后，即使我们知道了详细的需求，而且坚信他们不会在改变，但我们仍然不能很好的估算项目的进度和开发时间。

有时项目经理刚做好进度计划，而相关方可能又有了新的认识，某些任务可能已经不在需要，也可能新增了一些任务到图中。项目经理刚做好的进度计划已经反应不出当前项目的真实状态。计划的变更，不仅仅是日期的延长，还有可能是逻辑关系的变化，这是让很多负责敏捷项目的项目经理很是头疼。

在敏捷项目中，不确定性是一个相对比较正常的状态，所以不会制定很长时间的复杂计划。

常规的做法是通过远粗近细的方法进行，比如：为接下来的一周做详细的计划，为2个月后做粗略的计划。通过迭代开发，每次迭代都是基于上一个迭代基础之上，通过不断的响应变化来消除过程的不确定性。

与传统项目强调规划不同，迭代型开发管理方法允许对未完成的工作进行反馈，从而改进，是规划、执行、检视、调整，往复循环的过程。

起源

流派

视频

书籍

敏捷动态

培训

关于我们