tag:crieit.net,2005:https://crieit.net/tags/%E7%9F%A5%E8%A6%8B/feed Crieitでタグ「知見」に投稿された最近の記事 2022-10-28T20:17:34+09:00 https://crieit.net/tags/%E7%9F%A5%E8%A6%8B/feed tag:crieit.net,2005:PublicArticle/18310 2022-10-28T20:17:34+09:00 2022-10-28T20:17:34+09:00 https://crieit.net/posts/scrum-master-knowledge <h1 id="TL; DR"><a href="#TL%3B+DR">TL; DR</a></h1> <p>スクラムは１日にしてならず。</p> <h1 id="内容"><a href="#%E5%86%85%E5%AE%B9">内容</a></h1> <p>スクラムマスター研修を受けたので、その際に得た知見を書いておきます。<br /> スクラムマスター研修とありますが、実際にはスクラムに対する知識も増えたので、スクラム全体に対する内容もあります。</p> <h1 id="スクラムについて"><a href="#%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6">スクラムについて</a></h1> <p><a target="_blank" rel="nofollow noopener" href="https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf">スクラムガイド</a></p> <h2 id="シンプルさ"><a href="#%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%81%95">シンプルさ</a></h2> <p>スクラムは、スクラム単体では不完全なように意図的に作られている。<br /> スクラムは、拡張できる。</p> <h2 id="リスクについて"><a href="#%E3%83%AA%E3%82%B9%E3%82%AF%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6">リスクについて</a></h2> <p>アジャイルではリスクを下げ続ける、ウォーターフォールではリスクが上がり続ける。</p> <h2 id="スクラムマスターが実施すべきこと"><a href="#%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%81%8C%E5%AE%9F%E6%96%BD%E3%81%99%E3%81%B9%E3%81%8D%E3%81%93%E3%81%A8">スクラムマスターが実施すべきこと</a></h2> <ul> <li>専任の／安定したチームの構築</li> <li>明確な「完成の定義」の策定</li> <li>スクラムが明らかにしていることを、無視せず対処</li> </ul> <h2 id="スクラムの要素"><a href="#%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%81%AE%E8%A6%81%E7%B4%A0">スクラムの要素</a></h2> <p>スクラムには、次の要素がある。</p> <ul> <li>3つの役割</li> <li>3つのアーティファクト（成果物）</li> <li>5つのイベント</li> </ul> <h3 id="3つの役割"><a href="#3%E3%81%A4%E3%81%AE%E5%BD%B9%E5%89%B2">3つの役割</a></h3> <ul> <li>プロダクトオーナー</li> <li>開発者</li> <li>スクラムマスター <ul> <li>スクラムマスターは場を用意する責任はあるが、問題を解決する責任は無い</li> <li>スクラムマスターはスポーツコーチのようなもの</li> <li>スクラムマスターは、最初に、自分の助けが必要か尋ねる（自分から首を突っ込むことはしない）</li> </ul></li> </ul> <h3 id="3つのアーティファクト"><a href="#3%E3%81%A4%E3%81%AE%E3%82%A2%E3%83%BC%E3%83%86%E3%82%A3%E3%83%95%E3%82%A1%E3%82%AF%E3%83%88">3つのアーティファクト</a></h3> <ul> <li>プロダクトバックログ</li> <li>スプリントバックログ</li> <li>インクリメント</li> </ul> <h3 id="5つのイベント"><a href="#5%E3%81%A4%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88">5つのイベント</a></h3> <ul> <li>スプリント</li> <li>スプリントプランニング</li> <li>デイリースクラム</li> <li>スプリントレビュー</li> <li>スプリントレトロスペクティブ</li> </ul> <p>リファインメントは、頻度が高いため、イベントに含まれない（後述）。</p> <h2 id="3つの役割に大切なこと"><a href="#3%E3%81%A4%E3%81%AE%E5%BD%B9%E5%89%B2%E3%81%AB%E5%A4%A7%E5%88%87%E3%81%AA%E3%81%93%E3%81%A8">3つの役割に大切なこと</a></h2> <h3 id="プロダクトオーナー：決断力（と権限）"><a href="#%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%82%AA%E3%83%BC%E3%83%8A%E3%83%BC%EF%BC%9A%E6%B1%BA%E6%96%AD%E5%8A%9B%EF%BC%88%E3%81%A8%E6%A8%A9%E9%99%90%EF%BC%89">プロダクトオーナー：決断力（と権限）</a></h3> <p>プロダクトオーナーは、高速に変化する外部／内部の状況に対して、迅速な決断をする必要がある。<br /> また、外部への承認を通せるだけの権限が必要である。</p> <h3 id="開発者：汎用性"><a href="#%E9%96%8B%E7%99%BA%E8%80%85%EF%BC%9A%E6%B1%8E%E7%94%A8%E6%80%A7">開発者：汎用性</a></h3> <p>開発者はエキスパート（1つのことしかしない人）になってはならない。<br /> どのようなタスクに対しても実行できるだけの知識を得る必要がある。</p> <h3 id="スクラムマスター：影響力"><a href="#%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%EF%BC%9A%E5%BD%B1%E9%9F%BF%E5%8A%9B">スクラムマスター：影響力</a></h3> <p>スクラムマスターは、他者を巻込むための影響力が大切である。<br /> 影響力には、権威は必要無いが、知識／資格／コネといったソフトスキルが重要となる。</p> <h2 id="リファインメントの頻度"><a href="#%E3%83%AA%E3%83%95%E3%82%A1%E3%82%A4%E3%83%B3%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AE%E9%A0%BB%E5%BA%A6">リファインメントの頻度</a></h2> <p>プロダクトバックログのリファインメントは、プロダクトオーナーが予定をたててでも、最低限でも毎日は実施すべき。<br /> 理想としては、1日に何回でも実施すべき。</p> <p>また、スプリントバックログは、すべての開発者がリアルタイムに作業状況を反映させるべき。</p> <p>これが、デイリースクラムで進捗報告しなくても問題ない理由となる（バックログを見ればわかることをわざわざいう必要はない）。</p> <h2 id="外部からの仕事の対処"><a href="#%E5%A4%96%E9%83%A8%E3%81%8B%E3%82%89%E3%81%AE%E4%BB%95%E4%BA%8B%E3%81%AE%E5%AF%BE%E5%87%A6">外部からの仕事の対処</a></h2> <p>スクラムマスターや開発者に対して、外部からの仕事が依頼された場合は、プロダクトオーナーに判断を仰ぐ。<br /> それにより進捗が遅くなるのはプロダクトオーナーの責任となる。<br /> それをプロダクトオーナーが許容するのであれば、外部の仕事をスクラムチームメンバが担って構わない。</p> <h2 id="ユーザーストーリーに必要なもの"><a href="#%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AA%E3%83%BC%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%AA%E3%82%82%E3%81%AE">ユーザーストーリーに必要なもの</a></h2> <p>以下の要素を含める。</p> <ul> <li>誰が、......をしたい、なぜなら......</li> <li>価値（受入基準）</li> <li>作者（チケット作成者）</li> <li>見積り</li> </ul> <p>プロダクトオーナーにプロダクトバックログの価値を理解させるためのツールの1つであることに気をつける。<br /> プロダクトバックログアイテムの1つにリファクタリングとあっても、それだけではプロダクトオーナーは価値を見出せずに無視してしまうかもしれない。<br /> ここに、顧客の価値を書く事で、プロダクトオーナーの注意を引きつけることができるはず。</p> <h2 id="スプリント計画のトピック"><a href="#%E3%82%B9%E3%83%97%E3%83%AA%E3%83%B3%E3%83%88%E8%A8%88%E7%94%BB%E3%81%AE%E3%83%88%E3%83%94%E3%83%83%E3%82%AF">スプリント計画のトピック</a></h2> <p>以下の要素を含める。</p> <ul> <li>スプリントの価値</li> <li>できるようになること</li> <li>できるようにする方法</li> </ul> <p>スプリント計画で開発者を割当てるのはスプリントバックログアイテムではなくタスクであることに注意する。<br /> 1つのスプリントバックログを、開発者全員でタスクに取掛かることが望ましい。</p> <h2 id="各イベントの理想的な時間配分"><a href="#%E5%90%84%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88%E3%81%AE%E7%90%86%E6%83%B3%E7%9A%84%E3%81%AA%E6%99%82%E9%96%93%E9%85%8D%E5%88%86">各イベントの理想的な時間配分</a></h2> <ul> <li>スプリント：1day ~ 4weeks</li> <li>スプリント計画：8h/month</li> <li>デイリースクラム：15min/day</li> <li>スプリントレビュー：4h/month</li> <li>スプリントレトロスペクティブ：3h/month</li> </ul> <h1 id="スクラム運用のテクニックについて"><a href="#%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E9%81%8B%E7%94%A8%E3%81%AE%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6">スクラム運用のテクニックについて</a></h1> <h2 id="スクラムの要素 + α"><a href="#%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%81%AE%E8%A6%81%E7%B4%A0+%2B+%CE%B1">スクラムの要素 + α</a></h2> <p>以下は例として挙げる。</p> <ul> <li>5つの役割 = 3 + 2</li> <li>6つのアーティファクト = 3 + 3</li> <li>7つのイベント = 5 + 2</li> </ul> <h3 id="5つの役割"><a href="#5%E3%81%A4%E3%81%AE%E5%BD%B9%E5%89%B2">5つの役割</a></h3> <ul> <li>プロダクトオーナー</li> <li>開発者</li> <li>スクラムマスター</li> <li><strong>ステークホルダー</strong></li> <li><strong>スクラムメンター</strong> <ul> <li>スクラムマスターを補助するための、スクラムチーム外の人</li> <li>スクラムマスターのコーチ役</li> </ul></li> </ul> <h3 id="6つのアーティファクト"><a href="#6%E3%81%A4%E3%81%AE%E3%82%A2%E3%83%BC%E3%83%86%E3%82%A3%E3%83%95%E3%82%A1%E3%82%AF%E3%83%88">6つのアーティファクト</a></h3> <ul> <li>プロダクトバックログ</li> <li>スプリントバックログ</li> <li>インクリメント</li> <li><strong>プロダクトゴール</strong></li> <li><strong>プロダクトロードマップ</strong></li> <li><strong>リリース計画</strong></li> </ul> <h3 id="7つのイベント"><a href="#7%E3%81%A4%E3%81%AE%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88">7つのイベント</a></h3> <ul> <li>スプリント</li> <li>スプリントプランニング</li> <li>デイリースクラム</li> <li>スプリントレビュー</li> <li>スプリントレトロスペクティブ</li> <li><strong>プロダクト計画</strong></li> <li><strong>リリース計画</strong></li> </ul> <h2 id="Geoffrey Moore氏のプロダクトビジョン・テンプレート"><a href="#Geoffrey+Moore%E6%B0%8F%E3%81%AE%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%83%93%E3%82%B8%E3%83%A7%E3%83%B3%E3%83%BB%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88">Geoffrey Moore氏のプロダクトビジョン・テンプレート</a></h2> <p>プロダクトゴールを見据えるためのテンプレートの例を、以下に示す。</p> <pre><code class="html"><顧客ニーズの内容>がある<ターゲット顧客>のための<プロダクト名>は、<ユニークな顧客のメリットやセールスポイント>がある<プロダクトカテゴリ名>です。 <競合や代替手段名>と異なり、我々のプロダクトは<主な差別化ポイント>に強みがあります。 </code></pre> <p><a target="_blank" rel="nofollow noopener" href="https://blog.allstarsaas.com/posts/make-product-vision">日本のSaaSにはまだ足りない…急成長を支える「プロダクトビジョン」を作るための8つのポイント - ALL STAR SAAS BLOG</a></p> <h2 id="同意形成のテクニック"><a href="#%E5%90%8C%E6%84%8F%E5%BD%A2%E6%88%90%E3%81%AE%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF">同意形成のテクニック</a></h2> <p>難しそうなテクニックはなるべく避ける、簡単な合意にツールは必要ない。</p> <h3 id="抵抗ポイント"><a href="#%E6%8A%B5%E6%8A%97%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88">抵抗ポイント</a></h3> <ol> <li>項目を複数並べ、各項目に対し、0=喜ばしい〜9=本当に嫌、の10段階で各人にポイントを振り分けてもらう</li> <li>合計し、最も数値が低いものを選ぶ</li> </ol> <h3 id="5本指投票"><a href="#5%E6%9C%AC%E6%8C%87%E6%8A%95%E7%A5%A8">5本指投票</a></h3> <ol> <li>5=素敵！〜1=反対で進めてはいけない、までを片手で出してもらう</li> <li>項目を順に出していって、全員が3以上ならその数字で確定する</li> </ol> <h2 id="見積り手法"><a href="#%E8%A6%8B%E7%A9%8D%E3%82%8A%E6%89%8B%E6%B3%95">見積り手法</a></h2> <h3 id="相対見積り"><a href="#%E7%9B%B8%E5%AF%BE%E8%A6%8B%E7%A9%8D%E3%82%8A">相対見積り</a></h3> <ol> <li>見積りポーカー <ol> <li>最初にアンカー（指標）となるプロダクトバックログアイテムを開発者全員で選択し、5と仮定する</li> <li>それと比較し、開発者に数字を提示してもらう（プロダクトオーナーとスクラムマスターは出さない）</li> <li>差がない場合は、その数値で確定し、次のプロダクトバックログアイテムを選択する</li> <li>差がある場合 <ol> <li>最小数値を出した人と最大数値を出した人に意見を伺う</li> <li>3回やってもまとまらない場合は、手順2. に進む</li> <li>手順1.2. に戻る</li> </ol></li> </ol></li> <li>5本指投票：Fist of Five <ol> <li>全員が出した数字を大きい（小さい）順に出していく</li> <li>全員が3以上ならその数字で確定する</li> <li>そうで無いなら、手順2.1に戻る</li> </ol></li> </ol> <h3 id="類似性に基づく見積り"><a href="#%E9%A1%9E%E4%BC%BC%E6%80%A7%E3%81%AB%E5%9F%BA%E3%81%A5%E3%81%8F%E8%A6%8B%E7%A9%8D%E3%82%8A">類似性に基づく見積り</a></h3> <p>大量のチケットを捌く時に役立つ。</p> <ol> <li>MS, S, M, L, XLに相当するチケットを、それぞれに代表して1つずつ開発者が選ぶ</li> <li>全チケットを、MS, S, M, L, XLに開発者が当てはめる（ここは手分けしてで良い）</li> <li>全チケットを開発者が参照し、気になったチケットについて議論してもらう</li> <li>プロダクトオーナーにチケットサイズをレビューしてもらう</li> </ol> <h2 id="スクラムでよく使用されるが、スクラムでは規定されていないもの"><a href="#%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%81%A7%E3%82%88%E3%81%8F%E4%BD%BF%E7%94%A8%E3%81%95%E3%82%8C%E3%82%8B%E3%81%8C%E3%80%81%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%81%A7%E3%81%AF%E8%A6%8F%E5%AE%9A%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E3%82%82%E3%81%AE">スクラムでよく使用されるが、スクラムでは規定されていないもの</a></h2> <p>3つの役割／3つのアーティファクト／5つのイベント以外の全ては、スクラムでは規定されていないと考えて良い。<br /> 例えば、次の項目はスクラムでは無い。</p> <ul> <li>プロダクトロードマップ</li> <li>リリース計画</li> <li>ユーザーストーリー</li> <li>プランニングポーカー</li> <li>デイリースクラムにおけるスタンドアップミーティング <ul> <li>補足：<a target="_blank" rel="nofollow noopener" href="https://bliki-ja.github.io/ItsNotJustStandingUp/">朝会のパターン:立ってるだけじゃないよ - Martin Fowler's Bliki (ja)</a></li> </ul></li> </ul> <h1 id="大規模なスクラムチームの運用"><a href="#%E5%A4%A7%E8%A6%8F%E6%A8%A1%E3%81%AA%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AE%E9%81%8B%E7%94%A8">大規模なスクラムチームの運用</a></h1> <h2 id="スクラムオブスクラムズ"><a href="#%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%82%AA%E3%83%96%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%82%BA">スクラムオブスクラムズ</a></h2> <ol> <li>スクラムチームの開発者に1人、開発者のスクラムオブスクラムズを用意する。同様に、スクラムマスターをスクラムオブスクラムズとする</li> <li>全スクラムチームのデイリースクラムを、同じ時間に（もちろん各スクラムチーム毎に）対応する</li> <li>デイリースクラム完了後、スクラムチームの代表者として、開発者のスクラムオブスクラムズとスクラムマスターのスクラムオブスクラムズを、それぞれの会議体として用意し、スクラムチーム間の内容を調整する</li> <li>終わったら、各スクラムチームに戻って伝える（ここは会議体にする必要はない）</li> </ol> <h2 id="アジャイル移行チーム"><a href="#%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E7%A7%BB%E8%A1%8C%E3%83%81%E3%83%BC%E3%83%A0">アジャイル移行チーム</a></h2> <p>組織をスクラムに適応するための「アジャイル移行チーム」というスクラムチームを用意しても良い。<br /> 開発スクラムチームで検知した妨害に関する項目が、アジャイル移行チームのプロダクトバックログとなる。</p> <h2 id="組織の障害"><a href="#%E7%B5%84%E7%B9%94%E3%81%AE%E9%9A%9C%E5%AE%B3">組織の障害</a></h2> <p>組織をスクラムに適応しようとする際に発生する障害の例を、以下に示す。</p> <ul> <li>マトリックス化／分断したチーム</li> <li>スペシャリスト／単一障害点</li> <li>サイロ／ハンドオフ</li> <li>権限を与えられていないPO</li> <li>専門的な移行サポート無し（コーチング無し）</li> <li>「私たちの会社は他社とは違う」という意識</li> </ul> Morichan