締め切りに追い立てながら積読書を解消するデッドライン読書会。第18回から新しい本になりましての、今回第19回です。デッドライン読書会ってなに？は下記の投稿をご参照ください。
課題図書
前回に引き続き課題図書は、モダン・ソフトウェアエンジニアリングです。
後半戦の今回は、第Ⅲ部「プラクティスを使った小規模開発」、第Ⅳ部「大規模で複雑な開発」を含めた最後までが範囲でした。
感想文
全体の感想文と、個別のコメントを書きます～。今回は読むのが辛く、なかなか指が進まなかったです^^;（そういうテンションの時もあります。）
全体
第Ⅲ部では、Essenceを実存するプラクティスに当てはまめて有用であるかの検証しています。対象としているプラクティスは、
- スクラムライト
- ユーザーストーリーライト
- ユースケースライト
- マイクロサービスライト
の４つです。「ライト」とついているのは、本書独自に加工して、書籍の解説用に実際のプラクティスをシンプル化したためのようです。４種類も説明しなくても良いから、「ライト」ではないものをちゃんと説明してくれたらよいのに…とちょっと思いました。本書内ではストーリー調で主人公が四苦八苦しながらこれら４つのプラクティスをEssenceとともに実践していきます。
第Ⅳ部では、大規模開発にEssenceを適用する場合の解説です。第Ⅲ部までは、１チーム・１プロダクトにターゲットを合わせていましたが、第Ⅳ部では、複数チーム・複数プロダクトの場合どのようにEssenceを活用するかを検討します。大規模開発が原因で複雑化する問題のうちコラボレーションにフォーカスしています。チームが複数になると、チームごとにおかれた状況により多様な手法が採用されます。あるチームは古いシステムの面倒を見ているため、重要視されるのは既存機能を安定的に運用するための機能への深い理解。あるチームは随時機能を追加しているような対顧客向けのシステムを作っているかもしれません。この時に重要視されるのは、顧客の要望をいかに早く仮説を立てて検証をするといったことなど。このようにチーム間でバラバラなプラクティスを採用していたとしても、Essenceを採用していればカーネルという土台のおかげで、それぞれのチームの健全性は常に把握することができるわけです。（書いてみたけど、あんまり理解できていないなぁ…）
個別
気になった部分に個別にコメントします。
世の中にはスクラムに関する書籍がたくさんある。だが、スクラムを知らない人に、すばやく説明できるだろうか。
P. 180 14.9 スクラムとEssenceのふりかえり
これ、私も最近よく遭遇するネタです…。様々な書籍や動画、研修などのメディアがあるため、たしかにいろいろなスクラムが存在します。Aの本にはこう書いてあって、Bの本にはそこまで言及してなかった、スクラムガイドはあっさりしていてどうしたらよいか分からない、みたいな。これに対して私は「底本」を一冊決めておこうか…と考えていたんですが、もっと正しいのはそれぞれの手法をエッセンシャル化するような対処だったのかもしれません。
透明なフィルムを順番に重ねて絵にするように、複数のプラクティスを順番に合成すれば、最終的に手法になる。たとえば、２つのプラクティスを合成する場合、使うべきもの、やるべきこと、能力、パターンを個別に合成していく。
P.253 18.1 合成とは何か
アクティビティスペース上にソフトウェア開発で必要となるアクティビティをパズルのように組み合わせていく。その結果自分たちのチームには何が不足しているのかがぱっと見で分かるようになる。この活用方法がEssenceのとっかかりとして良さそうだと思っています。
意識すべきマインドセットの変化とは何だろうか。（略）
１ チームの一部が手法を選択するのではなく、チーム全体で手法を所有する。
２ 手法の記述ではなく、手法の使用にフォーカスする。
３ チームの手法は固定されず、継続的に進化させていく。
P.304 23.1 プラクティスと手法でアジャイルになる
１と３は同意なのだが、２は…。手法は記述することによって安定すると思うのだけどなぁ。
感想は書いてみたのだけど、理解が浅い…本以外からも情報を得ようと思っていろいろ情報収集してみましたので、その記録を次に残します。
その他調べたことのメモ
Essenceの本丸っぽいところを発見。ホワイトペーパーなどの解説が充実していそう。
マーティン・ファウラーは否定的なポジションのようですね。人は本質的に非線形的で予測不能なもの。
次回
- #20
- 未定！
- デッドライン
- #19の感想交換1Week（10/5〜11）
- インターバル
- #20の読書する時間2Week（10/19～31）
- #20のブログポスト期限（11/1）
コメント