アーキテクチャ助走路

「アジャイル開発の本質とスケールアップ」で「アーキテクチャ助走路」というプラクティスがあったので考えたことをメモ。
＃ラフなメモ書き。

【1】「システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践)」にもあるように、アジャイラーとアーキテクトの間には緊張関係がある。
小規模リリースとアーキテクチャの作り込みは、多分組み合わせが良くない。

アジャイラーとアーキテクトの緊張関係: プログラマの思索

アジャイル開発とソフトウェアアーキテクチャの緊張関係: プログラマの思索

WF、XP、RUPではアーキテクチャの考え方が違う。
WFでは、アーキテクチャは計画される。
XPでは、アーキテクチャは出現する。
RUPでは、アーキテクチャは成長する。

XPでは、「アジャイル開発の本質とスケールアップ」によると、最初のイテレーションでアーキテクチャスパイクという特別なイテレーションを導入する。
最初のイテレーションで、ベースとなるアーキテクチャを用意して、次イテレーションから少しずつ機能追加しながら、システムを拡張していく戦略をとる。
元々、XPは小規模なソフトウェア開発を対象にしていたので、このやり方でもうまくいったのだと思う。

又、最近は、RailsやSeasarのように優れたフレームワークがあるので、最初からアーキテクチャをスクラッチ開発する必要がない現状も味方していたのだろう。

しかし、大規模プロジェクトになると、たとえOSSのフレームワークがあったとしても、全てのサブシステムを考慮してあらかじめ設計しておく必要がある。
そうしなければ、不安定な基盤の上に家を建てるようなもので、リファクタリングばかりしても、品質もどんどん劣化していくだろう。

RUPはアーキテクチャ重視と名乗るだけあって、反復的にアーキテクチャを作り込むプロセスがある。
特に推敲フェーズでは、アーキテクチャの作り込みがやりやすいように思う。

RedmineやTestLinkなどでチケット駆動開発を実践して経験したことは、アーキテクチャや品質の作り込みを行うイテレーションを別途設けた方がいい、と気づいたことだ。
実際、小規模リリースだけでシステムを実現できるわけではない。
やはり、機能拡張せずに、特定の目的だけのために、イテレーションを使う時もある。
特に、結合テスト、システムテスト、負荷テストなど各種の観点でテストして、システムの品質を向上させていく時はそうだ。

漸進型開発と反復型開発を意図的に切り替える戦略がアジャイル開発にも必要。
その戦略を「アーキテクチャ助走路」という概念が含んでいると思う。

【2】「アジャイル開発の本質とスケールアップ」では、アーキテクチャ助走路とは、最初から数回のイテレーションをアーキテクチャの作り込みに使うこと。
例えば、最初の3回ぐらいまではアーキテクチャチームとプロトタイピングチームが連携して、システムの基板となるアーキテクチャを作りテストする。
そして、4回目以降は、各コンポーネントチームがサブシステムを並行して開発していく。

アーキテクチャ助走路の利点は、大規模システムのアーキテクチャを作るイテレーションを別途設けていること。
この方法によって、後のイテレーションで各コンポーネントチームは小規模リリースに専念できる。
アーキテクチャが後で大きく変化することがないように、あらかじめ準備しておくからだ。
つまり、アーキテクチャ助走路によって、大規模なリファクタリングなしに、後から機能を追加できるインフラを用意しておくのだ。

「アジャイル開発の本質とスケールアップ」では、アーキテクチャ助走路によって「意図的にアーキテクチャを作り出す」と言っている。
つまり、XPのような初期のアジャイル開発で課題となっていた「アーキテクチャを重視してない」件は、少なくともクリアされているように見える。

しかし、実際の開発では、後になってアーキテクチャを大きくリファクタリングせざるを得ない場合もある。
「アジャイル開発の本質とスケールアップ」では、アーキテクチャ助走路の延長と呼んで、3つの方法が書かれている。

一つ目は、プロダクトバックログにアーキテクチャのリファクタリング作業を入れること。
つまり、アーキテクチャの変更作業も、1個のタスクに落としこむことを意味している。
実際、ちょっとしたAPIの変更で解決できるレベルならば、他のユーザストーリーと並べて、バックログの観点から優先順位をつければいい。
普通はリファクタリング作業は開発速度(Velocity)を落とすから、ユーザストーリーの実現に必要な場合に一緒に作業する時が多いだろう。

二つ目は、一つのチームが1イテレーションでデザインスパイクを担当すること。
「アジャイル開発の本質とスケールアップ」によると、デザインスパイクとは、設計に関する問題、アーキテクチャの拡張、新技術のインパクトを解決する、あるいは、現在のアーキテクチャが持つ重大な問題を調査するための活動を意味している。
つまり、デザインスパイクとは、アーキテクチャの改善や拡張のための1イテレーションの作業を意味している。

実際の大規模開発では、アプリ共通チームやインフラチームのように、全開発チームのインフラを保守するチームが、定期的にデザインスパイクを実施する時が多いだろう。
そうでなければ、開発チームは自らアーキテクチャをいじって、更に自分たちのユーザストーリーを開発していかなくてはいけないので、アーキテクチャが劣化するリスクがあるし、開発チームの負荷も高くなるからだ。

三つ目は、全てのチームが1イテレーションでデザイン反復に従事すること。
つまり、全ての開発チームが新規開発を中断して、アーキテクチャの拡張とその影響範囲の修正に従事すること。

実際の大規模開発では、アーキテクチャの修正が全チームに大きく影響を与える場合もある。
そんな時に、アーキテクチャチームだけでなく、全チームがアーキテクチャの修正の影響を考慮して、修正に従事するイテレーションを別途設ける。
デザイン反復の利点は、全てのチームがアーキテクチャに目を向けるため、技術的決断をチーム自身が行うというアジャイル精神に合致すること。
逆に欠点は、デザイン反復は顧客価値をほとんど提供しないので、全体の開発速度が停滞してしまうことだ。何故なら、リファクタリング作業やアーキテクチャの作り込みのため、ユーザストーリーの実現を一つも行わないからだ。

上記3点の解決方法を考慮すれば、アーキテクチャ助走路を有効活用できるだろう。

「アジャイル開発の本質とスケールアップ」を読み込んでいくと、大規模アジャイル開発に必要なプラクティスがよく練られているなあ、という感想を持っている。
初期のアジャイル開発でよく言われた課題を解決するプラクティスをうまくまとめてくれている。

そして、「アジャイル開発の本質とスケールアップ」が上手だと思う点は、プラクティスのネーミングが上手なこと。
アジャイルリリーストレイン、スクラムオブスクラム、アーキテクチャ助走路などのように、プラクティスの名前を連呼するだけで、背景にある解決方法や問題意識も共有できる。

Agile2.0や大規模アジャイル開発を実践するうえで、「アジャイル開発の本質とスケールアップ」はもっと読まれていいと思う。