转载:
做程序2年多了,相比大牛来说,时间不长!
做一个小小的总结!
问题现状,
目前国内很多软件公司还是处于小作坊式的工作模式!
接到个项目,大家凑一起商议下怎么做,老大拍板决定后,大家分头行动!
于是一个项目开始了,前期大家忙的不亦乐乎!
每个人都有自己的工作, (有的公司分配不均的,如果有闲着的人说明管理有问题)
有的干脆就是一个人接管一个项目!
随着时间的改变,代码越来越多,bug也越来越多,更要命的客户说得加个功能,更更要命的是客户说功能得改!
一个人接项目的到了后期基本上就撑不住了.加班能搞定就是烧香拜佛了!结果就是项目失败.钱收不到.
团队接的,后期基本上是加班不断!牢骚一大片啊! 结果基本上是钱能收到或者只能收到一部分,客户牢骚不断!
如果你的公司有以上现象的,说明你的公司需要change
哪里需要change? 开发流程需要change
跟各位看官讨论个问题,
到底是什么决定了软件项目的成功或失败,又是什么决定了软件的质量?
下面的先别看,自己先想一下,待会再看,看看是不是和我想的一样!
我前几天看软件考试大纲中共分3个高级的级别
分别是项目管理.系统分析师,软件构架师
看到这里我豁然开朗,原来国家大纲的划分是有道理的,我以前一直不认为it证书有什么用.(现在看也还是没啥用,背背书就会的东西,做起来大眼瞪小眼)
说下我的看法,
项目管理者决定了软件项目的按时完成, 项目管理者负责软件开发任务的分包安排,物资和人力调度,等等一切资源的调配,目的只有一个,按计划完成项目!
系统分析师应该是第一个接手项目的人,这个人很重要,重要到直接决定了这个项目的成败.如果系统分析师分析错误,分析出了一个不正确的需求.结果....
系统分析师的要求比较高,程序可以不写,但是最起码知道有哪些方案,知道软件怎么实现. 系统分析师有点看似重要却又是个程序员都能干的职位!
但是有几点要求是程序员做不到的
第一,沟通能力应该非常非常的好,不然怎么和客户沟通?
第二,有点程序经验,能总结出实际需求!挖掘出真实需求,避免需求偏离! 如果这一点做不到,还不如不要系统分析师!
第三,亲和力或者领导力还有说服力比较高!
项目通过系统分析师分析后要确定哪些东西呢?
第一,系统要实现哪些功能. (确定后要客户签字,增加或者变更需求是要收费的!!^V^)
第二,每个功能的重要次序
第三,每个功能实现的意义
第四,每个功能的详细说明.说清楚是这样的而不是那样的?最重要的是说明不是那样的!
第五,用例图(UML中的第一种图)确定
第六,软件价格基本上确定个差不多了.
第七,分析系统可能会变的地方,还有"必定会变"的地方(把变更扼杀在系统分析阶段.一个好的系统分析员应该能够分析出哪些需求会变)
第八,砍掉不合理或者不重要的需求.
到现在为止我们的项目要不要接已经能确定了.多少钱也确定个差不多了!
需求还不确定,千万不要报价.否则只有赔本!
建议项目确定后先让客户交一点需求分析费,系统分析出来后,自己报价方便,客户付钱放心!
系统分析师和客户的交流应该建立在用例图上,用例图本来就是给客户看的.
说到这里,各位要注意了,不要小看用例图,一定要保存好哦,后面每个人都用得到!
客户看到用例图也愿意付钱,嘴巴说的过会就忘了!俗话说空口无凭,白纸黑字的才放心!
下面的工作重点转到软件构架师了
软件构架师做什么呢?
确定采用技术框架,环境,系统框架等等.
软件构架师需要作出那些东西呢?
第一,系统总体的说明,1页word文档够了,多了嫌烦.
第二,系统的运行环境和硬件设备,网络环境
第三,系统的总体架构和部署方案,(比如:MVC结构,5层结构,代理结构...)
第四,系统详细设计方案.分解技术实现方法.
第五,系统数据格式示例, 各功能模块之间或各层次之间的接口,通讯数据格式
//这一步是为了方便程序同步开发和分发,而且缩小了技术范围,降低了程序的耦合度, 测试人员可以根据这些接口和数据格式写单元测试. 当然增加了系统的集成问题
第六,如果遇到特别辣手的技术问题还需要让大家明白解决方法!
这里要说明一点,无论是用"文档" 还是用 "图" 或者"会议录像",只要构架师的概念能够让组员能够全部理解吸收就算达到目的,考虑到以后维护方便和程序员通常不会写文档和画图 还是会议录像比较容易接受. 会议录像不必每次都录, 构架师在不能确定技术方案时肯定是要和其它程序员探讨的.这个不需要录 . 只需要记录构架师决定方案后向大家宣布决定的会议
下面的工作重点转到项目管理者了,下面的步骤才应该算是瀑布模型或者敏捷开发的起点.
传统的将瀑布模型将前面的需求分析放进瀑布中是不合理的
项目管理者在接手到这个项目后,该做什么呢?
第一,配置资源,包括硬件,人力,财力,物力.还有客户资源.
第二,划分模块,模块分解,分包.分清初次,指定开发任务时间表 //建议采用敏捷模型安排进度表,每周|月提交一次产品,时间太长不好.太短也不好
第三,将合适的模块分给合适的员工,技术无法达到时,需要聘请技术高手做技术指导,
//这里要说明一下, 如果项目技术问题比较辣手应该提前考虑聘请专业技术指导员.以作决策.而且技术指导员可以抵抗技术风险. 技术指导员是把好的阻击枪,但不是万能的,不要把技术员当冲锋枪用!技术员是用来配合的!用来解决技术难题的!另外还可以帮助软件构架师做决策,做产品创新!
说到这里,各位实习生可能要喝彩了,自己不会也可以的啊!是的,按照这种流程下去的话,即时不会的话,也有人做技术指导. 新手得到锻炼,产品得以开发,质量得到保证.我们目前的情况是要求每个程序员都是高手,岂不知这样是有问题的,高手要写代码的话,思绪很专一不好打扰的. 每个人都是高手,每个人都有自己的一套方案!结果就是俩字 ----混乱. 新手有新手的好处. 老手有老手的好处! 新手是冲锋枪, 老手是狙击枪! 各有各的用途!
安排错了就看运气了!
第四,合理安排测试时间,发布时间.
第五,管理好项目文件,项目资源. 包括源代码,源代码数据库,数据库,硬件,网络,操作系统,文件,运行环境,与系统相关的各种资源理论上应该都做备份!
第六, 给各位员工-->端茶倒水. ^V^
下面这个项目到了实际开发阶段,
这一步大家都在做不用我说怎么做了吧?
咳!咳!
我还要罗嗦两句
从设计师哪里拿来的接口和数据格式,还有需求 只能模糊的告诉我们要做成什么样!
不能明确的告诉我们需要几个按钮,需要什么控件.需要什么样的界面. 采用树形控件还是下拉列表,这些是需要每个程序员决定的!
根据我的经验,在开始写程序之前先画个界面,或者先写个测试程序,将会有效的提高你的开发速度!降低程序开发失误率!
而先画界面的好处是可以把界面设计专门独立出去由专业的用户体验设计者来设计界面. 软件的用户评价将会大大提高!
到了这里大家应该会豁然开朗了吧,原来测试驱动开发是在这里用的,用户体验设计也是在这里用的!
根据项目管理者的安排,每周|月发布一次产品.(敏捷开发模式)敏捷模式有啥好处? 我就不说了,太多了.!^V^
经过一段时间后,项目逐步得到完善!
OK当所有主要的功能完成时,一个里程碑完成了.项目经理过来备份下
主要功能完成后,不要急于开发剩下的,先停一停,走的太快容易跌倒.
开开反省大会.写一下说明文档,先让用户测试一下,发现bug及时修改.
该重构的及时重构.该删除的及时删除!该patch的patch
用户极度不满意的话,损失也小一点.
或者重来或者放弃!
发现需求变更的时候,大家的砖头一直朝向系统分析师,不敢的话拍自己吧!
发现代码大部分只是Copy 的时候,大家赶紧停下,砖头拍向软件构架师,现在不拍到时候拍的是自己!
发现数据库连不上了,网络不通了,键盘坏了,没茶没水了...大声呼叫"管理员"
如果被客户发现了你的bug,就是老板拍你的时候了!
