ストーリーポイントとファンクションポイント法の比較

ストーリーポイントに関するInfoQの記事をまとめたのでリンクしておく。
ラフなメモ書き。

【元ネタ】
InfoQ: ストーリーポイントは複雑さや時間と関係があるか？

InfoQ: ストーリーポイントとは何か？必要ものなのか？

InfoQ: タスクに費やした時間ではなく開発速度をトラッキングする

InfoQ: 価値とベロシティ、そしてバリューベロシティの比較

InfoQ: ストーリーポイントの間違った使い方。

今振り返ってみると、ストーリーポイントの概念はXPが提唱して生まれ、Scrumがアジャイルな開発プロセスに組み込んで厳密に定義したように思える。
ストーリーポイントは、従来のソフトウェア開発から考えると奇妙な考え方だろう。
ソフトウェアの開発規模を表すが相対比較になっているので、厳密な開発規模の単位にはならない。
あくまでも固有のプロジェクトでしか通用しない規模の単位。

元来、開発規模は、ファンクションポイント法で厳密に測定する手法は既に知られている。
また、オブジェクト指向分析では、ユースケースポイント法として読み直す。

下記では、各業界のシステム開発において、1人月で何FP作れるのか、例示されている。
「システム開発の見積りのための実践ファンクションポイント法」によれば、15FP/人月がよく使われるらしい。

Sync-K : ファンクションポイントの換算値

だが、ファンクションポイント法の最大の弱点は、測定する工数がかなりかかること。
熟練した経験者でなければ、意味ある測定値を計算できないだろう。
もう一つの弱点は、開発規模をファンクションポイント法で測定して見積もったとしても、予定工数や予定される納期へ変換するには、COCOMOのような汎用的な経験値を使うか、実際のプロジェクトでリリース間際まで経なければ分からないこと。
COCOMOのような経験値を使って工数見積もりしたとしても、その見積りの正当性はかなり怪しい。
そもそも前提条件となるプロジェクトの状況(開発者の能力、チームの能力など)がCOCOMOのような経験値にぴったり当てはまるかどうか怪しいからだ。

それに対して、ストーリーポイントはメンバー全員で相対比較してとにかく早く見積もる。
そして、すぐにイテレーションを実施すれば実績工数が得られるから、Velocityを計算することができる。
つまり、Focus Factor＝実際に作った規模/実績工数が計算できるので、
Velocity(見積もったVelocity)＝予定稼働工数＊Focus Factor
で計算できる。

すると、開発対象のシステムのストーリーポイントを機能単位に洗い出して合算した値から、Velocityで割れば開発期間を見積もることができる。
しかも、実施した1イテレーションでまず見積もれる。
この見積の数値は、COCOMOよりも説得力があると思う。
何故なら、実際にチームが短期間とはいえ1イテレーションで経験した工数を含んでいるから、少なくともその時点のチームの能力を表しているからだ。
そして、イテレーションをこなすたびにVelocityを測定していけば、チームの能力に見合った見積りを測定することができるだろう。

アジャイル開発の利点は機能単位の小刻みな小規模リリースだけではなく、チームの現在の能力に見合った見積りを提示できる点にもある。
顧客に、現在のチームの能力ではこれぐらいの期間でこれぐらいの機能(規模)を提供できます、とイテレーションのたびに説明できるのは、ウォーターフォール型開発よりもとても有利だ。

特に「アジャイルな見積りと計画づくり」で提示されたScrumによるストーリーポイント見積りは、見積りが計画づくりの重要な作業であることを認めた上で、見積りの手法やその注意点を細かく説明している点がとても優れている。

アジャイル開発の見積りで面白いのは、実績工数よりもVelocityを追跡することに注力することだ。
予定していたVelocityと実績のVelocityを各イテレーションで計測しながら、次のイテレーションの見積りに使う。
実績工数にこだわると、いかに時間をかけずに仕事するか、に開発者の意識が寄ってしまって、手抜き作業が起きる可能性もあるからだろう。
また、実績工数は規模や難易度によって大きく変わるから、あまり当てにならない。
Velocityの計測を追跡することによって、チームの能力をいつも気にかけるようになり、XPの言う「持続可能な開発ペース」を保持するのにも役立つ。

ストーリーポイントやVelocityはアジャイル開発特有の概念であり、その概念の意味はとても奥深い。
Redmineによるチケット駆動開発を通じて、WF型開発でよく使われるFP法やEVMとは全く違うこともよく分かった。
こういうメトリクスを計測できる環境をチケット駆動開発は提供してくれるからこそ、色々思索することもできる。

第3回品川Redmine勉強会の感想 #47redmine

本日開催された第3回品川Redmine勉強会をUstで見た感想をメモ。

第3回shinagawa.redmine勉強会 : ATND

第3回勉強会 - shinagawa.redmine

shinagawa.redmine 第3回勉強会 - Togetter

【1】Redmineコミッタの@marutosijpさんが、RedmineをRuby1.8→1.9, Rails2.3→3.2へVerUpした経緯やその作業内容について解説してくれた。
僕としては、既存機能をデグレードさせずに環境周りをVerUpするいわゆるポーティング作業は地味だけれども難しい作業だと経験的に思う。

ポーティングとは【porting】（移植） - 意味/解説/説明/定義 ： IT用語辞典

RedmineがVer2.0でRails3へ移行予定: プログラマの思索

Twitter / @akipii: #47redmine ポーティングの例としてはCentOS5→6、JDK1.4→6、Apacheのセキュリティパッチ当て、WindowsUpdateなどたくさんあって、どれも結構神経を使う割には頭を使わない。面白くない作業だけどシステムの延命を考えるととても重要。

ポーティング作業の難しさは、テスト工数と納期のバランスを取ること、OSやライブラリのバージョンアップによってソースの修正が発生するバージョン管理の2点にあると思う。
既存機能に影響がないことをテストするために回帰テストすればよいが、古いシステムほどテスト自動化などないので、手作業のテストになり、どこまでテストすれば良いのか、判断を下しづらい。
だから、この機能は既にテストされたので品質は担保されている、などといった「みなしOK」の判断を下して、テスト工数を削減したりする。
でも、みなしOKの判断を誤ってテスト漏れが発生したりするから、サジ加減が難しい。

また、バージョンアップ前と後のソースを別々にブランチ管理する作業があったり、バージョンアップ前のソースからどのソースを最新の環境に持っていくべきか精査する作業が発生するため、バージョン管理が面倒になる。
だから、前者ではベンダブランチのような並行開発が必要になってくる。
後者は手作業で逐一ソースを精査するしかない。

でも厄介なのは、既存バグを発見したけれども、VerUp後のソースで直してしまうと、既存のソースにもバックポートする作業が発生する時だ。
特に、古い環境と新しい環境を並行稼動するような業務システムの例では、バックポートの作業を忘れると、せっかく直したバグ修正をバグとみなされてしまい混乱してしまう。
だが、古い環境で本番運用されている場合、すぐにバックポートの作業ができるわけではないから、既存バグをきちんと記録しておき、並行運用中に直すというやり方を採用するときもあるだろう。

バックポートとは【backport】 - 意味/解説/説明/定義 ： IT用語辞典

他に、下記のような意見もあり、僕はすべての現場を知らないので何とも言えない。
でも、他の言語やフレームワークなどのポーティング作業(例：CentOS、JDK、Apache、Androidなど)は、今はそんなに楽になっているのだろうか？
例えば、MSがWindowsOSの後方互換性の維持にこれだけ大きな手間をかけているのを見ると、ポーティング作業がそれほど楽なようには思えない。
最近では、AndroidOSのバージョンの違いや後方互換性で、スマートフォンメーカーが苦しんでいるように見える。
とは言え、RailsはVerUpで大きく変わりすぎたし、Redmineインストールに苦しんでいる人が多いのを見るとそうなのかもしれない。

Twitter / @sakaba37: 同意！ RT @akipii: Rubyだからこそアジャイルに開発できたのかも RT @kondoujp: Redmine 2.0 はよく頑張った! って思うし、素直に褒め称えられる。しかし、背景を考えると Ruby や Rails 捨てた方がいいようにしか思えない。

Twitter / @kondoujp: @akipii アジャイルなスタイルで開発を行うことと仕様の不安定さは全く層が異なる話です。はっきり言って、ユーザーとしては使いたいものはサービスであって、Ruby であるとか Rails であるというのはどうでもいいんです。その点で「よろしくない」と思いますよ。

Twitter / @kondoujp: @akipii 他の言語/フレームワークでは、バージョンアップにここまで手間がかかる事の方が不思議なんですけど。「これだけ短期間に VerUp できた」ではなく「VerUp にここまで時間がかかった」という認識です

【2】@tech_machiiさんのLotusNotesからRedmineへの移行作業の事例も興味深かった。
僕の感想は下記に書いた。

Twitter / @akipii: #47redmine　Redmineは中途半端に万能・・なるほど。Redmine導入はERP導入やCMMI導入に似ているなあと後で思います。導入工数と運用のバランスかなあ。。

Twitter / @akipii: #47redmine　redmineのRails3.2へのポーティング、現行業務をチケット駆動へデータ移行という発表を聞くと、こういう地味な開発が現場の業務システム開発でも多いのに気づきます。人の話は役立ちますね。

RedmineはOSSの割には高機能なので、何でもできそうなイメージがあるが、実際はどの業務をRedmineで代用し、他の業務を従来の手運用ないしExcel運用でカバーするか、という切り分けが難しい。
移行作業の工数は無限にあるわけでもないし、納期もあるから、いかに短期間で成果を出していくか、という戦略が大切になる。
似たような話として、ERP導入やCMMI導入では、導入や運用の失敗事例の話が山ほどある。

Redmine導入はERP導入に似ている #tidd: プログラマの思索

ポーティング作業や移行作業の事例を聞くと、業務システムの受託開発に似ているなあと思う。
案件は、いつも綺麗な新規開発ではなく、ポーティングやデータ移行などの地味でつまらない案件も多い。
でも、そのような案件は特にプロジェクト管理の質が良くないと失敗しやすいように思う。

【3】IPAの定量的プロジェクト管理ツールのお話もあった。
RedmineやTracを定量データの収集場所とみなし、データを集計してプロジェクト管理に役立てる発想として作られたらしい。
過去のソフトウェア工学やエンピリカルアプローチは、本来はこのようなツールを基盤として研究されるべきではなかったのか、と思う。
何故なら、RedmineやTracのようなツールがなければ、データ収集に工数がかかりすぎて肝心のプロジェクトの進捗に害があるからだ。

IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索

Twitter / @akipii: #47redmine redmineの利点：SCMリポジトリとBTSの両方のデータを一括集計できる。更新履歴が必ず残るのでシステム監査や追跡に使える。Webのデータマイニング機能で、開発者の作業ログを緩やかに収集・集計する仕組みがある。

Twitter / @akipii: #47redmine　RedmineやTracが無かった頃の人は、どうやって定量データを収集してメトリクスを集計していたのか気になります。多分帳票やExcelを自ら手作業で収集して、手作業でExcel集計(又は手計算)していたのだろうなあ。。昔の人はよくやっていたと思う。

チケット駆動開発の面白さは、アジャイル開発と相性が良い点だけでなく、マネージャをサポートするソフトウェアメトリクスの出力という一面もある。
メトリクスの分析や使い方は罠や癖があるけれども、見える化の一部として使えるだろうと思う。

メトリクスを使った品質管理の技法は、従来の日本の製造業が得意とする開発スタイルだ。
RedmineでWF型開発を行う場合、メトリクスを使う品質管理は相性が良いだろうと思う。

【4】@g_maedaさんのお話も興味深かった。
Redmine.jpにはいつもお世話になっています。

Redmine.JP

Home | Redmine.JP Blog

Twitter / @hell0_wor1d: 前田さんの優しい話し方、Redmine愛を感じる #47redmine

Twitter / @akipii: #47redmine OSSの貢献はソースコードの公開だけでなく、ツールの紹介や情報公開もあるというお話。実際に行動されているだけあって説得力あります。

Redmineが日本でこれだけ普及した理由の一つは、Redmine.jpがポータルサイトとなっていて、初心者から上級者まで誰もが参考に出来る情報が発信されていることだと思う。
単なるリンクの羅列、Wikiの日本語訳、VerUpされた内容の掲載だけでもとても役立つ。

Redmineコミュニティの利点は、日本人コミッタ(@marutosijpさん)がいることと有用な情報が一箇所に集まっているポータルサイト(Redmine.jp)があることだと思う。
コミュニティがツールの発展を支える良い事例の一つになっているのかなあと思う。

他にも@tkusukawaさん、@basyuraさんのお話も興味深かったです。

【5】個人的には、ChiliProjectがA Successful branch modelを採用して一部混乱した時があったという指摘、そして、Redmineではrebaseを多用してtrunkのリビジョンが一直線になるメインラインモデルを採用して混乱なくVer2.0をリリースできたという事実について、その背景を聞きたかった。

Twitter / @cointoss1973: 今日の #47redmine の個人的テーマ: Redmineと連携するリポジトリは、(Gitよりも)Mercurialがオススメという理由がよく理解できていないので、まるやまさんに聞いてみたい

Twitter / @akipii: 明日の予習。いかにRedmineのメインラインを守ってきたのかというバージョン管理の考え方が分かる。　Redmine 2.0 リリース ? shinagawa 20120519 v0.1 documentation　http://goo.gl/PvRds

Twitter / @akipii: trunkはrebaseを使うべきだ、ChiliProjectのRevision graphはdirtyと言う指摘に対し、git-flowモデルだから同意しないという回答。価値観の違い。ChiliProject - Bug #127 http://goo.gl/cTxI9

Twitter / @akipii: git-flowのバージョン管理手法は小規模プロジェクトでしか通用しない。pull requestは大規模オープンソースプロジェクトにはそぐわない。メインラインモデルが一番という指摘がある。明日のRedmine勉強会資料は参考になる　http://goo.gl/PvRds

A Successful branch modelの考え方はgit-flowというGitツールで実装されている。
その考え方はとても面白かったので、いろいろ考えていた。

git-flow による構成管理とRedmineの関係: プログラマの思索

しかし、そのモデルは小規模プロジェクトでしか通用しないという理由がきちんと分かっていないので、経験者から聞いてみたかったなあと思う。
実際、GitHubにあるChiliprojectとredmineをクローンしてコミット履歴を見れば、その違いがよく分かる。

Twitter / @akipii: GitHubからChiliprojectとredmineをクローンしてgit logを見た。Chiliprojectのリビジョンブラフは分岐が多くたくさん手が入って複雑。redmineのリビジョングラフは一直線でコミットログにマージ作業が書かれているので分かりやすい。

この点は資料を解読してみる。

EVMとバーンダウンチャートは本質的に違う

EVMとバーンダウンチャートは本質的に違うことを指摘している記事を見つけたのでメモ。
ラフなメモ書き。

【元ネタ】
バーンダウンチャート / バックロググラフっていいね。 - 遅れなんか見たくない。いつ終わるかを見たいんだ。: 円山貫’s EYE on high-tech development

【1】
(引用開始)
■ 縦軸に見積もり工数を取った場合、工数ベースのEVMS(*)をひっくり返した形に近い。
(中略)
※(バーンダウンチャートでは)プロット毎に残作業を見積もるということは、過去作業の作業効率から完成時コストを延長推定する(簡易)EVMSよりも本質的には厳密なもの。アジャイル精神、開発チームが作業をコントロールするためのツールとして使うのは楽しいが、超精密管理感覚で上から強制実施すると、むちゃくちゃ苦しくなりそうな、危ないグラフでもある。(※追記：2005.7.26)
(引用終了)

バーンダウンチャートはEVMの工数を残工数へひっくり返した形である指摘は、僕も同じ意見だ。
アジャイル開発の方が管理作業は第三者から見れば楽そうに見えるが、アジャイル開発の方が作業の終了基準が厳しいため、「超精密管理感覚で上から強制実施すると、むちゃくちゃ苦しくなりそうな、危ないグラフでもある」。

(引用開始)
■そもそも、EVMSとバックロググラフ(バーンダウンチャート)では、根本的な発想が違う。
EVMSは、計画(WBS)を絶対視したうえで期間と費用の計画偏差を是正しようとする。ベースライン計画に如何に収束させるか、という発想で、予算化した計画を動かすことはほとんど拒否する。
バックロググラフでは、期間固定で、計画(WBS)が流動するものとする。一定期間内に出来ることでとにかく切りをつけよう、という発想になる。
(引用終了)

EVMSとバーンダウンチャートは根本的に発想が違う指摘は全く同意。
PMBOKにせよ、WF型開発にせよ、最初に立てた計画から実績がどれだけずれているかを追跡して、いかにその変化を抑えこむか、という発想でコントロールする。
しかし、アジャイル開発はその発想がそもそも無い。
イテレーション計画は当然作るが、イテレーション実施中に、イテレーション計画の作業順序は頻繁に変わるし、流動的だ。
2～4週間という短い期間で全ての作業を終了させるには、計画にしがみつくよりも、その実績に応じてやり方を変えていく。

計画を立てて実績のズレを検証し、その内容をフィードバックしていくという仮説検証スタイルはアジャイル開発だけでなく、WF型開発でもよく言われている。
検証した結果、計画が間違っていたら計画を修正ないし、新しく作りなおせばいい。
しかし、計画を変更してしまうとWF型開発では当初の予算も変わってしまうため、修正することがとても難しい。

そんなことを考えながら、「アジャイルな見積りと計画づくり」や「ソフトウェア見積り―人月の暗黙知を解き明かす」を読み直すと、計画と見積りは密接に関わっている事実、更にそこにはもっと深い考えがあるような気がしている。

【2】@daipresentsさんのredmine_version_burndown_charts画面では、Scrumの考え方をさらに注入して、面白いメトリクスを表示してくれる。

理想ラインが加わったredmine_version_burndown_charts画面: プログラマの思索

(1)「予想ライン」が予定工数から計算される残工数、「実績ライン」が実績工数と進捗率から計算される残工数。
(2)理想ラインは、該当バージョンの開始日から期日に向けて残工数がまっすぐ下がっていく残工数。
(3)上限ライン・下限ラインは、予定工数の±20%という設定から計算される理想ライン。管理図のようなもの。
(4) 本来のバーンダウンチャートは、理想ラインの付近で表示されるのが望ましい。理想ラインから離れるほどタスクがあふれていることを示している。

また、バーンダウンチャートの下がり具合を調べると、チームの成熟度や能力を予想することもできる。

バーンダウンチャートのパターン集: プログラマの思索

上記の「上限ライン・下限ライン」枠内にバーンダウンチャートが収まっているならば、そのチームはそのイテレーションを完全にコントロールできていると言えるだろう。
でも実際のプロジェクトでは、「上限ライン・下限ライン」枠外に残作業が残ってしまって、アップアップになってしまう状況も多い。

また、バーンダウンチャートをRedmineで実際に運用するのは、結構面倒だ。
チケットに開始日、終了日、予定工数、実績工数を毎日正確に入力してもらわないとチームの実情にあったグラフにならないからだ。
この辺りの運用はまだまだ改善の余地はある。

「アジャイルソフトウェアエンジニアリング」におけるプロダクトバックログの考え方

「アジャイルソフトウェアエンジニアリング」が発売されるらしいのでリンクしておく。
サンプルとして9章がフリーで読める。

【元ネタ】
『アジャイルソフトウェアエンジニアリング』発行記念 | 日経BP社 ブックス＆テキスト Online

[書籍] アジャイルソフトウェアエンジニアリング | 長沢智治のブログ | 一伝入魂

「アジャイルソフトウェアエンジニアリング」という本が出版されます - かおるんTFSダイアリー

「アジャイルソフトウェアエンジニアリング」はMicrosoftのTFSを題材とした本。
MSのようにソフトウェア開発にとても経験のある企業でさえも、Conwayの法則から逃れられないという経験則は興味深い。

サンプルの9章を読んで興味深かった点は、プロダクトバックログの作成方法だ。
それ以外のアジャイルな考え方は、多分普通だろうと思う。

MSでもフィーチャ(機能)を基本として、フィーチャをタスクに分割してソフトウェアを開発する。
その弱点は、知らないうちに過剰生産してしまうこと。
つまり、無駄に機能が増えて使いづらいUIになったりする危険があること。
リーンソフトウェア開発でも言われているように、製品の過半数の機能はユーザが使い方を知らない機能ばかりになって複雑化してしまう。

そこで、フィーチャに階層構造を導入して、開発者の観点だけでなく顧客やビジネスの観点も入れるようにした方法が書かれている。
上記では、シナリオ＞エクスペリエンス＞フィーチャという階層構造でまとめる。
シナリオは、製品を使った場合に具体的な顧客価値を定義する。「もし○ができたら購入したい」というイメージ。
エクスペリエンスは、開発者が顧客へ具体的な価値を提案する。「○のやり方を教えましょうか」というイメージ。
フィーチャは、ユーザストーリーないし実際の機能。

「アジャイルな見積りと計画づくり」にあるエピック＞テーマ＞ストーリーの概念と上記のシナリオ＞エクスペリエンス＞フィーチャは1対1に対応するように作られているらしい。
MSがアレンジしているのは、シナリオに「基本項目」「顧客の不満因子の除去」というカテゴリも入れていること。

基本属性シナリオの例として、互換性、信頼性、パフォーマンス、グローバル対応などが挙げられているが、これは品質特性を意味しているのだろう。
つまり、顧客にとって価値ある機能は目に見える使い勝手だけではなく、製品全体を貫く品質特性(信頼性、可用性など)も当然含まれるわけだ。

顧客の不満因子の除去シナリオの例として、優先順位の低いバグや小さい便利なフィーチャを指している。
わざわざ顧客の不満因子の除去というシナリオを作っている理由は、これらのフィーチャは個別にトリアージした場合通常は修正対象外となるが、積もり積もれば大きな障害やユーザ離れの原因になるので、一つのシナリオにまとめて、他のシナリオと同じレベルで優先順位付けできるようにしたいから。
このやり方は、要件のトリアージで見落としがちな顧客価値を敗者復活戦で復活させる重要な仕組みなのだろう。
そういう意味では、MSはプロダクトバックログの良さと悪さを十分に経験しているように思える。

TFSは個人ではとても購入できるツールではないが、その考え方はチケット駆動開発にも適用できる。
チケットをストーリーカードに対応付けて、エピック＞テーマ＞ストーリーの階層構造を親子チケットで表現して、それぞれの階層で観点を使い分ければいい。
PivotalTrackerやFulcrumのようなストーリー駆動のタスク管理ツールと併用すれば、より面白いかもしれない。

「アジャイルソフトウェアエンジニアリング」は良い本のような気がする。

チケット駆動開発の適用範囲part4～ウォーターフォール型開発への部分適用の注意点

以前のJSOLさんのTiDDの運用事例の記事を読み直してみて、自分の理解不足の面があったのでメモ。
ラフなメモ書き。

【元ネタ】
「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL

[#TiDD] チケット駆動でAdaptable Waterfall開発！: ソフトウェアさかば

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

チケット駆動開発の戦略: プログラマの思索

裏プロセスは並行プロセス: プログラマの思索

「現状のソフトウェア開発は間違っていないか？」（プロセス編） － ＠IT自分戦略研究所

繰り返し開発の罠: プログラマの思索

段階リリースとアジャイルリリーストレイン: プログラマの思索

WF型開発におけるプロマネのテクニック: プログラマの思索

僕は、チケット駆動開発をアジャイル開発へいかに適用するか、という問題意識しなかったので、従来型の開発やWF型開発への適用はあまり考えていなかった。
上記の記事を読むと、WF型開発に特有の課題に対して、チケット駆動開発をどのようように適用したら効果的なのか、という点をよく研究されているという印象を持った。

「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOLの記事では、主に二つの課題、（1）ウォーターフォール開発でも内部にある小さな開発サイクルでの適用と、（2）プログラム改訂に関係するタスク以外のタスクや情報のチケット管理に適用した話が載っている。

(1)が意味することは、WF型開発でも短期間の開発サイクルの作業が存在しており、その作業にチケット駆動開発を適用しようとすること。
実際、要件定義、設計、実装、単体テストという工程が終わった後、ビッグバン結合で初めて大きな問題が次々に判明し、障害という名の元で短い開発サイクルの作業が生まれる。
その作業は障害管理に過ぎないけれども、障害をチケットに起票するのが起点となり、修正、レビュー、テスト、自動テスト、ビルド、リリースという一連の流れが全てチケットに作業履歴として残る。
だから、チケットにすべての情報が集約されるので、関係者同士の情報共有が楽になるし、SVNやGitなどの構成管理やJenkinsのようなビルド管理とRedmineを連携すれば、より強力に早く開発できる。

また、(2)では、設計書のレビューなどもチケットに作業履歴を残すことで、レビューの品質をあげようとする目的が示されている。

だが、(1)(2)の本当の問題点は、要件定義や設計、開発、テストの各工程で、一連の短い開発サイクルという裏プロセスが存在することにある。
WF型開発の定義では、前工程が完全に終了して次の工程に成果物が渡るので、手戻り作業や反復作業は基本ありえない。
しかし、実際の現場では、そんな綺麗事で開発できるわけがないし、リスクが高い。
だから、経験のあるプロマネは、裏プロセスという技を取る。

萩本さんの記事「「現状のソフトウェア開発は間違っていないか？」（プロセス編） － ＠IT自分戦略研究所」に書かれているけれど、要件定義・設計などの各工程で、PDCAサイクルを裏で回してリスクヘッジしているが、表に出さないようにプロセスを回す。

特に上流工程のPDCAサイクルは、実験的なアプリを作って画面イメージをすりあわせるプロトタイプという手法をよく取るがそれに当たる。
だが、プロトタイプはあくまでも暫定的なアプリのため、開発工程では結局一から作り直す場合も多い。
つまり、アジャイル開発における小規模リリースとは性質が全く違う。

そういう要件の検証、アーキテクチャ検証をあらかじめ実施するプロセスがあるのだが、教科書通りのWF型開発ではその認識が漏れていて、各プロジェクト独自のプロセスになりがち。
その裏プロセスを表に出すと、特に大手SIが自社で定めている開発標準とずれてしまうため、表に出さないようにわざわざする場合も多い。
だから、裏プロセスと呼ばれるわけだ。

また、別の手段として、段階リリースという方法もよく取る。
段階リリースとは、WF型開発において、サブシステム単位に複数回のWF型開発を回すこと。
大規模システムですべての機能を設計した後に開発して結合テストを実施するのはとても危険なので、意味のある業務の単位でシステムを分割し、その単位で段階的にリリースしていくプロセスを指す。
ビッグバン結合というリスクを回避するために、システムのサイズを小さくしてテストしてリリースするわけだ。

その意味ではアジャイル開発のイテレーションやスプリントの概念に似ているけれども、性質は全く違う。
イテレーションは2～4週間の定期的な開発サイクルであり、段階リリースではリリースサイクルは1ヶ月の時もあれば3ヶ月の時もあり不定期だ。
更に、イテレーション期間中は計画の変更は現状に合わせて行われるし、設計・開発・テストは並行して作業するのに対し、段階リリースの期間中はミニWF型開発なので、設計・開発・テストの工程の順に進んでいく。
だから段階リリースと言っても、結局はWF型開発であるからには最後のリリースにしわ寄せが来る。

そういう弱点がWF型開発には根本的にあるけれども、チケット駆動開発の恩恵は確かにある。
@sakaba37さんは、AdaptableWFと呼んで、WF型開発への部分適用でも十分な効果があると言われている。
とはいえ、WF型開発への適用は、WF型開発の特徴から来る根本的な問題をよく考えてみることが大事なように思う。

チケット駆動開発はApplication Lifecycle Managementを目指す

Application Lifecycle Managementに関して、MSが公開しているVisualStudioの資料が分かりやすかったのでメモ。

【元ネタ】
Visual Studio ホワイトペーパー

Visual Studio vNext: アプリケーション ライフサイクル管理

アジリティ (俊敏性) 向上のためのツール(ケント・ベック)

アプリケーション・ライフサイクル・マネジメント - Wikipedia

アプリケーション・ライフサイクル・マネジメント（ALM）は、ソフトウェアの開発や保守を含めた全体のライフサイクルをツールで継続的にサポートする考え方と僕は理解している。
MSのTFS、IBMのRational製品がALMを実現した有償ツールになるだろう。
もちろん、Redmineによるチケット駆動開発にもALMの考え方を適用することもできる。

ケント・ベックのホワイトペーパーでも、時速10キロの馬から時速100キロの車に移動手段が変わったことによって移動速度の向上が移動に関する人々の考え方や価値観を変えてしまったことを例にして、年1回のリリースが1ヶ月に1回、更には1日1回のリリースに変わると開発プロセスも抜本的に変わってしまうことを示唆している。
ツールが人々の考え方や価値観を大きく変えてしまうわけだ。
アジャイル開発は単にウォーターフォール型開発を発展させたものではなく、むしろ両者は質的に断絶している。

すると、報告のジレンマの話のように、リーダーだけでなく開発者の管理業務も大きくコストがかかっているのが分かってくる。
だから、自分がどのような作業をしているのか、逐一報告するのではなく、ツールに報告させるような形へ進化するだろう、と。
チケット駆動開発のようなツールは、チケットという媒体から緩やかに作業ログを収集して進捗レポートを出力する機能があるがまさにそれに当たる。

これは作業の透明化につながる。
自分自身が報告しなくても、周囲の誰でも自分の作業進捗が分かるし、逆に自分も他人の作業進捗が分かるからだ。
作業の透明化によって、情報共有が促進され、コミュニケーションが活性化する組織的効果も出る。
互いの役割を超えて自由に議論できる雰囲気が生まれれば、様々な問題解決で多様なリソースを使いやすくなるだろう。
朝会やふりかえりなどプロジェクトファシリテーションのプラクティスを連携させれば、より効果的になるだろう。

同様に、継続的デリバリーも、リリースサイクルが年1回から数分に1回へ質的に変わった現象から発生した概念と捉えることもできる。

色々考えてみる。

Redmine運用の感想を集めてみた

Twitterを眺めていたら、Redmine運用の感想が目を引いたのでメモ。

【元ネタ1】
Twitter / @polo_kwsk: Redmineが優秀すぎる・・・普通にソフト会社に開発させたらウン千万取られるところだ・・・PJ管理インシデント管理その他もろもろ使えるいいオープンソースソフトやでぇ。社畜SEさんにもおすすめ。

Twitter / @Sean_SF: そういうのってホントにあるんだなぁ? RT @sonoyu670 あるお客さんのところでは「それredmineでええやん」という使い勝手の悪い独自のPJ管理システムを持ってて、これウン千万とかかけて作ったんだろうな、馬鹿だな、って思ってた。

フリーのBTSがまだ普及していない頃、障害管理やタスク管理の重要性に気づいた会社は独自でBTSやITSを作り込んでいた。
そういう会社は先見の明があったに違いない。
だが、長年使ってくると、オープンソースのBTSやITSの方が普及してかつ高機能になって、逆に足枷になっている場合が見られる。
システムを長く使うのか、それとも新しいシステムにリプレースして移行するのか、判断が難しい。

【元ネタ2】
Twitter / @process_ok:Redmine を使い始めてすぐに気づいたこと。 やっぱり、チケットの発行単位とか、報告ルールとか、メトリクスの設定とか、マネジメントの本質的な価値の部分はツールだけでは決まらないので、自分で決めなくてはいけない、ということ。運用次第で、使えるツールにもゴミにもなる。

Twitter / @process_ok: あと、Redmineのようなツールが多彩な機能を持っているからと言って、それに引きずられて業務フローを考えるとか、ついやりたくなってしまうけど、危険危険。 あくまでやりたいことを先に書いた方が良い。

Twitter / @process_ok: たとえば、Redmineを使えばチケットを記入したり、ガントチャートを眺めたり、というのはすぐできるのだけど、それはあなたのマネジメント目的のどの部分に合っているのか、報告する必須の情報は何なのかを説明できないといずれ行き詰まると思う。

Twitter / @process_ok: それでも、きちんとしたツールがあれば、マネジメントはマネジメント本来の業務に集中することができるので、非常に助かる。さっき書いたのはツールがまともであれば発生する贅沢な悩みだ。

Remineのカスタマイズと運用 - satospo

RedmineやTracを上手に活用する6つのポイント ? Offside

小さなチームでの Redmine 運用で気をつけている 3 つのこと - Born Too Late

Redmineによるチケット駆動開発は、プログラマ上がりの現場リーダーのための開発プロセスだと思っている。
マネジメントの経験は少ないかもしれないが、手を動かす方が好き。
マネジメントで行き詰まる時は、技術力でカバーする方が多いだろう。

そんな状況で、ツールを使って進捗管理や課題管理、コスト管理、リスク管理などをフォローしていけば、自分なりのノウハウが色々貯められるだろうと思う。
既に、CMMI・PMBOK・ITIL・RUP・Scrumなど各種プロセスのベストプラクティスもアンチパターンも公開されているのだから、ツールを使って実際に試してみればいい。

すると、Redmineのようなツールはソフトウェア開発のERPのようなものだと思える。
開発チームという貴重なリソースをいかに有効活用して、顧客へ価値ある製品を届けるのか、という問題をソフトウェアで解いていく問題に置き換えてくれる。

Redmine導入はERP導入に似ている #tidd: プログラマの思索

ALMはSW開発のERPと同義: プログラマの思索

また、Redmineによるチケット駆動開発で面白い点は、ソフトウェア開発のタスク管理以外にも、課題管理・インシデント管理・ストーリー管理にも適用できること。
受託開発のタスク管理だけでなく、運用保守におけるインシデント管理、アジャイル開発のかんばんに似たストーリー管理も可能なのだ。
チケット入力の運用ルールさえしっかりしていれば、色んな観点のビューでプロジェクトの状況をモニタリングできる。

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

チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン: プログラマの思索

チケット駆動開発の適用範囲part3～ストーリー駆動のチケット駆動開発: プログラマの思索

他にも集めてみる。

チケット駆動開発の適用範囲part3～ストーリー駆動のチケット駆動開発

ストーリー駆動のチケット駆動開発について考えたことをメモ。

【元ネタ】
Twitter / @akipii: ストーリー駆動のチケット駆動開発はチケット管理以上に牛尾さんが提唱されたストーリー供給力とストーリー検証力の方が重要ではないかと最近考えている。ストーリーの整合性、実現可能性、ビジネス戦略の観点＋PivotalTrackerのようなかんばんに近いアジャイル開発の組合せが多分ベスト

チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン: プログラマの思索

【1】チケット駆動開発は本来はタスク管理から生まれたし、タスク駆動が一番やりやすい。
でも、チケット駆動開発の面白さは、課題管理やインシデント管理、ストーリー(要件)管理のように、他のやり方にも応用できる点にある。

ストーリー駆動の場合、チケットはストーリーカードと見なす。
実際の運用は、PivotalTrackerやそのRailsクローンFlucrumのように、顧客と開発者が一体になって、チケットを書き起こして作業してリリースしていく流れになるだろう。
そして、タスク駆動のチケット管理の運用ルールが「No Tikcet, No Work」なら、ストーリー駆動の場合は「No Ticket, No Release」(@kuranukiさん談)になる。
つまり、チケットにシステムに実装して欲しい機能を書かなければ、システムに反映されてリリースされないのだ。
顧客がリリースして欲しいと思うならば、まずチケットに書いてもらわないといけない。

【2】ストーリー駆動のチケット管理はまさに典型的なアジャイル開発だが、実際の運用はノウハウがなければ難しいだろうと思う。
その理由はいくつかある。
一つはチケットの粒度が大きいと、進捗管理がやりにくいこと。
この理由は下記に書いた。

Pivotal Trackerとredmineの違い: プログラマの思索

アジャイルに開発したいなら、チケットの粒度は1人日以下になるように、ストーリーを細かく分割しておく必要があるだろう。
すると、ストーリーをそれだけ細かく分割できるくらい、システムや要件を知り尽くしていなければ、そもそも分割すらできないだろう。

2つ目は、アーキテクチャが安定しないと機能改善ではなく障害修正ばかりになってしまいがちなこと。
@Sean_SFさんが似たようなTwitterを述べられている。

Twitter / @Sean_SF: 「いわゆる「チケット駆動開発」はレベルが高い。チケットを発行してまわるぐらいアーキテクチャとプロセスが安定している必要がある。チケット駆動にしたからといってプロセスが安定するわけではない。運用、改善フェーズには良い」 #devsumiC

Webシステム開発の場合、RailsやSeasarなどのように強力なフレームワーク上で細かいUI改善や機能改善が主な作業になるので、ストーリー駆動の開発がやりやすい。
でも、アーキテクチャを一から作るプロジェクトの場合、共通部品がまず揃ってからの開発になる。
それら共通部品を使いながら機能を開発していくが、実際は開発しながら共通部品のバグを見つけたり、共通部品の使いにくい部分を改善してもらったりする場合が多いだろう。
すると、共通部品の修正が発生して、他チームや他の機能まで影響してしまい、プロジェクト全体の開発が遅延してしまいがちになる。
特に製品系列開発や派生開発のように、コア資産をベースに次々に似たような製品や機能を開発していく場合、共通部品やアーキテクチャの信頼性や保守性が高くなければ、ストーリー駆動のチケット駆動開発は安定しないだろう。

【3】3つ目は、ストーリーそのものの品質が悪ければ、思うように開発できないこと。
ストーリーは顧客観点で書かれた要件だから、開発者視点とは違う。
だが、その要件がシステムとして実現可能性があるかどうか吟味した上でストーリーを作るべき。
すると、一つの要件を実現するために、たくさんの要件が芋づる式に出てきたり、既存の機能に影響を与えてしまったりする場合が頻繁に出てくる。
牛尾さんは、AgileTourOsaka2010で「ストーリー供給力」「ストーリー検証力」というアイデアを発表されたが、まさにそういう事象を指していると考える。

Agile Tour 2010 Osakaで講演してきました - メソッド屋の日記

Agile開発に足りないもの～モデリング技術: プログラマの思索

つまり、イテレーションを実施するために必要なストーリーをイテレーション開始前に8割以上は出せるようにする。
この作業が「ストーリー供給力」であり、普通は最初のイテレーション(スパイク)で、実装はせずに要件定義を中心に作業する方法もあるだろう。
そして、供給されたストーリーの整合性を取り、システムとして実現可能かどうか、矛盾していないか、MECEになっているか、などの観点でストーリーを吟味して、ストーリーを整理していく。
この作業が「ストーリー検証力」であり、アーキテクトという役割の人が最も活躍する場でもある。

【4】最近は「アジャイルサムライ−達人開発者への道−」のように、アジャイル開発のノウハウが公開されて、誰でも試せるようになってきた。
ストーリー駆動のチケット駆動開発は多分難しいだろうが、本来のアジャイル開発に近いだけに、是非とも実施できると面白いだろうと思う。

課題管理のチケット駆動開発part2

チケット駆動開発を運用していると課題管理が難しい。
その難しさの理由の殆どは、課題や問題、リスクなどの概念をきちんと区別していないからだと思う。
以下メモ書き。

【元ネタ】
課題、問題、リスクを区別できていますか？｜プロジェクトマネジメントの現場

Redmineでスクラム実践！～アジャイル開発始めました～ (3/3) - ＠IT

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

チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン: プログラマの思索

「問題」とは目的を阻害するような「現象」「事象」「症状」。
「課題」とは「問題」を発生させる原因。
「リスク」とは現時点で顕在化していないものの、ある確度で将来課題になりうる事象。

RedmineやTracで課題管理を行う場合、問題という事象をチケットに登録してしまいがち。
でも、本来はいくつかの問題を分析して、どこにその原因があるかを見出し、その原因をチケットに登録して、チケットに対策の提案や対策を実施した履歴を記録していく。
例えば、バグが多い原因が単体テスト不足だったとしたら、それが課題となり、テストケースをきちんと書いて事前レビューするなどの対策が作られて実施していくだろう。

実際のチケット駆動開発では、タスクも課題も両方登録していく状況が多い。
課題があるからこそ、その課題を解決するためにタスクが発生し、そのタスクを実施した結果、課題が解決されたかどうか評価される。
そのサイクルを早く回しながら、次々に出てくる課題を消し込んでいく。
その課題を消し込む際に、課題チケットの内容はソースや設計書などの成果物にパッチあてのように反映される。
チケット駆動開発のトレーサビリティの機能を使えば、それら成果物の更新理由がどんな課題なのか、を後から追跡できるのもチケット駆動開発の利点になる。

Scrumを運用できるRedmineのBacklogsプラグインには「スプリント障害事項」というチケットを登録できるが、これがまさに課題に相当するだろう。
つまり、チームの開発の障害となる課題を登録して、スクラムマスターを中心として課題を解決していくわけだ。

また、チケット駆動開発の運用が慣れたら、リスクもチケットに登録していくようになる。
「この機能にはユニットテストが足りないかもしれない」「この実装部分は将来のためにリファクタリングした方がいいかもしれない」などのように、現在は大きな問題にならないが将来に問題となるような気づきは結構ある。
それらもチケットに備忘録として登録しておくが、リスクのチケットは優先度が低いから現在すぐに作業は実施しない。
次のイテレーション計画を作る時やリリース計画全般を見直す時に、それらリスクのチケットを入れるかどうか判断する運用になるだろう。

コミュニティがチケット駆動開発を支えている

コミュニティとチケット駆動開発の関係についてメモ書き。

チケット駆動開発は元来、@machuさんがTracのチケット管理を運用した経験を発表資料として公開されたのが始まりだった。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

そして、Redmineを運用していた時に、その発表資料にあるエッセンスに刺激を受けて、アジャイル開発へ適用して試してみて、かなりうまくいった。
その経験を元にKOFで初めてRedmineによるチケット駆動開発について発表した。

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」: プログラマの思索

そこから「Redmineによるタスクマネジメント実践技法」が出版された後、アジャイル開発に興味のある一部の人たちにチケット駆動開発が注目された。

Redmineの設定方法や使い方よりもRedmineを用いてのアジャイル開発手法に重きを置いて解説してた　チームメンバーに是が非でも共有したい　する　はてなブックマーク - jiska - 2011年4月4日

デブサミ2011でチケット駆動開発について講演したら、既にチケット駆動開発を実践されている人達は多くて驚いた。
ネットでも、製薬業や製造業の人達もRedmineによるチケット駆動開発を実践していたらしく、「Redmineによるタスクマネジメント実践技法」で書かれているアジャイル開発の言葉(例えば、イテレーション、バックログ、小規模リリースなど)がよく分からないという感想があった。

なぜか分からないけど、「チケット駆動開発」という言葉が急速に普及したように思う。

そんな情勢の中、Tracのコミュニティは以前からShibuya.tracが活発に活動されていたが、Redmineの注目度が上がっている割にはRedmineコミュニティは日本に存在しなかった。
だが、2011年の夏に関西でRxtStudy、関東でshinagawa.redmineが有志で立ち上がった。
僕もその立ち上げに関わった。

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

【公開】第1回品川redmine勉強会の発表資料「障害管理からチケット駆動開発へ～ソフトウェア開発の3種の神器」 #47redmine: プログラマの思索

第1回RxtStudyは、Redmine本の著者4人全員が揃ったという事実が一番大きかったと思う。
Redmineのマーケットが日本にあるということがよく分かった。
@kuranukiさんの話もRedmineから離れた話になったけど、皆釘付けになって聞き入っていたのが印象的だった。

そして、東京ではshinagawa.redmineがIPA様のご厚意で提供された場所で、Redmineコミッタの丸山さんをお招きして開催された。
東京でもRedmineに関心のある人が多いというのがよく分かった。

そんな経緯を振り返ると、チケット駆動開発はコミュニティが育ててくれたのだと思う。
@machuさんがそのアイデアを公開しなければそんな話は出てこなかった。
チケット駆動開発をアジャイル開発へ適用した経験をXPJUG関西やSEA関西の人達と議論できなければ、これほど深く突き詰めて考えることもなかった。
そして、チケット駆動開発の講演場所を提供してくれたRuby関西、XPJUG関西、そしてアジャイルに関係するコミュニティがなければ、発表しながらチケット駆動開発のアイデアを育てていくこともなかった。

更に、Redmine非公式サイトを運営される@g_maedaさん、Redmineプラグインを次々に開発する人達(@daipresentsさん、@suerさん、@haru_iidaさんたち)、Redmineの機能改善に貢献する人達(@naitohさんたち)、Redmineのインストールツールを開発する人達(@mikoto20000さんたち)がいなければ、ここまでRedmineコミュニティが日本で大きく目立つこともなかった。

Redmineに関する課題と展望: プログラマの思索

RedmineもTracも、GitやMercurial、JenkinsやHudsonのようなツールは実際、コミュニティがその発展を支えている。
更に、Redmineは丸山さん、Gitは濱野さん、Jenkinsは川口さんのように日本人コミッタがツールの発展に大きな役割を果たしている。
日本人コミッタがいるおかげで、日本人開発者も積極的にこれらツールに関われるし、ツールの発展に大きく寄与していると思う。
日本のソフトウェア業界は輸出が殆ど無く海外で勝てないと言われるけど、コミュニティに出た限り、日本人開発者で優れた人はたくさんいる。
少なくともソフトウェア開発の3種の神器に関しては、日本人技術者が世界へ大きく貢献していると言えるのではないだろうか？

開発現場で試行錯誤して見出したチケット駆動開発というアイデアがどこまでソフトウェア開発の本質を変えてくれるのか、考えていく。