敏捷和UI设计

几天前，我的一个Twitter好友问我UI设计师如何融入敏捷团队。我曾与专门的设计团队和用户体验人员一起工作过，所以我想尝试一下他的问题并分享我的观点。一旦我完成我的笔记，它似乎是一个很好的博客帖子。我很想听听你们对我的答案有什么看法。

这里是……

我的朋友让我解释一下UI设计师在敏捷团队中的角色。他解释说，他们正在创建用户故事，但不确定如何将UI设计人员纳入这个过程。

关于解释敏捷的不幸之处在于，没有一种正确的做事方式。我希望团队能够运用一些原则。敏捷就是创造特定情境的策略。您只需采纳敏捷的原则，并在给定约束条件的情况下尽可能地应用它们。

也就是说. .我的朋友似乎找到了正确的方向。他们用典型的敏捷模式创建故事……“作为用户，我希望能够创建一个新帐户，这样我就可以做X”。我鼓励他应用的原则是，故事足够小，可以在一个sprint中完成，所有的学科都涉及到功能的实现(包括UI人员)，在sprint的最后，它可能是可发布的，换句话说，已经完成了。

这个理想在现实生活中是什么样的呢?在sprint计划会议期间，团队将围绕着白板进行协作，讨论创建新帐户意味着什么。开发人员可能会讨论需要创建哪些方法。QA工程师将讨论如何进行测试。UI设计师将帮助团队理解屏幕的外观。产品所有者将权衡业务价值，并保持对实现讨论的检查。亚博vip9通道

在讨论的最后，每个人都对如何构建功能达成了一致意见。因为每个人都在同一个页面上，UI人员可以开始迭代地制作模型(如果需要的话)，开发人员可以开始编写代码，也许QA人员可以开始进行测试计划。如果团队每天都在推新代码，也就是持续集成，换句话说，每个人都可以看到不断发展的产品并对其做出响应。

就像代码发展一样，文档发展，计划发展，产品发展。

来自专业设计师和QA人员的典型反应是，他们希望能够一劳永逸地完成工作。以这种方式操作感觉像是浪费。我鼓励我的朋友记住一些敏捷原则，比如仅仅提供足够的文档、简单的设计、将决定推迟到最后负责的时刻，以及不断地重构……关键是要把注意力放在工作产品上，而不是综合性的文档。

就像开发团队经常进行重构一样，支持团队成员也必须进行重构。

但是，如果每个人都不在同一个房间，在同一个团队中，甚至不在同一个公司(外部客户)中，该怎么办呢?您可以应用相同的原则，并使它们适应您的环境。我曾见过一些团队在前一个sprint中做了足够的UI设计，以确保开发团队在随后的sprint中继续前进....这使得事情变得更加复杂，并且比纯粹的敏捷方法产生更多的依赖关系。

当团队采用这种方法时，我将其比作产品负责人提前梳理待办事项列表并指定需求。UI模型对开发团队来说就像是一种需求。

作为一个团队，你只需要决定你想在前期设计上投入多少时间和精力。您可以使用预先设计进行敏捷实践，如果您想要更改任何内容，它只会导致您做更多的返工。这真的要看你们市场的不确定性了。如果事情有变化的倾向，那就减少预先投资。如果情况稳定，你可以投资更多。

图片来源:jaysmith.us / wp-content /上传/ 2008/06 / agile.jpg