最近一段时间一直在忙于工作，没有太多时间静下心来梳理一下自己的思路。所以总会感觉事情纷乱复杂，没有条理。由于工作形式、组织结构都跟以前相比有了些变化，这也使我发现了许多新问题，也迫使我去积极的思考一些相应的解决途径，想必应该是件好事。
在我们的项目中，一直以来都会给大家一个感觉，那就是时间压力紧，项目规模大，逻辑关系复杂。这些已经是共识。而针对于我们现有的状态，能否找到对应的、适当的开发形式，就变的尤为重要。下面我想根据这个问题谈一些个人的看法。
首先我想先区分一个概念，那就是可预见性开发与新产品开发的区别。
对于可遇见性开发(predictable development),当开发商对于所要开发的产品需求进行了一定的了解后，可以准确的估算和控制未来可能会产生的过程与风险。比如我们开发一个CMS,我们对于CMS的系统结构已经了如指掌，或有了非常足够的经验基础，当我们提及CMS的时候，大家马上可以反应出关于CMS的种种问题。这就是可遇见性开发。
而对于目前的xx项目，我们没有过多的经验可以借鉴，则应该属于新产品开发(new product development)。
关于两种开发，在过程、管理理念、计划和估算模型上都是截然不同的：
可预见性开发 | 新产品开发 |
第一次完成规格说明后，就进行构建 | 不可能在前期创建一成不变的、详细的规格说明书 |
在项目早期阶段就可以估算出成本与工作量 | 开始阶段很难进行预见性分析。随着经验的积累，计划与估算才会相应增加 |
有可能识别、定义、安排所有的细节活动 | 开始阶段识别、定义、安排所有的细节活动是不可能的，只能是通过反馈，需求构建，再反馈，再构建的方式逐步适应 |
不适应没有预定义的变动，改动率底 | 主动适应没有预定义的变动，改动率比较高 |
知道了xx项目的类型（新产品开发），让我们再来看看它早期的一些特征：
1.客户不能明确他们到底要什么，至少在项目的早期是这样的。
2.客户很难陈述所有的需求和知识。
3.他们想要的许多细节只能在开发过程中逐步展现。
4.细节对于他们过于复杂
5 随着对项目的逐渐深入与理解，导致需求变更或者增强。
就目前的情况来看，客户方似乎弥漫着一些对项目组不信任的气氛。究竟能不能按时完成任务，是我们，也是客户最期望知道的一个答案。所以我们为什么不试着多给项目一些建议呢，多换些角度来思考问题呢。“客户协作胜于合同谈判”，这是我们都明白的一个道理。那么怎么做才算是协作呢？我想应该是“积极、沟通、协作、适应”，具体说来：
--我们承诺会频繁交付可工作的软件，并且我们也不会因为项目后期的需求变更而牢骚满腹；
--你不要用文档、工具和过程这种有时候看上去会对项目有所帮助但实际上并无益处，并一度因为信任度的缺乏而用来监视我们的东西来延缓我们的开发进度。你不需要直接盯着我们的工作，而是应该常常和我们沟通。
针对于以上的期望，我们就不得不找到一种合适的开发模式，区别于传统开发模式的新模式，这就让我不由的联想到了ASD(Agile Software Development)敏捷软件开发，或者我们这里要说的应该是AID(Agile Iterative Development)敏捷迭代开发。如果先要给敏捷软件开发下出一个定义，那它应该是一个概念意义上的框架，用来取代传统软件工程项目的概念；它强调在项目的整个生命周期中，拥抱并促进由于软件进化式的发展所带来的变化。这有点象IBM的口号："On Demand!"，随需应变！但前提是一定要快，以最快的速度响应客户的需求。
官方定义：Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project.
传统团队与敏捷团队的对比
传统团队 | 敏捷团队 |
子系统所有权 | 集体代码所有权 |
一次性设计 | 增量开发 |
全面且完整地理解子系统 | 探索，发现 |
大量的事先设计，“结果管理” | “技术原型”，试验 |
全面文档化 | 自动化测试 |
通过分析整个设计保证质量 | 通过测试驱动开发保证质量 |
需要一个全面的分析 | 探索并限定相关信息 （例如，代码覆盖，小的任务，优先级划分等等） |
个人设计决策 | 形成且尊重团队的一致意见 |
把规模大小或复杂性作为成果 | 把规模大小或复杂性看作负担，尽可能减小 |
预先决定，尽量不改变设计 | 设计无止境，易变性，把变化作为学习的机会 |
传统团队 | 敏捷团队 |
上表在代码级别上列出了一些传统团队与敏捷团队的不同。富有经验的敏捷开发者有不同的编码方法。他们倾向于灵活编码，而不是等到整个设计都很完善了再进行开发。另外，他们还倾向于把编码视为学习和探索的机会。例如，遇到一个问题时，他们总是通过编写一个小的概念验证模型或“技术原型（spike solution）”使问题具体化，而不是构建一个复杂的模型或者通过自然语言描述来说明各种行为。同样，敏捷开发者更愿意去阅读第三方的代码。有时候，他们想做一些力所能及的改进；有时候他们这么做只是为了学习一种新的设计方法。最后，通过尽可能地让类、方法以及与潜在的方法调用链等相互独立，以便仅了解局部代码就足够了，这样就不用去花很多时间去研究整个子系统或应用。所有这些差异能更好地使开发者发现并处理编码中出现的问题，而不是仅仅使用高超的编码技能完成任务而已。
再让我们来看看敏捷团队的特点及优势所在：
★最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
★即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。
★经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月（推荐4-6个周为一迭代，当然也要考虑到成本的因素），交付的时间间隔越短越好。
★在整个项目开发期间，业务人员和开发人员、测试人员必须天天都在一起工作。
★围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
★在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交流。
★工作的软件是首要的进度度量标准。
★敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
★不断地关注优秀的技能和好的设计会增强敏捷能力。
★简单--使未完成的工作最大化的艺术---是根本的。
★最好的构架、需求和设计出自于自组织的团队。
★每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
当然，敏捷团队也存在着它自身的一些不足：
1.协作：在整个Agile的运行生命周期中，要求管理者、需求者、开发人员、测试人员这几部分紧密联系，相互配合，做到你中有我，我中有你。其实真正要做到这一点是有一定的难度的，而基于这种开发模式的项目通常对时间的压力是最明显的，而就是因为没有时间，如何平衡、协调自己的本职工作，还要做好和其它部门的配合工作，就变成了最突出的矛盾和问题。如果做不到这一点，那整个项目就会出现瓶颈，而不能达到最终效果。再有就是，协作的本身也是需要成本的！
2.对敏捷的要求：我们想象中的敏捷开发模式是，客户坐旁边看报听歌打游戏。程序员一会一会又一会的就简单的实现的客户的需求。客户一边说，我们一边做。这种方式当然是理想的，但却是很难实现的，我想任何一个客户也不会有时间和精力每天陪做在开发人员身边指导需求工作。所以如何才能达到最佳的敏捷效果，也是需要考虑的。
3.人员要求：以敏捷开发的思路，我认为，面对面的沟通是最快速的，最有效的方式，而这种方式的核心元素就是人。在一个项目当中，当人的因素远远超出制度或规则的因素，那么在某种程度上，我们不得不依靠人员的素质来把控整个过程，使其平稳运行。别忘了，敏捷方法论（特别是极限编程）要求编程人员有很强的编码能力，这点是必须的。
4.敏捷不是借口：敏捷的思路一经被提出，就受到了非常多的开发人员的拥护，尤其是国内的一些开发人员。而就项目本身而言，有适合采用敏捷式开发的，也有不适合的，但却被某些人通通拿来套用，行不行也都是敏捷。因为他们不愿意花大把大把的时间去阅读需求文档，规范文档，反反复复的和客户去确认。他们更希望就有人坐在身边，告诉他应该怎么做，他就照着做。这就成了敏捷开发之所以大受欢迎的主要原因。但其实你会发现，这与我们所提出的CMMI,过程管理其实并不冲突(如果你真正理解了Agile思想的话)。现在很多人认为Agile就是一种cowboy coding,其实不是这样的。在某些方面，ASD对纪律的要求更加严格；比如测试优先，比如持续集成等等。它的宗旨是讲究沟通，讲究协作，讲究创新.
当然，对于现在项目形式多样化，个性化，变化无常的特点，仅仅具有敏捷的思维是不够的。大家只有把各方面的理论、知识结合实际情况（尤其是中国市场的实际情况），加以裁减，灵活运用才可以。任何一种方法论都不是”唯一”的方法论。应当以最适当和最高效的方式达成最终目标，同时对客户的流程保有更好的适应性，确保客户从商业周期收到价值和商业利益和获得最大化的回报。
结论：变化是永恒的。无论哪一种模式，只有适合，没有好坏，只要我们采用了适合项目规模和沟通需求的开发方式，都是OK的。
结束语
最后唱个高调，希望和大家共同来思考一个问题：
20年前，我们接触到了计算机
15年前，我们知道了什么是DOS操作系统，掌握了BASIC
10年前，我们学会了服务器端语言，开始写客户端脚本
5年前，我们对过程管理有了概念，开始学习CMMI
现在呢？我们该做些什么呢...?
