瀑布会让我们失败，Scrum能帮助我们在项目中取得成功吗？

Question

让我解释一下我们的情况。我们是一家小公司，拥有大约20+的员工，一直以来我们一直在实施标准瀑布模型，但没有取得多大的成功(因为需求的频繁变化和缺乏方向)。

因此，有一天，我们的CTO进来了，他向我们简要介绍了SCRUM的情况，我们大家都相信，这个模型对于像我们这样的小团队来说会很好。不幸的是，我们大家都没有任何经验，实践SCRUM，我们一直主要依靠在线资源和书籍。

然后我们要开始一个新的项目，我们正在做这样的事情：

1. 从业务域用户收集需求
2. 用UI和特性准备一个需求规范(这已经花了我们几个星期的时间)
3. 再次会见业务域用户，看看是否需要进行任何更改。
4. 一旦业务用户同意了规范，我们将把这些特性输入到产品目录中。
5. 将这些特性分解为任务并分配给sprint

我们应该采取更灵活的方法吗？喜欢

1. 从利益相关者那里收集需求
2. 开始创建史诗般的用户故事，并与利益相关者共同完成。
3. 将这些史诗故事分解成较小的故事(一些ui支持)，并分配给短跑(2周)。
4. 我们向他们展示我们在这两周里所做的一切，得到他们的反馈，并为下一次冲刺做好计划。

考虑到我们的项目的性质，我们经常面对多变的需求和缺乏方向的挑战，那么上面的Scrum/Agile点会给我们带来什么好处，为什么上面的瀑布方法会让我们失败呢？

Answer 1

第二种方法更符合敏捷/scrum的精神，但它也要求客户承诺定期访问以查看进度并讨论进一步的特性。

如果客户对他们这方面的努力感到不安，或者他们已经对自己想要的东西有了一个很好的想法，那么您的第一个方法可能会更有建设性。

scrum的关键之一是，客户在产品的生产顺序上有很大的发言权，所以让他们清楚地指出他们希望更早拥有哪些功能，以及如果预算过大，哪些功能可能会落在垃圾桶里。如果客户在某些需求/故事上改变了主意，特别是如果这些需求/故事尚未实现，不要大惊小怪。

另一种更像scrum的方法，但类似于第一种方法，是这样的：

1. 收集需求
2. 将需求拆分成故事，并将它们放到一个待办事项中
3. 先从故事“创建架构”和"UI建议“开始
4. 在冲刺期间，与客户讨论您的建议。
5. 改进待办事项
6. 当每个sprint结束时，从待办事项中选择下一个顶级X故事来实现。

Answer 2

SCRUM (以及一般的敏捷方法)的主要优点是，您从涉众那里得到了更好、更快的反馈(对于实现，而不仅仅是规范)，因此，在一些事情上工作几周或几个月的风险就更小了，而最终却不是他们想要的。此外，您通常会更早地交付最有用的特性(由于优先级和sprint发布周期)。

如果你们都同意从这些优势中受益，并且如果涉众愿意做他们的部分(给出更频繁的反馈)，那么是的，您应该使用SCRUM (您描述的第二个过程)而不是瀑布(您描述的第一个过程与SCRUM无关)。

Answer 3

你似乎又回到了旧的/已知的程序上。SCRUM /敏捷开发的一个关键概念是，您没有一个大的预先规范。当然，您需要从一开始就了解整个视图，但是不能将每个细节都放在规范中。这就是导致瀑布过程的原因，这是不好的，因为它不灵活，变化或新的见解是昂贵的。

当你从Scrum开始的时候，你应该有一个专家Scrum如果你的团队里没有一个，你应该雇一个。至少在最初的几次冲刺。

你也应该得到你的管理层的支持(就像你所做的那样)，并得到你的客户的支持，因为(S)他需要为产品所有者提供服务。最后一点(客户/产品所有者的可用性)在我的经验中通常不是这样的。在这些情况下，敏捷仍然是有意义的，因为您可以更容易地改变方向，并且可以得到对您的工作的快速反馈。

顺便说一句:通常您没有指定UI应该是什么样的。这是一个源自于特性描述的隐式要求。当然会有一个风格指南，它涵盖了所有基本的UI概念，但是您不会针对不同的特性进行特殊的UI操作，除非这是特性的目标。