尽管在这个话题上已经合作出版了获奖图书，讲授和辅导也近10 年，但我仍然会遇到很多问题——主要来自产品经理、高层领导和技术经理——关于如何将提升交互设计集成到Scrum敏捷流程中。
这是一个持续困扰大多数组织的挑战，主要是因为引入Scrum敏捷的不是为了做更多深思熟虑、以客户为中心的工作，而是为了更快地发布更多代码。
我自己亲身和克服了这个挑战的团队合作过。那些经历被记录在我的文章、书籍和课堂中。近期我和合著者以及敏捷开发社区的聪明进步分子一起愉快工作。我们一起搭建了一个框架，逐步阐述如何将Scrum敏捷开发和交互设计集成。我们单独进行的一项练习是在一个精心设计的敏捷开发模型上附加提升用户体验和设计活动。下图是我对这项练习的尝试。
在您查看时，请注意一下警告：
这绝不是全面的交互设计活动列表。世界上没有那么多便利贴来涵盖这些内容。
我使用“设计”这个词（首字母D通常大写）作为设计师通常参与的所有活动的总称。
我对探究“设计”、“用户体验”等定义的无限深度并不是很感兴趣。请为其他主题保留该会话。
您有兴趣了解更多？
接下来我们将为整个团队提供汇集了敏捷式开发和交互设计的课程。
我为每一组用户体验编了号，以下是对每个分组的简要说明和分组理由。
产品积压包含了当前冲刺中无法处理的更广泛愿景的部分，存在高水平项目、愿景和许多假设。为了通告产品积压，设计冲刺、研究（定性、所有类型）和假设写作等活动有助于为这些项目注入真实情况和客户中心焦点。
冲刺计划是团队日常水平的工作计划。诸如“它会是什么样子？”、“产品如何从一个屏幕到另一个屏幕？”、“我们需要处理什么例外情况？”等问题，可以通过设计类似“协作草图”（又叫“设计工具”、“设计方案审核法”等）的工具或者交互设计师特别擅长促进的和其他组织的头脑风暴活动来回答。
战术设计工作（大写字母Ｄ作为产品设计各个方面总称）必须进入战术挤压——冲刺挤压，主要由设计师执行，同时也和敏捷开发团队的其他成员合作。关键是要以允许所有团队并行工作的方式确定这项工作的优先顺序。
核心敏捷式开发团队以及整合用户体验设计任务中必需但严重缺失的是团队的全职设计师。上一条策略中能和开发人员、产品经理和敏捷开发管理员实现并行合作的唯一方法是团队中有一名全职设计师。
冲刺审查是一起作为团队成员审视团队在冲刺期间产出的机会，也是一个回顾在冲刺（也就是产出）期间所学东西的机会。设计检验、讨论以及研究综合和定量分析的辩论等活动为我们在考虑推动的工作提供了信息，并帮助我们聚焦下一轮产品和冲刺积压的优先级。
特别需要指出的是，如果没有专门指派给敏捷开发团队的设计师，这一切都不会发生。他们的存在确保了相关活动的提出、优先权授予和执行。
如果将设计工作外包给团队以外的设计师（无论该设计师是否是内部成员），那么团队会发现自己又回到了“预先大量设计”的工作方式，也被称为瀑布式或“向前冲刺”方法——这些都会削减团队成员之间的合作、相互理解和信任。
你怎么看呢？哪些我说对了？哪些我又错漏了？你会或者已经以哪种不同的方式完成它？
我很想知道。
原文链接：看交互设计如何集成到Scrum敏捷流程中
敏捷管理延伸阅读：
300+精品课程，为你的求职、学习持续赋能。 热门课程推荐：
更多精彩案例与方案可以访问Runwise创新社区。我们为你准备了4大精选内容：
1.前瞻方案研究 2. 最新实践案例 3. 科学思维方法 4. 创新技术工具
标签：Scrum,冲刺,敏捷,设计,设计师,团队,交互 来源： https://www.cnblogs.com/runwisedigital/p/16561869.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。