敏捷开发描述

敏捷开发过程描述

1.敏捷开发的原则

原则一：个体及交互比流程与工具更具价值

原则二：可用的软件比冗长的文档更有价值

原则三：与客户的协作比合同谈判更有价值

原则四：对变化的响应比遵循计划更有价值

由此可见敏捷开发更注重人的作用，更注重人交流，团队协作。

2.敏捷开发-Scrum

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球。Scrum的开发过程如下图所示：

一个项目包含很多用户需求，可以把这些需求都划分成多个sprint(冲刺/快跑)来完成，每一个sprint就是一个迭代过程，也就是一个项目由多个迭代sprint组成。每个sprint包含需求-》分解功能-》细化-》开发-》测试-》演示等工程，这样保证了每一次sprint开发出来的版本都是“可用的软件”。

Scrum使用的软件：

(1)Jira + greenHopper ：项目实施和BUG跟踪

(2)Bamboo：持续化集成

(3)Confluence：wiki共享

(4)Selenium：自动化UI测试

(5)Jmeter：压力测试

3.敏捷开发-Scrum实施过程

(1)需求分析

需求主要是由需求部门完成，见如下表格：

Scrum要求需求方以ProductOwner的角色参与到项目中，直到开发结束。在需求阶段需要ProductOwner提供一份ProductBackLog来简述产品的需求列表，并且根据这些需求的重要程度给出需求的权重值，以便在计划中优先处理高级别的需求，ProductOwner可以根

在需求形成的过程中，可以在jira中新建一个项目，添加各种模块以及策略。并且把ProductBackLog录入jira系统中，jira中针对ProductBackLog的类型为Epic即大块的需求。

(2)计划会议

计划会议的参与人员包括ProductOwner，ScrumMaster，Team，大约4-6个小时的时间进行。进行的顺序如下：

①ProductOwner在jira中逐条介绍产品backLog；(30-60分钟)

②一起把backLog拆分成story，每一个sotry都必须估算时间；(180分钟)

③本次sprint的目标，起止时间以及演示时间(30分钟)

④确定哪些在本次sprint中开发(30分钟)

⑤确定sprint的立会的时间地点(5分钟)

计划会议中，把产品BackLog细化成Story，并录入jira中的Story类型中，每一个story 要尽量的细化，最好工作量是在2个小时以内(包括UI的设计)，在sprint初期阶段工作量的估算主要是靠人的经验。

在确定了此次sprint的起止时间以后，就可以知道开发大体的时间是多少，然后确定哪些story可以放到此次sprint中，尽量选择权重高的story首先完成。

在确定了sprint要完成的story同时可以确定哪些story属于哪个team即分配story。

在估算每个team的工作量的时候一定要考虑实际情况，估算中每人6时/天为通用值。

(3)迭代开发

计划完毕以后就可以进入开发了，每个teamer都有了自己的任务列表，队员应该根据情况由易到难，由简到繁的顺序快速开发。

开发中要尽量使用快速开发工具Tenace。

每日立会要风雨不改，定时定点的举行，立会中每个人都要回答三个问题：过去的一天完成了什么；下面将要进行什么开发；在开发的过程中遇到了什么困难。如果有技术难题不要再立会中进行，立会的时间不超过15分钟。

Teamer在开发的过程中如果开始了哪个story，则在jira中设置哪个story在开发过程中，如果开发完毕则置为开发完毕，发给测试组测试，任务面板如下：

Teamer在开发的过程中要尽量针对每一个类都写Junit测试类，如果时间紧迫也一定要针对相关的Manager写测试类。

利用bamboo进行每日构建，保证所有的类编译以及Junit类测试方法都是没有问题的。

测试人员看到开发完毕的story，迅速测试反馈。测试过程中，先利用selenium录制脚本以便回归测试，测试完毕后如果有bug立刻利用jira的bug进行提交，小bug可以直接找到开发人员口述(沟通)。快速测试快速反馈。

开发人员要合理利用自己的时间边开发新的边修改BUG。

遇到大的拦路虎要尽量先跳过，StrumMaster要承担起来这种困难。

如果在计划的时间太短则需要抛弃一些story，首先保证此次sprint做出来的东西是可用的。

(4)演示与回顾

演示就是更新正式平台，把sprint完成的可用的功能全部更新到正式平台中，让用户体验，在演示会议中，StrumMaster或者测试人员主动的给ProductOwner等实际操作的人员直接演示，如果有条件可以每个人都点击一下，或者给Product部门的人几天的时间让他们反馈。

有些技术性的东西无法演示的时候，选择不演示。甚至如果演示的成本过大则不演示。

回顾主要是总结sprint过程，以便提升。定期制作scrum过程调查，以便调整。