台湾精益老专家:什么是敏捷开发容易被遗忘的事

Posted DevOps时代

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了台湾精益老专家:什么是敏捷开发容易被遗忘的事相关的知识,希望对你有一定的参考价值。


我们常常说到敏捷转型要由上往下才会成功,为什么呢?

敏捷开发没有教主管们如何敏捷起来才是主要原因

敏捷教练们经常用同一套教材在教团队与主管,但这样做对吗?是不是应该教导主管们如何来管理敏捷团队才对呢?! 其实有关这个问题。

在早2005 年时就已经有一群卓越的敏捷人士,发现了这样的需求,就已经在努力的起草有别于敏捷宣言,专门指向专案管理面的宣言。

目的是用来协助主管们跨过敏捷管理的门槛,就称之为相互依赖宣言(Declaration of Interdependence, DOI),用它来做为进行敏捷管理时的指导原则。你只要在 Google 搜寻画面下,输入”DOI agile” 就能找到下面的结果:

台湾精益老专家:什么是敏捷开发容易被遗忘的事

选择 PM Declaration of Interdependence:

就能看见了,它所强调的是” 虽然敏捷宣言已有涉及软件开发,但敏捷专案管理的《相互依赖声明》则更关注专案的管理领域”。

这个协会初期称为 Agile Project Leadership Network,APLN;后来又更名为 Agile Leadership Network, ALN(把Project 拿掉了),但由于未能引起专案经理人社群的青睐(注1),形成了这个一样是由一群卓越人士所推广的运动,却很少人知道而迟迟没有发挥应有的效应。

也就间接的造成了今天在实行敏捷化时专案经理人遇到问题时经常会有无所适从的局面。

这里就简单地描述一下它的六大宣言:

台湾精益老专家:什么是敏捷开发容易被遗忘的事

DOI 的六大宣言( APLN 并没有提供中文的版本,因此我自行翻译了一下,欢迎修正)。

每句的特色是目标放在前一句,后面的句子则是作法的描述。后面括号是我加上的主题.

起草 DOI 宣言的卓越人士:

David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki worked to see what management principles might be required in order to achieve an Agile Mindset in product and project management, In 2005.

我们常常说这是一个 VUCA 的时代(注2.),要寻找任何问题的解答,只要随意的 Google 一下,获得的讯息便会多到我们不知道要如何来取舍的情境,要如何来抉择呢?

恐怕只有依靠类似敏捷宣言这类核心原则才足以拿来协助我们过滤这些个庞大的资料讯息,因此许多新的理论就纷纷以原则的方式提供我们做为行动的准则,如著名的敏捷宣言是在2001年所订下的。

台湾精益老专家:什么是敏捷开发容易被遗忘的事

2001的敏捷宣言

啰嗦一下:

敏捷价值 Agile value

敏捷开发注重价值的交付,并不断询问有关范围的不同表现是否值得他们提供的价值的问题,因此才能拥抱变化。上面这二个宣言正是在说明这一点。

拿来对应到 DOI 的第一项原则「我们通过专注的持续产出价值流,来增加投资报酬率。」

大家可以参考 Ron Jeffries 所撰写的《软件开发本质论—追求简约、体现价值、逐步构建》一书中所提到:

敏捷即是以价值为导向,也说明了为什么我们要依照价值来排列需求开发的优先顺序的原因。

这是一本从头到尾都在强调如何务实地体现价值的书,浅显易读是敏捷主管的必读手册。

台湾精益老专家:什么是敏捷开发容易被遗忘的事

价值才是我们的开始,才是我们的工作重点。

简单来说,价值就是”我们想要的东西”

– Ron Jeffries.

※ 团队与任务

「如何管理自组织团队?」是现代的领导者所遭遇到的最大挑战之一,你经常要面对到的是应该选择以具体、明确的方式来交付任务呢? 还是要授权团队但不做具体说明如何来完成它,让团队自行去进行任务拆解的方式。

这二者的差异,正是所有的 Scrum Master 都会要求主管在遇到问题时,也就是所谓的:

主管要尽量的「后退一步」让团队透过讨论的方式来解决问题,其实就是希望主管能够,让团队多做自组织的抉择少下指导棋的意思。

许多时候主管会有所疑惑,当我退了那么多步之后又怎能帮的上团队呢?说来话长,其实这叫作「赋能」,要让团队知道你遇到这样的问题时会怎么作,当他们碰到时自然会依照你的思维方式去作,也就跟你在现场没二样了。

当然, 前题是要先做到「授权」, 否则他们也不敢去作。

敏捷领导者领导团队,非敏捷领导团队则负责管理任务。
Agile leaders lead teams, non-agile ones manage tasks.

– Jim Highsmith

--> 如果再将 OKR 的准则融入后(注3,便成了主管授权时的二个原则:

  1. 授权给团队去完成任务,但不做具体的执行说明。

  2. 为目标设定完成时的验证关键结果,并让团队能够明确知道是否做到了。


传统的专案经理总是专注于以最小的变化来遵循计划,而敏捷的领导者则专注于成功地适应那些不可避免的变化。

时时选择以将顾客的价值放在第一位的前提下,自然的将客户价值视为专案成功的主要目标。

正所谓的,当我们晓得为客户产生价值和质量为目标时,此时的「计划」本身就成为了实现这些目标的手段,而不是目标本身了。这便是所谓的敏捷了。

【补述】

《敏捷管理 : 主管需要学会行动学习 Action Learning 》

何谓「行动学习」?

行动学习(Action Learning)是一个团队在解决实际问题中边做边学的组织发展技术及流程。

– AACTP 美国培训认证协会

行动学习的目的

行动学习是为了解决管理者和人们所面临的真实的複杂性挑战和难题,同时它也是个人发展的源泉。此外,有一点是敏捷变革要成功的基础,那就是变革成功的前提是:

主管要先行改变自己」,依据不充分授权原则认为,除非我们可以改变自己,否则就不能改变周围的任何事情。

– Revans 2011



注1. 未能推广开来的原由是,未获得专案经理社群的青睐。

这里有较详尽的说明: 

http://itsadeliverything.com/declaration-of-interdependence

注2. VUCA (是这四个字的缩写,不稳定 Volatility,不确定 Uncertain,複杂 Complex 和 模糊 Ambiguous,雾卡 )


参考: 《原来你才是绊脚石》

注3. 实施 OKR 其实是极端敏捷的,它只有二个规范,就是设定目标,然后再设定如何验证它,下面这张图是借自《硝烟中的 Scrum 和 XP 》作者〔瑞典〕Henrik Kniberg 在描述各个敏捷方法的规范数时所画的图示。

以上是关于台湾精益老专家:什么是敏捷开发容易被遗忘的事的主要内容,如果未能解决你的问题,请参考以下文章

09.精益敏捷项目管理——敏捷软件开发中QA角色

即将关闭|德国认证专家-汽车的敏捷开发方法实施|牛喀学城

《精益—敏捷项目管理:实现企业级敏捷》-读书笔记60-第11章 精益—敏捷开发中管理者的角色-1

敏捷开发,让工作更高效!

敏捷小讲堂什么是敏捷开发

07.精益敏捷项目管理——敏捷发布计划