敏捷初体验--没有最好只有最合适
写在前面
“老板，我想辞职。”
“怎么呢？”
“世界这么大，我想去看看.....”
不要笑，这不是梗，这确实是让我从通信行业走到互联网行业的一个原因。身体走再远也不及思想往出迈一步。
初入互联网行业，首先感受到的就是项目开发模式上的一个差异，本文就基于前后两个不同行业不同产品性质不同开发模式的体验认知做一些比较和分析，也是记录一下在学习敏捷的过程中的一些思路历程。
从Waterfall到Agile
对于瀑布开发和敏捷开发两种模型的介绍google百度一下都有很多了，为了后面更好的对比分析，这里还是先简单描述一下。
瀑布模型是很早之前就出现的一种被广泛应用的软件开发模型，它按软件生命周期讲整个过程划分成需求分析，系统设计，开发，测试，运行维护等几个步骤，从上至下固定顺序，只有上一个步骤完成下一个步骤才开始，按部就班。就像瀑布一样，如此开发模式是不走回头路的，一旦到中后期出现需求变更或者需要返工的情况，花费成本会很大。
瀑布模型的几个关键字：文档，计划，里程碑。
瀑布模型
再说敏捷，敏捷相较于文档驱动的瀑布开发，更强调人与人之间沟通的作用，以人为驱动。这里先暂且将它解释成一种理念，有多种开发模型方法贯彻了这种理念，例如XP（Extreme Programming）, FDD（Feature-Driven Development），DSDM(Dynamic System Development Method)等，应用最为广泛也最为大家熟悉的Scrum自然也在其中。
Scrum源于橄榄球里争球的概念，意为团队作为一个整体，团队内部传球一齐往前进。Scrum是一个增量迭代的开发过程，这个过程在时间上由若干个Sprint(迭代周期)组成，每个sprint一般为2-4周；在团队组成上，scrum由三个角色组成：Product Owner，Scrum Master，Scrum Team；产品负责人比较好定位，即我们的PD角色。流程管理员类似一个项目经理的岗位定位，很多公司企业的组织架构中没有明确的岗位来对应这个角色，这时候可能就会是其他岗位的成员来承担这部分的任务。ScrumTeam就不过多解释了，就是包括PO，SM和开发团队的成员。对于这三个角色比较官方的定义是这样：
产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
在Scrum中，首先PO将产品需求按优先级形成一个需求列表(产品backlog)，然后按照这个需求列表经过讨论评估确认每个迭代周期里需要完成的内容(Sprint backlog),在每一个迭代周期之后提交一个产品增量。Scrum就是通过重复迭代和增量来应对激烈市场竞争所带来的各种变化，从而更好的预见风险降低成本。
敏捷的几个关键字：人，迭代，灵活。
Scrum开发流程
为什么不敏捷
在简单描述瀑布开发和敏捷开发之后，可以发现敏捷开发好像更与时俱进，优势更明显一点。那么接下来，就要问一个问题了，既然敏捷开发更有优势，更好用，在互联网行业已经风生水起，为什么像以前老东家那样的一些公司企业不推行敏捷？又或者问为什么互联网行业会青睐敏捷开发？笔者就目前有限的一些的认知来对比分析一下，觉得以下几个方面的差异应该是其中一部分原因。为了方便比较，暂且将类似电信通讯行业等典型的传统企业简称T公司，将常见互联网行业企业简称E公司。
T公司
- 产品：企业级产品/解决方案；
- 用户：需求目标明确，定制化程度高；
- 按照合同交付验收产品；
- 合约制度牵绊需求变化。
E公司
- 产品：面向个体的SaaS(Software-as-a-Service)；
- 用户：不太清楚自己想要什么；
- 用户反馈推动产品改进；
- 竞争激烈，需求变更频繁。
首先从产品性质来说，T公司是为客户提供企业级的软件产品和解决方案，对于承载产品的相关硬件设备，网络等都是不做管理的，大家比较熟悉的金蝶，用友，Oracle等都属于这一类，常见的企业级软件有ERP，BI，OA，etc. T公司的盈利收益方式是比较传统的商品交易模式，甲乙双方签订购买合同，一手交钱 一手交货，不能说这个是一锤子买卖，但是至少这个产品交付会是一个比较规范流程化的过程。T公司项目开发过程往往是乙方认可甲方的解决方案后，从一个PO（purchase order）开始，制定产品交付计划，乙方开始对甲方的具体业务需求做分析，再进入设计编码测试等后面的步骤，在乙方完成内部产品的测试之后，甲方会真正最终产品的使用者进行验收测试，签订PAC(初验证书)，只有最后拿下FAC(终验证书)，才能进入运行维护阶段，而且在验收过程中，甲方需要向乙方提供比较详尽完善的文档。而E公司的产品则是倾向于面向个体(个人/商户)的软件服务，用户通过远程访问即可使用对应的应用和服务。E公司这种收益模式一般是通过用户自主在线付费或者收取中间服务费用，又或者像一些免费应用，通过扩大用户量吸引一些广告及周边收费服务。对快速发展的互联网行业来说，产品多样化以及收益模式的多样化也使得产品开发需要通过一种适应性比较强的方式来实现。
再来看用户需求差异，E公司面对的用户很多时候往往不清楚自己想要的是什么，用户自己也是一直处于一种寻找自己想要的产品的过程中。这个时候就需要我们能快速推出一个用户能看到能使用的产品版本，强占市场的先机，再通过用户的反馈来改进我们的产品，这个改进过程就是不断的迭代。再者，在百花齐放创新意识引领主导的互联网氛围下，产品竞争相比也是愈加激烈的，为了应对这种快速的市场变化，需求变更自然会比较频繁。相比之下，T公司面对的企业用户一般都已经有自己固有的业务模式和流程规范，所以需求目标会比较明确，在需求分析阶段，大部分的需求变更调整都会落实，再加上合约制度的牵绊，在后续设计开发过程中需求变化没有那么频繁。
基于上述几个方面的原因，虽然这里没有做全方面分析，像企业的组织架构等因素都未放在列，至少可以管中窥豹，意识到两种不同的开发模式各有特点，敏捷开发是好，但不尽适用。没有最好，只有最合适。
