はじめに
以前、書籍「スクラム実践入門 成果を生み出すアジャイルな開発プロセス」を読んだ際のメモ。
今さら感はあるが、要点のまとめとして現在スクラム開発現場で仕事をしている、またはこれから導入しようとしている方々のちょっとした参考にでもなればと思い投稿する。
導入
- ラグビーのスクラムに由来
- アジャイル開発手法の一つで、多くの開発現場で採用されてきている
※アジャイルとは「すばやい」「俊敏な」という意味で、反復 (イテレーション) と呼ばれる短い開発期間単位を採用すること - ソフトウェア開発の目的および手段の不確実性に対応するもの
手法と役割
- 手法：スプリント、スプリントレビュー、スプリントレトロスペクティブ
- 役割：プロダクトオーナー(PO)、スクラムマスター(SM)
- POは課題達成志向リーダー、SMは人間関係志向リーダー
自己組織化
- スクラムチームはスクラムイベントを通じて自己組織化していく
- 3つのロール – PO、SM、開発チーム。上下関係はない
5つのスクラムイベント
- スプリント … ステップバイステップでプロダクトとスクラムチームを成長させる
- スプリントプランニング …スプリントの計画を作る。リファインメント
- デイリースクラム …日々の進捗、予定、問題を共有する
- スプリントレビュー …仕事の成果を確認する
- スプリントレトロスペクティブ …仕事の進め方を改善する
スクラムにおける作成物
- プロダクトバックログ …何を実現するかの一覧
- スプリントバックログ …今何を行うかの一覧
- ToDo(まだ誰も手をつけていないもの)
- Doing(誰かが着手しているもの)
- Done(完了したもの)
- インクリメント …スプリントで作ったもの
プラクティス
-
パターン
-
状況(コンテキスト)
-
問題
-
空気(フォース)
-
解決
-
インセプションデッキ …10の課題でプロジェクトを導く
-
リーンキャンバス …プロダクトを1枚で定義する
-
ユーザストーリー …ユーザ視点で要求を簡潔に記述する
-
良いユーザストーリーを作るには'INVEST'が必要
-
Independent：独立している
-
Negotiable：調整可能である
-
Valuable：ビジネス価値がある
-
Estimable：見積もり可能である
-
Small：手ごろなサイズである
-
Testable：テストが可能である
-
ユーザストーリーマッピング …ユーザ体験を時間軸で整理する
-
プランニングポーカー …開発チーム全員で見積もりをする
-
スパイク …技術的不確実性を取り除く(ための事前調査)
-
バーンダウンチャート …プロジェクトの進捗を見える化する
-
パーキングロット …アイデアを一時退避する。ファシリテーションテクニックの一つ
-
KPT …レトロスペクティブを効果的に実施する
-
Keep：良かったことや続けたいこと
-
Problem：困ったことや改善したいこと
-
Try：良かったことを伸ばす案や困ったことを解消する案
-
技術的負債の返済
-
継続的なインテグレーション
スクラム導入事例と目的
- 作業の属人化の回避
- 割り込みタスクをある程度は許容する
- コミュニケーション不全による信頼低下を避けるべき。企画運営ー開発間などのゴールや目的意識の共有が必要
- プロダクトバックログおよびスクラムチームの分割
問題と解決策
- 開発チームの強み弱みの可視化、スキルの底上げ
- スラクムへの理解度を上げる勉強会を開催する
- 意欲がわかない理由を明らかにする
- スクラムイベントの参加者票を作成 ステークホルダー参加の推奨・非推奨
役割別の問題
- プロダクトオーナーが抱える問題
- プロダクトオーナーと権限を有するステークホルダーの権限すり合わせまたは委譲
- 開発チームが抱える問題
- サポートチームをつける そのサポートチームにもスクラムを適用
- インクリメントの受け入れ条件を作る
- 外側のチームを巻き込む
- スクラムマスターが抱える問題
- 「GROWモデル」でスクラム導入の目的を整理する
- Goal(目標)、Reality(現状)、Resources(資源)、Options(選択肢)、Will(意思)
ケーススタディ
- スプリントプランニング(ストーリーポイント)は1日1人あたり5~6時間程度が多いようだ
- 個別の依頼は即答を避ける
- スプリントレビューはただの進捗共有会ではない アイスブレークのように場を和らげた上で行った方が緊張をほぐし、積極的に意見を出したり、参加したりしてもらうのに効果的→お菓子を食べながらレビュー
- グラウンドルール、ワーキングアグリーメントを作る
最後に
スクラム開発現場を開発メンバー(Tリーダー)として2年ほど経験した感想には以下のようなことが挙げられる。
・スクラムという体裁(型)だけ導入しても意味はなく、理解を持ってある程度専任的に取り回しのできる舵取り/牽引役もしくは評価役が必要
・「自己組織化を促す」という点では有効かつ効果的なシステム
・プロジェクト自体がイテレーションを回すサイクルに向いているかの判定をどこかでするべき
大切なのは「自ら課題を発見し、素早く効果を上げるプロダクトづくり」ができるか否かだ。そのためには手法そのものに固執する必要はなく、仕組みのいいところだけを取り入れつつ旧来の手法に戻る、または新たな方法を模索してもいいように思う。