注意：
抽象度低く、具体性高い記事。
全てのプロジェクトに適切なものかはプロジェクトに応じるのであくまで参考程度に。
ただし、取り入れはしなくても考え方は知っておかないと痛い目を見ます。
以下プラクティス集
1:実践、推奨プラクティス
・ストーリー実施時はテストケースの追加をdevが実施し、ストーリー完了時にdevがテストケースの確認をする（もしくはテストコードの作成）
コード品質の向上
・1PBIは1人が1週で終わるサイズ以上にする
デカすぎて開発できませんでした！
→ スプリントで進捗がない → プロダクトゴールへの進みがわからない →信頼とか色々失う
・1ストーリーは20時間で収まる範囲
DODが漠然としないため、予測が大きくずれないため
・プランニングは2weekならば最大6時間
これでも時間が足りない場合、リファインメントが機能していない、KTが機能していないことの指針となるので、このルールによって問題点をあぶり出す。
・基本2week1スプリントとして進行
短すぎても長すぎても、設計が崩れたり、開発が遅れたりするので
・出社時の1日1時間KT時間
KTを行い、知識共有は、コードの健全性を高め、結局はリターンとして大きなものが帰ってくる。病気リスクのケアにもつながる
・gitのブランチルール
当然
・製作物のviewはスプリント開始前に用意してもらう（最低正常系、異常系1パターンずつ）
見た目は一番認識がズレるところ、また、機能のイメージも画面がないとすぐ想定がずれやすい
・レビューという儀式は、受け入れではなく、受入済みのものをステークホルダー に共有するもの。そのタイミングで受け入れしない
POのお客様意識を排除する、スプリント内でのコミュニケーションを促進するため、阻害しないため
・KPTは keep notGood try action（推奨）
改善を考える機会を最大化できる、具体的な改善策に意味はない
・リファインメントは2weekであれば、合計6時間確保する、一ヶ月先のものまではしっかり見積もり、
全体の見積もり精度を上げ、個別ストーリーのDOD理解を促進する
※一ヶ月以上先のものはざっくり見積もりを行う。
・SMとは別にテックリーダーがいること（最悪兼任でも良い）
設計のないコードは悪いものである可能性が非常に高いので、それを回避するため
・外部で働くアドバイザーみたいなエンジニアは不要
実際に手を動かせる人間、現場感の説明時間というコストがかかる、よっぽどの特別な理由がない限りはコスパは悪い。
・定期的なスクラムチェックリストの確認会をSMとPOで行う。
POのスクラム知識は開発効率に大きくつながる、それぞれの範囲での成果の最大化は
・マルチファンクショナルなチーム
外部から雇ってもコミュニケーションコストや、スピード感の違いで、結局最初はいなくてもチーム内のエンジニアがキャッチアップした方が効率がいいパターンがほぼ毎回
・フロントおよびバックエンドのテストコード
テストコードでバグを下げる、テストコードを書いた人間がバグに最速で気づくスピードを上げるのと、
後日リファクタした時に潜在バグに気づくメリット、inputアウトプットを簡単に見れるなどのメリットがある
・バグに対しては必ず5wを記載する。
バグを出す理由は必ず何処かにある、それを探れないエンジニアは、開発チームの質と、信用を下げる
・コードプッシュで自動デプロイされる環境
無駄な工数の削減
・テックのプロフェッショナル知識のあるテックリーダーとスクラムマスター
スクラムマスターだけでは無理、二人で引っ張る環境、もしくは全部するスクラムマスターが理想。
・50%以上チームの横にいるPO
チーム意識を芽生えさせるため必要
・開発チーム内コーディングルールと手順書の設置場所の確保
設計の共有場所は必要、また、運用の手順書は常に作らないと、運用は不可能
・インフラのパラメータシート
運用する上で、パラメータシートがないと、整理も共有効率も崩壊する
・ハッピーパスとアンハッピーパスの作成と、マイルストーンの定期的な確認会(2~3ヶ月に一回)
ビジネス価値の意識をPOに根付かせるため、不要なストーリーを追加しないため
・ストーリー、PBIへのDODの明確な定義
透明性を上げるため、PO自身によって透明性を高めること、当事者意識を持つためあ
・DODに毎回記載が面倒なやってほしい項目は記載箇所を変え、そこへのリンクをストーリーに貼り付ける
透明性の向上のため
・POによるPBI受け入れ要件リスト（チェックリスト）
POが要件を決めること、チーム意識の醸造
・ストーリーのビジネス価値を常にPOに確認する
ビジネス価値のない仕様を省き、最速で価値をデリバリーするため、無駄な開発を行うことで無駄な時間を減らし、無駄な信頼関係の喪失を省く
・1スプリントごとのPOからステークホルダーへのデモ
POだけではプロジェクトは回らない、いろいろなメンバーへの協力を仰ぐこと、現場感を伝えること、開発のビジネス価値で優先順位を持って開発する考えを育むため
・スプリント前のメンバー全員による1h単位でのタスクぎり
・リファインメントは1ヶ月分ストックを目指して、開発工数の10%を使用する
共通のコード
・開発環境、stg環境、prod環境は必要
これは環境の切り替えに慣れる必要があることもある、stgがないと開発環境から本番に移す時に一発勝負なので、事故の確率は飛躍的に高まる
・リファインメント前の設計担当者の前読み込み、情報整理は有用（2~4hが適切）
全員で調査する時間は無駄、結果の全員への共有は必要
・リファインメントでのPBIごとのタイムボックスは確保が望ましい（PBIにもよるが5m~10m）
深入りしても良くない、リファインメントはあくまで薪割り、プランニングよりは概要をポイントとしたもの。
・対象端末は確定する
これはPOとのDODの共有につながる
・プランニング2の段階で、ストーリーのDODを明記し確定させる、これはすなわちやらないことを確定させるという意味でもある。
・個人の消化予定時間を毎スプリントみる
個人の作業効率向上なくして、チームでの作業効率向上はないので
・バグチャートを使用した振り返り
バグを増やさないため
・プランニング2で、1タスク１時間で作成する
知識共有と、設計をかため、予定時間の精度も高めるため
・スクラムとCICDと自動テストは基本的に切り離せるものではない。そういった実装を行えるエンジニアは一人は確実に必要。
無駄な繰り返し作業を省き、作業効率の最適化を行うため、
・スクラムマスターとテックマスターが3ヶ月くらいでスケジュールを大方整理するなど理想
スクラムと言っても、スケジュールに乗せる考えは必要なので
・見積もりを安定させるための設計ストーリーは必要（何か形に残る成果物は必要）
全員で設計をする必要はなく、できた設計が共有されれば充分
・最低でも設計に責任を持つ人間はPRレビューを実施する
コード品質の低下を下げる
・POも含めてKPTでのMVP投票
POとdevの当事者意識と要件確定の責任感、チーム感を高め、開発効率の邪魔になるお客様意識を防げる
・1週間に一人2hのPRレビュー時間、一人2hのKT時間、リファクタは1.5h バッファは10%
PRレビューの時間は必要、正しい設計につながる、KTも大事、全てはコードの品質を高めるための目的、
バッファ10%を取れば、過度なマイクロマネジメントを防ぎ、コミュニケーションコストを下げる
リファクタは必要、開発を進めれば、どんな設計も見直しが必要な時がくる、それをより早いタイミングでつぶさないと
さらに大きな負債となり近い未来に無駄な時間につながる
・アジャイル開発のプロになるなら、スクラムガイドと、エクストリームプログラミングの理解はあるとかなり質は高まる。
比較検討ができるようになり、それぞれの良さの理解度もグッと上がる。
・テックリーダーの存在
スクラムマスターがごちゃごちゃいうと、やっぱり、指摘に大して、メンバーが反感や、自立心を損なう可能性が高まる
テックリーダーがその指摘を行うことで、チームの総意感が高まり、チームの意向として納得しやすくなる。
経験が浅いチームにはテックリーダーは必要不可欠くらいに考えても良い。
・1日の集中時間は5時間程度で計算
これはPRレビューなどは含めず、あくまで個人での開発の時間、個人のスキルアップ機会の確保、モチベの確保、現実的な限界点、開発効率の最適化、開発予定時間の精度向上
・集中時間の確保
最低3時間は欲しい、話しかけることでの集中力を妨げることの防止のため、同時にKTも大事なのでバランスは非常に難しい、ペアプロ1時間、集中3時間などが理想
・他人によるチェックリストでの確認
(開発者Aがストーリーチェックリストの作成と、確認、その後Bがチェックリストのダブルチェックをする) ストーリーにサイズにもよるが最大1hづつ
POの消費時間の減少のため、認識齟齬の解決、バグの最速での潰し
・ストーリーは、開発中→コードレビュー→テストケースチェック→POレビュー→完了の流れ
品質高いコードのため
・リモートの際、meatはつなぎっぱなし、話しかけるときはチャットで一言
すぐ話しかけるメリットと、集中の両立のため
・ストーリーポイントはフィボナッチで
見積もりを長中期的に実施できることにつながる、また、チームで一致させやすいためにフィボナッチを使用する
・クロスファンクショナルなチームが必要、フロント、バック、DB、運用、デザイン、ビジネス
ビジネスはPOが担当する、この視点がないと、運用に耐えうる開発物は作れない。チームとすることで、情報の共有にかかる時間が人数分まとめて実施できる効率化がある。
・リファインメントは1回3時間まで、開発は全員参加
長すぎても集中力は持たない
・ ペアプロは1日1時間
知識共有を進めるため
・必要に応じた設計ストーリーの作成
予測時間、DODの明確化のため、必要な時はある
・半分はリモート、半分は直接出社
リモートができないというのは、問題があるから、devの4時間も集中時間を確保する目的もある
・リモートの理想は週の半分
リモートでモチベの向上、開発メンバーの場所的ディスアドバンテージの解消、
リモートをすることで、直接実施している無駄の削除の洗い出し、知識共有ができていない問題の洗い出し
・スクラムマスターの開発参加50%
開発を実施することで、スクラムルールを高圧的に押しつけず、ある程度話を聴けるようにする、100%にしないことで、スクラムマスターとしての業務も実施し続ける
開発目線があることで、現実的なスクラムの成長をチームと進めていける。
メモ欄
↓ ストーリー編
↓ プランニング編
↓ リファインメント編
↓ 日常の開発編
↓ レビュー編
↓ KPT編（レトロ）
↓ デプロイ編
↓ 中長期的なスケジュール編