敏捷开发个人理解

敏捷开发的核心：应对需求的变化

 

诞生的原因：传统的开发模型如瀑布模型要在编码前完整并且准确的调查好用户需求，需要 耗费大量的时间，却达不到用户满意的效果。因为在实际生产过程中，用户的需求是多变的。

 

敏捷开发过程：在开发前罗列出用户最基本的需求，按需求的重要性、风险性设定不同的优先级。优先级高的需求先开发，及早开发出软件原型，与用户进行交流，让用户提出修改意见。在开发过程中，可以采用story card、story wall的方式，将每个需求做成story card张贴在story wall上，对于每个story card又可以分为小的story card迭代开发，指定专门的程序员负责该模块的开发，并设定该模块预期的开发时间。每天汇报该模块的开发进度，做到项目进度的可控，每个程序员的工作量也可控。

 

敏捷开发与持续集成的结合：在开发过程中，开发人员时时 上传Story card最新版本，测试人员时时下载最新版本进行测试。对每个story测试完后再进行完整的测试。  

敏捷开发环境搭建：SVN+jenkins配套工具，我将会在之后的博客中谈到SVN服务器的搭建和使用，常见问题的解决，jenkins持续集成工具的搭建和使用。

具体参考《敏捷开发环境搭建》。

 

敏捷开发简单流程：

1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。(backlog可以理解为需求或者要做的事情)

2、召开产品backlog计划会议，预估每个backlog的时间，确定哪些backlog是需要在第一个sprint中完成的，即sprint的backlog。(sprint可以理解为一个团队一起开发的一个任务集合)

3、把sprint的backlog写在纸条上贴在任务墙，让大家认领分配。(任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上，这样大家都可以看得到任务的状态 )

4、举行每日站立会议，让大家在每日会议上总结昨天做的事情、遇到什么困难，今天开展什么任务。(每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，时间控制在15分钟内)

5、绘制燃尽图，保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0 ，这个sprint就完成了)

6、sprint评审会议是在sprint完成时举行，要向客户演示自己完成的软件产品 。

7、最后是sprint总结会议，以轮流发言方式进行，每个人都要发言，总结上一次sprint中遇到的问题、改进和大家分享讨论。