再谈敏捷和架构

  对于敏捷前面谈的很多,其核心仍然是短周期迭代交付,可视化,自适应调整,开放式及时沟通,所有的敏捷实践基本都是围绕这些核心展开,如果再要对敏捷的核心抽象就是迭代+自适应。

  周末和我一个师兄聊天,觉得在原公司实施敏捷后确实带来了很多的变化。原来可能大家都说很忙,确实是否真的很忙不清楚,原来一个任务来了来安排不下去,原来客户要的东西迟迟交付不了,或者是交付后就陷入到持续的变更。实施敏捷后这些问题都得到了一定的程度的改善,这么好的东西怎么原来没有引入进来,在cmmi上浪费了这么多的时间。

  其实我个人理解原来的过程改进和cmmi一点都没有浪费时间,就像原来我们经常说瀑布都做不好如何去做好RUP软件过程?基本的cmmi过程都做不好如何去做好敏捷?做任何事情我们都必须经历的阶段是简单-》复杂->简单的过程,只有经历过了复杂你才知道如何来简化,如何来吸取精华去除糟粕。CMMI里面确实很多过程都比较重,但是很多的核心过程思想必须要有,只是用更加敏捷的方法来实现这些思想。

  公司实施敏捷,开始使用user story card,这是很好的,但是我们要注意到product backlog和sprintbacklog绝对不仅仅是user story。很多人任务敏捷抛弃了文档,而实际上敏捷只是浓缩了文档,backlog中有userstory,有详细的业务场景描述,有优先级,有规模和工作量估计,有类型,有如何演示,如何实现,如何测试等各种内容。这些内容可以看到一直从需求覆盖到设计和实现和测试。这可以说是敏捷里面最重要的一份文档,而且这份文档是完全可以结构化的文档,结构化的条目就是userstory,用户故事是最开始的最小粒度单元,关于用户故事的需求,设计和测试所有内容都在这里,体现方式最简单就是excel,这个东西太好了,你这样做你发现原来cmmi需求管理中要做的需求追踪没必要了,这个excel文档本身就实现了需求追踪。单独的测试用例文档好像也没有必要了,需求文档也不要了,而且需求比原来的描述方式更好,体现了业务场景站在用户视角,没必要还要像原来搞个用户需求文档+软件需求文档,项目管理的复杂文档也可以不要了,就在这里估算安排人员,确定时间。所以可以看到浓缩的都是精华。

  再回过头看来,架构到哪里去了?backlog里面能否体现架构的核心内容?我个人的答案是不能的,仍然沿用《人月神话》里面观点的话,架构需要保证高度的概念完整性,否则谈不上架构。backlog里面的如何实现好像体现了部分架构的内容,让我们感觉架构也是可以迭代的,渐进式的,这个观点没有错,但是这个只能算做是低层级的概要设计,高层的架构还是没有。所以我原来一直强调了一个思路,对于变更型和增量版本型的项目特别适合用scrum,而对于全新的项目根据适合RUP的思路,体现用例驱动和架构为核心,在迭代版本规划出来后再考虑敏捷的思路。

  在岗位细分后,软件开发里面分出了独立的需求分析师和架构设计师岗位,大家可以回想下原来没有细分前,这两个岗位其实和合并为一个的,即原来的系统分析员。这其实是实施敏捷后我们需要做的一个回归,重新会产生类似系统分析员角色,系统分析员负责需求和高层架构。低层的一些架构下沉到sprintbacklog的每一个迭代里面来做。高层架构做的内容包括全局用例分析,全局数据视图,集成视图和接口交付,其控制的边界在于这些内容是否跨越了多个迭代版本,这好比一个数据实体设计,如果是在某一个迭代版本内部体内循环则不一定要在高层架构设计,但是如何是涉及到多个迭代版本使用则需要在高层架构识别和设计。对于全新的产品研发,高层架构不稳定,直接导致不断迭代加入进来的内容结构混乱,这个问题必须要重视和考虑。

  很多时候我们都在想,我现在新研发一个产品,原来公司类似的一个产品已经用过这个架构了,或者说公司已经有相应的技术平台,所以架构工作没有必要了。注意我们通常说的产品平台或技术平台,SSH框架等都是框架,是架构中非功能性架构的内容。而实际根据产品需求或用户需求过来,考虑的子系统,模块组件规划等是功能性架构的内容,不要以为有了平台或框架就没有架构的内容了。

  通过前面分析,敏捷下架构能否迭代的问题就比较清楚了。对于不属于高层架构的内容是可以迭代的,到了每一个迭代版本中再来做架构,对于高层架构的内容一般不能迭代以保证设计的概念完整性。对于高层架构本身,整个设计和方案思路是不能迭代的,但是实现过程本身是可以迭代的,如同一个接口,设计必须体现做,这个做了接口本身的实现可以和其它功能模块的开发并行。

it知识库再谈敏捷和架构,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。