« ドメイン駆動設計の意義~MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築 | トップページ | MVCモデルのバリエーション »

2013/12/04

チケット駆動開発を紹介した書籍一覧

最近、チケット駆動開発に言及した本がチラホラ見かけられる。
内容と感想をラフなメモ書き。

【1】「アジャイル概論」「わかりやすいアジャイル開発の教科書

いずれもアジャイル開発の文脈でチケット駆動開発を紹介している。
わかりやすいアジャイル開発の教科書」はタスク管理の観点、「アジャイル概論」はバージョン管理との連携に焦点を当てている。
アジャイル概論」では、バージョン管理ツールにコミットした時、コミットログに記載されたチケットNoがpost commit-hookされる点も記載している。
つまり、No Ticket, No Commitの運用ルールが実現できること、さらにそこからJenkinsのようなCIツールへつながる点も説明している。
チケット駆動開発の特徴の一つであるツール間連携に繋がる話だ。

【2】「本当に使える開発プロセス

チケット駆動開発をタスク管理の観点だけでなく、ALM(Application lifecycle management)の観点に焦点をおいている。
すなわち、進捗や障害の見える化だけでなく、開発プロセス全体をカバーする基盤としてチケット駆動開発を説明している。
ALMにチケット駆動開発を適用できるアイデアは、「チケット駆動開発」の10.8節「Application lifecycle management」でも既に触れている。
おそらく、MicrosoftのTFSやIBMのRational Team Concertが最終製品になるだろうと思う。


【3】「チケット&計測でITプロジェクト運営の体質改善

【3-1】チケット駆動開発をソフトウェア工学におけるソフトウェアメトリクスの収集・集計・分析の観点に焦点をおいている。

従来のソフトウェア工学の問題点は、肝心のメトリクスの元ネタとなるデータの収集や集計そのものが大変である点だ。
障害管理票や課題管理票を紙ベースの帳票で運用していた時代では、メトリクスの元ネタとなるデータを帳票から手で集めて、更に集計し直す手間がかかっていた。
ソフトウェア開発の作業そのものがIT化・自動化されていなかったのだ。
だから、メトリクスを収集・集計する仕組みを導入しようとすると、開発者の作業コストが大きくなる問題がずっと続いていた。

だから、ソフトウェア工学を論じようにも、肝心のデータがないために研究の障害が大きかったのではないかと思う。

しかし、チケット駆動開発という仕掛けによって、チケットに作業や障害、課題などプロジェクト内部の情報が全て入力・蓄積される。
よって、そのチケットを色んな観点で集計すればいい。

すると、チケット管理ツールは2つの観点で語ることができる。
一つ目は、チケット管理ツールはPMBOKにおけるPMIS(プロジェクト管理情報システム)と同一であることだ。
つまり、チケット管理ツールは、ソフトウェア開発のERPなのだ。
その主張は「Redmineによるタスクマネジメント実践技法」の8.3節「Redmineと外部ツールを連携」で既に触れている。

もう一つは、チケット管理ツールはメトリクス収集ツールとしてソフトウェア・リポジトリ・マイニングに使えることだ。
つまり、ビジネスインテリジェンス(BI)の観点で、チケット集計結果を分析することができる。
その主張も「Redmineによるタスクマネジメント実践技法」の8.2節「測定できれば制御できる」で既に触れている。

【3-2】「チケット&計測でITプロジェクト運営の体質改善」では、IPAが作った定量的プロジェクト管理ツールEPM-Xを元にメトリクスを出力し、ソフトウェア工学の知識を使って、プロジェクトの進捗やシステムの品質を分析評価している。

定量的プロジェクト管理ツール(EPM-X):IPA 独立行政法人 情報処理推進機構

EPM-XはRedmineをベースに、データ変換やデータ分析などの機能を追加した大規模なチケット管理ツールだ。
読者対象はプロジェクトマネージャや品質管理者であり、アジャイル開発に興味を持つ人やプロジェクト管理に興味のない開発者ではない。
実際、アジャイル開発に触れた部分は数ページだけ。

むしろ、WF型開発にチケット駆動開発を導入した場合、どのように運用すればどのような効果が得られるか、についてEPM-Xを元に説明している。

【3-3】「チケット&計測でITプロジェクト運営の体質改善」で興味深い点はいくつかある。
一つは、チケットの2大機能として、「作業内容の分類と記録」「作業の指示・受け渡し」に分類している点。

前者の例は障害管理票や課題管理票など、入力項目の多い帳票が相当する。
管理者が集計結果を元に分析する機能に力点を置く。
だから、入力項目が多くなり、開発者の作業負荷が大きくなりやすい。

後者の例は、タスクカードやWBSにおける作業が相当する。
管理者が作業を指示し、開発者が作業指示書に基づいて作業する機能に力点をおく。
作業をスムーズに行うことに力点を置くため、集計・分析が弱い。

この分類は、チケットをメトリクス収集として扱うか、ワークフローで管理するものとして扱うか、という観点で分けているように思える。
つまり、チケットの使い道、使う目的が異なるのだ。

もう一つは、チケット発行契機として「フィーチャ型」「WBS型」に分類している点。

前者は機能単位の開発スタイル。
機能の実現に重きをおくため、運用保守やアジャイル開発に適用しやすい。
主な特徴しては、作業の経過は積極的に管理せず、開発が終了次第、順次リリースしていく点に力点を置く。

後者はトップダウンによる作業管理の開発スタイル。
管理者がプロジェクト全体の作業をWBSで洗い出して詳細化し、進捗やコストを管理していく。
普通はWF型開発に適用しやすい。
メトリクス収集ツールとしてチケット管理ツールを扱う場合、こちらの観点で運用する方が、たくさんのメトリクスを得られる。

この分類は、チケット駆動開発をアジャイル開発に適用するのか、WF型開発に適用するのか、という観点で分けていると考えた方が分かりやすいと思う。

【3-4】「チケット&計測でITプロジェクト運営の体質改善」を読んでいて思うのは、「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」で著したアイデアが、実際の具体例で詳しく説明されている点だ。

チケット&計測でITプロジェクト運営の体質改善」では、チケット管理ツールから得られた進捗や品質に関するメトリクスを分析すると、どのような評価や結果が得られるのか、について、「第6章 計測事例に学ぶプロジェクト運営の体質改善」でとても詳しく説明している。
この章はとても参考になる。

EPM-Xはプロジェクト管理に役立つ情報を収集し、これらの情報をビジネスインテリジェンス(BI)を活用してグラフ化して可視化するシステムである、という指摘はまさにそうだ。(P.54)
Redmineによるタスクマネジメント実践技法」の8.2節「測定できれば制御できる」で既に触れている。

また、チケット管理ツールから得られたメトリクスを複数プロジェクトの異常検出で使う方法は、発電所の中央制御室に多数の表示器があり、特定の異常値を早く検出するために使われるのと同じという文章がある。それは、モニタリングツールのコックピット型活用方法であるという指摘はまさにそうだ。(P.105)
Redmineによるタスクマネジメント実践技法」の8.1節「PMBOKのEVM」で、パイロットが操縦する時の計測器に例えた内容と同じだ。

4.4 進捗管理では、EVMによる予実管理にも触れている。
EVMの実現方法のアイデアは「Redmineによるタスクマネジメント実践技法」で既に出しており、どのように実装するか、という点が興味があった。
但し、個人的に残念なのは、PV・AC・EVをチケットにどのようにマッピングするのか、という説明が省略されていた点だ。
特に、EVをチケットでどのように実現するのか、という点は、アジャイル開発とWF型開発では全く違う。
その違いについて、もう少し説明が欲しかったと思った。

「おわりに」では、今日のソフトウェア開発の最重要課題が「説明性と追跡性」であると書かれている。
この理由は、現代のソフトウェア開発では、単にプロダクトをリリースすれば良いだけではなく、正しいプロセスでちゃんと作れているか、というシステム監査の観点も重要であるからだ。
その観点はチケット駆動開発がサポートできるという点が本書の主張なのだろうと思う。

他には、参考文献のトップに「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」が記載されているのが正直嬉しかった。

他にも色々探してみる。

|

« ドメイン駆動設計の意義~MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築 | トップページ | MVCモデルのバリエーション »

プロジェクトマネジメント」カテゴリの記事

Redmine」カテゴリの記事

ソフトウェア工学」カテゴリの記事

構成管理・Git」カテゴリの記事

チケット駆動開発」カテゴリの記事

Agile」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« ドメイン駆動設計の意義~MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築 | トップページ | MVCモデルのバリエーション »