我想,做软件开发最害怕的就是需求变动。好不容易完成一个功能,客户看了,随便动动嘴,就要让你修改这里修改那里,在他眼中看似很简单的一个改动,其实要做不少的工作量。如果从商务角度去拒绝,不重要的改动确实可以拒绝,但客户难缠或者业务必须要达到的功能,也不得不去改。这时候,增加了工作量且不说,最重要的,感觉心里烦躁。本来自己心满意足的完成了一个任务,没得到一个崇拜的眼神和诚心的赞扬,结果不仅没表扬反而被别人挑刺。这心理落差是极大的。
或者说,接了一个项目后,只有一个模糊的功能,实际上细节不清楚,心里没有清晰的轮廓,那么也会让人心烦,不知道从什么地方下手
这两种经历,我都遇到过,而且让我受了不小的打击。
经过多个项目后,我发现快速原型法和重构是最有效的开发模式,当然我做的都是小型项目,这种方式适合小项目
快速原型在百度百科定义:快速原型模型需要迅速建造一个可以运行的软件原型 ,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。
我认为快速原型模型的本质是,快速搞清软件到底应该实现什么功能,客户实际需求到底是什么。这包括两方面,一是软件开发者搞清楚,二是客户自己清楚需要什么功能,因为有时客户自己也不清楚实际需求,或者当初考虑不全面,导致后来要求修改这里修改那里。而快速原型法,潜台词就是告诉客户,你有什么功能赶快告诉我,别到最后说这说那。
敏捷开发的作者说,不要害怕需求变化,要拥抱变化。说实话,刚开始看到作者说这句话,感觉作者站着说话不腰疼。我是很不喜欢变化,我喜欢做最简单的事情,就可以赚钱,比如说,一个客户要求做一个串口数据采集显示的软件,那我直接做了给他,只要可以采集数据并且显示出来,那么他就付钱,我不喜欢啰嗦。可实际上,没这样的好事,客户往往会改变一些需求,比如改变一下按钮的位置、显示的颜色字体、增加实时曲线等等。我最讨厌当我觉得软件完成的时候,客户再提这样的需求变化。这样让我心情很不好。
所以当我遇到这些实际问题的时候,开始尝试用敏捷开发的思维对待客户,先用最短的时间最省力气的办法给客户一个可以使用的简陋(或者说丑陋)的软件,发给客户后,自己就坐在办公室喝咖啡,qq上泡mm,耐心的等待客户反馈。然后第二天客户反馈,并且询问客户,为什么这样?结果这样效果很好,让我少走了很多弯路。
快速原型法另外一个内涵是,不做无用功或者少做无用功,不做或少做客户不需要的功能。
这类似工业控制的PID调节方法。不断根据反馈,实时调节输出,以达到最佳效果
第一次写博文,不知道把我对快速原型法的理解说明白说清楚没有。