私が考えるスクラム開発のルールを記述します。

方針

地に足の着いた開発
- 持続的な開発を心掛ける。
  - 「ベロシティの安定」よりも「労働時間の安定」を心掛けるべき
    - 開発チームは「ベロシティを高めよう」と自然と努力する。
    - ベロシティを安定させようとすると、開発メンバーが労働時間の増減で調整しがちいなる。
可能な限り開発サイクル（反復）を維持する
- 開発サイクルの維持を妨害する要素（外部要因）から開発チームを守る努力が必要
  - インシデントの発生と対応時期の調整
  - 別チームとの連携（連携機能の開発スケジュールの調整）
可能な限り自動化
- コーディング
  - フォーマッターの活用
- テスト
  - リグレッションテスト自動化
- CI/CD
  - ブルーグリーンデプロイメント
自動化できない場合はチームでの標準化
- 各種資料
  - テンプレート化（必要部分を最低限、記入内容、表現方法を統一）
- コーディング
  - 命名方針（レビューコストを削減）
  標準化のメリット標準化のデメリット
  
  作成コストの削減（迷わなくなる）
  レビューコストを削減存在意義に対する認識欠如

標準化のメリット	標準化のデメリット
作成コストの削減（迷わなくなる）レビューコストを削減	存在意義に対する認識欠如

ルール

スプリント0

スクラムチームの定義

目的、チームの存在意義の定義
スプリント周期の定義

スクラムイベントの定義

周期	イベント
1回	スプリント0
スプリント	スプリントプランニング、スプリントレビュー、スプリントレトロスペクティブ
デイリー	デイリースクラム
適宜	プロダクトバックログリファインメント、リリーススプリント

リリーススプリントでの実施事項の定義（テスト項目、テスト方法）

ステークホルダの定義
品質バックログの存在の定義（妥当性確認計画）
技術負債に対する方針定義
- 技術負債量に対する方針（取り立てスプリント？）
- 過去の反復で作りこんだ不良に対する行動
  - 不良を作りこんだプロダクトバックログアイテムの完成の定義を見直す必要がある。

各スプリント

開始時（プランニング）

スプリントバックログアイテムのタスクの構成粒度（分解粒度）の定義
完成の定義
- レビュー量の定義（仕様決定：3名、実装レビュー：1名）

終了時

開発効率の定量化
- 各スプリントの開発メンバー全体、及び担当者毎の作業時間の可視化
- スプリント毎のベロシティの定量化、及び単位時間当たりのベロシティの定量化
技術負債量の定量化
- 技術負債の返済計画

反復の完了に係わるルール（例）

分類	ルールの例
信頼性	未解決の不良が0件
	当該反復の開発部分でのリグレッションテストの不備なし
	潜在もしくは反復跨りの障害が発生した場合のリグレッションテスト完了
	単体テストレベルで命令網羅率が100%
	ユースケースごとの不良摘出目標値達成（機能要求に対応したバックログに対応して目標値を設定）
	リグレッションテストレベルで確保すべき命令網羅のパーセンテージ
	リグレッションテスト準備、実行、確認を含めて全自動化されていること
保守性	新規・変更のメソッド・関数の複雑度の上限
	新規・変更のメソッド・関数の最大ネストの上限
	新規・変更のメソッド・関数の実行分行数の上限
	クラスの実行分行数の上限
	クラス内の各メソッドの複雑度合計の上限
	UTF-8以外のエンコードのソースコードなし
	テスト部分を除く最大のコードクローンのトークン数の上限
	静的解析指摘のインシデントなし
	その他のプロジェクトのコーディング規約違反がないこと
	技術的負債の算出および上限値
	ディレクトリ構成及びファイル名等が実装規約通りであること
	チケット管理システム及びファイル名等が実装規約通りであること
	チケット管理システムおよびバージョン管理システム等の使用方法が正しいこと
作業関連	反復終了時に技術的負債を人時で算出していること
	レトロスペクティブでKPTが明確であること