敏捷初体验--没有最好只有最合适

写在前面

“老板，我想辞职。”

“怎么呢？”

“世界这么大，我想去看看.....”

 不要笑，这不是梗，这确实是让我从通信行业走到互联网行业的一个原因。身体走再远也不及思想往出迈一步。

 初入互联网行业，首先感受到的就是项目开发模式上的一个差异，本文就基于前后两个不同行业不同产品性质不同开发模式的体验认知做一些比较和分析，也是记录一下在学习敏捷的过程中的一些思路历程。

从Waterfall到Agile

瀑布模型是很早之前就出现的一种被广泛应用的软件开发模型，它按软件生命周期讲整个过程划分成需求分析，系统设计，开发，测试，运行维护等几个步骤，从上至下固定顺序，只有上一个步骤完成下一个步骤才开始，按部就班。就像瀑布一样，如此开发模式是不走回头路的，一旦到中后期出现需求变更或者需要返工的情况，花费成本会很大。

瀑布模型的几个关键字：文档，计划，里程碑。

再说敏捷，敏捷相较于文档驱动的瀑布开发，更强调人与人之间沟通的作用，以人为驱动。这里先暂且将它解释成一种理念，有多种开发模型方法贯彻了这种理念，例如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和开发团队的成员。对于这三个角色比较官方的定义是这样：

为什么不敏捷

在简单描述瀑布开发和敏捷开发之后，可以发现敏捷开发好像更与时俱进，优势更明显一点。那么接下来，就要问一个问题了，既然敏捷开发更有优势，更好用，在互联网行业已经风生水起，为什么像以前老东家那样的一些公司企业不推行敏捷？又或者问为什么互联网行业会青睐敏捷开发？笔者就目前有限的一些的认知来对比分析一下，觉得以下几个方面的差异应该是其中一部分原因。为了方便比较，暂且将类似电信通讯行业等典型的传统企业简称T公司，将常见互联网行业企业简称E公司。

T公司                                            

E公司

1. 产品：面向个体的SaaS(Software-as-a-Service)；
2. 用户：不太清楚自己想要什么；
   
3. 用户反馈推动产品改进；
4. 竞争激烈，需求变更频繁。

首先从产品性质来说，T公司是为客户提供企业级的软件产品和解决方案，对于承载产品的相关硬件设备，网络等都是不做管理的，大家比较熟悉的金蝶，用友，Oracle等都属于这一类，常见的企业级软件有ERP，BI，OA，etc.  T公司的盈利收益方式是比较传统的商品交易模式，甲乙双方签订购买合同，一手交钱 一手交货，不能说这个是一锤子买卖，但是至少这个产品交付会是一个比较规范流程化的过程。T公司项目开发过程往往是乙方认可甲方的解决方案后，从一个PO（purchase order）开始，制定产品交付计划，乙方开始对甲方的具体业务需求做分析，再进入设计编码测试等后面的步骤，在乙方完成内部产品的测试之后，甲方会真正最终产品的使用者进行验收测试，签订PAC(初验证书)，只有最后拿下FAC(终验证书)，才能进入运行维护阶段，而且在验收过程中，甲方需要向乙方提供比较详尽完善的文档。而E公司的产品则是倾向于面向个体(个人/商户)的软件服务，用户通过远程访问即可使用对应的应用和服务。E公司这种收益模式一般是通过用户自主在线付费或者收取中间服务费用，又或者像一些免费应用，通过扩大用户量吸引一些广告及周边收费服务。对快速发展的互联网行业来说，产品多样化以及收益模式的多样化也使得产品开发需要通过一种适应性比较强的方式来实现。

再来看用户需求差异，E公司面对的用户很多时候往往不清楚自己想要的是什么，用户自己也是一直处于一种寻找自己想要的产品的过程中。这个时候就需要我们能快速推出一个用户能看到能使用的产品版本，强占市场的先机，再通过用户的反馈来改进我们的产品，这个改进过程就是不断的迭代。再者，在百花齐放创新意识引领主导的互联网氛围下，产品竞争相比也是愈加激烈的，为了应对这种快速的市场变化，需求变更自然会比较频繁。相比之下，T公司面对的企业用户一般都已经有自己固有的业务模式和流程规范，所以需求目标会比较明确，在需求分析阶段，大部分的需求变更调整都会落实，再加上合约制度的牵绊，在后续设计开发过程中需求变化没有那么频繁。

基于上述几个方面的原因，虽然这里没有做全方面分析，像企业的组织架构等因素都未放在列，至少可以管中窥豹，意识到两种不同的开发模式各有特点，敏捷开发是好，但不尽适用。没有最好，只有最合适。

参考资料及部分图片来源：https://www.versionone.com/agile-101/agile-methodologies/