项目管理沙龙第十二次会议纪要--为没有共识的项目组定制敏捷方法

项目管理沙龙第十二次会议纪要

本次会议的主题是为没有敏捷共识的项目组定制一个敏捷的实施方法。这是一种普遍存在的情况，和其他的新事物一样，总会有一些人对“敏捷”这两个字比较敏感，究其原因，无外乎偏见、误解和不了解（无知），部分人则是恐惧或自大。当然，不了解是绝大多数人的原因。

但是，面对“没有共识”的人们，到底是说服之后再实施敏捷呢，还是先实施敏捷再用实际效果展示给他们？这是一个问题。我们倾向于后者，即先实施让人们看到效果。理由很简单，因为人与人之间的知识和经历的差异很大，要全部说服的时间成本太高，甚至于不可能，如果面对是一个有一定经验的人，要想说服他抛弃原先的经验来接受一个新事物，难度恐怕会更高。所以，“暗渡陈仓”或“偷梁换柱”地实施敏捷，是一种切实存在的需求。如果要给这种方法安装一个冠冕堂皇的名字，那就是“传统的项目管理方法到敏捷管理方法之间转换与过渡”。

之所以我们要探讨这种情况，因为我们坚信“敏捷不会把事情变得更糟”，既然敏捷肯定不会“砸场子”，肯定“效果>=现状”，所以“暗渡陈仓”就是有价值的，也是可行的一种推广方法。

我们的目标项目组情况是这样的：团队成员之间技术水平差异较大，但是工作热情高涨，气氛较好，而且项目组感觉“陷入泥潭”已经很久了，看着一堆难以维护的代码，大家都有一种想要改进和突破的渴望。但是团队的关键领导之一对敏捷的态度比较暧昧，不支持也不反对，但对敏捷始终保持着足够的距离，既不拒绝，也不欢迎，更不去深入了解。在管理方法上，项目组采用月计划和周计划相结合的管理方法，即每月定一个计划，本周的计划细化到可执行。但是可想而知，管理比较混乱，计划也经常不准确。

面对这样的项目现状，我们首先讨论的是实施策略：

1. 绝口不谈敏捷两个字，也不谈敏捷相关的什么术语，避免反弹。
2. 选取敏捷方法中最有价值的几个行为，改良项目组的管理现状。
3. 在达到效果，取得大家的认同之后，全面实施敏捷方法。

经过讨论，我们总结出的敏捷成功的要素有如下几个：

1. 管理上的PDCA循环。通过Plan-Do-Check-Adjust形成一个不断改进的循环。
2. 工作的可视化。通过将工作以可视的形式展示出来，让团队对进度有切身的感受。
3. 任务的定量化。所有的任务在阶段开始前就已经定好，一般不再改变。
4. 沟通。定期、按需沟通，保持信息流转的顺畅。信息包括：任务，进度，问题等。
5. 团队工作。团队的每个人都知道所有的事情，了解一致，当然就没有歧义。
 
事实上，敏捷的这几个要素纳入到任何一种管理方法中，这种方法也就立刻符合了“敏捷”的规范，因为“敏捷”本身就是一种“价值观”，在同一个价值观下，可以有N中不同的方法。“老酒”兑“新水”自然也是可以的。

讨论之后的具体实施方法如下：

1. 沿用原来的“月度计划”和“周计划”结合的管理方式。 用敏捷术语就是一个“迭代”长度为1月， 但是考虑到一个月时间太长， 不容易出效果， 所以在每个月的15日加入一个局部总结会议。 实际上把一个月分为上下两个半月，即2周一个迭代。这个也是目前公司敏捷经验中推荐的初期迭代长度。

   a) 每月月初开“每月例会”，内容就是规划本月的工作， 并且将工作细分为可分配的任务， 颗粒度粗一点没关系， 但是要保证一个月够用， 不需要中途再加。 例会上所有的工作都要进行讨论， 保证大家都对工作没有分歧， 其次要对每个工作进行评估，评估的单位采用传统的“工作日”。 只有所有工作都进行了评估， 才能评估任务的进度。

   b) 每月15日左右开“月中总结会”，负责总结一下上半月的工作情况， 讨论改进措施， 并根据进度，酌情调整下半月的任务进度安排。

   c) 每月月末召开“月度总结会”， 负责总结整月的工作情况，并讨论改进。 月末总结会议一般不要和月初的例会合在一起开。

2. 开始实行每日例会。会议上监控如下的几个问题：

   a) 每个人当天的工作状况是否都已经更新

   b) 对停滞超过2天的工作要询问原因，可考虑进一步细化和分解。

   c) 鼓励在例会上交流，慢慢形成交流的气氛。

3. 所有的工作和进度，在白板或者wiki上展示，统一管理。

   a) 初期的工作任务描述可以简单，但是要在计划和总结会议上形成口头共识，防止歧义。 在实施过程中逐步精细化，慢慢达到敏捷对Backlog的要求。

   b) 暂时不考虑使用敏捷工具，避免反弹。

 
在实施过程中，还有一些技巧需要酌情使用：

1. 任务评估由具体执行人给出评估时间，然后乘以相应的系数，作为实际的任务期限。

2. 某些需要形成共识的地方，可以故意引导对方出错，然后给出相应的正确方法。 比如代码难看难维护， 可以先采用“每周代码show”的方式， 逐渐形成集体对代码质量的重视， 达成共识之后，进而引入“代码评审”的方法。
 
接下来的沙龙时间里，我们会持续跟踪这个方法的实施效果。
 
考虑到目标项目是真实的项目，为了保证实施的隐蔽性，本次沙龙会议纪要仅在沙龙成员和特邀嘉宾内部发布，请勿外传！