在以前的工作场所工作过 Scrum(ish) 之后，我正试图在我的新工作场所为一个全新的项目实施它（我不是 Scrum 专家）。在开始编写故事之前，我们有一些编码的先决条件（同时正在整理）。诸如数据库设计、API 设计等。我们计划使用两周的迭代，但我不清楚第一个（或两个）如何为客户提供有用的东西，如果我们首先必须“有可能交付”打下一些基础”？关于如何治疗这个的任何想法？
问问题
324 次
2 回答
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 之旅，坚持住，因为最初很难。一旦你完全“明白”了，那么你和你的公司就会很高兴你做到了。
于 2013-07-31T11:59:49.047 回答
1
在理想的世界中，技术先决条件应该被考虑到每个故事的估计中，并且您应该只实施“刚好足够”来完成故事。请参阅“做最简单的可能可行的事情”
为什么需要设计 API 或数据库？尽量避免Big Up 前端设计。避免预先构建框架，应用YAGNI
您很难理解如何在两周内发货，因为您本末倒置；也就是说，您的优先级是错误的。重要的是交付客户软件——而不是构建数据库或 API 设计。
这是对长期生产力的一种交易，您应该避免积累过多的技术债务。许多敏捷方法论会争辩说，像这样的前期工作是错误的，因此应该避免以尽量减少浪费。精益软件建议将决策推迟到最后责任时刻。
于 2013-07-23T08:36:13.247 回答