随着软件开发人员从创造软件中获取越来越多的经验，我们慢慢地领悟到了此过程（“有利地位”）中的战略点在哪里。
此文章对其中的一个战略点进行抛砖引玉，以便你可以在更少的时间内向客户交付更多的价值，并在你的软件领域保持信任。
时间高效即一切
在软件开发中，我们设备的费用是固定且微不足道。我们经常性的费用则是开发人员的薪水，但通常相比于我们正在创造软件的价值来说也是微不足道的。那么重要的费用是什么呢？是时间。
很多软件开发的费用是固定的。真正重要的费用在于时间。
用于发现客户价值并编写代码来提供所消耗的时间是我们关键的资源。好消息是时间是免费的。坏消息是一个开发人员的效率是固定的，而我们不能根据需要去提高它。我们要想充分我们的关键资源，最好的求助方式就是识别出所浪费的时间并把它最小化。
期望落差浪费的时间
我们今天所创造的软件已日益复杂。为了创造软件，开发人员必须同时在他们的大脑中构造一个与软件同样复杂的模型。
不管什么时间，当开发人员被要求修复一个问题或者添加一个新特性时，他们都会在一头扎进去做出改变前先咨询他们意识中的软件模型。如果模型与软件匹配得很好，那么这个过程的时间是高效的。如果出现分歧，开发人员就得花时间来问“为什么这样不行（像我期望的那样）？”。
在你的软件开发中，用于问这个问题的时间所占的百分比是多少？任何花在问这个问题的时间都会与更有价值的问题“我们怎样才能为用户发现更多的价值？”背道而驰。
当其他程序员要着手工作于一个软件，却因为没有机会建立一个意识模型而不能立即马上就做出有意义的改变时，分歧点就有可能增加。构建模型是非常耗时的，且通常被可以看得到源代码却未能发现与之相随的意识模型的管理者低估。你不能把100份源代码文件从一个开发人员交给另一个开发人员，然后期望第二个开发人员阅读完后马上就可以开始工作。
特别当下一个开发人员不是在同一个团队时，分歧点提高的可能性会更高。某种程度上，可以通过内部团队的沟通来减少期望落差。追加的开发人员并没有很多的机会和原始的开发人员进行沟通。
那么，我们怎样才能最小化期望落差呢？
我们不是在创建软件，而在发现软件
最小化期望落差的关键在于明白我们不是在创建软件，而是在发现软件。想一下你最后工作的那个软件项目，可能起初花了你数月的时间来编写它，但你需要从零开始，从某个人告诉你输入哪些字符开始，从多久后你要重新再次编写开始。很可能不超过一天。事实上敲打代码并不需要太长时间。搞明白敲打什么代码才花时间。
一旦你把软件开发看作是一个发现的过程，你就会发现基本的舞蹈就是进行实验。每一次我们添加一个新特性或者修复一个bug，我们都是在进行一个实验。编写代码，或许再编译一下。可以吗？当你问这样的问题时，你正在看着你的实验结果。进行实验最关键的是什么？是控制。
我发现用攀岩来作类比是很有帮助的。当攀登一个岩石壁时，谨慎的攀登者在他们前进时会花上一些时间来把钉子敲进岩壁。钉完钉子后，攀登者会尝试一条新的路线（相当于他在进行一个实验）。如果实验失败了，他会回退到上一个钉子。钉子限制了他浪费在发现路线这个过程中的时间。
自动化测试 = 攀岩的钉子
在软件的世界中，与攀登所用的钉子类似的是什么？最好的类比就是我们一系列的。
自动化测试有利于产出可以工作的软件并且能很好逼近客户的价值。
软件被看作是可以工作的，当：
没有期望落差：按照客户期望那样运转
自动化测试可以很好逼近客户的价值
全部的自动化测试都通过
第一点和第二点是很难评估的，所以第三点是我们的关键指标。虽然它并总是可工作软件精确的指标，但通常情况下它是足够好的。立即提高也是很容易的，如果全部的测试都通过了但是软件并没有满足客户的期望，那么可以添加更多的测试（受限于成本-效益）。
我是通过使用对客户价值进行敏捷测试的超级大粉丝。然而，例如这样的变种途径也是非常有用的。
占领有利地位并保持住
这些内容对于大部分开发人员都很熟悉。我们如何应用他们 -- 我们选择忍受的和那些我们不能忍受的条件，对于降低浪费会产生不同的结果。
很多我见过的以及作为一个整体的工业，都已经搞明白怎样创建软件并且现在在丰田汽车公司（催生了精益生产和后来的敏捷软件开发）练习珩磨对于价值/浪费区别开发的理解。
根据你当前在学习过程中所在的位置，这篇文章也许是一个介绍，又或者是一次温顾。
发次发布都应该是可工作的
绝不发布一个未能100%工作的软件版本。千万别这么做。
可能对于开发人员来说这是最难的准则，因为我们都被更多特性的呼声驱赶着。添加更多特性是有趣的，这会让人感觉很好，并且我们可以自由放手去做而不用顾及大的蓝图。以全部的自动化测试通过为代表，确保每个重要特性，是来自经验的更微妙的情感奖励。这感觉就像你第一次意识到，“嗨，不是全部的赤霞珠（译者注：葡萄品种之一）品种都尝起来一样而我就喜欢这一种！”而不是，“哇塞！我正在喝酒！”
确保每一次发布的版本都是可以工作的，不是牛仔的风格“看我是怎么做到的”。而是认真制作的过程。
为什么这点这么重要？因为如果你散发了一个非工作版本的软件，你就等于把浪费了一传十、十传百尝试使用你软件的各种各样用户的时间的期望落差暴露给了世界。人们会忍受这种浪费并且弄明白怎样从你的软件中获取价值吗？如果你的软件足够酷毙或者新颖的话，有时他们会，但是你每做一次，就等于把你所在的领域建立的信任减少了一分。
不久前，我很兴奋地在我的项目中使用了一个开源的软件。看起来它匹配得很完美。有着广泛的文档，代码看起来也很好，似乎也用些用户。怀着兴奋的心情，我花了整整三天，或者说工作了24个小时，尝试一个可工作的用例。我提交了bug报告，重新阅读了文档，遍历了已有的bug报告，甚至阅读了它的源代码。
最后我才意识到除了外表，这个软件根本没法工作。我掉进了期望落差，浪费了宝贵的时间。我切换到了另一个不同的承诺更少但按我期望那样精确运转的类库，从此以后我再也没回过头。
软件交付给用户的价值和时间图表中，这两者的关系应该至少是呈线性的 -- 花费在编写软件 的时间越多，交付给用户的价值就越多。
如果你的代码是不能工作的，当在编写代码时你还是要记住上面的图表，它可能会为你提供某些价值，但实际交付给用户的价值还是零。
如果你想使得不稳定、未完成，还在血流不止的软件版本变得可用，只要还有另外一个可以工作的版本的话，你还是可以置身度外的。确保master分支总是100%可以工作的，没有任何异常，这样的话你想创建多少个不稳定的分支都可以。当且仅当稳定版本是充分可用时，这样才行之有效。如果在你血流不止的版本发布很久后，而人们为了获得他们需要的特性强迫去和期望落差作斗争的话，就没什么好指望了。
有没感觉这是个可望而不可及的目标？在你关注稳定性之前，是不是总有一组更多的特性你需要去完成？如果是的话，并不止你一个人。这种感觉在软件行业里普通存在。微软项目经理以大声地对他们的开发商说“航运是一个特性”而出名，从而以便克服这种共同的现象。
解决方法就是交付更少一点，幅度更小一些，然后你就可以习惯性地去做并开始为下一次发布而工作。
可工作的发布有利于激励bug报告
来自用户的bug报告（和特性请求）是珍贵的反馈。对于在发现用户价值的探索中是有帮助的。写一份bug报告需要一定的精力并且仅当你的用户发觉可以从软件中获取重要的价值时，他们才会愿意为之付出努力去证明。
不要期望有用户反馈bug报告，特性请求，和其他有用的表单，如果你发布了不可工作的软件。
把你的软件想象成一辆车。如果它开起来很顺畅，能把它的乘客带到新的地方，他们会很积极地让你知道后尾灯是否坏了或者对提高燃料有效率的渴望。通常都能很好工作的汽车这一事实，使得隔离一个缺陷或者一个特性，以及描述其简单性都很容易。另一方面，假如汽车离不开车道的话，用户就会没有动力为你写一份bug报告。他们会假设这辆汽车明显是不能工作的，也就不会花时间去让你知道。
在交给另一位开发前要确保软件是可以工作的
为最小化第二位开发人员构造意识模型所需要的时间，最好的方法就是可以工作的并且拥有一套自动化测试套件。请记住，要想做有用的工作，第二位开发人员需要为之进行实验，所以也就需要获得控制。如果全部的测试都通过了，那么他就拥有了控制并且可以使用10%的代码进行隔离的实验而不需要为其他90%的代码构造意识模型。
这是巨大的胜利！大部分从他人接手到软件的开发人员，花费了大量的时间在 a）为它构造一个意识模型，以及 b）找出为什么没有按预期那样工作。假设你给的是有着可靠自动化测试套件、可以工作的软件，他们则可以立即投入时间开始创建特性交付更多的客户价值。
更坏的情况，当专业的开发人员继承了既不能工作又没有自动化测试套件的软件时，他们通常会重新构建整个项目而不是搜刮。我一次又一次看到过这样的情况，并且实际上这是最明智的做法因为（反直觉的）相比彻底搞清楚不可工作的软件，重新构建需要的时间更少。谈谈浪费吧！
结论
当编写代码时，有很多不同的优先级需要满足。尤其是在开源项目中，开发的动力也许是来自内部的驱动，包括编程的乐趣。
当开发人员学会把他们外部的注意力放在让可工作的代码成为客户的优先级之一时，协同反馈循环也就出来了。用户使用这些软件并且如果有需要的话，则上报关于提高的请求。开发人员获得的这些先前的反馈，反过来又可以提高软件的价值，吸引更多的用户。
在短期时间内取得火箭式前进的项目（如Docker、Node.js等）与那些辛勤工作数年都没有太大演进的项目，之间的区别就在于协同反馈循环。
把你的项目变成火箭吧。
本文翻译作者为：dogstar，发表于开源中国个人博客；欢迎转载，但请注明出处，谢谢！