除了甘特图，你还应该了解些什么软件项目管理知识

前言

A bad plan is better than no plan.

坏计划也好过没有计划。--彼得·蒂尔《从0到1》

在软件开发工程中，很少会有单打独斗的程序员。这是因为现代较常见的软件项目通常都非常复杂，所要求的人力、资源、时间也比较多，仅由一个开发者来完成大型软件项目无异于 “愚公移山”。因此，软件开发通常离不开团队协作和项目管理。所谓项目管理（Project Management），简单来就是有序的组织、规划、执行并完成项目中各个任务的一种方法论。当然，实际项目管理的范畴还远不止这些，通常还会涉及资源调配、优先级制定、进度追踪等。它是工业革命的产物，也是现代管理学的分支，它能够大幅提高工程完成效率以及成功率。本文讨论的主要是软件项目管理，相较于传统的建筑工程、机械工程等项目管理有很大的不同。早期的 IT 项目管理来自于建筑工程等传统项目管理方法论，在信息时代早期扮演了重要的角色，大幅提高了软件开发和协同效率。然而，随着 IT 行业高速发展，消费者产品需求瞬息万变，市场形势变得越来越不确定（Volatile），传统的软件项目管理模式已经不能再满足软件开发需求。因此，现代软件开发模式，例如敏捷开发（Agile Development），应运而生，成为了很多互联网企业的首选。

传统项目管理模式（例如瀑布流）有什么弊端？现代项目管理模式（例如敏捷）又有什么改进？我们是否应该完全摈弃瀑布流模式，全面拥抱敏捷开发？作为一个程序员，是否应该掌握一些项目管理知识以及相关工具？作为一个团队领导，应该如何制定项目管理流程保证开发效率和质量？如果读者有类似上述问题的疑惑，本篇文章将为您详细分析和解答。

传统方法论

本文所说的传统项目管理模式，是指历史较长、更注重框架与方法论、同时也相对更严格的项目管理框架。比较典型的传统软件项目管理模式是瀑布流开发模式（Waterfall），这是很多传统软件项目采用的开发模式，其中涉及到的工具甘特图也是广为人知，甚至成为了项目管理的标志；另外比较流行的传统项目管理框架有美国的 PMBOK（全称 Project Management Body of Knowledge），这是一本项目管理指南，是由全球项目管理会员组织 PMI 编辑发布，也是专业项目管理认证 PMP 的基础，它基本上可以看作是项目管理中的 “驾驶执照”；英国政府发布的 IT 项目管理认证 PRINCE2 跟 PMBOK 一样，也是全球权威的软件项目管理框架，比较适合大型项目；此外，还有注重质量管理的 6 Sigma，这是跟其他方法论完全不一样的方法论，强调质量优先，比较适合于制造业等需要高精度质量控制的行业。 本文不打算介绍所有的项目管理方法论，想详细了解的读者可以参考 Project Manager 相关介绍。

瀑布流开发模式

所谓瀑布流开发模式（Waterfall），从字面上很容易理解：整个开发项目由很多任务及子任务组成；每个任务有对应计划的开始和结束时间；任务之间通常有依赖关系以及先后顺序；如果将任务的计划执行时间在 甘特图（Gantt Chart）上可视化出来，长得就跟瀑布流一样。下面是一个典型的项目管理甘特图。

上面的甘特图反映了软件项目的系统开发生命周期（SDLC，全称 System Development Lifecycle），其中包含需求分析（Requirements Analysis）、系统设计（System Design）、开发（Development）、测试（Testing）、验收（Closing）等多个阶段。需求分析通常在软件项目的最初始阶段，而测试与验收一般在项目的最后阶段。在瀑布流开发模式中，项目任务一环扣一环，紧密联系，项目管理者可以在甘特图中一目了然的看到看到项目的全貌。通过规划项目任务和设计甘特图，我们似乎期待可以准确预测项目周期与完成时间。

然而，“理想很丰满，现实很骨感”。瀑布流开发模式最大的问题来自于它对不确定性的低容忍度。如今市场环境快速变化，商业机会转瞬即逝，企业的生存压力已经不允许开发团队花大量的时间在需求分析和系统设计上。很多传统软件企业花几个月甚至一年的时间在分析和设计阶段，又花几个月甚至几年的时间开发、测试和上线产品，最后却发现终端用户不满意甚至拒绝使用，大量的时间成本和人工成本打了水漂。这是很多 IT 企业用血换来的教训。现在的企业更希望有更灵活的软件项目管理框架来满足业务发展。

PMBOK

前面说过，PMBOK 支撑的 PMP 认证是项目管理行业中的 “驾驶执照”，这是因为 PMBOK 中定义的管理框架几乎适用于任何一个行业。它诞生于上个世纪 70 年代，经过几十年的发展到如今已经发布到第 6 版，到如今可以说是最知名和最权威的项目管理指南。简单来说，PMBOK 把项目管理概括为 10 个领域，通过对这 10 个领域的系统管理，可以有效的控制整个项目的进度、成本、资源等因素，保证项目成功，最大限度控制风险。希望详细了解 PMBOK 的读者可以参考 PMI 官网。

PMBOK 不只是适用于 IT 行业，各行各业都可以运用它的项目管理框架，因此是一个大而全的方法论。包括像之前提到的瀑布流开发模式，也是 PMBOK 中部分领域的实现方法而已。它们二者并不互斥。同样，PMBOK 的方法论涉及的概念较多，因此也显得比较正式，其中的工作说明（SOW，全称 Statement of Work）、Charter、Closing Report 都可以作为项目的正式文档，因此在大型项目中使用得较多。

其他

笔者没有深入接触过 PRINCE2 和 6 Sigma，因此就不详细展开了。

敏捷开发模式

在如今 IT 行业快速发展的大背景下，已经很少有 IT 从业者没听说过敏捷开发（Agile Development）了。敏捷开发也如字面上的意思，是非常注重灵活性和交互性的项目管理方法。在实践敏捷管理的过程中，项目团队可以跳出传统项目管理框架中条条框框，变得更加 “敏捷”。那些看似不可变更的目标、截止日期甚至是交付物，在敏捷框架下都可以随实际情况灵活调整。就像没有重型铠甲和大规模辎重束缚的蒙古射骑兵，敏捷开发团队可以快速适应战场环境的变化，从而灵活而轻松的攻破敌人的防线。

敏捷开发特点

敏捷开发有三个比较大的特点。

1. 由开发周期驱动。每个周期通常持续 1-4 周，从而保证每个周期的交付物都可以被频繁评估，从而让开发精力聚焦于产品优化。
2. 基于迭代周期。每个迭代周期通常是固定的，因此周期结束时总会有一个有效的交付物。
3. 对客户开放。客户可以在周期结束后看到半成品，从而提高了透明性与交互性。

敏捷开发意义

敏捷开发与传统开发模式的最大不同点，是敏捷开发不要求在项目执行前提前安排整个项目任务的执行计划。在敏捷开发中，整个项目被分割成多个更可控的阶段，在阶段完成处设定项目里程碑（Milestone），而在里程碑达成时客户（Customer）及相关干系人（Statekholder）可以根据阶段交付物对半成品（WIP，全称 Work in Progress）提供反馈，为下一个阶段的开发提供参考意见。在这样不断的 “规划 -> 开发 -> 反馈 -> 规划 -> ...” 周期性的开发模式中，最终交付的产品有很大可能会跟客户期待的更加接近，从而提高客户的满意度，也避免了大量的资源浪费。在全球畅销书《精益创业》中，作者提到：企业的最大浪费是来自于 “返工”。因此，采用敏捷开发的模式，项目团队可以有效规避需求变化带来的风险。这让实践敏捷开发的企业具有反脆弱性，能够在不断的迭代和学习中获得适应环境不确定性的能力。

迭代/时期/冲刺

敏捷开发中的一个核心概念是迭代（Iteration），也叫时期（Phase）或冲刺（Sprint）。这是敏捷开发中的最小时间单元，通常持续 1-4 周。反复迭代的过程其实也就是一个不断优化产品的过程。在迭代周期结束时，项目组通常会完成一部分或整个（可能不太完善的）产品，同时也会收到来自客户或相关干系人的反馈，从而为下一次迭代提供参考。例如，在一个广告投放后台管理系统开发项目中，第一阶段开发团队根据初期的简单需求开发出了一个非常基本的后台系统，只有投放广告和查看数据的核心功能；项目组将第一阶段的交付物在Sprint 1 总结会上呈现给终端用户，并且告知这不是最终成品；终端用户根据实际使用场景提出一些改进意见，或汇报一些 Bug；在接下来的阶段中，项目组就可以根据 Sprint 1 的反馈进行调整，将优化任务和 Bug 修复任务安排在 Sprint 2；然后这样不断迭代下去。这样一来，每个迭代完成之后，最终的交付产品会越来越接近最优的状态。

相关角色

在敏捷开发中，有几个重要角色。

• 产品负责人（Product Owner）。主要负责与客户、相关干系人以及开发团队沟通，制定用户故事（User Stories），以及需要持续与开发团队一起协作，保证开发进度。
• 开发团队成员（Development Team Members）。项目任务实施者，通常是开发者、设计师、测试人员等。
• 流程管理员（Scrum Master）。负责整个 Scrum 流程在项目中顺利实施和开发，解决客户与开发者的沟通障碍。这个角色可以是跟产品负责人重叠的。
• 相关干系人（Stakeholders）。不一定直接负责产品，但可能间接参与到产品的使用流程中。

每日站会

每日站会（Daily Stand Meeting）是项目组成员每日面对面沟通的一个持续大约 15 分钟的短会，主要目的是追踪项目开发任务进度，解决任务执行过程中遇到的问题，以及协调资源等。不要简单的以为站会就是 “站着开会”。首先，大家站在一起，能够让项目组成员集中注意力，将重心聚焦于项目任务上来；其次，较短的会议时间能够让整个会议不偏离主题，而且更能够节省时间，提高工作效率；另外，每日站会要求项目组成员每人都需要发言，这提高了团队成员的参与度。下图是一个每日站会的例子。

看板

看板（Kanban）是丰田 JIT （Just in Time）精益生产中的管理工具。它为项目任务设置了不同的状态，通常是 Backlog、To Do、In Progress、Testing、Done 这几个状态。而每个任务会预估一个完成所需时间，通常是按小时计。另一个重要的任务属性是优先级，在积压阶段（Backlog），开发团队成员需要根据各自的经验和专业知识判断该任务所需要的时间，以及定义任务的优先级。不同类别的任务用不同的颜色标记。这样的看版在每日站会中能发挥很大作用，因为它清晰直观，能够一目了然。当任务改变状态时，例如开发者从 Backlog 取出一个任务卡片，将会被直接放在 To Do 中。下图是一个看板示意图。

当然，我们现在有更现代化的工具来管理看板的流程，不用人工设计一个看板或购买大量的贴纸。一些比较热门的工具包括 Trello、禅道、Teambition等。

燃尽图

燃尽图（Burndown Chart）是一个追踪项目进度的有效工具。它是一个随时间递减的曲线。横轴是持续时间，纵轴是剩余故事价值总数、任务预计总工时等。燃尽图通常有两个曲线：一个是预估的理想下降曲线，通常是随时间线性下降的；另一个是实际下降曲线，表示在某个时间实际剩余的价值或工时等。如果实际曲线在某时刻高于理想曲线，则表示目前进度是落后的；相反，如果实际曲线低于理想曲线，说明进度是领先的。下图是一个燃尽图示意图。

用户故事和项目任务

在敏捷开发中，用户故事（User Story）跟项目任务（Project Task）比较容易混淆。它们分别是站在不同角色的角度上描述的。用户故事简单来就是的终端用户的使用场景。它通常是由项目负责人向客户或终端用户收集整理而成，并会站在业务的角度制定各个故事的价值（Value）以及优先级（Priority）。而项目任务是开发团队根据用户故事的描述，结合实际系统架构、技术环境等因素，分解出来的实际开发任务，相对于用户故事来说更加具有落地性。因此，可以说项目任务是为了实现用户故事而制定的。用户故事的价值和优先级通常需要结合实际业务背景以及商业价值，因此需要由产品负责人来主导制定；项目任务通常更加偏技术层面，因此需要由对技术模块比较了解的开发人员制定。这些通常都可以在初期会议以及里程碑总结会议来完成。

Scrum vs 极限编程（XP）

对于了解过敏捷开发的读者来说，可能已经听说过 Scrum，甚至将 Scrum 等同于敏捷。这个看法从技术层面上来说是不确切的。Scrum，包括之后会聊到的极限编程（XP，全称 Extreme Programming），只是敏捷开发方法论下的一种指导框架。它们的目标都是在保证项目质量的条件下，尽可能增强灵活性；很多专业术语，例如用户故事、项目任务、迭代，都是一致的。它们不同点主要在于如何执行每一次迭代或冲刺。

在 Scrum 中，每一个迭代中的项目计划通常是不允许变更的，一旦在迭代初期决定后，用户故事和项目任务就不允许改变了。只有当该迭代结束之后，才可以根据实际反馈做相应调整。这样做的好处在于，项目团队成员可以在每一次迭代中集中精力完成各自的任务，保证实现功能的质量和效率，以追求该迭代周期完成之后产品的稳定性和可靠性。但这样做也有缺点，那就是相对来说不够 “敏捷”，因为一旦项目计划确定，就不允许加入新的需求或更改已有需求。另外，Scrum 的迭代周期一般是 2-4 周，相对来说比较长。

而在 XP 中，未实现的用户故事则是可以被新的用户故事替换的，前提是实现这两个用户故事的工时是相等的。而在用户故事的优先级上，XP 更加严格，它要求实际项目任务要严格遵守用户故事的优先级。另外，XP 在软件实施过程要求也更为严格，一般需要采用测试驱动开发（TDD，全称 Test Driven Development）、自动化测试（Automated Testing）、结对编程、重构等相对严格的质量控制措施。因此，虽然 XP 在用户故事上显得比较灵活，但在软件实施流程上要求非常严格，因此对开发团队的技术和经验要求也更高。

其他

敏捷开发还包括不少其他方面的元素，本文限于篇幅原因就不深入介绍了。

如何选择项目管理模式

在实际工作中，我们会遇到大大小小的项目需求，如何选择项目管理模式是一个重要问题。但可惜的是，目前来说没有一个完美的解决方案，能够适应所有软件类项目。本文虽然花了大量的篇幅介绍敏捷开发，但并不意味着敏捷开发是全能的。传统的瀑布流开发模式有很多弊端，但它也有不少适用场景，例如政府 IT 项目，或一些专业性很强的开发项目。而且，在做项目管理模式的选择前，还需要充分了解一些表面上看不那么明显的隐性因素，例如企业文化、组织架构、行业背景、人力资源、团队经验等等。因此，笔者认为，敏捷开发并不是解决一切问题的万能钥匙。我们在做实际选择前应该三思而后行。甚至在一些情况下，还需要根据实际情况综合各种管理模式做一定程度的调整，让其变得更加适合当前的项目背景。

敏捷开发的优势非常明显，它能够更加适应快速变化的商业和市场环境，帮助企业克服一些不确定性因素，从而能够交付更多对用户有价值的产品。而且，敏捷开发通常比起传统的瀑布流开发来说，省略了很多不必要的文档以及繁琐的沟通流程，因此通常会花更少的时间完成更多的事情。但是，敏捷开发相对于传统的瀑布流开发来说显得不那么正式，有点像 “游击队” vs “正规军” 的感觉。传统项目管理模式，例如 PMBOK，有非常完备的流程管理和文档管理，对于长期性的大型项目来说是更为合适的。

所以，笔者认为，如果你的市场环境和客户需求会频繁变化，而这种不确定性会大幅度影响企业的财务健康，那你千万不要犹豫，就选敏捷开发。相反，如果市场环境变化没那么快，而客户需求相对来说比较固定，另外还具有较高的合规性以及正式文档要求，例如政府 IT 项目，那么你可以选择用传统的项目管理模式，例如瀑布流开发模式。

总结

本篇文章是一个关于软件开发项目管理模式的科普文。我们从传统的项目管理开始，介绍了一些常见的方法论，例如瀑布流、PMBOK 等，并分析了它们的不足。然后，根据传统项目管理方法论的缺点，引入了现在比较流行的敏捷开发，介绍了敏捷开发的特点、意义、核心概念等等。最后，本文根据传统方法论以及敏捷开发的比较，得出了传统方法论和敏捷开发分别适用的项目场景，认为敏捷开发适合更易变的市场环境，而传统项目管理适合需求变化不大的项目。

实际上，敏捷开发的概念主要强调了灵活性与反馈，它能够给我们带来一些启示。读者可以试着回答一下这些笔者联想到的问题：身型巨大的恐龙为什么会灭绝？为什么说猫有九条命？三体人为什么能够在极端环境下生存？曾经的龙头企业（例如柯达）为何依然会倒下？曾经只在校园推广的 Facebook 为何能够成为社交巨无霸？笔者不打算一一讲解，相信读者可以根据自己的理解做一些判断。

或许部分程序员认为项目管理只是项目经理的事情，我需要做的只是写一手好代码。但笔者始终认为：只会写代码的程序员叫码农，不止会写代码的程序员才叫工程师。因此，我们开发人员还是应该多了解一些技术以外的知识，例如今天介绍的项目管理知识。否则，今后能写代码的人工智能或许会抢大家的饭碗。

社区

如果您对笔者的文章感兴趣，可以加笔者微信 tikazyq1 并注明 "码之道"，笔者会将你拉入 "码之道" 交流群。