写点什么

敏捷背后

  • 2009-08-14
  • 本文字数:2154 字

    阅读完需:约 7 分钟

山雨欲来

作为一个组织,当我们一年前首次邂逅 Scrum,第一感觉就相信它是管理层所期望做到的领域之一,因为对于工程方面运作方式的改变势在必行。那时,感觉减缩开支并不是非“敏捷”不可,可能只要些不一样的做法,而且这种方式也必然经历了当时“彻底的改革之风”潮流的洗礼。

改革之风

一年飞逝,我们公司从经历的改变中获益匪浅,这一切要归功于我们新上任的分管工程的副总裁,是他给我们和 Scrum 牵了线,搭了桥。有了这一扎实的根基,我们可以来吹捧些好处了(看,我也能说得很草根!):

  • 能更好地对不断变化的市场和投资者们的市场要求做出回应——特别是当我们正处在金融海啸中。
  • 能尽早遇到困难 ——我们对此感激不尽,因为不管你遵循什么过程都会有苦难 ,对我们每个人来说,越早经历越好。
  • 有优先级、有重点的执行(一段时间内)。问任何经理那是否值得,十有八九会以“除非发生了变化,计划就是计划” 这句引言做回答。陈述本身并没有错,但把责任和职责一起交到产品所有人手里是在我们组织有过的最棒的事。
  • 自我管理团队:怎样理解主动承担责任这种方式比要求团队做出承诺并坚守它好呢?

一年前,我们团队中也不是完全没有这些;只是当初很多都错过了,而现在每个团队都能做到所有这些。为了避免这篇文章落入宣扬敏捷益处的套路,我想快点言归正传——毕竟如果撇开已有的敏捷转变的结果不谈的话,已经有很多有资历的专家在谈那点了。

面纱背后

我想要写下这些并非由于我看到了团队中那些可见的变化,而是来自一些无形的东西。转变的面纱背后,可以这么说,人际关系中感观价值上的改变,更强调信任的必要性,解决多地点交流不够高效的迫切需求等,这些都是我想要一探究竟的。过去一年,在我点击和转发的数以千计的链接中,在那些你能想到的任何类型和格式的共享文档中,还不到5%(或二十分之一)能触及到这个话题,我渐渐发现它是我们转变中的一个副产品。面对信息海洋,我不记得从哪儿找到这个,但从去年我就深深地记住了这个引用——“实事求是是敏捷的基础”。一个同事后来推荐给我一个链接,能够更好地解释这一点

这并不意味着我所有的同事和朋友们以前都不诚实,而一夜之间就改邪归正;恰恰相反,事实上,在职业生涯中我还没遇到过有足够的证据说谁故意不诚实的。其实,依我的拙见,当需要一个人完全诚实的时候,环境会造就或破坏一个人对此的反应。此前我天真地以为——不诚实,是非此即彼的;在某段时间内,你只能是道德高尚的或者道德败坏的,诚实的抑或不诚实的。有些不符合社会道德准侧的杂念也许会在我们的记忆中逐渐消失,就像我们人类倾向于仅仅记住快乐的事情一样。

言归正传,我提到的诚实和真实是抽象概念,是我们对自己以及身边人的发自内心的承诺。举个简单例子,如果在几年前我还是一名架构师的时候,有人要求我给新任务做一个粗略估算,我会毫不犹豫。然而现在,我会考虑再三。但现在除了我的工程估算能力有所改进,什么都没改变;另外层意思就是我会根据“我是否真的确定,我的承诺能代表整个团队?”来做出判断。当我看到一个团队成员在竭尽所能地兑现团队的共同承诺时,我会想要去停止一切的讨价还价,我不想做出一个他/她不能兑现的承诺。如果你仔细看,界线模糊了,角色被合并了——懂得协作的团队将走到最后!在敏捷转变之前,我们可能已经对周围的人做了个承诺,但是由于各种外界原因,那些最紧迫的活动的范围并没有立即去做,随后又不得不去面对由此引发的一系列反应。有了敏捷和Scrum,由于一切困难都与我们正面遭遇,由于我们想要成为群体中的一部分(羊群心理?),我们会想要自觉地做出一个承诺 ——一个我们能够兑现的,不被周围人孤立的约定。

运用到日常生活中去

想象一下,如果在你的生活圈中,每个人都坦承说出自己的承诺,并对此供认不讳,老实说,这会给其他人施加一种“同辈压力”,逼迫他们也去实现自己的承诺。我有个信心十足的想法,在我们的影响范围之内,我们能够控制我们的命运——这意味着对我们自己的承诺不应该有借口。我读过的某篇文章说,鉴于我们把大量的时间用在了工作上,我们的个人生活只是我们工作的衍生。限于我使用Google 或其他搜索引擎的能力,我没能推荐一篇关于怎样把在工作中采用的敏捷开发方法论转化到运用到工作以外的生活中,从而让生活更有质量的文章。但可以考虑一下这个想法,如果我们在工作之外,个人生活中,采纳了相同的原则,那会是给我们孩子不错的一课吗?在当今社会,已经不能像记忆中那样单靠一件事情就能名垂青史,这与几个世纪前的战争年代,很有可能一夜成名有所不同。今天我们能留下的不再是英勇的行为或事迹,而实际上是一个人职业生涯所做的并能够持续影响未来二、三十年的那些贡献。

如果这意味着一个人职业生涯的转变能够直接给社会带来正面影响,这就很值得庆祝了。如果我们有机会在我们的生活中来做个榜样,并因此史上留名(小范围地),这得感谢背后的敏捷,对此,我很赞同——我的朋友们,关键就是背后的敏捷。

是的,敏捷有一个方面还没有在我们的日常生活中得到运用——“生活是一场马拉松,不是冲刺。”!!

查看英文原文: The Hidden Face of Agile

感谢张晓庆对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2009-08-14 00:112691
用户头像

发布了 114 篇内容, 共 33.9 次阅读, 收获喜欢 2 次。

关注

评论

发布
暂无评论
发现更多内容

打破底层技术瓶颈,RTC技术或成为物联网市场的强劲引擎

擎声科技

物联网 RTC sdk 实时音视频 擎声Qtt

微服务的拆分与设计原则

阿泽🧸

微服务 8月月更

开源一夏 | Node.js实战对于Buffer和Stream模块系统的深入剖析

恒山其若陋兮

开源 8月月更

Kubernetes 云原生日志构建

CTO技术共享

开源 签约计划第三季 8月月更

自媒体代运营为何被诟病,代运营的水有多深

石头IT视角

文件管理-Linux系统压缩打包

Albert Edison

Linux centos 文件管理 tar命令 8月月更

新书上市 | 连载 5 年,千万读者追更,这本书讲透了通信背后的故事!

图灵教育

5 分钟温故知新 RxJS 【转换操作符】

掘金安东尼

前端 函数式编程 8月月更

leetcode 303. Range Sum Query - Immutable 区域和检索 - 数组不可变(简单)

okokabcd

LeetCode 算法与数据结构

HPC、AI与云计算:当智能时代三叉戟在亚马逊云科技完美融合

脑极体

头脑风暴:最长递增子序列

HelloWorld杰少

算法 LeetCode 数据结构, 8月月更

RocketMQ高可用设计之故障规避机制

急需上岸的小谢

8月月更

Kubernetes Kruise Rollout

CTO技术共享

开源 签约计划第三季 8月月更

【源码解析】MyBatis结果集映射和参数绑定

小明Java问道之路

源码解析 mybatis源码 mybaits 深度 8月月更

C++继承中的多继承语法与菱形继承

CtrlX

c c++ 面向对象 继承 8月月更

IPv6邻居发现协议详解

穿过生命散发芬芳

NDP 8月月更

C语言基本的窗口开发

计算机魔术师

8月月更

ABAP工作进程对数据库表读取操作的检测

汪子熙

数据库 SAP abap Netweaver 8月月更

关于 SAP ABAP 字符变量和字符串变量字符个数的一个知识点

汪子熙

字符串 SAP abap Netweaver 8月月更

【Django | 开发】面试招聘信息网站(快速搭建核心需求)

计算机魔术师

8月月更

深度学习公式推导(3):初探神经网络

老崔说架构

百炼成钢 —— 声网实时网络的自动运维丨Dev for Dev 专栏

声网

Dev for Dev 自动运维

【React源码系列】React Context原理,为什么我建议尽可能少的使用React Redux管理状态 审核中

爱切图的木子老师

react源码 react context react redux

【精通内核】汇编下的C语言

小明Java问道之路

指针 C语言 结构体 汇编语言 8月月更

【精通内核】深入理解汇编语言

小明Java问道之路

指令集 寄存器 汇编语言 8月月更 机器语言

Kubernetes 重大更改和删除

CTO技术共享

开源 签约计划第三季 8月月更

我眼中的无影云桌面‖云桌面使用者角度

乌龟哥哥

8月月更

RocksDB在大规模分布式系统应用中的经验

CnosDB

时序数据库 开源社区 CnosDB 工程师有话说 CnosDB Tech Talk

把充电宝拆了看看

Sher10ck

拆解 充电宝

[极致用户体验] 网页里的「返回」应该用 history.back 还是 push ?

HullQin

CSS JavaScript html 前端 8月月更

每日一R「09」类型系统(三)

Samson

8月月更 ​Rust

敏捷背后_研发效能_Mukund Srinivasan_InfoQ精选文章