敏捷管理目标:更高质量的软件产品,更快更低成本满足用户需求。
高质量:测试驱动,结对编程等
更效率:小版本、快迭代等
低成本:通过避免大项目周期长走湾路、试错快速完善产品
传统瀑布开发模型流程如下:
敏捷开发过程其实也会经过这几个过程,但更强调小版本、快迭代。
这里所要讨论的是敏捷开发过程中,要不要做设计的问题讨论。
设计包括:概要设计、详细设计
我见过不少的项目,在需求完成之后,便进入开发。而设计也只仅仅是开发人员之间讨论大概的实现流程、结构,没有任何设计文档。
似乎设计显得多余,因为没有设计过程,功能也一样开发出来,最终也能上线,交付使用。
至于不需要设计的观点,可以归纳几个方面:
1,需求文档已足够;
2,设计需要时间,敏捷开发就是要试错,及早发现问题并修正;
3,测试驱动,以保证质量;
4,开发人员的讨论就是设计;
敏捷真是个好东西,去到随便一个项目,它都能说是敏捷开发。
不懂的领导可能会问什么是敏捷开发,敏捷就是快速开发,快速适应市场,不断试错。
是啊,不断试错。敏捷真是个追责的好挡手,而且理所当然。出了质量问题,自然心安理得推到试错上。
是不是为了追求效率,不断试错,就可以不用做设计?
首先,来看看哪些情况可以不需要设计:
1、单一简单功能
2、能力较高的开发人员,可以自己设计自己开发
简而言之,就是开发人员能一撸清晰,没有障碍,没有盲点的,都可以直接进入开发;
反之,则建议做好设计。
假如省略必要的设计,需求完成之后即进入开发,会可能出现什么问题?
1、需求文档不能反映系统细节,需要来回沟通;
2、不能从整个系统角度最优化的考虑,开发人员往往只考虑自己负责那部分功能,加上能力差异,实现方法也不同;
3、开发人员之间接口设计定义需要不断讨论,不能从更高层次去定义,加上能力差异,定义标准千差万别;
4、开发人员都只知道自己那部分,缺乏对整体的了解,等联调测试才发现不通或者其它欠考虑问题;
5、开发人员基本会参照需求文档开发,不会考虑需求合理性;
6、测试人员参照需求文档列举测试用例,而开发改动范围可能大于需求范围,造成测试用例不全面;
总之,清晰的设计能给人耳目一新,豁然开朗的感觉;能减少上述的问题。
好的设计,能提高效率,降低成本,结构清晰,开发人员抱怨少,而且能预知问题风险。
在时间上并不一定比不需要设计的模式多;相反可能会只需要更少的时间。
如果要做设计,则要做到什么程度?
设计太细,则投入时间成本过高;
设计太粗,则不利于开发人员开发;
所以,设计粒度还是以开发人员能够掌握、开发为准。
特别是对于功能、系统之间协同开发,设计人员提前介入,画好流程图、时序图;则对于后面的任务拆分、评估大大提高效率。
联系客服