敏捷思考0.1版
最近“如何在让开发团队敏捷起来”的话题时常被公司的兄弟开发团队讨论起来，而且有些团队也开始进行实践，并获得了第一手的体验和经验。这两天也在不断思考如何让自己的开发团队如何敏捷，这篇文章就是用来记录相关的内容，不过自己在这方面额内容涉猎不多，所以把这次敏捷思考定位到0.1版。
变更的成本
软件变更的成本实际上是操纵这软件开发的多种方面。下面这张图描述的是瀑布模型中的变更成本曲线。
图一
举例来说，如果是犯了需求错误，并在需求阶段发现它，弥补的成本不是很高，仅需要修改需求模型就可以；如果在设计阶段才发现需求的错误，不但需要修改需求模型，基于错误需求模型的相关设计也必须重新评估、设计；在编程和测试阶段发现需求的错误，导致的变更成本就更大了。所以在传统(瀑布或者迭代)开发模式(如下图)中，通过对软件开发过程进行细分，完善流程和规范，尽量保证前置阶段的输出是正确的（通过文档输出、设计评审等手段），目的就是把变更的成本降到最低。
但是，我们的现状是：
- 项目流程过于死板，瀑布式开发
- 问题暴露延后，测试压力很大
- 各自开发，没有结对编程，造成能力壁垒
- 需求变化带来的负面影响
- 团队不统一认识造成的浪费
- 项目评估不准，周期长
- 等待造成的浪费
- 没有安排优先级造成的浪费
- …….
注以上内容来自公司其他团队的分享。
那大家不经要问这个是为什么？我自己的回答是以下几点：
首先，在传统模式下每个阶段的工作都由专门角色来负责，需求分析阶段-需求分析师；设计阶段-架构师或开发人员；开发阶段-开发工程师；测试阶段-测试工程师。在这种分工和流程设计的环境下，项目中的每中角色只能接触有限的上下文，每个阶段工作只有有限的人员参与，每个阶段工作的质量直接受限于主要负责人的经验、知识、能力等等。
还有，延迟的结果输出，导致最后的结果设想存在很长时间段的“幻想”期。无论是需求文档、设计文档、测试文档，只有在实际结果产出以后才能得到验证，甚至有些需求理解不符合业务方的期望的问题直到软件在进行客户体验或者上线以后才能被发现。
最后，还有就是主动或者被动地选择低效的沟通方式。人们习惯依赖最低效（至少不是最高效）和繁琐的沟通方式——文档来进行沟通。通过文档进行沟通存在很多的弊端：一、制作繁琐，不但需要文字描述，有时候还需要图文并茂；二、文档输出的质量也不够稳定，很依赖撰写者的描述能力，三、文档的理解也需要耗费时间和资源，理解过程中存在失误。
对敏捷的理解
如果敏捷是要解决传统(瀑布或者迭代)开发模式的弊端就必须解决以下问题：
一、将每个阶段的变更最小化，也就是说要使得需求分析、设计、编码和测试最大程度地正确。如何达到呢？首先，就要求每个阶段的负责人具备更高的能力，这是一个答案，但也不是一个答案，因为个人能力的提升需要一个过程。其次，就是利用“集体智慧”，无论是需求、设计、测试都要充分表达出自己的想法，例如，需求分析师要负责向开发人员和测试人员说明为什么要有这个需求；这个需求是如何实现业务方的需求的；将来业务可能的需求扩展有哪些，和现在需求的关系如何，如何应对将来的发展。开发人员和测试人员会站在各自的角度以及利用自己的专业知识给出需求设计、建模的意见和建议。一句话“三个臭皮匠顶个诸葛亮”，用“集体智慧”去解决瓶颈问题。还有，就是充分的沟通，想必大家都知道沟通的重要性这里就不在叙述了。
敏捷宣言中有若干条价值观或者原则与此相关
原则：
业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
对卓越技术与良好设计的不断追求将有助于提高敏捷性。
围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
二、减少变更的成本，也就是说当变更无法避免的时候，如何让变更成本最小化。用“运动是绝对的，静止是相对的”这句话套在这里就是“变更是绝对的，不变更是相对的”。如果图一中的变更成本曲线是指数型的话，我们就要想办法把变更成本的曲线来加以改变，下面这张图是理想的变更成本曲线图。
那么这种变更成本曲线如何实现呢？我们来数一数手中的武器：
需求的武器有：
- 界面原型
- ……，我不熟悉需求分析工作，实在想不出啥
开发的武器有：
- 单元测试
- 重构
- 持续集成
- 代码生成工具
- ……
测试的武器有：
- 自动化测试
- ……，测试的工作我同样不熟悉，呵呵
但最最重要的还是那个“不是答案的答案”——即要求提高需求分析人员的概念领域建模和业务流程建模能力等等；设计师的面向对象设计能力、架构设计能力；测试人员的测试分析、设计能力:-)。我相信这些能力才是控制变更成本的最有效工具。
不断的观察我们实际的变更成本曲线，从而不断的强大我们的武器、提升我们的能力，最后目标只有一个“面对变更，我们不但无所畏惧，而且自信满满” 。
敏捷宣言中有若干条价值观或者原则与此相关
原则：
我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
简单——尽可能减少工作量的艺术至关重要。
最好的架构、需求和设计都源自自我组织的团队。
三、让变更提早被发现，敏捷开发中倡导的“频繁交付新的软件版本，将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强”能在很大程度上让变更提早被发现，并将变更的成本最小化。敏捷宣言中有若干条价值观或者原则与此相关
价值观：
可以工作的软件重于求全责备的文档。
原则：
经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
可以工作的软件是进度的主要度量标准。
对于这点想在日后的文章中再展开叙述。
四、团队间高效沟通和诚意合作。敏捷开发倡导并在某种程度上神话了某些工具，例如白板，“业务人员和开发者应该在整个项目过程中始终朝夕在一起工作”，而实际上只要我们能够了解这些工具或者环境准备都是为了减少沟通障碍、提升沟通效率和效果，就能破除对这些表面功夫的迷信。对于这点也想在日后的文章中再展开叙述。
敏捷尝试计划
主要的敏捷执行流程大致如下图所示
下面是几个主要内容的说明:
周期0指的是进入项目流程后的一个阶段，进行的内容包括了最初的分析、建模、分析。这个阶段进行的内容涉及到高层的需求分析、需求建模、设计建模、测试分析等工作，工作内容的范围、难度存在比较大的差异，时间跨度可能有几个小时到1-2周，强烈不建议投入更多的时间，因为那样会有过度建模的危险，另外过度延长可交付软件的交付周期也会导致变更机率的加大。
周期1至n进行的是详细建模、详细设计、开发、测试等一系列工作。在一次发布的周期里，建模工作经常会是分钟级别。产品经理、需求分析师、开发、测试（我们的工作模式很难让业务方一起参与到软件开发的流程中）一起分析正在处理的需求，一起通过白板或者草稿上绘制一张草图，然后产品经理、需求分析师、开发、测试各自进行需求分析、需求建模、设计、开发、测试分析等工作。需求建模和设计建模可以采取高效的工具来进行，例如，需求分析师是可以通过Pencil之类的工具完成界面原型的设计，而开发工程师可以通过UML来描述类图和时序图，从而将主要的设计思想和内容表达出来，至于面面具到的文档可以留到后续的工作中来完善。团队在实现阶段(开发和测试）会花费大量时间。在开发中，遵循和使用TDD、重构、或者代码生成可以有效提升开发效率，而在测试阶段这样敏捷的工具和方法就为数不多了！
在周期0至周期n的过程中，将涉及的评审工作也根据迭代周期穿插进行。在完成了项目后需求、开发、测试工作人员可以根据最终的工作结果完善文档（这些文档对于我们团队在后续的开发、维护工作中还是至关重要的）。
总结
以上就是这段时间对“敏捷开发”的思考和整理，由于没有多少直接的敏捷实践经验，更多的内容要等待通过以后的实践工作来体会和总结。
参考资料
瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型，在瀑布模型中，开发被认为是按照需求分析，设计，实现，测试 (确认)， 集成，和维护坚定地顺畅地进行。
在最初的文章中，Royce提倡重复地使用瀑布模型，以一种迭代的方式。但是，大多数人并不知道这一点，一些人也不相信它能够作为一种真实世界的过程使用。在实践中，过程很少能够以纯线性的方式进行。 通过回到前面的阶段或改变前一阶段的结果的迭代是非常普遍的。讽刺的是，在Royce 1970年的那篇文章中他讲述这种模型的目的是作为例子来说明这种模式是有缺陷的、不能工作的。事实上，软件开发相关文章中对这个名词的大量引用正是对这个广泛流行的软件开发做法的一种评判。
瀑布模型（Waterfall Model）最早强调系统开发应有完整之周期，且必须完整的经历周期之每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等，因此瀑布模型又可以称为‘系统发展生命周期’（System Development Life Cycle, SDLC）。由于该模式强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制，因此能有效的确保系统品质，它已经成为业界大多数软件开发的标准（Boehm, 1988）。
敏捷软件开发又称敏捷开发，是一種從1990年代開始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于「非敏捷」，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。
评论测试