敏捷项目管理Scrum连载系列之Scrum理论与应用篇（二）

往期文章

敏捷项目管理Scrum连载系列——初识Scrum

敏捷项目管理Scrum连载系列之Scrum理论与应用篇（一）

---

前言

在上期文章中，老程和大家分享了Scrum的两大部分

理论部分：

1. 方法
2. 核心思想
3. 事件
4. 价值观

---

正文部分

经验性过程
软件开发是一个复杂的活动，不同于制造业流水线的生产模式， 在软件产品开发的过程中不仅存在着需求的不确定性，也存在着技术的不确定性，再加上参与软件开发的主体通常是由多人组成的软件开发团队，加上人的因素，就让整个软件开发的活动变得非常复杂。如上图所示，软件开发活动通常处在下图的很复杂的区域。

为了管理软件开发活动，我们引入过程控制来管理它，一种方式是预定义的过程（瀑布式项目管理方法），另一种是经验过程（敏捷项目管理中的Scrum管理方法），在这里老程和大家重申一点，敏捷不是灵丹妙药，在实际项目中，需要结合公司的现状进行选择。

老程也提过很多人对敏捷持怀疑状态，这个只是理论，用于实战不行，我们用过，后来效果还是那个样子。
每每遇到这样的话题，老程只会默默一笑，不予理会。中医和西医那个更好？
要我说，都好也都不好，对症下药，药到病除的方子，不管中西，都是好方子。

预定义的过程

我们所熟知的是预定义的过程，它通常使用已知的方法解决已知的问题。制造业生产线就是典型的预订也过程，如生产啤酒、汽车、燃气灶等等生产线。预定义的过程特点就是给与固定的输入得到固定输出。

比如一条生产燃气灶的流水线，从第一个上线工位扫码绑定时，预定义的工艺卡就开始播放，到下一个工位，产品条码被识别，开始播放下一个工艺卡。它的优势在于可以大规模的批量生产，缺点在于，机动性差，无法满足个性化的生产；一旦过程定义出现错误，或者产品上存在瑕疵，就会造成较大的损失。

如果我们期望解决的问题比价复杂，并且存在较大的不确定性，我们需要使用经验性过程。其特点是过程不能够完全地英豪，结果是不可预知的，生产过程也是不确定的。比如研究一款新产品、5G、曲面屏等等，在这个过程中，我们需要通过不断刺探用户/市场的真实反馈，进行适应和调整，使过程能够产生我们需要的结果。

软件研发通产存在很多很多的不确定性，并且生产过程及其的复杂，所以更适合经验性的过程进行管理。我知道，有很多很多的管理者认为，IT研发也可以像流水线一样，按照统一的流程，统一的方法进行编写，对此，我持保留意见。

---

Scrum 是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周（团队可根据自身的环境和情况决定其长短）。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog,同时需要做到限制WIP。有很多的公司的CEO认为，上了敏捷开发速度就会增加，实际上，如果不限制WIP，就如同高速免费时引起的阻塞。

在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

应用的范围

• 研究识别可行的市场、技术、产品、已经产品能力；
• 开发产品、增强功能
• 基于Scrum持续的增量交付；
• 自适应环境（云、其他环境）为产品提供支撑；
• 支持和更新产品

---

Scrum的基本应用
开发过程中四要素：人、过程、技术、工具。对一个成功的软件项目来说，这四样要素都不可省。其中人占了很重要的部分，一个好的公司一定有着一个好的团队，一个好的团队一定是气氛融洽，公平、透明的一群人组成的。提到这不得不提，网上流传某某大厂实行996，很多企业的管理者脑筋一动，我们也搞996。要知道，996的背后是什么？是高薪和认可以及尊重，现在很多的企业，最起码的尊重都没有，天天靠喊喊口号，打打鸡血，自我麻痹，卵用没有。

Scum推进技巧之榜样的力量

Scrum的项目管理是比较容易实践的，正如上节课中，我提到“容易入门、难以精通”，对于想用敏捷的团队，我建议可以先做这个。

1. 要营造一个一体化的团（devops）队，也就是将所有有墙的部门通通打掉， 直接按照项目型运作，把大家拉到一起，不要考虑你原来是什么部门，先把项目做出来再说。

2. 很多项目中，总是存在这样的一些人，项目成功不成功对他们是无关紧要的（火腿和蛋的故事），但是有些人项目不成功对他们是非常 重要的，而真正的敏捷项目就要这些人来挂帅，并且这些人是站在一条战线上的，所以就叫拉到一体化的团队里面来，大家都对交付负责。

3. 就是办公环境最好 也能够随着改变。以前大家都是那种小格间的方式，但是这种方式是非常不利于做交流和做项目的。

4. 就是现身说法，拉动其他人键入。前面讲到有很多这样的人会到团队中去说 敏捷怎么怎么好，但是如果你让一些对项目成功不成功都不相关的人去讲是没用的，因为大家一听，首先就会质疑50%，所以就需要树立榜样，让成功的团队现身说法，讲他们当时是怎么开展敏捷的，这样别人一听才能理解到原来你是这么这么做的，弄明白敏捷的做法，消除因未知所带来的的恐惧，自然会有很多人愿意加入进来。

---

前面的两篇文章和这一篇，讲的都是理论，旨在让大伙明白传统型项目管理和敏捷式项目管理的区别，为后面的文章做铺垫。

在下一篇文章中，我们将讲解Scrum在团队中的应用，基于实战分享哦，敬请期待。