软件开发框架(更新中)

一、验收测试驱动开发

针对MVP采用的假设验证过程很很像敏捷中经常提到的测试驱动开发(TDD), 我称之为【验证假设驱动开发HVDD（Hypothesis Validation Driven Development）】 ,涉及到如下四步流程：

1）.提出需要验证的前提假设

2）.建立观测数据指标

3）.开发最小可行产品

4）.搜集数据验证假设

当你想要开发MVP的时候，为避免过度开发，避免浪费，建议考虑如下简单原则： 放弃对你将要进行的假设验证没有直接用处的一切功能、流程或努力，以达到快速实验的目的。巴菲特的投资理论里面讲“少即是多”，也是同样的道理。

很多人肯定会担心MVP的质量问题。其实，质量与速度总是相辅相成的，开发MVP，与我们所提倡的高质量产品并不矛盾。在MVP里，我们只是首先拿一个客户的刚性需求，并对其进行重点开发，把这个功能做到极致（极致的意思，其实质量是很重要的一环），而忽略其他暂时对验证假设无用的功能，然后迅速投向市场。

虽然有时，我们的MVP可能看起来很简陋，或者还不能称之为一个理想的合格产品，但一定要有勇气拿出来晒一晒，让用户提前检验；如果客户认可，则继续完善；如果客户根本不认可，需要立即更换方向，开始下一次实验。如果你一直待在自己的金字塔里，闭门造车，即使做出来一堆“漂亮的垃圾”，但因无用，浪费更多，干做无用功。

采用验证假设驱动开发(HVDD)，只是帮我们解决了快速检验前进的方向对或不对的问题，但要真正占领一个细分市场，还需要跨越多条鸿沟。

其实之前，我们还做过另外一个试验，这里也分享给大家，是关于求职者是否有打印彩色简历的需求。[样例来源【敏捷一千零一夜】

我们依然从验证假设出发。

1. 提出需要验证的前提假设

价值假设：学生用户因为项目经验、实际工作技能等简历要素的缺乏，应届学生相互之间可比性较差，会倾向于在简历形式等方面下功夫，以赢得面试机会。而彩色的简历，会让他们脱颖而出，故他们可能会打印彩色简历。
增长假设：学生用户应该具备很强的羊群效应，因为同学都在打印彩色简历，故自己也会打印。

2. 建立观测数据指标：

有打印彩色简历需求的学生占所有学生求职者的比例；

3. 开发最小可行产品

通常如果把在线简历转换成可打印的彩色简历，需要如下功能

1) 多种输出模板的选择(模板开发需要提前进行)

2) 个性Logo上传 (譬如学校校徽)

3) 在线微调(类似在线PS，需要精确控制输出内容，避免将原本一页的内容输出到两个打印页面，这肯定是很大的一块工作)

4) 预览

5) 生成可打印的文件或图片

初步估算，如果把上述内容全部实现，估计2个迭代左右（20工作日）；根据前面名片的经验，这次我们也没有急于开发这项功能，而是采用了类比和反证分析法来验证我们的假设。

4. 搜集数据验证假设

首先，我们参加了天津大学举办的华北地区应届本科生双选会，在会上，看到只有很少比列的学生拿的是彩色简历，应该不到1%；在天津大学校园内有三家较大的打字复印社，学生们的简历多数是从这里打印的，调查了一下复印社的老板，他们说打印彩色简历的比例少之又少，虽然有，但很少见,估计七八十人有一个；定向调查了三家招聘应届生较多的公司，HR一致反馈，彩色简历很少，每天收上来几百份，最能看到一两份。从这三个数据，我们可以在没有开发任何功能代码的情况下，轻松验证了之前的价值假设不成立，那自然增长假设也就没有意义了！于是，这个功能被果断的束之高阁。

二、测试驱动开发

测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。

2.1、基本原理

试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。

测试驱动开发的基本过程如下：

快速新增一个测试
运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过
做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法
运行所有的测试，并且全部通过
重构代码，以消除重复设计，优化设计结构

简单来说，就是不可运行/运行/重构--这正是测试驱动开发的口号。

2.2、测试驱动开发中测试的特征

测试驱动开发中需求分析和详细设计的范畴，在代码基本完毕以后，并且这些测试也成为单元测试的一个部分。

2.3、本质优势

TDD根据客户需求编写测试用例，对功能的过程和接口都进行了设计，而且这种从使用者角度对代码进行的设计通常更符合后期开发的需求。因为关注用户反馈，可以及时响应需求变更，同时因为从使用者角度出发的简单设计，也可以更快地适应变化。
出于易测试和测试独立性的要求，将促使我们实现松耦合的设计，并更多地依赖于接口而非具体的类，提高系统的可扩展性和抗变性。而且TDD明显地缩短了设计决策的反馈循环，使我们几秒或几分钟之内就能获得反馈。
将测试工作提到编码之前，并频繁地运行所有测试，可以尽量地避免和尽早地发现错误，极大地降低了后续测试及修复的成本，提高了代码的质量。在测试的保护下，不断重构代码，以消除重复设计，优化设计结构，提高了代码的重用性，从而提高了软件产品的质量。
TDD提供了持续的回归测试，使我们拥有重构的勇气，因为代码的改动导致系统其他部分产生任何异常，测试都会立刻通知我们。完整的测试会帮助我们持续地跟踪整个系统的状态，因此我们就不需要担心会产生什么不可预知的副作用了。
TDD所产生的单元测试代码就是最比较好的开发者文档，它们展示了所有的API该如何使用以及是如何运作的，而且它们与工作代码保持同步，永远是最新的。
TDD可以减轻压力、降低忧虑、提高我们对代码的信心、使我们拥有重构的勇气，这些都是快乐工作的重要前提。
快速的提高了开发效率。

三、缺陷驱动开发

四、特征驱动开发

4.1、为什么需要FDD

FDD没有传统工程中冗长的设计过程，而是通过边设计边开发进行迭代完善，因此它非常适合项目的快速开发，由于不断的竞争，现在一个项目的交货周期越来越短，需要在极短的时间内开发一个可维护、可拓展的高质量软件系统已经是形势所逼。

　　软件开发人员喜欢新的事情，使用FDD每两周就有新的事情可做，而且每两周就可以交货完成一些工作，离目标越来越近，这种 Closure感觉在开发队伍中是很重要的，可以让大家万众一心，有一种拧在一起的冲劲，从而潜在地提高开发人员的积极性。

　　同时，项目经理也会喜欢FDD，通过FDD，他们能够知道规划什么、以及确立关键开发阶段，经理们可以频繁参与项目协调和管理，同时掌握大家的工作成果，从而了解整个项目完成的百分比进度，例如是完成了57%还是其他数字。

　　软件系统的客户也回喜欢FDD，他们能够参与或看到开发过程中的关键阶段，能够看见前一阶段的开发结果，以确认和他们要的是否一致，并提出下一步修改意见。

4.2 FDD是什么？

FDD是一个模型驱动( model-driven)、短期遍历(short-iteration)的过程. 注意，FDD是一个开发过程，过程总是有起点和终点，FDD的起点是起源于创建一个全局的模型轮廓（不要求很精确，大概模样就可以），然后大概是两周的一系列的"design by feature, build by feature"的迭代，逐渐丰富模型功能内容，features是指小的、以软件用户的视角看是有用的特征功能，一个FDD开发过程

翻译过来就是：开发整体模型--》构建功能列表--》计划功能开发--》按照功能设计-->按照功能构建