得刚毕业的时候自己很单纯，满脑子“技术（而且只有核心技术）在身，走遍天下的思想”；因而当时花了大量的精力研究CPU架构，操作系统核心，编程技术等等。自己当初的技术屌丝状态今天仍然历历在目！

当然，随着工作经历的增多，我对于软件行业的看法也在潜移默化的变化着。今天小编就以一位资深的软件从业人员的视角，来给大家介绍一下软件研发项目的管理模式之敏捷（Scrum/Agile）开发。

我入行软件领域的时候还是瀑布模式的天下。从市场部给出市场趋势结果，产品部门给出产品设计文档，研发团队进行技术评估，反馈，沟通，确定产品最终设计；最后，导入研发团队进行任务细化，切分，安排开发任务以及对应的优先级等等。这一套过程走下来没有几个月是完不成的！因为这里面包含的不仅仅是单个部门的工作，各个部门对问题的理解差异以及心理期望各不相同，这些需要有大量的沟通，协调来统一产品方向。

粗略估算，单这些任务基本上就会花上几个月的时间才能完成。而这些仅仅是一个项目的开始，因为这个阶段仅仅是给出了产品的目标结果，对于实际的开发过程以及产品质量保证环节都还没有开始。

研发团队拿到经过技术评估后产品需求，需要根据开发工作的特点进行细化，拆分，分配到开发人员手中；而开发人员也需要进行一些基本的软件设计：给出接口文档，架构文档等；也需要与测试团队沟通好测试的各种case，避免后续测试存在理解上的偏差。最后才是coding，release，测试。

说了这么多读者是不是觉得有点跑题了？非也！我们是要先看到传统的瀑布模式对于目前软件行业的局限，才能能够深刻理解美国人发明“敏捷”的根源。那么软件研发有什么特点呢？尤其是互联网相关的软件研发呢？一句话：“研发速度跟不上需求变化！”这一点相信大家都可以很容易理解。软件行业尤其是互联网行业，机遇无处不在，市场也无处不在，就看谁能够快速抓住用户需求的痛点并迅速抢占市场份额，俗称“圈羊”。如果慢了半拍就相当于将机会拱手送人。因此，快速决策，快速研发，快速投入市场进行营销就是企业尤其创新型互联网企业的命门！

试想，互联网企业继续使用“瀑布法”开发软件，那么从需求变更提出，到最终上线运营，营销，这个周期一般至少要1年左右（产品需求定案3个月，5个月研发，4个月修复bug）！而且周期越长，风险越不可控制！输的可能就越惨！对于做deliver业务的企业也会失去客户的新人，毕竟客户花钱还是很紧着看成果的。

不得不说，欧美人的洞察力跟分析能力，创新能力还是很强的。针对于这些问题， 他们提出了颠覆“瀑布模式”的全新项目管理模式：“敏捷模式”（Agile）。

什么是敏捷（Agile）？我接触这个概念最初在德企，我现在也非常感激当初的manager能够将这个先进的东西介绍给我们的研发团队。为了便于圈外人士理解，我需要介绍一点有趣的事情。

橄榄球在国内不是很流行，但是在美国以及英国却是十分受欢迎的一种体育运动（大家别觉得我跑题了，容我慢慢道来）这个体育运动的规则相对自由，可以推人，抱人，绊人等等，反正我们常见体育运动里面严重犯规的行为很多在橄榄球里面都是可以接受的，尤其是美式橄榄球，也叫硬式橄榄球（因为全身穿戴坚硬的盔甲，头戴安全帽而知名，目的就是保护球员），得分的方式是计算球朝向对方球门前进的yard，或者射门进球。

由于项目规则十分自由，导致球员的冲撞，对抗异常激烈；如果一个球员拿着球，站在原地不动，基本就会被球员压成面饼了！如果拿着球跑动，那么后面将有千军万马追着你，跟你抢球！目的就一个：想尽办法抢夺对方的球，避免对方抱着球向自己的球门前进哪怕一个yard！

谁拿到球，那么谁就是整个团队的核心，所有的成员必须时刻帮助这位球员抱着球前进，并时刻准备着接球，成为下一波进攻（每次一波进攻的阵营被成为Scrum）的团队核心！也就是说整个团队是没有一个类似固定的前锋，后卫的概念的，每个队员随时都有可能成为整个比赛的焦点。

谈到这里我们应该了解道，其实“敏捷/Agile”的目标是实现像橄榄球运动那样，高效，快速，小步伐的接近目标。而后面我们要提到的Scrum就是“敏捷/Agile”理论的一种实现方法（也有许多其他的实现方式，在此不做讨论）。

准确的说，敏捷（Agile）是一种理论并非一种工程实现的方法，而后面的Scrum才是Agile的一种实现方法。敏捷（Agile）的核心理念是：将复杂的项目周期（主要是针对于瀑布模型的周期过长问题）进行切分，使之成为既不是太长也不太短的项目小周期（太长了就退缩回瀑布模型了；太短了会影响各个团队的工作效率），称为“迭代”周期（橄榄球中球保持在一个队员手中，传递到下一个队员之前的时间），每个迭代周期的边界时间点（球传到下一个人手中的时候），允许需求变更（其余的时间点不允许需求变更）调整研发团队的开发任务目标，同时开发过程中不强调过程，流程，文档等传统观念的细节（规则比较自由），而是强调可用软件的输出（球的向前传输以及进球）；即一切工作的重心都要以可用软件的交付为最高目标，其余的事情都是可以降低优先级。

一句话总结：敏捷的核心是围绕交付客户满意的软件为目标的，所有的活动都要围绕着这个主题进行。

下面我们来看看Scrum的运作方式。首先不是所有的团队以及项目都使用Scrum管理，Scrum不是“万能药”，它是有局限性的，这一点要有清晰的认识。我们在此只是针对软件开发项目来进行介绍。

首先，Scrum认为团队是整个项目的核心资产。对于传统的团队（团队人数过多，比如超过10人以上的大团队；团队人员素质不均的）不适合使用Scrum来管理，需要做相应的培训，改造，转型才可以成功。

Scrum要求团队内的成员都是精干的多面手。即每位成员无论是在技术的扎实度，广度以及自我管理（时间管理，态度以及责任心）方面都是非常优秀的！因为Scrum在运作过程中每位成员随时都有可能成为整个team的核心，即资源的调度者。我们应该可以想象一位憋足的资源管理者可以产生的后果吧？所以Scrum要求的团队是精英团队！

其次，Scrum适合项目周期紧，项目交付任务有明确目标的项目。比如，一个项目评估下来可能持续几年甚至几十年，那么Scrum不适合；抑或是科研单位那种没有明确目标的探索性质的项目也不适合使用Scrum管理。用我的话来说“Scrum是一个锋利的短刀，适合快速的披荆斩棘项目；对于愚公移山这种项目，不合适！”

Scrum中相关的角色：

1. 团队（负责把产品做出来，承担研发责任；其实所有的一切都是为了让团队更加高效的输出而存在的）

2. Scrum Master（整个团队的老保姆，大到会议的主持，需求的变更，Scrum流程的实践管理；小到团队的开发环境不舒适，成员的情绪问题，开发测试设备等杂七杂八的都由这位负责）

3. Product Owner（产品需求提出方，以Backlog的形式给出，并定义开发任务的优先级，与研发团队一起评估复杂度，对整个产品的业务成功与否承担责任即ROI）

4. 其他相关人员（QA，UIUX等）

Scrum中的一些术语：

1. Sprint（冲刺）就是团队的一个开发周期，就是常说的“迭代”

2. Product Backlog，PO梳理出的具有一定业务价值的工作任务，通常比较大，整个项目会被切分成许多Backlog并形成研发团队的原始工作任务池。它有一个非常重要的属性：优先级，这直接决定了哪些任务先做，哪些后做。

3. User Story（故事，我一直认为这个主流翻译非常low，但我也找不到比这个好的翻译了）与Backlog相比较，是团队从技术的角度对Backlog的一种细化与分解并确认需求细节可投入开发的产物。User Story详细定义了开发人员能够执行的需求细节，以及质量的标准，复杂度等信息。

4. Task 是比User Story粒度更小的任务，不是所有的User Story都要分解成Task，按照实际需求来处理。

5. Sprint Daily Standup Meeting 每日的工作会议，不是为了汇报任务，而是要清除昨天的开发过程中遇到的问题以及今天要做的任务中存在的问题。

6. Sprint Planning Meeting Sprint开始前的计划会议，决定下一个Sprint需要做的Backlog并进行分解形成User Story以及Task，形成可执行的任务

7. Sprint Retrospective Meeting每个Sprint结束后的会议用于总结上一个Sprint做的好的与不好的地方并给出改进调整措施。

8. Story Points由于开发工作分类不同（前端跟后端开发，Java与C++复杂度各不相同），造成同一个User Story的复杂度评估无法标准化（传统的做法是 人/日）这种评估方法不够客观。为了抽象出不同劳动的复杂度，方便评估任务复杂度，做好风险控制，使用point作为无差别的单位做任务复杂度评估。通常可以将 1point=1.5 人/日计算即可

9. Kanban就是一个可以写字的白板，用于在展会中管理当前Sprint的Backlog，User Story，Task的状态，进度等。大致如下图所示。

10. Burning Down Chart 燃烧曲线，用于管理任务的进度，工作的剩余量的一张图

11. Scrum软件，用于方便管理人员管理Backlog，User Story，Task等工具

Scrum的运作框架如下：

Scrum/Agile并不要求所有采用这种模式的团队严格遵守每一个原则，只要能够高效，高品质的输出可用的产品即可。现在比较流行的XP，Test Driven等开发模式也都可以与Scrum结合，达到更好的团队管理效果。

本文为镛人随笔原创作品，侵权必究。