最近は少しずつ関数型言語も学習中。Smalltalkには憧れるがJavaScriptにはどうも馴染めない。
個人的にWebアプリをつくるのが好き。GAE/J + GWTで個人的な家計簿アプリなどをつくって楽しんでいる。
TDDはJavaというかJUnitしかできない軟弱者。CIは他人がJenkinsを動かしてるのを眺める程度。興味がないわけではないが積極的に推進してくれる人がいるので任せてる感じ。
開発プロセスが好き。というか無駄のあるチーム作業が嫌い。個人は暇を持て余すべきだがチームが時間を持て余してはならないと考える。
効率的な開発を進める補助としてツールを使うのが好き。ツールは少しの操作で大きく広範囲に使用できることが望ましいと考える。
逆にルールとして存在するツールは多くの場合、効率化の弊害になるのではないかとも考えている。
ツールができることの意味と実際の開発にマッチさせるためにはどうすればよいのか、と考えることが好き。
より少ない手間で大きなことができるのがソフトウェアとインターネットの存在価値だと考える。
今の会社ではRedmineをすすんで導入してきた。ツールを使うことで得られること、そしてツールを使う人がそのツールにどのような期待を抱くのか、について経験を得られた。
それとともにRedmineを使ってできることの限界も感じはじめた。ツールを使わされている側の人にとっては諸々の入力作業なとが手間にしかならないこともあるし、そもそも何のために使ってるのか考えない人も多い。
その経験を踏まえた上で、ぼくはツールを作り、開発の効率化に貢献したいと思う。
自分が考える最強のALMをつくってみたいと思う。
そんなことを思う、最近です。
Permalink | コメント(0) | トラックバック(0) | 01:11
ツールは手段です。ツールを使用するには目的が伴うのが普通です。
本記事では目的に応じたIssue Tracking Systemの使い方を示したいと思います。
Issue Tracking Systemを導入する目的はなんでしょう？
いろいろ挙げられると思いますが、ここでは次の3点に絞ります。
順番に見ていきます。
要件という用語はユーザーストーリーとして置き換えてもらっても構いません。
ざっくりと次のようなイメージをしてもらえば良いでしょう。
向いているツールに(?)がついてるのは使用経験がないので憶測で書いています。*2
フィードバックがあれば歓迎しますのでお願いします。
プロジェクトの要件だけを管理するパターンです。
詳細なタスクまではチケットにしません。
タスクが細かすぎてチケットを作成するコストが高くなってしまう場合に有効です。
要件の変更、追加などに対応するため、1つ1つの要件は比較的小さくなるでしょう。
作業のトラッキングはリポジトリのコミットコメントなどを活用します。Redmineのようにチケットとコミットを関連付ける機能を持っているツールであると助かります。
要件とタスクを管理するパターンです。
要件はタスクから積み上げられるためざっくりとした題名になりがちです。そのため要件のチケットを終了させるタイミングが難しく、誰のどういう判断基準によって終了と見なすのかチーム内でしっかりと合意する必要があります。
タスクはすべてチケットになっているため外部の人が見た時も状況把握の手助けになります。あとどれだけの作業が残っているのかもメンバー間で認識しやすくなります。*3
またデジタル上でタスク管理する利点として、バーンダウンチャートなどを自動で作成してくれるツールも活用できます。
ちなみに要件とタスクは階層関係になるためチケットも親子関係で作られることが望まれます。*4
課題を管理するパターンです。一般的にバグトラッキングと言えばこの使い方になります。
課題と書きましたが障害やバグと言い換えても良いでしょう。
上述の2パターンと比較すると目的はより明確です。
1つ1つのバグを記録し、解決するためのワークフローを提供します。
「要件管理パターン」はタスクの管理をアナログな方法によって解決することが期待されます。アナログな方法はチームの工夫次第で様々な取り組みをしてよいでしょう。
一方で「要件+タスク管理パターン」はデジタル上でタスクを管理することにより、確実なタスクのトラッキングを可能にします。Issue Tracking Systemと銘打つツールですからトラッキングは重要な要素です。厳密に1つのタスクも取りこぼせない詳細な管理をしたい場合は「要件+タスク管理パターン」が有効でしょう。
おそらく「課題管理パターン」はどのプロジェクトでも必須だと思われます。
そのうえで、必要に応じて「要件管理パターン」もしくは「要件+タスク管理パターン」を組み合わせるようになるでしょう。
冒頭にも書きましたがツールは手段です。目的に応じた使い方をみなさんそれぞれで考えてみてください。
Enjoy!
Permalink | コメント(0) | トラックバック(0) | 16:49
有効ではないと思ってます。
〜 これが正解だとは思ってませんが以下、個人的に思ってることを書きます 〜
Redmineでは標準でガントチャート機能があってチケットの開始日、終了日にあわせてチャートを作ってくれます。初めてRedmineを見る人は、「これを使えば進捗管理ができるんじゃないか？」と思うことでしょう。ぼくも思ってた時期がありました*1。
しかし、実際にチケットをWBSみたいに運用するのはそれなりの労力を求められます。
なぜでしょうか。
メンテナンスに時間を取られることももちろんですが、日付を変える作業のめんどくささが半端なくてRedmineを使うのが精神的苦痛になります*2。個人的にはMS ProjectのUIでも満足できていません。(使いこなしてないだけなのかもしれませんけど)
そもそもスケジュール管理って何をするためのものなのでしょうか？「計画した通りの進捗であることを制御する」ことが目的であるのなら管理するポイントをマイルストーンとして置けばいい話です。
イテレーション開発をしているならイテレーションごとの期日だけを見ていれば十分なのでチケット(タスク)ごとの期日などどうでもよいはずです。ウォーターフォール開発についても同様で、外向けのスケジュールと打ち向けのタスクは乖離するのが日常なのでチケットの期日にこだわってたらいつまでたってもタスクを終了にできません。
そもそもスケジュールを管理するのは誰の責任なのか？チャートの日付と進捗を見るのをスケジュール管理として扱うことが本当に適切なのか？今一度考えてみるべきではないでしょうか。
要件管理だけをするならPivotal Trackerが最適かもしれません。タスク管理だけをするならアナログのホワイトボードや付箋が良いかもしれません。
その他、情報共有したり作業時間の分析をしたりとトータルな管理をするのにRedmineは向いてると思います*3。
ソフトウェア = 少ないコスト → 最大限の効果
が成り立つのが人がソフトウェアを使う大前提であるべきなので、コストが必要以上にかかってしまうスケジュール管理はRedmineには向いていない、というのが(現時点での)ぼくの意見です。
Permalink | コメント(0) | トラックバック(0) | 10:39
