我开始了解 Scrum，我有兴趣与我们的开发团队一起尝试。我对此有很多疑问……但我最大的心理障碍是实际的图形设计。
在我们当前的开发周期 [瀑布式] 中，我们的图形设计师根据松散的 PRD 来布置包含所有图像等的页面。如果我们要利用 Scrum 的方法，这种发展将如何进行？我认为我们习惯于看到大局并朝着大局前进……而不是在进行过程中将视觉部分拼凑在一起，这正是我期望的 Scrum 图形设计政策。
至少对积压工作中的所有功能进行线框图是闻所未闻的吗？还是更明智的做法——对于第一个 sprint——以这样一种方式设计它的功能，以便我们可以随时添加其他 sprint 的新特性？ （即，当需要新功能时，请讨论“这适合当前设计的什么地方？”）
【问题讨论】：
这是我建议您这样做的方式（即，我们尝试这样做的方式）
Pre-sprint 0：确保您对自己想做的事情有一个清晰的认识。不必非常详细，但不应该是“我们要建立一个社交网站”
Sprint 0：开发工具 - 设置 CI 服务器，处理部署脚本等，所有基本框架都完成了。最后，您应该能够按下一个按钮（最坏的情况：在远程服务器上运行单个命令），该按钮在您的源代码控制系统中获取代码，构建它，打包它，运行您想要的所有测试它，报告回来，如果可能的话，将它安装在测试服务器上（或至少产生一个可以安装在测试服务器上的包）。
此时，设计师正在做线框图。他们的目标是为您认为需要的尽可能多的站点制作基本线框（考虑站点地图和流程，而不是字段和像素）。然后，完成后，与项目经理一起制定最重要的事情，并详细了解线框图。还不是像素。
项目经理等正在与设计师和业务/利益相关者合作，编写故事和任务供您执行和跟踪。显然，他们需要对站点地图等有所了解才能做到这一点。
这可能需要不止一个 sprint。从一个开始（我建议 2-3 周冲刺 - 1 太短，4 太长），看看你还需要做多少等等。
所以在 sprint 0 结束时，您有：
那么你开始 sprint 1
请记住，对于前 3 到 4 个 sprint，您将不知道自己在 sprint 中可以做多少工作，所以请不要误会！尽可能多地完成工作（按照业务/ PM 安排的优先顺序），你认为你可以肯定完成。您以后可以随时服用更多！
您大量开发这些页面，而设计人员则对下一个页面块进行线框设计（由 PM 确定）。也许设计师为那些页面做艺术，所以你可以在下一个冲刺中做
因此，您正在开发您拥有的东西，而设计师正在为您的下一个 sprint 设计东西。
当然，他们也可以进行 Scrum 流程，只是他们更早开始了 sprint！
现在重复，直到你完成工作
在 sprint 期间，如果（例如）需求发生变化或添加了新内容，则会为此编写一个新故事，并将其安排到工作中。如果它是超高优先级，它可能会排在首位，并成为下一个 sprint 的首要项目（通常是 1-2 周之后）。或者它可能是一个很好的，所以它在底部 - 业务决定。
产品经理/设计师需要知道他们可以改变事物，但改变确实会产生后果，因此来回改变和改变不符合他们的（财务）利益。但需求确实会发生变化，XP 和 Scrum 比瀑布式处理更好。
别忘了：
您的 PM 应该能够预测项目何时结束 - 查看您在上一个 sprint 中完成了多少工作（您的速度），然后将剩余的工作量除以该数字，您就得到了 sprint 的数量去。很简单。
哦，阅读故事点 - 不要以数小时或数天来估计故事。使用积分。为了引导它，只需制作您估计（例如）8 的第一个故事（序列为 1、2、3、5、8、13、21、40、60、100、无限）。然后取第二个故事，并相对于第一个故事估计它 - 它是工作的两倍（13）吗？一半的工作（5）？差不多 (8)？
在冲刺结束时，将你完成的分数相加，这就是你的速度。你可以承诺在下一个 sprint 中做的最大工作量就是这个量。你总是可以提前停止冲刺，或者如果你提前用完，就从积压的工作中抽出更多的工作。随着你的前进，你的速度会稳定下来。
该死，我确定有关于如何运行它的书籍等，所以我会停下来:)
【讨论】：
我非常不同意 Jason 提供的答案。 Scrum 的全部意义在于摆脱设计师首先“做他们的事情”然后继续做其他事情的方法。这完全 100% 违反了所有精益/Scrum 原则！
如何将设计师融入 Scrum 流程？把它们扔进去！确保您不只是将瀑布项目包装到 Scrum 中，因为这是通往失败的最佳途径！ Scrum 只有在没有例外地实施时才有效。 “Scrum，但是……”是最糟糕的项目模型。组织工作，以便可以同时进行设计和开发。不要过度设计初始设计，而是让它成为一个推拉式的情况，硬币的两面都会影响另一面。 Scrum 的重点是迭代、迭代和迭代，因此要充分利用这一点。
此外，实际上完全避开传统的基于 Photoshop 的设计是相当精简的。您可以从 Signal vs. Noise 中的这篇出色的博客文章中了解更多信息： http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop
【讨论】：
我之前做过这样的事情，设计师在早期迭代中做他们的事情，他们的工作产品被开发团队在以后的迭代中使用。随着开发团队开始工作，设计师会继续进行项目的其他部分，或者可能会进行其他项目。
我想我们已经习惯了看到大 拍照并驶向它
您仍然可以这样做。您的设计师可以进行更大的前期设计，开发团队可以使用 Scrum 进行迭代。
【讨论】：
对于 sprint 0 中的设计部分，您可以使用 Styletyles (http://styletil.es) 之类的技术来确定项目所需的图形样式。因此，您不需要预先进行大型设计，并且在冲刺时仍然保持敏捷。
【讨论】：
很简单！ :) 好吧，让我分享一下我们是如何做到的。
1) 产品负责人创建线框并添加到 backlog（我们使用 Yodiz，www.yodiz.com） 2）我们的平面设计师创建模型并将它们放在模型共享工具（www.concept.ly）上 3) 我们的开发人员致力于设置服务器。如果一切准备就绪，我们有非常聪明的产品负责人，您将始终有待选择的待办事项。
1) 开发人员开始制作最终的模型，这些模型在概念上已经完成。 2) 设计师在积压中由产品所有者添加的其他线框工作。
我告诉过你这很容易！
【讨论】：
我想分享。我是未来社交应用程序开发团队的 Scrum Master。这个团队有 1 名用户界面设计师、1 名用户体验设计师（我）、1 名前端开发人员（css、ajax 等）和 3 名程序员。
这是我们第一个使用 SCRUM 框架的项目，因此非常具有挑战性。 Scrum 日常会议的趋势是，我们的设计工作从未完全完成，因为我们最初的产品积压中有“用户希望被说服注册”之类的故事，然后我们在该故事中添加了“演示方式”，所以从在那里我们可以确定需要做什么（即我们需要做线框，完成文案等......）
那，可以做得更好。根据该故事逐项列出每项任务，并估计每项任务的时间。例如，在产品积压期间，我们可以从那里按顺序创建这些：站点地图 > 任务流 > 线框
现在的问题是，我们是否在 sprint 中完成所有这些工作？或者我们应该在任何 sprint 之前就这样做吗？如果我们在 sprint 之外进行，就违背了 scrum 的目的，对吗？
做过用户体验设计的人都知道，这些任务需要相当长的时间来准备。那么为什么不把所有这些都作为冲刺的一部分呢？让程序员也参与这些任务。
线框图在整个项目期间都非常重要。它就像建筑物的蓝图，从头到尾都在使用。
因此，在您的第一个 sprint 期间，根据产品积压工作制作初始线框图。并在每隔一个 sprint 期间相应地调整线框。我们的程序员将根据任务流程设计他们的代码，然后根据线框图直观地创建它。
哦，顺便说一句，不要太在意产品的外观（拥有初始设计模型总是一件好事）。相反，专注于用户的需求和愿望，并设计一个非常以用户为中心的流程来实现这一点。然后我们的设计师会弄清楚他将要设计什么样的界面。如果线框设计得当，设计师在设计用户界面时会遇到很少的问题。创建文案也是如此。
总之，在每次迭代中携手并进。对于那里的初学者（比如我），给 SCRUM 一个为你工作的机会。如果它适用于像 fantasyinteractive.com 这样的公司，那么它也适用于你吗:)
附言要获得出色的线框，请使用 omnigraffle (mac)，这太糟糕了！
【讨论】：
如果我们要利用 Scrum 的方法，这种发展会如何进行？
虽然这篇文章很老，但它促使我自己研究。我找到了 Jeff Patton 为 UX 设计师/从业者编写的“十二种新兴实践”，我认为它特别适合这个问题，并且是一个非常有用的框架集：
如果您想更深入地挖掘，jeff 会说出来agileproductdesign.com.
【讨论】：