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