一年之前我们公司的项目一般都是一两个人来完成的.完成的质量总是不太理想,很多时候完成后才现发有这样那样的问题.严重影响项目的进度和部门形象.新的方法实行了差不多一年了,效果非常理想.
大概说一说我们之前的开发流程,首先会有其他的部门负责人找到我或者我的上头阿生,我们两个会根据用户的需求写一份详细的说明文档,然后根据需求文档设计数据库.完成这两件工作后会把需求文档给我们的同事,然后两三个人简单讨论一下就开始真正的编码工作了.
其实很多时候编码的同事的理解可能跟你的想法有出入,同一份文档可能会有两种不同的理解.最后出来的效果,那真是哭笑不得啊!
一年前我们发现这个问题越来越来严重了,于是我们引入了敏捷开发,项目团队人員由一两个人一组变成五六个人一组.
在项目的最初阶段,跟用户讨论问题的时候就会把相关的同事一起叫过来听(注意,这个阶段主要以听为主),了解完需求后,我们内部组别再一起讨论确定最终的需求文档(这样做的好处是在这个阶段用户的需求,参加开发的同事也已经非常清楚了,不需要项目负责人再讲解一次.).
然后我们会进入系统分析阶段,这时界面设计人員也会加入,这一个阶段我们会把用户需要的数据,采用的什么技术,页面的大概框架都会进行详细的讨论.团队的人員在这一个阶段会非常活跃,这一阶段要花费大量的时间讨论,有时候一次不够,需要第二次,第三次,第N次再开会讨论,直到团队的所有同事都非常清楚为止.(关键部分)
讨论完成后,会将项目分成很多个非常小的阶段,每个小阶段有一些功能组合列表,我们团队使用的是自己认领的方式,让团队的成員自由选择自己有兴趣的功能组合并写上大概的完成日期.最后定下一次的会议的时间,一般是每一个小阶段结束的时间(当然并不是每个小阶段都必须开会).每次会议的间隔时间不定,一般为1-3天.
访方法实行半年多以来,效果非常理想!由于参与人数增多,每个人員开发的代码都要互相调用,代码的规范,可复用性,效率都得到了很大的提升.由于采用认领的方式,积极性和责任心都大大提高(因为你的功能没有完成会影响到整个项目的进度,你的功能做得不好也会影响整个项目,程序員都是这样,压力越大,做出来的东西也越好).
各位大虾对此有什么看法,或者还可以改进的地方,欢迎留言我!