BABOKはアジャイル開発に使えるか

BABOKとアジャイル開発に関する記事があったのでメモ。

【元ネタ】
BABOKはアジャイル開発に使えるか - 記者の眼：ITpro

Agile BABOK Extensionというドキュメントが届いた - たこはちの「へのかっぱ」日記

BABOKは、要件定義以前のシステム化計画で使う知識体系と認識している。
だから、要件定義やビジネス分析もBOABOKでは一つの知識エリアに過ぎない。

PMBOKがプロジェクトマネジメントの知識体系として優れているように、BOBOKも業務分析、システム化立案の知識体系として今後普及する可能性はある。
ERP導入によるBPR、SCMの改善、CRMの運用などでBABOKを使えるだろうと思う。
丁度、萩本さんが提唱されている要求開発も、BOBOKが目指す所と同じように見える。

僕も実際の開発で、システム化立案や要件定義では、アジャイル開発がうまく使えない経験をしていて、色々試行錯誤している。
BABOKのような発想もいるのかもしれない。

アジャイル開発と要件管理: プログラマの思索

課題管理のチケット駆動開発: プログラマの思索

上記の記事で面白いと思ったのは、BOBOKの課題として「基本的な考え方がウォーターフォール型になっていること」と識者が認識していること。
つまり、RUPが反復型開発でアーキテクチャで作り込むように、BABOKもシステム化立案や業務分析を反復型で分析したいのだろう。
その時の問題は、イテレーションで反復している間、スコープをどのように決めて、誰がどんな役割でアウトプットを出していくのか、をはっきりさせることにあるだろう。
単なる反復では、手戻りが多すぎて、成果物の品質が悪くなることは初期のAgile開発の頃から言われていた指摘だからだ。

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

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

現代のAgile開発が抱える課題: プログラマの思索

多分、「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」にあるアーキテクチャ助走路という概念が、反復に対するひとつの示唆を与えているだろうと直感している。