在Redmine backlogs中规划项目方法

前文Release,Sprint,Story和Version的关系讨论了一些基本概念。而且提到

简单来说就是一个Release可以包括几个Sprint，一个Sprint包含几个Story. 当然一个Story可以跨越多个Sprint或者Release。

这句话看上去容易理解，真正做规划的时候要注意方法：

第一阶段：首先明确了产品的最终目标后

专门写了一篇讨论这个。

http://blog.csdn.net/csfreebird/article/details/8918518

第二阶段：定义用户Story和Release,此时有两种方法

方法一：

划分若干Release，每个Release包含了要完成的Story。

方法二：

把产品分解成用户story，这些story放入backlogs中。然后根据story的依赖关系进行分组，自然形成不同的Release计划，从backlogs中移动到不同的Release中。我个人更喜欢这种方法。

注意：

为简单起见，Story不可以跨越Release, 如果遇到这种情况，将这个Story拆分。

然后在每个Release中可以补充其他类型的story，比如技术类的。

创建Release需要使用Redmine的Release tag来创建，参考文档：

http://www.redminebacklogs.net/topics/releases.html

第三阶段：定义Sprint

不需要考虑整个产品发布周期每一个release包含的sprint，仅仅设计当前release需要包含的一个或者多个sprint.

Sprint只考虑团队人手和固定时间内（比如2周）能处理什么Story。所以并不是按照Relase进行设计，而是通过Story和Release发生间接关系。参考：

http://forum.redminebacklogs.net/Releases-Backlog-Sprints-Confusion-td4025677.html

The idea is first to plan stories from the backlog into releases. These stories will show up on the release page then. In the second step, at each iteration (or up front if you wish), stories get planned from the current release into their sprints. Then the sprints show up. Conceptually, Releases tie to stories, not to sprints. Usability on this is not finished yet, and we have an issue discussing releases and sprints on github: https://github.com/backlogs/redmine_backlogs/issues/882

Issue（issue可以表示story或者release)的target version属性用来指定它是属于哪一个sprint。具体将story和sprint关联，并让sprint在release中可见的使用方法参考：

Conceptually, sprints are not directly connectable to releases. They connect implicitely via stories. 

Some terminology: when we talk abount a 'Sprint' in backlogs, we actually use a redmine 'version' - Sprints use the redmine's version. 
There are some places in redmine, where the word 'version' is used - e.g. in the issue detail view. 

Various ways to do the connection: 
 * Go to the backlogs tab and drag a story from the release (right) into a sprint (left). Then this sprint will show up in the releases page. (If there is no sprint, on the backlogs page there is a menu at the product backlog where you can create a new sprint) 
 * If you edit  an issue, you can set a target version. This actually puts a story into the sprint. If the issue is also assigned to a release, that sprint (=version) is visible on the release page. 
 * On the release page, you can right-click  issues and get a context menu, offering to set the Target version (=Sprint) from there. 

Releases in backlogs are meant to help breaking down large backlogs into manageable terms and not required at all to do proper agile development per se. They do not enforce anything. 
 So if you have all your stories in the product backlog, priorize them there, and drag them directly into sprints (as you go and the project develops), you are set for continuous deployment. 
The Releases on top would eventually help to communicate to non-agile customers or to get grip of a vast number of stories - or to support your requirement of planning key features.

如下图，sprint2是通过release1.1.0的左侧的New story菜单创建的。一旦创建，就自动位于左边。

release 1.1.0的所有story都拖动到了左边的sprint2。

一旦有了sprint，就发现自动出现了菜单taskboard，注意必须保证sprint不为空，里面已经包含了story，调整sprint的时间范围。

然后点击taskboard菜单后就能进入并创建task，开始工作了。