BT

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

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

| 作者 Claudio Kerber 关注 0 他的粉丝 ,译者 李竞 关注 0 他的粉丝 发布于 2012年6月12日. 估计阅读时间: 9 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。
我建议您在阅读本文之前最好先读一读该专题文章的上半部分。上半部分基于一些结果明确、有目共睹的案例。下半部分则是基于我个人的经验、非正式的研究和观点。所以内容的可信度依赖于我的经验。

先让我猜一猜:如果你正在或者打算在敏捷开发环境中工作,那么我打赌,在你最初了解它的时候,肯定有所触动,而对于那些触动你的貌似“合理的事情”,你会觉得有必要促成它们在现实中发生。

好吧,至少我是这样。当我最终明白敏捷是什么时,就做了所有能做的事情让它运转起来。

有趣的是,有些东西,虽然只是在理论中有所了解,却真真切切的能够与心灵沟通,我们能感受到它们是优良的、可取的、合理的且近乎本能。在我的职业生涯中碰到的具有如此特质的事物,多半都和精益软件开发方法有关。

最初知道“精益”这个概念还是在1994年,那时我16岁,正在一所工业培训学校学习机械和建筑设计。从那以后,我时不时会接触到“精益”,但必须承认,当它逐渐被软件行业所接受时,我却把它给忘了。结果,我带着一些古老业界模型中的习惯做法开始了我的IT生涯,也把这些习惯带给了可怜的同事们。

我之所以能醒悟过来,主要是因为我开始阅读Poppendieck 夫妇的文章,他们将“精益”的概念套用到了软件开发上。另外我也开始关注巴西一些专业人士的最新动向,例如Luiz Claudio Parzianello / @ lcparzianello (敏捷业务分析)和Rodrigo Yoshima / @ rodrigoy(利用“看板”软件进行产品管理)。我非常期望将所有这些概念都付诸实践——我总有一种强烈的感觉,我们工作中浪费的精力太多了。

但是精益又怎么和一个Agile BA千方百计变得多余扯上关系的呢?让我们继续往下看。

精益生产的主旨之一是消除浪费。在业务过程中,在很多方面都会出现浪费,最常见的莫过于“库存”和“移交”。为了当前的目标,我们只关注移交。

在业务过程中,有中间人就会有移交。只要中间人介入,就会产生直接的开销和相关的风险。

开销主要是交流和任务本身占用的时间。风险在于交流有可能出错。交流中的问题在业务过程中会被放大,就像滚雪球一样,最终造成灾难性的后果。

在上图中,每一次移交都会产生时间成本和不良沟通的风险,那么,在什么情况下设置中间人的角色才能利大于弊呢?好吧,既然考虑到成本,那么没有比双向交流——例如传统的软件开发过程(如下图)——的沟通成本更高的了。

从图中可以看出,在开发阶段,即使是解决很小的疑问,都会耗费大量的时间,冒很大的交流风险。

那么,本文标题应该改成“干掉所有中间人”喽?这我也不能苟同。他们(其实就是我们)的存在是有原因的。当我们的价值总和超过固有的时间成本和风险时,我们就会存在(或者说,应该存在)。这是基于投资收益率的计算而得出的结论。

举例来说:我记得我们曾经为某公司的一个巨大流程创建了分区活动图(partitioned activity diagram),涵盖了从挖掘潜在客户到安装产品的若干活动,跨越了足足15个区域(partition)。经过分析,虽然大家认同可以做很多改进,但是每个“区域”带来的价值超过了它们的成本和风险,这也是不争的事实,因此他们全部保留了下来。

在讨论项目管理方法学的时候,经常出现的错误想法就是认为世界是静态的。有人会问:“在这样的项目中什么角色最重要?”其他人(直到最近为止我也是这样)回答:“这个、这个还有那个”。

然而实际情况却常常是这样:角色的重要性会随着工作的开展不断变化,就像桥下的流水一样。在项目管理中我们应该把这一点考虑进来。

生命在于运动,世界绝非静止。

因此,当问及作为中间人的BA对于IT项目是否重要时,我的答案是肯定的,不过还得看是在什么时间点。

根据我的经验,在迭代增量开发的项目中,BA的重要性在项目开始处于峰值状态。而随着一个优秀团队——例如在本专题上半部分中提到的那个——逐步成熟,这种重要性会逐步降低。

如上图所示,根据精益软件开发方法,在“B阶段”的工作效率远高于“A阶段”,但是如果没有BA,你很难到达B阶段。

 

以下是对“A阶段”BA重要性的分析:

BA的收件箱

BA的发件箱

模糊的企业策略

组织架构

价值链

业务模型

数以千计的相关方

模棱两可

分歧的观点

文化冲突

利益冲突

缺乏自信

愤世嫉俗和讽刺挖苦

开发团队

产品愿景

相关方保持一致

综合

通用词汇表

没有歧义

验收准则

自信

良好的幽默感和心灵的沟通

非常优秀的开发团队

 

上表显示的是一次非正式问卷调查的结果,调查对象是和我一起工作的程序员。问题很简单:“你觉得我对项目有贡献么?如果有,是以何种方式?”把自己想象成产品,就很容易了解自己在何时何地是重要的。

这个图表可以提醒我们,任何项目总是同时在开发两个产品。一是我们的解决方案,人们用以——我们希望——解决某种问题。一是我们的团队,以及团队工作的环境。

人们常希望我们这些BA能够以更广阔的视角看待对业务重要的事情。我们的目标不仅限于解决手头的问题,还包括提升解决问题的整体业务能力。而开发团队——即使是外包团队——是这个整体的组成部分。

在Scrum圈,我经常听到这样的观点:Scrum Master在一个优秀团队的建立过程中起到很大的作用。这一点我同意,因为他们也是团队的一部分,面临着相同的挑战。

在新的环境中,Scrum Master在项目开始时至关重要。技术问题如代码库、开发环境、集成、部署、结对编程甚至代码缩进必须在数日之内定义好并开始运转。在这个阶段,Scrum Master的方针和做法是项目启动的基础。

即使知道上述的决策会随着工作的开展而变化,并且不断会有新的选择出现,但只要能正常工作,这些问题与和产品相关的问题比起来就相对不是那么重要了。

在第一次评审之后,“做什么以及为什么要做”成为了关注的焦点,因为此时客户开始介入了。同时Agile BA也开始登台亮相,毕竟,让Scrum Master承担所有的事情是不公平的。

以更广的视角看待对业务重要的事情也让BA能理解,在大多数情况下,随着项目的进行,逐步减少自己的参与程度,是比较明智的做法。

但需要特别注意的是,减少参与的只是业务分析师,而不是业务分析。业务分析贯穿项目始终,或者针对问题域,或者针对解决方案。而正是由于BA的存在,才拉近了问题域和解决方案的距离。

关于作者

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

 原文链接:The Day I Became Unnecessary - Part 2 


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

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

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的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通知我

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

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

讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT