共计 7051 个字符，预计需要花费 18 分钟才能阅读完成。
前言
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-4 周，从而保障每个周期的交付物都能够被频繁评估，从而让开发精力聚焦于产品优化。
- 基于迭代周期。每个迭代周期通常是固定的，因而周期完结时总会有一个无效的交付物。
- 对客户凋谢。客户能够在周期完结后看到半成品，从而进步了透明性与交互性。
麻利开发意义
麻利开发与传统开发模式的最大不同点，是麻利开发不要求在我的项目执行前提前安顿整个我的项目工作的执行打算。在麻利开发中，整个我的项目被宰割成多个更可控的阶段，在阶段实现处设定我的项目 里程碑 （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 并注明 “ 码之道 ”，笔者会将你拉入 “ 码之道 ” 交换群。