今天仍是3.5节“山寨级项目管理”，是其第三部分：敏捷方法。

---

敏捷更是手段

互联网产品更新速度极快，很多产品保持着平均一两周发布一次的频率。这么快的速度，是为了迅速响应市场与用户，这个特点和互联网、软件项目的其他特性杂糅在一起，必然要有相应的方法论支撑，即“敏捷方法”。

从书本到实践

经典的软件工程方法旨在定义一套完备的过程规范，使软件开发的运作就像是机器设备的运转，人在其中则是可更换的零件，不论是谁参与其中，机器都能运转良好。这意味着：开发进度的可预见性，流程方法的固化与可复用，人力成本的节省，人员的流动不会对软件开发构成影响等等。这样的做法对于公司而言，是具有很大吸引力的。其背后所隐含的观点则是：软件从业者无须是具备非凡智力的高级人才，人是一种可以被任意替代的资源，并且软件的需求从项目开始的时候就是确定的，而且不会改变。这显然是不符合事实的。

所以在瞬息万变的互联网、软件行业，大家渐渐体会到敏捷的优势。作者参考了几种经典的敏捷模式，按照产品、团队的需要定制了属于自己的敏捷方法，特点如下：

1. 有计划，更要“拥抱变化”。随着时间变化，必然有新的信息出现，特别是市场环境、用户情况等瞬息万变的互联网业界。并且，项目估计的不确定性是会累积的，80%×80%×……以后，能确定的就更少了。所以强行遵守开始订的项目计划是没有意义的，而应该不断地修正，当然，在一开始的计划中间就应该留有一些弹性。

2. 迭代周期内尽量不加任务。敏捷再灵活，也不能容忍毫无控制的变化，“迭代”权衡了变化的成本和不变的成本，这是一个将“大项目长期不变”细化为“当前迭代不变，下次迭代待定”的做法。此外，如果某次迭代内的任务无法完成，可以为了时间点的要求，移出一部分任务到下一个迭代。可以把每个迭代看作一个小的瀑布模型。敏捷其实并没有排斥经典的项目管理方法，只是各种方法都应该用在最适合的场景，瀑布模型对于需求固定的项目，比如在管理一个工厂时就非常有效。

3. 集中工作，小步快跑。项目干系人都在一个区域办公，或者在一间会议室里办公，这样可充分利用白板和墙壁。相应地就要求团队较小，一般小于十几人，太多了可分割为多个团队。同时，项目有较短的迭代周期，通常是2～4周。集中工作也是为了倡导较少的文档，更多地口头沟通，其实这点对团队成员要求很高，特别是对国内的技术人员。

4. 持续细化需求，强调测试。需求唯一不变的特征就是“不断变化”，用不着在需求阶段纠缠。有些需求在开始的时候是提不出来的，或者说没法细化的，所以试图一次性完成需求分析的工作会存在“过度需求”的问题，是浪费时间的行为，到后来多半还是要改。我们在开发和测试过程中完善需求，而且特别看重测试驱动项目，更早的测试，重度的测试。这需要有很强很严谨的测试人员，TC编写、TC评审，甚至测试执行的过程可以用来补充和细化需求，比如业务逻辑里的一些限制条件、异常流程等，往往都是测试人员提出来的。

5. 不断发布，尽早交付。让需求方不断地、尽早地看到结果，并给予反馈。这点也要求需求方充分投入，包括集中办公、参与验收测试等。“冒烟测试”、“每日构建”就符合“尽早交付”的概念，可以让需求方尽早看到最新的产品；不断的发布也是为了把大问题分而治之，先解决最核心的，风险最大的部分。

项目中的敏捷沟通

“无论最终发现什么，我们必须理解并完全相信：每个人在其当时所处情况下，在其能力范围中，做了最大的努力。”这是敏捷里让人很温暖的一句话，让我们互相理解，又能激发团队力量。在此基础上，更顺畅的沟通成为可能。接下来说说团队在真实的项目中是如何沟通的，不妨叫做“敏捷沟通”。

每个项目，项目经理都会建立一个即时通信的IM群；一个临时的邮件列表，把项目干系人全部加入。IM用于实时沟通，比如发了重要邮件要大家赶紧收、文档有重要更新、测试环境正在构建暂时没法访问等，都可以在群里吼，群公告也可以贴上项目各种文档、资料的地址，以及一些测试环境的地址等公共信息。项目相关的第一封邮件，会把大家的E-mail收集齐，在此邮件最后说明“本项目干系人以此封邮件为准，大家的项目邮件可以直接回复全部并修改邮件名称和正文”，我们可以通过此邮件建立项目的邮件列表，之后有人员变化也可以随时增删。

作者亲历的团队坚持着经典的每日站立晨会，对于典型周期为2～4周的项目，控制粒度到“天”很有必要。

此外还有“项目看板”，可以视情况而定。项目看板可以和项目日报、晨会整合应用，板上横向为各个功能点的进度百分比，纵向为项目成员。每个项目成员负责的功能点，用一张张便笺表示，在项目开始的时候这些便笺都贴在0%的下方，随着项目的进行，它们就逐渐被拿到右边的方格里。每天晨会的时候，大家都围在白板前，集中调整便笺的位置。红黄绿不同颜色的便笺可以用来代表不同类型的任务，白板最右边留出一块写其他必要的信息，非常随意。用了这种看板，对于周期短的项目，邮件日报有时就可以省略了。这个看板的最大好处是随时可视，也是一种督促和帮助，另一方面，如果真遇到困难，大家也能及时发现并提供帮助。

对于相对长期的项目，可以将项目看板换为项目墙。上面主要有整个项目的时间轴、各个团队的重要里程碑、产品设计过程的一些可视化文档等。究其目的，也是让所有项目干系人随时可以了解到项目的各方面信息。

最后小结一下，从沟通扩大至整个敏捷方法，任何团队都在探索一个介于“无过程”和“过度过程”之间的折衷方案，使之给团队带来最大的收益。

与外包团队的敏捷合作

与外包团队一起做项目容易产生很多矛盾。首先，项目外包使得甲方不愿意砍需求。甲方认为，反正是乙方干活，合同都签了，那么显然是能多做一点就占一点便宜。比较而言，公司内部项目的需求在很大程度上是可以砍的，是“保质不保量”，这更符合敏捷的原则。但是项目外包，甲方在提需求的时候不愿把任何一个功能像平时那样推到下一期做，因为这个项目结束后，下一期在哪里都不知道，所以“保质保量”变成了“不保质保量”。

其次，甲方“验收测试”团队的工作方式与乙方配合困难。敏捷会导致提交测试的产品和最初的需求之间必然有很多变化，并且文档很难完全反映，而这种敏捷在公司内部之所以运行得很好，是因为PD、开发、测试人员在项目过程中可以充分交流。而项目外包的时候，甲方的测试团队没有和乙方一起办公，只是从一份颗粒度过粗的需求文档上派生出“验收测试”的TC，又因为验收有“考试”的性质，所以不允许乙方的开发人也参加甲方的TC评审，导致产品经理只能和甲方代表确认细节，必然导致双方对需求理解的鸿沟。虽然乙方也有自己的测试团队，但明显他们的测试强度比起甲方的验收测试差很多。

这是作者通过一次失败的经历总结的经验，最后作者提到“一次失败给人带来的收获往往大于一次成功，幸运的是我学到很多，不幸的是公司损失不少。最后送大家一句话：任何情况下，我们都要做好手头的事情，确保“就算这事儿对公司来说又黄了，我也要通过做事有所收获”。我认为这是大家都应该牢记的。