BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

那天,我成了多余的人(一)

| 作者 Claudio Kerber 关注 0 他的粉丝 ,译者 李竞 关注 0 他的粉丝 发布于 2012年5月16日. 估计阅读时间: 9 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

让我们从一个真实的故事讲起吧:

时间:2011年夏天一个炎热的星期二。

地点:巴西,圣保罗市,圣保罗大街某栋办公楼的某个会议室。

事件(更确切地说是仪式):审阅为某金融机构所做的Scrum项目的第七个Sprint。审阅过程中,开发团队会向客户展示该sprint中完成的工作(主要是开发了一些指定的功能)。人物:围坐在桌边的11个人,分成如下几组:

客户:

  • 一位项目经理(灰色)
  • 两位遗留系统专家(灰色)
  • 三位最终用户(使用产品的人)(绿色)

供应商(我们):

  • Scrum Master(本项目中不是开发人员)(灰色)
  • 我,从客户角度作为Agile BA,从技术团队角度则是PO(灰色)
  • 三位程序员(整个团队有六个人,但审阅会在客户公司进行,我们又没有面包车,所以没把整个团队拉过来)(红色)

座位安排如下图所示:

有趣的是,最终用户(绿色)和程序员(红色) 面对面而坐,可是没有人要求他们这样。

落座完毕,程序员开始介绍。他们一边展示按照客户的布局要求设计的界面,一边演示上次计划会中选定开发的各种操作。突然,客户开始提问。一问一答之间,谈论的内容便也信马由缰起来。整个过程我只是默默旁观。

我注意到,我们——那些灰色的圆圈们——本来应该主持会议、控制会议节奏、提出议题的,此时却惜字如金,不说一句废话。

我又注意到,在交谈中程序员所用的字眼都是面向业务的,根本不需要翻译。

更有趣的是,一位最终用户发现上一个Sprint遗漏了一些重要需求,这些需求自然赶不上即将发布的版本。

这种情况难免会发生,毕竟计划赶不上变化。对此,不同的项目管理方法采用不同的应对手段,对于Scrum来说,就必须推迟发布。当然,谁都不愿意这样,所以当推迟发布不可避免,推迟的时间就越短越好,最好控制在一个Sprint之内。

作为Agile BA/PO,我的工作主要是同时理解业务和正在开发的系统。换句话说,我需要和客户、最终用户打成一片,为他们的需求找到最经济的实现方式。系统中已有的大部分功能都是以这种方式确定下来的。但对于眼下这种情形,我能做什么呢?非常少。

出乎意料的是,开发团队利用他们的业务知识,客户利用他们对系统的了解,双方非常高效地商讨出了解决方案。这可是破天荒地头一回。

在这个过程中,我们这些“小灰”们只是偶尔提些建议,我则负责更新文档(其实这个工作在那个场合一点也不重要,只是在编写用户手册以及支持外部QA时有些用处)。

最有趣的是,我们正在讨论的是项目的第七个Sprint,鉴于我们的Sprint包括10个工作日,那意味着我们正在谈论的是大约105个日历天数的工作成果,也意味着项目伊始至今也不过3个月左右的时间。

撇开不谈那些实际的工作成果——在不到五个月的时间内完成了相当多的功能,同时系统架构、用户交互符合严格的标准,所有这些还都是以外包的形式完成——Scrum的应用还给我带了另一大好处:

在短时间内,我们创建了一个六人的开发团队,该团队不仅能从技术角度给出解决方案,而且能从业务的角度理解问题并做出反应。

我希望我能衡量这一好处的经济价值,但没那么简单,因为我们不仅造出了金蛋(运行的代码),而且培养出了能下金蛋的鹅(我们的团队)。

我们能有这样的成果归功于三方面的因素。首先是Scrum一直推崇的核心精神,我称之为“团队实体”——团队有责任在每个Sprint结束的时候,通过与有关各方的面对面交流,将解决方案进行交付。

这样的仪式缩短了距离,消除了偏见和疑虑,增进了心灵的沟通。程序员和客户开始用名字称呼对方(至少在巴西是这样),开会时也会纯粹因为关系亲近而坐在一块儿。

在我还是商业管理专业的本科生时,我学过一些不同的方法用以评估职业人士的工作表现,但是没有哪一种能像Scrum这样直观、公正。我觉得,顶多两个Sprint就可以让你了解一名职业人士是“猪”,还是“鸡”,或者更糟

这也引申出我们的第二个因素——团队优化。正如人们所说的,“Scrum不能帮你解决问题,但可以帮你看清问题”。通过每天的例会、团队中任务的分配以及工作可视化工具的应用,例如我们使用的“ Sprint 看板(一个画板,上面展示了工作的进度和任务的分配)”,谁干得好谁干得差一目了然。

任何项目团队都需要管理:如果团队里有人只聊天不干活,那他/她会被要求离开项目组。如果在新的项目组,他/她还是如此,那抱歉,只能让他/她走路。

与解雇相比,开除出项目组没有那么严厉。这种事情也确实发生过几次,其中还有一位老兄不幸被解雇了,因为他在上一个项目中就被开除过。所有这些开除的决定都不是独断的或单方面做出的,所以不需要过多地解释,被开除的成员也通常心服口服,团队的气氛也没有因此变得紧张。

碰到这种事情发生,我就必须做两方面的工作。一是要让开发团队能畅所欲言地交流,甚至决定谁应该离开;二是要让客户理解开除组员的决定,虽然这会使得团队规模变小,甚至小过我们与客户约定的规模,但都是为了使项目能更好地开展。

我在两方都发起了信任投票,结果让我们清楚地看到,对于团队来说,小而精胜过大而滥。

第三个因素和Agile BA/PO的角色有直接的关系,就是我的“交付-价值”表的应用:

解决方案(交付)

问题(价值)

程序员说了算

BA说了算

BA提供参考意见

程序员提供参考意见

技术设计

目标

系统

业务

最终用户

利益相关者

非功能性的

功能性的

怎么做以及为什么这么做

做什么以及为什么要做

我常在我的课堂以及讲座上展示这张表格或者他的变体。它能帮助说明一个道理:虽然开发团队和业务团队之间有个中间人的角色(例如Agile BA/PO),但双方绝对不应该彼此疏远。

从开发团队的角度来说,Agile BA/PO是问题域(Problem Domain)的代表(调查研究之后),但开发团队也需要及时了解业务变化,同时业务上的问题也需要听取开发团队的意见。同理,虽然解决方案由开发团队负责,但BA/PO必须了解解决方案的最新情况,系统遇到问题也需要听取BA/PO的意见。

迭代开发的一大妙处是互动无所不在:在各种Scrum仪式上,包括计划会、每日例会和Sprint审阅会,甚至在Sprint开发进行期间也是如此。

这使得领域相关的信息能够以支持决策优化的动态过程形式自由地传播。可以说,迭代增进了交互。

我记得在同一个项目期间,有一天我在拜访客户时接到了一个程序员的电话。他想对某个需求的实现方法做一些技术变更,特地打电话问问我的意见。交谈虽只持续了2分钟,却增进了我们之间的联系,让我了解到一种能更好解决问题的办法,而且产生了一种积极的、持久的共识。

简单来说就是,即使责任已经很明确,我们仍要尽力消除双方的交流障碍——一方事事从价值出发,一方时时以交付为重。

在这篇文章里我一直谈论Scrum,但上下文提到的很多有趣的东西都是来自于精益软件开发概念。在这篇文章的第二部分,我将以商业管理专业科班的身份阐述为什么作为Agile BA/PO应该希望自己变得多余。

问题在于:你敢不敢?

关于作者

Claudio Brancher Kerber (@oclaudiobr):巴西人,自称商业分析狂热者,自1997年开始摸爬滚打于软硬件制造相关的问题域,专注于团队领导和团队授权。1998年他和朋友一起创建了巴西第一个不动产网站——Aluguel在线,用户在网站上可以方便地租售房屋,但由于缺少简单的商业模式导致网站的财务失败。于是他放弃了自己学的土木工程专业,转而学习商业和营销,以认清自己的失败。现在他利用这些知识和经验帮助公司填补商业模式和IT支持方式之间的鸿沟。Claudio供职于Grupo RBS(巴西重要媒体,拥有电视台、电台和报纸),身份是互联网计划的Agile BA。他常在会议上发言,喜欢骑着自行车穿梭于圣保罗的大街小巷。他的网站在这里

 


感谢侯伯薇对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

好玩 by song zhang

很有趣味i!

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT