如何快速交付高价值的软件

什么是价值

在《禅与摩托车维修艺术》一书中,作者罗伯特 · 波西格塑造的主人公斐德洛一直在探索什么是良质(quality)。斐德洛认为,“良质,就是那些你喜欢的东西”。在软件开发领域,我们也引入类似的观点。


什么是价值?我们会基于价值决定要做什么,以及不做什么。我们会先做价值高的事情,而将价值低的事情放到后面去做。那么,这里的价值指的是什么呢?


简单来说,价值就是“我们想要的东西”。

有些浏览器的卖点就是打开网页速度快,那么价值就是速度快。

对于12306而言,价值就是用户能订到票,界面丑陋,体验差劲都是其次。

如果我们的产品开发速度太慢,我们决定精简一些功能,加快速度,这里,价值就是开发速度。

选择价值,就是选择那些对我们重要的东西。
所谓价值,就是那些我们想要的东西。

同时构建功能特性与基础

软件开发好比建筑,造一个房子,想要打下基础,软件开发也一样。

每个功能特性都需要有坚实的设计基础,或者说坚实的“基础架构”。
首先构建简单而实用的版本
如果对于每个必需的功能特性,我们都能构建出小的版本,同时还为它们打下足够坚实的基础,那么我们就能够做到最好。


 

零缺陷与良好的设计

缺陷相当于拙劣的功能特性。它使项目进展变得不确定。只有消除缺陷,我们才清楚真正完成了哪些功能特性。

修复缺陷会带来不确定的时间延迟。随时发现缺陷随时修复,这样才能清楚知道完成了哪些功能特性
 


 

随时随地的测试你的软件

延迟交付产品,而且交付的还是有缺陷的产品,这会让我们看起来很蠢。我们最好还是别这样。

实际上,并没有什么别的好办法。在每一次迭代结束时,我们都必须尽可能地使软件没有缺陷。要做到这一点,唯一的方法就是测试。

测试不但没有减慢开发速度,反而使其变得更快!这是因为测试可以使我们犯更少的错误,同时使错误更快地被发现。

软件始终保持良好的设计

在改变设计的同时保持其良好状态,这通常被称为重构(refactoring)

若不能保持设计处于良好状态,轻则影响项目的进度,重则导致项目失败!

测试和重构结合起来,使得增量式开发成为可能。

能力是提高速度的前提

每个创业团队都想走得更快。拼命往前跑说不定会出bug(缺陷)、犯错误,累死团队,到头来更耽误进度。

为了加快开发速度,我们能做的最有价值的事情就是提高团队成员的技能。这一投入很快就能带来以下回报:浪费在修复缺陷上的时间会更少、开发过程会更加顺畅。不要将迅猛当作高效。速度最快的团队总是平稳、优雅地前进。

团队的实力是速度的上限。要想更快只有一个秘诀:找到更好的人才。

精简功能

简洁比复杂更难做到。你必须努力厘清思路,才能让一切变简单。但这终究是值得的,因为一旦你做到了,就能创造出奇迹。
——史蒂夫·乔布斯

假如你把策划中的4个功能砍掉2个,开发速度立即就会变快一倍。本来计划中一个半月才能完成的版本,现在三周就可以发了。再说,早期产品功能少是好事。

苹果公司为了创造出质量卓越的产品,会选择性限制产品功能。iPhone第一次出现时就是一款非常卓越的产品,尽管它缺少了一些你期待在智能手机中出现的功能,如应用程序不能组织起来归入文件夹,不能在同时运行的应用程序之间切换,也不能在手机锁定时进行拍照。难道真的是苹果公司的天才们一时糊涂正好忘了这些产品功能么?不太可能。他们很清楚在产品一开始就填入许多功能,只会延误发布时间,降低产品质量,而且他们知道在产品更新时可以再加入功能的。所以2007年第一款iPhone发布时,苹果公司并没有获得多少商业人士的追捧,那些欢欣鼓舞的用户更多是娱乐型消费者。

Gmail之父Paul Buchheit曾这样说过:“如果你的产品是伟大的,那么它就不需要是一款在各方面都做得很好的产品。” Buchheit在这里所要表达的核心观点是,你需要将少数几件事情做到最好,而不要想着每一件事都要做得完美。

重构

我们需要稳步前进。为此,需要时刻保持设计的清晰和整洁。而为了做到这一点,则必须进行重构。

构建一个功能特性所需要的时间大致来自以下两个主要方面:一个是它本身固有的难度,另外一个则是将它加入现有代码时可能的难度。对于功能特性固有的构建难度,开发团队一般会估计得比较准确。因此,使开发速度变得不确定或者慢下来的就是将功能特性加入现有代码时可能的难度。我们称这一难度为“劣质代码”。
如果我们允许代码的质量下降,那么有些功能特性可能很容易就被加了进来,而另外一些看起来相似的功能特性则可能陷入劣质代码所形成的曲折通道中。这导致两个看起来相似的任务所需的时间大不相同。
为了保持进度的平稳,我们必须避免这种曲折通道;而当这样的通道确实存在时,我们需要做的就是使它变直。

猜你喜欢

转载自blog.csdn.net/milu2003516/article/details/106227352