3.1 敏捷与设计矛盾吗

3.1 敏捷与设计矛盾吗

设计师注意到的关于敏捷的第一件事情通常是它没有设计阶段。敏捷项目一头扎入开发中,对设计师所信仰的设计是产品开发过程的重要组成部分这一理论完全不给面子。设计师所看到的是许多短得荒唐的最后期限,在这些期限上要交付可工作的软件,并且不对重要的设计活动的工作量和复杂性做任何考虑。结果,许多设计师相信设计会受到严重损害,于是直接就对此很排斥了。

敏捷公开宣称,它反对大量的前期设计,这听起来像是对设计的批评。这样的立场会让对敏捷不太了解的设计师感到不舒服。

让我们加入一些上下文,应用一些观点,并且揭示“敏捷中没有设计空间”这一流言的真相。

争论中大部分都与软件的前期设计有关,所以我们将首先快速了解一下这方面内容,然后探究如何将这些论点用在体验设计上。

3.1.1 软件开发中的设计

我们已经知道,敏捷是由于对软件项目交付方式的不满意而产生的。敏捷离开了离散的、顺序的、功能特定的方法,而采用跨功能的协作和并行工作方式。另一项基本改变是不再在实现任何价值之前将每件事都做得很彻底,包括设计在内。它的思想是只做刚刚好的工作,然后随着了解深入而精益。

这意味着传统上总是事先完成达到第n个程度的系统架构设计,是最先进行根本改变的内容之一。 Martin Fowler在“设计死亡了吗?”白皮书中探究了“经过计划的设计”过程这个通常在建筑设计中遵循的做法,并且将其与软件架构进行比较。建筑师将设计绘制出来,在他们做这件事的时候,他们考虑并解决建筑设计的问题。一旦设计完成,就会递交给按设计进行施工的工程人员与建设公司。这也是软件设计的通常做法。在软件构建之前,软件架构师花费可观的时间来定义一个系统,而后才将软件设计规格说明书递交给不同的团队或其他公司来构建,这会造成以下两个主要问题。

  • 难以解决在设计阶段完成之后出现的设计问题。由于不可能提前想到所有问题, 在后来的阶段中出现问题将不可避免,这时系统设计师已经转移到其他项目中工作了。
  • 软件架构师不再是开发人员。开发人员典型的职业生涯是从编写代码开始的。最终他们会毕业,成为软件架构师,然后就几乎不再写一行代码。考虑到软件开发技术的更新步伐,这就意味着软件架构师很快就会与开发方法脱节,在需要解决一些让开发人员焦头烂额的底层实现问题时不那么有效。

替代大量的前期设计的是演进式设计。一些死忠于这一方法(比如极限编程, XP)的人,相信大量的前期设计不应当存在。他们相信项目应当尽可能赶快开始编码,并且可以按需通过“重构”来解决设计问题。

3.1.2 体验设计的教训

这里的讨论强调在敏捷中对“设计”这个词的使用。在技术社区经常讨论并研究前期技术设计要多少才合适。那么,也可以对体验设计问一些相同的问题:

  • 与提前做所有的系统设计相比,提前做所有的体验设计是否更合理?尤其当我们知道并且接受这样一个事实:对建立良好体验产生影响的因素会改变。

  • 试着在产品发布之前让其完美,却延长了初始想法和业务开始得到投资回报的时间之间的间隔,这是否有意义?

答案是否定的。

如果认为体验设计是成功的关键,那么我们不认为项目应当从编码开始,就如我们不应该在建筑的概念得以探明之前就开始施工。

如果是这样,那么建筑工应当从哪个地方入手?砖头、砂浆还是基础结构?要是建筑师将建筑设计成玻璃与钢的结构或者使用圆柱形的形式又该如何?是否要把建筑工人已经完成的东西推倒,从草图重来?

仅创建刚刚好的前期设计做为开始,并且通过测试、学习和精益来完成设计细节是更为有效的工作方式。在前面所提及的那篇论文中,Martin Fowler以这样的建议来表达他对这一观点的赞同:

“为了让软件能工作,演进式设计需要有股能驱动其朝向某一个点会聚的力量。这股力量只能从人而来——团队中必须有人能做出决定,确保设计保持高质量”。

那么敏捷与反设计矛盾吗?它并不与设计相悖,而是反对任何浪费的或者不直接创造价值的东西。于是,我们不会在项目的早期阶段进行所有的设计活动,然后将输出结果扔给墙外的开发人员;而是要看看我们在哪些地方可以将浪费最小化、将价值最大化,并且不需要对设计的质量或者用户体验做出妥协。我们的做法是只做刚刚够建立设计愿景的思考,这个设计愿景可以测试与验证,而后以迭代的方式构建设计细节。

目录

相关技术