项目管理沙龙第十次聚会纪要-AOM项目的敏捷实践

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

会议一开始，就有人跟我们分享了一个名词，“分析瘫痪”，意思是不断地追求完美，结果始终在设计状态，无法到下一步去。详细可参考这个 http://hi.baidu.com/parad1se/blog/item/8724472a71b87e25d52af1a3.html 和 google。与会者都有同感。而破解“分析瘫痪”的诀窍，就是“敢于行动”，因为人就是在不断的错误中学习并改进的，不犯错，当然也就谈不上改进了。如果用沙龙常用的术语说，那就是“敏捷”。

今天的敏捷话题是分享AOM的敏捷过程。AOM是一个基础平台产品，在实施敏捷之前，采用周计划的模式来管理，即每周定制计划，组员按照计划完成工作，并且更新自己的工作状态。这种管理模式在需求控制，角色分工，任务分配和团队激励上，都存在较大的问题，所以AOM团队想到了利用敏捷方法来改进项目管理。所以这一点上AOM和NSEC最大的不同，就是AOM是主动“拥抱敏捷”，而NSEC是“被敏捷”。

AOM有产品经理（PO）的角色，负责需求的最终拍板。敏捷教练（SM）负责团队敏捷过程的正确性和改进，但是和一般SCRUM规则不同的是，SM是项目组之外的人，且不负责项目的进度，项目的进度由项目组自己来管理。项目组依然有项目经理（PM）的角色，但是在实行过程中，这个角色的作用被弱化了，变成了一些关键事务的协调人和PO的代理人。日常的进度监控工作，则由轮换的“主持人”完成。

在产品的计划会议上，AOM使用纸牌游戏的方式来对每一个任务评估point数。并且根据团队的能力，设置sprint计划的point总数。和NSEC不同，AOM不会在每一个sprint中预留point，而是将一些项目之外的事务变成backlog放到sprint中一起进行跟踪。如果外部干扰太大，就要及时调整sprint中未开始的backlog，删掉一些优先级较低的backlog，并且用更小的backlog弥补进来，并保持sprint总的point数不变。就像长跑的时候呼吸和脚步的频率要非常一致才能跑得很好一样，敏捷过程也很重视“节奏”。所以AOM的sprint时间长度也基本是稳定的，目前是两周一个sprint，部分为三周。

在产品的回顾会议上，所有的问题都会被分析一遍，对于投票最多的前三项问题，会在下一个sprint中生成backlog并分配专人跟踪和完成。其他问题，如果是规则性的，就会去更新规则。

每日站立会议上，主持人会先向大家通报一下上一个工作日的task完成情况和进度的预测，然后团队每个人再回答一下三个问题：昨天做了什么，今天做了什么，遇到什么困难。在日常任务的跟踪上，AOM通过纸质的任务看板和纸质的backlog卡来进行跟踪，每天下班前，主持人会根据看板的进度情况，敦促当事人及时更新任务卡片，并将任务卡片的进度数据同步到ScrumWorks中（大家回忆起了读书时候的“课代表”）。每次站立会议都会有一个人记录会议纪要，并且将其内容登记在wiki上，以便全体成员（包括缺席人员）备查。

主持人机制在AOM敏捷过程中占据十分重要的地位，它负责对团队每个成员进行敏捷管理意识和能力的培养，通过角色轮换的方式，让团队成员获得一种比本职角色更高的角度去看待软件开发和管理，尝试他们以前不太有机会去尝试的团队管理或设计方面的工作。在AOM团队中，主持人按周轮换，除了跟进项目进度之外，还要负责控制会议的时间。

不同的会议，控制时间的基准也是不一样的。对于计划会议，则每个backlog的讨论时间=会议计划长度/sprint中backlog数目。对于每日例会，每个人发言时间=15分钟/发言人数，最长没人发言时间不超过（30分钟/发言人数）。回顾会议上，每个问题的讨论时间=会议计划长度/问题总数。另外，对于讨论和辩论，控制时间是每项讨论和辩论不超过1分钟。只要超过时间，主持人就会主动打断，维持会议效率。

AOM同时也引入了“结对”的机制。组员自由结对，分主副手。所有的任务要两个人同时签名才有效，主程序员负责编码，副手负责单元测试，并且在sprint结束之后，主副手角色调换，副手负责维护该部分代码，包括修改bug和增强功能。这种结对延伸到项目组的每一个方面，所以每天站立会议会议纪要，也是会议主持人的结对伙伴来记录的。

AOM的敏捷过程中，大家发现使用纸牌、看板、任务卡片的方式，使整个过程充满了“游戏性”，具有很强的“参与感”。组员之间互相关心，在任务分配上更公平，工作效率更高，每项任务中的职责分工更明确，当然产品的质量也更高了。而且轮换主持机制让每个人都有更多的角色体验，可以让PM空出来思考更深层的问题。

目前AOM尚未在每个sprint结束之前进行show case。

与会者在讲述过程中插入了很多的讨论和分析，大致有如下几个话题：

与会者首先关心的是“需求来源”问题。因为项目的特殊性，AOM的需求更多来自于团队的拍脑袋，其次是公司内其他项目提出的要求。与会者一致认为，不管怎样，“有目的的手机用户需求”是肯定的，但是需求的筛选也是值得注意的方面，要结合项目的目标来进行。比如iPhone多半可以肯定不会去实现什么“双卡双待”和“收音机”的功能。但是有时候的“拍脑袋”和“摸着石头过河”也是不可避免的。这就要求PO充分担负起责任来，PM也要担当一下，比如某些需要预研才能确定做不做的技术，就要先动起来。

关于showcase，有人发现公司的一个怪现象：“产品的名字大家都听过，但是长相大多都不知道”。仅从这个意义上去看，showcase的重要性也是不言而喻的。大家一致的意思是要用起来，因为它可以让团队充分感受到目标和时间的压力。但是初期不一定非要每个sprint都show，在掌握方法之后慢慢提高，最终达到每个sprint都show的程度。但是一定要注意showcase是要求不要做特别的准备的，也就意味着showcase的成果就是日常工作成果。

“到底有多敏捷”是与会者提出的一个问题，有人觉得公司内部的过程改进组织就应该来回答这种问题，通过对项目组敏捷过程的观察，给出一个敏捷的级别，并且以此来逐步指导和提高项目组的敏捷程度。

有人关心“任务没有人领”的问题，经过讨论，我们发现虽然有部分任务会存在只有某人能够完成的情况，但是只要经过细分，大部分任务的难度都会降下来，并降到其他人也可以认领的程度。有人发现如果能够将“个人学习计划和任务结合起来”，是可以降低某些任务对人的依赖性的。

“如果团队中有破坏者怎么办”，这是有人用“六顶思考帽”的思考方式提出的问题。但是大家在讨论中发现，利用每日例会和看板，我们很容易发现那些虚假的进度汇报，并且敏捷中持续的沟通，让谎言在其中生存的难度变得极大。一旦“破坏者”被发现，要么被清除出团队，要么自动离开，或者痛改前非，融入团队。

在分析“轮换支持”机制的时候，有人举例了IBM的60%工作，40%沟通的时间安排比例，谈到了如何让员工更多思考，聪明工作的问题。不过未展开。

敏捷其实不是一种新生的事务，无论从其指导思想，还是各种使用的工具和方法，大部分都是敏捷提出之前就已经存在的，比如看板就是源自丰田的精益管理方法，每日例会则来自于服务行业。现在敏捷已经不仅限于软件开发，在市场销售、公司管理都有应用案例。

最后，有人提出“敏捷管理方法如何在餐厅运用”的问题，引起了大家热烈的讨论，但是考虑到沙龙的时间，讨论在一片欢乐中结束，不过我们不排除以后会抽出一个专题来讨论这个问题。