再谈敏捷和架构

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

　　周末和我一个师兄聊天，觉得在原公司实施敏捷后确实带来了很多的变化。原来可能大家都说很忙，确实是否真的很忙不清楚，原来一个任务来了来安排不下去，原来客户要的东西迟迟交付不了，或者是交付后就陷入到持续的变更。实施敏捷后这些问题都得到了一定的程度的改善，这么好的东西怎么原来没有引入进来，在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框架等都是框架，是架构中非功能性架构的内容。而实际根据产品需求或用户需求过来，考虑的子系统，模块组件规划等是功能性架构的内容，不要以为有了平台或框架就没有架构的内容了。

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