设计思维和敏捷的区别与联系

设计思维

设计思维是将设计与所有特定工具集（工业设计、架构设计、平面设计）解耦后，认识到这一过程可以应用于任何的问题上。

设计思维也作为人本设计的同义词；这种联系的建立很大程度上要归功于上世纪80年代末90年代初斯坦福大学和IDEO内部人员的工作。在此背景下，设计是一个周期性过程，用以明确未来的状态，并向后连接到当前的状态（这就是“逆向工程”和“后合理化”这样的术语常见于设计中的原因）。

在可行性、愿望和获利点之间来回跳跃，就是设计的本质。我在这里故意用“跳跃”这个词，是因为无论我们用了多少个三向维恩图、弯曲线条或其他比喻来描述，设计本质上是一个模糊的过程，在此过程中，只有经过向前跳跃（原型设计、头脑风暴、草图概述），随之向后跳跃（综合、故事讲述、汇报），才能形成共识、树立信心。

敏捷

敏捷方法是开发软件的一种方法，它的特性由软件本身决定。对许多人来说，它是瀑布式开发（或称为工程）的补救之术。瀑布/工程过程完全可以适用于硬件的生产，但就软件而言，这个方法可谓是完全错误的。

对于硬件，越接近生产环节，要进行更改的成本会越高；而对于软件，特别是对象明确的软件（上世纪70年代以来，基本所有软件都是如此），更改元素的成本相对较低。这一点因互联网连接的“永远在线”而进一步突显出来，即意味着如今的软件开发者能够随时向用户推送软件更新。

敏捷宣言中包含着持续的测试理念，还要求软件开发应该不断进行从输入用户需求到创造出“足够好”软件的循环过程。

这种不断改进的状态与设计的前后跳跃过程基本上是一样的。唯一的区别是，在设计中，我们是在项目期间都保持这种状态，而在敏捷中，我们将在软件的整个生命周期中维持这种状态。

精益

精益和精益创业这两者的区别也值得讨论。

精益以敏捷为基础。

敏捷提高了团队的自主能力，创造持续的工作过程，而精益则进一步强调了效率（减少浪费、快速行动、大局意识）。同样的，这些也都是设计团队所熟悉的概念，从而导致精益与设计思维之间的模糊。

精益创业采用这种方法，将其应用到公司建设中。这就是所谓的构建/估量/领会循环的来源，本质上，精益创业借用了软件开发的规范模式，应用在商业领域。其成效的确很好，因为：所有的新业务都是软件业务。此外软件工具越来越大众化。这自然就意味着设计师也可以使用那些从前只有软件工程师才能使用的工具——也就意味着软件人员、设计人员和业务人员都在使用相同的工具。

因此，要来回答最初的问题：IDEO如何区分设计思维过程与敏捷方法？

相似之处（设计思维与敏捷之间）

1. 这两者都从执行工作的团队之外寻求可投入的地方。对于设计师来说是用户研究、业务需求和技术可能性。对于软件开发来说，则更多像是需求列表、用户故事和成功指标。
2. 这两者也都包含迭代方法和持续改进。我个人认为，设计更多的是前后的来回跳跃，而软件是连续循环的开发过程——但两者探讨的都是持续改进的理念。
3. 此外有一个虽不甚明显，但也同等重要的相似之处是：两者都强烈呼吁在团队中培养富有同理心和激励自主的健康文化。可以看到，敏捷宣言的价值观与IDEO的价值观惊人地相似：

敏捷：“方法工具不如人才交流”

IDEO：“成事在人”

敏捷：“周全文件不如实用软件”

IDEO：“少说多做”

敏捷：“合同谈判不如客户协作”

IDEO ：“协作”

敏捷：“遵循计划不如应对变故”

IDEO ：“拥抱模棱/失败为师”

不同之处

1. 软件开发一般没有“综合”阶段。通常，从上一次迭代中得到的经验教训是下一次迭代的直接来源。收集需求是常见的前期准备，随后在工作开始之前，最好先确定需求的优先级列表。设计思维则更善于吸取经验，随后发掘出能够胸有成竹地完成向新事物飞跃的工作模式。这个不可思议的综合过程或许比我们想象的更专属于IDEO。
2. 设计思维有一个“后遗症”，即我们仍然会习惯性从项目的开始、中间和结尾来考虑问题。敏捷当然也有这些阶段关卡（alpha阶段、beta阶段、发行阶段），但是设计过程可能更需要这些节点来强制达成输出的一致性，而软件开发会更善于在任意时间点部署解决方案。
3. 也许最有趣的区别在于设计与软件的相离性。在日常活动中，我们使用软件，而当要完成工作，我们的工具范围比之要广泛得多，从简单的东西（如笔和纸）到更复杂的工具（如商业模型图），我认为我们拥有的工具集比软件组要大得多。

模糊地带

1. 正如我前面所说的，之所以造成模糊，最有可能是因为在敏捷和设计思维的所有阶段都使用了软件。不仅是我们在同一品牌的笔记本电脑上使用相同的软件，非技术人员执行软件工程任务也越来越容易。比如，桌面排版软件让每个人都可以做平面设计师的工作，软件架构也使得如今的设计师也能够开发出非常高级的软件。类似于谷歌推出的设计语言Material design的设计模式和语言库能帮助开发人员生成高级的可视化界面。在某些情况下，高分辨率原型与可生产代码之间的差别基本为零。如果我用来进行构建的是可扩展的云工具（如亚马逊云计算服务平台AWS），那就没有什么能阻止我的用户规模从10个扩展到10000个。（除了我的银行存款）
2. 另一个因素是团队的越发多样化。在IDEO，我们自然高度重视这一点，但随着越来越多的以设计为基础的公司成立（如爱彼迎），我们通常会发现有的设计团队中有软件工程师，或有的软件团队中有人种学家。当各种各样的团队将他们的过程结合在一起，模糊的产生便在所难免。
3. 最后，上面这些技术的快速运转，也让一切看起来非常模糊。亚马逊目前约每10秒部署1次代码，也就是说你在读这段文字的时候，代码已经更改过60次了。试想，如果10分钟内，福特对某款汽车做了60次更新（事实上，特斯拉已经在这么做了——所以还是想象他们吧）。当这一点成为我们所研究材料的一个基本特征时，事物间的界限就会变得模糊。”

原文作者：Matt Cooper-Wright

翻        译：吴晓君