日経コンピュータ(2009/11/11発売)の特集記事「幸せを呼ぶアジャイル開発 30年前の改善魂を取り戻せ」に、チケット駆動開発の内容が現場の事例の一つとして掲載されている。
その記事の中にある一文に惹かれた。
ツールがサポートすれば、メンバーの働き方が変わっていく。
行動が変われば考え方も変わっていく。
似たような言葉として、松井秀樹が恩師から言われた言葉がある。
心が変われば行動が変わる。
行動が変われば習慣が変わる。
習慣が変われば人格が変わる。
人格が変われば運命が変わる。
何か似ていると思いませんか？
後者の言葉はトップダウン。
心が変われば人生を変えられる。
前者の言葉はボトムアップ。
ツールで行動を変えれば、考え方が変わる。
ツールでプロセス改善する発想も、前者と同じ。
ツールでSW開発のあり方、考え方も変えるのだ。
| 固定リンク | コメント (0) | トラックバック (0)
NoSQLという単語が最近流行しているらしい。
【元ネタ】
masuidrive on rails - NoSQL – SQLはもう古い?
NOSQL(Not Only SQL)ムーブメント - おおたに6号機blog
NoSQL - Wikipedia, the free encyclopedia
言わんとすることは、RDBからkey-value storeへの流れ。
普通のWebシステムならば、RDBで十分使える。
しかし、ユーザ数やトラフィックがとてつもなく膨大な場合、データベースのパフォーマンスに問題が出てくる。
Webサーバーのスケールアップは、サーバーの増設で対処できるが、RDBのスケールアップが難しいのだ。
ApacheのCouchDB(Erlangで作られている)、GoogleのBigTable等のkey-value storeはいずれも、データストアをいかにスケールアップしやすくするか、と言う観点で作られていると考えれば、その方向性も理解しやすくなるだろう。
| 固定リンク | コメント (0) | トラックバック (0)
2009/11/23に、PFP関西ワークショップ#20-AgileNight2009が開催されます。
CMをどうぞ。
| 固定リンク | コメント (0) | トラックバック (0)
ソフトウェア開発の特徴で良い記事があったのでメモ。
【元ネタ1】
ソフトウェア開発組織はオーケストラ：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェア開発で伸びる人，伸びない人【第二版】：柴田 芳樹 (Yoshiki Shibata)：So-net blog
荒井さんの本「ソフトウェア開発で伸びる人、伸びない人 【第二版】 (技評SE選書)
「特別付録 音楽とソフトウェア開発」という章が面白かった。
ソフトウェア開発組織はスポーツではなくオーケストラ。
個人のスキルは前提条件であり、協調するのが大事。
一人のスキルが低いと、演奏する音楽全体の品質が落ちる。
オーケストラでは、指揮者(プロジェクトマネージャ)以外に、副指揮者(プロジェクトリーダー)、コンサートマスター(アーキテクト)の役割が必須。
管理者の仕事が3人に分かれているのに注意。
SW開発の大規模プロジェクト(数十人以上)も同様に、管理者の役割が分化されるはず。
アジャイル開発のような小規模チームでは、管理者が役割を兼務する時が多い。
バッハやモーツァルトもその時代の音楽楽器の技術をフルに使うことで、優れた楽曲を残した。
IT技術も、その時代に合った技術をフルに使えば、ベターなシステムが作れるはず。
しかし、IT技術は陳腐化が激しいので、システムの寿命も本来は短いのかもしれない。
【元ネタ2】
「ソフトウェアは工業製品ではない」 まつもとゆきひろ氏：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェアエンジニア：柴田 芳樹 (Yoshiki Shibata)：So-net blog
日本のITベンダーのプロセス改善に何故、違和感を感じるのか？
彼らのプロセス改善の根底には、アートを作るのではなく、工業製品を作っているイメージがある。
ソフトウェア開発のプロセスが細分化されて、プログラミングではなくコーダになっている。
【元ネタ3】
ソフトウェアエンジニアの成長カーブ：柴田 芳樹 (Yoshiki Shibata)：So-net blog
開発チーム（組織）の成長：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェア開発において、成長できない組織や個人は、プロセス改善できない。
ソフトウェア開発においてプロセス改善するには、プログラミング技術が時代に乗り遅れないように、常に磨かなくてはいけない。
| 固定リンク | コメント (0) | トラックバック (1)
Redmineをホストごとに作るためのシェルスクリプトが公開されていたのでメモ。
【元ネタ】
10分でredemineのホスティングサービスを作る | 半袖野郎 blog.hansode.org
社内の一つの部でRedmineを使う場合、問合せ管理だけなら一つのRedmineでよい。
Redmineの複数プロジェクト機能を目的ごとに使い分ければ更に管理しやすくなる。
しかし、開発と運用保守を兼ねる小プロジェクトが多いならば、ホストごとに作った方が管理しやすいだろう。
| 固定リンク | コメント (0) | トラックバック (0)
Redmineのチケット集計機能で良いプラグインがあったのでメモ。
いずれもマイグレーションが不要で、Redmine0.8.4で動作したから、ver0.8.xで大丈夫だと思う。
【元ネタ1】
Redmineプラグイン開発 - 大豆プラグインがとりあえずできた - フジハラボ -- 目指せ！スーパーエンジニア
このプラグインは、期間を指定後、下記を集計出力する。
1-1・担当者指定でチケット一覧を表示
1-2・トラッカーの時間コスト(実績工数)を出して、円グラフなどでグラフ化する
1-3・バグの種類を分析して、円グラフなどで表示する(チケットに「原因」というカスタムフィールドを追加し、バグという名前のトラッカーだけ入力)
1-2の機能は、実績工数の分布を集計してくれる。
この機能によって、テストやバグ修正に時間が取られているか、開発や設計などの上流工程で時間を取られているか、分析できるから、リスク分析に使える。
また、1-3の機能は、リリース後の障害分析で重要な機能だ。
この機能によって、バグの原因がリリース作業の不注意から生じたのか、コーディングミスなのか、設計漏れなのか、分析できるから、プロセス改善の資料の元ネタになる。
リリース後のふりかえりMTで各種の集計レポートがあれば、開発者の意識も変化させる事ができ、その後のチームの成長に役立つだろう。
【元ネタ2】
Redmineプラグイン開発 - Roadmapsプラグインリリース - フジハラボ -- 目指せ！スーパーエンジニア
このプラグインは、ロードマップの各バージョンの詳細情報(開始日・終了日・予定工数・実績工数)を一覧できるように改良している。
この機能は、Redmine標準のロードマップ機能を強化してくれる。
XPの計画ゲーム、あるいは、リリース計画やイテレーション計画は、ロードマップ画面で行うから、できるだけ機能強化されるべきだ。
RedmineがTracよりも優れている点の一つが、ロードマップ画面に各バージョンの情報を一目で一覧できることだと思う。
Tracのロードマップ画面は終了チケットの割合しか表示しないので、実際のプロジェクトの進捗情報を読み取りにくい。
Redmineのデフォルトのチケット集計機能はサマリと工数レポートだけしかないし、ロードマップ機能も進捗とチケット一覧しかないが、プラグインで機能強化すれば、リスクを早めに嗅ぎ取り、問題が起きる前に対策を早期に実施できるはず。
他のプラグインも試してみたい。
| 固定リンク | コメント (0) | トラックバック (0)
チケット駆動開発にPMBOK
＃あくまでもラフなメモ書き。
【元ネタ】
redmineの wikiマクロで graphviz その1 - あぁ そうだった
結構ややこしいぞ！ アーンド・バリュー計算と分析－ ＠IT自分戦略研究所
Redmine - PluginBudget - Redmine
【1】PMBOK
クリティカルパスを見るには、ガントチャートではなく、PERT図を描いて追跡しなくてはならない。
ガントチャートは、PERT図やクリティカルパスから導出される、顧客向けの進捗資料に過ぎない。
Redmineチケットの関連に「先行する」という機能がある。
これは、MSProjectでWBSを作る時のFS関係に相当する。
すると、この機能を上手に使って、Redmine上でPERT図、更にはクリティカルパスを表現できないか？
イメージはこんな感じだ。
まず、WBSの最小単位をチケットとし、FS関係をチケットの関連リンクの「先行する」機能で表現する。
チケットには、開始日・終了日・予定工数の属性が付与される。
つまり、PERT図で使われるマスタデータを全て、チケットとその関係で表現し、Excel上で作りこんでRedmineへ一括インポートする。
次に、Redmine上で、FS関係をGraphvizで表現して、PERT図へグラフ化する。
つまり、全チケットのFS関係を下記のようなGraphvizファイルへ変換し、GraphvizでPERT図へ自動変換する。
pert_diagram.dot
digraph pert_diagram {
ticket1 -> ticket2;
ticket1 -> ticket3;
ticket2 -> ticket4;
ticket3 -> ticket4;
}
↓
Graphvizで変換した図：pert_diagram.gif
クリティカルパスを計算するには、バックトラッキング機能を使えば、再帰的に計算できるはず(多分)。
Haskellならば、上記の関係を正しく表現できれば、クリティカルパスを自動計算できるだろう。
上記の生成したPERT図に、チケットへリンクする機能があれば、もっと良いだろう。
【2】PMBOK
EVMで重要なのは、SV(スケジュール差異)とCV(コスト差異)だ。
プロジェクト期間中のある時点で進捗やコストを計算した時、スケジュールが遅れたり、コストがオーバーすると、SVやCVが負の値になる。
特に、ITプロジェクトに工事進行基準が導入される経緯を考えると、PVやSVを自動計算できる仕組みが欲しい。
Redmine上でEVMを表現できれば、進捗の遅延やコストの負荷をリアルタイムに追跡できるはず。
Redmineチケットで、CVやSVを表現するには、チケットの属性に「コスト」の情報が必要になる。
Redmine本家のプラグイン一覧にあるPluginBudget - Redmineが使えないだろうか？
つまり、チケットへコスト(金額)を入力できれば、予定工数・実績工数の差異から、SVだけでなく、CVも理論的には計算可能。
上記はあくまでも、Redmineでできたらいいな、というアイデア。
チケットという概念には、大きなポテンシャルがあると思う。
| 固定リンク | コメント (0) | トラックバック (0)
チケット駆動開発を運用する上で、あった方がよいと思う運用ノウハウをプラクティスとしてピックアップしてみる。
なお、下記には、他の人のアイデアも含まれているので、引用先をリンクしておく。
【元ネタ】
脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所
チケット駆動開発のベストプラクティスを収集したい: プログラマの思索
チケット駆動開発 - Live a meaningful Life
チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)
2009-09-17 gitだからこそできるチケット駆動開発のやり方- kunitの日記
１・チケット・ファースト(Ticket First)
プロジェクトの作業はチケットを受け取ってから始める。
作業が発生したら、まずチケットに起票してから始める。
このルールが徹底されて初めて、チケット駆動開発が始まる。
そして、チケットはXPのタスクカード(作業指示書)として扱う。
すると、チケットに作業履歴が残り、運用保守で検索しやすくなる。
進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアルタイムに進捗情報を出力できる。
チケットを成果物の単位で作ると、作業しやすくなる。
例えば、「設計書を作る」「機能Aを作る」「バグを直す」「テスト仕様書を作る」など。
つまり、チケットはWBSから作り出すこともできる。
この手法はPMBOKにも流用可能のはず。
２・チケットはシンプルに
チケットの入力項目やワークフローは必要最低限にし、シンプルにしておく。
チケットに必須項目や入力項目が多いと、開発者がチケットの更新に億劫になり、チケットに最新の状態が反映されなくなってしまう。
特にワークフローが複雑な場合、メンバーが慣れるのに時間がかかり、TiDDの威力が半減する。
リリース後のKPTによるふりかえりMTが、チケットの運用を見直すタイミングになる。
リリースをこなしながらチケットを改善していけばいい。
３・分割統治(Divide and Conquer)
プログラミングと同様に、タスクは分割して統治する発想が大事。
複雑なタスクはWBSでツリー構造に階層化したり、分割する。
この時、分割統治の観点として、チケット・イテレーション・プロジェクトの3つがあると考える。
3-1.チケットで分割統治
僕の経験では「一つの成果物を一人の担当者が１～５人日以内で完成させる作業」まで細分化するのが良いと思う。
実際は、リリース後にチケットを集計してみると、チケット1個の工数は1人日以下になっている時が多いと思う。
理由は、新規開発後のテストでバグ修正や、顧客からの問合せ(障害修正・改善要望)など、開発チームが予想していたタスクの規模を超える時が多いから。
タスクが増えすぎた場合は、小規模リリースやチケットの関連付け、他の分割統治のプラクティスで対応する。
又、遅延したチケットは作業しやすいように分割した方がいい。
例えば、機能追加のタスクなのにリファクタリングに時間がかかっているチケットは、リファクタリングと機能追加のタスクに分ける。
開発者が作業しやすいように、コミュニケーションを取りながら、臨機応変に行えばいい。
他に、GitやMercurialのような分散バージョン管理を使っているならば、2009-09-17 gitだからこそできるチケット駆動開発のやり方- kunitの日記のように、チケット単位でトピックブランチを作る運用方法もあるだろう。
3-2.イテレーションで分割統治
細分化されたチケットは、リリース計画やイテレーション計画に基づいて、各イテレーションにアサインされる。
チケット駆動開発やRedmineでは、イテレーションをリリースバージョンと同一視するため、小規模リリースを実現でき、自然にアジャイル開発になる。
チケットをどのバージョンでリリースするか、という取捨選択や、イテレーション内部でのチケットの優先順位付けがプロジェクトマネジメントそのものになる。
アジャイル開発と同様に、チケット駆動開発でも、イテレーションを上手に使うのが重要だ。
僕がよく使う手法として、バージョンと対応されない特別なイテレーションとして、「バックログ」や「内部課題」を作っている。
「バックログ」は、顧客から寄せられた改善要望のチケットを貯めるイテレーション。
例えば、リリース直後に寄せられた膨大な改善要望は、バックログに溜め込んで保留とし、障害修正など、本番運用の安定に力を注ぐ。
そして、本番運用が落ち着いたら、バックログに溜まったチケットの難易度や優先度、予定工数などを洗い出し、リリース計画を立てて、チケットを各イテレーションへアサインしていく。
つまり、「バックログ」はScrumのプロダクトバックログのように、要望を一旦受け付けてフィルタリングし、リリース計画を立てる場とする。
即ち、XPの計画ゲームをバックログのイテレーションで行っているようなものだ。
又「内部課題」は開発者から寄せられたチケットのうち、優先順位が低い作業やいつやるか未定の作業を溜め込むイテレーション。
例えば、このソースはリファクタリングした方がいいが今手を付ける必要はない、とか、だいぶ先の予定作業などの備忘録。
そして、リファクタリングした方がいい機能を修正するタイミングで、進行中のイテレーションへチケットを移動して、リファクタリングも同時に行う。
あるいは、来るべき時が来たら、チケットをイテレーションへアサインしていく。
つまり、「内部課題」は開発チームのリスク管理を行うイテレーションだ。
「内部課題」のイテレーションを備忘録として使い、作業漏れをなくす。
特に、リファクタリングが必要な箇所はファウラーが言う技術的負債そのものだから、工数見積もりのリスクに直結する。
故に、システムのリスクに直結する情報は積極的にチケットへ登録する雰囲気作りが重要だと思う。
「バックログ」も「内部課題」も終了期限の無い特別なイテレーションとして扱うのに注意。
3-3.プロジェクトで分割統治
プロジェクト単位でチケット管理する状況は、顧客からの問合せと開発のタスクを分けたい時が多いだろう。
つまり、インシデント管理と実際の開発は、BTSの複数プロジェクト機能を使って、プロジェクト単位で管理する。
この方法によって、開発チームは、開発と無関係なインシデントのチケットを意識することなく作業すればいい。
他の例としては、大規模プロジェクトで、サブチームごとにタスク管理したい場合や、サブシステムやコンポーネント(jar, dllなど)の単位でタスク管理したい場合があげられるだろう。
４・No Commit, No Ticket
TiDD提唱者のまちゅさんが「チケット無しの成果物のコミットは不可」というルールをこのプラクティスで呼んでいたので、引用させてもらった。
チケットファーストのルールに従うと、必ずコミットする時にチケットNoは存在する。
つまり、修正意図の不明なコミットを排除する意味が込められている。
このルールのおかげで、運用保守時にリバースエンジニアリングしやすくなる利点がある。
５・チケットは常時最新に
八朔さんがTiDDで最も重要だと述べたプラクティス。
チケットに登録したとしても、進捗や情報が更新されないと、BTS上で最新の進捗情報を確認できなくなる。
特に、リリース直後に問合せや障害が大量に発生して、チケットが乱発されたり、放置されたりする時に起きやすい。
だから、チケット管理の責任者が常にチケットの状況を見ておく必要がある。普通はプロジェクトリーダーがその役割を担っているだろう。
大規模プロジェクトでは、専門のチケット管理者を配置して、進捗確認させるといいだろう。
また、チケット更新やSVNコミットのタイミングで関係者へメール送信する機能を使えば、気付きやすくなる。
他に、RedmineやTracでは、活動欄でSVNリポジトリ・チケット更新・Wiki更新などの履歴が表示されるので、最新情報を見る事ができる。
故に、活動ログの活発具合が開発チームの活発度に直結するので、注意した方がいい。
６・チケットは関連付ける
八朔さんの運用方法では、チケットは、要件-成果物-作業のツリー構造で関連付けられる。
このやり方ならば、チケットをタスクカードだけでなく、ストーリーカードとして扱う事もできる。
あるいは、複雑な機能を実装するチケットを分割した場合、関連するチケットをまとめるために、Redmineの関連リンク機能を使えばいいだろう。
僕がよく使う方法は、マージ作業が発生した場合、マージ作業のチケットに発生元のチケットを関連リンクさせておく。
これによって、マージ作業の意図を関連元のチケットから理解しやすくなる利点がある。
７・小規模リリース(Small Releases)
チケット駆動開発では、リリースバージョンをXPのイテレーション、Scrumのスプリントと同一視してアジャイルに開発していく。
RedmineやMantisでは、ロードマップ画面がイテレーション計画を行う機能になる。
そして、リリースされたイテレーションに紐づくチケットは、変更履歴画面でChangeLogとして残る。
この2つの機能おかげで、BTS上でリアルタイムに進捗情報や、リリース履歴を簡単に確認できる。
８・朝会
チケット駆動開発を実践すると、自然に朝会をするようになった。
朝会でロードマップ画面を見ながら、誰がどのチケットを担当していて、進捗が遅れているなら何が問題なのか、を議論する場になる。
朝会は、コミュニケーションが始まる場であり、リスク管理を行う場でもある。
９・ペア作業
Redmineの柔軟なワークフロー機能を使っていると、チケットは必ず2人の手を経て終了するようになった。
例えば、チケットを終了できる権限はプロジェクトリーダーのみとし、彼が承認したら終了できる。
あるいは、バグ修正のチケットは、開発者とテスターが交互にステータスを更新しながら検証していく。
XPのペアプロと異なるが、1枚のチケットを2人以上の手が加えられているので、ペア作業と呼んでいる。
ペア作業の利点は、自然な品質チェックと、自然なペアプロ。
１０・ふりかえり(Retrospect)
チケット駆動開発を実践して、イテレーションをリリース後、自然にふりかえりMTを行うようになった。
KPTで行ってみると、開発者も管理者も色んな思いが出てくる。
バグが多かった、無事に終わったけれどこうすればもっと良かった、このプロセスがやりにくかった、など。
チケット集計結果を見ながらKPTすると、チケットやワークフローの運用改善のアイデアが出てきて効果的。
他にも色々あると思うので、収集してみたい。
| 固定リンク | コメント (0) | トラックバック (0)
「アジャイル開発はMTTRを重視している」指摘を受けたのでメモ。
【元ネタ】
MSDN：可用性の概要
ソフトウェアやハードウェアの信頼性や可用性に関する用語として、MTBF・MTBR・稼働率などがある。
MTBF＝稼働時間/稼動回数
MTBR＝修理時間/故障回数
稼働率＝MTBF/MTBF+MTBR
故障率＝1/MTBF
MTTRは可用性、MTBFは信頼性・障害密度に密接に関係するのは周知の通り。
MTBFが大きいほど信頼性は高いが、ソフトウェアのMTBFは格段に小さいように思う。
SRATS:Software Reliability Assessment Tool on Spreadsheet Softwareのサンプルでも、MTBFはわずか16時間に過ぎない。
つまり、16時間後には必ず障害(バグ)が出る。
しかし、MTTRが「0」に近ければ、信頼性が低くても稼働率は100％に近くなる。
つまり、バグ修正工数が少ないほど、ユーザ側から見るとシステムはずっと稼動しているように見える。
アジャイル開発で、「開発の一番重要なファクターは時間である。平均バグ修正時間をみれば品質がわかる」という話を聞いた。
つまり、アジャイル開発ではMTTRを重視している、と。
確かにそうだろうと思う。
リファクタリング、テスト自動化、継続的インテグレーション等のプラクティスは、保守性を高めてソースを修正しやすくすることにつながる。
つまり、バグ修正工数と言うMTTRを短くすることにも注力していると言っていい。
Googleでも、サーバーは故障するものであり冗長化することに力点を置いているという話もある。
極論な話だが、HDDが1時間に1回壊れたとしても、予備のHDDにすぐに取替えできるならば、問題ないという考え。
つまり、MTBFが小さくてもMTTRがほぼ0ならば、実際のシステムの利便性は問題ない。
システム開発でもそうだ。
度重なる機能改善やバグ修正があったとしても、修正工数を小さくできる余裕があるならば、自信を持ってプログラミングできる。
つまり、保守性が高く、可読性の高いシステムならば、どんどん機能改善できる余裕が出てくる。
すなわち、アジャイル開発と相性がいい。
プログラミングの保守性を高くする為のノウハウがGoFのデザインパターンでもある。
マネジメントのノウハウとしては、イテレーションという単位にシステム開発を分割して、スコープを制御する事によって、システムの安全性と継続性を重視する選択肢も取れる。
アジャイル開発と品質管理の関係についても色々考えてみたい。
| 固定リンク | コメント (0) | トラックバック (0)
チケット駆動開発にITILの概念を持ち込めるか、考えた事をメモ。
【元ネタ】
サービスサポート - Wikipedia
初心者歓迎！ ITIL連載講座：ITILの成り立ちと現状を知る (1/2) - ITmedia エンタープライズ
【1】ITILはIT運用プロセスのフレームワーク。
PMBOKと並んで、管理者がマスターすべきマネジメントツールだろう。
昨今のITの問題として、運用保守の作業負荷が増大している点が一番にある。
流行の早いWebシステムであろうとも、数年前に作ったシステムのアーキテクチャが時代に合わずに古くなっても運用せざるを得ない。
稼働中の古いシステムで、ユーザ企業は実際の業務をこなし、売上を上げているからだ。
そんな状況で、保守という名前でどんどん機能追加してシステムが不安定になったり、スケールアップが難しくなり、マンパワーでカバーするなどの問題点が噴出する現場が多くなっているだろう。
上記の問題に対し、ITILの利点は、運用保守や派生開発に応用可能で効果的な点だと思う。
運用保守の観点では、問題管理とインシデント管理を区別している点が重要だ。
つまり、障害の調査と根本対策を立てる問題管理と、ユーザから障害だけでなく改善要望や単なる使い方の質問までをサービスデスクで管理するインシデント管理はきちんと区別する。
例えば、「Webにログインするパスワードを忘れた」というユーザの質問に対しては「パスワードリマインダーを使って下さい」と回答すればいい。
この質問は障害ではなく、マニュアルを見れば、サポートデスクの女性がすぐに対応できる。
インシデント管理がしっかりすれば、開発部隊やサーバー保守部隊は、引っ切り無しにかかってくるユーザの電話から解放される。
インシデント管理で対応できなかったインシデントに対してだけ、エスカレーションして問題管理で対応すればいい。
派生開発の観点では、変更管理とリリース管理を区別している点が重要だ。
清水吉男さんが提唱する派生開発のプロセスXDDPでは、是正保守と改良保守(適応保守)を明確に区別する。
つまり、いわゆるバグ修正である是正保守と、ソフトウェア訂正ではないまったく新しい機能追加である改良保守は、開発プロセスがそもそも違うのだ。
例えば、携帯電話にカメラやお財布ケータイの機能を追加していくのは、どう考えても障害修正ではないのだ。
しかし、この例のような派生開発をきちんとした開発プロセスで行っている現場は少ない。
ITILでは、変更管理でRFC(変更要求書)を作り、RFCをCAB(変更諮問委員会)が精査して、設計・開発・リリースの計画をまず立てる。
そして、変更管理で作られた計画に従って、リリース管理のプロセスで実装してリリースしていく。
清水吉男さんが提唱する派生開発プロセスXDDPは、この変更管理のプロセスや成果物がしっかりしているので、特に組込み製品の企業がよく使っているのだろうと思う。
【2】改めて、ITILのプロセス群(特にサービスサポート)の目的をサービスサポート - Wikipediaから引用する。
１・インシデント管理･･･迅速なサービスの復旧を行い、企業が行う事業活動への影響を最小限に抑える
２・問題管理･･･インシデントや障害原因の追究と対策および再発防止策の策定を行う
３・構成管理･･･ITサービスの構成アイテム（CI）情報の精確な収集、認識と収集した情報の維持管理および確認・監査を行う
４・変更管理･･･CI情報の変更を安全確実かつ効率的に実施する
５・リリース管理･･･変更管理プロセスで承認された内容を本番環境（ITサービス提供媒体）に正しく反映させる為の作業（リリース作業）をコントロールする
６・サービスデスク･･･ITサービスを提供する組織とITサービスを利用する顧客の窓口的役割を担い、インシデント対応などのサポート業務を行う
チケット駆動開発のインフラであるBTSやSCMは、問題管理や構成管理を本来サポートしている。
ITILのプロセスをチケット駆動開発にのせられれば、BTSを問題管理以外のプロセスにも応用できる。
つまり、システムテストの障害管理だけでなく、日々の運用保守や新規開発、リリース作業の管理にもチケット駆動開発を応用できるだろう。
例えば、インシデント管理で、ユーザからの日々の問合せを、障害や改善要望などのカテゴリでフィルタリングし、システムを修正する必要のある要求はScrumのプロダクトバックログに詰め込む。
実際は、バグ修正のタスクと区別したいので、インシデント用のプロジェクトとワークフローを作って管理すればいいろう。
即ち、Redmineの複数プロジェクト機能、柔軟なワークフロー管理機能が必要になる。
例えば、変更管理では、変更要求をRFCとしてまとめて、CABは開発部隊だけでなくサーバー保守部隊やユーザの情報システム部門から構成して、RFCの精査やリリース時期の判断を下す。
そして、リリース管理では、RFCに従って、開発者がソース修正し、テスターが検証し、ライブラリアンがリリース作業を行う。
実際は、RFCにある要求をストーリーカード、RFCに基づく作業をタスクカードできちんと管理すればいいだろう。
そして、開発者・テスター・ライブラリアンの作業はチケットの属性によって使い分ければいい。
即ち、チケットの親子関係・柔軟な属性カスタマイズの機能が必要になる。
RedmineやTracにあるガントチャート・カレンダー・工数集計・バーンダウンチャートなどの多様なレポート機能があると、進捗管理が更にやりやすくなるだろう。
上記の思索を考えると、ITILのプロセスはチケット駆動開発と相性が良いと思う。
RedmineやTracをBTS(Bug Tracking System)だけでなく、ITS(Issue Tracking System)へ拡張する発想とITILがすごく相性がいいからだ。
同様に、PMBOKもチケット駆動開発に載せる事ができるか考えてみたい。
PMBOKはプロジェクト管理のフレームワークであり、その特徴は、リソース管理、コスト管理に優れている点にあると思う。
RedmineやTracの優れたレポート機能がPMBOKの概念の実装を補完してくれるはずだ。
| 固定リンク | コメント (0) | トラックバック (0)
: 
最近のコメント