领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
让敏捷与“以用户为中心的设计”和谐共生
作者 Mike Bria 译者 郑柯 发布于 2010年3月19日
用户体验专家Anthony Colfelt使用一个案例告诉我们：仅有敏捷是不够的；他还深入指出：“以用户为中心的设计”（以下简称UCD）能够，而且应该与敏捷合并使用。
为了表明自己的观点，Colfelt首先提出：对于发掘业务的真正需求这个难题，敏捷是合适的解决之道吗？他以此引出自己的观点。
就其自身而言，敏捷在调整自己、适应变化方面做得很不错。但是我们必须知道：它能否用来治疗某些症状，这些症状的更深层次原因在于：业务不知道自己的真正需求。虽然敏捷能让开发团队更好地应对这个问题，但是并没有从根本上解决问题，很多时候还创建出了新的问题。
他从用户体验的角度出发，描述了自己所见过的、敏捷出现问题的6种“雷区”：
- 雷区之一：设计角色不清晰
敏捷原则说：“在整个项目过程中，业务人员和开发人员必须每天坐在一起。”这几乎没有为用户体验设计人员留出任何空间，常常让开发人员从事此类工作，而他们又很可能不具备相关技能。 - 雷区之二：没有定义需求收集过程。
敏捷团队的头脑中认为：“需求会像魔法一样从天而降”，从而不愿意花时间和精力制订产品的长远战略规划，认为这“不敏捷”；类似的情形并不少见。 - 雷区之三：走捷径的压力。
强迫用户体验设计过程使用与其对应开发工作所采取的迭代方式，这会导致冲动式设计（impulsive design），丧失与用户测试设计想法的机会。当然，敏捷允许测试真实的产出的可用性，但是要应对由此产生的反馈，所花的时间要超出人们的期望或是他们所能接受的范围。 - 雷区之四：称之为“足够好”的诱惑。
即使（也许应该说尤其）当敏捷表现出色的时候，团队总要面对排定优先级的需要，是“继续改进现有特性，让它们更好”，还是“向产品中继续添加新特性”？正如Cofelt观察到的：经常发生的是：继续改进的工作被放在一边，人们更喜欢令人兴奋的新东西。如此这般，我们构建出来的产品中，所有的特性都不能令人满意。
- 雷区之五：无风险的概念探索时间不足。
很多敏捷团队在项目的第一天（或是很接近的时间之内）就会开始着手实际工作。有些团队会使用“第零个迭代（iteration zero）”来做一些前期的规划和设计。Cofelt质疑时间是否充足：相对于在编码之前以粗略的方式验证某些想法，以可工作的范例来验证想法这种敏捷的方式是否总能胜出？ - 雷区之六：伤害品牌。
将未经（以用户体验设计的方式）实地测试的功能特性放到市场之中，即使是有意要这么做以收集反馈，也会让客户很快地丧失信心，不再相信你们公司能够不断达到目标；这会伤害你们的品牌，而品牌是很难建立起来的，一旦倒下，再想重树品牌就更难。
Colfelt做了一个有趣的总结，指出：敏捷本身“善于改进，但是不善于定义”。他强调指出：只用敏捷，也许足以“把现有产品提升至新的水平”；但是，特别是在要开始新东西的时候，“某些层面的规划是必要的，这样可以避免勉强拼凑各人对于最好的设计方案的看法，那样只能产生类似于弗兰肯斯坦式的怪物。”
他接下来描述了一种传统的、也是“典型的”UCD过程，要读者注意该过程中对于产品“战略”的前期研究（他在后面称之为“概念设计”，并举出完美的iPod设计作为典型例子），他强调指出：即使采取敏捷的方法论开发产品，前期研究同样重要。Colfelt的讲述方式很小心，没有说敏捷排斥这样的前期思考过程，而是提出：敏捷能够直接鼓励此类研究，以彰显敏捷之长处。
UCD的重点是“战略”和“概念”挖掘，它可以而且应该与敏捷的“改进”能力相结合；说到底，Colfelt就是希望提升人们对于这一点的认识。
总的来说，要想把二者结合在一起使用，就要避免对它们各自的武断态度。要记住：敏捷没有强制如何定义概念或是整体的设计方向，但是很善于执行具体的设计研究和良好的规划。UCD必须要很灵活，以应对如下现实状况：实现团队遇到问题，不得不强制采取另一种设计方案。文档只记录必要的信息，以便于传播。设计与开发团队应该尽量坐在一起，因为跨职能的协作和面对面的沟通至关重要。设计团队在开发团队之前先使用一个sprint也很有帮助，他们就能有足够的时间测试和迭代。如果遵循这些规则，两种方式就能和谐共存，发挥作用。
在做出任何强硬判断之前，不妨先花些时间读读Colfelt的全文。你不妨看看Johnny Holland这篇相关文章，其中提到用户体验设计人员在敏捷（Scrum）环境中如何调整自己的工作方式，他还讨论了与“战略”相关的类似主题，不过更关注与开发团队的交互，以及迭代层面的活动和团队动力相关内容。
查看英文原文： Harmonizing Agile with "User-Centered Design"
译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。
有道理，这个提醒来得非常及时
发表人
Wang Carl
发表于
更新，抱歉，上篇大错了几个字: 有道理，这个提醒来得非常及时
发表人
Wang Carl
发表于
Re: 更新，抱歉，上篇大错了几个字: 有道理，这个提醒来得非常及时
发表人
李 冬
发表于
敏捷是有条件的
发表人
q yan
发表于
Re: 敏捷是有条件的
发表人
李 冬
发表于
确实是一个补充
发表人
Jun Ran
发表于
-
经历了基本版本的“伪敏捷”，这个版本我在带着想着真敏捷的方向努力。这种在前期UCD方面投入的不足确实是让已经滚动起迭代的版本非常烦恼。
并非用户就能够给出界面涉及方案，用户只能做选择题，而被选方案，需要开发团队花时间、花精力、费心思才能给出。
而迭代过程中，“速食主义”非常流行。一切设计方案都有点像方便面，看起来解决问题，吃到嘴里没有嚼头，吞到肚子里，没有营养。
不错，缺乏定义，确认有经验的人、有才华的界面专家快速的给出定义。 -
经历了几个版本的“伪敏捷”，这个版本我在带着向着真敏捷的方向努力。
目前这种在前期UCD方面投入的不足的问题，确实是让已经滚动起迭代的版本非常烦恼。
并非用户就能够给出界面设计方案，用户只能做选择题，而被选方案，需要开发团队花时间、花精力、费心思才能给出。用户能够提供的是：哦，我感觉这个不太好。
目前迭代过程中，“速食主义”非常流行。一切设计方案都有点像方便面，看起来解决问题，吃到嘴里没有嚼头，吞到肚子里，没有营养。
不错，缺乏定义，确认有经验的人、有才华的界面专家快速的给出定义。
对于品牌的影响，的确会是这样，每个迭代产品都向用户正式发布，将会给一些高端用户留下不良印象，尤其是当你的软件升级给长痛苦的时候。 -
敏捷不是一群新手做出系统的葵花宝典，而是一群高手，经历过传统开发流程的人，精简了一些繁文缛节后的最佳实践。所以，做好敏捷，传统的技能是前提。
-
这个还是同意的 写葵花宝典的人是个高手 盲目练葵花宝典的人结局也都很惨。。囧
-
貌似标题还是大错了 呵呵
-
UCD解决的应该是这个问题：
如何很好地捕获并且挖掘出客户的需求，同时把这些需求设计成符合用户习惯的，让客户满意的UI。
而敏捷确实更加注重执行层面，它们应该可以成为互补的关系。
6 条回复
关注此讨论 回复