最新做一个项目的体验

以往我们做个项目,比如工期是两个月, 一般是上线前一星期UAT(给业务用),再前4天要ZBB,给测试做回归,再前4天要CC.这就去了13天,两个月也就47,8天工作,还要开些个会,讨论个需求,搭个环境,也就是说,两个月的工期其实也就一个月.

然后我们怎样呢,CC时间赶个超垃圾的版本上去,全是BUG,应该说这不是BUG,是根本没有作完,让测试把没有做完的东西当BUG提,然后在一段时间里面了完成没有完成的东西,bug一个不看,然后又集中力量解bug,这时我们对需求提出的变更一般都不允理采.然后再上线前两天,才把bug解完.需求不是很满意,我们的各项指标都不好看,bug多,open多.

 

好,我们换个简单的项目,工期也是两个月,我一个月就CC了,并且没BUG,那我后半个月是不是可以玩了.

 

有时候,我们面临一些实效性很强的项目,这些项目如果不能在规定的时间内开发完成,就没有意义了,我们可以功能少点,带bug,但一定要在规定时间内上个可用的版本.

这时候,就要求我们快速开发,并且为了不让人有种努力干活KPI的指数却很低,我们要有新的标准和流程去控制这个项目.

 

我们的手段是,扫清障碍,保证方向,多核运作.

我们的终极目标是,头天开发完,第二天就上线.

我们的态度是,做一个好产品,而不是完成项目.

 

扫清障障碍,首先相关人士都要坐在一起,美工,程序员,需求,测试.扫清距离和沟通障碍.

测试在程序的骨架没有搭出来之前,可以不加入,在程序做出一个基本可用版本后,加入.

 

进度的最大关键人物在开发,开发只管写代码,其它的事情啥也别干.

不用参加与项目无关或与开发无关的任何会议,工作总结,项目管理软件,bug测试可以自开自关.

是的,我们把程序员当爷供起来了,程序员只要做好开发就起了,其实一切都不用分心.

必须有独立的代码分支,独立的测试环境,总之不能让其它因素,其它项目影响开发进度.

 

需求和产品经理,项目经理应是一个人,这个人提需求,监控进度.我们可以根据现在的情况,改变计划.

很多领导一开始都要求细分工时,可是很多程序员都喜欢看着做.因为有时候,我们确实要花很多精力去细分一个项目,所以我们可以把项目分成几个关键因素,如

基本流程能通,关键场景数据要对,主要交互,周边功能.

我们什么时候完成基本流程能通,这时测试参于进来,有问题记录下来,并和开发说,开发说搞定了,测试就可以测.

在主要交互完成后,就可以进行UAT,最好上线,让一些业务人员去用,最早拿到最终用户的态度,发现关键性,重大问题.说白了就是让业务当测试,拿生产环境当测试环境.是这保证方向

测试实时回归测试,了解开发解bug和设计程序的思路,为了实现改完一个bug,看看会不会影响其它地方

如果是程序是新老组合,那老员工一定要了解新员工的开发思路,必免出错.这也是保证方向.

 

在任务派发和迭代方面,分三步计划,1,保证系统的可用性,2.项目的竞争力,创新点 3.功能全面实现

在做完竞争力的时候,就要上线测试,拿到终端客户的一手反馈,和爆露重大缺陷.

开发.美工,需求,测试都并行高速动作起来,扫清一切障碍,确保走直线,这是我觉得实现快速开发的基本思路