概要

良いアジャイルチームに関する方法論、考え方がよくまとまっていると感じた。

昨今の開発現場ではDevOpsやアジャイルの議論は避けて通れない。
チームの技術的リーダーを自任する方は、ぜひ実際に読むことをお勧めしたい。

この中からいくつか、個人的に覚えておきたいと思った箇所を紹介する。

第３章：複雑さと不確実さという課題に対処する

複雑系や一般システム論の視点から、ソフトウェアおよびその開発の複雑さを説明している。
複雑さに対する基本的理解がなければ、なぜアジャイルでなければならないかを理解することは難しいだろうと思っている。

もしこの章に興味があれば、複雑系に関する本を読んで欲しい。

チームの自律性を育てるために、ブラックボックス化することについて説明している。
ブラックボックス化とは、チームの外部からマイクロマネジメントしないということ。

マイクロマネジメント
あれやれ、これやれ、こうやれ、と細かく指図すること。

アジャイルは、メンバー一人一人の成長と、自律性を重視している。
マイクロマネジメントは自分で考えて行動すること（自律性）を阻害する。
マネージャーは、メンバーの目的意識と自主性を育てるために細かく指示しないという事が、これまでの管理至上主義なプロジェクトマネジメントの考え方と異なると思っている。

システムの大構造と人間組織の構造は一致すべきという事。
システムをDesign by Contract（責任による設計）によって設計するとすると、そのモジュールの責任は一つのチームに割り当てられているべき。

チームの中で何か問題が発覚したとき、人を問題の根源と考えるのではなく、システム（仕組み）を問題の根源と考える。
限界はあると思うが、仕組みを変えることによって行動の変革を促すことが「自律性を尊重する」という事だと思う。

これがなかなか実際は難しい。プロジェクトはすぐ大きくなりがちだし、スプリントもすぐ長くなりがち。それを小さく保つには、常に意識する必要がある。

そうしないと加速度的にチームがカオスになるというのはとても感じる。
チームレベルでも個人レベルでも、常に心の中に置いておくべき価値観だと思う。

個人：Pull Requestはなるべく小さく保ち、短い時間でcloseする。

この章はとても面白かった。大規模なプロジェクトはウォーターフォールでやるしかないのではないか、というのがこれまで一般的に語られてきた文脈だと思う。ここでは大規模プロジェクトでアジャイルをするための考え方がまとめられている。
是非読んで欲しい。

基本的には、大規模プロジェクトは複数の小さなプロジェクトに分割する。

いわゆるマイクロサービスアーキテクチャの話。
一般的な議論だがとても重要。

この言葉を初めて知った。複数のスクラムチームにより、大きなスクラムチームを構成する事。
スクラムチームにおけるメンバーが人間からチームに変わっただけとも言える。そしてSoSにおける考え方はスクラムチームと同じ。

スクラムチーム 1---* メンバー
スクラムチーム 1---1 スクラムマスター
SoS 1---* スクラムチーム
SoS 1---1 SoSマスター

プロダクトオーナーは全てのスクラムチームに配置すべきだろうか？SoSに一人だろうか？
全体に一人でいいように思うが・・・そこは分からなかった。

完成の定義。何をもってタスクの完了とみなすか、文書化しろと。
レビューポイント、レビューの方法の定義などなど、あいまいだとタスクがいつ終わったのか分からなりがち。

DevOpsによく出てくるテーマだ。

計測の重要性は常に意識すべきだと思う。
ただし、計測しすぎないことも重要。過学習になる。

問題が発生したら、想像で修正に動くのではなく、ログを調べて原因を突き止めてから動くよう心がけよう。性能上問題が発覚した場合、いきなりコードを修正するのではなく、どこがボトルネックか計測してから修正しよう。

個人的には、大規模プロジェクトでもアジャイルできる希望を持った。
この内容が「当然だよね」と言える開発チームが日本国内に増える事を願っている。

日本でなぜアジャイルがうまくいかないのか？とても考えさせられる。
上に書いてあるような事を実際に実行しようとしたとき、おそらく多くの反発があるに違いない。

多くの開発現場で、ここに書かれているような罠に陥っているだろうという事は想像に難くない。