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

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

本次沙龙的主题是由NSEC项目组介绍他们的敏捷实践经验。作为公司第一个实施敏捷的项目，他们的成绩给整个公司带来了震动，也是公司其他项目实施敏捷的参考和基础。因为时间是所限，这次沙龙虽然只来得及只讨论了NSEC的四个问题，不过逐个问题讨论的过程中，我们涉及到了更多的方面。

上次沙龙提出的“代码秀”在NSEC实施了一周，效果不是很好，首先是频率问题，上次沙龙谈到的代码秀周期是“周”或“月”为单位，NSEC的实践证明以“天”为单位确实是太频繁了；其次是项目组太忙了，没时间总结，而且分散独立提出各自的代码片段，如果没有专人汇总收集的话，分享起来还是不太方便；另外出现的问题是，程序员知道某些做法是错误的，但是太忙了，没有时间去写的更好。对于最后一种情况，每日的代码审查效果会更好些。

NSEC启动的时候，由他们的敏捷教练给大家讲了一个多小时的敏捷方法，但是大部分人之前没有听说过敏捷，并不是十分了解敏捷给各方面带来的好处，当然也就没什么想法，用时髦的说法，就是属于“被推行”敏捷的。在实施的过程中，感觉每日例会有些用处，另外就是感觉工作压力大了，尤其是在结对的时候。于此相对应，AOM的敏捷实施就好很多，感觉推行起来比较有趣。当然最开始也有一个敏捷启动会议，说明一下试试敏捷对大家的好处，使大家能够理解并支持。所以项目的敏捷启动会议是很重要。AOM的实施过程中对角色划分有了一定的改进，把标准定义中的ScrumMaster职责划归两个角色，一个是PM，负责项目的进度，另外则是新的ScrumMaster，他仅负责和保证敏捷的规则实施的准确性。这样的分工，敏捷教练可以身兼多个项目组的教练职责。

另外需要说明的是，因为NSEC的项目进度压力比较大，依然加班比较多。这种NSEC达到的快速交付效果，到底是敏捷带来的还是加班带来的，其实很难分清。即使从现在来看，也一样。

PM对敏捷能否正确理解是很重要的。有一段时间，NSEC的敏捷教练因为工作关系只要一没去跟踪，敏捷规则就会松懈下来。如果项目组内部有人熟悉敏捷，保持持续的跟踪，效果会更好一些。在敏捷的实施过程中提出了很多的问题，比如状态更新不及时，多任务并发的时候如何去处理等等。NSEC项目组采用的方法是ScrumWorks和卡片同时进行的方法，所以每个人除了去更新卡片的进度之外，同时还要去更新软件里边的进度，所以忘记更新的概率很大。在AOM的实施过程中，同样也是ScrumWorks和卡片同时使用，但是做了改进，每个人都只需要去更新卡片的进度，并由专人把每个卡片的进度同步到ScrumWorks中去。这个工作由每日例会的主持人负责。除了同步进度之外，主持人还需要每天在例会开始时候向大家报告项目的总体进度（已做的、正在进行的、未开始的），并且还要对本次sprint的完成时间进行预估，除了例会之外，还需要负责sprint计划会议和回顾会议。AOM的例会主持人是每周轮换的。每周轮换主持人的效果很好，每个人的积极性和学习都非常投入，项目成员对于一些深入的做法也比较容易接受。一个典型的例子就是他们的设计和文档工作，做到了很仔细的程度。但是每周轮换主持人也有不好的地方，就是团队主持人的能力提高速度比较慢，因为每周都是新人，所以每周都是初学者状态，直到一次轮换结束。如果在此期间敏捷教练缺席的话，敏捷制度就可能松懈。相比而言，ASPI项目的轮换做得就比较好，轮换是以月为单位。主持人有充分的时间来学习和提高，即使敏捷教练缺席，主持人也可以担当起“规则的维护者”这个角色来的。

从AOM和NSEC的敏捷实施过程中来看，都出现了每个人都只关注局部而忽视总体的情况，最后解决的方法也大同小异，基本都是派出一个专人去负责这个事情。也就是我们的敏捷团队中依然存在有“架构师”的角色。

在任务评估方面，NSEC是最早引入“打扑克”backlog评估方式的项目组，但是NSEC在backlog评估完毕之后，没有去进一步跟踪point数和实际工时的对应关系，也没有在总结回顾的时候评估point评估的准确性。对比AOM团队和BPM团队，目前也仅评估了每一个backlog的point数，并没有深入去评估每个task和工时的对应关系。ASPI评估了point和每个task的工时，但是没有去跟踪两者的对应关系。从实践来看，不把point换算成实际的工时，对敏捷的继续发展没有多大的影响。但是和NSEC相比，其他几个项目组采用了简单的效率计算公式，就是“效率=sprint的总point数/（人数×sprint工作日数）”，这个效率就是每人每工作日可以完成的point数，目前的数据是1个point/人日，因为一个point对应0.5工作日，所以也就是平均工作效率为50%，虽然有提高的空间，但是也已经够可以了。

在我们参考的书中特别提出，敏捷在实施三个月之后会有危机出现。事实上我们虽然没有出现危机，但是也有了一些的坏味道，比如改进错误的速度降低了，随意增加backlog或随意扩大backlog的工作量，随着时间的推移，在大家习惯了敏捷的快节奏之后，问题会出现的更多，应该对此做好准备。

NSEC的另外问题是缺少一些敏捷的要素，比如现场没有客户或客户代表，做完之后和客户的期望不符导致返工等。经过我们的讨论，认为客户不再现场有几种方法可以缓解或避免：要么有客户代表或让产品经理和客户充分沟通，要么使用设计原型和客户事先就达成一致，要么就是建立UAT（User Acceptance Testing）环境，让用户可以实时看到系统的变化情况。

在讨论过程中，与会人员冒出了两句经典错误认识，“敏捷不要文档”和“敏捷实施需要高超的能力”，遭到了大家的驳斥。首先说“敏捷不要文档”，对了一半，敏捷只是不要重复去做一些只为了看的文档，敏捷更重视过程原始数据的收集和分析。也就是说，如果文档和推进项目进度和交付的目标不符，那么这种文档就尽量不要，即使需要，也是用最简单的格式记录一些原始数据就可以了。至于“敏捷实施需要高超的能力”，正好相反，从我们的实践中就可以知道，敏捷的实施并不需要什么特别的准备，只需要项目团队实施敏捷的共识而已。更不需要管理者有什么高超的能力，无论如何实施，敏捷都“不会做的比项目组的现状更差”。

下一次的聚会，依然讨论NSEC的敏捷实践。