前言
在一家传统的互联网公司要实行敏捷开发是一个非常困难的事情。不管是企业管理者还是研发人员，如果准备选择去使用敏捷开发去管理项目流程，推进软件活动，那么他们必然对敏捷开发抱有极大的信心或者是带有很高的期望。不得不说，敏捷开发确实是一种非常先进的软件活动实践，但是很多公司都没有成功的实行敏捷开发，反而因此拖慢了项目进度。
我经历过的各种开发模式
经历过边做边改的开发模式，也用过瀑布模式，敏捷开发，总的来说，不管使用哪种开发模式，还是成功交付的项目居多。但是交付的代码质量跟整个交付过程的区别还是很大的。下面就我的经历说一下这三种软件开发模型
1. 边做边改的开发模式
在做某一个官网时用法了该种模式，客户并没有明确需求和想法，只是简单的告诉我们需要做成跟某某网站差不多一样的，然后我们就先模仿着做了，照猫画虎，后来客户说这里需要改一下，那里需要改一下，这里换张图，那里改行字，布局变一变，反正就是说哪里改哪里。项目不大，一堆杂乱无章的代码最终也是交付了，弄得很是心力交瘁。
2. 瀑布模式
用的最多的也是这种开发模式，之前在外包公司做项目，都是先跟客户签订合同，拿到需求文档，然后开始项目，如果客户的需求不会发生变动，那是最棒的，一次性设计，一次性编码，一次性交付。但是如果发生用户需求要变动的情况就比较麻烦了，先是互相扯皮，看对方是否会妥协，对方如果不妥协，那就接着谈增加或者变动需求的价格，然后根据新功能重新设计代码，有的需求变更是牵一发而动全身的，所以只要需求一发生变动，结果往往是不尽如人意的。要么是开发人员坚决不同意修改，这会导致客户不满意，会没有后期合作。要么是开发人员的工作量会因为需求变动的变得很大，此外，客户还需要多付一些钱。
3. 敏捷开发
敏捷开发我在一次较大型的项目中应用了，进行了一些诸如头脑风暴，用户故事编写，每日站会，迭代，评审，回顾交流等活动，但是效果并不是很理想，最大的感觉就是项目进度的严重拖延，原本只需要至多一周就能完成的功能模块，在一些乱七八糟的要求下，会变得异常复杂，我在项目中所应用到的敏捷并不是纯粹的敏捷开发，公司出于某些原因，要求每一个人都是产品经理，所以我作为开发人员，需要参与到用户故事的编写当中，此外，担任产品经理这个角色，出完用户故事，还需要出业务流程图，草图或原型图，项目字典，输入输出的控件规范，如果跟谁沟通了需求，还需要有沟通记录。出完这些文档，担心有所缺漏，还得去跟领导沟通一下。
产品要出的东西出完了，还需要去找设计，沟通一下草图，让前端按照草图去设计页面，还需要去找前端去沟通接口文档，给前端把接口文档写好并保证前端可以看得明白。
好不容易进入到了编码环节，还得要有概要设计，详细设计，伪代码，这样才能正式开始编码，不然一旦编码中出现了什么问题，领导就会管你要概要设计，详细设计，没有的话，就只能自己背锅了。写代码的时候也是分了好多层级的，Controller，Service,Repository，Model，Validate，当时对代码的规范性跟代码质量也是有很高要求的。
这下耽搁了一大堆时间，终于可以开始正式打开编辑器写代码了，写完代码测好接口，提交到线上，前端可以愉快的调接口了，这个时候问题来了，我当时项目是五个后端，一个前端，距离上次对接完接口文档有几天时间了，前端可能把当时对接的内容也忘的差不多了，再给讲一遍。而且如果接口写完，发现没办法按照预先的数据结构返回数据，也不知道前端到底开始对接了没，没对接还好，再重新讲一下接口格式，如果已经完成了对接，或正在对接，这个时候要改，前端是非常不情愿的，因为一个前端，要同时对接五个人的接口，忙的不可开交。有时候前端不对接接口，后端在开发其他的模块了，这个时候前端才去对接之前的接口，如果对接出现了问题，后端还需要再回到之前的模块里面去，极大的拖延了项目进度。因为前端太忙，所以我们写接口文档的时候需要万分小心，不能出现一点错误，真是看了一遍又一遍，就怕出现一丝丝的问题。
好不容易完成了对接，到了代码评审的时候，领导说人人都要有产品意识，现在做的这个还有哪里哪里没考虑到，哪里需要变动，这下好了，敏捷的核心就是迭代，迭代的意思就是重复之前做过的，紧接着，漫长的一轮又来了。
给我的直观感受就是天天加班，还没有成果，没有成就感，苦不堪言。除此之外，还有每日站会，因为前端不能及时完成后端已经完成的接口，所以后端在做其他模块的时候，还得催促着前端及时调接口，催来催去，矛盾也是日渐加深，更加难以沟通。矛盾加深带来的后果就是站会可能会吵起来，或者沟通一些没有意义，鸡毛蒜皮的小事，陷入自行车棚问题中去。最后由于项目周期实在过长（多达七个月），团队问题太多，这个由一个产品，一个前端，一个设计，五个后端，两个测试组成的项目组被迫宣布停止该项目的研发。
可能导致推行敏捷失败的原因分析
个人觉得，敏捷开发之所以会失败的原因有以下几个方面：
- 1.人们很难从一种习惯变更为另外一种，或者说是人都是不愿意改变习惯的。比如敏捷开发中提到的站会，即使只是短短的几分钟的一个交流，也会让不熟悉的人比较难以适应，或者觉得多余（已经有日报机制了，为什么第二天还要重复汇报）
- 2.完全不同与以往的新软件开发模式，头脑风暴，用户故事，迭代会议，回顾会议，代码评审会，Sprint Backlog, 由于是从国外引进的一种软件开发模式，所以还是比较难以理解的。
- 3.敏捷更多的是一种理念，但是更多的软件公司还是拘泥于形式，完全照搬敏捷的各种会议，各种表现形式，而忽略了敏捷的真正内涵。很多公司一上来就全盘否定之前的开发模式，开始生搬硬套，最终非但没有让开发变得更容易，反而增加了工作内容。
- 4.还有其他种种的原因，再次就不一一列举了。比如把回顾会议开成了批斗大会，把站会开成了工作汇报会，由于对敏捷没有清晰的认知，还会产生各种各样的争执。
敏捷的原则与核心价值观
敏捷开发的核心价值观：
- 个体和互动高于流程和工具
- 工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 响应变换高于遵循计划
敏捷开发的12原则：
- 1.通过早期和连续型的高价值工作交付满足“客户”。
- 2.大工作分成可以迅速完成的较小组成部分。
- 3.识别最好的工作是从自我组织的团队中出现的，
- 4.为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。
- 5.创建可以改善可持续工作的流程。
- 6.维持完整工作的不变的步调。
- 7.欢迎改变的需求，即使是在项目后期。
- 8.在项目期间每天与项目团队和业务所有者开会。
- 9.在定期修正期，让团队反映如何能高效，然后进行相应地行为调整。
- 10.通过完成的工作量计量工作进度。
- 11.不断地追求完善。
- 12.利用调整获得竞争优势。
公司现状
基于以上种种可能会导致敏捷失败的原因，企业在实施敏捷开发的时候不应该盲目进行，而应该根据企业的具体情况，小步迭代，逐渐引入敏捷的概念，实现从传统模式到敏捷开发的平缓过渡。
形式不重要，重要的是发扬其核心价值观与原则。目前我在新的一家公司做技术总监，我想要吸取以前的不足，结合各种软件开发模型的优点，不走形式主义，不关注于使用的软件开发模式， 力求用最小的成本解决问题。
我公司是初创公司，用的是传统的瀑布开发模式，甚至可以说是瀑布模式都算不上，就比边做边改的那种模式强一点吧。造成这样的原因一方面是初期各岗位人员不足，二来是需求变化的太快，随时可能改变，无法写出来确定的需求文档。后来经过三个多月的磨合，以及人员补充，逐渐变成了正常的瀑布模式，会出需求文档，原型图等。就这样，磕磕绊绊完成了公司电商小程序两个版本的迭代。每完成一个版本迭代，我们都会有一个回顾会议，在第一次回顾会议上，开发团队普遍提出了需求不明确的问题，还有诸如没有提前定义好接口文档，代码不规范，产出效率低的问题。在会议中，就这些问题，也给出了一些针对性的解决方案，针对需求不明确的问题，让大家多站在用户的角度去思考，要有用户思维，必要时邀请非开发人员参与体验，产品经理需要出具需求文档，流程图，确保大家对需求的理解无异议。在第二次回顾会议上，大家没有再提出代码不规范，产出效率低等问题，但还是有人提出需求不明确的问题，或者说是需求明确了，但有些细节我就是没想到。比如需求文档里说明，用户可以管理自己的简历，然后开发人员这边做了简历的添加，编辑，但是没有做简历的删除，后来经过反馈，增加了简历删除的功能，经过测试发现，用户可以删除别人的简历，这里就产生了一个bug，用户应该只能删除自己的简历。这种类似的问题可以归集到需求不明确，需求中没有明确的告知用户可以删除自己的简历，也没有明确的告知用户不可以删除别人的简历。这个问题也可以归结为是开发人员考虑不足的问题，开发经验不够丰富，所以没有想到可以有删除的功能的存在，或者没有验证是否是自己的简历就可以删除。单总的来说，如果在需求阶段就明确好要有简历删除的功能，并且用户只能删除自己的简历，那么也能在很大程度上去避免类似的错误的产生。所以在第二次回顾交流会后，我对需求文档的要求是尽可能的详尽,越详细越好。
如何在公司实行敏捷
针对公司现状，以及最近两次回顾交流所反馈出来的问题，结合敏捷开发的理念，我做了如下调整
与项目经理跟产品经理讨论前
- 需求问题，需求尚存在不明确的地方
- 解决方案
- 由产品经理带领客户团队（项目经理，设计，文案，实际客户）共同研讨用户故事与需求
- 座位调换，项目经理与产品经理处于同一位置，便于需求的接收和意见的交换
- 其他方案待定
- 解决方案
- 日报内容与实际完成出现较大的偏差
- 解决方案
- 技术部分为产品团队与研发团队，日报统一由各组员发至经理处，经理统一在工作汇报群汇报整体进度
- 产品组负责产品需求，设计图，文案，测试，研发部负责项目的开发，部署
- 产品团队每周至少进行一次项目效果展示评审（评审时间由双方经理协定）
- 解决方案
11/19/2019 12:26:47 PM
与项目经理跟产品经理讨论后
- 需求问题
- 项目经理先跟业务对接，由项目经理担任真实客户，避免产品团队频繁与业务团队频繁接触，造成需求的混乱
- 将项目经理与产品经理安排在一块，便于需求的沟通
- 尽可能详尽的需求文档
- 应对需求变更
- 小步迭代，两周为一个迭代周期
- 需求排列优先级，每次在需求池中挑出一两个高优先级的做（开发团队应该总是先开发的是对客户具有较高价值的需求）
- 敏捷方法
- 建立公共代码库，可复用的构件
- 回顾交流会至少一月一次
- 不要在项目回顾会议充满抱怨和指责
- 以提高团队生产力为目的
- 质量保证
- 开发组完成后提供测试地址给产品部，由产品成员进行评审
11/20/2019 2:04:24 PM
网友评论