即将实施敏捷，制定些细则，请拍砖

    最近公司要尝试敏捷开发，我入职没多久，就被要求研究一下如何实现。之前只是听说过敏捷开发，没有真正实现过，经过近3个星期的整理，试用了selenium jira greenhopper confluence等工具，决定下个项目就开始实施敏捷开发，下面是实施的过程，还没过试用期，大家帮看有没有问题，多提一些实用的意见

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敏捷开发
1. 进行详尽的需求调研 2. 形成详细的需求文档 3. 以后的设计与开发与需求相关，需求不可再变化	1． 需求方参与，提供ProductBackLog即需求简述列表 2． 计划、开发中不断交流迭代需求

传统瀑布开发模式  Scrum要求需求方以ProductOwner的角色参与到项目中，直到开发结束。在需求阶段
需要ProductOwner提供一份ProductBackLog来简述产品的需求列表，并且根据这些需求的重要程度给出需求的权重值，以便在计划中优先处理高级别的需求，ProductOwner可以根据需求的大小估算出产品开发的工作量(人/小时)。如下列表为示例ProductBackLog

 

序号（ID）	名称	重要性	工作量估算(小时)	如何做演示	备注
1	存款	30	5	登录， 打开存款界面，存入10元，转到我的账户余额界面，检查我的余额增加了10元	需要UML顺序图，目前不需要考虑加密问题
2	查看自己的交易明细	10	6	登录，点击“交易”，存入一笔款项，返回交易页面，看到新的存款显示在页面上	使用分页技术避免大规模的数据库查询。和查看用户列表的设计相似

 

    在需求形成的过程中，可以在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都有了自己的任务列表，队员应该根据
情况由易到难，由简到繁的顺序快速开发。
开发中要尽量使用快速开发工具。
每日立会要风雨不改，定时定点的举行，立会中每个人都要回答三个问题：过去的一天完成了什么；下面将要进行什么开发；在开发的过程中遇到了什么困难。如果有技术难题不要再立会中进行，立会的时间不超过15分钟。
Teamer在开发的过程中如果开始了哪个story，则在jira中设置哪个story在开发过程中，如果开发完毕则置为开发完毕，发给测试组测试，任务面板如下：

未进行	开发中	开发完毕	测试中	测试完毕
权限管理	用户添加 用户修改	用户查询

      
这样开发和测试不断的循环，形成每个story都是迭代的。
Teamer在开发的过程中要尽量针对每一个类都写Junit测试类，如果时间紧迫也一定要针对相关的Manager写测试类。
利用bamboo进行每日构建，保证所有的类编译以及Junit类测试方法都是没有问题的。
测试人员看到开发完毕的story，迅速测试反馈。测试过程中，先利用selenium录制脚本以便回归测试，测试完毕后如果有bug立刻利用jira的bug进行提交，小bug可以直接找到开发人员口述(沟通)。快速测试快速反馈。
开发人员要合理利用自己的时间边开发新的边修改BUG。
遇到大的拦路虎要尽量先跳过，StrumMaster要承担起来这种困难。
如果在计划的时间太短则需要抛弃一些story，首先保证此次sprint做出来的东西是可用的。

(4) 演示与回顾
演示就是更新正式平台，把sprint完成的可用的功能全部更新到正式平台中，让用户体
验，在演示会议中，StrumMaster或者测试人员主动的给ProductOwner等实际操作的人员直接演示，如果有条件可以每个人都点击一下，或者给Product部门的人几天的时间让他们反馈。
有些技术性的东西无法演示的时候，选择不演示。甚至如果演示的成本过大则不演示。
回顾主要是总结sprint过程，以便提升。定期制作scrum过程调查，以便调整。