スクラム現場ガイドを読んだ

「スクラム現場ガイド」を読んで感じた自分の考えを忘備録として残していく。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

1章 スクラム：シンプルだが簡単ではない

成功の鍵として以下が述べられている。

• チームがルールを理解すること

• チームが基本的な仕組みを理解すること

• 時間を取ること

• 途中ではスクラムを始めないこと

マインドや仕組みの理解してもらうためには色々ある。

• 勉強会

• ディスカッション

• ワークショップ

スクラムの価値について

• 集中 スクラムチームとして1つのことに集中して取り組む。集中できない要因を表面化して対処する。スクラムマスターとしてやるべきこともある。

• 尊敬 尊敬しあえる関係をつくる。現状チームでできているのか？うまくプロジェクトを進めることで自然とメンバー間の尊敬が生まれる。

• コミットメント 「誓約」と書かれていることが多いが、どちらかというと「貢献」に近い気がする。 開発メンバーは必ず達成するという決意を持たないといけない。ただし残業や雰囲気が悪くなることは許されない。 メンバー間で、チームが達成するゴールの共有ができているか？

• 勇気 恐れを減らすことでチームやメンバーが困難に立ち向かうことができる。

• オープンさ 新しいアイデアを受け入れやすくすることで学習する組織になることができる。ふりかえりでこれを実現する。

2章 仲間と共に旅立つには

なぜスクラムをやるのか？理解してもらうことが必要。 チームのビジョンを知る。ビジョンを実現するためにスクラムをおこなう。 チームが求められていること、目標、ビジョンを改めて意識してもらう。

新しいことをチームに浸透させるために、共有を行う理解はメンバーに任せる

4章 ベロシティの測定

スプリント初期段階での、ベロシティの計測方法

• 過去のデータをつかう

• 手元のデータから推定する

• 様子を見る

最悪と最善のシナリオを想定してもらうため、ベロシティの平均は幅で伝える。 マイクコーンの係数表

幅で伝えることと、自信とセットでベロシティを伝えることで、ステークホルダーを巻き込んでプロジェクトを進めることができる。

5章 スクラムの役割

役割を兼務してはいけない。 スクラムマスターは木を見て森を見る。 開発メンバーは木をずっと見る。 兼務すると問題を混同しがちになってしまう。 ただ、スクラムマスターが開発チームの近くにいる状況は作れる。

6章 スプリントの長さを決める

プロジェクトが短いほどスプリントの期間を短く。 1スプリントが4ヶ月以上は長い。 プロジェクト期間の終了までのフィードバックの回数が適切か考えると良い。 要件が不透明な場合、フィードバックサイクルは短いほうがよい。

スプリントを決める要因 プロジェクトの期間 スクラムチームの能力 顧客の忍耐 リスクを取れる量

7章 完成を知る

完成の定義とは、最高の仕事への決意の表明。 完成の定義が必要だ、という回答にチームを導ける質問を用意する。

11章 リリースプランニング

最善と最悪の両方のベロシティから見積もりを出す。 期日と機能のトレードオフを伝える。 毎スプリントごとにリリースプランニングを修正する。

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

ストーリーを分割できないか考えてみる。 目安としてはユーザーがやりたいと思うアクション単位、またはシステムが行うアクション。 ストーリーが大きいかどうかは質問ベースで考える。明確か、詳細か、理解できるか。

13章 欠陥を抑制する

メンテナンスが放置されている。 その場でできる優先度の高いものはその場で行う。 メンテナンスをチームで行える仕組みが必要。

15章 スプリントレビュー

ステークホルダーにデモをさわってもらうやり方もある。 ステークホルダーに触ってもらうことで、想定外の操作があるかもしれない。 チームとステークホルダーのコミュニケーションが不足している。 チームに不要なストレスは書けない。

16章 ふりかえり

チームメンバーの学びの場。 検査と適応が最も現れるイベント。 クロージングとしてスプリントの感想を述べてもらうのは良さそう。 ざっくばらんに気軽に話せる環境を作ることで、チームメンバー間のコミュニケーションが活発になりそう。

19章 ペアプログラミング

設計を伝えたりメンタリングを行うときには素晴らしいが、すべての作業でやる必要はない。 交代のサイクルを早くすることで、ナビゲータの集中力を途切らせない。

20章 新しいメンバー

新規メンバーは、文化の変化を受容できる価値観を持っているか？ スキルよりも、変化に対応できるマインドを持っているかが重要。

21章 文化の衝突

理解する時間と空間を与える お互いが適応する

22章 スプリント緊急手順

• 障害を取り除く

• 助けを求める

• スコープを減らす

• スプリントを中止する

落ち着いて現状を分析し、チームメンバーやステークホルダーと密にコミュニケーションを取ることが大事。

23章 持続可能なペース

判断をしないことの痛みをもとある場所に返す。 ゴールは生産性を上げること、ただしいきなりそれを目指すのは良くない。 ペースを安定させて長いスパンをかけて生産性を上げていく。

燃え尽きそうなメンバーがいないか監視する。

24章 動作するソフトウェアを届ける

必ずリスクの高い要素から着手する。

コアストーリーを決める。 機能を薄く横断する形でストーリーを決めていく。 早く失敗することで手直しがやりやすいかつ早く手直しできる。 効率的だがあらぬ方向に進む可能性があるやり方と、多少非効率だが確実な方向に進むの方法どちらがよいのか？

25章 価値の測定と最適化

ステークホルダーや顧客にもわかりやすく伝えるために透明性が重要。 何か要望を通したいなら、その人にも考えてもらうようにすればうまく回るかもしれない。

• 機能実現

• 税

• スパイク

• 前提条件

26章 プロジェクトのコストを事前に考える

スクラムが始める前にコストを見積もるのは難しい。まずは仮定を基に見積もる。 スプリントが進むにつれて明らかな点が増えればそのたびに見積もりを行う。 顧客やステークホルダーには仮定を基に見積もったことを伝える。 チームや顧客、ステークホルダ全体でプロジェクトを進めていくのがアジャイル。

27章 スクラムにおけるドキュメント

ドキュメントを書かないのは間違い。いつ、なにを書くかが重要。

完了の定義や受け入れ条件にドキュメント作成を入れて、必ずドキュメントを更新する習慣をつける。 スプリントのPBIとしてドキュメントを作成することもアリ。 アジャイルに進めるということは、適切なタイミングで、正確に、責任を持ってドキュメントを書くということ。