使用GREENHOPPER实施Scrum过程

1. greenhopper本身带有一个scrum issue type scheme, 项目配置成使用这个scheme
issue type有：
Epic： 一大段的需求，这种需求需要拆分。拆分后Epic本身可以resolved，对应的sub-task还可以open放入后续的sprint中
Story: user story
Technical task：需要完成的，但又是业务需求中没有的，以sub-task的形式存在
Bug：jira本身的
Improvement：jira本身的

2. greenhopper有四个custom fileds:
business value:数字类型，度量业务价值，适用于EPIC和story，可以用百分制来度量
Flagged:一个标记字段，标记issues有障碍。 通过planning board中每个card的右上角下拉菜单打标记，标记之后这个card连通它父亲一级的card会标志上一个大大的黄色感叹号，相反的是如果这个小版本发布了，这个card会标上一把绿色大勾。（如何实现小版本大版本？--sub version,master version）
Rank:用于标识product/sprint backlog的优先级
Story Points：复杂度的度量或者需求规模的度量，数字类型，也只适用于Epic和Story

3.Agile菜单
分为四种面板：
planning board: 可以在sprint计划会议上使用, 维护backlog,对issues做时间估算，发布计划，sprint计划
task borad：可以在每日例会上用，sprint进度跟踪，Story进度跟踪，log work，
chart borad：燃尽图，每日例会和sprint 回顾时用，包括Hor burndown,issue burn down,burnup charts等
released board: sprint回顾使用
这几个面板可以设定一个Context，其实就是一个过滤器+排序器的组合，这样可以让面板只显示你想要的东西和按你的要求排序
默认有两个context，
On the fly Context,配置为： 用户修改这个context只会在当前用户有效。（通过context工具栏修改）
default：这个管理员可以修改，改了之后影响所有用户

4.project template
greenhopper提供了一个Scrum的template，内容见 administration - project templates


5.实现有层次关系的版本管理，
如版本1.0包括sprint1 - sprint10 十个版本，那1.0就是master version, 各个sprint就是sub version，
通过planning board - version  view model（版本视图） 来实现这个功能，在sub version - master version右边的编辑按钮中选择它的父版本，编辑之后这个版本会多一个子版本的图标。

6.task board的使用
纵列默认有三列，todo,in progress,done, 将一个card从todo 拖拽到in progress就让这个card变成正在工作中了。默认的comment是不填的，如果需要必填comments，则需要将这个字段配置成必填。
纵列可以通过planning/task board中tools - configuration进行配置，
task board有compat (kan ban)模式，outline模式两种，
outline模式下，有sub-task的issues会分行显示，没有sub-task的issues被放置在OTHER ISSUES中，
Column constraints：在每一列的右上角下拉箭头中有一个Column Constraints的选项，可以设置business value,story points,time remaning ,Standard issue count的最大值、最小值，如果实际统计的值不在最小最大值范围内，那这列就会标红警告。


7.story point和time tracking
time tracking是jira本身的功能，针对所有类型的issues都可以设置，在task board的card 右上角还有个图标可以快速log work
Story points是greenhopper带有的功能，是Scrum的一种时间估算方式，与time tracking类似，time tracking有明确的计量单位：h,d ，分别是小时，工作日，并且会自动换算，如果你设置好8小时=1天，你输入0.5d和你输入4h是等价的，所以倾向于使用time tracking，而不是使用story points，虽然这是Scrum的做法。
但对于Story issues，greenhopper默认会在planning board中显示story points而不是time estimate，这会带来一些不方便。

8.Epic与Story关联
首先需要安装jira-labels-plugin 2.3 (jira 4.0)
然后自定义一个Epic的custom field，类型为Label Field（greenhopper4.3+lable-plugin2.3已经带有了）
之后就可以在story card的Epic/Theme字段填入Epic的 key，这样两者就建立了关系，在planning board中点击Epic card上右下角的show all linked issues就可以在一个弹出窗口中显示所有关联的story.

9.chart board
这里有很多的图，如果business value和story points两个字段没有规划好使用，那这两个字段的图就不可用了。
hour burndown chart是基于time tracking的一个燃尽图，纵轴是remainning hours，横轴是日期，这要求每个issue在original estimate要填好，time log也不要疏忽了，不然这图也没有多大意义。
还有一个issue burn down chart，这个是按问题数目来画的图
这些图有几种线：
guideline:红色的，这是理想情况图
实际图：绿色的，如果不偏离红色太多，说明计划和估计做的不错
required daily rate:这个是按照还剩多少工作量和天数算出来的每日要求的工作效率
虚线的ongoing和trend 不知道有什么意义。
要得到一个完美的图很难。。 需要很好的sprint计划和过程中勤快的记录

10.通过greenhopper操作issues
创建issue，通过create card实现，其中Epic/Story两种类型被定义成需要填入business value和story points，Time estimate在这里就不能输入了。
打印cards，通过planning board - 版本那栏右边有个打印机图标，点击后可以打印出来，打印后再裁剪。

11. rank
rank 字段存在，但不能编辑和查看它的值，这是正常的吗？只能通过拖拽来改变这个字段的值？

 

 

 

附件有个浅白的ppt，参加金融IT聚会贡献的一个topic。