我尝试在我的团队中实践Scrum。但是我的同事问我:
我们的软件有明确的要求。那么为什么我们要使用scrum
我怎样才能说服他放弃这件事呢?
没有人应该使用scrum，就像他们不应该使用vi或emacs，或汰渍洗衣粉，或脆花生酱一样。Scrum只是团队协作的众多方式之一。如果你的团队已经在一起很好地工作，那么可能没有什么好的理由切换到scrum。
scrum的好处在于它可以帮助团队将一个大问题分解成一系列较小的问题，并及时地按照优先顺序交付这些问题的解决方案。它还可以让你更容易地发现你是否在构建错误的东西，这样你就有时间进行修正。
如果软件行业在过去的几十年里学到了什么，那就是需求一直在变化。Scrum的设计就是为了接受这个事实，而不是希望它不会发生。
从管理的角度来看，scrum允许规划经理更准确地预测项目作为一个整体何时完成。历史表明，人们的任务越小，就越容易估计。如果你已经有并理解了你的需求，但是你正在构建的东西你估计需要两个月的时间，它可能需要两个月，但可能需要三个月。或四个。或8。通过制作故事并确定其大小的过程可能会产生更准确的估计。
说了这么多，如果你的团队不想使用scrum，你绝对不应该。Scrum在团队使用时有效，而不是个人的集合。如果团队作为一个整体不愿意遵循scrum，那么scrum将是无效的。
敏捷可能是件好事的原因有很多，假设虽然需求是100%清楚的，但执行的最有价值的顺序是什么并不清楚，并且提前交付部分产品可能已经提前返回价值。
-
一些功能的早期交付可能已经解锁价值． 构建应用程序时，可以先释放管理模块，然后是打印模块，然后是报表模块，最后是底层业务逻辑。按照这个顺序，在实际实现业务逻辑之前，值将为0。在这段时间里，其他模块会积满灰尘，它们的价值也会被推迟。通过首先发布业务逻辑和部分报表和管理模块，您可能能够更早地将应用程序投入生产，并更快地释放价值。这样你会有更好的投资回报率。
-
提前交付可以让您证明您的架构，部署和基础设施． 通过以更小的部分交付产品(这可能允许一小部分用户早期使用它)，您可以早期证明您的体系结构(从而降低风险)，并且您可以获得多次测试部署脚本的机会，确保一旦您的应用程序被大量使用，您可以在更短的时间内部署修复，并且对最终用户的影响更小。
-
提前交付提供反馈． 你认为(假设)需求是100%清楚的。在许多情况下，他们很少这样做，或者通过看到实际的应用程序，可能会意识到它实际上并没有做它需要做的事情。通过定期展示工作软件，您有机会不断证明您100%了解需求。如果你采用的是传统的瀑布式设计，你就得赌一把，因为你知道需求。在敏捷的方式中，出错的风险要低得多，因为您将在早期知道自己错了，并且仍然有机会改变方向。
-
许多应用程序中60%的功能从未使用过． 以微软的word为例。实际上有多少人在使用可扩展性模型?嵌入式XML ?随着时间的推移，产品中还会出现更多这样的功能。没错，这些功能都有市场，但很多人可以使用稍微高级一点的写字板。除非你拥有微软那样的市场影响力，否则以瀑布式的方式构建一个拥有word所有功能的应用程序，然后发布它，将会非常非常昂贵。使用敏捷方法可以让您尽早停止，永远不会构建不需要的功能。对于许多瀑布式开发项目，需求通常比实际需要的要多。许多"业务"要求的东西比他们最终知道的要多，许多人认为安全总比后悔好，他们把所有他们认为可能需要的东西都添加到需求规范中。
-
你能证明100%已知需求的假设是正确的吗？ 我想这是不可能的。特别是因为需求会随着时间的推移而变化。但是对于小项目，或者对于非常明确的工作(可能是法律或某种认证要求的)，人们可以确切地知道需要什么，然后构建它。
您只提到需求是已知的。这是否意味着您的开发人员已经确切地知道如何构建它?你知道如何测试它了吗?你知道最有用的交货顺序是什么吗?您的基础结构能够处理应用程序吗?所有这些问题都可以通过构建实际产品的一小部分并不断集成它们来轻松回答。
当然，你可能能够在纸上准确地计算出所有的部分将如何组合在一起，在极少数情况下，当你了解这个领域，使用经过验证的技术(通常是稍老的技术)，并且已经构建了至少3次非常相似的东西。在这些情况下，你允许自己通过使用旧的东西来创造一些技术债务，你可能不需要任何形式的敏捷。
现在，您是否需要在此过程中进行大量的Backlog细化?如果很多需求都是已知的，则可能不会。由于所有其他的好理由，我说用敏捷的方式工作有很多好处，特别是如果假设所有的需求都是已知的。
如果你的团队接受这些理由，那么无论如何都要采用敏捷。不管是scrum还是别的什么。至少要定期交付，并确保您的工作得到持续的测试和部署。如果你的团队不接受它，那就试着用一种包含上述要点的方式来构建你的瀑布项目。定期交付，确保你的工作得到持续的测试和部署……等待……这听起来像敏捷，如果不是至少迭代和增量交付;)。