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を使っていれば、おそらくスムーズに運用できるだろう。

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