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

    最近公司要尝试敏捷开发，我入职没多久，就被要求研究一下如何实现。之前只是听说过敏捷开发，没有真正实现过，经过近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过程调查，以便调整。

 

你太矛盾了，你的原则里明明写着
原则一：个体及交互比流程与工具更具价值
原则二：可用的软件比冗长的文档更有价值
可是你的管理软件还整了那么一大堆。
敏捷开发实践需要坚持！只要你坚持这一点，你会成功的。

整这些软件是为了自动化做的，比如selenium为了回归测试方便，bamboo为了持续集成方便，jira的录入时项目管理的统计以及bug管理等功能
总之这些都是为了减少管理开发人力成本

二楼很有意思。我们应该实践用针去刻硬盘了

二楼说的对

敏捷不是一堆工具组合
也不包含强制执行的制度

上工具之前你们做到了 回归测试 持续集成 项目管理的可视化 ？

回归测试都是有的，  持续集成 项目管理的可视化还没有进行。
敏捷开发的确不是工具组合
主要是考虑到大家对敏捷开发都不熟悉，
所以利用多种工具来圈定一下范围和强制执行一些制度，
没有管理经验，也没有带队经验，感觉应该这样，请大家都说说敏捷开发过程的经验

归纳的比较好，总体感觉你从书本上整理的比较多。
公司之所以让一个试用期的员工来牵头推行敏捷，多少体现了这家公司的保守态度。

要实施敏捷，尤其从传统项目方式上转身过来，是实施效果的不确定酝酿着风险。公司老板最终关心的是回报，而不在乎是否敏捷、中层管理者更多的关心的是自己的职位是否稳定、如果有黑锅是否有人能来背。

两个要点你暂时观察不到：
1. 如何与传统的项目方式衔接，你需要在迭代计划层面上更上一层，考虑发布计划，以及如何跟踪和执行发布计划。由于敏捷项目更倾向于不固定的期限，对于发布计划需要考虑项目缓冲（功能缓冲或者期限缓冲）。推荐你看看Mike Cohn的《敏捷估计与规划》
2. 中高层的意识形态，能否转变过来：例如是否对于加班红利有客观认识，是否认同单元测试代码对于功能代码的意义，是否在管理层有中间力量来推动整个转型，否则敏捷只是一个笑话。这里我强调的，敏捷不只是工程实践，也是项目管理转型。

楼上说的不错. 但我看lz还没到"推行"这一步那,第二点暂不用考虑.

敏捷的核心在于“建立动态需求分析的可能，让功能无限接近需求”。所以快速建立应用，让需求方尽快的参与到项目的设计中是敏捷的关键所在。

我支持你,但是我不看好你们的实施效果.
如果你们现在的开发方式很陈旧的话,那等于是整个流程体系的变更.
而且这个需要中层项目经理的强力推动和上层领导的支持才能实施的.
比如建立符合你们的需求获取分析体系,开发体系,测试体系等,还要进行整体培训.
光靠你调研一些纸上谈兵的方法,很难奏效.