将Scrum调整到UX模型 （Adapting Scrum to a UX Model）
中心思想：当两个来自不同地方的团队共同运作一个项目时，如何将 Scrum 引入团队中去，并推动项目向好的方向进展。
将Scrum调整到UX模型 （Adapting Scrum to a UX Model）
全文共计：2761字 预计阅读时长：15分钟
原文链接：https://www.uxmatters.com/mt/archives/2014/07/adapting-scrum-to-a-ux-model.php
——（搬运工注释：Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法——百度百科 有兴趣的可以百度一下，Scrum的方法挺有意思的）
正文（再次感谢伟大的谷歌，可以让一个英语渣渣查找阅读国外文献资料）
敏捷方法论 - 更具体地说Scrum--是一种日益流行的方法，可以在保持灵活性的同时提高软件开发速度。当整个团队搭配在一起时，Scrum运作良好。团队成员在每日Scrum会议期间进行实时通信。但是，假设一个团队的一部分从不同的位置以不同的角色运作。声音具有挑战性 在本文中，我将通过探索开发团队在Scrum项目上与单独UX团队合作时遇到的挑战，尝试回答关于用户体验和Scrum的一些常见问题。我还会为作为Scrum团队成员的UX团队提供建议。
虽然本文中的信息反映了我与客户合作的经历，但保密性阻碍了我讨论具体情况，因此我将介绍基于我在工作中遇到的一些具有挑战性情况的场景。这个场景类似于一个非常成功的项目中的实际情况，UX项目团队并未与Scrum团队的其他成员共同工作。我希望这篇文章对于从事Scrum项目的UX专业人员和软件开发人员都有用。
情景
在这种情况下，来自两个不同位置的Scrum项目有两个团队一起工作：一个开发团队和一个UX团队。根据商定的计划，开发团队依赖UX团队制作线框，设计合成材料和图形设计资产，否则他们无法开始开发。为了让事情变得更有挑战性一点，让我们假设UX团队是做一个第三方供应商不通常遵循Scrum的方法作为其日常的一天交付模式的一部分。但是，他们必须为此参与。
遵循Scrum的基础知识
遵循Scrum原则和实践是Scrum团队在行动中发挥作用的原因。例如，一个团队必须遵循本书的Scrum角色和流程。每个Scrum团队由产品负责人，Scrum Master，Scrum团队成员和业务系统分析师组成，他们可以作为替代产品负责人并定期与Scrum团队合作。团队参加预定的sprint会议并致力于设计，编码和测试可交付物的共同目标 - 无论是新功能还是错误修复。在每次冲刺会议期间，团队都会处理产品积压，冲刺积压和枯竭图表。
在这种情况下，一个单独的UX团队没有将 Scrum作为其交付模式的一部分，这对团队实现Scrum的好处提出了严峻的挑战。例如，一个项目可能会遇到可交付成果流失，由于日程安排未对齐而被延迟，由于审批流程缓慢而受阻，或遇到通讯故障
（搬运工注释：
Scrum基本术语——
角色
产品负责人 Product Owner： 负责维护产品订单的人，代表利益相关者的利益。
Scrum主管 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的 收益最大化。一般不翻译。
开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。
工件
产品列表 Product Backlog：根据用户价值进行优先级排序的高层需求。
冲刺订单 Sprint Backlog：要在冲刺中完成的任务的清单。
产品增量 Increment：最终交付给客户的内容
活动
计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队 进行估算的计划会议。
每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站 立进行而得名。
评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。
反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。
其他
冲刺 Sprint: 一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所承诺的 一 组订单项的开发。）
在Scrum团队成功工作的提示
那么，在这种情况下，UX专业人员如何能够成功？团队使用Scrum方法来使他们在与独立或外部UX团队合作时取得成功的关键调整是什么？以下是缓解与单独的UX和开发团队共同工作相关的挑战和风险的一些建议。
以流畅的方式进行规划，并将UX团队带到Scrum
整个Scrum团队（包括开发团队和UX团队）都需要遵循相同的原则，使用相同的语言，并使用相同的术语。在项目开始时向所有UX团队成员提供Scrum的基本概述。
UX团队的交付成果（例如线框和可视化设计资产）至少提前两次冲刺，以便将UX团队的时间表与开发团队的冲刺计划保持一致。
此更改将允许产品负责人有足够的时间仔细查看UX团队的可交付成果，并捕获系统限制和不需要的定制区域等问题。提前或在第一次冲刺期间完成技术审查。
让开发人员参与UX可交付成果的审查。产品所有者不是开发人员。所以他们可能很难理解技术能力。我建议让审查周期中的开发人员参与，以帮助减少在冲刺期间进行重大设计更改的可能性，这可能会危及您的目标日期并降低开发速度。
使用第二个sprint来修改设计交付物并获得利益相关者的批准。
在第二次冲刺期间，UX团队应根据他们从产品负责人和开发人员收到的反馈，花时间对线框和可视化设计资产进行必要的更新。但是利益相关方的批准呢？使用此Sprint窗口获取利益相关方的批准。通过分配签收时间，产品负责人可以确保开发团队实施的所有用户体验设计的全部业务支持。Sprint计划应该期望并允许业务利益相关者在稍后看到演示时请求对UX设计进行调整，但这种早期审查和签署可以防止在开发过程中对项目进行全面改造或大量更改。
留出时间进行规划。
UX团队在有时间为每个项目规划和分配最合适的设计人员时更为高效。因此，请确保UX团队主管或经理有机会尽早表达疑虑，并对即将开展的工作有全面的了解。务必提供项目管道的清晰视图，就UX交付日期达成一致，并向UX团队提供指导，而不是详细的业务需求文档（BRD）。你需要给UX团队空间创造力。产品负责人应与UX团队负责人或经理密切合作，传达项目愿景，并可通过分享与少数复杂模块相关的示例以及将团队引荐给具有类似功能的网站或应用程序来帮助您。
促进UX团队和开发团队之间的沟通。
请记住，UX团队和开发团队并不坐在一起。因此，正式的反馈意见使得轻松传达任何微小的返工或表面变化的需求。要求产品负责人扩大其角色并承担促进UX团队和开发团队之间沟通的责任。选择具有较强沟通能力的产品负责人; 谁理解线框，视觉设计和技术发展; 并且有能力回答UX团队提出的问题。产品负责人应充当UX团队和开发团队之间的桥梁。
使用协作工具来促进Scrum团队的工作。
产品负责人应该利用各种工具来简化团队合作。敏捷工具非常适合帮助开发团队组织冲刺，维护产品积压和报告进度。产品负责人必须鼓励团队使用基于电子表格的反馈表单，敏捷工具（如Jira）和文件共享网络。使用文件共享工具非常重要。可能会有大量UX构件，如线框和可视化设计资产。将它们作为电子邮件附件进行交换会堵塞人们的收件箱并造成混淆 - 特别是随着版本数量的增加。当文件被埋入人们的收件箱时，很难找到它们。Dropbox，Google Drive，Google Docs和OneDrive等工具也解决了电子邮件系统文件大小限制的问题。产品负责人必须利用Confluence或SharePoint等解决方案来维护严格的版本控制并提供归档机制。文件共享系统必须对整个团队开放，使UX和开发团队成员能够上传和下载文件。当团队成员上传文件的新版本时，必须将旧版本的文件移至归档文件夹。
尽可能沟通面对面。
直接面对面沟通总是有帮助的，可以更好地洞察用户体验设计，并减少沟通不畅和需求缺口的可能性。但是，如果无法进行面对面沟通，产品负责人应该联系UX项目经理。电话会议和WebEx等协作系统提供了团队可以使用的替代方案。产品负责人必须让UX团队负责人或经理对任何变更请求进行循环，以便他或她可以在UX团队中管理工作负载。与UX团队负责人或经理一起工作时，产品负责人应计划额外的设计更新时间并填写最终交付日期以允许不可避免的中期冲刺更改请求。
将UX团队纳入功能演示和评论。
在根据特定功能的开发来分配开发时间时，开发团队在进行下一个功能之前没有时间进行更正或调整。邀请UX团队进行演示，以便他们可以直接听取利益相关方的反馈，并可以立即发现开发人员可以快速修复的小实施错误。通过在评论中加入UX团队，您可确保每个人都可以快速实现任何必要调整。
综上所述
在一个Scrum项目中，一个不遵循Scrum作为其交付模型一部分的UX团队对实现Scrum的好处提出了严峻的挑战。为了解决这个问题，开发团队的人员必须作为联系人，并定期与UX团队紧密合作，以调整两个团队的时间表，以及他们对可交付成果和要求的期望。这将确保UX设计工件的及时交付，更好地符合需求，以及在开发开始前向UX团队提供反馈的一致流程
