Scrum（一）敏捷开发之始

项目为什么会失败？

你可能会说：

• 没有市场调研，纯靠YY，做出来的产品不符合市场行情。
• 开发过程中，团队与客户两地，沟通太费力，无效沟通太多，浪费时间。
• 开发周期过长，互联网变化太快，等你的产品出来，黄瓜菜都凉了。
• 开发团队内部不和谐，各种经理、总监、架构等，听调不听宣。
• 一届领导一届政策。
• 销售跟客户吹牛太大，开发出来的产品hold不住了。
• 老板独裁，介入管理和开发具体事务中，严重干预。
• 极尽压缩工期，产品是赶出来的，哪有质量可言。996.ICU = 产品.ICU
• 项目镀金，客户需要一个碗，你给了一个镀金溜边印花的金碗。
• 。。。。。。

但总结起来就是：所做非所需

• 所做：你做出来的产品，可能是一个软件、app或一项服务。
• 所需：市场所需要的，客户所需要的或者被服务者所需要的。

思考下，在现实中，甲方在乙方眼中是什么样的形象？

你可能会说：

• 客户大概知道自己要什么，但说到具体，可能就说不出来了。
• 客户的需求总是在变，今天说这个功能要做成xxx，明天可能就变yyy了。
• 客户对自己的业务功能不了解，可能会造成业务死角、业务漏洞、业务不闭合等情况。

可能有一个词能表达你的意思：VUCA

• Volatility（易变性）
• Uncertainty（不确定性）
• Complexity（复杂性）
• Ambiguity（模糊性）

字面意思即其含义，社会是在变化的，而且越来越快，就像我们常听到的一句话，变是唯一的不变。客户与客户的需求是在变化的，你如果不随之变化，怎能达到客户所需？

瀑布模型

什么是瀑布模型？概念请自行谷度！
在早期，瀑布模型是很流行的一种开发方式。在现在，仍然有很多公司采用瀑布模型的开发方式。
在笔者理解，瀑布模型是一种思维方式的总结，比如你打算做一个产品、做一个功能，做一件事情等，你可能会这么想：

• 别人是怎么做的，我借鉴下。
• 我预计把这个产品、功能做什么什么样的，或者我怎么来做这件事情。
• 我得详细设计下这个产品、这个功能，或者我得好好想想怎么做这件事，得提前做好计划。
• 然后出了一份详尽的设计文档，或者一份周密的计划，在xxx时间我做xxx，在yyy时间我做yyy,...............
• 然后开始开发这个产品、功能，或者实践这份计划。
• 然后达成目标。

这就是瀑布模型的思维，瀑布模型是按照软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护六个阶段来实施的。
你能看出有什么问题来吗？如果你了解瀑布模型，你会说瀑布模型的突出缺点是不适应用户需求的变化。那么怎么理解这句话？哦，我指的不是字面意思，而是在上面这个例子中怎么体现这句话的。

再看看这个例子，也是按照瀑布模型做的：

• 客户给了一个完整的软件需求，5个月后，客户首次见到该成型的软件，GameOver。
• 客户给了一个完整的软件需求，然后开干，一个月后，客户修改了一次需求，两个月后，客户修改了一次需求，......，直到5个月，客户没有见到该成型的软件，GameOver。
• 客户在软件中新提了一个小的功能需求，一两周后，客户首次见到该功能实现，May be it's not OK，但我还有修改的机会。

什么区别？瀑布模型的应用粒度问题。

那怎么办？
你可能会说：

• 我在开发的过程中经常给客户演示和沟通就行了。
• 比如我把这个软件，分为1/2/3/4/5个大模块。
• 每个大模块下分为abcde小模块。
• 我先做1大模块的a小模块，然后给客户演示。不行就改呗。
• 再做1大模块的b小模块，然后给客户演示。不行就改。
• 。。。。。。
• 一直到开发完成，不就行了吗。

OK，当然行，这就是敏捷开发的思维。
但并不代表我们就否定瀑布模型。

敏捷宣言

• 个体与互动 高于 流程与工具
• 可用的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划

我们承认，右边这些条目是有价值的，但我们认为左边这些条目具有更高的价值。

敏捷宣言的理解

• 个体与互动 高于 流程与工具
  虽然甲乙方在合作过程中有各自的流程和工具，或者对接的流程与工具，这些必不可少，但个体与互动，经常性的沟通，更有必要，更能直观的表达各自的想法。有流程，但不一定拘泥于此。强调沟通，拥抱变化。做事为先，合作协作。
• 可用的软件 高于 详尽的文档
  详尽的文档，在前期有强大的指导意义，过程中持续记录变化，当文档被写出来的那一刻，就已经代表过期了，最终只是作为一份留存。但可用的软件才是我们的终极目标。因为客户不关注过程，只关心结果，也就是你做出来的软件。
• 客户合作 高于 合同谈判
  我们与客户是合作共赢，而非对立关系，我们要关注客户的价值，帮助客户成功，客户成功我们就成功。在双方达成目标的过程中，需要反复沟通验证，彼此信任，双方都可能会付出一些代价，金钱或时间等，因为有付出才有回报。合同谈判是一种约定，是一个合作开始的标志。
• 响应变化 高于 遵循计划
  市场是变化的，客户所需也是变化的，遵循计划很重要，但过程中我们要积极响应需求变化，变化产生价值，为客户创造价值，就是为我们自己创造价值。总之，计划赶不上变化。

题外话：甲方与乙方，应该是合作共赢的关系

完美状态：

• 甲方出需求，乙方出产品实现需求，甲方对产品很满意，皆大欢喜。

部分有问题的现状1：

• 甲方有大概的意向和大致的需求描述。
• 乙方来细化这些需求。
• 乙方来实现这些需求。
• 乙方交付产品。
• 甲方不满意。
• 互掐。
• 甲方项目失败，乙方拿不到尾款。

部分有问题的现状2：

• 甲方有明确的需求。
• 乙方根据需求来做。
• 甲方频繁修改需求
• 乙方交付产品
• 甲方不满意。甲方：这不是我要的。乙方：你需求就这样写的。
• 互掐。
• 甲方项目失败，乙方拿不到尾款。

部分有问题的现状.......

总结起来就是：

• 表现现象：乙方所做 非甲方所需。
• 深究原因：甲方没有看到产品的开发过程，不能及时提出反馈，乙方不能及时作出调整，导致产品越长越歪。
• 谁的责任：能单纯的说是甲方责任吗？能单纯的说是乙方的责任吗？

从甲乙方考虑，产品为什么会长歪：

• 甲方出的需求没问题，有详细的文档，按其需求出来的产品本来应该是可以市场成功的，但乙方没有理解需求，又没有跟甲方沟通，导致交付的产品与需求出入很大。
• 甲方有大概的意向，但不明确自己要什么，出的需求本身就有问题，乙方怎能做出甲方满意的产品。
• 。。。。。。
• 归根结底：沟通问题

敏捷的十二条原则

• 优先通过尽早和持续交付价值的能力来使客户满意。
• 对衍变的需求做出计划，尤其是是当变革导致竞争优势时，需要在整个开发过程中维持同样有价值的灵活性。
• 从几周到几个月，高频次地交付可工作的功能，交付间隔越短越好。
• 业务人员，客户或其拥护者，以及实施者必须在整个项目中每天一起工作。
• 项目的建立要基于被充分激励的个体。 给予他们必要的环境和支持，并充分相信他们能够完成工作。
• 私人谈话是将信息传递到交付团队内部和内部沟通的最高效和最有效的方法。
• 可工作的能力是衡量进度的主要标准。
• 敏捷过程有助于交付的可持续性。 项目资助人，开发人员和用户应该参与进来，并能够保持稳定的节奏直到项目完成。
• 持续关注技术卓越和良好的设计能够增强敏捷度。
• 简单–最大数量地保持工作项不开始的艺术–是本质，特别是在实施团队中。真正的敏捷开发项目并不强制在实施团队中有人为的报告和流程要求。
• 基于最少的一组指导原则，最佳架构、需求和设计诞生于自组织团队。
• 团队定期反思如何变得更加高效，并且能够优化和相应调整其行为。

一些有用的网址

• 敏捷宣言 官网 http://agilemanifesto.org/

• 敏捷原则 官网 http://agilemanifesto.org/principles.html

• 敏捷联盟 官网 https://www.scrumalliance.org/