プログラマの思索

チケット駆動開発でAgile開発を初めて実践できて、Agile開発の長所や短所が色々分かってきた気がする。
今の時代にAgile開発はとても優れていると思っているが、乗り越えるべき課題はまだまだある。
その課題も、時代の変化によって、より難しいレベルまで要求されているように思う。

2000年代に現れたXPを代表とするAgile開発は、その利点は広く知られてきたが、適用の限界や短所について従来から指摘され続けてきている。
その課題についてまとめてみる。
#考えたことをラフなメモ書き。書きかけもある。

【1】Agile開発はプロジェクト管理が弱い

アジャイル開発でプロジェクト管理、そしてプロセスを管理する部分が弱いという指摘は従来から言われていた。
確かに、PMBOK、CMMIなどの観点から見れば、Agile開発はプログラミング重視で全体的なプロセス設計がなされていないように思える。

だが、Scrumがプロジェクト管理の部分を補強してくれている。
Scrumは一言で言えば、XPの計画ゲームを実現したプロセスフレームワークだ。
基本は、1ヶ月という固定の期間(スプリント)中は要件を固定して、インクリメンタルに開発する。

Scrumで重要な概念は、プロダクトバックログとスプリントバックログだ。
プロダクトバックログは要件の貯蔵庫、スプリントバックログは直近のリリース予定のタスクの貯蔵庫。

顧客からの要望、バグ修正、リファクタリングなどは一度プロダクトバックログに貯められて、どのスプリントで実現するか、長期的に判断して、スプリントにアサインされた時に、スプリントバックログに入れられる。
そして、スプリント中は、スプリントバックログにあるタスクを一つずつ解決していく。
当然、タスクの作業順序は状況によって日々変わるから、デイリースクラムという名の朝会で状況を確認し、各担当者に作業をアサインしていく。
スプリント中の進捗管理は、バーンダウンチャート、かんばん、など各種のプラクティスで補完できる。

プロダクトバックログという概念は、TestLinkのテスト仕様、GTDによるタスク管理にも同様の発想が見受けられる。
又、「決断をできるだけ遅らせる」というリーンソフトウェア開発のプラクティスに似ている。
まずは要望やタスク、テストケースは一旦貯めて、その後に状況に応じて優先順位付けすればいい。
現場リーダーは優先順位付けマシンなのだ。

「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」では、アジャイル開発におけるリリース計画の作り方でヒントになることが沢山書かれている。

ScrumがAgile開発へ補強した概念は、リリース計画だと思う。
長期的なリリース計画と短期的なイテレーション(スプリント)計画の2つの戦略によって、小規模リリースを無理なく実現できるようにしている。

当然、チケット駆動開発もAgile開発のプロジェクト管理を補強してくれる。
チケットをXPのタスクカードのように扱えば、ロードマップが自然にリリース計画となり、日々の進捗は、チケットの自動集計と言う機能に置き換えられる。
Redmineを実際に運用してみれば、Agile開発というプロセスの本質が見えてくると思う。

【2】Agile開発はスケールアップが難しい

XPはその発端からして、小規模なチームで小規模なプロジェクトで実験された経緯がある。
だから、Agile開発は大規模チームや大規模プロジェクトでは運用しにくい、という指摘は従来から言われ続けてきた。

「アジャイル開発のスケールアップ」はソフトウェア工学的にも重要な問題だと思う。
小規模なシステムでは見えないものが、大規模なシステムでは問題として出てくる。
テスト駆動開発で単体テスト済みのモジュールであっても、たくさんのモジュールを結合して非機能要件と言う問題が出てくるように、大規模システムになって初めて出てくる問題もあるのだ。

だが、Scrumは大規模チームや大規模プロジェクトに応用出来る仕掛けがある。
大規模チームへScrumを適用した成功例は「塹壕より Scrum と XP」が初めてではなかろうか？

昨今は「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」のように、アジャイル開発をスケールアップするためのヒントが公開されている。
「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」で最も重要なプラクティスは、アジャイルリリーストレインとスクラムオブスクラムだと思う。

複数のチームが定期的にリリースしていく場合、電車の発着を時刻表に従うように、複数のチームもイテレーションも同期させることがアジャイルリリーストレインだ。
つまり、全チームのイテレーションは必ず同期させる。
このプラクティスがなければ、一番遅れた開発チームに他の開発チームも影響されてしまい、全体の開発速度も下がる。

アジャイルリリーストレインの変形としては、イテレーションの階層化と言う手法もある。
例えば、組込システム開発で、ハードウェアチームの1イテレーションに対し、ソフトウェア開発チームは3つのイテレーションで小刻みに内部リリースしていくという戦略。
つまり、ソフトウェア開発チームは早めに小さなモジュールをリリースして、ハードウェアチームにそのモジュールを渡して試験してもらい、そのフィードバックを受けながら、次イテレーションで改善していく。
この方法を使えば、ハードウェアとソフトウェアの結合テストを事前に少しずつ実施することで、リスクを減らせる。

次に、各チームリーダー(スクラムマスター)が定期的に集まって、プロジェクト全体の進捗や課題、方針を棚卸して決定する場がスクラムオブスクラム。
スクラムオブスクラムがなければ、複数のチームにまたがる課題や依頼事項をプロジェクト全体の視点で制御できなくなる。
このプラクティスは、PMBOKのCCB(変更管理委員会)、ITILのCAB(変更諮問委員会)に相当するだろう。

この2つのプラクティスが最重要と思うのは、複数の開発チームのインターフェイスに関わるプラクティスだからだ。
この2個のプラクティスが、開発チームがお互いに調整する場、お互いに作ったモジュールを渡したり受領して移植する場、そしてリリースを調整する場を提供してくれるからだ。

更に、Redmineによるチケット駆動開発では、アジャイル開発のスケールアップを補強してくれる機能がある。
RedmineのVer1.0の機能にある3つの機能、つまり、プロジェクトの無制限の階層構造、バージョンの継承、チケットの親子関係(サブタスキング)が重要だろうと思う。

プロジェクトの無制限の階層構造を使えば、サブチームのタスク管理を大規模プロジェクトのタスク管理の一部として位置づけることができる。
例えば、第1階層のプロジェクトは、大規模プロジェクト全体のタスク管理として、第2階層以下はサブチームのタスク管理にすればいいだろう。

バージョンの継承機能を使えば、親プロジェクトのバージョンを子プロジェクトのバージョンへ継承できる。
これによって、全体スケジュールのイテレーションに各チームのイテレーションを同期させることができる。
つまり、アジャイルリリーストレインを実現できる重要な機能なのだ。
実際は、例えば、親プロジェクトのイテレーション(バージョン)1個に対し、サブチームのイテレーション(バージョン)を複数個へ階層化する手法を取れば、より柔軟にリリース管理できるだろう。

そして、チケットの親子関係を使って、親チケットをストーリーカード、子チケットをタスクカードに階層化すれば、要件からタスク、ソースまで一貫して追跡できる基盤が整う。
Redmineのサブタスキング機能には、親チケットへ子チケットの情報(開始日・終了日・進捗率)をロールアップしてくるので、とても使い易くなった。

「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」にあるプラクティスをRedmineで実現すれば面白いと思う。

【3】Agile開発はアーキテクチャや品質の作り込みの観点が弱い

RUPなどに比べると、Agile開発はアーキテクチャや品質の作り込みの観点が弱いという指摘も従来から言われ続けてきた。
ケントベックやファウラーは優れたモデラーでもあったから、アジャイル開発で成功できたが、モデリング無しで開発するのは、大規模プロジェクトになるほど難しい。

昨今のモデリング技法はUMLが席巻しているが、UMLは詳細設計とコーディングをシームレスにつなげてくれるが、要件定義やシステム提案の段階から落とし込むのには適していない。
ユースケース記述について、「ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations)」などの本を読んで確かにが参考になったが、顧客と話しながら要件を落としこんでいく時には役立たない。
むしろ、DFDやIDEF0のようなプロセス図の方が顧客にも分かりやすい。

アーキテクチャの設計、要件定義におけるモデリング、品質を考慮したテスト計画は全てトップダウンから計画を作るのが正攻法。
トップダウンで仮説検証。
全体構想を描くために計画が一番重要。
後でアーキテクチャを変えるのは難しい。

アーキテクチャをプロトタイプのように作っては壊して、アイデアを試す方法もある。
だが、プロトタイプを再利用可能な部品やフレームワークまで、設計や品質を高めるのは難しい。
むしろ、RUPの推敲プロセスのように、アーキテクチャを少しずつ反復しながら、機能拡張して品質を高める方が現実的。

モデリング手法にアジャイル開発の影響を受けたものとして、アジャイルモデリングがある。
つまり、アジャイルモデリングは軽量のモデリングスタイル。
「アジャイルモデリング―XPと統一プロセスを補完するプラクティス (OOP Foundationsシリーズ)」が代表作。
でも、何も新しい事は言っていない。
モデリングに対して新しい視点を何ももたらしていない。

「システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践)」の言う通り、アジャイラーとアーキテクトは対立しているのが現状。
アジャイル開発をシステム提案や要件定義に持って行っても、うまくいかない。
アーキテクトがアジャイラーになるしか、アジャイル開発を実践できていないのが現状。

【4】Agile開発は分散開発まで考慮されていない

大規模プロジェクトになるほど、開発チームもメンバーも分散する。
分散の規模も、一つの部屋では無理で、一つのビルで部屋をまたがるだけでも、心理的な距離は長くなる。
オフショア開発になれば尚更だろう。
チームビルディングにフォーカスを当てたプロジェクトファシリテーションは優れたツールだと思うが、分散開発に関してそのノウハウがないのが残念。
その問題意識については、プロジェクトファシリテーションに足りないもの: プログラマの思索に書いた。

Agile開発にはたくさんの希望やアイデアがある。
上記にあげた課題も必ず解決できると確信している。