Process & Scrum

依然是一样的话题，依然是我自己的点滴心得，我希望能通过这种方式不断的去认识以及总结。

上次Flow VS Agile中我们谈到了过程和敏捷的初体验，主要针对一开始如何做需求的研发。

转眼3个月过去，我的项目经历立项、市场分析、总计划、需求研发、需求澄清、工作量评估、架构设计这几个阶段。如果按照Process过程来讲，可以说我们到了概要设计这一步。（标准瀑布过程：问题定义、可行性研究、需求分析、总体设计、详细设计、编码、测试、运行维护）

从目前来看那我们岂不是没有敏捷吗？可是上次不是谈到我们是用的敏捷来管理项目吗？对了，到目前为止，我们确实还没有用到敏捷，这都是标准的瀑布模型，标准的开发流程。但对于前面的步骤的原则不太一样，我们不是让每件事情100%完成才启动下一个步骤，这才是关键。比如说我们的需求开发可能只是定一个大的框架，如feature有了，可能就到下一个步骤进行设计了，进行GUI了。这样看来我们有点像是快速开发的模式。

那么真正的Iteration迭代是什么时候开始呢？就是在所有开发环境基本准备完毕的时候，如，架构设计完成了，概要设计也有点眉目了，基本开发IDE统一了，code rule有了，一个简单的实作有了，那么我们就可以开始Iteration了。或者说可以开始做release plan meeting了。那么前面所有我姑且称之为Iteration之前的准备吧。

用一句话总结上面所说，就是，我们用快速开发的模式来做Iteration迭代之前的准备工作。可能这个时候很多“观众”会问了，为什么不用纯快速开发或者纯Agile呢？呵呵，我觉得这或许就是我们常说的凡事都有利有弊，关键是我们要找到适合我们自己的平衡点。这或许就是我们的平衡点吧。

这里引入一个我也不知道是谁说的思想，过去的这么多年来，我们的软件开发方法可以分为三大类：第一大类，也就是最初的时候，我们开发基本上只有Coding，没有太多的设计，甚至没有任何市场分析及需求开发，测试和后期维护也很少。因为那个时期编程才刚刚起步，可能编程完全就是为了体现计算机的计算能力，或者使用计算机作为辅助工具。我们姑且叫他Coding类吧。第二大类，软件的兴起，软件给我们带来了全新的生活方式，我们越来越注重用软件来解决问题，软件设计也越来越复杂，编程不再可能是个人英雄了。我们需要团队的力量，这个开发人员越来越看中设计，完美的设计带来的好处不用我说，提高效率，减少返工，扩展方便。我们可以把这个阶段叫做Architecture&Design类；可能很多公司目前都属于这一类。还有一类，也是我们公司现在所推行的，Full类，是什么意思呢，就是我们会适当减少对设计的投入比例，而增加需求、以及后期推广维护的投入比例。让这个研发生命周期是一个比较平均的一个投入比例，既不完全倒向Coding，也不完全倒向Architecture&Design。

回到我们上上一段所说的，这就是我们的平衡点，也正是我们Process & Scrum的艺术之处。