原因才是真正的关键问题

上世纪九十年代,我们在软件开发领域遭遇了史无前例的低迷局面。编程开始成为一种主流行业,而不再是少数天才的专利——这对我们来说非常可怕。但这一切在2001年得以转变,众多睿智头脑的激情碰撞开始给整个产业带来前所未有的重大影响——虽然我的这一论断未必能得到他们的认同。他们最终拿出的成果解答了上世纪九十年代困扰所有人的大问题——通过创建社区,让思路相近的人们一同探讨如何更好地实现软件交付。如今敏捷化开发趋势已经广泛铺开,我们也已经在软件开发方面获得一个又下一个辉煌的胜利——然而新的问题也由此产生。

给我(Gordon)印象最深的一句名言是“不要把交响乐谱写与音乐本身给人的触动混淆起来。只有少数天才能够创作出震撼人心的交响作品,而作为普通人,我们只能安静欣赏并从中获得属于自己的灵感与喜悦。这一点不得不承认,这个世界确实只是有少数的天才级人物,做出革命性的突破,一大批顶尖的人才,将其发扬光大,(每个人都是天才,关键是他能否找到自己的领域)

也许有点跑题,但我个人认为这个比喻在软件开发领域也同样适用。在我看来,我们常常会把如何漂亮地解决代码问题如何保质保量完成编码工作甚至是否利用正确设计或方式正确的语言进行开发视为重点。请容我解释,这些当然很重要,但绝不能算作关键。真正决定一款软件是优秀还是伟大的因素不在于此。(在于哪些?)遗憾的是,这恰恰是很多软件工程师所关注的唯一因素。


困扰了软件项目与产品交付任务多年的一大难题在于,我们到底应该开发出什么样的成果(结果为导向?)。一般大家的回答会是“用户想要的”,但很多用户甚至根本不了解自己的需求,由此盲目推出的产品显然无法令人满意。(做需求分析的方法也很多啊?

在大学里,一位导师给Gordon讲了一家美国汽车制造商的故事。当时这家企业进行过一项调查,询问人们希望在汽车里看到哪些设备以及印象中美国汽车应该具备哪些特色。最终结果?当然是彻底失败了。虽然这类开放性话题往往令答案变得非常复杂,但在这个案例中,我认为最大的问题在于汽车用户与汽车设计师之间存在本质差别。

同样的情况在计算机用户方面也有反映;他们大多能够肯定地指出自己不喜欢的产品设计,但却无法从零开始帮我们设计出完善的系统化产品。跟大部分人一样,他们善于从视觉或听觉角度做出主观评判。虽然开发人员也希望能从根本上实现这些终端感受,但却绝不会仅仅以“感觉”这种无法捉摸的角度进行产品设计想根据这些角度的反馈定义出准确且具备操作性的开发方案几乎是不可能完成的任务。

「用户可以说自己不喜欢的设计,是因为他们善于从视觉和听觉的角度做主观的评判,你让他说原因,有些说不上来,说上来也大都千差万别,设计师要观察,要思考他们举动背后的原因,完全按照用户直白需求的设计,不具备可行,要提炼

在斯坦迪集团于2002年针对成功交付组织的调查中,我们发现80%的交付特性甚至从未或很少得到使用。即使这一数字并不完全准确——因为我不知道他们是怎么统计到这个结果的——我仍然表示赞同,因为就在我所使用的这款文档编辑工具中,就存在一大堆我从来没用过甚至根本没听说的功能与特性。我的朋友,同时也是软件交付创新领域的合作伙伴Russ Miles曾经通过记录发现,他“在1987年前后推出的Mac版微软Word 1.04b版本中即可实现目前的所有日常操作。”这可绝不只是“软件膨胀”的老调重弹了,而绝对是一种巨大的浪费。浪费金钱、浪费精力,而且最重要的是,它浪费了我们最宝贵的资源——生命。如果我们把注意力都集中在Office里的那个回形针吉祥物上,还能有什么空闲开发出真正革命性的划时代成果!

再举一个例子,我的手机上有很多同样毫无意义的特性。我要批评的并不是设备或者软件本身,而是替那些定义、编写并测试该特性的人们感到惋惜。即使是在最近十年来,全世界在软件开发方面投入的数万亿美元中有多少是毫无意义、毫无价值甚至是与开发目标背道而驰的?回头反思,这些开发出来的东西有用吗?也许《2010:太空奥德赛》真会成为现实。

我并不是说长久以来软件开发领域从未拿出过伟大的产品或者赢得过令人印象深刻的革命性进展。关键在于如今大部分软件特性都不具备实际意义(iphone的质量比其它差一点又如何,它的使用率显著高于其它且类产品,经常被使用的产品价值意义要高于其它同类产品,除了少部分领域以外,大部分的物品的价值都会反应在价格、使用频率。)。我得说这种状况就算不会令人抓狂也已经相当令人沮丧,尤其是对于那些真正有能力有意愿做出“交响乐”级别产品的人才而言。

敏捷已经成为主流,这种梦幻般的趋势有望推动我们将个体需求与交互感受提高到超越流程及工具本身的新层面。“敏捷宣言”是一种态度,旨在将最杰出的头脑与最成功的交付系统集中到软件开发领域中来。我们要做的是努力了解软件交付成功案例中的共性,例如协作负载、小批量开发以及定期对业务软件进行反思。这些因素能够最大程度保障软件交付获得成功,而不是被动接受大批量任务与大型项目所带来的高风险。

我担心的是接下来会发生什么。比如说,敏捷软件开发最终成为软件工程链条中的固有组成部分……然后整队出发!我们现在能够以惊人的效率实现产品交付,这是一次伟大的进步。数十年来,我们一直在努力将这一目标变为现实,也因此得到了理想的结果。然而正如Russ在他QCon伦敦2013大会上的发言所说,现在我们已经实现了“快速交付有价值软件”的目标,但接下来的目标应该放在如何完成“快速交付有价值变化”上。如果软件看似有价值实际却毫无用处该怎么办?如果软件定位只考虑到远景规划中的一小部分怎么办?也许我们已经花了十年时间打开水龙头、把嘴凑上去,却发现自己直接被呛到了……

产品交付周期的缩短与产品开发效率的提高令我们面临更大的危机——一旦出发点有误,速度越快结果就越糟糕。没错,利用高度协作等敏捷技术也能在更短的时间内迅速拨乱反正,但只抱着“我们的方向没问题”的心态就着手使用敏捷技术无疑太过幼稚。毕竟我们的开发团队还是由人组成,技术无法解决人身上存在的固有问题。

我们的朋友兼技术大师Gojko Adzic邀请我们参与到2013年二月的一次精彩聚会当中。他将一些最成功的软件业人士如今在一起,举办了这次仅持续一天却激情洋溢的研讨活动。我们花了很长时间讨论上述疑问,而Gojko则在他的博客中表达了自己的看法。

会议期间,其他与会者介绍了一些我们原先就关注过的技术以及从未在实际中见识过的新思路,他们每个人的观点都很清晰,而且努力帮助我们理解为什么2001年“敏捷宣言”成员无法认同“正确”软件交付方案这一说法——这也正是困扰我们的问题所在。每项技术都有自己的“正确性”视角及对背景的特定要求,因此我们需要牢牢抓住“原因”这个核心议题从事软件开发工作。

让Gordon最受触动的观点在于,技术人员需要利用可视化方法帮助企业领导者弄清为什么他们需要某种解决方案,而这一点在执行层面上难度极大。

这些都是在开发流程中真实存在的实践方案,帮助XP及Scrum尝试并最终实现理想中的敏捷诉求。这些框架同样也能帮助我们达到理想的效果。

此次为期一天的研讨会最终为良好的软件开发流程总结出以下几条原则:

  1. 组织应专注于结果与影响,而非功能特性;
  2. 团队根据来自产品用户的实时与直接反馈决定下一步方向;
  3. 技术人员应该了解进行当前工作的原因
  4. 每位成员都拥有敬业精神。技术人员要自己主去查找相关资料(工作时间),做到一点即通。

我们将以上几条内容的顺序进行了重新调整,因为这样看起来才会有自然的承接关系。

这些原则完美体现了软件开发工作的全新关注重点,甚至足以成为我们改变业界规则的进军号角。套用一句比较通俗的说法,虽然站在“敏捷宣言”作者的肩膀上,我们以及整个业界其实才刚刚起步。但我们已经在交付工作上越走越远,这是个好现象。

现在是时候开始关注交付对象的正确性了,而这一切都要从反思自身交付软件的“原因”开始。正如Russ所说,“我们不(仅仅)是软件开发人员;我们要传递的是有价值的变化。”这就是软件开发业界在未来十年中的前进轨迹。要让这一点成为现实,其难度与推动敏捷开发成为主流方案不相上下,但对于未来的意义也同样重大。

欢迎走近成功软件交付的未来,而这一切的核心就是搞清“原因”。


草木全
分享到:
共 0 条  此列表为空  当前1/1页

© 2014 究问社区 copyRight 豫ICP备13003319号-1