スクラム開発って最近よく聞くけど、実際どんなイベントを
実施しているの？？実際よくわからない。。。
実際に私のチームが実施しているイベントや注意点をご紹介します
ウォーターフォール開発、アジャイル開発、スクラム開発、、、
さまざまな開発手法を耳にすることがあるかと思います。アジャイル開発ってよく聞くけど、実際にどんなイベントを実施しているんだろう。。。こんなことをTwitterで見たことが何度かあります。
私は現在開発チームのスクラムマスターをしていますので、実際の事例をご紹介しながら
スクラム開発の具体例をご覧頂ければと思います。
この記事で紹介すること
- そもそもスクラム開発って何
- スクラム開発のイベント内容
- イベントの実施例
アジャイル開発とスクラム開発
スクラム開発はアジャイル開発手法の1つです。
まずはアジャイル開発の特徴についてみてきます。
アジャイル開発とは
アジャイル開発の特徴は以下の3つになります。
- 目的達成のためにチームでお互いに協力しながら進める
- 一度に全て作成するのではなく、早い段階から動作する成果物を作成し、修正していく
- ステークホルダーからフィードバックを受け、成果物や計画を柔軟に調整する
というような特徴になります。
アジャイル開発という言葉が生まれたのは2000年代前半です。
従来の開発手法では手戻りや柔軟な修正が難しかったため、アジャイル開発が作成されました。
アジャイル開発では、重要なもの、リスクの高いものに先に取り組み、優先順位をつけて成果の最大化を目指します。
スクラム開発とは
スクラム開発の特徴は以下になります
- 問題点や現状を把握し、見える化しておく
- 重要性、優先度を考慮してプロダクトの成果を最大化する
- 進捗や期待されている成果を達成でいているかを定期的に確認する
- 振り返りを行い、よりよい方法に変更し適応する
が特徴です。あらかじめ定めた期間（スプリント）を何度も繰り返し、成果を最大化を目指していきます。
スクラムには「 5つのイベント、 3つの役割」 がありルールとして定められています。
これらのルールの枠組みの中で、振り返りを通して柔軟に自分達のやり方を開発方法を反映させていきます。
次の章では3つの役割についてみていきましょう。
役割
プロダクトオーナー（PO）
プロダクトオーナーの１番の役割はプロダクトの価値を最大化することです。
プロダクトの責任者であり、1プロダクトにつき1人のプロダクトオーナーが任命されます。
特徴は以下の通りです。
- プロダクトの価値を最大化する
- ステークホルダーとの折衝
- 優先順位の決定
スクラムマスター（SM）
スクラムマスターは、スクラムの理解と実践を推進し、プロジェクトを円滑に進めることに責任を持つ人です。
特徴は以下の通りです。
- スクラムチームの全体が、スクラムとは何かを理解した上で開発を行っているかチェック
- チームが協力しやすい環境にあるか確認しながら、サポートする役
- イベントのファシリテート
チームによってはスクラムマスターはコードを書かない場合もありますが、多くのスタートアップでは人手が足りていないため、スクラムマスターも開発メンバーに含まれている場合が多いかと思います。
私も開発しながらイベントのファシリテートや会議に参加しています。
開発メンバー
多くの方はこの開発メンバーに該当します。開発やテスト、品質向上につとめます。
次の章ではイベント内容と実際にどんなことをしているのかご紹介いたします。
イベント
私が所属するチームでは1スプリントの中で5つのイベントを実施しています。
簡単な図を作成しました。（手作りでデザインセンスなくてごめんなさい。。。）
スプリントプランニングで計画したことをスプリント内で取り組み、実装後は成果物のチェックと振り返りを行います。
あくまで私のチームでの1例です。
スプリントプランニング
スプリントプランニングでは、次回のスプリントでどのタスクに取り組み、どこをゴールとするのか決定します。
ここで確認する項目は以下になります。
- スプリントの完了の定義を決定
- チケットの不明点洗い出し
リファインメント
リファインメントでは、各チケットに対して見積もり、作業の詳細化を行います。
チケットの見積もりですが、人の意見に引っ張られないよう、私のチームではポインティングポーカーを使用しています。各自が見積もったポイントを入力し、全員が入力した段階で他の人の見積もりポイントが確認できます。
画像のようにポイントにずれがある時は議論してタスクのすり合わせを行い、改めてポイントを出し合います。全てのチケットの見積もりと完了の定義が決まれば終わりです。
チケットのポイント算出は個人の性格が出るので、実際に行うと面白いです！
また作業の詳細化は1つの作業が5時間以内になるまで分解します。5時間を超える作業は、そこからさらに分解を実施します。
実装での注意点や開発ルールのドキュメントを一緒に確認しながらチケットのゴールの認識合わせも大切です。
デイリースクラム
デイリースクラムでは以下の項目の共有を行います。
- タスクの進捗
- 詰まっている点
- 勤怠の連絡（この時間は連絡がつかない等）
私のチームではデイリースクラムは必ず15分以内に終わることをルールとしています。
詰まっている点の共有で15分を超えるようなら該当者のみが残り、残りのメンバーは各自の作業に戻ります。
スプリントレビュー
スプリントレビューでは、以下の項目を実施します。
- ステークホルダーに成果物の共有
- 技術的に知っておきたい箇所の共有
- 作成したドキュメントの説明
- 計画に対してどれだけ過不足があったか
レトロスペクティブ
レトロスペクティブでは、スプリントで発生したことや、考えたことを共有します。
私のチームは以下の4ポイントを書き出し、共有とactionのすり合わせまでを完了させます。
具体例を記載します。
| 見積もりと実態に乖離があったチケット | motto(反省点) | action(改善) | good(良かった点) | |
| member1 | チケット番号 | |||
| member2 | 該当のドキュメントがなく、見積もり内に未達だった | 該当のドキュメントを作成 | ||
| member3 | 既存のバグを解消できた |
決定したことは次のスプリントから反映できる事が、柔軟に対応できるのがスクラムの利点です。
以上、イベントのご紹介でした。参考までに私のチームのイベントのみ記載されたカレンダーの1例です。スプリントは金曜スタートとしています。（デイリースクラムは本来15分ですが、枠が小さすぎたため1時間にして見えるようにしている点だけご了承ください。）
ファシリテイトで注意している点
スクラムマスターとして、イベントのファシリテートを行うにあたって、注意している点をご紹介します。必要な能力等はいろいろあると思いますが、能力ではなく具体的な行動としてご紹介します。
- 必ず画面共有しながら認識相違がないかその場で確認する
- 議事録は必ず残し、チームの財産とする
- 「誰が」「いつまでに」「何をするのか」を明確にする
- 個人の失敗は仕組みでカバーできる案を考える
基本的にリモートでの会議となりますが、週に1度は出勤日を合わせて出社し、ランチ等でコミュニケーションを取ることも大切にしています。
最後に
ここまで
- アジャイル開発とスクラム開発とは
- 3つの役割とは
- 5つのイベント
- 私のチームの事例
- ファシリテートで意識している点
をご紹介してきました。
スクラム開発は会社によって採用しているイベントが異なれば、定義がちがうこともあるので、ここに記載したことは1例として捉えていただきたいです。
最後にスクラム開発を学習した際に読んだ書籍をご紹介します。
スクラム開発の概要、実施例を漫画風にさくさく勉強できます。
スクラムマスターの必要性や、注意点等が詳細に記載されています。
最後まで読んでいただきた方で、おすすめの方法や利用しているツールがあればぜひTwitterまでご連絡ください。
ありがとうございました。
コメント