敏捷、Scrum 和以客户为导向的开发

4.90/5 (14投票s)

2013年4月7日

4分钟阅读

55688

关于敏捷基本原则、Scrum 方法论和以客户为导向的软件开发的思考。

一个经典的软件开发问题

你是否曾经参与过一个历时数月的大型软件开发项目，但最终客户却不使用它？大多数开发人员都有过，而且可能不止一次。

确保你开发的软件真正满足客户的需求一直是软件开发中最大的挑战之一。解决这个问题是敏捷宣言背后的动机之一。敏捷宣言的第一指导原则指出

我们最优先考虑的是通过早期和持续交付有价值的软件来满足客户。

敏捷宣言是由 17 位软件开发人员组成的团队于 1991 年 2 月在犹他州举行为期两天的会议上制定的。它内容如下：

通过亲身实践以及帮助他人，我们正在发现开发软件的更好方法。通过这项工作，我们开始重视

个体和互动胜过流程和工具

工作的软件胜过详尽的文档

客户协作胜过合同谈判

响应变化胜过遵循计划

也就是说，尽管右侧各项有其价值，但我们更看重左侧各项。

虽然敏捷宣言和底层原则对软件开发实践没有具体说明，但大多数人会认为敏捷软件开发团队或过程有两个标志

如果你真正遵循这两个原则，你很可能会交付客户实际想要使用的软件。

当一个组织开始变得“敏捷”时，他们相对容易养成频繁向客户交付软件的习惯。不幸的是，客户协作更难做好，这也是本文其余部分的主题

如果你是一名软件开发人员，那么你很可能听说过 Scrum 方法论。你可以在维基百科上找到一个简短的描述，并在 JeffSutherland.com/ScrumPapers.pdf 上找到更广泛的文档。

简而言之，Scrum 涉及团队以称为 sprints 或迭代的增量周期交付软件。 scrum 团队由产品负责人、scrum 主管和团队成员组成。产品负责人被称为客户的声音，并在计划会议上充当客户的代理。

许多人将 Scrum 等同于敏捷，其创建者大力推广它作为敏捷软件开发过程。你可能会惊讶地发现，你可以完全按照 Scrum 方法论来做，而完全忽略实际的客户！

在 Scrum 方法论中，客户可能参与的唯一一点是在 sprint 审查期间，但这并不是强制性的。理论是让产品负责人（通常是产品设计师、产品经理或软件开发人员）充当客户的代理就足够了。问题是他们实际上不是客户。他们有自己的偏见和议程，不一定与客户的愿望或需求相符。

我并不是说 Scrum 是一种糟糕的软件开发方法，或者产品负责人毫无意义。我想说的是，为了避免创建 YAGNI （你不会需要它）的功能，你必须在迭代期间直接与客户协作。

敏捷不仅仅是一个流行语；它代表了商业软件开发的许多理想目标和原则。

虽然 Scrum 和其他敏捷软件开发过程已被证明具有价值，但我建议采用这些方法的组织仍然需要确保他们的软件开发过程是由客户驱动的。

我认为以下原则可以帮助任何软件开发团队，无论他们使用何种方法，以确保以客户为导向的开发过程