ここからダウンロード・インストールできます。
http://www.redminebacklogs.net/en/installation/
- rails 2.3.5
- rubygems 1.3.7
- rack 1.0.1
- rmagick
- i18n 0.4.2
- icalendar
- prawn
- holidays
上記の環境が必要．
% gem install icalendar
% gem install holidays
% gem install prawn
を実行して足りないものをインストールした．
prawn は以前，別のアプリでいれたような気がする(RubyのPDF生成ライブラリだった)．
と思ってたけどインストールされてなかった．
あれ？
% rake redmine:backlogs:install
を行ったときに足りないのは教えてくれるっぽい．便利です。
以下，インストール手順．
Redmineインストールディレクトリに移動して以下のコマンドを実行．
% rake generate_session_store
% rake config/initializers/session_store.rb
% rake db:migrate RAILS_ENV="production"
% rake db:migrate:upgrade_plugin_migrations RAILS_ENV="production"
最後のは昔のデータベースないよって怒られた．つくってないからかな．今回，新たに環境を新しくしているので気にしない．
% rake tmp:cache:clear
% rake tmp:sessions:clear
cd path/to/redmine
% rake redmine:backlogs:install
これ実行したときに，ストーリーに割り当てるトラッカーと，タスクに割り当てるトラッカーを聞かれるがあとで変更できるので適当に．
あとは日本語環境ないので
の下にあるen.yml をコピーして，ja.ymlを生成．
ja.yml をひらいて，上から2行目の"en:" という部分を"ja:" と変更すればOK.
他日本語にしたい場所があれば，このファイルを適宜なおしていく．
余裕と自信があれば，本家にコミットお願いしてみてもよし．
以下，使ってみての感想，気づいたことを適当に．まとまってなくてごめんなさい．
バージョンが入ってないとプロジェクト内のチケットはプロダクトバックログに入るストーリーとして扱われる．
New Storyを選択すると新しくチケット(ストーリー)が作られる．
Redmineの「バージョン」がスプリントになっているっぽい．
新しく作ったProduct Backlogは，スプリントに割り当ててから作業を開始することになる．
これはドラッグ・アンド・ドロップで直感的にできる。
スプリントにたくさんストーリーがあると見づらくなってしまうので、スプリントは短い期間(1〜2週間)で、ストーリーは上司報告用の内容に自分はしている。
BacklogsとReleasesの対応がわからない．Release計画を立てても，そこにストーリーを割り当てられないので自分の考えているのとイメージが異なる．Scrumの理解がまだ甘いか．
いや、このプラグインの理解がまだできていないのだろうな。
チケットにストーリーポイントを持つことができる．
そのストーリーポイント数がリリース計画に表示されるようになる(のかな？)．
タスクに割り当ててもどうなるのか分からないんですが．．．
「Backlogs」の各スプリントの左上の▼をクリックすると複数の項目がリストで出てきて、タスクボードを選択すると、"かんばん"のような画面が表示される．
そこで各スプリントからタスクを新規作成できる．
ここで作成した時に入力したRemaining hoursは，そのまま予定工数に引き継がれる．
また，スプリントの子チケットとして，Redmine上では管理される．
そう、各ストーリーが持つタスクは、チケットの親子関係とおなじになる。
対象バージョンも自動的に割り当てられる．
対象バージョン自体はリリースバックログ，
ストーリーポイントは割り当てられるタスク数．
でもタスクボード表示にすると，右下になぜかイカ娘が表示されるのは勘弁してほしい．．
なので，変更。
vendor/plugins/redmine_backlogs/assets/stylesheets/rb_default/taskboard.css
のimages/ika_bg.pngの箇所を修正した．消してもいいけど，せっかくなので自分の好きな画像(グレートありがとうウサギ)に置き換えた．
グレートありがとうウサギの動画
あと，Backlogからチケットをクリックすると別ウィンドウで開くのは自分は好きじゃない．
そのうち慣れて，開いたチケットの編集終えたら閉じる癖がついたけど．
このプラグインを使うことによって，スプリントに属するタスクをチケットのトラッカーを一つ割り当てる必要がある．
自分は，Taskというトラッカーを作成して割り当てたのだけどそうすると，子チケットのトラッカーは全てTaskというトラッカーになる．
この動きで気になったのは2点．
1. 集計がどのように行われるか
時間集計は，子チケットと親チケットでは別々に集計される．
表示上は，親チケットは子チケットの時間合計+親チケット自身の時間が表示されるが，時間集計プラグイン(worktimeやchartsプラグイン)では時間が重複して集計されることはなかったので安心．
2. トラッカー管理について
どのトラッカーの作業割合が多いかなど集計したいときにcharts プラグインを使用しているが，ここには当然ながらTaskトラッカーもカウントされてしまう．
そのため，Taskのチケットはフィルタリングする必要がある．
自分の運用方法を整理する．
まず，プロジェクトがある．
その中で子プロジェクトをもっと活用することにする．(各プロジェクトにプロダクトバックログとスプリントバックログが入る．)
子プロジェクトをリリースバックログとすればよいかも．
ここからがBacklogsプラグインを使った活用になる。
・バージョンを決める．これがスプリントになる．
・各ストーリを作成する．これはチケットの新規作成 または，Backlogsの”New Story"から作成する．
一つのスプリントの中に複数のストーリーを入れていく手順になる。そして，ストーリーは複数のタスクを持つ．
Backlogsの良いところはステータスの更新がドラッグ&ドロップで出来るところ！直感的！
終了済みに溜まっていくチケットも結構快感です。
あと，Releasesの使い方がわからーん．ちゃんと使い方読むか．．
正直，タスクのトラッカーは選べないので，集計の時に困る．というのは，トラッカーを色々きちんと名前を付けて分けているから．
カテゴリーで分けるかなぁ．．そうするとプロジェクトつくるたびにカテゴリー作らなきゃいけなくて正直面倒．
親チケットの時間のみを使用するような集計プラグインを作ってみるかとか妄想中．
また，このサイトにあるプラグインを入れることでBacklogsの見積もり/作業時間の予実を参照できるようになります．ナイス．
http://d.hatena.ne.jp/coolstyle/20110309/1299651689
このサイト参考になりました．
http://yusuke-kokubo.appspot.com/events/shibutra10/
特に
・ストーリー → したいこと
・タスク → やること
という考え方．
自分の場合、チケットを仕事の中心において回していくことで様々なログをチケットに残していくようになった。また、残していくログがそれぞれのチケット間で関係を持つようになり、一種のデータベースのようになった。
Agileをやろうと決めたメンバーがRedmineをどのようにチームのやり方に合わせて使うか悩むのではなく，Redmineというツールを使って，ツールの使い方を覚えるうちにAgileな仕事の進め方を覚えていく．
通常は、目的があってそれに合うツールを探すと思うんだけど、アジャイルって何？っていうメンバーを巻き込むには、強制的にツールを使わせて言ったほうが体験を通して理解されていくのではと思った。
このやり方は割と受け入れられやすいのではと思った．やった人から広がっていく．そういう連鎖が生まれてくれれば嬉しい．
