关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。
想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。
6年前关闭。
Improve this question
我开始了解 Scrum，我有兴趣与我们的开发团队一起尝试。我对此有很多疑问……但我最大的心理障碍是实际的图形设计。
在我们当前的开发周期 [瀑布式] 中，我们的图形设计师根据松散的 PRD 布置包含所有图像等的页面。如果我们使用 Scrum 的方法，这种发展将如何进行？我认为我们习惯于看到大局并朝着它前进……而不是在我们前进时将视觉部分组合在一起，这就是我期望的图形设计的 Scrum 政策。
至少对积压工作中的所有功能进行线框化是闻所未闻的吗？或者更明智的做法是——对于第一个冲刺——以这样一种方式设计它的功能，以便我们可以在进行时添加其他冲刺的新功能？ (即，当需要新功能时，讨论“这在哪些方面适合当前设计？”)
最佳答案
这是我建议您这样做的方式(即，我们如何尝试这样做)
Pre-sprint 0:确保你对你想做的事情有一个很好的愿景。不必非常详细，但不应该是“我们想建立一个社交网站”
冲刺 0 :开发人员工具 - 设置 CI 服务器，处理部署脚本等，所有基本框架都已完成。最后，您应该能够按下一个按钮(最坏的情况:在远程服务器上运行单个命令)，该按钮在您的源代码控制系统中获取代码，构建它，打包它，运行您想要的所有测试它，返返回告，如果可能，将其安装在测试服务器上(或至少导致您可以在测试服务器上安装的包)。
这个时候，设计师正在做线框图。他们的目标是为您认为需要的尽可能多的站点制作基本线框(考虑站点地图和流，而不是字段和像素)。然后，完成后，与 PM 一起制定最重要的内容，并详细讨论该问题 - 线框。还不是像素。
项目经理等正在与设计师和业务/利益相关者合作，为您编写故事和任务，让您有很多事情要做和跟踪。显然，他们需要了解站点地图等才能做到这一点。
这可能需要不止一个冲刺。从一个开始(我建议 2-3 周冲刺 - 1 太短，4 太长)，看看你还需要做多少等等。
所以在 sprint 0 结束时，你有:
那么你开始冲刺 1
请记住，在前 3-4 个 sprint 中，您不会知道在 sprint 中可以做多少工作，因此请注意错误!尽可能多地完成您认为可以完成的工作(按照业务/PM 的优先顺序)。您以后可以随时服用更多!
您开发这些页面，然后设计师将下一个页面块(由 PM 确定)线框图。也许设计师为那些页面做美工，所以你可以在下一个冲刺中做
所以，你正在开发你拥有的东西，而设计师正在为你的下一个冲刺开发东西。
当然，他们也可以进行 Scrum 过程，只是他们更早开始了冲刺!
现在重复，直到你没有工作
在冲刺期间，如果(例如)需求发生变化或添加了新内容，则会为此编写一个新故事，并将其安排到工作中。如果它是超高优先级，它可能会排在最前面，并成为下一个冲刺(通常是 1-2 周之后)的最重要项目。或者它可能很好，所以它在底部 - 业务决定。
PM/设计师需要知道他们可以改变事物，但改变确实会产生后果，因此来回改变和改变不符合他们的(财务)利益。但是需求确实会发生变化，XP 和 Scrum 比瀑布更能解决这个问题。
不要忘记:
你的 PM 应该能够预测项目何时结束——看看你在上一个冲刺中做了多少工作(你的速度)，然后用剩下的工作量除以这个数字，你就得到了冲刺的数量。简单。
哦，并阅读故事点 - 不要以小时或天为单位估计故事。使用积分。要引导它，只需将您估计的第一个故事(例如)设为 8(序列为 1,2,3,5,8,13,21,40,60,100,infinite)。然后取第二个故事，并相对于第一个故事进行估计 - 它是工作(13)的两倍吗？一半的工作(5)？大致相同(8)？
在冲刺结束时，把你做了多少分加起来，这就是你的速度。您可以 promise 在下一个冲刺中完成的最大工作量就是这个数量。你总是可以提前停止冲刺，或者如果你提前用完，就可以从积压工作中提取更多的工作。随着你的前进，你的速度会稳定下来。
该死，我确定有关于如何运行它的书籍等，所以我会停下来:)
关于scrum - 您如何将 Scrum 应用于 Web 开发的设计部分？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/658836/