スクラム開発とは？

概要

アジャイル開発の開発手法の一つです
アジャイル開発宣言内容を実現する為の開発方法です
共同作業をサポートするフレームワークです
継続的に改善するチームの作成が目的です

名前の由来

スクラムとはラグビー用語で集団でぶつかり合う際のフォーメーションの事で、
勝利の為にチーム全体が協力し合い力を合わせてボールを取ります。
ラグビーのように集団が協力し合い一体となる姿が似ているからとか。

前提

スプリント開発を理解、採用する上で一番重要な事は、
【アジャイル開発宣言】を理解し
その考えに共感できるかという事です。
その考えに賛同できる場合は採用すべきです。

アジャイルソフトウエア開発宣言
4つの価値

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
・【プロセスやツール】よりも【個人と対話】を、
・【包括的なドキュメント】よりも【動くソフトウェア】を、
・【契約交渉】よりも【顧客との協調】を、
・【計画に従うことより】も【変化への対応】を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

12の原則

開発体制

プロダクトオーナー
スクラムマスター
開発チーム

開発体制の役割

プロダクトオーナー

プロダクトの責任者である
プロダクトオーナーは１人
顧客が求める価値を理解する
価値を提供できるよう、作業の優先順位をつける
プロダクトバックログの管理者である
価値を提供する為に利害関係者との対話を行う
スプリントの終了権限を持つ

スクラムマスター

プロダクトオーナーのサポートを行う
開発チームのサポートを行う
外部からの不要な干渉からチームを守る
スクラムが正しく実践されるように促す

開発チーム

開発を行う
成果物を完成させる
１チームは３～９人で構成する

※多いい場合は新たにチームを作ります。

##スクラム開発の流れ
1.開発決定
2.役割を決める
3.スプリント0（準備期間
4.スプリント1（開発開始
5.スプリントの終了

開発決定

開発が決定したら開発メンバーを集めます。

役割を決める

メンバーに以下の役割を与えます。

プロダクトオーナー
チームメンバー
スクラムマスター

スプリント0（準備期間

開発開始前の助走期間

チームの自己紹介
スクラムの勉強
スプリントの認識合わせ
ビジョンの明確化
要件定義
全体計画
プロダクトバックログ作成
開発環境の構築
必要技術スキルの勉強会

※準備不足で進めてはいけない

初期の要件を収集したり、アーキテクチャを検討し、
要件定義や設計などはスプリント0で行います。

スプリント1からは動作するソフトウェアという成果物が完了条件です。
その為、ふわふわしている状態ではスプリントが空回りし
スクラムが失敗します。

ラグビーでいうと
#####スプリント0は試合前
練習をして体作りや、戦術を学ぶ準備期間です。
#####スプリント1は試合
【１スプリント】は【１試合分】です。
試合に勝てるように課題に対して戦術を組み、
チームで協力して勝利します。
しかし試合前に準備を怠れば勝つことは難しいでしょう。

#####スプリント毎に成長するチーム
1試合毎にチームは色々な経験をし成長するでしょう。
フレームワークは正しく利用することでチームが成長し、
価値あるプロダクトを生み出します。

スプリント1（開発開始

スプリントとは１、２週間単位で行う成果物の開発期間のことです。
スプリント期間中にチームで協力し、成果物を完成させます。
以下の手順で作業を行います。

0.プロダクトバックログ
1.スプリントプランニング
2.デイリースクラムミーティング
3.開発作業
4.スプリントレビュー
5.レトロスペクティブ
6.プロダクトバックログリファインメント

0.プロダクトバックログ

プロダクトオーナーが開発チームが行う作業に優先順位を付けてた物です
優先順位は機能や改善要素などがあります
利害関係者全員が現在の状況を把握できるようにします

プロダクトオーナーの優先順位設定に影響する要素

顧客の優先事項
課題の緊急度
実装の相対的な難易度
作業項目間の共生関係 (A を先に完了すると B が容易になるなど)

※チームを円滑に回す為にも全員が
　優先順位の付け方について理解する必要があると考えます。

1.スプリントプランニング

スプリントバックログを作成する事が目的であり、
その為の工程です。

#####スプリントバックログとは、
プロダクトバックログから優先順位の高いタスクを抜き出します。
それを実現する為に具体的なタスクに落とし込み、見える化した
タスクの事です。

プロダクトバックログからこのスプリントで実装する機能を選ぶ
優先順位の高い機能から選択
開発チームが使える時間の確認
仕様書の見直し(仕様の変更はここで吸収する。)
タスク分割 → 各詳細仕様の確認
各タスクのスプリントバックログ作成
開発メンバーへのタスク割り当て

※重要なのはチームで達成できるという事です。
チーム全体で協力し合い、チームで終わらせます。

2.デイリースクラムミーティング

スプリントゴールを達成するためにうまく進んでいるかを確認し、再計画します。

全員の現状報告
スケージュール確認
問題がないかチーム全員が確認
進捗の確認
確認したいことを質問
問題可決の為のMTGの依頼
作業遅れによるフォローの検討

重要なのはスプリントをチームで達成する為に現状を確認を行い対処します。

3.開発作業

自分担当しているタスクを完成させ、成果物を提出することを求められます
また、チームでスプリントを完成させる為に行動する事が求められます

4.スプリントレビュー

実装した機能についてレビューを行います。
スプリントバックログの基準を満たしているかどうかをポイントに評価する。
スプリント最終日に行われます。

スプリントレビューは、プロダクトオーナー、スクラムマスター、開発チーム、利害関係者で行われる会議です。チームはスプリントで作成した成果物のデモを行い、
スプリントバックログの基準を満たしている否かをを決定します。

スプリントレビューの目的は、チームが顧客と利害関係者に達成した成果物を見せる事です。

5.レトロスペクティブ

スプリントの振り返りMTGの事です。
チームの問題点や良いところを探し、
次の活動の改善や継続的に取り組む事項について合意し
チームを改善します。
振り返り法としてKPT法などがあります。

重要なことは
・非難をしない文化
・責任を追及しない
・問題点への早急な取り組み

6.プロダクトバックログリファインメント（PBR）

プロダクトバックログアイテムを明確化・詳細化することです。
つまり見直しです。
これは非常に重要な工程で、
スプリントプランニングが始まる前には必要な分を着手可能にする必要があります。

プロダクトバックログに更新・追加・削除等があった場合は、その内容を共有します。
中長期のビジョンや目標もこの場で語りあいます。

スプリントの終了

スプリントが完了次第、次のスプリントへ移行しこれが繰り替えされます。
続ける必要がなくなった場合にスプリントは終了されます。
また、緊急事態によりスプリントを続けることができなくなった場合も同様に終了されます。
スプリントの終了はプロジェクトオーナーのみが行えます。

以上。