プログラマの思索

Redmine Backlogsプラグインを今頃になって入れてみた。
実際に試してみたら、Redmine BacklogsプラグインはScrumプロセスを忠実に実現しようとしているように思えて、すごく感動した。
自分が理解できた部分までメモ。
＃すべての機能はまだ分かっていないので、後で書く。

【1】インストール方法

下記の環境に入れた。

Windows7
java version "1.8.0_11"
jruby 1.7.20.1 (1.9.3p551) 2015-06-10 d7c8c27 on Java HotSpot(TM) 64-Bit ServerVM 1.8.0_11-b12 +jit [Windows 7-amd64]

Redmine2.6.6
XAMPP

JRubyでRedmineBacklogsプラグインを動かす: プログラマの思索

【2】Redmine Backlogsのカード印刷の設定

タイトルとか決めてないけどこのままでもいいかもしんない: Redmine Backlogsのカード印刷(card printing)設定が有効化できない場合の対応

Redmine BacklogsでストーリーカードをPDF出力する時の文字化けを防ぐ方法 - HOW TO GO

redmine\plugins\redmine_backlogs\lib\labels\labels.yaml
を作る
↓
redmine\plugins\redmine_backlogs\lib\ttf
にIPAフォントを入れる

【3】基本的な使い方の参考リンク

詳細は、下記を参考にした。

Redmine Backlogs :: Usage: Product Owner

Redmine Backlogs :: Usage: Scrum Master

Redmine Backlogs :: Usage: Team Member

Redmine Backlogsで簡単スクラム！プロダクトオーナーとして使う編 | 世界はどこまでもシンプルである

Redmine Backlogsで簡単スクラム！スクラムマスターや開発チームとして使う編 | 世界はどこまでもシンプルである

かんばん！～もし女子高生がRedmineでスクラム開発をしたら（4）：「Redmineでスクラム実践！」～アジャイル開発始めました～ (1/3) - ＠IT

かんばん！～もし女子高生がRedmineでスクラム開発をしたら（4）：「Redmineでスクラム実践！」～アジャイル開発始めました～ (3/3) - ＠IT

かんばん！～もし女子高生がRedmineでスクラム開発をしたら（1）：「高校生になって初めてスクラムを始めました」～「ストーリー」で何を作るかまとめよう (1/3) - ＠IT

Ruby - redmineのプラグインredmine_backlogsの(個人的な)設定のお話 - Qiita

【4】Scrumフレームワーク

重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編） － Publickeyによれば、Scrumのフレームワークは下記になる。

a)Scrumのプロセス
・スプリント計画
・デイリースクラム
・スプリントレビュー
b)Scrumのロール
・プロダクトオーナー
・スクラムマスター
・チーム
c)Scrumの成果物
・プロダクトバックログ
・スプリントバックログ
・バーンダウンチャート

【5】基本的な使い方

以下、理解できたことを箇条書きで書いてみる。

【5－1】プロダクトオーナーの使い方

* バックログ画面で、プロダクトバックログから「新しいスプリント」でスプリントを新規作成できる。
　スプリントはRedmineバージョンに対応している。
　注意すべき点は、プラグイン設定画面で、Redmineバージョンに開始日も追加できる。
　スプリント名は｛スプリント番号｝_｛そのスプリントの到達目標点｝にすると良いらしい。
* 「バージョン」を選ぶとRedmineのバージョン画面に遷移する。
* 「Wiki」を選ぶと、バージョンのWikiに遷移する。
　スプリントのテンプレートWikiを事前に作っておけば、プラグイン設定画面の「スプリントのテンプレートのWikiページ」にWikiページ名を書いておくと、スプリント生成時にバージョンのWikiをテンプレートからコピーして生成してくれる。
　Ruby - redmineのプラグインredmine_backlogsの(個人的な)設定のお話 - Qiitaを参照。

* 「新しいストーリー」でストーリーカードを新規作成できる。
　 作ったストーリーに対して受け入れ条件を説明欄に記入する。普通はPOが書く。
* ストーリーポイントを付ける。ストーリーポイントは、プラグイン設定画面で、フィボナッチ数で登録しておく。
　ストーリーポイントは持ち帰ってチームと相談して付けるか、チームに付けてもらう。
* スプリント内のストーリーは、優先順位は並び順になる。プロダクトオーナーが優先順位付けする。プラグイン設定画面で、Redmineの優先度も別途追加できる。
　プラグイン設定画面で「新しく作成されたストーリーが追加される位置」で「下に」を選べば、新規ストーリーは最下位に登録される。
　チームは上から順にストーリーをタスク化して消化する。Redmineのチケット一覧画面よりも、優先すべきタスクが分かるので良い機能。

* リリース画面
　複数のプロダクトバックログを管理する画面。
　「リリース」を新規作成すると、プロダクトバックログの中で、開始日・終了日ごとにカテゴライズできる。
* リリース配下のストーリーをスプリントへ移動すると、リリースとスプリントが紐づけられる

* リリースマルチビュー：複数のリリースを束ねたビュー。「リリース」タブから、該当リリースに含まれているストーリー、スプリントの情報が表示される。
　例えば、「1次開発」マルチビューの下に「6月リリース分」「7月リリース分」のリリースを紐付ける。
　
* 「リリース」を使うと、プロダクトオーナーは各スプリントで実施する前の計画段階で、一つの製品のリリース計画を「リリース」ごとにカテゴライズして計画できる。
　但し、Redmineのロードマップ機能とは関連付けられていない。

* スプリントの状況を確認するには、バーンダウンチャートを選ぶ。
　かなり細かい情報が表示される。
　
　理想時間：残のストーリーポイント数。デフォルトでは、理想時間の計算からは土日が外されている。プラグイン設定画面で「土曜と日曜をバーンダウンに含める」をONにすれば土日を含めることも可能。
　残り時間：ストーリーの残り時間の合計。タスクカードの残り時間から計算。
　承認されたポイント：ストーリーポイントの増加をグラフで見る。スプリントの途中でストーリーが増えてうまくスプリントが回らない場合に使うと良い。
　着手すべきポイント：POにリジェクトされて受け入れられなかったストーリー。
　解決すべきポイント：解決していないチケット。「着手すべきポイント」「解決すべきポイント」のチケットはいずれも、プロダクトオーナーなどにCloseを確認してもらう。

* スプリントの終了は、Redmineのバージョンを「完了」にする。
　スプリントのWikiに、打合せやレビューなどスプリントに関する情報を記録する。
　終了しないストーリーは、チケットの「コピー」を選択するとチケット編集画面に「元のストーリーへのリンクを含める」「タスクをコピー」を選択できる。つまり、次スプリントにストーリーをCopyするだけでなく、発生元のリンクも残してくれる。

* 「リセット」はスプリントを途中で中止する機能。警告メッセージがとても丁寧。

「このスプリントをリセットする際の注意！！
本当にスプリントをリセットしますか? スプリントのリセットは
ストーリーとタスクに次の影響があります:
* 作成日はスプリントの開始日に設定されます
* コメントを除いた全てのストーリーとタスクの変更は削除されます
* 現在の値は、全てのストーリーとタスクの初期値になります
* ステータスはチケットのデフォルトのステータスになります」

【5－2】スクラムマスター・開発チームの使い方
* スプリントメニューから「かんばん」を押すと、該当スプリントのかんばんに移る。
　担当者ごとに異なる色でタスクは表示される。

* ストーリーカードが左欄に表示され、プラスボタンを押すとタスクカードを登録できる。
　裏では、ストーリーカードが親チケット、タスクカードが子チケットになっている。
　タスクカードには残り時間を記入できる。残り時間はTOCのバッファ管理に使えるだろう。
　タスクカードの担当者、作業者のユーザID、コメント、作業時間も入力できる。
　作業時間はRedmineチケットのデフォルト機能の実績工数。その時の作業者の工数が作業者のユーザIDに対応する。
　かんばん上でドラッグ＆ドロップでタスクカードを移動できる。毎日、常時最新化する。
* タスクの担当者の色は、Redmine右上の［個人設定］で［バックログ］の［Task color］でタスクの色を変更できる。

* プラグイン設定画面で「タスクの状態へのストーリーの追従」で「全てのタスクがクローズされたときクローズ 」を設定すれば、フック処理が動くので、ストーリーカードを逐一、終了ステータス更新する必要がなくなる。
* 「スプリント障害事項」は、タスクカードを妨害する発生源の課題。
　「スプリント障害事項」チケットのブロック欄にチケットIDをカンマ付きで登録すると、Redmineの関連チケットの機能「ブロックされている」で紐付く。これは凄い。
　つまり、ブロック元の課題チケットが解決されなければ、タスクカードは完了ステータスにできない機能をRedmineの機能で実現している。
　プラグイン設定画面で「バックログとかんばんの自動リフレッシュの間隔」を設定すれば、かんばんのタスクカードを最新化した時に自動的にその状態がバックログにも反映される。これは便利。

* スクラム統計：
　リリースやスプリントに関する最新の進捗報告書に近い。

【6】他の機能

Redmine Backlogs :: Advanced topicsに書いてある機能が完全に分かってない。

Redmine Backlogs :: Releases
→「リリース」機能。
　リリース計画に相当する。

Redmine Backlogs :: Release graph
→「リリース」機能に関するバーンチャート。
　プラグイン設定画面で、「リリースバーンアップチャート (実験的機能)」をONにする。
　リリースグラフから何が分かるのか？
　「リリース」に関係付けられたストーリーの集合から、各スプリントのVelocityやストーリー消化具合が分かるが、それが何を意味するか？
　「リリース関係」にある「追加」「継続」「初期」「自動」の使い道が分かってない。

Redmine Backlogs :: Release multiview
→リリースマルチビューは複数の「リリース」を束ねたもの。
　複数のリリースのバウンチャートを組合せたい要望から生まれた。
　リリースマルチビューのリリースバーンチャートから何が分かるか？
　プロジェクトの進捗、スコープ変更の内容とどのように関連付けられるか？

Redmine Backlogs :: Sharing sprints/releases
→プラグイン設定画面で「バックログの共有」をONにする。
　「新しいスプリントを共有」で選べる項目はRedmineバージョンの継承設定と同じ。
　下記の説明がある。
　
　新しいスプリントは、ユーザーとプロジェクトのパーミッションに従い共有されます。
　システムで共有できるスプリントは管理者のみ作成できます。
　階層とツリーで共有されたスプリントは最上位プロジェクトのパーミッションが必要です。
　
　たぶん、スクラム・オブ・スクラムを実現するツールと思われる。
　例えば、「Single team, multiple projects」は1個のチームが複数システムを保守している場合。
　例えば、「Multiple teams, single project」は大規模受託案件で、サブシステム単位に各チームが担当している場合。

【7】上記のように、Redmine BacklogsプラグインはScrumプロセスを忠実に実現しようとしている。

個人的には「スプリントのリセット」がデフォルト機能に含まれているのに感動した。
実際のプロジェクトでは、プロジェクトの中止の判断は開発チームにもプロジェクトリーダーにも存在しないから、走り出したら止まらない、という怖い一面がある。
特に、要件定義や受注の段階で、失敗する可能性の高い案件は山ほどあるだろう。
だから、ごく稀だろうが「リセット」する勇気も必要な時もあるだろう。

また「リリース」「リリースマルチビュー」「リリースグラフ」機能のように、リリース計画の作業をサポートするような機能を付けているから、使いこなせれば、かなり効果が上がるのではないか？

但し、Scrumで感心すると同時に難しいと思う点は、Velocityの計測とVelocityの安定だ。
つまり、バーンダウンチャートを綺麗に表示させること。
Velocityを毎回計測することによって、リリース計画の精度は理論上良くなる。
しかし、実際の作業では、毎回のスプリントのVelocityを安定させるのは難しいはずだ。

スプリント中のタスクの順序や依存関係、リスクを常に把握できていればよいが、その判断が大きく間違ったら、Veclocityは大きく狂ってしまう。
Velocityが安定しなければ、リリース計画に響くし、顧客などのステークホルダーの信頼関係にも響く。

この辺りのノウハウはまたまとめてみる。