六年前，我是一家大型网络设计公司的技术总监，他们没能够成功应用Scrum。 当时管理当中存在相当多的障碍，尽管如此，富于创意的经理是最坚持的。起初，只是不想让架构企业软件的现实阻碍他们当时在做的图像处理 （Photoshop） 或平面设计 （Illustrator）的美好设计。自然，在开发阶段当这些人工产品与现存企业构架相碰撞的时候会有许多问题。 这种障碍导致了延期，高强度压力，低质量编码，以及每年40%的雇员流动率（和漂亮图表）。这家公司激励了我对于UX和敏捷的兴趣, 我也因此而找到做敏捷的基本方法。 迄今为止，在编程尤其是网站的所有修炼中，UX人是最坚持也最好的应用敏捷并投入实践。
以下是我如何与意愿做敏捷的用户界面设计师以及信息架构师工作的：
1. 产品backlog和它的优先级是所有工作的动力，所以，我们采取商业优先，而非用户界面优先。
2. 绘制最高水平的用户界面图。不可将就，只要最高级别的。
3. 看backlog，开始思考UI 1/2前方一个迭代需要什么样的团队。
4. 制作纸上原型（草图，纸上菜单，纸上按钮）来支持接下来下一个sprint的用户故事。不要用UX认为很酷的新特性来修饰。KISS。包括这方面的确认和其他接受标准。参考风格指导与要求一致。参考页码模板与要求一致。我叫这个是1页码设计规格。
5. 与PO,QA一起复审原型， 在sprint计划前几天带领开发人员，确保他们认为足够好并且具备可测试性。关于潜在的权衡性，需要做好记录。
5a. 检查设计文件， 区分各自的版本。
6. 和团队的其他人一起参与sprint计划。
7. 与团队一起执行，设计细节予以明确(规模, 位置, 行为等）。与QA一起进行新的UI 测试计划。帮助构建开发IDE中的用户界面 (HMTL/CSS/PHP等) ，连线时与开发人员一道。与质量保证一起进行测试并且施行自动UI测试。(Ruby/WATIR等)。
8. 重复每一个sprint
回顾，UI设计师在团队之前开始1/2 sprint，在UI事项方面协助产品负责人，输入sprint计划 开发出非常起边灵巧的原型。 Sprint方面剩下的工作完成了。我发现这种“刚刚好”有时间彻底考虑清除UI事项，而不必在远离团队的孤绝情况下找出解决方法。
其他的方法包括：
• 为团队设计一个风格向导，并让他们读读，听取他们的反馈并提高。
• 设计模板：不是每一页都是独特设计。 参考原型和设计规格里的那些模板。
• 在迭代的开始，打破用户界面/布局和业务规则之间的依赖性。在开始的时候一致通过数据/字段/控制，这样业务规则就可以显示为很简单的免费网页布局。
• 通过让用户进行一些操作，以及观察相应的反应来检查你的纸上原型。不必担心最终大的可用性测试，经常简略地与一些随和的人沟通，足够了解业务。
• 避免复杂高精确度的用户界面设计工具。这些真正会让你慢下来，并且过早终结你的决策。这些决定通常是错误的。
用户界面的不稳定性根源通常是由于客户需求细节知识的缺乏和技术限制。产品backlog和用户故事以及接受标准可能不是处于很好的状态。要消除这些差 异，UI人员必须去查清很多细节来进行设计，这些使得他们慢下来，同时导致sprint过程中的的很多设计变化。 就产品负责人而言，用户界面设计师可能需要弥补产品负责人知识和努力的不足。通过让产品负责人提高产品backlog来解决根本问题，这样设计师和团队可 以在sprint中有更好的用户故事和接受标准。用户界面工作仅仅是另外一种形式的软件需求，其他的还有软件架构，特性，测试计划。所有这些活动都可以通 过即时生产方式完成，产生出独家时尚，一致的架构以及可用的界面。今天许多人在做。尽管这样，这确实需要人们去改变他们的行为方式，而这似乎是最难的事 情。
原文地址：http://www.scrumalliance.org/articles/336-agile-user-interface-design-and-information-architecture-from-the-trenches
此文由scrum中文网翻译整理，转载请注明
