设计的地点和时间，体系结构活动发生在Scrum中。

Question

传统的瀑布生命周期包括一个特定的设计和规划阶段。在Scrum中，没有大的预先设计。将特性分解成故事、在sprint计划会议和sprint期间进行的少量设计。

由于sprint计划的时间限制在几个小时之内，所以团队没有足够的时间来决定技术选择，哪些职责属于不同的组件部署和发布考虑事项等等。

设计工作属于哪里？是否应该在短跑计划之前进行，并将细节添加到故事或任务中？或者应该有一个额外的设计会议，后冲刺计划？

Answer 1

设计应该规划，或者作为足够的额外的故事点的每一个故事或作为一个单独的故事。而且你的团队中仍然应该有拥有和监控设计的设计师。

问题在于，设计代表的是“没有业务价值”，而纯粹的用户故事通常会被抛到“团队”(Team)上，这是一群专注于工作软件而不是可维护软件的开发人员。因此，随着scrum的引入，有意识的设计往往不再存在。当然，对于规模更大、运行时间更长的产品来说，这是一个等待发生的独裁者。不过，这将是一个无声的过程，开发时间和回来的bug数量将逐渐增加。没有人会认为这是令人担忧的，我们只会做更多的测试，并对此感到满意。最近测试已经发展成为一件大事，这不是巧合，也是在运行中的软件项目中。

幸运的是，今天我们也有一个花哨的名字：“技术债务”。这是一个伟大的名字，因为它听起来不像一个问题，任何人，但开发团队。这意味着这也是他们的错，技术人员应该为此付出代价，而不是企业。这是他们的问题。

公平地说，这是真的。开发团队必须确保他们进行设计。他们是自我组织的，必须有足够的力量来储备资源去做必要的事情。他们致力于他们自己制定的计划。将有压力，以推进功能，但它仍然是他们的责任，以思考事情和有责任的人，谁要对此负责和负责。Scrum确实增加了维护这些基础的难度。

Answer 2

罗伯特·C·马丁( Robert C. Martin )曾在youtube上谈论过这个问题：

土地掠夺者忘记了

在这里，他强调了一个共同的问题，即在Scrum体系结构和设计中从来没有提到过，所以应该由团队来确定项目中的体系结构和期望应该意味着什么。

我个人的观点是，您应该在团队中有一个实例来负责架构和设计。合同应该是:建筑师决定如何推进这些主题。另一方面，他不应该能够逃避由此产生的问题，这些问题来自他的决定。

在我当前的项目中，我们目前面临着几个问题，这些问题主要可以归结为概念多样化和分散的代码基础，除了完全忽略体系结构而不是以一种有用的方式扩展它的实现之外。

关键是:如果您无法在团队中找到对给定需求的最佳体系结构的理解，那么您就不能期望团队做得很好。对于代码质量问题也是如此。一个民主的解决这个问题的方法，可能是一种方式，如果理解只是在一些小的一点上不同。但是，如果你有重要的讨论，但不能导致解决，你最好让某人的立场，以作出决定。

Answer 3

设计工作属于哪里？

无论是在第一次冲刺之前，还是在第一次冲刺上，也可能是在以后的每一次冲刺中。有些团队会在第一次冲刺之前有一段时间来做这些决定。如果决策不是在第一个sprint之前做出的，那么您必须在第一个sprint中至少完成一些设计和结构设计工作。随着项目通过sprint的推进，将有机会执行额外的设计和架构任务。范围取决于正在构建的产品的范围和复杂性。

我认为，在任何sprint计划会议上，说“我们没有足够的信息来构建这个架构，所以我们的第一个故事(或任务)需要提出架构”这样的说法是完全正确的。

scrum的全部意义在于让团队能够对如何构建产品做出决策。如果产品构建过程的一部分涉及到对体系结构的决定，那么对于任何sprint来说，这都是一个非常好的活动。