关于敏捷的一些想法

年底做年会总结，讨论考核指标，谈到敏捷开发，谈到写设计文档。其实有的团队已经做到按周发布，而且持续了好长一段时间，年后计划开始按天发布了；另一方面，还有的团队两周还出不来东西。因此，敏捷，还是值得考虑一下。

其实敏捷这个东西，已经谈了好几个年头了。但是在实践当中感觉常常让人误解，以至于：天天都有做站会，但是速度不见的有提升；文档也不写了，遇到问题没人知道怎么回事；设计也没有了，于是质量上也不去，BUG很多。有感与此，说一些自己的体会。

一、为什么要敏捷

其实也不大清楚从什么时候开始，大家开始说敏捷了。大概也就是做IT的人感觉到自己的压力太大，想找一种方法为自己减压吧。

IT屌丝的压力来自什么地方？就是天天需求变化，但是老板天天要求有东西交差。最典型的场景就是，老板心里只有一个想法，还不懂要做成什么样的，只不过想弄点东西出来看看市场的反馈而已。

聪明的程序员就想跟老板说:OK，我满足你的需求，但是，你要按我的规则来玩，这个规则就是敏捷。(什么，你不敢说？这个只能问你怎么经营你的老板了。)

好了，敏捷出来了，它的目标就是加快交付，把软件产品推到用户手里。在互联网的世界里，这个变得尤为重要，因为能否做到第一，意味着你的公司是否能活下来。

二、什么是敏捷

说到敏捷，大名鼎鼎的《敏捷宣言》大家应该都读过了。好吧，很多人说，敏捷不要文档，大概都出自这里吧。哈哈，把人家最重要的：要交付，也要质量都忘记了。只记得，要站会了。

其实，敏捷目标是交付，是质量。所以，敏捷应当是一切在交付，在质量的基础上，加速软件开发的方法和过程。

那么是不是什么东西都适合敏捷呢？这个不一定了，比如，你做的是项目型的应用，跟人家签了单，要写合同，这时需要拿文档，把需求一次性谈清楚，到期一次性交付的。这时就要考虑一下是否合适了。当然不排除可以借鉴这个理念做过程改进。

三、怎么做敏捷

做敏捷是一个系统的方法论，涉及软件开发的整个周期。认识有限，先说说自己的看法吧。

1.公司组织架构

说到这个，不得不提一下公司的站略，敏捷向来应当至上而下展开的。任何从开发者着手的敏捷，都是想法折磨IT屌丝。看到太多这样的例子了，为了赶工，天天加班；需求经常变，代码一团糟。

现代化的组织结构，都是讲究扁平化的（这方面没什么研究，只能讲个大概^_^）。大概是这样：



CTO下面直接管理若干项目，项目下面直接过成员。所有的项目，除了项目经理、技术经理是固定的外，开发人员是流动的，可以自由的选择项目组。如果项目紧张的时候，可以从别的项目流入新的开发人员；如果项目维护的时候，可以把空闲的资源流动出去。由于组织扁平，上下级之间的沟通顺畅，提高组织的效率。

当然，这样做的好处还有：极大的利用了现有的开发资源；对于程序员来说，有不同项目的开发经历，丰富了自己的人生简历；对于项目经理、技术经理来说，就是不断的深入自己的专业领域。这样做也带来了管理上的难度，对于管理团队来说是一个严峻的考验。

2.软件需求

说到软件需求，不得不得一下MVP(Minimum Viable Product)：你的需求是用户最想要的，最能体现你的产品价值的东西。

经常看到这样一个例子，产品经理（或者产品团队）一次性的拿出非常完整的产品方案，要求开发团队开发。本来设计出来的东西就很复杂，但是在过程中，产品经理觉得设计不够完善，于是不断的变更、叠加需求，更糟糕是还不让开发团队变更发布时间。

其实，需求是需要管理和控制的，这个控制的方法就是寻找MVP，做原型来验证。然后，把产品的需求排优先级，通常一个版本内实现优先级为高的东西，沟通优先级为中的东西，忽略优先级为低的东西。然后，有些特别的情况是产品经理还没想好产品应该是什么样的，只是一个心中的构想，那么这时候就要一个预研型的团队，专门跟着产品经理，把他的构建做好，然后再进入产品的开发流程。

也许很多人说，开发不完怎么办？一般来说，要做到按周发布，本周要发布的需要是两周前就已经确认好了，本周要开发的东西上周就已经完成设计了。

还有人说，产品经理的需求一直变怎么办？如果没有特别的情况，是不让进入开发周期的需求进行变更的。如果产品经理经常性的临时变更需求，这就要做需求管控了。如果管控不了，只能出绝招：“你来！”。当然，对于预研性的项目，不能这么来啦。这时产品只是看看效果，不算正式产品，不做质量控制。

3.软件架构

谈到软件架构，当IT屌丝这么多年，经历了之前的模块化、分层化，到后来的SOA，以及现在的微服务。呵呵，其实对于软件架构，还是从需求出发，能够满足当前产品的需求就好。之所以大概这么折腾架构这东西，主要还是因为需求变化的太快了，有点招架不住吧。

在互联网的应用中，动不动就是改需求，动不动就是性能问题，动不动就是要发布（交付）。一个产品，视产品的大小，能一个月完成一个开发周期就不错了。要加快开发周期，可以把不同的需求放在不同的模块中开发，并行做，速度就快起来了吧。但是分模块的做法，最后产品集成的时候，可能出现构建失败什么的情况，还有再折腾一下代码。好吧，就把每个模块单独拆成小小的应用，独立运行。各个模块间通过REST风格的接口做通信，这样连部署也独立了，定好接口后，发布时也可以不要再去折腾代码了。快起来了吧，因为应用是独立的，而且很小（通过1到2个人就能维护起来），这样这些应用就可以很快，每周一次是没问题的。

关于微服务，其实涉及的东西很多：应用多，怎么管理？团队怎么管理？应用怎么拆分？应用怎么运维？哈哈，团队的管理就是参考上面说的扁平化了，应用的拆分，可以看下面关于软件设计的内容。应用怎么运维，这时候，就要谈到DevOps：“You Build it，You Run it”。为了辅助开发者运维应用，这时候的运维不再只是帮忙安装一下软件什么的了，需要上一套的构建工具、部署工具、监控工具、及部分的自动化运维工具：开发者通过这些的工具，可以很方法的构建应用、发布应用、查看应用的运行状态；访问出错了，开发者可以很方便的查到运行日志，定位异常原因；用户访问量上来了，应用会自动的扩展运行实现；等等。

4.软件设计

这时用UDD是可能不怎么适合了，DDD或者TDD可能很适合你。我们面临的环境是不断迭代的开发，不断变更的需求。我们要考虑的是如何尽可能的复用之前的服务，代码，测试等等开发资源。

做完需求分析，很自然的我们就得到一个业务模型。然后，对这份的业务模型进行归类、分层次，就得到了份面向该业务需求的初始化模型，即完成了一个最简单的领域驱动设计的过程。每个类别、每个层次的业务模型都可以把它归为了个子系统（应用）进行深入的讨论，就得到了一批的小应用列表。

随着需求的不断变更，开始整理我们的设计模型，不断的完善、不断的抽象。就可以用相对简单、统一的方式把业务的需求都描述出来、描绘完整。呵呵，想法是丰满的，现实是骨感的：需求的不断变更，BUG不断怎么办？上单元测试呀！把所有的接口、重点的算法、关键的步骤，都上用单元测试。每次的修改都要确保单元测试全部通过：放心内部实现改了，但对外的质量还是刚刚的。

5.关于编码

哦，每个应用就1、2个人开发了，人走了，怎么办？这就希望我们的代码能够保持相对统一的规范以及良好编码风格。此外，架构、设计应该要对其所设计的应用的代码负责：Code Review，这是少不了的。哈哈，Git、Gerrit还是不错的组合。

四、一些体会

1.要不要写文档

文档是要写的，但是可以少写。其实，按上述的过程下来，应用多了，需求是什么？它们间有什么关系？人走了，怎么接？这都要靠文档呀。当然，也不是都要按国字头的需求、设计文档来写啦，比如对于设计文档，要写清楚：

背景

说明设计的需求、目标。不要是一句话，要说明清楚场景是什么，做这东西有什么意义。

设计

总体结构

模型类

序列图

性能

日志

异常

接口

2.关于按周发布，按天发布

其实按周发布，按天发布，并不是针对每个应用讲的，是针对每个产品讲的。如果一个产品有10个应用，每个应用能两周发布一次。那么恭喜你，你的产品可以做到每天都有1个发布的。^_^

有的人说，这有点假。但是现实是，对于这个产品来说，每次的发布（无论是底下那个应用），都意味着增加了某个特性、或者修改了某个BUG，对于产品都是向前走一步的。如果需求控制的好，可能向产品经理的要求又前进了一步。

3.关于人

其实，这么下面，感觉当负责人的压力好大。公司的高层，要管理好整个组织；产品经理，要想好产品的高点；项目经理，要分解好新产品需求；架构师，要做好产品的构架、设计；开发人员，要编码、还要写单元测试。一个系列下来，好像那个环节出错了，后面的都会出问题。有对人的要求好高呀。

其实，敏捷，也就是这样。^_^，要保证质量，要保证可持续，也要保证速度。

四，总结

软件是一个开发过程：需求、设计、开发、发布、维护。没有敏捷前，它是这样，有了敏捷后，它还是这样。敏捷只是一个手段，不是目标。软件的系统是迭代而来，软件的产品是演进而来的，对于软件的过程，还是看看自己的目标，如何能满足软件的需求，怎么合适，怎么来。