在以前的工作场所工作Scrum（ish）后，我正在尝试在我的新工作场所实施一个全新的项目（我不是scrum专家）。在我们开始处理故事之前，我们有一些代码的先决条件（这些故事正在进行中。像数据库设计，api设计等等。我们计划使用两周的迭代，我不清楚第一个（或两个）如何为客户提供有用的东西，如果我们首先必须“可能发送”奠定了一些基础“？关于如何对待这个的任何想法？
答案 0 :(得分：1)
在一个理想的世界中，技术先决条件应该被考虑到每个故事的估计中，你应该只实现“足够”来完成故事。请参阅“Do The Simplest Thing That Could Possibly Work”
为什么需要设计API或数据库？尽量避免使用Big Up front design。避免预先构建框架，应用YAGNI
你很难理解如何在两周内发货，因为你在马前有车;也就是说，你的优先事项是错误的。重要的是提供客户软件 - 而不是构建数据库或API设计。
这是一项反对长期生产力的交易，你应该避免累积太多technical debt。许多敏捷方法论认为像这样的前期工作是错误的，因此应该避免以最大限度地减少浪费。精益软件建议将决策推迟到Last Responsible Moment。
答案 1 :(得分：1)
您所遇到的是非常典型的新团队想要迁移到Scrum，他们来自更传统的流程。适应Scrum是非常非常困难的，我们总是这样说，其原因是需要进行许多心态变化。
团队应该理解的第一个变化是，当将PBI（需求）引入Sprint时，它只是一个明确定义的需求而没有别的。这意味着没有设计，数据库模式或API的要求。团队必须在sprint中完成所有这些工作，并构建并测试需求。
如果你是Scrum的新手，你很可能会在座位上蠕动，以为无法做到这一点。你现在可能是对的，但这是努力工作的地方......改变团队的工作方式。这很难。
一些指示： -
小规模要求 - 大多数团队都面临着糟糕，模棱两可的要求，以前需要花费数天才能完成设计，构建和测试。本文的目的是学习将这些 EPIC 要求分解为更小的增量要求，其中每个要求都建立在之前，但明确增加了业务价值。现在，我将在这里直言不讳......这是大多数球队面临的最大挑战。就个人而言，我已经训练/指导Scrum多年来现在还没有发现任何不能分解成小要求的功能，平均估计完全完成2-3天。
团队组成 - 团队需要其中的人员具备设计，构建和测试PBI所需的所有技能。他们不应该依赖于团队之外的其他人。拥有依赖关系，削弱了团队，但它突出了管理层，没有足够的人具备专业技能。
Sprint计划 - 应该使用Sprint计划进行高级设计，并讨论团队如何解决每项要求。许多团队通过澄清弱的要求和辩论要求来浪费他们的冲刺计划。这表明需求薄弱，应予以解决。 Sprint计划是讨论如何来构建/测试PBI和而不是什么。
教练 - 我真的建议您聘请经验丰富的合同教练/顾问，让您前进并做正确的事。试图自己做这件事，只会导致一个不必要的痛苦世界。
架构 - 在项目开始时，团队和架构师花一两天头脑风暴产品的宏架构并讨论要使用的技术是没有错的。但是，当涉及新要求时，它们被设计并调整到产品中。这听起来很难，但使用正确的软件工程模式，使用SOLID原则，定义良好的模式以及强大的持续集成和单元测试。消除了糟糕架构的风险。毫无疑问，团队中应该有一名成员具备设计建筑师新要求的技能。 [网上有很多证据表明，重新分解的不断发展的架构会产生比大型前期架构更好的应用程序 - 但另一个辩论]
应用程序生命周期管理 - 使用CI，单元测试，测试实验室，持续部署，投资强大的ALM工具。为团队提供合适的工具可以让您快速交付，而且缺乏这些工作会让您感到瘫痪。具有自动化测试的CI对于增量产品至关重要，因为存在快速且持续的变化，并且您希望保护变更不会破坏先前的要求。
ScrumBut - Ken和Jeff不再支持使用ScrumBut一词，因为它被认为是精英主义，而且经常被视为贬低。相反，团队最好是实施Scrum并通过指导帮助他们。
欢迎来到您的Scrum之旅，因为它最初非常难以挂在那里。一旦你完全“得到它”，那么你和你的公司将非常高兴你做到了。