敏捷 (Agility)及敏捷方法——第三部分

在敏捷系列的第一及第二部分中,我们分别讲述了敏捷到底是什么以及究竟何时使用敏捷方法才有意义。

我们对敏捷在组织中的作用下了以下定义:“敏捷是一种让一个组织能够快速有效地适应不断变化的环境的能力。”如果一家经营中的公司从事与技术相关的业务,并且其相关技术会经常发生改变,那么敏捷工作方式及原则就能在此发挥重大意义。在这种情况下,许多传统的工作方法便会显得不实用,比如制定长期的项目计划、做出固定财务预算、确立固定目标以及既定的关键绩效指标。与之相反,如果使用一些具体体现我们在第二部分所介绍的敏捷原则的方法,便可以起到事半功倍的效果。

那么,这些所谓的敏捷方法叫什么呢?最出名的当然是设计思维(Design Thinking  针对创新的初期过程)和Scrum (针对创新的后期过程)。

设计思维是一个以用户为中心的创新行为。基于对用户及其需求的观察,一支跨学科的团队将根据他们的所见所感,研发出一套全新的想法及解决方案。这些想法将会被很快地体现到范例中去,使用户得以及时体验。比如,设计思维的一个典型例子是,设计一款新型的家居产品或者对一家大型购物中心的购物体验进行改进。

Scrum是开发复杂产品(多数为软件)的一个程序设计,在其开发过程中会经常出现变化。Scrum最初出现在软件开发行业,但今天也被越来越多地应用在非软件产品领域。一支Scrum团队由三个固定的角色组成(产品主管、Scrum主管以及研发团队),他们以所谓的冲刺作为形式,来完成一个可输入的产品元素。大致可以这样说,与设计思维相比,Scrum要更强调模式化。在Scrum中,所谓的冲刺设定了固定的角色以及固定的时间(最多四星期)。但一次设计思维的具体时间,取决于问题提出的方式。我们creaffective有过和客户合作几天的经验,但也有项目会持续数周或者数月。

这两种方式都是敏捷原则具体应用的实例,并且互相补充。设计思维是初次为不明确的问题找出可能的答案,而Scrum更旨在实施一个已被认定的可能的解决方案。所以,设计思维被用于创新过程的前半部 (首先必须找到有可能的解决方案,然后再多方考量),而Scrum用在之后,在这里将试着使用解决方案。

这两个方法都作用于敏捷原则及元素的基础之上。

三个例子:

Reviews/ Feedbacks  审核会议

在短时间定期间隔后,我们将开展一次针对内容结果方面的回顾(在Scrum中),或者请客户进行一次反馈(在设计思维中)。目的在于,尽可能快地为下一步做好预习并从客户的反馈中做出及时调整。通过这种方式,就能够使解决方案更大程度地吻合客户的需求。在开创方案的过程中,我们会多次进行反馈并会对工作内容进行多次修正。

Retrospektiven (回顾)

除了内容上的回顾,这两种工作方法也会逐渐完善团队的协同合作,从而让团队能够更有效地开展工作。藏在背后的思维方式是,自我反馈不是浪费时间(很可惜在很多公司中被认为是这样),而是更有效地工作。在此,也会定期召开所谓的回顾会议,以加强团队及团队合作建设,从而达到检测标准。

失败快,失败也便宜

 譬如,设计思维的一个目标就是很快很简单地提出解决方案的范例。这些范例是非常简单并基础的,他们只会呈现出解决方案的作用原理或者直观外表。这样做的目的在于,获取一些可以用来和用户或者客户直接对话的实例,以便得到他们的反馈。

在此过程中,人们会有意识地借助简单的工具快速地来完成范例。这背后的考虑就是,之后总归会做出调整。这样,在之前只耗用了少量的时间和能量的前提下,以后就更容易调整。“错误”的成本在此也会明显降低,因为我们可以更快地从反馈中学到新东西并努力适应改变。

重要的是要理解,既不可以把Scrum也不可以把设计思维与敏捷混为一谈。这两个都是抽象的敏捷原则在一个具体的情况下的具体应用方法。至于这些具体的方法是否适用于某家公司,只能由该公司自己来做决定。当然也有其他能体现出敏捷原则具体的方法。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*

(Deutsch) Social Media
(Deutsch) Folgen Sie uns auf Facebook, Twitter oder XING. Wir veröffentlichen zudem regelmäßig auf Medium.com.