工程単位のBTSプロジェクトやBTSバージョンが何故よくないのか、再考してみた。
ラフなメモ書き。
【元ネタ】
TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索
バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索
Agile開発の肝はイテレーションにあり: プログラマの思索
頻繁なVerUpがソフトウェア開発の本質: プログラマの思索
【1】WF型開発に染まっているPMやPGは、どうしても工程単位にBTSプロジェクトを作ったり、BTSバージョンにアサインしたりする。
自分たちの開発スタイルが、滝の流れのように成果物を下流工程の人へ渡して、最終成果物を作っていくからだ。
例えば、設計プロジェクト、結合テストプロジェクト、本番障害プロジェクト。
機能Aの設計バージョン、機能Aの開発バージョン、結合テストのバージョン、のように。
チケット駆動開発はそもそも、プロジェクト管理機能を持つBTSをタスク管理に使う発想だから、WF型開発でそのように使うことも可能。
だが、その運用方法では、チケット駆動開発の特徴を生かしきれていないと思う。
【2】工程単位にBTSプロジェクトやBTSバージョンを作って一番困る状況は、問合せや改善要望、リファクタリングなどのチケットはRedmineのどこに配置すべきか？が分からないこと。
プロジェクトの前半では、確かに工程単位に設計書を作り、プログラムを作り、単体テストをしていく。
その頃までは順調に進むだろう。
しかし、結合テストやシステムテストの工程に入ると、実際にシステムを動かしてみて、今までの潜在リスクが初めて現れる。
バグの原因は単体テスト漏れだけでなく、要望は判明していたにも関わらず設計そのものが漏れていたり、顧客の要望を間違えて設計していたりする時があるだろう。
設計漏れならば、設計書を最初から作り直し、ソースも修正してテストしなければならない。
それぞれの作業はSE・PG・テスターと役割が異なるから、それぞれのチケットを起票した場合、それらは結合テストやシステムテストのBTSプロジェクトやBTSバージョンにアサインされるべきだが、本来どの工程で直すべきなのか、が分かりにくい。
結局、設計書作りもソース修正もバグ検証も、同一のBTSプロジェクトやBTSバージョンで管理しないと、連携作業が悪くなるからだ。
あるいは、実際にリリース後、顧客から改善要望や問合せが来た場合、本番障害プロジェクトにチケットを起票すべきかどうか迷う。
何故なら、本番障害プロジェクトは、顧客から指摘された障害のみを登録する運用ルールの場合が多く、それ以外が発生原因のチケットが混ざると、PMが集計して進捗報告する時に困るからだ。
その運用ルールを外した場合、本番障害プロジェクトには、実際に顧客の業務に支障が出る本番障害だけでなく、顧客の改善要望や、システム修正と無関係な問合せのチケットが混じってしまうから、もはやぐちゃぐちゃのプロジェクトになる。
しかも、それまでに使った設計プロジェクトや結合テストプロジェクトはもはや使われなくなる運用にすべきかどうか、判断に迷う時もある。
仕様変更が来た場合、最初から設計書のどの部分を修正するか検討して、ソースも修正して、テストもしていくとなると、どのBTSプロジェクトに入れたら良いか分からない。
結局、工程単位にBTSプロジェクトを作ったとしても、プロジェクトの後半では、どのBTSプロジェクトも何でもありのチケットが混じってしまって、ぐちゃぐちゃの状態にならざるを得ないだろう。
工程単位にBTSバージョンを扱った場合も、設計バージョンのタスクは全てのチケットが１００％完了になるのは、プロジェクト終了ぎりぎりか、そもそも１００％でCloseすらされないだろう。
何故なら、設計バージョンに含まれる設計書は実際は、顧客の要望吸い上げの作業が遅延して間延びしたり、顧客の都合でリリースが延期されてバックログ扱いになったりして、保留の設計チケットが残るはずだからだ。
結局、工程単位にBTSバージョンを作ったとしても、いつまで経っても完了しないBTSバージョンが残ってしまって、じきに放置されて、作業漏れの原因になりやすい。
【3】チケット駆動開発の基本的な運用ルールは下記4個あると言える。
3-1・BTSチケットをXPのタスクカードのように扱う
3-2・PFのかんばんをBTSチケット集計結果で表現する
3-3・BTSバージョンをビルドモジュールのリリース予定バージョンと対応付ける
3-4・BTSプロジェクトをSCMリポジトリ(リリースするビルドモジュール)単位に対応付ける
【3-1】１番目は、チケット駆動開発をAgile化するための基本的な運用ルール。
チケットは作業指示書であり、仕様書そのものではない。
チケットをタスクカードのように扱うことで、開発チーム内部の作業を全て見える化できる。
ここから、プロジェクト内部の作業はチケットに起票してから始めるというチケットファーストの運用ルールが派生する。
また、チケットは作業指示書であるからには、その作業結果である成果物が必ずアウトプットとして要求される。
だから、チケットと成果物を紐づける運用ルールとして、「No Ticket, No Commit!」が派生される。
そして、この運用ルールは、ビルドモジュールからソースのSCMリビジョン、チケットに書かれた修正理由まで追跡できるインフラが整う。
すなわち、従来のAgile開発にはなかった特徴であるトレーサビリティが自然に現れる。
【3-2】２番目は、PFのかんばん、XPのタスクボードは、チケットの状態をグルーピングしたクエリで表現できることを意味している。
PFのかんばんは所詮、イテレーションに含まれるチケットに対し、未着手(ToDo)・作業中(Doing)・完了(Done)というチケットの状態でGroup Byしただけに過ぎない。
BTSの優れたチケット集計機能を使えば、かんばんやバーンダウンチャートだけでなく、ガントチャートやカレンダー、予定・実績の工数比較、バグ収束曲線など、いろんな観点で進捗や品質のメトリクスをいくらでも簡単に出力できる。
これによって、現場リーダーの意思決定を支援するインフラが整う。
【3-3】３番目は、XPの小規模リリースを実現するための最も重要な運用ルール。
Agile開発の最大の特徴は、短期間に動くモジュールを作りながら、頻繁にリリースすることによって、品質も機能も改善していくことだ。
WF型開発では、リリースのタイミングはプロジェクトの一番最後であり、リリース予定バージョンはただ一つしか無い。
だから、イテレーションが存在しない。
従って、開発者にとってAgile開発の最大の利点である開発のリズムが生まれず、延々と残業が続き、最後の一発の本番リリース前後では、休日出勤はおろか徹夜作業も強いられる時もあるだろう。
BTSバージョンがリリース予定バージョンと紐づく利点は、二つある。
一つは、SCM連携によるトレーサビリティのおかげで、ビルドモジュールのバージョンに含まれる全てのソース修正理由を追跡できることだ。
実際のソフトウェア開発では、モジュールをリリースする場合、障害修正だけでなく、顧客の要望を受けてユーザインターフェイスを改良したりエラーメッセージを直したり、障害とは言えない仕様変更も含んでリリースするのが普通だ。
だから、デグレードを起こさないために、どのソース修正がどのバージョンに含まれるのか、を追跡できるインフラがあるのは心理的に非常に心強い。
もう一つは、BTSバージョンの集合はリリース予定(リリース済)バージョンの集合でもあるから、Redmineのロードマップがリリース計画そのものになって、変更管理のインフラが整うことだ。
たとえWF型開発であろうとも、ハードやOSのバージョンアップやセキュリティパッチなどの要件で、ソフトウェア開発は頻繁なバージョンアップが宿命だから、変更管理プロセスがしっかりしていないと、すぐにシステムは不安定になる。
たったソース１行の修正やミドルウェアのVerUpでシステムはすぐに動かなくなるからだ。
だから、いつどんな機能追加や障害修正をリリースすべきか、というリリース計画を作ることが重要。
そうでなければ、マネジメントが機能していない開発チームであり、行きあたりばったりのシステム開発になってしまうだろう。
そのリリース計画は過去のリリース履歴も含んだ、将来のリリース計画でもある。
すなわち、将来のリリース予定バージョンの集合はRedmineのロードマップ、過去のリリース済みバージョンの集合はRedmineの変更履歴(リリース履歴・ChangeLog)に相当する。
PMはロードマップを見ながら、顧客の要望の重要度と開発チームの作業の優先度を天秤にかけながら、チームの直近のゴールとその先のゴールを明確にすべきなのだ。
駄目なPMはチームのゴール(リリース予定バージョン)を提示できないから、メンバーも今何を作業すればよいのか分からなくなる。
そして、BTSバージョンに含まれるチケットは、作業の種類をワークフローの単位でチケットに起票して管理すればよい。
PMは、リリース対象の機能追加や障害修正はどんなワークフローで制御すべきか、判断して、担当者にアサインする。
Redmineならば、トラッカーでワークフローを制御できる。
上記の例のように、システム開発の作業中に突然発生した仕様変更や顧客の要望、問合せは、それぞれのワークフローに対応するチケットで起票すればいい。
そして、どのタイミングでリリースすべきか、という問題は、どのBTSバージョンにチケットを設定すべきか、という問題へすり替えればいいだけなのだ。
もし、顧客の要望がかなり先のリリース物件ならば、バックログのようなBTSバージョンに一旦入れておけばいい。
BTSのチケットは元々突発的な障害を管理するために作られたから、作業予定日やステータス、実績工数、リリース予定バージョンなどの属性を変更するのは非常に容易だ。
だから、Agile開発のように変化が激しいソフトウェア開発に非常に適していると言える。
上記の理由から、XPの小規模リリースという運用ルールは、チケット駆動開発では、トレーサビリティやリリース計画、ワークフロー管理に密接に絡んでいることが分かる。
【3-4】４番目は、BTSプロジェクトを作る観点は、SCMリポジトリ、つまりビルドモジュールの単位であるべきということ。
Redmineは元々、BTSプロジェクトとSCMリポジトリが１対１に対応すべきという設計思想で作られている。
その意味は、BTSプロジェクトは動くモジュール単位で作るべきということだ。
何故、工程単位のBTSプロジェクトが良くないのかという理由は、例えば、設計プロジェクトでは、設計だけではリリースできるモジュールが出来上がらないからだ。
設計書だけできても、動くプログラムはないわけだから、顧客に価値あるソフトウェアを届けると言うAgile開発の精神とは全く異なる。
BTSプロジェクトがSCMリポジトリに紐づく利点は二つある。
一つは、並行開発のタスク管理が可能なインフラが整うこと。
Agile開発を実践してみると、頻繁にリリースするが故に、本番運用中のリリースブランチと裏で新規開発中のtrunkの２本のコードラインを持つ必ず並行開発になる。
一度リリースしたコードラインは、それで終わりではなく、顧客が業務で使ってみて、障害が発覚したり、UIを改善して欲しいなどの要望が届く。
しかし、開発チームは次のリリースに向けて新規開発中なので、突発的に発生する本番運用中の障害修正や機能改善の作業も必ず強いられる。
並行開発のタスク管理はとても難しいけれども、チケット駆動開発ではブランチ(コードライン)単位にBTSプロジェクトを作る運用なので、どのソースをどのチケットで修正すべきかが明確になり、作業が混乱しない。
そして、メインラインモデルのような構成管理パターンも併用すれば、品質重視のリリースブランチと機能拡張重視のtrunkを使い分けることができるので、ソースのデグレードも起きにくくなる。
もう一つは、Agile開発のスケールアップが運用しやすくなること。
大規模プロジェクトになると複数チームのタスク管理をBTSでやりたくなるが、WF型開発しか知らないPMならば、その時に工程単位にBTSプロジェクトを作ってしまいがちだ。
すると、複数チームの設計タスクが設計プロジェクトに混じってしまい、各チームがリリースするコンポーネントがぐちゃぐちゃに混じってしまう。
BTSプロジェクトが動くビルドモジュール(コンポーネント)に対応する運用ルールを課すならば、各チーム単位のBTSプロジェクトを作り、各チームのコンポーネントのSCMリポジトリと対応させるべきだ。
そして、各チームのBTSプロジェクトで、設計から開発、テスト、リリースまでのタスク管理を行えばよく、BTSバージョンはそのチームのリリース計画に基づいたリリース予定バージョンに対応させることができる。
そうすれば、各コンポーネント単位で小規模リリースを実現できるようになるから、自然にAgileになる。
Agile開発のスケールアップを更に徹底させるならば、複数チーム間で発生する課題の棚卸しはスクラムオブスクラムで行い、複数チーム間のイテレーションを同期させるためにアジャイルリリーストレインを課せばよいだろう。
アジャイル開発のスケールアップはアジャイルリリーストレインが鍵を握る: プログラマの思索
スクラムオブスクラム: プログラマの思索
現代のAgile開発が抱える課題: プログラマの思索
段階リリースとアジャイルリリーストレイン: プログラマの思索
すなわち、各チームのタスク管理だけでは解決できない課題は、チームリーダーの一つ上の階層であるスクラムオブスクラムで合議制によって意思決定を下す運用にする。
そして、他チームのコンポーネントが自チームの開発に必要ならば、各チームのイテレーションを同期させることアジャイルリリーストレインの運用ルールを行えばよい。
そうすれば、大規模プロジェクトのタスク管理は各チームのリリース計画(ロードマップ)の集合になるから、各チームがリリースするコンポーネントの整合性に注力しながら、全体のリリース計画を調整すればいい。
各チームリーダーが集まって意思決定を行うスクラムオブスクラムは、プロジェクトのリリース計画を決める重要な場でもある。
つまり、PMBOKのCCB、ITILのCABのような変更管理会議の役割であるべきだ。
上記の理由から、BTSプロジェクトとSCMリポジトリが１対１に対応する特徴は、メインラインモデルによる並行開発やAgile開発のスケールアップに密接に絡んでいることが分かる。
【5】上記のことを考えていると、実際のソフトウェア開発の特徴がおぼろげながら見えてくる。
実際のソフトウェア開発はもっと泥臭くて、とても繊細だ。
工程単位に穴のないような品質を作りこんで作業していくWF型開発は、あまりにも理想的で、綺麗過ぎる。
現場のソフトウェア開発は、突発的な仕様変更や障害修正、設計漏れによる手戻り作業がとても多い。
そして、リリースしたシステムは納品して終わりではなく、OSのセキュリティパッチ、顧客の要望による機能改善など、頻繁にVerUpしていかざるを得ない。
かと言って安易なVerUpはデグレードを発生させて、システムを不安定にさせてしまう。
それらの作業をこなしながら、並行して現状の作業を行わなければならない。
だからこそ、イテレーション単位に、どのタスクをいつリリースするのか、という観点でまとめて、小刻みにリリースしながら品質も機能も拡張していくAgile開発が有効であると思われるのだろう。
チケット駆動開発には、WF型開発の弱点を補うだけでなく、Agile開発を強化してくれるヒントが隠されているように思う。
」や「
」が紹介されているのには驚いた。
」の本とその勉強会のログも紹介されていたので、調べてみたいと思う。
」は
さんの翻訳本なので興味があります。
」に書かれているショウジョウバエのような実験モデルと同じ。
」を紹介されていたのでメモ。
」の感想を見つけたのでメモ。
」の本に書かれているアパレルメーカーのビジネスの例が書かれている。
」を読んで腑に落ちなかった点が下記のBlogを読んで分かったのでメモ。
」にも書かれているが、業務システムの複雑さそのものは、いくらサーバーの性能がアップしても、プログラミング言語の生産性が上がっても変わらないことを「業務システムの複雑さの保存則」と呼んでいる。
」では、Railsのスケールアップのためにデータモデリングをあらかじめ考慮すべきと主張し、RailsでのDOAの重要性を主張している唯一の本でもある。参考になる。
」では、プログラムのリファクタリングと同様にデータベース設計のリファクタリング方法を説明している唯一の本。とても役立つ。
最近のコメント