アジャイルへと向かう組織:慎重に歩こう
ほとんどの組織は、組織全体のアジャイル・トランスフォーメーションを実行するために、アジャイルコーチを雇う。その目的は、コーチがビルから去るまでに、無駄のない健全な組織にすることだ。しかし、トランスフォーメーションをチームレベルだけで始めると、エンドツーエンドのデリバリー・プロセスを改善して維持するというトランスフォーメーションを実現するのは非常に難しいだろう。
ほとんどの組織は、組織全体のアジャイル・トランスフォーメーションを実行するために、アジャイルコーチを雇う。その目的は、コーチがビルから去るまでに、無駄のない健全な組織にすることだ。しかし、トランスフォーメーションをチームレベルだけで始めると、エンドツーエンドのデリバリー・プロセスを改善して維持するというトランスフォーメーションを実現するのは非常に難しいだろう。
ペアプログラミングはここ数年で一番議論が続けられているプラクティスのひとつだ。ほとんどの支持者はペアプログラミングの利点をほめたたえることを惜しまないが、その人たちでもペアで作業することの導入に苦労があることを認める人は多いだろう。それはなぜか。Obie Fernandez氏はそうなる理由と考えられる10の項目を挙げている。
Allan Kelly sites an article from MIT's Sloan Management Review about why it is important to get a team's technical competence and ability improved before focusing on business-IT alignment. This, he claims, is one of the reasons Agile software development has been so successful. Allan's point indirectly touches on a recent community debate about successful, valuable, Agile adoption.
2ヶ月前、InfoQはJim Shore氏の人気の記事を紹介した。それは、組織が「アジャイル」を名前だけで導入し、実際にアジャイルであるために本当に意味するものの導入に失敗するという、現在増えているコミュニティの傾向を強調するものであった。コミュニティリーダーとその他の人たちは、この状況で何が起きているのか彼らの考えを投稿し、Shore氏の最初の立場から、最近さらに数歩踏み出している。
大企業のソフトウェアアーキテクトが直面する重要課題の多数が、テクノロジーとしての組織と大いに関係がある。Dan Greenblogはこの問いに答えようと、最近のブログで、ソフトウェアアーキテクチャの裏にある原則と効果的な組織構造の間の類似点を指摘している。
組織のITへの投資が(買い取りや借用、構築などにより)増加し続け、ビジネスプロセス管理(BPM)やサービス指向アーキテクチャ(SOA)などのコンセプトがいっそう普及するにつれ、エンタープライズアーキテクチャ(EA)という任務はいっそうありふれたものになった。David Linthicum、Mike Kavis、Alan Inglisの三氏は最近、業界内のEAに関する見解をそれぞれ語った。