敏捷开发

第一个管理的项目采用的是敏捷开发，以下是个人对敏捷开发的一点实践总结。希望能给大家提供一些帮助。

（关于敏捷开发的3355，敏捷宣言，十二准则在最下边有。）

敏捷开发流程：

1.首先需求负责人理清需求。

2.团队内部要熟悉了解（可以做做游戏）。

3.当天下午及晚上迭代任务拆分。评估工时。

4.开始第一天每日例会领取任务。

5.迭代中旬测试用例评审，接口文档评审，故事验收标准。

6.期间每天早上的站会主要是总结昨天做了什么，遇到了什么问题，今天要干什么（承诺）。负责人需要对问题进行解决。不要阻塞开发。

7.迭代结束需要开迭代评审，迭代回顾。晚上进行任务拆分。

8.上一迭代未完成的任务放进下一迭代。需求变更的也放入下一迭代。

 

 

详细过程：

1.一周主要有以下几个过程：

每日立会。

迭代评审。

迭代回顾。

迭代计划会。

接口评审。

测试用例评审。

故事验收标准。

周报。

演讲分享。

 

每日立会：

每日立会是用来回顾自己在昨天做了什么，还有什么任务没有完成，为什么没有完成，遇到了什么问题需要解决。自己今天要做什么。根据反应的情况进行调整。负责人需要对所有的问题故障进行尽快的解决。

每日立会的公开性透明性能够清楚的认识到每个人的能力和问题。团队成员领取任务是一种承诺，既然承诺了就需要去完成。

 

迭代评审：

迭代评审是对本次迭代的评审，需要严格按照故事的验收标准来进行评审。是检验本次的迭代成果的时候。检验本次的完成情况并进行梳理，看有哪些没有完成，为什么没有完成，是否有什么风险，并将没有完成的移到下一迭代。完成后需要将本次迭代的成果交给甲方进行验收，看是否有需要改变的地方。如果有的话将需要改变的需求移到之后的迭代进行。

 

迭代回顾：

 

回顾本次迭代的团队情况。每个人需要写团队的三个评价：

好，不好，待改进。必须是针对团队的，不能针对个人。之后将统计结果写在黑板上，由团队人员进行投票。每个人必须对每个栏目进行投票，可以投多票反对，一票赞同，赞同票必须投，反对票可以不投。完成后总结团队的情况并解析。下次迭代改进。

 

迭代计划会：

迭代计划会需要对下次迭代的需求进行讲解和任务划分。将故事划分成一个个任务，由相应人员进行工时评估，录入系统。完成后将任务和故事打印出来，贴到看板上。

 

迭代本身：

这个暂时不知道是什么意思。

 

接口评审（迭代中旬）：

对团队人员写的接口进行评审，看是否符合标准，解释是否明了，需要用到该接口的人员有什么问题都可以提出来。需要修改的则现场进行修改。

 

测试用例评审（迭代中旬）：

对测试人员编写的测试用例进行评审，主要是测试人员进行评审看用例有那些缺陷或不严谨的地方。反思自己写的测试有什么不足。

开发人员则需要注意看看测试人员会测试那些东西，反思自己思维上有哪些没有考虑到，尽量的在开发阶段进行完善。不要提交到测试那一大堆bug。

 

故事验收标准：

故事的验收标准需要由团队人员来进行编写，提交给负责人，负责人同意后，则迭代评审时按照该标准进行评审。

周报：

每个人需要在一周结束时写一份周报来总结。周报内容应包括以下内容：

1.本周所做的工作

2.本周完成的工作

3.本周遗留的工作

4.有挑战性的工作

5.有成就感的工作

6.所学到的知识

7.自己需要改进的方面

8.建议团队需要改进的方面

9.其他

 

演讲分享：

这个是附加的，因为咱们都缺乏一些经验性，常识性的东西，所以需要以演讲的形式来为团队成员扩充知识面。

 

 

敏捷开发术语解析：

分组：开分前需要分好团队，根据不同情况将一个团队分成几个组，可以不分。并取个名。

迭代：一个项目可以分成多个迭代来进行完成。每个迭代完成一部分任务。以主线程为中心。以价值为核心。来判定优先级。

用户故事：将所有的需求划分成一个个用户故事，如果一个用户故事的任务量太大时必须拆分成几个小故事。用户故事有史诗级用户故事和普通用户故事。史诗级用户故事就是特别打的一个任务点。必须拆分成n多个任务故事。

用户故事举例：作为xxx,我要通过xxx,进行xxx。

用户故事地图：用户故事地图就是由许多许多的用户故事及任务张贴到物理看板上之后组成的一个地图。

任务：每个故事可以拆分成多个任务。由不同人员进行认领完成。

任务划分：每个用户故事可以拆分成很多任务，常规的有：前台页面开发，接口文档设计与开发，后台逻辑开发，测试用例编写，接口自动化测试，页面测试。  数据库设计一般在开发前就以完成，不过也可以在开发时添加数据库设计任务。

燃尽图：

所有的用户故事和任务被划分工时后会形成一个燃尽图，燃尽图以一个迭代为周期。随时间推移，团队人员需要为燃尽图进行工时的增减。燃尽图可以直观的看出团队任务的完成情况。

电子看板更新：

每日立会开完后，需要跟新电子看板，将自己认领的任务拖到相应位置。一天当中完成任务后需要将任务拖到完成状态，如果阻塞需要拖到阻塞状态。完成后可以继续认领新的任务。并将物理看板上认领相应的任务，当一天结束时，如果手头的任务没有完成则需要更新剩余工作量。

 

敏捷看板：

敏捷看板有物理看板和电子看板，物理看板只能每日立会的时候可以拖动，电子看板可以随时拖动，敏捷看板可以让团队人员更加直观的看到团队的完成成果和项目进度。

看板有以下几个字段：

用户故事，todo,doing,block，done.

 

 

工具：

敏捷开发的工具网上有很多，我们用的是自己的。

需要具备的功能：

敏捷看板 电子看板及燃尽图的展示。

用户需求 将一个模块拆分成多个用户需求

用户故事 将一个用户需求拆分成多个用户故事

迭代计划 迭代计划时长，迭代完成情况统计，团队人员完成情况统计等等。

缺陷管理 当测试人员测出bug后可以提出缺陷有开发人员进行修改。

用例管理 对测试用例进行管理。

模块管理  一个项目首先划分为一个个模块

 

持续集成：一键自动化集成部署。

 

自动化测试。测试人员进行自动化的接口及页面测试。

 

代码扫描。对所有代码进行，不合规范的将会报错。

接口管理：我们使用的是本地搭建的rap2。

敏捷宣言：

个体和互动 优于 流程和工具

工作的软件 优于 详尽的文档

客户合作 优于 合作谈判

响应变化 优于 遵循计划

 

SCRUM这个框架里面包含了这几个核心的要素：

1、3个角色：SM、PO、开发团队（自然包括了我们的开发人员和QA）。

2、3个产出物：Product Backlog、Sprint Backlog、交互的可用软件工件。

3、5个活动：计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理（发生在整个SCRUM周期的任何时间）。

4、5个价值观：公开、专注、勇气、承诺、尊重。（这五个价值观尤其重要，贯穿整个敏捷开发。）

十二条准则：

12原则作为敏捷开发对于软件开发流程的指导性纲领，其实是对敏捷宣言进行了具有实际操作意义的解释。下面是敏捷宣言12原则：

我们遵循以下准则：

1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

4、项目过程中，业务人员与开发人员必须在一起工作。

5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

11、最佳的架构、需求和设计出自于自组织的团队。

12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。