如何实施敏捷开发

一、前言

       敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

二、敏捷流程

敏捷流程.png

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中遇到的问题、改进和大家分享讨论。

三、敏捷环境搭建

要实施敏捷开发，需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件：maven/gradle 管理工程的依赖、jenkins 持续集成和自动编译发布、Sonar持续监测、自动化测试、git 集中代码管理、jira 记录需求和状态。

四、敏捷项目实施过程

1. 先根据各自的能力聚集一批完成这个项目的工程师，项目经理可以根据总体项目的投入机动调整资源以及支持。

2. 充分调动客户（老板和业务同事）参与进项目，他们的参与直接决定了项目成功与否。结合之前的经验，如果他们参与不够，最终做出来的东西就不是他们要的，或者离他们要的差距很大。他们刚开始加入的时候，很迷茫有时会表现的比较抗拒，这个时候一定要耐心坚持让大家把第一个sprint开发成功，使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化，如果有需求变化，就添加任务到任务墙，大家可以对所有任务的时间有个全面了解，如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。

3. 需求分析师和客户沟通记录需求。多次沟通后，把需求原型用最简单的工具绘制出来，项目经理审核通过后和客户沟通确认，反复迭代，直到整个需求大家没有异议。

4. 产品设计出来后，召集项目成员分解任务，确定每个任务的时间，可以使用敏捷扑克牌来估计。任务分解尽量控制在1-2天的粒度，这样大家1-2天就可以做出一个能测试的原型，尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周，不能太长，也不能太短。太长会出现疲劳，太短的sprint会让大家觉得工作太多，做完一个又一个。 例如：“项目1”估算结果为120人天，总共投入4个人，需要30天4周时间，我们切成了4个sprint，差不多1个月时间完成，满足业务的时间要求。

5. 分阶段实施sprint，绘制任务墙，划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙，贴到未开始的地方。

bug-kanban.png

项目-kanban.png

需求-kanban.png

五、每日站立会议

       站立会议总结昨天的任务是否有问题，对于当前的任务有什么建议，尽量控制在15分钟内，有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果，而是团队驱动，每天大家做的事情都反映在墙上，谁出现了什么状况，大家都会帮他想办法，保证整个项目能够成功。每一个任务完成，由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。

六、软件开发过程

       认领任务后，怎么保证大家开发有质量的代码？团队有资深点的工程师，不需要太多指导，直接可以参与项目的开发。而学习型工程师，需要指导帮助才能一步步做用例、系统分析。项目负责人不建议认领太多开发任务，他负责开发团队的概要需求审核，没有审核通过的需求不能开发等等。大家都知道，系统思路有了，剩下就是技术实现的过程，只要技能掌握熟练实现基本难度不大。大家可能会问，敏捷开发不是强调软件开发的产品是软件，而不是文档吗？我们这里也不是像传统开发软件一样为了文档而文档，只是让大家把自己的设计思路写下来，只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论，这样的文档是不欢迎的，受欢迎的文档只需写出用例分析，表设计，复杂的逻辑需要画出流程序列图。

七、项目演示总结会议

       在项目结束后，让所有参与项目的成员都参加，一起演示给客户展示，并解答客户的问题，充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享，并为下一个sprint做准备。

八、结尾

工作流参考:项目工作流
本站文章部分理解来源于网络,仅作为学习之用,版权归原作者所有.如果侵犯了您的权益,请来信告知,我会尽快删除.