Hatena::ブログ(Diary)

こくぼ@Everything is the experience.

こんにちは。この日記は主にプログラミング関係のことを書いています。
読書と写真を趣味にしています。よろしければこちらもどうぞ。 Flickr , Twitter , github

 

2012-01-23

自分のできること、好きなこと、やりたいこと。

プログラミング言語は主にJavaRuby

最近は少しずつ関数型言語も学習中。Smalltalkには憧れるがJavaScriptにはどうも馴染めない。

個人的にWebアプリをつくるのが好き。GAE/J + GWTで個人的な家計簿アプリなどをつくって楽しんでいる。

TDDはJavaというかJUnitしかできない軟弱者。CIは他人がJenkinsを動かしてるのを眺める程度。興味がないわけではないが積極的に推進してくれる人がいるので任せてる感じ。

開発プロセスが好き。というか無駄のあるチーム作業が嫌い。個人は暇を持て余すべきだがチームが時間を持て余してはならないと考える。

効率的な開発を進める補助としてツールを使うのが好き。ツールは少しの操作で大きく広範囲に使用できることが望ましいと考える。

逆にルールとして存在するツールは多くの場合、効率化の弊害になるのではないかとも考えている。

ツールができることの意味と実際の開発にマッチさせるためにはどうすればよいのか、と考えることが好き。

より少ない手間で大きなことができるのがソフトウェアとインターネットの存在価値だと考える。

今の会社ではRedmineをすすんで導入してきた。ツールを使うことで得られること、そしてツールを使う人がそのツールにどのような期待を抱くのか、について経験を得られた。

それとともにRedmineを使ってできることの限界も感じはじめた。ツールを使わされている側の人にとっては諸々の入力作業なとが手間にしかならないこともあるし、そもそも何のために使ってるのか考えない人も多い。

その経験を踏まえた上で、ぼくはツールを作り、開発の効率化に貢献したいと思う。

自分が考える最強のALMをつくってみたいと思う。

そんなことを思う、最近です。

2011-11-30

Issue Tracking Systemの利用パターン

ツールは手段です。ツールを使用するには目的が伴うのが普通です。

本記事では目的に応じたIssue Tracking Systemの使い方を示したいと思います。

Issue Tracking Systemを導入する目的

Issue Tracking Systemを導入する目的はなんでしょう?

  1. 要件を管理したい
  2. タスクを管理したい
  3. 報告書の元ネタにしたい
  4. 情報を共有する場にしたい
  5. 進捗を管理したい
  6. 課題を管理したい

いろいろ挙げられると思いますが、ここでは次の3点に絞ります。

  1. 要件管理
  2. 要件 + タスク管理
  3. 課題管理

順番に見ていきます。


その前に前置き

要件という用語はユーザーストーリーとして置き換えてもらっても構いません。

ざっくりと次のようなイメージをしてもらえば良いでしょう。

要件(ユーザーストーリー)
お客さん*1が望んでいること、お客さんに提供する価値
タスク
要件を実現するためにすべきこと、TODOと言い換えても可

もうちょっと前置き

向いているツールに(?)がついてるのは使用経験がないので憶測で書いています。*2

フィードバックがあれば歓迎しますのでお願いします。

「要件管理パターン」

プロジェクトの要件だけを管理するパターンです。

詳細なタスクまではチケットにしません。

文脈
  • 要件の変更が激しい
  • タスクが細かすぎる
  • 具体的な作業はアナログで管理したい
解説

タスクが細かすぎてチケットを作成するコストが高くなってしまう場合に有効です。

要件の変更、追加などに対応するため、1つ1つの要件は比較的小さくなるでしょう。

作業のトラッキングはリポジトリのコミットコメントなどを活用します。Redmineのようにチケットとコミットを関連付ける機能を持っているツールであると助かります。

メリット
  • チケットにかけるコストが低い
  • 工夫次第で様々に管理できる
  • 要件しか乗らないのでお客さんとのやり取りにも使いやすい
デメリット
  • タスクが漏れる可能性がある
    • (漏れても気づかないリスク)
  • ツールを見ただけでは要件のステータスを把握できない
向いているツール
  • Pivotal Tracker ◎
  • JIRA (?)
  • Redmine+Backlogsプラグイン(タスクボードは使わない) ○
  • Trac (?)
  • TFS (?)
  • Backlog △

「要件 + タスク管理パターン」

要件とタスクを管理するパターンです。

文脈
  • やることが詳細まで決まっている
  • 作業を抜け漏れなく管理したい
解説

要件はタスクから積み上げられるためざっくりとした題名になりがちです。そのため要件のチケットを終了させるタイミングが難しく、誰のどういう判断基準によって終了と見なすのかチーム内でしっかりと合意する必要があります。

タスクはすべてチケットになっているため外部の人が見た時も状況把握の手助けになります。あとどれだけの作業が残っているのかもメンバー間で認識しやすくなります。*3

またデジタル上でタスク管理する利点として、バーンダウンチャートなどを自動で作成してくれるツールも活用できます。

ちなみに要件とタスクは階層関係になるためチケットも親子関係で作られることが望まれます。*4

メリット
  • 作ったタスクが漏れることがなくなる
    • アナログだと消えたり忘れられたりどこかに飛んでいってしまうリスクがある
  • バーンダウンチャートなどツールによる支援も活用できる
デメリット
  • チケットを作成してメンテナンスするコストが高い
  • 要件を終了させるタイミングが難しい
  • 1つ1つの要件が大きくなりがちなため要件間の重複が発生しやすい
向いているツール
  • JIRA (?)
  • Redmine+Backlogsプラグイン ○
  • Trac (?)
  • TFS (?)

「課題管理パターン」

課題を管理するパターンです。一般的にバグトラッキングと言えばこの使い方になります。

課題と書きましたが障害やバグと言い換えても良いでしょう。

文脈
  • バグをワークフローに沿って管理したい
解説

上述の2パターンと比較すると目的はより明確です。

1つ1つのバグを記録し、解決するためのワークフローを提供します。

メリット
  • 目的が明確であるためツールを選ばない
  • バグを記録するだけなのでチケットの粒度に悩まない
デメリット
  • ツールが多すぎて迷う
向いているツール
  • JIRA (?)
  • Redmine ○
  • Trac
  • Mantis (?)
  • Bugzilla (?)
  • 影舞 (?)
  • Backlog (?)

「要件管理パターン」と「要件+タスク管理パターン」の関係

「要件管理パターン」はタスクの管理をアナログな方法によって解決することが期待されます。アナログな方法はチームの工夫次第で様々な取り組みをしてよいでしょう。

一方で「要件+タスク管理パターン」はデジタル上でタスクを管理することにより、確実なタスクのトラッキングを可能にします。Issue Tracking Systemと銘打つツールですからトラッキングは重要な要素です。厳密に1つのタスクも取りこぼせない詳細な管理をしたい場合は「要件+タスク管理パターン」が有効でしょう。


パターンの組み合わせ

おそらく「課題管理パターン」はどのプロジェクトでも必須だと思われます。

そのうえで、必要に応じて「要件管理パターン」もしくは「要件+タスク管理パターン」を組み合わせるようになるでしょう。


まとめ

冒頭にも書きましたがツールは手段です。目的に応じた使い方をみなさんそれぞれで考えてみてください。

Enjoy!

*1:もしくはユーザー

*2:というかRedmineしか使ってないユーザーの主観なのでアテにしないでください

*3:要件管理パターンの場合はこれをアナログなタスクボードによって解決します

*4:またはそれに類する関係

2011-10-25

Redmine(or Trac or yet another ITS)でスケジュールを管理するのは有効か?

有効ではないと思ってます。

〜 これが正解だとは思ってませんが以下、個人的に思ってることを書きます 〜

Redmineでは標準でガントチャート機能があってチケットの開始日、終了日にあわせてチャートを作ってくれます。初めてRedmineを見る人は、「これを使えば進捗管理ができるんじゃないか?」と思うことでしょう。ぼくも思ってた時期がありました*1

しかし、実際にチケットをWBSみたいに運用するのはそれなりの労力を求められます。

なぜでしょうか。

  • スケジュールに変更が起こった時のメンテナンスコストが高い
  • 開始日、終了日を簡単に変えられるUIではない

メンテナンスに時間を取られることももちろんですが、日付を変える作業のめんどくささが半端なくてRedmineを使うのが精神的苦痛になります*2。個人的にはMS ProjectのUIでも満足できていません。(使いこなしてないだけなのかもしれませんけど)

そもそもスケジュール管理って?

そもそもスケジュール管理って何をするためのものなのでしょうか?「計画した通りの進捗であることを制御する」ことが目的であるのなら管理するポイントをマイルストーンとして置けばいい話です。

イテレーション開発をしているならイテレーションごとの期日だけを見ていれば十分なのでチケット(タスク)ごとの期日などどうでもよいはずです。ウォーターフォール開発についても同様で、外向けのスケジュールと打ち向けのタスクは乖離するのが日常なのでチケットの期日にこだわってたらいつまでたってもタスクを終了にできません。

そもそもスケジュールを管理するのは誰の責任なのか?チャートの日付と進捗を見るのをスケジュール管理として扱うことが本当に適切なのか?今一度考えてみるべきではないでしょうか。

Redmineを有効な使い方

  • 要件管理
  • タスク管理
  • 課題管理
  • 情報共有
  • 作業時間管理

要件管理だけをするならPivotal Trackerが最適かもしれません。タスク管理だけをするならアナログのホワイトボードや付箋が良いかもしれません。

その他、情報共有したり作業時間の分析をしたりとトータルな管理をするのにRedmineは向いてると思います*3


まとめ

ソフトウェア = 少ないコスト → 最大限の効果

が成り立つのが人がソフトウェアを使う大前提であるべきなので、コストが必要以上にかかってしまうスケジュール管理はRedmineには向いていない、というのが(現時点での)ぼくの意見です。

*1:2,3ヶ月くらい

*2:ならない人には向いてるかもしれませんね

*3:別にRedmineじゃなくてもTracでもなんでもいいですが

 
最近のコメント
ページビュー
667096
2004 | 04 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 |
2010 | 01 | 02 | 04 | 05 | 06 | 07 | 09 | 12 |
2011 | 03 | 06 | 07 | 10 | 11 |
2012 | 01 |