分享

敏捷开发项目之系统设计问题

 天葬之下于星空 2017-07-29

敏捷管理目标:更高质量的软件产品,更快更低成本满足用户需求。

高质量:测试驱动,结对编程等

更效率:小版本、快迭代等

低成本:通过避免大项目周期长走湾路、试错快速完善产品

传统瀑布开发模型流程如下:

敏捷开发过程其实也会经过这几个过程,但更强调小版本、快迭代。

这里所要讨论的是敏捷开发过程中,要不要做设计的问题讨论。

设计包括:概要设计、详细设计

我见过不少的项目,在需求完成之后,便进入开发。而设计也只仅仅是开发人员之间讨论大概的实现流程、结构,没有任何设计文档。

似乎设计显得多余,因为没有设计过程,功能也一样开发出来,最终也能上线,交付使用。

至于不需要设计的观点,可以归纳几个方面:

1,需求文档已足够;

2,设计需要时间,敏捷开发就是要试错,及早发现问题并修正;

3,测试驱动,以保证质量;

4,开发人员的讨论就是设计;

敏捷真是个好东西,去到随便一个项目,它都能说是敏捷开发。

不懂的领导可能会问什么是敏捷开发,敏捷就是快速开发,快速适应市场,不断试错。

是啊,不断试错。敏捷真是个追责的好挡手,而且理所当然。出了质量问题,自然心安理得推到试错上。

是不是为了追求效率,不断试错,就可以不用做设计?

首先,来看看哪些情况可以不需要设计:

1、单一简单功能

2、能力较高的开发人员,可以自己设计自己开发

简而言之,就是开发人员能一撸清晰,没有障碍,没有盲点的,都可以直接进入开发;

反之,则建议做好设计。

假如省略必要的设计,需求完成之后即进入开发,会可能出现什么问题?

1、需求文档不能反映系统细节,需要来回沟通;

2、不能从整个系统角度最优化的考虑,开发人员往往只考虑自己负责那部分功能,加上能力差异,实现方法也不同;

3、开发人员之间接口设计定义需要不断讨论,不能从更高层次去定义,加上能力差异,定义标准千差万别;

4、开发人员都只知道自己那部分,缺乏对整体的了解,等联调测试才发现不通或者其它欠考虑问题;

5、开发人员基本会参照需求文档开发,不会考虑需求合理性;

6、测试人员参照需求文档列举测试用例,而开发改动范围可能大于需求范围,造成测试用例不全面;

总之,清晰的设计能给人耳目一新,豁然开朗的感觉;能减少上述的问题。

好的设计,能提高效率,降低成本,结构清晰,开发人员抱怨少,而且能预知问题风险。

在时间上并不一定比不需要设计的模式多;相反可能会只需要更少的时间。

如果要做设计,则要做到什么程度?

设计太细,则投入时间成本过高;

设计太粗,则不利于开发人员开发;

所以,设计粒度还是以开发人员能够掌握、开发为准。

特别是对于功能、系统之间协同开发,设计人员提前介入,画好流程图、时序图;则对于后面的任务拆分、评估大大提高效率。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多