執筆中
目次
結局勝手な妄想だけど。。
使い方なんて人それぞれであって、どう使おうと構わないと思っているのだけれど、
プロジェクト管理をやっていると色々な人の使い勝手について意見をもらったりするので
一般的に使えそうな内容について記載しておこうと考えた次第。
プロジェクトを作る判断材料についての考察
プロジェクトを作成する際に粒度をどの程度にするか、判断材料を示してみる
ある程度は長く続くプロジェクトを作成する（短命なプロジェクトは作成しない）
よくある話で「各フェーズ」ごとにプロジェクトを作る人がいる。
または「○○プロジェクト 2012年」というのもよく見かける。
管理者の立場から察するにこの気持ちはよく分かるのだが、意外と使いにくい。
私が考える短命なプロジェクトの最大の欠点は
昔のフェーズで行った内容を引き継ぐことが面倒
である。でも
そのまま使い続けるのはデータベースの検索が遅くなってレスポンスが悪い
ここで作成するのが「サブプロジェクト」だ。
例えば
- まず「○○プロジェクト」を作成する。
- ある程度経って過去のチケットが多くなってきたと感じたら「○○プロジェクト 2012」を作る
- このとき、親プロジェクトに「○○プロジェクト」を指定する
- ついでに管理画面：設定を開いてチケットトラッキングタブを表示して以下のようにしてもいい（速度改善は多少犠牲にするが）
- 「異なるプロジェクトのチケット間で関係の設定を許可」をON
- 「サブプロジェクトのチケットをメインプロジェクトに表示する」をON
- 「○○プロジェクト」から「○○プロジェクト 2012」に移動してもよいチケットをプロジェクトのチケットタブからフィルタリング
- チェックを付けて右クリック⇒移動で「○○プロジェクト 2012」にチケットを移動する
メリットを見てみよう。
- メインプロジェクトである「○○プロジェクト」は継続できる
- チケットの親子関係や、関連付けもそのまま残る
- フィルタ条件に「サブプロジェクト」が表示されるので、「なし」を選べばチケットが表示されなくなる（検索・表示速度アップ）
個人的にこの方法が最もデメリットが無い。
手間もサブプロジェクトを作ってチケット移動するだけ。
オススメ。
メインで使うプロジェクトは、作成する製品単位でプロジェクトを作る（サブプロジェクトはあくまでサブ）
例えば「ooシステム win」とか「ooシステム mac」というプロジェクトを作ってないだろうか？
または納品先のメーカーや納品先のメーカーが出す製品毎にプロジェクトを作っていないだろうか？
管理者の視点としては正しいように見えるし、実際やったことがある。
このようにプラットフォームで分離したプロジェクトは、たとえサブプロジェクトにしても苦情が出ることがある。
苦情のほとんどの理由は、開発者に管理の仕事を強要した時だった。
私が経験した内容を踏まえて書くと、
- 同一チームで各プラットフォームを同時開発していると、煩雑過ぎて使っていられない。
- 開発チームが完全に分かれている場合でも、共有するライブラリやバグの横展開が煩雑になりやすい。
- バグ登録で間違える。上がってきたバグを見落とす。挙句、同じチケットが別プロジェクトに上がってくる。
- 親チケットの共有が難しく、設計や製造の関連付けがややこしくなる。
などがある。
管理者的にもかなり最悪だが、開発者からしてみれば憤り以外の何でもない。
対処法としては、
チケット移動先としてサブプロジェクトを使う
である。
さっき「たとえサブプロジェクトにしても苦情が出る」と書いたじゃないかって？
いやそうじゃない。
管理者としては
- あとで分離するのが面倒だし、
- ガントチャートも見るのが楽
なので、ついつい先にサブプロジェクトを作ってしまう。
うん、それは構わない。
ダメなのは「サブプロジェクトにチケットを作ることを開発者に任せること」である。
それは管理者の仕事だ。
適切なステータス、工程、マイルストーン、進捗を管理してこそ管理者だ。
チケットがどのような経過を辿り、プロジェクト間を移動し、過去バグ保管庫に納めるかを定めるのが管理者だ。
したがって、メインで運用するプロジェクトは「自分たちが開発している製品」で管理することが望ましい。
出荷先情報は、カスタムフィールドで複数指定できるようにしておけばいいし、それを管理するのは管理者の仕事だ。
実はこう考えると、プラットフォーム毎のサブプロジェクトなど必要ないことに気づくはずだ。
カスタムクエリで必要十分なのである。
共有ライブラリの開発ではプロジェクトを作らない（まず親チケットで共有ライブラリを作る）
先に補足すると、「共有ライブラリ単体を製品として作る」場合はこの条件から除外される。
ここで話題に挙げているのは
「まだ“共有ライブラリという製品”になるか分からないのに専用のプロジェクト作るのは止めようぜ」
ということ。
バージョン管理やプロジェクト管理では、「袂を分かつ」ということが重要な意味を示す。
それは
- 「単独で製品になるのか」という問いに「Yes」と答えられる必要が生じる
ことだ。
後述するが、チケットとは機能や工程などを示すもので、その集合体がプロジェクト(＝製品)の完成を意味する。
逆にプロジェクトを完成させても製品として出せない場合は、プロジェクトの分け方を間違えている可能性が高い。
「共有ライブラリ」はそういう状態に陥りやすいので、まずは親チケットから始めるべきだ。
（まぁ・・・そのくらいの意気込みで作る、というのであれば止めはしないが。。。）
ちなみに途中で製品レベルになったら、新しくプロジェクト作って移動させればいい。
その時は管理画面：設定のチケットトラッキングタブで「異なるプロジェクトのチケット間で関係の設定を許可」をONにしておく。
そうすれば関連性を切らずに移動できるので参照も楽だろう。
なお、プロジェクトが完成するために「共有ライブラリ」が必要なのは構わない。
OSS使うようなものだからだ。
親チケットを作る判断材料についての考察
親チケットは階層構造になるので、使い方によっては進捗が飛躍的に伸びるほど有用だ。
しかし誤った使い方をすると無駄どころか、著しく進捗を落としかねない。
そんな玄人嗜好な親チケットの使い方について考察してみる。
親チケットは要求定義を除き、機能で分かれているべきである
管理者がやりがちなことで、「設計工程」やら「製造工程」という親チケットを作ってしまう。
よく分かる。このチケットのガントチャートは見易さが半端ない。
しかしチケット駆動開発を行うには非常に使いづらいことを認識しておくべきだ。
まずはキチンと工程を考えてみよう。
一般的な開発・保守工程はこのようになる。
アジャイル開発だろうがウォーターフォール開発だろうが、粒度が違えど工程は似たようなもの。
そして考えて欲しい。
粒度毎に上記工程を行っている、でしょう？
ある機能を実現するために工程をこなすのであって、製品はその集合体でしかない。
ではこれを踏まえ、チケットの発行手順(とチケット駆動開発の手順)について記載する。
- 機能の抽出のために要求定義のチケットを発行することはよいことだ。
- そして抽出された機能毎に新規機能追加となる親チケットを発行する。
- １つの機能は抽象化されているので、細分化した機能の子チケットを発行する。
- 十分に明確な子チケットが登録されたら、それぞれの子チケットに対し設計チケットを発行して設計をまとめる。
- 矛盾が無いか他の子チケットを見ながら、各機能を形成する子チケットの設計が完了していく。
- 機能毎に連携がある場合はこの時点で関連付けが行われてゆくだろう。
- できればこの時点で機能間のクリティカルパス（先行する or 後続する）の関連付けを行っておく
- 親チケットは子チケットの設計を粒度にあった設計書としてまとめていく。
- 最上位の親チケットまで設計がまとまったらシステムテストの設計書が作れるはずだ。
- 細分化した子チケットについてもテスト項目をまとめていく。自動的に結合テストができていく。
- すべての結合テストが出来上がったら、最も細分化された子チケットに製造チケットを発行する。
- テスト駆動開発も行っているならテストコードを先に作っていくことだろう
- このとき一緒に単体テストチケットが完成していく
- また、必要ならクリティカルパス（先行する or 後続する）の関連付けを行ってゆく
- 製造が完了していくと単体テストがこなされていく
- 機能単位の単体テストが終わった時点で、可能な粒度であれば結合テストを行ってゆく
- 最上位の親チケットが持つシステムテストに移行できるようになる
- 機能が実現されたとき、最上位の親チケットが自動的に「終了」ステータスとなる
「工程」という属性のチケットは、開発では最下位チケットなのである。
そして人間がブレイクダウンしていくのと同じようにチケットが階層を持つことが重要となる。
つまり開発では「機能」が親チケットとなりやすい。
で、開発者に使いやすいと管理者に優しくないんだけど？
さて、上記までで開発者的には使いやすい感じになっているだろう。
しかし、ここからが勝負だ！
これから管理者にも嬉しい形に仕上げていかねばならない。
特に問題はガントチャートで、これが上手く見れるかどうかが非常に大きい。
管理ではむしろ、ガントチャートは詳細情報に分類されるので逐次見るものではない。
後述するバージョンやマイルストーン、スクラムプロジェクトが鍵となる。
親チケットは開発機能・工程に捧げてしまった。
ならば別の手を使うしかあるまい。
進捗率の計上方法を簡単にしてムリしない
まず、余計な手間を省くところから始めよう。
Redmineには２種類の進捗管理方法がある。
- 手動・主観で進捗状態を入力していく
- チケットの状態によって自動的に進捗が変わっていく
ハッキリ言って前者は煩わしくて仕方ない。
（ただ個人的には前者の方がチケットの状況により親チケットの進捗が上がっていくので好きである。見るのが。）
後者の「チケットの状態によって自動的に進捗」を行う場合は以下のように設定を行う。
- 管理画面：設定のチケットトラッキングを選択
- 進捗の算出方法を「チケットのステータスを使用する」に変更する
- 管理画面：チケットのステータスの各ステータスを選んで「進捗 %」の項目を適切な値に変更する
- 「進捗 %」を入れていない項目は進捗率が変わらない。フィードバックとかには便利
- 私がチケットステータスを設定するならこんな感じ
- 新規：[空欄]
こうしておくと子チケットの進捗が変わった時に自動で親チケットの進捗が変わる
- 着手：40%
着手したら一律40%になる。
開発者はそのほとんどが途中の進捗を更新しないので、入れさせるだけ手間である。
- 問合せ中：40%
ローカルだとトラッカーが「要件」になっているものだけ使用している。
仕様の確定やリソースの確保を行う場合に使う。
- 承認待ち：90%
レビューを行う前や、Redmine管理外の人物から許可を得る間に使用。
このステータスになっているものは管理者が集計して手続き・質問・場の提供をする。
- フィードバック：[空欄]
- クローズ：100%
私は「解決」のステータスをどうしていいか分からないので、即クローズしてもらってる。
別に見るのに不便はないし、必要ならリオープンするんで。
- ドロップ：100%
仕様が無くなったり、バグが取り下げられたり、顧客がいなくなｔ（ｒｙ
正常に完了していないステータスは全てこれ。
たまに類似ステータスも用意するけど。
進捗率を見る場所は「ロードマップ」！（ガントチャートじゃない）
本題。
管理者が気にすることは、予定日までに予定のものが終わってくれているかどうかしかない。
開発しかり、要件の明確化しかり、顧客要望しかり、だ。
そういうのを親チケットなどで管理しようというのがそもそも間違い。
これこそロードマップに描かれるべきステータスだ。
ロードマップは「プロジェクトの設定」から行う。
チケットとかガントチャートとかが書いてあるタブの一番右にある項目だ。（デフォルトなら）
この中には「情報」「モジュール」「メンバー」などがあるが、
そこの「バージョン」を選んで欲しい。
最初は何もないので左下にある「新しいバージョン」をクリックしよう。
このような画面が出ただろうか？
#ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (redmine-version-add.PNG) |
表示されたら名称と期日を入力する。
- 名称
- 設計工程－チームA
- 期日
- ２週間～４週間程度のサイクルで入れるとチケット棚卸しが楽かな
すると「チケット」の左横に「ロードマップ」が表示されるようになるはずだ。
#ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (redmine-version-team_a.PNG) |
このバージョンにはまだチケットが登録されていないので何もマップしていない。
適当にデータを割り振ると以下のように表示される。
#ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (redmine-version-team_a-tickets.PNG) |
チケットの進捗が進むと連動して表示が切り替わってゆき、
#ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (redmine-version-team_a-progress.PNG) |
詳細画面を開くとこのような表示になる。
#ref error ：ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (redmine-version-team_a-detail.PNG) |
ここから始めて欲しいこと（リリースでマイルストーンを決める）
いや、書いてもいいんですよ？
明確なリリース日程が数ヶ月も後の話なのに、その数ヶ月後のバージョンだけ置いてあっても意味ないんですから。
それだったらまだ工程管理用に使っている方がマシというものです。
ですが、できればマイルストーンを置くつもりで作っていく方がよいです。
工程も１つのマイルストーンです。
特に工程でマイルストーンが置かれる開発形式をウォーターフォールモデルといいますね。
じゃあアジャイルだと何をマイルストーンにするのかというと、各リリースです。
例えば顧客に動作イメージを伝えたり、要求とのすり合わせを行うことってあるでしょう？
そこまでに実装していなければならない項目をチケットとし、プレゼン用の製品納品日をバージョンにします。
立派なマイルストーンですね。
あとは定期報告会も１つのマイルストーンです。
開発側としてはどの程度まで完了していることを目標にするか、マイルストーンを置くわけです。
注意して欲しいのは、バージョンも増えすぎると管理が煩雑になることです。
見ないとダメになる確認ポイント設置が上手く続けるコツだと思います。
最終更新：2013年01月26日 18:57
