敏捷开发流程总结

Agile——敏捷开发，做为CMM神话崩溃后被引入的一套新的软件开发模式，这几年来被普遍引发关注，并被寄予厚望。敏捷开发在其它业界的应用是否理想不得而知，但下面总结了我所在公司的敏捷开发试验，但愿可以达到管中窥豹的目的。

敏捷开发宣言——
个体和交互 赛过 过程和工具
可以工做的软件 赛过 面面俱到的文档
客户合做 赛过 合同谈判
响应变化 赛过 遵循计划
尽管右项也有价值，但是咱们以为左项具备更大的价值。

以上的宣言比較抽象，基于该理念，下面是ThoughtsWork咨询公司的推崇的n个敏捷开发实践：
Iteration
迭代开发。可以工做的软件赛过面面俱到的文档。所以，敏捷开发提倡将一个完整的软件版本号划分为多个迭代，每个迭代实现不一样的特性。重大的、优先级高的特性优先实现，风险高的特性优先实现。在项目的早期就将软件的原型开发出来，并基于这个原型在兴许的迭代不断晚上。迭代开发的优势是：尽早编码，尽早暴露项目的技术风险。尽早使客户见到可执行的软件，并提出优化意见。可以分阶段提前向不一样的客户交付可用的版本号。
IterationPlanningMeeting
迭代计划会议。每个迭代启动时，召集整个开发团队，召开迭代计划会议，所有的团队成员畅所欲言，明白迭代的开发任务，解答疑惑。
Story Card/Story Wall/Feature List
在每个迭代中，架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完毕开发，交付提早測试（Pre-Test）。当一个迭代中的所有Story开发完毕之后，測试组再进行完整的測试。在整个測试过程当中（pre-test，test），基于Daily build，測试组永远都是天天从配置库上取下最新编译的版本号进行測试，开发者也随时改动測试人员提交的问题单，并合入配置库。
敏捷开发的一个特色是开放式办公，充分沟通，包含測试人员也和开发者一块儿办公。基于Story Card的开发方式，团队会在开放式办公区域放置一块白板，上面粘贴着所有的Story Card，按当前的开发状态贴在4个区域中，各自是：未开发，开发中，预測试中，測试中。Story Card的开发者和測试人员依据开发进度在Story Wall上移动Story Card，更新Story Card的状态。这样的方式可以对项目开发进度有一个很是直观的了解。
在开发者開始开发一个Story时，ta需要找来相应的測试人员解说Story功能，以便測试人员有一致的理解，同一时候開始本身主动化系统測试脚本的开发。
Standup Meeting
站立会议。天天早上，所有的团队成员围在Story Wall周围，开一个高效率的会议，一般不超过15分钟，汇报开发进展，提出问题，但不浪费所有人的时间立马解决这个问题，而是会后个别沟通解决。
Pair Programming
结对编程是指两个开发者结对编码。结对编程的优势是：通过两我的讨论后编写的代码比一我的独立完毕会更加的无缺，一些大的方向不至于出现误差，一些细节也可以被充分考虑到。一个有经验的开发者和一个新手结对编程，可以促进新手的成长，保证软件开发的质量。
CI/Daily Build
持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发者天天将编写/改动的代码及时的更新到配置库中，本身主动化编译程序天天至少一次本身主动从配置库上取下代码，执行本身主动化代码静态检查（如PCLint），单元測试，编译版本号，安装，系统測试，动态检查（如Purify）。以上这些本身主动化任务执行完毕后，会输出报告，本身主动发送邮件给团队成员。假设当中存在着不论什么的问题，相关责任人应该及时的改动。
可以看到，整个开发组频繁的更新代码，出现一些问题不可避免。经过測试部又在不停地基于最新的代码进行測试。新增的问题可否够被及时发现并消灭掉，取决于本身主动化单元測试和系统測试能力是否足够强大，特别是本身主动化系统測试能力。假设本身主动化測试仅仅能验证最简单的操做，则新合入代码的隐患将很是难被发现，并遗留到项目后期，造成大的风险。而实际上，提高本身主动化測试的覆盖率是最困难的。
Retrospect
总结和反思。每个迭代结束之后，项目组成员召开总结会议，总结好的实践和教训，并落实到兴许的开发中。
ShowCase
演示。每个Story开发完毕之后，开发者叫上測试人员，演示软件功能，以便測试人员充分理解软件功能。
Refactoring
重构。因为迭代开发模式在项目早期就开发出可执行的软件原型，一開始开发出来的代码和架构不多是最优的、面面俱到的，所以在兴许的Story开发中，需要对代码和架构进行持续的重构。迭代开发对架构师要求很是高。因为架构师要将一个完整的版本号拆分红多个迭代，每个跌倒由拆分红很是多Story，从架构的角度看，这些Story必须在是有很是强的继承性，是可以不断叠加的，不至于兴许开发的Story全然推翻了早期开发的代码和架构，同一时候也不可避免的需要对代码进行不断无缺，不断重构。
TDD
測试驱动开发。正如上面讲的，迭代开发的特色是频繁合入代码，频繁公布版本号。測试驱动开发是保证合入代码正常执行且不会在后期被破坏的重要手段。这里的測试主要指单元測试。

敏捷方法反思：
本身參与的敏捷开发项目总的来讲不是很是成功，这可能也是业界遇到的通病：
一、对于全新的软件，在项目早期測试人员就參与并实现本身主动化測试脚本，但实际上软件的界面等很是不稳定，致使測试人员返工的工做量很是大。
二、对于全新的软件，资料人员过早參与，后期返工工做量大，缘由同第一点。
三、本身主动化系统測试工做量大，測试人员投入大量的精力在使測试本身主动化起来，而没有足够的精力放在真正的測试软件的功能是否正常。即使是这样，本身主动化系统測试脚本也多流于形式，測不出深层次的问题。
四、代码动态检查工具执行不理想，流于形式。没有人对Purify有深入的理解和应用经验，报告中查出来很是多告警，但不知怎样消除。
五、因为高速搭建原型，没有在架构上进行严谨的设计，致使后期一直堆砌代码。
六、异地开发模式下没法实现高速构建、高速交付，团队广泛感受很是疲惫。
七、敏捷开发不提倡加班，但实际上不管是CMM仍是Agile哪种开发模式跟是否加班都没有一定联系。