TiDDを実践して気付いたことpart7～繰り返し開発を制する者はSW開発を制す

先日、S-OpenでRUPで有名なクールシュテン博士によるアジャイル開発の講演があった。
Agile開発は大規模プロジェクトでは難しい、アーキテクチャを重視するプロジェクトでは難しい、などの話を聞いて、そんな話は昔から聞いていた、と正直聞き飽きた。

そんな違和感を感じながらも、チケット駆動開発を実践して、アジャイル開発の難しさが何となく分かってきた気がする。
考えたことをメモ。

【元ネタ】
TiDDを実践して気付いたことpart6～TiDDでAgile開発を実践して分かってきたこと: プログラマの思索

TiDDを実践して気づいたことpart4～TestLinkによるテスト戦略: プログラマの思索

以前書いたように、Agile開発が難しい理由は、その最大の特徴である「超短期間の繰り返し開発」を実現するハードルが高いことにある。
その内容は次の3つに言い換えられる。

１・繰り返し開発はイテレーション管理が難しい
２・繰り返し開発において、インクリメンタル型開発と反復型開発を混同してる
３・繰り返し開発は並行開発でもあるため、並行開発の制御が難しい

１は、変化を受け入れる技術、プロジェクト管理、開発環境がなければ、アジャイル開発は絵に描いた餅だ。
当初の計画になかったタスクの追加、イテレーション内におけるタスクの優先順位の変更は、頻繁に起こるが、確実に対応するのはやはり難しい。
タスクから成果物まで追跡できるインフラがなければ、ほんの少しの仕様変更の対応なのに、バグを混入させてしまい、品質を劣化させてしまう。

３は、実は、繰り返し開発には並行開発というプロセスが実は隠れているという指摘。
短期間にリリースしていくと、一度リリースしたシステムは生き続けるが、裏では次バージョンに向けて機能改善していく。
大規模プロジェクトになるほど、複数のサブチーム、サブシステム、製品ファミリーで同じような現象が起きるから、どんどん制御が難しくなる。

２で提起した「漸進型開発(インクリメンタル)」と「反復型開発(イテレーティブ)」の使い分け戦略こそが、違和感の根源だと思う。
「アジャイル開発では、アーキテクチャ重視や品質重視のプロジェクトでは有効でなかった」と講演で話していたが、それは漸進型開発のみで解決しようとして失敗するだけであって、2種類の繰り返し開発を切り替える発想がないだけだと思う。

一定の期間で機能拡張しながら小刻みにリリースしていく漸進型開発は、開発者にとってとても楽しい。
リリースするたびに作ったものが動くので、ユーザが確認できるだけでなく、開発者にとっても、開発のゴールはリリースなのだ、といつも再確認できる。
イテレーションのリズムで開発するのは、開発者のモチベーションアップにつながるし、楽しい。
試行錯誤しながらリリースしていくというスタイルには、漸進型開発がとてもやりやすい。

でも、アーキテクチャを作りこんでから機能追加していくスタイルや、とにかく稼動するシステムへ更に品質を作りこんでいくスタイルには、漸進型開発だけでは物足りない。
アーキテクチャや品質は1個のイテレーションだけで実現できるわけがない。

例えば、性能などの非機能要件は、全てのイテレーションで実現せねばならないが、解決方法は、試行錯誤しながら分かる時が多い。

また、作った機能の殆どは単体テストを通過しているから動くけれど品質に不安がある場合、システムテストや受入テスト、モンキーテストなどで、システム全体をテストして細かなバグを潰していく。

あるいは、ソフトウェアプロダクトラインのように、製品ファミリーの共通部品をコア資産として抽出し、各製品の特徴はアプリケーション資産で開発するスタイルの場合は、どうしてもアーキテクチャ重視になる。
そのアーキテクチャは試行錯誤しながら、決めていくことが多い。

品質もアーキテクチャも反復型開発で、システム全体を俯瞰して少しずつ作りこんでいく方がやりやすい。
でも、反復型開発の弱点は、スコープが発散しがちなこと。
実際の開発では、テストしながら仕様変更にも対応したり、割り込み作業が入ったり、変化が発生する。
更に、アーキテクチャや品質はいくらやっても、終わりがない作業だから、それらに対応するたびに、どんどん工数も作業の範囲も膨らむ。
だから、反復型開発はスコープを意識しなければ、とても難易度が高いと思う。

逆に、漸進型開発では、リリースと言うとても強い制約条件のおかげで、スコープがあまり広がることはない。
リリースというゴールがあるから、開発チームだけでなく、ユーザにも強い制約をかけることができる。

他に、大規模プロジェクトに繰り返し開発を適用する場合、サブチーム内部では漸進型開発で開発させて、複数のサブチームの結果を統合するイテレーションでは反復型開発に切り替える手法が最も現実的だと思う。
例えば、Webシステムの結合テストや、組み込み製品開発でSWチームとHWチームが連携する工程は、反復型開発に切り替えて、品質をまず確保する戦略を取る。
特に、チームのスケールアップには、反復型開発の方がやりやすいように思う。

チームのスケールアップでは、並行開発のインフラがあることも重要だ。
つまり、サブチーム単位にブランチがあるわけだから、そのブランチ間で最新機能を相互に確実にマージできるインフラがなければ、すぐに統制が取れなくなる。
多分、MercurialやGitのような分散バージョン管理がその解決方法になるだろう。

反復型開発をどの場面で使うべきか、漸進型開発をどの場面で使うべきか、戦略がはっきりしていないから、未だにアジャイル開発は難しい、と言っているだけなのだ。
それらの問題は、分散バージョン管理とチケット駆動開発を組み合わせれば、開発インフラに関してはほぼ解決できると思う。

今のSW開発は、常に新しい技術を取り込んで、定期的にバージョンアップする宿命を持つ。
変化を取り入れるのはSW開発の宿命。
繰り返し開発は「変化を受け入れる」ことができるのが最大の特徴。
繰り返し開発を制する者はSW開発を制するのだ。

チケット駆動開発のアンチパターンpart2

チケット駆動開発のアンチパターンで気付いたものを更に追記しておく。

【元ネタ】
チケット駆動開発のアンチパターン: プログラマの思索

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

【再考】TiDDのプラクティス集: プログラマの思索

【1】メトリクスの罠

RedmineやTracでは、いくらでもチケット集計結果からメトリクスを得られる。
管理者はついつい、そのメトリクスで実績評価して、メンバーのモチベーションを下げてしまいがち。
メトリクスは万能ではない。

メトリクスだけではプロジェクトの現状を把握できないのが現実だ。
メンバーの表情、各種の成果物、など色んな観点から、プロジェクトの現状が定まっている。
いくらメトリクスが悪くても今改善途中かもしれないし、メトリクスが良くても実はメトリクスを改ざんしているのかもしれない。

メトリクスはバッドノウハウの塊。過信しない方がいい。

【2】問合せはバグ修正なり

顧客からの問合せや設計者への仕様の質問をチケットへ起票する時、そのチケットをバグ修正のワークフローで管理してしまいがち。
すると、問合せの作業状態を管理しにくいし、担当者がチケット更新方法をよく間違える。
「問合せ中」「回答済み」のステータスがバグ修正のどのステータスに相当するか、正直分かりにくい。

理由は、BTSのデフォルトの機能であるバグ修正のワークフローだけでは、SW開発の全ての作業をカバーできないから。
所詮、BTSはバグ管理にしか過ぎない面がある。

また、仕様の質問を問合せフローでチケットに起票しておけば、開発中やテスト中に、何故こんな仕様になったのか、要件を探す元ネタになりうるので役立つ。
あるいは、顧客の問合せなどのインシデント管理をチケットに残しておけば、どんな問合せが多いか分析できる。
例えば、「ログインのパスワード忘れた」という問合せが多いならば、パスワードリマインダーの機能を追加したら問合せ数が減りますね、という話に持っていける。

現場のメンバーと試行錯誤しながら、ワークフローを編み出した方がいい。

【3】チケットを決められない

特に大規模プロジェクトでは、担当タスクを他のサブチームに作業をお願いしたり、上級SEを通じて顧客へ問い合わせるなど、チーム外と連携する時が多い。
その時、チームから上がったチケットをどのように対処すればいいか、プロジェクトリーダーさえも対処しようが無い時がある。
こういう状況では、関係するステークホルダー全員で決めるしかない。

大規模プロジェクトでは、「進捗会議」「課題管理会議」と称して、サブチーム間で連携しなければ対処できないタスクを調整したり、溜まったタスクを関係者全員で棚卸しする会議がある。
いわゆる変更管理会議(CCB)、あるいは変更諮問会議(CAB)。

上記のようなチケットは、このような会議で一つの議題にしてもらい、ステークホルダー全員で、優先順位付け、対処方針を立てる、各チームの調整を行うのがよいと思う。
但し、会議で決めてもらう分、利害が対立しやすく、チケットの作業期間が長くなるので注意。

【4】足りないステータス

担当者の作業状態がチケットのステータスに紐づいていない状況。
例えば、レビュー中、テスト中、本番リリース前(開発環境にリリースして検証OKだが本番リリースしていない)などのステータスが無い場合が相当するだろう。

これらのステータスがなくてもプロジェクトが回るのならよいけれど、今誰がこのチケットを担当しているのか分からなくなるようなら、ステータスを増やした方がいい。
ステータスが無いために「このチケットは今どうなっている？」というやり取りが多いならば、無駄なコミュニケーションのコストがかかっている。

ステータスが不足していると思える状況は、BTS以外のツールと連携したり、ペア作業を行いたい時だ。
TestLinkとバグ検証を連携したり、Hudsonとデプロイ＆リリース作業を連携するならば、ステータスを増やした方がやりやすい。
また、バグ修正＆検証やコードレビューをペア作業する場合は、担当者ごとのステータスがあれば、作業状態や進捗情報を追跡しやすくなる。

リリース後のふりかえりMTで、開発者とKPTしながら改善すればいいだろう。

他にも気付いたら追加していく。

TiDDを実践して気づいたことpart4～TestLinkによるテスト戦略

チケット駆動開発にTestLinkを導入してテスト管理してみて、テスト戦略みたいなものをぼんやりと感じた。
以下メモ書き。

【元ネタ】
脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所

テスト手法の概念をTestLinkで説明する: プログラマの思索

TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索

TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索

TestLinkを運用して気付いたことpart4～TestLinkの概念を再考: プログラマの思索

TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念: プログラマの思索

TestLink・BTS・SVN・Hudsonの関連構造: プログラマの思索

【1】Redmineによるチケット駆動開発はとてもアジャイルに開発できるけれど、システムテストや受入テストの進捗管理はやりにくかった。
テスト工程の進捗管理は、テストケースの実施数・成功数・失敗数の予定・実績を比較することにあるけれど、Redmineチケットはテストケースと一致しないからだ。
だから、TestLinkを導入して一番良かったのは、テスト結果集計画面で、リアルタイムにテストの進捗を見れるようになった事であり、それから早期に是正対策を取るのが可能になった。

TestLinkがExcelなどの他のテスト管理ツールよりも良い点の一つは、Redmine・Trac・Mantisなどの既存のBTSと連携する機能がある事だ。
この機能によって、テストケースに失敗した場合、BTSチケットにバグの内容を書き込んで、バグ修正とバグ検証をペアプロのように作業できるようになる。

SW開発で最も難しい局面は、結合テスト(Integration Test)・システムテスト(System Test)・受入テスト(User Acceptance Test)などの各テスト工程で頻発するバグをいかに直していくか、にある。
バグ修正＆検証フローは実はとても複雑なワークフローであるからだ。

脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所の「図4－4－4　TestLinkのバグ検証とRedmineのバグ修正の連携フロー 」に書いたように、バグは修正して終わりではなく、バグ修正内容を検証して、更に失敗したテストケースが成功した所までの作業を含む。
そして、この作業は、バグを発見し検証するテスター、バグを修正する開発者、リリース作業を行うライブラリアン、そして全てのプロセスを監視するプロジェクトリーダーの4人が関わるので、そのやり取りだけで忙殺されやすい。

従来は、この作業内容をExcelの障害報告書に記載して、紙ベースで管理し、各担当者が判子欄にサインして承認するというフローをやっていた。
だから、バグが1日10件も出るととても煩雑になり、バグ管理だけでプロジェクトリーダーが忙殺される時も多かった。

TestLink＋Redmineの良い点は、この作業をチケット駆動開発と言うプロセス上で、バグ修正＆検証のワークフローを明示した点にある。
更に、脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所の「図4－4－5　バグ修正に対するRedmineチケットの状態遷移図 」に書いたように、Redmineのデフォルトのワークフローではバグ検証の作業管理がやりにくいので、更にカスタマイズした。

これが本来のバグ修正なのだ、と気付いた瞬間が、TestLinkによるテスト戦略を感じた時の一つ。

【2】TestLinkのテストケースのステータスには「成功」「失敗」「未実施」以外に「ブロック」がある。
「ブロック」は事前条件を満足できないためテスト不能な状態を表す。
このブロックを初めて使いこなせて、テストにはバグ検証の限界があるのだと気付いた時が、TestLinkによるテスト戦略を感じた2番目の瞬間。

実際にテストしてみると、1個のテストケースが失敗すると、1個のバグが出て、後続のテストケースは全てブロックになる。
更に、バグに依存する機能のテストケースは、全て「みなしバグ」になり「失敗」になる。
また、バグの原因を追求すると、類似バグが出てくる為、更にバグが増えてくる。

ブロックやみなしバグの発生源は、ブロッキングバグと言われる。
まさに、テストどころか開発そのものをブロックしてしまう危険バグを指す。
テスト工程では、ブロッキングバグをいかに早く的確に潰すか、が鍵を握る。

実際は、1個のテストケースの失敗の影響はとても大きく、最低10個のテストケースが「失敗」又は「ブロック」になる時が多い。
つまり、「みなしバグ」や「ブロック」のテストケースはテストしても無意味なのだ。
以前は、「みなしバグ」や「ブロック」の発想がなく、とにかくテストしまくるものの、バグが出た為に再テストするテストケースが多発して、うまく制御できなかった。
だから、無駄にテスト工数を浪費して、肝心のバグ修正がおろそかになる場合も多かった。

そんな経験を経て、イテレーション単位にTestLinkのテスト計画を実施しながら、常にテストの失敗率に注目するようになった。
理由は、テストケースの失敗率がある上限を超えると、殆どのテストケースがブロック又はみなしバグで失敗の状態になってしまい、もはやテストしても無意味になる状態があるからだ。
僕の経験では、失敗率が10％を超えるともはやテストしても無意味で、ブロッキングバグを修正するよりも、最初から単体テストをやり直す方が早いように感じてしまう。

【3】TestLinkのテスト結果はビルドという概念で管理される。
ビルドはビルド番号を指すと教えてもらった時、ビルドでイテレーションを管理すればいいのだ、と気付いた瞬間が、TestLinkによるテスト戦略を感じた3番目の瞬間。

ビルドの利点は、同じテストケースを回帰テストで管理しやすくなる事。
また、ビルドのテストケースが全て完了したら、ビルド番号を振り直せば、ビルドモジュールの履歴に書かれたチケットNoからバグチケットを探す事ができる。

アジャイル開発にTestLinkを組み込む場合は、TestLinkのテスト計画をイテレーションと見なして、反復型テストを行えばいい。
すると、テストケースを作ってテスト計画を立てた時点で、テスト期間が短すぎたり、テスターや開発者が少なすぎたり、テストケースがそもそも多すぎる場合、実は納期までにテストが終わらない事実が判明する時がある。
原因は、テストと言うスコープを制御できていないのだ。

2～4週間のイテレーションにテスト計画を押し込めるには、2種類の戦略がある。
一つは、イテレーション内で開発とテストの両方を行い、テスト完了後にリリースするインクリメンタル型開発。
もう一つは、開発のイテレーションが完了後、せいぜい数百の単位でテストケースを分割したイテレーションを順次テストしていく反復型テスト。

普通のシステム開発では数千～数万のテストケースに膨れ上がる為、おそらく反復型テストが基本戦略になるだろう。
イテレーションとテスト計画を同一視することで、テストのスコープを制御しやすくしているのだ。

更に、後追いテストや五月雨式テストというテスト戦略も出てくる。
後追いテストは、テスト完了後からリリース直前までに優先度が低いテストケースや未実施のテストケースを後を応用に実施する事。
五月雨式テストは、仕様追加が頻繁な場合、仕様が決まって開発が終了次第、すぐにテストして、五月雨式に開発＆テストしていく事。

後追いテストも五月雨式テストも、十分すぎる品質よりもスケジュールを重視する昨今のビジネスを反映していると言える。
ほどほどの品質をまずは確保した後で、リリースを優先し、品質を作りこむテスト戦略。

プロジェクトリーダーは、インクリメンタル型開発・反復型テスト・後追いテスト・五月雨式テスト等のテスト戦略を意識的に使い分ければ、SW開発で最も難しいテスト工程をコントロールしやすくなるだろう。

TiDDを実践して気付いたことpart3～繰り返し開発の戦略

Redmineでチケット駆動開発を実践して改めて、アジャイル開発は繰り返し開発であると認識した。
Redmine、Trac、Mantisでチケット駆動開発を経験してみて、繰り返し開発の戦略やコツがあるのがぼんやりと分かってきた。
ロジカルに言い尽くせないけれど、以下メモ書き。

【元ネタ】
変更要求に対する選択肢: プログラマの思索

Subversionコードラインのライフサイクル: プログラマの思索

チケット単位に並行開発する事例: プログラマの思索

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

チケット駆動開発のモチーフ: プログラマの思索

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

【再考】TiDDのプラクティス集: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間: プログラマの思索

【1】チケット駆動開発では、タスクを全てチケットに書き起こし、それらチケットをリリース計画に基づいて各バージョンへアサインし、順次リリースしていく。
つまり、XPの小規模リリースとは、2～4週間という短期間でリリースを繰り返す繰り返し開発である。

繰り返し開発(スパイラルモデル)には、インクリメンタル型と反復型の2種類があるのは既に知られている。
インクリメンタル型は、各繰り返し(イテレーション)でどの機能を実現するかを決め、それを１回の繰り返しでリリースする。
反復型は、各繰り返し(イテレーション)でシステム全体の機能を少しずつ作っていき、何度も繰り返して完成させる。

RUPが反復型開発であるのに対し、XPやScrumのようなアジャイル開発は、基本はインクリメンタル型開発だ。
顧客価値を重視する開発スタイルだから、顧客へ早めにリリースすることを優先する。
つまり、XPの小規模リリースとは、小刻みに機能拡張しながらリリースしていくインクリメンタル型開発スタイルを指している。

インクリメンタル型開発の利点は、機能というスコープが小さいのでスコープを制御しやすい点にある。
リリースが最終ゴールだから、スコープが揺れていてはリリースできないからだ。

逆に反復型開発は、スコープを制御しづらい弱点があるように思う。
例えば、工程ごとの繰り返し開発の途中で、度重なる仕様変更を取り込んでしまい、スコープを制御できずに破綻してしまう時は多くないだろうか？

しかし、反復型開発では、システム全体の機能を何度も繰り返しながら作り上げるため、スコープさえ制御できていれば、品質を向上させるために使える。

【2】Redmineでチケット駆動開発を実践すると、自然にインクリメンタル型開発になったけれど、それだけでは品質には不安があった。
だから、TestLinkを導入して、システムテストや受入テストの工程を別のイテレーションで実施し、色んな観点のテストやバグ修正を行って、品質向上を図った。
すると、このイテレーションは、反復型開発に似ているのに気付いた。

つまり、リリースできる品質まで持ってきたが、更なる検証で品質を向上させたい場合、インクリメンタル型開発から反復型開発にチェンジして、複数回のイテレーションでテストを実施する手法だ。
これによって、TestLinkのテスト計画をRedmineのバージョンに見立てて順次テストしていく反復型開発がやりやすくなった。

【3】反復型開発を使う場面は他にもある。
特に、複数のサブチームによる大規模開発、ソフトウェア開発チームとハードウェアチームが連携する組み込み製品開発などが相当するだろう。

例えば、組み込み製品開発では、SWチームは、HWチームから提供されるハードウェアを元に、HWチームの開発サイクルよりも短いイテレーションで順次開発してみる。
理由は、早めにハードウェアとソフトウェアを結合して動作させながら確認したいからだ。

すると、この場合、HWチームの1イテレーションに対し、SWチームは複数のイテレーションをこなしていることになる。
つまり、イテレーションの入れ子構造で反復型開発を行っている。

反復型開発のもう一つの利点は、イテレーションの入れ子構造によって、開発のスケールアップがやりやすい点もあるだろう。

【4】インクリメンタル型開発が難しい理由は、並行開発になってしまう点にあると思う。

例えば、イテレーションで実装した機能をリリースしたら、そのシステムは顧客の前で動き続けるが、裏では開発チームが次のイテレーションの機能を実装し始める。
そして、次のイテレーションの機能をリリースしたら、前のイテレーションのシステムは廃止して、裏で次の次のイテレーションの開発を始める。
つまり、自然に、本番運用と新規開発の2種類のコードラインを常時保守せざるをえないのだ。

但し、並行開発に対する一つの回答は、メインラインモデルという構成管理手法で既に知られている。
つまり、trunkというメインラインからリリースする時は、ブランチを派生させ、常にtrunkが最新の安定した機能となるようにコードラインを保守する手法。

メインラインモデルの手法は、いくつかのバリエーションがある。
おそらく最もよく使われる手法はタスクブランチだ。
例えば、現在、Ver3.0へ向けて開発中で、その次のリリース予定のバージョンは4.0である時に、突然の仕様追加に対応しなくてはならなくなった場合、Ver3.1のタスクブランチを定めて、Ver3.0→Ver3.1→Ver4.0の順にリリースしていくという開発スタイル。
このタスクブランチの手法によって、品質を維持しながら、納期とスコープ、工数のバランスを取ることができる。

チケット駆動開発では分散バージョン管理を使って、更にトピックブランチという開発スタイルも選択できる。
つまり、チケットごとにトピックブランチをローカルに作って開発し、最後にtrunkへプッシュする開発スタイル。
これはタスクブランチを各チケットへ更に分化した場合に相当する。
GitやMercurialを使っていれば、おそらくスムーズに運用できるだろう。

チケット駆動開発による小規模リリースは、インクリメンタル型でも反復型でもどちらの繰り返し開発も運用可能だ。
繰り返し開発では、インクリメンタル型と反復型を故意に使い分ける戦略が重要ではないだろうか？
また、アジャイル開発が難しい理由は、インクリメンタル型と反復型を使い分けるノウハウがなかなか見当たらず、実践しにくい点にあるのではないだろうか？

プロジェクトマネジメントプリンシプル

「プロジェクトマネジメント プリンシプル - 変革の時代を生き抜くための人と組織の挑戦　[原書名：The Principles of Project Management]」を読み始めた。
今まで敬遠していたPMBOKの概念が支障なく理解できる。

プロジェクトマネージャがその権限を振るえる組織、チームビルディング、コンフリクトマネジメント、調達管理。
プロジェクトと言う形態が工学として知識体系化されたきっかけは、航空宇宙科学のプロジェクトから始まったのか、とか。
プロジェクトチーム形成や人的資源管理は、まさにプロジェクトファシリテーションそのものだな、とか。
「変化を抱擁する」をフレーズとしたXPは、まさにプロジェクトの特徴をおさえているな、とか。

内容は少し古いけど、エッセンスは詰まってます。

チケット駆動開発でメトリクス採取コストを下げる

面白い記事を見つけたのでメモ。

【元ネタ】
データを見ないプロマネ

(前略)
ですが、トラブルになるプロジェクトは経験上、
* プロジェクトデータを継続的に収集できる仕掛けがない
* メトリクスの分析とフィードバックが不十分(集計して眺めているだけ…）
のいずれかが該当するはず。
こういうプロジェクトは個人的にPDDD(Plan-Do-Do-Death)プロジェクトと呼んでます(^^)
オープンソースのプロマネツールも数多く存在する現状を考えると「プロジェクトデータを継続的に収集できる仕掛けがない」プロジェクトは減ってくでしょうから、プロジェクトデータを分析して、早めに適切なアクションを打つことができるプロマネの価値はさらに高まっていくのではないでしょうか。

マネジメントの基本は予定と実績の比較・評価から是正対策を立てることだ。
しかし、計画を立ててその後は知らない、制御できない、というプロジェクトは数多い。

プロジェクトデータを採取しようにも、メンバーの入力工数が逆に増えて、プロジェクトの生産性が落ちる場合がある。
ある大手SIでは、メンバーに15分おきに作業内容を強制的に入力させていると聞いたが、開発者は奴隷ではないから、むしろモチベーションも低下しているのではないか？

チケット駆動開発では、SVNコミットする時にチケットと連携する機能があるし、チケットに作業履歴だけでなく進捗情報を記入することもできる。
つまり、開発者がToDo管理している感覚の背後で、BTSがチケットを自動集計して、進捗や品質に関するメトリクスを出力してくれる。

PMBOKなどのマネジメント手法も一般化しているから、メトリクスさえあれば好きなようにリスク分析できるはずだ。
今後のプロマネは、マネジメント手法だけでなくメトリクスを採取するツールや運用ルールも考慮する必要があるだろう。

チケット駆動開発のアンチパターン

チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。
以下メモ書き。

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

【再考】TiDDのプラクティス集: プログラマの思索

【1】チケットのアンチパターン
【1-1】乱発されたチケット

よくある最悪なパターンは下記2ケースがあるだろう。

設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。
あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。

そのままチケットに登録すると、チケットが乱発される。
そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。

こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。

【1-2】有効期限切れのチケット・放置されたチケット

終了予定日を過ぎて放置されたチケットを指す。
担当者がアサインされていないチケット、担当者も作業を忘れてしまったチケットが相当する。
こういうチケットが増えるたびに、チケットの精度も運用ルールも混乱していく。

対策としては2種類あると思う。
一つは、チケット管理の最終責任者は現場リーダーである事。
現場リーダーは、定期的に必ずチケットが最新の状態であるかチェックし、担当者へ逐一作業確認すべきだ。
担当者がアサインされていないチケット、リリース予定のバージョンがないチケットはすぐに保守すべきだ。
それが現場リーダーの本来の仕事であるからだ。

もう一つは、バックログのような特別なイテレーション、インシデント管理用プロジェクトのような特別なプロジェクトで管理すること。
顧客からの改善要望や問合せは、Scrumのプロダクトバックログのように、バックログのイテレーション又はインシデント管理用のプロジェクトで別管理する。
開発チームは、それらをチケットに登録しておくが、平時の開発作業とは別の作業であると認識し、リリース計画を立てる時に、顧客の要望や問合せを精査して、どのバージョンへリリースするか、取捨選択する。
つまり、XPの計画ゲーム、Scrumの計画プロセスに相当する作業を、バックログやインシデント管理プロジェクトで行う。

あるいは、ソースがコーディングルールに則っていない、とか、リファクタリングすべきだが優先度が低いなどの開発チーム内部の作業は、内部課題の特別のイテレーションで別管理する。
これらもチケットに登録しておくが、平時の開発で関係するチケットにリンクさせておく。
これらのチケットは、リスク管理に相当する。
工数見積もりが実績と大きく異なるのは、リファクタリング工数を見積もっていない場合がとても多いからだ。

【1-3】責任が重すぎるチケット

複雑で大変な作業、複雑な複数の成果物を作る作業を一人の担当者がアサインされた一つのチケットにしてしまう状況。
その担当者のプレッシャーは大きいし、担当者がもし新型インフルエンザにかかったら、誰もカバーできなくなる。

チケットは仕様書ではなく、作業指示書だ。
だからこそ、WBSのように成果物単位に細分化し、更に1個の成果物を一人の担当者が1週間以内に作業するまで細分化すべきだ。
実際の現場に合わせて、チケットの粒度はカスタマイズすればいい。

おそらくリリース後に集計したら、1人日以内のチケットへ細分化されているだろう。

【1-4】停滞したチケット

アサインされた担当者のチケットの進捗が進まない状況。
よくある状況は、進捗が90％のまま1週間経ってしまうこと。

対処としては2つある。
一つは、実績の進捗率は、0％・50％・100％の3種類と固定する方法のように、ルール化する。
つまり、チケットのステータスと進捗率を対応付けする。

もう一つは、チケットの中身を精査して、別作業を別チケットへ細分化すること。
チケットの進捗が悪い原因は、WBSの洗い出しが不十分だった時が多い。

例えば、1個の画面を実装するのに、実は複数の共通ライブラリ、モジュール、共通画面を作るために工数がかかっている、とか、新規の機能追加のはずなのに実はリファクタリングしていた、など、作業の予定と実績が大きく狂っている時が多い。
つまり、現場リーダーの作業割り振りが間違っているのが原因の大半だ。

【1-5】タスクがチケットに書かれない

開発チームでやるべき作業をチケットに登録していない状況。
例えば、ビルド作業、テストデータ作成作業、開発環境の構築作業などのように、顧客に無関係で開発チーム内部でやるべき作業を登録せずに、あうんの呼吸でやっている場合が多いだろう。

すると、やるべきタイミングで作業を忘れて、進捗が遅れたり、作業の品質そのものが落ちる。

この状況の根本原因は、WBSの洗い出しが不完全か、せっかく洗い出したWBSをチケットにすべて登録していないか、のどちらかだ。
つまり、現場リーダーがチケット駆動開発の運用ルールを徹底できていないのが根本原因だ。

【1-6】SCMと連携されてないチケット

SVNコミットする時に、チケットNoを書き込まず、チケットとSVNリビジョンが紐づかない状況。
まちゅさんは「No Ticket, No Commit!」と呼んで重視している運用ルール。
この状況では、せっかくのチケットが単なる作業履歴に過ぎない。

チケットとSCMが連携することによって、要件からソース、ビルドモジュールまでチケット経由で相互に追跡可能になる利点がある。
特に要件管理を実現したい場合に、とても強力な運用ルールだ。

【2】バージョンのアンチパターン
【2-1】ゴールの見えないバージョン

いつまで経ってもリリースできないバージョン。
よくある例は、顧客の改善要望の言いなりになって、バージョンへどんどんチケットを追加していくこと。
すると、いつまで経ってもリリースできないどころか、システムの品質がどんどん劣化していく。
機能追加すれば、必ずバグが紛れ込んでしまうからだ。

ScrumでもXPでも、スコープをあらかじめ制御しておくことを重視する。
イテレーション実施中に突然の仕様変更の要求が来たとしても、基本は次イテレーションに回して、すぐに対応しない方がいい。
機能追加よりも品質を重視する方が、手戻り作業が少なくなるからだ。

【2-2】優先度がごちゃ混ぜのバージョン

リリース計画、イテレーション計画がきちんと行われず、一つのバージョンに全てのチケットが放り込まれた状況。
例えば、顧客の問い合わせ・改善要望・障害報告、リファクタリングなどの作業が混じっていて、メンバーは、何から手をつければよいか、分からなくなっているだろう。

XPの計画ゲームでも、Scrumの計画プロセスでも、リリース計画をきちんと作る。
複数のバージョンを立てて、定期的に小刻みにリリースしていくという開発スタイルを取れば、チケットの優先度は自然に定まる。
顧客の要件の重要度と開発工数のバランスから、リリース計画が作られて、そのバージョンにチケットをアサインしていく。
上記の状況に陥った原因は、現場リーダーがプロジェクトのスコープをきちんと管理できていなかったことにあるだろう。

また、開発サイクルが異なるチケットは別管理にした方がいい。
例えば、顧客からの単なる質問やリファクタリングなどは、別のバージョンやプロジェクトで管理した方がいい。
本番運用のソースと新規開発中のソースをブランチで別管理するように、プロジェクトもブランチ単位で分けた方がいい。

【3】プロジェクトのアンチパターン
【3-1】大規模プロジェクトでごちゃ混ぜのプロジェクト

大規模プロジェクトでは、複数のサブチームのタスク管理が必要になるが、一つのプロジェクトに全てのサブチームのタスクが混在している状況。
TiDDを実践すると、経験的に5人以上のチームのタスク管理は非常に煩雑になる。
理由は、TiDDにおけるチケットの粒度は開発者視点なので、とても細かいからだ。

だから、複数プロジェクト機能を使って、サブチーム単位や工程単位などで分けた方が管理しやすいと思う。

また、チケット管理の専門担当者を配置し、随時チケットを保守させる。
更に、定期的に課題管理会議を開いて、チケットの棚卸を行った方が良い。
チケットに上がった問題が複数のサブチームが連携しなければ解決しない場合もあるので、調整作業が必要だからだ。
あるいは、どのチケットから手を付けた方が良いか、サブチームのリーダーの観点ではなく、もっと上層部のマネージャの観点で優先度を決めた方が良い場合も多々あるだろう。

他にも気付いたアンチパターンがあれば、随時追加していきたい。

TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間

TiDD(チケット駆動開発)が何故、アジャイル開発と密接に関係するのか、経験を思い出して考えてみたことをメモ。
＃下記はロジカルでないので注意。

【元ネタ】
裏プロセスは並行プロセス: プログラマの思索

チケット駆動開発のモチーフ: プログラマの思索

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

【再考】TiDDのプラクティス集: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

【1】Redmineでチケット駆動開発を実践して、これがアジャイルだ！と気付いた瞬間は、イテレーションと言うリズムに気付いた時だ。
Redmineのロードマップ画面で、バージョン毎にチケットをアサインした後、バージョンの進捗率が100％になり次第、随時リリースしていった。
すると、開発メンバーはリリース予定のバージョンを直近のゴールと見なして、自然に頑張るようになった。

そして、リリース後にKPTによるふりかえりMTを開いて、リリースしたバージョンについて、KPTの観点でヒアリングして議論したら、自然にプロセス改善になっていた。
僕は、チケットの運用ルール改善や作業の品質改善を狙っていたのだが、メンバーからは、設計書のこういう部分が分かりにくいからバグが出た、このワークフローはやりにくい、チケットでタスクの見通しがよくなった、など、色んな意見が出て、紛糾した。
そして、次のバージョンへの対策も決まり、ちょっとずつ、開発チームの作業効率も上がった。

SW開発で最も嫌なのは、ゴールが見えず、残業や休日出勤が延々と続く状況。
いわゆるデスマーチ。
リリース前のシステムテスト、リリース直後の膨大な問合せや障害報告で起きる。
特に、ウォーターフォール開発で、ドカンと一発リリースした直後が大変。
ウォーターフォール開発では、イテレーションと言うリズムが無いのが一番嫌だ。

【2】アジャイル開発では、スコープをコントロールしながら、小刻みに機能拡張しながらリリースしていく。
だから、リリース後の障害報告や問合せもそれほど多くないし、開発チームがコントロールできる範囲内に抑えられる。
何よりも、スコープをイテレーションに閉じ込めて、イテレーションというリズムが生まれるのが気持ちいい。
XPやScrumならば、必ず２～４週間後にリリースというゴールがあるので、作業が見えやすい。

チケット駆動開発では、ロードマップ画面でリリース計画やチケットの取捨選択を行う。
つまり、ロードマップ画面で、スコープを制御しながら計画ゲームを行っている感覚だ。

イテレーションは通常２～４週間という小さいタイムボックスのため、納期やコストが固定だから機能というスコープで調整するしかない。
つまり、リリース計画を立てて、複数のバージョンを随時リリースしながら機能拡張するという小規模リリースを自然に行っていた。

小規模リリースという繰り返し型開発に気付いた瞬間が、これがアジャイルだ！と思った2番目の瞬間。

このロードマップは、チケット駆動開発で最も重要な機能だと思う。
ロードマップは、平鍋さんが提唱するプロジェクトファシリテーションの「見える化」の例で出てくる野球のスコアボードと同じだ。
ロードマップには、「最新の正しい情報」がバージョンの進捗率とチケット一覧が表示されていいる。
Webなので、「メンバーも現場リーダーも(できれば顧客も)」ロードマップを見れる環境にある。
そして、ロードマップにあるバージョンの予定や進捗から、直近のゴールはこれだ、と「次の行動」が誘発される。

チケット駆動開発はプロジェクトファシリテーションともすごく相性がいいと思う。

【3】Redmineは1プロジェクト＝1リポジトリという設計思想で、Subversionと連携できる。
更に、Redmineには複数プロジェクト機能がある。
だから、ブランチを別プロジェクトで管理してみたら、自然に並行開発になっているのに気付いた瞬間が、これがアジャイルだ！と思った3番目の瞬間。

Subversionをまともに使いこなすまで、ずっとtrunk1本だけのコードラインだったから、並行開発を意識する事はなかった。
しかし、小規模リリースしていくと、本番環境のソースはブランチ、裏で機能拡張中のソースはtrunkというソース管理に自然になる。
すると、マージ作業という面倒な作業が発生するので、Redmine導入前はSVNのタグを乱発してコントロールしにくかった。

Redmineでは、本番運用と開発中のチケットは別々に作り、マージ作業のチケットは発生源の障害修正のチケットとリンクすることで、開発者はすごく作業しやすくなったみたい。
管理者としても、マージ作業のタイミングを忘れる事がなくなったので、ありがたい。

上記の経験を通じて、繰り返し開発が難しい理由は並行開発という開発プロセスが隠れているからだ、と思うようになった。
一度リリースしたソースはそれで終わりではなく、ブランチとして次のリリースまで生き続ける。
開発チームは、次の開発をやりながら、本番運用のソースも保守しなくてはならない。
そして、裏で開発中のソースをリリースしたら、本番運用のブランチを新たに作り、以前のブランチを廃止するという運用サイクルが生まれる。

つまり、小規模リリースというプラクティスは、単なる小刻みな機能拡張による繰り返し開発だけでなく、複数のコードラインを常時保守する並行開発という開発プロセスが本質なのだ。

アジャイル開発が難しい理由は、この並行開発を制御できない点にあると思う。
ウォーターフォール開発であろうとも、組込み製品やパッケージ製品の開発では、複数の製品ラインを保守しながら本番運用と開発中の2系統のソース管理をしているのだから、もっと大変なはずだ。

逆に言うと、並行開発を意識している開発プロセス、開発チームは、自然にアジャイルな開発を行っているだろうと推測している。

TiDDを実践して気付いたことpart1～解ける問題であれば人は自然に解決する方向へ動き出す

PFP関西ワークショップ＃20で平鍋さんのPFの話を聞いた。
もう何度も同じスライドで同じ内容を聞いているのに、いつも新鮮な感覚がある。

プロジェクトファシリテーションの話を聞きながら、チケット駆動開発(TiDD)でどうやって実現できるか、妄想をめぐらせてみた。

【元ネタ】
【Facilitation】解けない問題を解ける問題へ変換する: プログラマの思索

「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」の本で「解けない問題を解ける問題へ変換する」という挿話がある。
この挿話では、解けない問題を解ける問題へ変換すると、人は自然に解決する方向へ動き出す、という教訓を提示している。

この教訓は、実際の開発現場でとても実感する現象だと思う。

SW開発では頻繁にデスマーチ・プロジェクトが起きる。
デスマーチ・プロジェクトでは、いくら目先の問題を解決しても、問題がとにかく多すぎて、現状がなかなか変わらない。
すると、メンバーもチームも無気力になり、一つの歯車で働いている感覚に陥る。
解けない問題はチームを無気力にするのだ。

過去、SW開発の諸問題を解決するために、色んな開発プロセスやプロセス改善の手法が提唱されてきた。
CMMI、PMBOK、RUP、Agileなど。
それらを勉強すると確かに概念は整理されるけれども、いずれも実践しにくい。

CMMIやRUPは、その膨大な量で圧倒されてしまう。
いくら勉強しても、あまりにも大きすぎて、開発現場へ応用しようとすると、畳の上の水泳練習みたいで、カスタマイズが難しい。
CMMIやRUPは勉強になるけど、運用するにはたくさんのノウハウを必要とする。

Agileも実践的プラクティスが多いけれど、良い方法と分かっていても、手が出せない部分が多い。
Agile開発の根本的な特徴は、頻繁なリリースを支える技術やプロジェクト管理手法が前提であるため、運用するには高度な作業やマネジメントが要求される。
手作業では到底無理であり、専用のツールは高価だったりする。

しかし、この数年で状況が少しずつ変わってきたように思う。
RedmineやTracなどのプロジェクト管理機能を持つBTS、SubversionやGit、Mercurialなど高機能なSCMのおかげで、タスク管理やソース管理をツールで補完できる範囲が広がってきた。

チケット駆動開発はTracのチケット管理から生まれたけれど、Redmineでチケット駆動開発を実践して初めてAgile開発をスムーズに運用できた経験をした。
すると、実際の現場の雰囲気も変わってきた。
つまり、ツールを使ってAgile開発について書かれた本の内容を運用できると、イテレーションを繰り返す度にチームは自然に改善されていった。

そして、Agile開発について書かれた本の内容を実践できただけでなく、それらの本に書かれていない新しい概念が出てきたように感じた。
その新しい概念は、当初はチーム特有のノウハウに過ぎないけれど、イテレーションを繰り返す度にノウハウが積み重なって、一つのプラクティスになる。

そのサイクルは、ツールを導入するとチームやメンバーの行動が変わり、行動が変われば考え方も変わっていく流れと同じ。
つまり、ツールが考え方を変えて、道具が新しい手法を生み出すサイクル。

ソフトウェアはとても柔軟で、しかもすごく威力がある。
それはビジネスだけでなく、SW開発自身についても同様だ。

ソフトウェア(ツール)で、SW開発の諸問題を解けない問題から解ける問題へ変換すると、チームもメンバーも自然に解決する方向へ動き出す。

SW開発の現状は、各種の概念や技法は出し尽くされた感があり、それをいかにツールで実現して、現場で運用できるようにするか、という問題へ変わりつつある気がする。

チケット駆動開発もその流れにあると思う。
実際、チケット駆動開発はBTSという従来のツールを使っているし、タスクをカードで管理する発想もXP等で既に提唱されているからだ。
しかし、チケット駆動開発というアイデアによって、アジャイル開発のインフラが整ってきたという現状がある。

今後、チケット駆動開発を実践して気付いたこと、考えたことを色々書いていく。

ビジネスもSW開発プロセスも鈍重になっていく

最近のビジネス、SW開発プロセスで思うこと。
以前に比べて、どんどん鈍重になっている。

10年位前のSW開発の場合、「納期までに要求を満たすシステムを納品する」のが条件だった。
しかし、最近は更に、「納期までに要求を満たすシステムを納品し、開発プロセスが正しくマネジメントされている」ことを求められるようになった。
だから無駄なドキュメントが増えて、無駄なドキュメントを作る工数も増えてしまい、アジャイル開発しているのにその正当性を説明するのに手間がかかるようになった。

それはビジネスでも同じ。
最近よく言われるのは、コンプライアンス(法令順守)やJ-SOX対応。
確かにコンプライアンスは大事だけれども、本来の業務以外の間接業務の負荷が大きくなり、無駄なコストが増えている。
会社にシステムを導入する場合も、本来の業務を支援するシステムだけでなく、社員の労働状況やコンプライアンス状況を管理するためのシステム導入が増えている。

大前研一や木村剛は、このような最近のビジネス状況を官製不況と呼んでいたように思う。
こういう状況で最も得をする人たちは、取り締まる役割のお役所、総務人事部、あるいはSEPGやPMOなのかもしれない。

最近の企業を取り巻く情勢は、ビジネスのスピードを落とす方向に力を入れている。
SW開発も同様に、開発プロセスの正当性を説明するために、スピードを落とす方向に力を入れている。
正直、アジャイル開発への逆風が強まっている時期なのかもしれない。