前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >中国台湾精益老专家:什么是敏捷开发容易被遗忘的事

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

作者头像
DevOps时代
发布2018-12-18 16:41:40
9010
发布2018-12-18 16:41:40
举报

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

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

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

在早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 在描述各个敏捷方法的规范数时所画的图示。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-11-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 DevOps时代 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档