チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン

チケット駆動開発の適用範囲について考えたことをメモ。

【元ネタ】
チケット駆動開発の適用範囲: プログラマの思索

Twitter / @akipii: チケット駆動開発にはいくつかのパターンがある。タスクカードのように扱うタスク駆動が一番やりやすい。システム運用保守やコールセンターはインシデント駆動。システム提案や要件定義なら課題駆動。

Twitter / @akipii: チケット駆動開発では僕は課題駆動が一番難しいかもと最近思う。SEは顧客から本質的な問題を見つけるために課題を何度もぶつけて探す。設計書は課題の回答をパッチのように更新して出来上がる。ソースと同じだ

Twitter / @akipii: チケット駆動開発はバグ管理からアジャイル開発へ発展した手法だ。チケット駆動開発をうまく運用できてないチームはバグ管理の基本から見直した方がいい。BTSの一つ一つの機能には今までの世界中の開発者の経験と知恵が込められているのを感じ取って欲しい。

Twitter / @akipii: 影舞、Bugzilla、Mantis、Trac、Redmineに至る歴史を辿れば先人の知恵が分かってくる。BTSの一つ一つの機能には過去の開発者がバグ解決に苦労した形跡がうかがえる。WF型開発でもAgile開発でもSW開発の基本はバグ管理だ。バグ管理を見ればチームのレベルが分かる

Twitter / @akipii: WF型開発とAgile開発ではバグ管理の入り方が違う。WF型開発は信頼性を高めてMTBF(バグが出ない時間)を長くする手法を取る。Agile開発は保守性を高めてMTTR(バグ修正時間)を短くする手法を取る。システムの稼働率を高めるためにAgileとWFは考え方が全く違うのが面白い

Twitter / @akipii: @cointoss1973 Redmineの使い方を他の人はどのように説明しているのか興味があります。Agile開発を重視するのか、厳格なワークフロー管理を重視するのか、GTDのようなタスク管理なのか、課題管理に使うのか。100人分のRedmineの使い方が知りたい。

【1】チケット駆動開発にはいくつかのパターンがある。
一つの観点は、補完チケット方式か完全チケット方式。
もう一つの観点は、トラッカーの観点。

補完チケット方式は特定の工程や特定の作業にチケット駆動開発を適用するやり方。
よくある例は、テスト工程のバグ管理、設計・開発工程のレビュー管理があるだろう。
@machuさんがチケット駆動開発を提唱された時も、テスト工程における細かな作業の管理に使われていた。
その考え方については下記に書いた。

補完チケット方式はチケット駆動開発の先祖返り: プログラマの思索

障害管理からチケット駆動開発へ発展した歴史から見れば、補完チケット方式は先祖返りの開発スタイル。
高機能化したBTSの機能(レポート、ワークフロー、Wiki、SCM連携など)を使えば、より効果的に作業を管理しやすくなるのは当たり前だ。

完全チケット方式はソフトウェア開発で発生する全ての作業をチケット化して管理していく。
以下、完全チケット方式を前提に話を進める。

【2】トラッカーの観点とは、チケットの発生源が何であるか、によって変わってくる。
随分前にも色々考えた。
Redmineを使って気付いたことpart6～チケットの発生源: プログラマの思索

タスクカードのように扱うタスク駆動が一番やりやすい。
GTDのようなタスク管理もできるし、作業指示書として厳格なワークフロー管理の配下に置くこともできる。
僕がアジャイル開発へ適用した時も、タスクカードのように扱うやり方で行った。
要件や仕様の粒度を小さくすることができれば、ストーリーカードのようにチケットを扱ってもっとアジャイルに開発することもできるだろう。

タスクカードのように扱う場合、チケットはすぐに溢れるので、チケットの取捨選択が重要になってくる。
基本は、バージョンをイテレーションに同一視する(「Version is Iteration」)ことによって、アジャイルっぽい開発スタイルになる。
イテレーション単位にタスクを区切っていくタイムボックス的なタスク管理が一番やりやすい。

【3】営業マンや社内の事務の人がITSでタスク管理を行う場合、チケット入力のユーザインタフェースの改良が重要になってくるだろうと思う。
元々チケットは障害報告票が起源なので、入力項目が多すぎたり、複雑な操作になりがち。
それほどITに慣れていない人達にチケット駆動開発に慣れてもらうためには、デスクトップアプリのように使いやすいUIにすることが重要になってくる。
WebならAjaxなりJQueryなりCSSなり、クライアントサイドの技術が必要になってくるだろう。

Redmineのユーザインターフェイスは使いやすい: プログラマの思索

また、WebのUIは一時保存や自動保存の機能が弱いので、せっかく入力した内容が消えてしまってガッカリする時も多い。
そんな場合は、RedmineならDrafts pluginを導入して、自動保存する機能を追加すればいいだろう。

作成途中のチケットを自動保存するDrafts plugin #redmine: プログラマの思索

RedmineでUI改善に可能性を感じる機能は、REST機能だ。
RESTの使い道としては、例えばiPhoneやAndroidなどのスマートフォンからURLを叩けば欲しい情報を取得したり更新したりすることがあげられるだろう。
つまり、スマートフォンやタブレット、TV、携帯ゲーム機などの各種デバイスからサーバーにあるRedmineへアクセスすれば、ブラウザの画面と同じように操作できるUIを作ればいい。
そうすれば、各種デバイス向けにITSの機能を逐一作る必要もない。

RedmineのRESTful APIを使う: プログラマの思索

SOAPからRESTへ: プログラマの思索

RedmineのREST機能は@yohshiyさんの下記のWikiがとても参考になる。

Redmine REST API - r-labs

スマートフォンからRedmineを操作できるならば、外出先で営業マンがタスクを検索したり更新することも楽になる。
あるいは、CIツールJenkinsやテスト管理ツールTestLink、他の外部システムからRedmineへアクセスして欲しい情報を取得したり連携することもできるだろう。
REST機能によるUI改善は大きな可能性を秘めていると思う。

【4】システム運用保守やコールセンターで障害や問合せの管理を行う場合はインシデント駆動になる。
例えば、ネットワーク障害やハード障害が検知されたら、その障害をまず管理票として起票した後、暫定対応を実施したり、影響範囲や根本原因を調査して根本対策を実施したりする。
ITILの概念に慣れていれば、適用しやすいだろうと思う。

ITILのプロセス関連図: プログラマの思索

その場合、技術的に面白い点は、他システムのチケット発行をトリガーとしてチケットを自動登録する機能だ。
よくある例は、障害検知したら普通は障害ログのメールが発行されるタイミングでチケット登録すること。
Redmineにはメールを送付すればチケット登録できる機能があるので、この機能を簡単に実装することができる。

Redmineのチケット登録をITILへ応用する: プログラマの思索

Redmine for ITIL: プログラマの思索

@haru_iidaさんは、Hudson(Jenkins)から発行されるビルドエラーメールをRedmineに投げて、チケットを自動登録する事例を紹介されていた。

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

チケットを自動登録できる利点は、障害の検知から調査、暫定対応、対応完了に到るまでの作業履歴をチケットに集約しやすいこと。
チケットに作業履歴が一元化されれば、その後の運用保守で過去の事例として参考になるし、障害別にレポート出力すれば障害の傾向分析にも使える。

そして、インシデント駆動の場合はタスク駆動以上にレポート機能が重要だ。
普通は障害の発生原因は特定のパターンがあるし、障害が発生しやすい環境を是正する対策作りにレポートがとても役立つからだ。

【5】システム提案や要件定義でチケット駆動開発を運用するなら課題駆動になる。
僕は課題駆動が一番難しいかもと最近思っている。
何故なら、SEは顧客から本質的な問題を見つけるために課題を何度もぶつけて探すからだ。
そして、提案書や設計書は課題の回答をパッチのように更新して出来上がる。

課題管理のチケット駆動開発: プログラマの思索

顧客の曖昧な要望、作れたらいいなという希望から実際に使えるシステムへ変換する作業はとても難しい。
アジャイル開発はその作業の一つの手法だが、多分それだけでは足りない。

もっと基本的な手法が必要な気がしている。
つまり、要望をシステム要件に落とす時、フィージビリティスタディ(実現可能性)をどこまで深く考えているか、という能力に大きく左右される気がしている。
その技術はよりソフトウェア設計の基本的なものだ。
この辺りはもう一度まとめ直す。