「スクラム現場ガイド」を3分の2くらいまで読みました。

作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
出版社/メーカー: マイナビ出版
発売日: 2016/02/27
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

やっと3分の2くらいまで読んだので、また感想書いときますた。

Chapter 11：リリースプランニング

スクラムでのリリース計画の考え方についての話でした。スクラムでもリリース計画はありますが、ウォーターフォールのときと考え方が異なり、一定期間のチームのベロシティを基にして、「この機能までを実装するまでには、この辺りの日くらいで出来そう」とか、「この日にレビューなどやるなら、ここまでの機能までが出来てそう」とかを予想しするのです。
私がやってること、まんまでしたー。

Chapter 12：ストーリーやタスクを分割する

1つのストーリーを小さくすることで、スプリント内でたくさん完了を積むことができるよって話です。
目安としては、『ユーザがやりたいと思うアクションの最小のもの』あるいは、『ビジネス価値のあるに最小の機能』だそうです。
この切り方、はじめは慣れませんでした。最近では、サイズ「2」や「3」、大きくてもサイズ「5」くらいのものになってきてて、とても安定してます。

Chapter 13：欠陥を抑制する

バグが見つかった場合、どうするか（バグ潰しスプリントをやるか？スプリントの最後でやるか？など）？という話。ここでは、「バグが出たらその場で修正してしまう」という方針でやってみるというもの。ただし、1時間以内に直せなければ、いったん、欠陥トラッキングシステムに記録する。その後、引き続き欠陥の修正を行い、終わった後に作業内容をトラッキングシステムに記録し、元々やっていた作業の前にバックログを追加して、修正した欠陥の対応を記録するというものでした。こういった欠陥マネージメントのプロセスを定義しておき実施することが大事ということですね。ほんと、勉強になります！

Chapter 14：サステインドエンジニアリングとスクラム

「サステインドエンジニアリング」というのは、おそらく、前に作ったシステムを保守しながら、今の開発作業を続けるための技術手法のことだと思います。
そのアプローチとして、２つの案（「専任チームを割り当てるモデル」と「スプリントから固定時間を割くモデル」）を出していて、それぞれのメリット・デメリットや、専任チームにする場合、そのメンバーをローテーションさせるなどのアイデアを出していて、とてもいいと思いました。
レガシーコード（理解しづらい、変更しづらいコード）に対する対応も今後考えていきたいですね。

Chapter 15：スプリントレビュー

上手くいかなかったスプリントレビューについて、対策グループを作りやり方を変えたことでうまくいくようになったという話でした。スプリントレビューの準備にはあまり時間は掛けたくないのが本音でしょうが、ステークホルダーとの信頼関係を維持やフィードバックを頂くことなど重要な位置づけにあるものなので、場合によっては時間を確保してでも必要な準備をした方がいいのでしょうね。

Chapter 16：ふりかえり

ふりかえりが意味をなしてなかったチームの話です。毎回、だらだらと話すだけで、何の改善にもつながらなかったのであれば、やる意味ないってことになりますよね。
この話で面白かったのが、「改善が必要なこと」の優先順位を決めるために、メンバーそれぞれに仮想のお金100ドルを振り分けてもらい、もっともその額が多かったものから、その対策に取り掛かるようにするというもの。こういったことはやったことなかったので、とても参考になりました。

Chapter 17：生産的なデイリースタンドアップ

デイリースクラム（朝会）で、遅れてくる人や、まとまりがなかったり、曖昧な回答する人がいた場合の対処例が書かれていました。幸い、私はデイリースクラムで悩まされたことがないのですが、今後こういった事もあった場合の参考になりますね。

Chapter 18：第４の質問

デイリースクラムの際に言い難くて言い出せなかったメンバーが居て、そのせいで、前もってわかっていたにも関わらず問題明るみに出てしまったという話でした。デイリースクラムでは、基本、「昨日やったこと」「今日やること」「困っていること」をそれぞれメンバーが話していく場なのですが、「それだけでは話難いものがありそうだ」という場合には、第４の質問に答えていこうというそういった話でした。変にルールに囚われず、臨機応変にこういった質問増やせばいいというそういった例としていいですよね。

Chapter 19：ペアプログラミング

ペアプログラミングやっていると、キーボードを打っていない方のメンバーが退屈で居眠りしてしまうことがあるという場合の対処方法でした。マイクロペアリングという方法を提案しており、これの場合だと数分おきに頻繁にキーボードを打つ人が変わるので、居眠りする余裕もないというものでした。マイクロペアリングというのは初めて知ったプラクティスだったので、勉強になりました。