敏捷的出现是有感于早前瀑布式开发模式的种种弊端，在2001年由一些业界的专家提出了一种更有效率的软件开发模式。一种更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法。
敏捷这个舶来品传入国内后，不同人有不同的理解和解释，不同的敏捷方法论都有其市场，敏捷在国内目前算是大行其道。
自己在软件行业的也算混着有些年头，也想尝试去总结一些东西，就有了今天这篇博文，任何一个模式在传播时都会经过团队的一定加工和构解形成团队自己的模式，笔者想介绍的就是自己对于敏捷的理解。
个人大致上将敏捷分为四层成熟度模型
第零层 ：基于流程阶段进行划分工作
第一层 ：基于需求功能进行划分
第二层 : 遵循scrum或是XP等方法论的敏捷实践
第三层 : 基于敏捷宣言、敏捷原则为指导的团队敏捷实践
第零层
传统的瀑布式和敏捷最大的区别在于，瀑布式是将软件开发流程进行分阶段的够解，主要分为：需求分析，架构、设计、编码实现、测试、部署、维护。
每一个阶段都有自己的边界， 各个阶段都会有阶段成果作为项目进度衡量的标准，这种严格的分级导致了自由度的降低，同时在早期做出的承诺对于后期的需求变化难以调整，代价太大。处在这个阶段的团队基本术语敏捷成熟度模型的零层
第一层
从阶段式的开发模式进度，基于需求功能分解的开发模式，在这个阶段我们是将需求分解成不同程度的小需求，并在一个周期内不同阶段交互的完成需求，不再是单一机械将功能划分未一个个阶段并产生阶段成果。
第二层
在这个成熟度的团队会熟练的使用一些敏捷方法论的action，并能根据自己团队的一些特点加以改造使之找到最适合自己团队的方法论，处在这个团队的特征是喜欢就执行过程中的问题，通过添加流程机制的方式来加以预防和尽早发现，基本停留在对于方法论的选择上
第三层
这个阶段的团队采用敏捷的价值观来转变团队成员的思维，以敏捷原则为指导，然后在团队中批判性的接纳无论是scrum还是XP等方法论中的手段来营造自己想要的团队氛围，并在实践的过程中不停的尝试、磨合、改造。
敏捷从某种角度看就是一种项目管理方法，项目管理的本质是人的管理，不同的人在不同的引导下会形成不同的团队氛围(文化)，自然而然的就是会在团队的工作中凝练出自己团队的方法论。
故他们之间的一个顺序或是优先级是 团队中的人 >>> 文化(氛围) >>> 方法论！人的培养，团队氛围的营造是优于方法论的选择。
处在第三阶段的团队基本算是一个自组织的敏捷团队，积极响应，充分发挥每个人的主观能动性！
0 条评论。