在2012年工作过的某家大型银行了解到了敏捷，当时在那里全面的推行敏捷，因为自己刚刚学了项目管理所以对于敏捷的敏感度不高，而且来自上海的咨询团队轰轰烈烈的搞完一段时间之后，敏捷的效果也不是很令人满意。所以当时有一些对敏捷管理的不太看好，后来随着自己接触的项目管理工作越来越多，和交流的逐渐广泛。才发现有些项目的确可以也需要进行敏捷管理，特别是那次参加了PMI组织的PMO大会，美国的专家在发言的时候对敏捷的解释使我对于敏捷项目管理豁然开朗。他说：敏捷就是内部的变化小于外部的变化。其实深刻理解这就话就是，敏捷变成了以项目团队为中心，项目团队掌握了主动权。
项目的铁三角分别是范围、成本和时间。我们知道采用传统瀑布式的管理方法是因为我们的范围和时间都已经确定了，可变的就是成本及资源投入。我们在这里可以狭隘的理解成资源投入就是指人员的投入，这样的项目一般是告诉你我要做一个什么事情或产品，大约有多长时间。然后开始去找团队，这时候需要确保的是范围和时间，的成本是一个可变量。也就是谁有能力将成本降到最低说就可以抢到优先权。可以看到我们项目管理其实就是在三项条件两项确定的条件下去协调第三项使得整个项目铁三角面积最小，也就是质量最优。而我们想象一下如果范围不确定，我们怎样才能使质量最优呢？其实就是需要把时间和成本固定到合适的位置。这也就是我们所说的敏捷项目管理，在项目范围不确定的条件下，我们确定成本（项目团队人员数量）和时间（每个迭代周期）。也就是我们固定几个人每隔一段时间做这个项目，你提出的需求必须去适应这两个条件。因为不会再有太多的人员和时间投入了。所以这就是以敏捷开发团队为中心，如果这个迭代需求数量过多了那么我们只能根据优先级完成高优先级的工作。而不是以范围为中心去实现所有需求为目标。开发团队有了自己的节奏，外界的变化再大也不会影响到这个节奏，这就是敏捷。
敏捷有一些最重要的表现，如版本故事，看板管理，敏捷会议等。在很多的项目组织实现敏捷的过程中都是以这些表现来评判一个团队是否是否实现了敏捷。就像是我们在评判一个人是否漂亮通过脸，通过身材，通过声音等。但是一些时候我们在想要实现敏捷的时候太过于着急了，一个习惯于传统瀑布管理的团队在短短半个月或一个月之内就抛弃了原来的工作方法，计划全部变成了版本故事，工作全部使用了敏捷看板，全部按照敏捷会议的原则进行沟通，这是我遇到的不少敏捷化的实际情况。这样做的结果是整个业务工作停滞，大家都在为了敏捷而敏捷。对于组织来说这样的敏姐之路会有一些得不偿失。我们需要对实现敏捷做好方案，使得组织在不丢下业务的情况下实现向敏捷的平滑过度。
对于实现敏捷的步骤我有如下建议：
1.首先是确认需要敏捷管理的项目
不是所有的项目都适合用敏捷管理的方法，就像是我们所说的一些范围比较明确的项目其实就不适合用敏捷管理。例如我们建设一个项目管理系统，市场上项目管理系统已经很成熟，这时候我们不需要专门的一个团队，进行迭代开发。我们需要投入适当的资源，尽快的开发出产品并进行使用实现收益。如果我们使用敏捷，产品的范围一直在变反而使得项目管理系统缺乏逻辑性和严谨性，造成不便。而对于维护型项目和创新型项目产品逻辑架构基本不会太大变化只是功能的优化和增加型项目反而适合使用敏捷管理。
2.敏捷是一个过程而不是一个结果
敏捷管理是一个过程，用《敏捷的革命》这本书中的观点说，其实实现了敏姐沟通或知实现了工作的看板管理都可以认为是工作敏捷化了而不是需要所有特征都实现才觉得自己是真的实现了敏捷。因为每一样敏捷特征都有其优点，如我们实现了了看板管理后其实我们就已经享受了敏捷的好处。所以敏捷是一个过程需要我们真正的实实在在的通过敏捷实现收益，而不是去看结果是否都打到了要求的样子，管理最重要的是大家都认可，从内心去执行提高效率。而不是为了完成面子工作。
3.本着对组织负责的原则，民主也要集中
作为组织的一份子，每个成员在考虑自己的同时也要考虑组织。为组织的高效和发展负责，敏捷管理和其他任何管理方法一样，是改变我们某种习惯。而这种改变必将会受到抵制，这时候我们需要有变革的勇气，来实现组织的真正敏捷。
网友评论