More Effective Agileは良い本だ
「More Effective Agile ソフトウェアリーダーになるための28の道標」を一気に読んだ。
アジャイル開発の古い情報をアップデートできて良かった。
10年以上前のXPとかにハマっていた人にはお勧めと思う。
ラフなメモ書き。
【参考】
『More Effective Agile』を読んでみた感想 - 虎の穴開発室ブログ
More Effective Agile ソフトウェアリーダーになるための28の道標 読了 - nemorineのブログ
クネビンフレームワークについて講演してきました | サーバントワークス株式会社
半日かけて「More Effective Agile」をじっくり読んだ。
線を引いた箇所はかなり多数。
読むたびにインスピレーションが働いた。
この本のキーワードは「クネビンフレームワーク」「複雑系」「スクラム」「ブラックボックスなスクラムチーム」だ。
クネビンフレームワークでは、ソフトウェア開発は複雑系のドメインなので、従来のシーケンシャル開発では問題解決できない。
なぜなら、煩雑系のドメインの問題解決手法であり、複雑系では対応できない。
クネビンフレームワークでは、煩雑系では「把握→分析→対処」、複雑系は「調査→把握→対処」で問題解決の手法が異なる。
だから、アジャイル開発が必要とされる。
クネビンフレームワークは1990年代には概念があったのに、誰もそれを言ってなかったのが興味深い。
「More Effective Agile」では一貫して、クネビンフレームワークの話が出てくる。
クネビンフレームワークの概念のおかげで、ソフトウェア開発の本質は複雑性であることを常に認識させられるメリットがある。
人月の法則本の「ソフトウェア開発の本質は複雑性だ」を思い出す。
「More Effective Agile」では、アジャイル開発とはスクラムと同義だ。
XPなど他のアジャイル開発も紹介されているが、スクラムの「検査と適応」がOODAループと相性が良いことが強調されている。
僕は、調査→把握→対処という問題解決の手法を何度も高速に回すことと同じであり、その経験によって学習して判断能力を高めていくと理解している。
アジャイル開発では雨後の筍のように数多くのプラクティスが提唱されるが、最終的には、スクラムは複雑系の問題解決にいているから推奨されている。
一方、XPは技術プラクティスが残った。
カンバンは煩雑系の作業に向いていて、複雑系の仕事はスクラムの方が向いている、と言う。
この考え方を取り入れると、ソフトウェア開発だけでなく、企画提案系のプロジェクトの仕事は全てスクラムで実施した方が良いだろうと思う。
つまり、一般のビジネスマンもチームで仕事するのが普通だから、スラクムをマスターした方がいいのではないか。
「More Effective Agile」で良く出る言葉は、「スクラムチームはブラックボックスとして扱える」ことだ。
実際、スクラムチームというアジャイルチームは、自律的なチームであり、スプリント単位にアウトプットを必ず出してくれる。
つまり、外部のプロジェクトマネージャは、スクラムチームのマイクロマネジメントは必要ない。
スクラムチームのインプットとアウトプットさえ管理すればいい。
チームをブラックボックスとして扱うことは、チームを大人として扱うことと同じであり、技術の詳細や進捗を逐一管理すべきでないことを示唆している。
よって、プロジェクトマネージャは、スクラムチームにサーバント・リーダーシップで振る舞うようになる。
「スクラムチームはブラックボックスとして扱える」ことは、コンウェイの法則を良い方向に自然に従うことになる。
つまり、オブジェクト指向プログラミングのように、スクラムチームはコンポーネントと同一視すれば、疎結合なスクラムチームを構成すれば大規模なチームを構成して、大規模なソフトウェアを効率良く作れるようになるはずだ。
スクラムチームはコンポーネントのように疎結合であるならば、メッセージパッシングがスムーズであり、無駄なコミュニケーションがないはず。
でも、スクラムチームをオブジェクト指向設計のコンポーネントと同一視できても、チームである限り状態は持つし、副作用を起こすことで、チームは変化するから、不変なコンポーネントとは違うはず。
この比喩はどこまで使えるのか？
この辺りはまだ分かってない。
「More Effective Agile」では、アジャイル開発をいかに大規模ソフトウェア開発に適用するか、というテーマを後半で詳しく説明してくれている。
意外だったのは、大規模アジャイル開発のフレームワークは、LeSSよりもSAFeの方を推奨していたことだ。
僕の身近のスクラム関係者は、LeSSを高く評価し、SAFeを低く評価していたので、どちらが正しいのか、まだ分かってない。
@sakaba37さんのアドバイスでは、プロセス志向がSAFe。
SAFeでは、アーキテクチャ管理、プロセス管理のレイヤが別にあり、基本テンプレートもある。
RUPに似ている。
一方、情報共有がLess。スクラムチームをベースに細胞のように階層化していくイメージ。
Lessの方が状況共有や暗黙知を重視するから日本人向きで、日本人好みだろうね、と。
すぐに作るために暗黙知を重視しているわけであり、暗黙知はチーム内で認識できていればいい、と。
つまり、スクラムチームがブラックボックスならば、チーム内で問題解決できる専門能力を持つだけでなく、暗黙知もチーム内で共有できているから、スクラムチームは強いわけだ。
アジャイル開発がこれだけソフトウェア開発に浸透して使えるならば、ビジネスの観点で計測したくなる。
実際、スクラムは「検査と適応」のサイクルをこなすことで、スクラムチームは経験を深めて、予測可能な振る舞いを行うようになる。
つまり、スクラムチームは計測可能な状態になる。
たとえば、ベロシティのように。
すると、コストやスケジュールが予測可能になってくるので、ビジネスで計画を立てたり、意思決定するのにその予測を使えるメリットが出てくる。
「More Effective Agile」では、最後に規制産業にアジャイル開発をいかに適用するか、というテーマがある。
たとえば、製薬業や医療業界、航空機メーカー、金融機関、政府など、法律による規制が前提にある産業だ。
では、アジャイルやスクラムは規制産業でどうやって支援するのか？
アジャイルの境界を引いて、文書作りやソフトウェア要求やソフトウェアアーキテクチャ設計はシーケンシャル、実装スプリントはアジャイルと分けることを提案している。
よく見れば、これはウォーター・スクラム・フォールじゃないの、と思ってしまうが、たぶんこれが現実的な解決法なのだろう。
最後に、スクラムの導入と社内展開は、キャズム理論に従うという指摘は参考になる。
実際、社内のイノベーターはすぐに飛びついてくれるし、アーリーアダプターは色んな意見を出してくれる。
その後のアーリーマジョリティへの展開が一番大変なのだ。
「More Effective Agile」はまだまだ読み直してみたい。
最近のコメント