项目整体流程总结

项目整体流程总结

百度百科：
ER图也称实体-联系图(Entity Relationship Diagram)，提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型。 它是描述现实世界关系概念模型的有效方法。

ER图通俗讲，就是软件项目设计图纸，因为下文基本贯穿全文，请大家了解一下 以下为ER图
替代文字

从项目调研说起

在项目初期,最重要的是找到用户的痛点,如果用户痛点不够痛,基本就是意味着项目上线困难,因此前期调研一定要找到用户最迫切要解决的问题,并且考虑一下如果目标达成,将带来怎样的效益,如果这个流程想通了,才能开始以下的步骤,以下的流程,是很轻量级的循序渐进

1.绘制ER图,调研,期间不会开始写代码,这个时间周期一般在两个星期,
第一步
找业务主要负责人,组织第一次会议,业务相关人都要到场,各抒己见,充分讨论问题,

在会议中捕捉有用信息,让用户讲解现状,在讲解现状的过程中,一定要将用户讲的,用自己的语言再描述给用户听,等待用户确认后,才能获取正确的信息

​ 由于用户所处环境不同,以及表达能力的不同,所以向用户提问一定要简洁清晰,不要使用软件技术语言,所以开会之前一定要看大量的用户基础资料类似Excel,先做到心中有5-6成了解,在这个过程中,一定要抱有一个空杯心态,用户是业务专家,同时也是衣食父母,充分的敬意与诚恳,才能与用户有效沟通,一定要以ER图为根本思考会议内容,把控会议的进度,如果用户谈论的话题与自己调研的问题有偏差,一定要及时沟通,询问自己重要的几个点,大家都是为了工作,这些谁都不会在意,如果这次调研效率低,会将问题抛到下一个周,问题会随着多次会议滚雪球

​ 在一个项目周期中,用户的耐心一般最多三个月,这里不是指单个用户,而是用户群,如果在三个月的周期内,软件没有达到预期效果的70%,说明这个项目出现一些问题,用户群对于软件的热诚度不断降低,这样造成的后果很严重,因此在上线项目的时候,项目时间控制方面要紧凑高效

​ 但是这种赶工期是建立在项目清晰明确的情况下,项目的ER图,能够充分说明项目的清晰度

工作经验：让用户提供所有的Excel文档,流程文档,是所有,除了保密的只提供文件表头及模拟数据外,其他的都要提供,因为经常发生项目开发完成,用户又拿出一张Excel,你设计的ER少了一环,这时候只能徒增工作量,并且将严重影响软件的开发周期, 这件事情的解决方案是:可以事前说明，后期拿出的Excel文件要罚款，一般会引起用户的重视，毕竟调研开发成本不低.

另:当前用户流程是否符合上系统的的要求，如不符合需先进行标准化；需求做不做需要考虑成本与收益的关系.

第二周会议
根据上次的沟通,以及用户提供更加细节的资料,可以绘制出一份ER图,这时候这张ER图应该能够80%的描述整个业务流程,这一次是来做对象关系的编码之前最后确认的,将每两个物料之间的关系都要让用户确认,这一次依然需要全体业务师傅参与,这次沟通后,注意说话的时候,一定要让所有的师傅听懂你的意思,调动现场的气氛,否则如果现场有的师傅不太在意会议的内容,那么有可能会丢失重要的信息,为项目引入错误决策风险.

第三周
这一周将带来的软件的演示版本
通过第二周绘制确认的ER图,首次制作的软件是非常简洁的,借助自制Oracle表格转换为NHibernate工具,通过NHibernate,编程效率高,DEV托拉拽，这个时候的软件编写是非生产标准的,主要以演示为主,但是核心功能要出来,系统其中有可能包含大量bug,但是这不重要,用ER图与用户沟通的目的是用低成本有效沟通,而不是最直观的,当用户看到软件示例时,用户就会提出大量的问题,这时候注意不要被用户的细枝末节问题困扰,关键询问用户的核心问题是否已经解决,如果解决说明就项目按预期进行,如果有问题,查看是否是ER图的问题.

第四周,全力修改bug,这时候在使用了Spring,Hibernate,Oracle这些组件的情况下,有很多特性是可以规避风险的

第一个,
Oracle的主外键,这个是关系准确的保障,所以数据库建立主外键的目的就是提升软件的鲁棒性

第二个,
Spring事务,上了线的系统必然存在各种bug,如果有错误不符合规范的数据写入,那个错误将会滚雪球一样让你失去对于系统的控制,开发同学之间的逻辑错误,在Spring事务传递方案后,出现问题,即使在用户那里报个错,也不会破坏数据结构,这个逻辑如果没有Spring对于协同开发将是一个不小的任务

第三个,
Spring.Net+NHibernate强大的SQL日志功能,这个功能将用户的操作记录详细存储,

根据SQL流程日志,就再现了用户的操作过程,这样就能快速定位问题,并且一旦定位修复问题,这个问题就很难再次发生,在项目上线的时候总是有些紧张,但是有时候必须要知道哪些是不可控的,哪些是可控的,一定要做到心中有数

有了这三个的有力保障,软件整体运行是可控的

DEV的引进,解决了用户体验的问题,用户总是拿Excel来类比新开发的系统,DEV有效缓解了用户的抱怨,一定要让用户知道,我们是最期望项目成功的人,但是Excel历时几十年,上千工程师的优化,功能强大,而新系统的优势在于数据共享,并且数据权限可控,这些用户会逐渐的接收,整体效益的提升

第四周
下一步就是按部就班的上线了,有了前面的保障与用户体验,上线过程一般不会出现什么严重问题,如果出现严重问题,还是ER图没有设计好,要知道核心的关系如果错了,将很有可能将前面的开发推到重来,所以ER图如果不画,没有三个保障,项目加班调试,系统不稳定,莫名其妙的问题,不可控的方式,都会造成项目的延期,要注意这一步的时候,是用户耐心最薄弱的时候,如果一个问题反复出现,无法及时解决,用户对于项目的质疑会越来越大,即使管理人员介入,也必须解决bug,加班加点的排查,没有三项保障就是原因之一.

第五周
即使有三项保障,项目进展一般都会问题升级,就是用户突然发现,原来没有软件前我的做法有些局限了,现在有了软件了,我想改需求,改需求,改需求,

什么能够保障改需求,

第一:单元测试
单元测试至今未能引入的项目的框架,这个框架对于数据库开发,太重量级了,

一直想引入本地数据库类似SQLite,但是没有成功,另外一个重要的原因,开发成本要上升一倍,尤其是刚开始使用单元测试,但是思维无法转变,感觉就是一个累赘,单元测试实际上是对需求的代码化,这个代码将需求严格的执行,不会走样,这样就有力的保障了先前的业务的准确性,开发同学代码修改的就有信心

理论上单元测试就是我们自己编写的预编译器,提高开发人员效率

第二:预编译错误,事务错误
预编译错误,什么添加字段,基本上通过上面这两个,针对新添加的功能,基本测试通过,生产通过的概率很高,上生产测试一下,就可以上线,但是对于修改需求,就难以替代单元测试的地位

第三:严格的命名规范
使用NHibernate对象命名后,使用I Service DAO 等前后缀,就严格的组织起了代码,所以重点还在ER图上,ER图的命名规范必须做到严格,否则一个不够清晰准确的命名,后面的开发的代码都是这个词不达意的名称,程序跑起来没有问题,开发同学就强迫自己学了一个不相干的密码单词,自己知道这个项目中的意思,项目基本走入密码学的范畴

由于Sping切面 有严格的命名限制 可以设置为只能使用Save Update Delete Select为起始名称,这样在读彼此对方的代码的时候能够很容易理解,实现约定规则

经过以上一个月的流程打通,这时候依然是一个星期一次交流会议,交流的内容越来越接近项目应该的样子,这个时候也会产生很多细节问题,就是抉择一些问题,这个时候一定要冷静思考,虽然有很多建议,但是做决定的还是负责人自己,所以要权衡利弊,抓住重点,有些项目就是因为一个重要的点无法解决,而使项目出现鸡肋现象

这里要说明一下,有一种关系设计是这样的,就是将所有的关系都设计成多对多,然后将给开发者在程序中控制关系,这种成本是巨大的,虽然购买的PLM都是这种设计,但是这也是通用PLM的必然选择,可以任意组装是对这个系统的要求,

但是定制化系统,可以避开这个问题,因为一个多对多对于开发人员造成的工作量是成倍的增长,各种业务都要编写大量的维护代码,因此在绘制ER图的时候避免多对多,如果必须多对多必须与业务同学开发同学三方确认,认为必须为多对多的关系,才能设置为多对多

项目的整个过程中,主外键,事务,日志一直在保障着系统的运转,从开发效果上看,使用这种开发方式基本上都是三个月软件基本定型上线

以上项目过程都是层层推进,每次都是小步快挪,就像画画,先打底稿,勾出轮廓,绘出结构,最后再重彩浓墨刻画细节,

项目同此理,开发那么高成本的事情,一定要前期规划好,才能事半功倍.

以上内容项目总结,希望能对大家有所帮助,若有错误,敬请指正