项目管理沙龙的第一次聚会纪要

项目管理沙龙的第一次聚会纪要

会议的主题是项目管理和敏捷。敏捷是近几年的热门话题，也是最让人误解的名词了。
有人在会上提了这样的例子：

引用

两个人A和B爬山，B不管三七二十一，直接上山朝目的地行进，结果半路遇到没路，就折回来再重新走一条路，这个就叫“敏捷”。而A呢，先绕山走了三圈，制定出一个完美的计划，并且进行风险评估，设计应对方案，然后还划出几个里程碑，最后开始实施，到了山顶，人们叫这个为“瀑布式项目管理”。并且现在都认为B会先到目的地。

这个例子引起了大家的反对。并认为最早写这个例子的人肯定不懂敏捷。相比而言，其实敏捷更重视计划和阶段的划分，而且在过程跟踪上的力度也比传统方法要紧密。

这就提出了“什么是敏捷”的话题。

有人首先强调了敏捷方法和传统的指令式项目管理方法在目的上的一致性，就是以达成项目目标（进度、成本、质量、团队等）为目的。但是他们是两种完全不同的解决思想的产物。

传统的项目管理方法首先普遍认为员工是一种需要用严格约束来驱动他们工作的，而监管他们的人就是项目经理。几乎所有关键的项目工作压力都集中在项目经理身上，由PM进行任务的分解、评估、工作分配和任务跟踪，还需要对过程数据的收集和评估等，当PM出现差错、懈怠或者不胜任的时候，项目就会陷入混乱和停滞。在团队氛围上，普遍士气不高，没有明确的团队激励机制。

但是敏捷方法采用的是相反的思想，他们首先强调的人的因素。希望通过充分调动人的积极性，将项目管理的职责分摊到每一个人，每一个人在履行自己的工作承诺的同时，也参与项目组的所有管理工作。通过持续的“计划-实施-检查-改进(PDCA)”工作循环，保证团队和参与的每一个人都得到提高。敏捷方法的主要激励机制是“成就感”，所以团队氛围普遍较高昂。在BPM和AOM的SCRUM实践中，有明显的感受。

另外有人举了例子：

引用

一个人A在早上八点准备从深圳出差到北京，但是到机场的时候误点了，于是他就上了一辆taxi，让司机B开车去北京，并且要求中午就要开到。

很明显这是一个很过分的要求，深圳到北京这么远，很明显不可能4个小时到达。用数学公式来解释，就是“速度×时间”远远小于了“距离”。所以这个是一个不可能完成的任务。

但是把同样的场景放到软件开发项目中，却有不同的结果：客户A要求在某个期限内完成项目，作为项目经理的B很可能就答应下来，但是结果要么是无法完成，要么就是完成质量不高，导致后期返工。

目前最常见的问题是项目组无法评估项目的规模，也不知道项目组的实施能力，从公式“距离=速度×时间”来看，项目组当然也就无法评估项目结束所需要的时间了。面对客户的无理要求，这样的乱答应也就毫不奇怪。

通过过程数据收集和评估，来获取项目的实施能力、规模、质量、进度数据，是项目经理的一项重要工作。但是在传统的项目管理方法中，实施起来并不容易。一般要达到CMMI3或4的企业才能达到这样的能力，但是通过SCRUM方法的实施，在前两个迭代之后，就基本可以获得这些数据了。

为什么实施SCRUM之后就可以短时间内做到？这个是沙龙中提出的又一个问题。实际上敏捷采用的管理策略是一种“人民战争”的策略，通过发动“群众”，提高大家的主动性，平等和积极地参与项目的日常管理。有这么多人，通过每日例会和其他的频繁沟通，来平等获取项目的各种信息和状态。这样当然比传统的一个项目经理单打独斗要有精力，而且更细致，更全面。更重要的是项目组员获取的“任务”，基本都是自己感兴趣的甚至就是自己发现的，工作干劲上是传统项目管理手段所不能达到的。

所以“敏捷”的管理力度更强、更深入、全面和细致。而且从实际来看，敏捷的项目管理者并不需要拥有比传统方法的项目管理者更高的能力，相反还更轻松一点。

讨论中并不是所有人都认可敏捷。实际上SCRUM中的做法不是什么新发明的，都是传统项目管理中已经大量应用的技术，比如需求的功能点评估，项目过程数据收集和评估，设计方法等，项目管理过程中只需要坚定地朝项目目标前进，只要是好的方法都可以拿过来实践，我们就可以在SCRUM的基础上来发展出一套符合自身特点的敏捷过程。传统的项目管理方法也可以采用敏捷的一套做法，慢慢把自身敏捷起来。

不过有人立刻就此观点提出了异议。从公司目前两个项目组的SCRUM实践经验可以看到，敏捷过程（至少是SCRUM方法）中充满了一些隐喻的做法，比如评估point和评估hours并行进行，相互印证；比如backlog打分过程的知识传递和博弈；比如每个迭代的“计划会议-每日例会-回顾会议”这个PDCA的循环过程；比如Team Work的团队责任原则，等等。缺少这些基础的价值观，“敏捷”就不再是敏捷了，而不纳入这些价值观，传统的项目管理方式也永远不能“敏捷”起来。

当然，敏捷方法也有自身的缺点。首先一个就是缺少一个人去关注全局，关注架构。但是很快有人提出，敏捷只是一种项目管理方法而已，把这个缺点说是敏捷的缺点也有点牵强。继续讨论之后，我们发现在实施敏捷的时候，还是不能忘记每个角色的分工和侧重点，虽然号称是“平等”，但是架构师依然要多关注架构，测试工程师也依然不能忘记产品的“可测试性”。

敏捷的初衷就是要抛弃各种条条框框，所以敏捷实施过程中，也并不存在什么“必须”去做的方法，哪怕是敏捷的核心价值观，也没有什么固定的做法。灵活是敏捷的表现，但是“灵活”并不等于“粗糙”，事实上敏捷就是拒绝“粗糙”的，我们要看到敏捷的“灵活”背后所蕴含的“细腻”的各种实践。我们在去看《敏捷宣言》：

引用

敏捷软件开发宣言
http://agilemanifesto.org/iso/zhchs/
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。

可以看到，所谓的“敏捷”方法，就是秉持敏捷理念的项目管理方法。

但是在敏捷的实施过程中，并不都是一帆风顺的。一个流畅的敏捷管理过程，机器的辅助是相当重要的，比如关键的“持续集成”。

总结

虽然这次讨论的主题是“项目管理和敏捷”，但是话题涉及到了项目管理的很多方面。会议气氛热烈，有很多精彩之处，个人比较满意。但是因为是初次沙龙，所以会议话题有些分散，有些同学希望主题能够更加明确一些。

期待下次更好。