#2018年中总结之二#项目问题浅思 领域驱动设计?敏捷开发?

十个月的时间,展转六七个项目,虽以普通开发人员的视角管中窥豹,但项目中的问题弊病依然可见一斑.从几个方面写写本身的见闻和浅析吧

1. 人天问题

软件开发项目最大的成本就是人.人天预估的高了不容易中标,人天预估的低了又难以保证质量,其中的权衡拿捏不是我一个小技术能涉及的.可是真正落地实际状况并不理想,在许多项目的承包上,项目预估的人天与实际所需严重不符,甚至有项目刚开始作需求分析的时候,工期已通过去了一半多.因此即便已经疯狂压榨开发人员(个别项目整月整月的加班到12点),不少项目仍是不得不延期,仓促赶工的项目质量不行与延期以后带来的成本提高都在下降甲方的满意度,同时也下降了乙方的利润

2. 业务能力不足

多数项目中缺乏能从总体角度辅助客户完成业务功能设计的出色业务顾问.不少项目中,甲方业务需求本身想方案完成方案设计,乙方业务能起到的做用小.

3. 盲目推行新模式

赶鸭子上架推行DDD,领域驱动设计的确要求与业务增强沟通,双方共同设计出领域模型.可是在双方对领域驱动设计都缺少了解的状况下强行推动DDD很容易弄巧成拙.

一方面业务人员容易落入本来瀑布式开发的窠臼中(视各类需求分析文档\开发文档为项目进度的里程碑)(这也有甲方的领导很难转变思惟的缘由:有时候业务角色接受了新型的软件开发方法,而他们的领导却不能紧跟这种变化)

另外一方面,DDD要求技术人员也要转变思惟,系统的设计,尤为domain层的实现,与本来的mvc模式彻底不一样.并且,领域模型驱动代码的实现要求保证领域模型的设计是正确的.不然咱们没法肯定领域模型能够解决领域中的核心问题

这就致使,甲方由于缺少项目产出(特别是在项目前期,DDD由于重产品而轻文档,缺乏能向甲方说明的项目进度的标的)会开始怀疑乙方的进度,而双方对领域的不擅长致使迟迟不能推演出正确领域模型设计又继续加剧这种不信任,而后由于时间有限,仓促赶出一个领域模型并进行开发,以致于模型没法符合实际业务须要反而增长了开发难度...而项目的延期又会致使甲方进一步怀疑乙方能力...

总而言之,我认为在实施DDD的过程当中,咱们缺少一个领域专家的角色带领咱们向DDD过渡.

 

4. 技术与业务之间的隔阂

在项目中,业务在完成了项目前期业务模型设计以后的主要角色就变成了监工和功能测试人员.

许多业务顾问除了催进度以外就只会甩锅,说什么什么问题是开发的问题,是他们写的bug.而技术人员一样会把锅甩给其余:好比设计的时候没写清楚,好比这个代码不是我写的而是以前的人写的等等.

互相甩锅致使乙方内部都没法通力合做,大把的时间用来互相扯皮推脱任而不是解决问题.

5. 规范与标准化的缺失

1. 代码仓库管理分散,各个项目组有各个项目组的svn服务器.虽然很早就在客户部署了统一的gitlab服务,可是项目迁移缺少动力,进展缓慢

2. 项目文档管理混乱,这个比代码管理还要混乱,代码最差的状况也至少有svn中央仓库,而文档要么直接缺失,要么就只保存在个别几我的的本地电脑中.

3. 项目文档没有标准化,每一个项目的文档都使用不一样的模板,并且当代码功能变动时,文档一般没有跟着变动.这给后续接手运维或者升级的人员带来了很是多的困难.

4. 缺少代码审计流程.大多数项目没有代码review环节,代码质量彻底依赖开发人员自查,关于安全性的缺陷检查与编程规范基本无从谈起.

5. 缺少测试,大多数项目没有规范的测试流程,大多数开发人员不写测试类.单元测试无从谈起.测试人员一般由甲乙双方的业务人员兼任,一般也只是在页面上点点点的黑盒测试.

6. 缺少开发规范,包\类\方法\字段的命名没有规则,数据库设计字段命名随意,对如何拆分数据表缺少清楚的逻辑.

 

6.人员变更大

项目成员表来源复杂,组织结构复杂,项目成员来自公司内不一样的事业部,直接汇报的领导各自不一样.并且,由于压力福利种种缘由,项目内持续有人离职,因此项目组不得不从公司的其余部门调人同时从外面招人,而新招聘的员工质量没法保证,从企业内其余部门调来的员工又由于跨部门,带来了管理上的麻烦

 

尝试的改变与局限

1. 推行容器化,由于容器化的推动依赖gitlab的CI/CD功能,容器化倒逼各个项目组向统一的gitlab迁移代码,而容器化也同时简化了发布流程,提升了标准化.而推行容器化的局限在于如下几点:

   • 不少老项目部署在weblogic环境中,迁移难度大,并且部分老项目长期没有技术人员维护,从接手到升级成本很高.

   • 即便是使用了gitlab管理代码的项目,可是不少项目没有严格执行gitflow的流程,致使分支管理混乱,各个分支代码不统一,部署版本不肯定等等问题依然存在

 

2. 推行敏捷开发,在一些新项目中使用敏捷工具如看板等推动项目进展取得了不错的成效,客户能够经过看板直观的看到项目的进展,开发上的进度也更容易掌握. 局限性在于推行敏捷须要有懂敏捷的人员参与,而不少项目人员没有敏捷的培训对敏捷工具不熟悉,也不了解敏捷方法.这就意味着敏捷开发难以大规模推广.(频繁的人员更迭也加重了这一点,由于新加入项目的同事广泛并不了解敏捷)

 

3. 成立了测试小组专职进行自动化测试.这确定是一件好事,可是目前的测试仍是依旧停留在表面,使用的是eggplant模拟点击网页操做的测试工具作黑盒测试,虽然在必定程度上节约了测试时间成本.可是局限性依旧很大:

   • 一方面是软件学习成本高,本来作功能测试的业务人员很难学会使用.

   • 一方面这种测试依旧是黑盒测试,并且难以测试边际值,只能测试正确的流程可否完整执行. 另外据我了解,测试人员在项目中地位不高,并且一般还须要兼职作开发工做.

 

4. 安排开发人员互审代码. 这项工做初衷很好,可是实际执行中,代码审计的优先级远远低于功能开发,在开发进度压力大的状况下没有人在意功能是如何实现的,由于能定期交付就已经用尽全力了.