Trelloを開発しているFog Creek SoftwareのDanielさんのブログより
：How the Trello Team uses Trello
※ご本人に翻訳および、Qiita掲載の許可を頂いています。
はじめに
Trelloチームは他の人達よりもTrelloを使っているでしょうか(ええ、私たちはずっとTrelloをたくさん使ってきました)。Trelloを使ったソフトウェア開発管理についてはすでにいくつか良記事がありますが、私たちが日々の業務の中でどのようにTrelloを使っているか興味がある人もいると思います。
Public Development Board
Trelloチームはpublic boardを持っていて、現在ではこんな感じになっています。
このboardではTrelloチームが取り組んでいることの全一覧を見ることができます。boardにはコメントと投票機能が付いているため、一般のTrelloユーザーからのフィードバックを受ける場となっています。
しかし、私たちの多くのタスクはinternal boardで管理されており、一般には公開していません(Fog Creek社員には見えていますが)。こうしている理由として、
- 私達の日々のタスクの多くは一般公開しても、あまりうれしいことがない
- サーバーダウンにつながるようなバグ等の公開は不必要なリスクである
- 時々、こうしてみんなをを喜ばせたいから！
Internal Board
Internal Boardには以下のリストがあります。
- Incoming Bugs (新規バグ)
- Bugs for this week (今週のバグ)
- Planning (計画中)
- Doing (作業中)
- Waiting for test/review (テスト/レビュー待ち)
- Ready for merge (マージ可能)
- Unshippable (まだリリースできない)
- ... ペンディングやリリース済みのバージョン
Incoming Bugs (新規バグ)
Trelloに関するバグは、以下のように報告されます。
- ユーザーからのメール。FogBugzというサービスを使って管理しており、サポートエンジニアがバグレポートを見つけたら、このリストに追加します。
- ユーザーのツイート。
- Fog Creekのほとんどの社員はTrelloユーザーです。彼らは自分でバグを見つけたら、リストに追加します。
- テスターにより発見されたバグ
カードの名前からバグの内容が推測できない場合は、カードの説明部分(description)に詳細を書きます。画像が必要な時は添付します(なるべく簡単にこの操作ができるようにしました。Command-Shift-Control-4して、Command-Vするだけです。すごいと思いませんか？)
バグの重要度が高い場合(例えば多くのユーザーに影響するような可能性があるバグ)は、High Priorityラベル(緑色)を付けます。これにより、カードのプライオリティが高く、QAやリリースプロセスを早く通す必要があることをチームメンバーに知らせることができます。
Bug for this week (今週のバグ)
バグが多くのユーザーに影響する場合、すぐに修正するようにしますが、すべてのバグが緊急を要するわけではありません。このリストは、小さなバグ修正を少しずつ消化していくのに使用しています。
Planning (計画中)
新しい機能を実現するための技術、サービス、UIモック等を時間をかけて計画することがあります。カードがそういった作業の初期段階にあるときに、このリストに置かれます。
やることがたくさんある場合は、チェックリストを使います。
Doing (作業中)
開発者がBug for this weekか、Planningの作業に着手すると、カードをこのリストに移動します。Fog Creekのみんなここを見ることができ、Trelloチームの作業内容を見れます。
カードのタスクが完了すると、コードの位置を示す以下のような注釈を付けてます。
Fixed in daniel/timezone-crasher
(私たちの場合、リポジトリと変更箇所を示すようにしています)
... その後、開発者はコードレビューを始めるため、"Waiting for test/review" boardへカードを移動します。
Waiting for test/review (テスト/レビュー待ち)
新機能やバグフィックスがマージされる前に、以下の2つプロセスを通過する必要があります。
コードレビュー。全てのソースコードはKilnで管理しており、私たちはレビュー機能をよく使っています。
QA。対象のコードがレビューを待っている間、このリストに追加されます。レビューが通ると、テスターのアバターをカードにドラッグして、テスターにカードがチェック可能であることを知らせます。
その新機能もしくはバグフィックスが仕様通り動作していることが検証できると、テスターはカードを"Ready for merge"に移動します。
Ready for merge (マージ可能)
新しい機能のテストやレビューが終わると、開発者はコードをマージして一つのリリース候補を作成し、すべてのカード"Pending version"へ移動します。
そのバージョンはリリースされる前に、ステージングサーバー(本番サーバーとほとんど全く同じ設定のサーバー)にデプロイされます。QAてテスターがチェックを行い、すべての変更箇所が含まれたバージョンの動作確認を行います。変化点のテストの他に、QAテスターはスルーチェック項目を持っており、リリースの毎にチェックを行います。(時々、なにか新しい変更が全く関係ないような別の部分に影響することがあります)
QAテスターのチェックが終わると、カードには"Verified"ラベルが付けられます(私たちは青色ラベルを使っています)
すべてのカードのチェックが終わると、リリースしても大丈夫です！新しいバージョンをユーザーに届けます。新しいバージョンに何か問題があった場合のために、通常なるべく早い時間にリリースしています。
Unshippable (まだリリースできない)
時々、リリースの準備ができた頃に(通常、私たちは新しいリリース用ビルドを行います)、誰かがリリースに影響するようなバグを見つける事があります。そんな場合、カードはここに移動されます。みんなこのリストに登録しているので、リリースできない何かがあればすぐに知ることができます。
(上記のはある時の実在したカードです... 私が行った作業の副作用でこうなってしまいました。ある理由により、リリース前に見つけるとができませんでした。10分後に修正版をリリースしましたが、ユーザーから多くの報告を受け、今でもまだ恥ずかしく思っています。このマヌケなバグのチェックは、今はスルーチェックリストに含まれています)
Pending/Released versions (ペンディングやリリース済みのバージョン)
"1.37.2 (staging)"や"1.29.1 (prod 8/1/2013)"のような名前のついたリストがあります。このリストにはそのバージョンにおける全てのバグフィックスや新機能のカードが置かれます。
新しいバージョンをリリースすると、リリース日のマークをリストに付け、しばらくボード内に残しておきます。これによりみんなが最近の変更を見ることができますし、自分たちの成果を見るのはとても楽しいですですしね。
しばらくするとこのバージョンのリストはアーカイブされます。
(ボードが大きくなりすぎるのを防いでいます)
その他のボードは？
可能ならば、全てのカードをinternal boardで管理します。そうすれば常に一つのboardだけを見ていればよいわけです。逆にboardはとても大きくなってしまいますが、幸運なことに僕達は大きいモニターが使えました。
たまに短い期間の間、ブレインストーミングや反省会のために新しいboardをスピンアップすることがあります。それらのboardの寿命は短く最終的にはアーカイブされます。