2019-11-20 从回顾交流到敏捷开发

2019-11-20  本文已影响0人  赵旻峰

前言

在一家传统的互联网公司要实行敏捷开发是一个非常困难的事情。不管是企业管理者还是研发人员，如果准备选择去使用敏捷开发去管理项目流程，推进软件活动，那么他们必然对敏捷开发抱有极大的信心或者是带有很高的期望。不得不说，敏捷开发确实是一种非常先进的软件活动实践，但是很多公司都没有成功的实行敏捷开发，反而因此拖慢了项目进度。

我经历过的各种开发模式

经历过边做边改的开发模式，也用过瀑布模式，敏捷开发，总的来说，不管使用哪种开发模式，还是成功交付的项目居多。但是交付的代码质量跟整个交付过程的区别还是很大的。下面就我的经历说一下这三种软件开发模型

1. 边做边改的开发模式

在做某一个官网时用法了该种模式，客户并没有明确需求和想法，只是简单的告诉我们需要做成跟某某网站差不多一样的，然后我们就先模仿着做了，照猫画虎，后来客户说这里需要改一下，那里需要改一下，这里换张图，那里改行字，布局变一变，反正就是说哪里改哪里。项目不大，一堆杂乱无章的代码最终也是交付了，弄得很是心力交瘁。

2. 瀑布模式

用的最多的也是这种开发模式，之前在外包公司做项目，都是先跟客户签订合同，拿到需求文档，然后开始项目，如果客户的需求不会发生变动，那是最棒的，一次性设计，一次性编码，一次性交付。但是如果发生用户需求要变动的情况就比较麻烦了，先是互相扯皮，看对方是否会妥协，对方如果不妥协，那就接着谈增加或者变动需求的价格，然后根据新功能重新设计代码，有的需求变更是牵一发而动全身的，所以只要需求一发生变动，结果往往是不尽如人意的。要么是开发人员坚决不同意修改，这会导致客户不满意，会没有后期合作。要么是开发人员的工作量会因为需求变动的变得很大，此外，客户还需要多付一些钱。

3. 敏捷开发

敏捷开发我在一次较大型的项目中应用了，进行了一些诸如头脑风暴，用户故事编写，每日站会，迭代，评审，回顾交流等活动，但是效果并不是很理想，最大的感觉就是项目进度的严重拖延，原本只需要至多一周就能完成的功能模块，在一些乱七八糟的要求下，会变得异常复杂，我在项目中所应用到的敏捷并不是纯粹的敏捷开发，公司出于某些原因，要求每一个人都是产品经理，所以我作为开发人员，需要参与到用户故事的编写当中，此外，担任产品经理这个角色，出完用户故事，还需要出业务流程图，草图或原型图，项目字典，输入输出的控件规范，如果跟谁沟通了需求，还需要有沟通记录。出完这些文档，担心有所缺漏，还得去跟领导沟通一下。
产品要出的东西出完了，还需要去找设计，沟通一下草图，让前端按照草图去设计页面，还需要去找前端去沟通接口文档，给前端把接口文档写好并保证前端可以看得明白。
好不容易进入到了编码环节，还得要有概要设计，详细设计，伪代码，这样才能正式开始编码，不然一旦编码中出现了什么问题，领导就会管你要概要设计，详细设计，没有的话，就只能自己背锅了。写代码的时候也是分了好多层级的，Controller，Service,Repository，Model，Validate，当时对代码的规范性跟代码质量也是有很高要求的。
这下耽搁了一大堆时间，终于可以开始正式打开编辑器写代码了，写完代码测好接口，提交到线上，前端可以愉快的调接口了，这个时候问题来了，我当时项目是五个后端，一个前端，距离上次对接完接口文档有几天时间了，前端可能把当时对接的内容也忘的差不多了，再给讲一遍。而且如果接口写完，发现没办法按照预先的数据结构返回数据，也不知道前端到底开始对接了没，没对接还好，再重新讲一下接口格式，如果已经完成了对接，或正在对接，这个时候要改，前端是非常不情愿的，因为一个前端，要同时对接五个人的接口，忙的不可开交。有时候前端不对接接口，后端在开发其他的模块了，这个时候前端才去对接之前的接口，如果对接出现了问题，后端还需要再回到之前的模块里面去，极大的拖延了项目进度。因为前端太忙，所以我们写接口文档的时候需要万分小心，不能出现一点错误，真是看了一遍又一遍，就怕出现一丝丝的问题。
好不容易完成了对接，到了代码评审的时候，领导说人人都要有产品意识，现在做的这个还有哪里哪里没考虑到，哪里需要变动，这下好了，敏捷的核心就是迭代，迭代的意思就是重复之前做过的，紧接着，漫长的一轮又来了。
给我的直观感受就是天天加班，还没有成果，没有成就感，苦不堪言。除此之外，还有每日站会，因为前端不能及时完成后端已经完成的接口，所以后端在做其他模块的时候，还得催促着前端及时调接口，催来催去，矛盾也是日渐加深，更加难以沟通。矛盾加深带来的后果就是站会可能会吵起来，或者沟通一些没有意义，鸡毛蒜皮的小事，陷入自行车棚问题中去。最后由于项目周期实在过长（多达七个月），团队问题太多，这个由一个产品，一个前端，一个设计，五个后端，两个测试组成的项目组被迫宣布停止该项目的研发。

可能导致推行敏捷失败的原因分析

个人觉得，敏捷开发之所以会失败的原因有以下几个方面：

敏捷的原则与核心价值观

敏捷开发的核心价值观：

敏捷开发的12原则：

公司现状

基于以上种种可能会导致敏捷失败的原因，企业在实施敏捷开发的时候不应该盲目进行，而应该根据企业的具体情况，小步迭代，逐渐引入敏捷的概念，实现从传统模式到敏捷开发的平缓过渡。
形式不重要，重要的是发扬其核心价值观与原则。目前我在新的一家公司做技术总监，我想要吸取以前的不足，结合各种软件开发模型的优点，不走形式主义，不关注于使用的软件开发模式， 力求用最小的成本解决问题。

我公司是初创公司，用的是传统的瀑布开发模式，甚至可以说是瀑布模式都算不上，就比边做边改的那种模式强一点吧。造成这样的原因一方面是初期各岗位人员不足，二来是需求变化的太快，随时可能改变，无法写出来确定的需求文档。后来经过三个多月的磨合，以及人员补充，逐渐变成了正常的瀑布模式，会出需求文档，原型图等。就这样，磕磕绊绊完成了公司电商小程序两个版本的迭代。每完成一个版本迭代，我们都会有一个回顾会议，在第一次回顾会议上，开发团队普遍提出了需求不明确的问题，还有诸如没有提前定义好接口文档，代码不规范，产出效率低的问题。在会议中，就这些问题，也给出了一些针对性的解决方案，针对需求不明确的问题，让大家多站在用户的角度去思考，要有用户思维，必要时邀请非开发人员参与体验，产品经理需要出具需求文档，流程图，确保大家对需求的理解无异议。在第二次回顾会议上，大家没有再提出代码不规范，产出效率低等问题，但还是有人提出需求不明确的问题，或者说是需求明确了，但有些细节我就是没想到。比如需求文档里说明，用户可以管理自己的简历，然后开发人员这边做了简历的添加，编辑，但是没有做简历的删除，后来经过反馈，增加了简历删除的功能，经过测试发现，用户可以删除别人的简历，这里就产生了一个bug，用户应该只能删除自己的简历。这种类似的问题可以归集到需求不明确，需求中没有明确的告知用户可以删除自己的简历，也没有明确的告知用户不可以删除别人的简历。这个问题也可以归结为是开发人员考虑不足的问题，开发经验不够丰富，所以没有想到可以有删除的功能的存在，或者没有验证是否是自己的简历就可以删除。单总的来说，如果在需求阶段就明确好要有简历删除的功能，并且用户只能删除自己的简历，那么也能在很大程度上去避免类似的错误的产生。所以在第二次回顾交流会后，我对需求文档的要求是尽可能的详尽,越详细越好。

如何在公司实行敏捷

针对公司现状，以及最近两次回顾交流所反馈出来的问题，结合敏捷开发的理念，我做了如下调整

与项目经理跟产品经理讨论前

11/19/2019 12:26:47 PM

与项目经理跟产品经理讨论后

11/20/2019 2:04:24 PM

上一篇下一篇

猜你喜欢

热点阅读