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

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

 

评论

26 楼 volking 2011-03-26  

都是基于理论性的东西，有没有实践的出来的动作可以模仿的？

25 楼 taochenpfj 2011-03-22  

个人认为现在实施为时过早。
有几个问题：
1.楼主的考察和学习，还只限于理论阶段，因为在这个以人为本的管理方式中，需要好好考察的不是方法，而是你的团队。没有看到你对团队的考察，而你写的这些东西，网上，尤其是infoq里面有很多很好的实践；
所以，你如何定位你的团队呢？
2.自己了解是不够的，我吃过这方面的亏，也就是你现在这水平，但是团队的成员不理解。所以，你的培训计划是如何安排的呢？
培训内容强调哪些方面？也就是你需要让团队了解什么？
3.一上来就用这么多软件，有必要吗？既然是团队协作，你们最开始时，先不必上太多软件，一起用纸来处理就是很好的沟通。唯一需要软件的就是你，需要做燃烧线等方面的分析。。。
4.你们领导做好应对风险的准备没？
5.你的团队态度如何？

个人愚见，因为我当年就是在“人”这层上失败了。。。。

24 楼 feiyan35488 2011-03-19  

yushuangyuan 写道

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

你的职位是 项目经理还是技术经理？ 让你做这些工作

23 楼 labchy 2011-03-17  

需要强力的pm支持

22 楼 ymkyve 2011-03-14  

samwong 写道

你好，我现在的公司就是用敏捷开发，而且我本人觉得公司实施得很好，实现敏捷开发有几大好处，这是我在项目中体验出来的，而非来自书本，

第一，实施敏捷开发，可以对发现需求的变更可以快速反应。
第二，对于一个大型项目，实行并行开发或交差开发，用敏捷开发减少冲突。或并行开发时对冲突作及是的更正。
第三，一个再牛的java开发技术员，他可能连最基本的js都不懂,敏捷开发可以使开发员互补知识不足，对开发员的补位有很好的作用,如他开发着一个子项目hibernate，当做完后，他又可能去写js的前端，之后又可能去补位到其它上。这样有助于项目的总体成本的下降。

再引用下,哥们说的很在理

21 楼 ymkyve 2011-03-14  

skzr.org 写道

打击的居多阿

呵呵，兄弟，这个我支持你

既然老大要你研究，你摆正自己的位置阿——你只是辅助老大，是一个参某

这个前期还是要靠老大去走上正轨的，可以参考下文来不断检查

速览：软件开发中的7大浪费

前面有兄弟说要坚持，是的这个是要坚持的，我相信任何事务都是从弱小到大发展的

加油

+1

LZ的总体方向绝对是正确的
由此可见敏捷开发更注重人的作用，更注重人交流，团队协作。
而且这些工具也是很有用的,工欲善其事,必先利其器
楼主所用的这些工具,也是敏捷过程所必须的

不过前面有几位也说到了
首先要有老大来支持做这个事,还有就是不要要求一步到位,把这些都上了
你们公司以前不是这样的开发方式,要一步到位会,会引起其它团队人员的反感(而人又是首要因素)

所以我觉得,楼主所说的方式方法,工具流程都是愿景,但实现过程需要一步一步的来

20 楼 我是来看热闹的 2011-03-13  

螺旋式的所谓scrum。

19 楼 deific 2011-03-11  

方法管理和执行管理高效可靠，并且可控，我觉得项目应该就能成功

18 楼 samwong 2011-03-11  

有兴趣的可以去我的博客转转

http://samwong.iteye.com

17 楼 samwong 2011-03-11  

你好，我现在的公司就是用敏捷开发，而且我本人觉得公司实施得很好，实现敏捷开发有几大好处，这是我在项目中体验出来的，而非来自书本，

第一，实施敏捷开发，可以对发现需求的变更可以快速反应。
第二，对于一个大型项目，实行并行开发或交差开发，用敏捷开发减少冲突。或并行开发时对冲突作及是的更正。
第三，一个再牛的java开发技术员，他可能连最基本的js都不懂,敏捷开发可以使开发员互补知识不足，对开发员的补位有很好的作用,如他开发着一个子项目hibernate，当做完后，他又可能去写js的前端，之后又可能去补位到其它上。这样有助于项目的总体成本的下降。

16 楼 lndalian2000 2011-03-11  

本人水平比较差.

很有幸也参与过敏捷开发.

提醒LZ几点.

1.要有充分的加班准备.特别是你不充分了解项目的很多细节和人员情况的时候.
2.对工具的使用和开发的规范希望你们组的每一个人都非常熟悉.
3.从第二个循环开始.对时间的把握性要逐步精确.
4.确保必要的时候你能申请到足够的资源来应付可能的风险.

15 楼 bonny 2011-03-10  

1，天下武功，无坚不摧，唯快不破。
2，对任何重构或者变化，都能保证代码是安全的

14 楼 tchen8 2011-03-09  

zdyhlp 写道

4到6个小时的计划会议，好像太不敏捷了哦。这么长的会议，效果不会好

这是计划会议正常所需要的时间，estimation比较有挑战，这是迭代计划的基石；所以迭代中的四大仪式：计划、站立式日常会议、演示、总结缺一不可。

每次迭代中总是有效果比较差的某些方面，通过总结（retrospective会议）来获得持续改进，一般几个短期迭代之后随着团队的磨合，效果越来越彰显。

而不必在传统方式下，一个瀑布下来可能半年过去了，总是以为“下一个项目我们会改善”的那些问题，其实永远得不到解决。

13 楼 zdyhlp 2011-03-09  

4到6个小时的计划会议，好像太不敏捷了哦。这么长的会议，效果不会好

12 楼 yushuangyuan 2011-03-09  

sniffer123 写道

建立新的体系，使用新的工具，这会带来重大的学习成本
要知道稳定的开发环境和开发习惯，能带来的效率提升可是非常可观的。
快速的出原型才是敏捷的根本，至于用什么工具，这倒是舍本求末了

这位仁兄说的对，敏捷其实是一种思想。
在实施敏捷前，是否应该先弄明白，为什么要敏捷？
还有你的team是否接受这种思想，目标是否明确？
比起你那些管理工具来说，这是不是更有意义？

11 楼 skzr.org 2011-03-08  

打击的居多阿

呵呵，兄弟，这个我支持你

既然老大要你研究，你摆正自己的位置阿——你只是辅助老大，是一个参某

这个前期还是要靠老大去走上正轨的，可以参考下文来不断检查

速览：软件开发中的7大浪费

前面有兄弟说要坚持，是的这个是要坚持的，我相信任何事务都是从弱小到大发展的

加油

10 楼 sniffer123 2011-03-08  

建立新的体系，使用新的工具，这会带来重大的学习成本
要知道稳定的开发环境和开发习惯，能带来的效率提升可是非常可观的。
快速的出原型才是敏捷的根本，至于用什么工具，这倒是舍本求末了

9 楼 Sunny_kaka 2011-03-08  

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

8 楼 s8186255 2011-03-08  

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

7 楼 强强爱妍妍 2011-03-08  

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