Deliver-Oriented Software Development Strategy
面向交付输出就会保持认真谦逊的心态，会更注重使用者的感受，能接受反馈，能满足要求，为交付结果负责，最终使真正的用户满意。
开发过程大体上分为四个阶段：
1. 需求阶段
2. 开发阶段
3. 联调阶段
4. 测试阶段
需求阶段
需求阶段包括需求评审与问题反馈。在这个阶段，能够及时反馈需求的设计缺陷、逻辑遗漏与描述分歧，不仅能更好的规避后期可能遇见的由于设计变更而导致的开发返工问题，而且能让设计者改进设计提高产品质量。
在这个阶段往往会被忽略的是，由于设计者自己对需求很熟悉，从而导致描述设计的文档内容不够细致或有针对性阅读人群限制。甚至，有些设计者会认为，文字不能完全表达自己的设计意图，而直接用图形表达自己的设计逻辑。我们都知道，简单的文字描述都有可能会产生歧义，图形就更不用说了。尤其是在细节不够丰富，逻辑不够严禁，设计不加说明的文档里。
很多，在作者看来理所应当的事情，往往就是开发人员需要耗费大量时间去沟通与确认的事情。非常耗费时间。
假设，开发人员只得到5天的可用时间，由于需求设计考虑不够充分导致开发到一半的时候无法继续，或者因为需求设计没有细节描述，开发人员需要反复确认这些问题，可能就已经消耗了70%以上的时间了。这么一来，实际留给功能开发的时间就所剩无几了。我们知道，所有的文档也好，设计也罢。都不是面对最终用户的，只有最终形态的产品才是用户真正所需要的。然而，产品作为给用户提供生产力的工具，作为需求呈现的载体，实际开发的时间不够充分，就不能保证产品的实际用户使用效果，肯定会影响产品力。
别外，换一个角度看，设计人员的输出其实是面向开发人员需要参考的设计文档或原型设计，换句话说就是设计人员的用户应该是开发人员。所以，设计应该是向开发人员交付的。以满足用户需求为交付目标的设计过程，一定是以方便用户使用，或容易获取信息为出发点的好的设计过程。(这里的用户指的是使用设计的开发人员；这里提到的设计是指设计过程，并不是面向最终用户的需求本身，而是设计与开发者交互的过程的产出)。
开发阶段
时间评估
开发人员参与需求评审与沟通过程，获取足以评估开发时间的必要信息内容后。需要根据自身情况很客观的给出开发时间长度(一般以人天为单位)。由于这个时间只是个评估值，所以并不能反映真实的开发时间。作为一个参考值它最重要的意义有两方面：一是给产品一个合理的发布时间；二是给开发制定计划与资源划分的可能。(这里不考虑已经确定要交付时间的场景，因为这样的场景没有讨论的意义。能完成就是能完成，不能完成就是不能完成。如果考虑更多的变量，那也只是在各方面做出妥协，比如降低质量，砍掉功能等，如果可以的话)。
思考设计
在开发阶段(也就是实际编码阶段)对于开发人员来说交付就是使命、质量就是生命，时间就是保障。能保质保量的按时交付功能是每个开发所追求的事情，是目标也是理想。说是理想是因为在实际开发项目过程中，往往会因为各种各样的外在因素影响开发实际投入编码的时间与心态，有些因素是可控的，有些则是不可控的。不可控的因素有：时间因素(加班除外)、人员因素、技术储备等。可控因素包括一切服务于开发行为本身的制度、规则、流程、资源等。既然是服务于开发，就应该尽全力保证开发时间与开发质量。让开发人员将所有精力都投入到开发与设计工作里，使其只关注怎样把开发质量做好。除此以外，开发者在编码之前投入更多的时间去思考设计或给出实现设计并且Review设计，既能避免由于经验不足或都自身思维惯性导致的开发实现设计缺陷、代码质量问题、与很多后续问题(包括：维护、扩展、变更等问题)，又能在Review过程中分享更多好的设计思路、加深对需求的理解与获取更多的经验。
代码编码
Coding是软件实际产生的过程，我认为这是一个核心步骤，也是软件从无到有变化的过程。其它所有的准备工作与流程都是为了能更好的保证开发这一步能按照预期进行，按照计划完成。一个极限的观点是，即使没有其它过程，开发过程也是无可替代的的核心的核心。
软件开发编码过程应该是占整个软件产生周期3分之2甚至更多的时间。即使这样，这个过程也可以拆分为设计与实现两个部分。通常情况下，将70%的时间用于设计如何实现功能，30%的时间用于实际编码。这样做的好处是能高效率的试错，使逻辑完整，Coding之前考虑更多的场景，结合思路整理的过程，最终形成一个逻辑上没有盲点、设计上覆盖全面、有合理调整空间和可编码的结果。剩下的就是编码过程本身就变的顺理成章了，在已经设计好结构的逻辑上写代码实效率会很好，速度会很快，基本不会出现Bug。总结一句话就是：先想后做，70%逻辑30%动手。
代码评审
code-review也是为保证开发质量的一个活动。原则上所有的代码在提交之前都要经过代码评审。因为是人就有可能出错，不是主观故意出错，也可能无意识的犯一些低级错误和忘记移除不应该出现在产品中的代码等。在编码过程中的代码评审主要目的就是为了避免这样的问题，在提交代码之后的代码评审主要目的则是为了重构、提高扩展性与分享Case等，为后续的开发维护做积累与沉淀。这点很重要，试想一下，软件开发不是一次买卖，如是每次开发都能产生除了交付之外的更多价值，如：团队、组件、工具、经验等。不仅能服务当前的产品，而且能服务更多的相似产品。软件的持续集成将成为可能。在一个好的基础上继续开发，产品质量也有保证。有了之前沉淀下的组件与工具，开发过程将事半功倍。
**总的来说，开发过程总体上是：设计 -> 评审 -> 编码 -> 评审**
联调阶段
API约定
将复杂的软件拆分成各个不同的部分各司其职，再将各部分组合起来形成完整的可有的软件功能，是一种很常见的软件架构，将拆分后的各部分独立并行开发也是一种常见的开发策略。比如，前端与后端、服务与服务等。然而在整合各独立部分形成完整功能时，如何处理其协同工作就成了完成系统整合的一个关键的因素。通常情况下，各部分在开发之前约定好交互行为(也就是API接口)后，并行各自独立基于接口约定进行开发。但大多数人都不重视API约定这件事，在制定API接口时最常见的问题就是，设计API约定的开发者不是以使用者为出发点，也不是以整体模型设计为核心思路，这就导致一个很常见的问题，当大家都以这样的API约定开发到一定程度时，或者到联调时候才发现，这个API约定是有问题的。通常的表现是发现API约定没有考虑周全，导致开发者无法完成功能的开发，或是，从API设计时就没有考虑到实际使用体验与使用场景。这个最常见于后端开发者单纯的以数据存储的角度设计API约定，而不考虑如何更好的读取。这样一来就必须修改API约定，修改API约定又会导致其它依赖部分可能存在的潜在问题，并且，使用API约定的一方(开发者)也要配合修改已经开发的代码。造成整体开发任务返工，进度肯定会受到影响。
所以，综合下来看解决这个问题关键就是“重视API约定，抽象业务模型”。多花时间在API约定的设计上，从全局的角度考虑设计，抽象出真正适应的业务模型，围绕着正确的业务模型做API设计，各部分都去适配此模型，就不会出现API设计缺陷。即使API设计考虑不全，那也只是增加变量或参考量，模型本身不用修改，以模型为基础的各部分开发工作也就不用修改了。
依赖协议
既然有了可以依赖的API约定，那么开发过程中潜在的变量就有处理的可能。将API约定看作各部分交互的协议，依赖协议做功能实现其结果就是可预测的。既然结果是可预测的，各部分就能自己独立的模拟交互逻辑与结果。也就是各部分自己做Mocks或基于协议的单元测试。只要能通过测试，我们就可以认为，联调肯定也是不会出任何问题的。实际联调的过程就变成整体测试的过程。不会产生返工或进度时间浪费。依赖协议最大的好做是，协议模型能使所有独立的开发有了一个共同的意识模型形态基础，在跨部分沟通时也会舒畅很多。
通常在前后端分离开发的过程中，都是由后端开发者制定API的。以后端提供API服务的角度看，后端开发有义务交付可信赖、易用的API约定。
测试阶段
需求评审
与开发人员一样，测试第一时间介入需求评审可以从更多角度对产品提出有价值的观点。开发更多的是以实现功能为出发点考虑问题，测试则是以更接近使用者的观点给出具有普适性的反馈。在这个阶段所有参与者能达成统一的需求理解标准与产品交付标准，则可以在转测时尽可能减少对同一问题产生分歧的可能，还可以让开发从一开始就以一个更具产品化(一个面向用户的产品)的心态和标准去设计实现，从而产出更符合要求的产品。
独立客观
做为保证产品质量的最后一个步骤，测试人员要独立客观严谨的验收产品，从使用者的角度反馈真实的使用感受，让产品问题消化在内部。由于在软件生产过程中角色的不同，测试与开发往往是在相对对立，或者说相对独立的角度对产品的功能做出自己的判断。开发人员往往更主观一些，因为从实现的角度看需求，开发人员在保证质量的情况下，追求的是尽可能以最小的代价实现功能，这就导致一个不争的事实，开发总是希望缩小开发范围、或减少、或遗漏设计中没有描述的潜在且必要的需求。大多数开发者都是这样的心态，他们往往不会站在使用者的角度去增加易用性、或优化场景等开发工作量。此时，测试人员独立客观的以用户(使用者)的身份体验或发现问题就变的很重要了。即使一个测试团队的人员不能代表所有用户的观点，但设身处地的为用户考虑以严谨的态度提出质疑则是很具有一般普适性的，是能代表大多用户的。
效率原则
得到正确的反馈时，不一定会得到开发的理解，这件情经常发生在项目里。测试提出的问题，在开发人员单从功能的角度看，则不认为是个问题。这个行为本身就是个大问题。有时测试也会得到激进的回答：“这个问题改不了”。我们都知道没有完美的产品，也没完美的解决方案，问题是需要收敛的，不可能将所有细节或优化或全部问题都完美解决再发布产品，处理问题本身就是个费时费力漫长的过程，更何况处理都是基于经验的、内部的还不完全是来自市场的反馈。所以，划分出必须解决的问题，重点投入处理有价值的问题，优先只处理这些问题的同时也必须遵循一个原则：问题能不能改是一回事，是否是问题是另一回事。原则上，无论是什么级别的问题，只要是问题就得消灭。
产品与竞品拉开差距的并不是能不能用，而是好不好用。80%的竞争者都能做到80%的基本能力，能做到剩下20%差距的就凤毛麟角了。
*总结*：
设计对开发交付；
开发对测试交付；
测试对用户交付。
面向交付输出就会保持认真谦逊的心态，会更注重使用者的感受，能接受反馈，能满足要求，为交付结果负责，最终使真正的用户满意。
作者 zonebond [email protected]