スクラム定義
スクラムの進め方を記載しました。これから始める方の参考になれば幸いです。実践するときのコツなどは別の記事で書きます。
スクラムはアジャイルの価値観を実現するためのフレームワークです。
詳細はアジャイルとスクラムの違い〜定時で帰らせるためのマネジメントシリーズ〜に記載しました。
思い
定時で帰すのは、１日あたりの労働時間を固定すると正しくベロシティ（開発速度）が計測できますし、開発効率が上がります。何よりエンジニアの心身の健康が守れます。
（2022年3月現在まだまだできていない…）
元ネタ
会社のミッションと融合させなければ、社内に浸透しないので、アジャイル・スクラム・XPと融合させました。
- アジャイルソフトウェア開発宣言
- ジェフ・サザーランドの「スクラム 仕事が４倍速くなる“世界標準”のチーム戦術」
- ケントベックの「エクストリームプログラミング」
- ソフトブレーン7つの行動指針
目的
- ソフトブレーンのミッション「顧客の生産性の最大化」に合致する ※1
- ソフトブレーンの7つの行動指針に合致する
- 顧客基点で全てを始める
- 事実に基づき、本質を追求する
- 現状を疑い、変化を起こせ
- 3年で10年分の成長を
- リーダーであり、フォロワーであれ
- 公平で開かれたコミュニケーション
- 向き合う姿勢・やり抜く力
- エンジニアは成長とやりがいと充実を実現できる
※1 スクラムはアジャイルの概念を継承したフレームワークであり、アジャイルは顧客価値に重点を置いている。
アジャイルソフトウェア開発宣言
- プロセスやツールよりも個人との対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
左記の価値を認めながらも、右記のことがらにより価値を置く
価値（XPより）
- 尊敬
- コミュニケーション
- 単純さ
- フィードバック
- 勇気
役割
下記をバイネームで決める
やること
チームビルド
- チーム編成と役割を定義します。（事例：スクラムにおけるチームビルド）
プロダクトバックログを作成する
-
プロダクトバックログとは（リンク先に事例があります）
- タスク
- 作るべきもの
- チームが実行する可能性があるすべてのことを洗い出す
- タスクに必要な情報を揃える
- タスクは見積りができるほどに小さいか
- 成果物があることが完了
- 完了を定義し、チームメンバー内で合意する
- PO - プロダクトオーナーはステークホルダーと合意し優先順位を決める
プランニングポーカーによる見積り
- プランニングポーカーを使う（リンク先に事例があります）
- 相対的な見積り（時間ではない）
- カードまたはツールを使う
- https://plapo.net/register
- ゲストユーザで問題ない
スプリントの計画を立てる
- プロダクトバックログが同ビジョンを達成できるか
- 単位当たりの予定を立てる
- 1週間
- 2週間
- 4週間（1か月）
- ポイントも集計（予実管理）
- 原則的に追加・変更しない
- 各メンバーが集中できる環境を作る
進捗を可視化する
- スクラムボード
- 未着手
- 作業中
- 完了
- バーンダウンチャート
デイリースタンドアップ
- 目的
- 指示をしない
- チームメンバーの自律性を尊重
- 報告の義務もない
- 困っている人を他のメンバーが助ける
- 15分
- 15分過ぎたら改善の余地あり
- 立つ
- 各メンバーが話す
- チームがスプリントを終了するために昨日何をしたか
- チームがスプリントを終了するために今日何をするか
- チームがスプリントを終了するために妨げになっているもの
スプリントレビュー
- 成果を見せる／動くものを見せる
- プロダクトバックログで定義されている完了基準を満たしているかをみる
- ポイントからベロシティを測る
- 個人のベロシティではなくチームのベロシティ
スプリントレトロスペクティブ
- 批判をしない信頼が重要。根底に尊敬がある
- うまくいった点
- もっとうまくできたはずの点
- 次のスプリントで改善できる点は何か
- 助け合い