「エッセンシャルスクラム」はまさに中級者向けだった（前半戦） drc#24

　デッドライン読書会第24回は「エッセンシャルスクラム」の前半戦でした。デッドライン読書会の説明はこちら。

課題図書
感想文
1. 個別で興味深かったところ
次回

課題図書

　今回の課題図書は、Kenneth S. Rubinさん著作の「エッセンシャルスクラム」の前半戦でした。範囲は第Ⅰ部「コアコンセプト」と第Ⅱ部「役割」です。エッセンシャルスクラムは、システム開発のメソドロジーであるスクラムの中級本としてよく取り上げられています。邦訳は2014年出版です。いつか読みたいな～と積読になっていましたので、まさにデッドライン読書会で消化するにふさわしい一冊です。

https://amzn.to/2OttR7j

感想文

　第２章「スクラムフレームワーク」と第３章「アジャイルの原則」で基本的なスクラムの内容を学ぶことができます。スクラムはスクラムガイド2020によって定義されていますが、実践は各現場にお任せです。スクラムガイドはスポーツでいうルールに近く、各テクニックや戦術は書かれていません（この説明は強引なたとえ）。これでは、いざやろうとした時に困っちゃうよね？ってことで様々な解説書が出版されています。とりわけ中級と考えられる書籍は、本書の他に、

Bitly

Bitly

Bitly

などがあげられるでしょうか。（あれ…Clean Agileって読んでいないような…）

　前半ではコアコンセプト（原則、要件、プロダクトバックログ、見積もり、技術的負債）と役割（プロダクトオーナー、スクラムマスター、開発チーム、スクラムチームの構成、マネージャー）がテーマにされていますが、著者の経験に基づいた具体的な解説で、自身の現場とのDiffがとりやすい書きっぷりになっていると感じました。

　特に「役割」が良いですね。「責任」、「特性とスキル」、「一日の様子」で解説してあるため、自分（や、自分のチーム）のふるまいとの比較がしやすいです。一日の様子を見ると、各役割がどういった活動に何％くらいパワーを割いているっていう踏み込みもあります。「なるほど、他の現場ではこんなふうにやってるんだ」っていうのが学べます。ただいずれも説明されている「特性」っていうのは…ちょっと言いすぎかなぁとも思います。「〇〇を持っている人がスクラムマスターに向いている」みたいにも読めるため、そこまで言わなくてもよいのではと思いましたね。

個別で興味深かったところ

新しいスクラムチームに「スクラムガイド」を渡して、よい結果を期待することはできない。著者たちの比喩を使えば、チェスを初めてプレイする人にルールの説明書を渡して、まともに指すことを期待するようなものだ。「スクラムガイド」だけでは足りないのである。
まえがき

　さっきスポーツの例を書きましたが、本書ではチェスの例でしたね。

たとえば、スクラムを新製品開発に用いて、カンバンを割り込み駆動のサポートと保守に使うといった具合だ。
第1章イントロダクション 1.5 スクラムは役に立つか？

　今年これは研究したいこと。それぞれは理解しているが、うまく連携した方式を試してみたいなと。下記の本をもう一度引っ張り出してこなくては。

今すぐ実践！カンバンによるアジャイルプロジェクトマネジメントマイクロソフト関連書

理論から実践へ！アジャイルに踏み出せなかった現場に贈る、効率的なチーム運営の秘訣とは？ソフトウェア開発における「カンバン」（英語でもKanban）は、トヨタのジャストインタイムスケジュール管理メカニズムに基づくプロジェクト管理手法のこと。本書は"Agile Project Management with Kanba...

アジャイルの原則を伝統的な開発の原則と比較するのは、計画駆動の開発が悪く、スクラムがよいと証明するためではない。どちらも、プロの開発者の道具箱に入っているツールなのだ。悪いツールなどというものはなく、そのツールを使うのに適していない機会があるだけだ。
第3章アジャイルの原則 3.1 概要

　最近仕事でこんなんあったなぁ。そういえばCSMの研修を受けたときに教えられたことでもある。「スクラムマスターはチームが最適な開発方法論を選択できるようにサポートする必要がある」と。

最終責任時点（LRM）
第3章アジャイルの原則 3.3 与件と適応

　Leanの用語だったか。ぱっと分からなかったのでメモ。

経験上、スプリント2回から3回分程度のストーリーを準備完了状態で抱えておくとうまくいくことが多いようだ。
第6章プロダクトバックログ 6.6 フローの管理

　こういう具体的な話がとても助かる。

それも面倒な質問ではなく、質問することが目的ではなく、思慮に富んで深遠であり、内省をうながす質問（probingquestion）をする。それによって、自分で答えを見つけられることを認識してもらうのである（ソクラテス式問答法だ）。
第10章スクラムマスター 10.3 特性とスキル

　これね。むずすぎる。コーチングスキルなんかな。（スキルと書くとなんだか浅薄だなぁ）

私がゲーム開発のチームにいたとしたら、AIとちょっとしたテストは担当できるだろうが、アートデザインは無理だろう（私にさせたくもないはずだ！）。しかし、Photoshopでファイルフォーマットを変換したり、複数のファイルを処理するスクリプトを書いたりするような、アーティストの才能が不要なデザインワークでアーティストたちを支援することはできる。
第11章開発チーム 11.4 特性とスキル

　開発メンバーは多能工であることが求めら、特にT字型スキルであることが望ましいと。それでも高度な専門性や、一見センスが必要そうな領域って避けがちだと思います。この例を引用したのは、「やるか、やらないかの、ゼロイチじゃないよね」ってことを示す好例だと感じたからです。

13.6 プロジェクトマネージャー

　この節は全体的に参考になった。マネージャーと、ファンクショナルマネージャーと、これまでのプロジェクトマネージャーが、スクラムではどういう役割分担となるかの整理。

次回

後半も楽しみです。

#25
- エッセンシャルスクラム（後半戦）
デッドライン
- #24の感想交換1Week（3/15〜21）
- #25の読書する時間2Week（3/22～4/3）
- #25のブログポスト期限（4/4）