Tech

入門スクラム〜スクラムフレームワーク

投稿日:2019年7月31日 更新日:

はじめに

こんにちは。カイザーです。
今回はプロジェクト開発手法の1つである「スクラム開発」のフレームワークについて、まとめてみました。

スクラムの特徴

シンプルなフレームワークであること

スクラムのフレームワークはシンプルで軽量です。ルールブックと呼ばれる「スクラムガイド」はたった17ページしかありません。しかし、スクラムは「フレームワーク」であり、問題を簡単にするものではありません。
難しい課題は、難しく、様々なケースに当てはめて、柔軟にスクラムを考える必要があります。そのため「習得は困難」とされています。

素早い反復を繰り返すこと

スクラムでは、フィードバックループを短期間で反復させながら、開発を進めます。そうすることにより、素早いフィードバックを得ることができます。また、問題があったとしても小さいうちに迅速に対応してしまうのも、スクラムの特徴です。

検査・適応・透明性

スクラムでは、様々な事がらについて、検査・適応を行います。例えば、スプリントレビューではそのスプリントで完成したプロダクトを検査します。その結果は、今後の開発に適応されていきます。(スプリントレビュー)
また、デイリースクラムも検査と適応の場です。毎朝、メンバーの状況共有を通じて検査し、スプリントゴールを達成するための障壁がある場合は、チームでそれを解消するために適応します。
さらに、スクラムでは、プロダクトだけでなく、そのプロセスに対しても、検査と適応を行います。(スプリントレトロスペクティブ)

こうした検査・適応をうまく行うために、「透明性」を心がける必要があります。つまり、重要な情報には、プロジェクトに関わる全員がアクセスできるようにし、誰もがそれについて確認したり、議論したり出来るようにしなければなりません。

また、スクラムでは「分からないことを受け入れる」としており、このような「検査・適応」を繰り返すことにより、チームが学習し、より良いプロダクト(価値)を考えて実践できるようになったり、より良いやり方を考えて実践できるようになるとしています。

スクラムの役割

スクラムでは、「プロダクトオーナー」「スクラムマスター」「開発チーム」が1つのスクラムチームとなります。スクラムチームは、自己組織化し、機能横断的であると言われています。

自己組織化チームは、作業のやり方や順番について、最善策を自ら考え選択します。いちいち、チーム外から指示を受ける訳ではなく、能動的なチームである必要があるのです。

機能横断的チームは、この1つのスクラムチームで、プロダクトを「完成」させることのできる能力を持っている必要があります。

また、「プロダクトオーナー」「スクラムマスター」「開発チーム」は役割であり、役職ではありません。そこにピラミッドのような上下関係はなく、お互いの役割を達成するために、各々のが責任、協力してゴールを達成します。

プロダクトオーナー

プロダクトバックログの管理に責任を持つ1人の人間であるとされています。
プロダクトバックログは、簡単に言うと「実現したいことリスト」です。
詳細は後ほど説明します。
プロダクトオーナーの役割は以下です。

  • 開発する機能やその優先順位を決める。
  • 最も価値の高い作業から行われるようにする。
  • どのようなプロダクトを開発すべきか、明確なビジョンを持っている
  • さらに、明確なビジョンを関係者全員に伝える。

こうした役割を達成するため、プロダクトバックログの管理に責任を持ちます。

スクラムマスター

スクラムマスターは、スクラムの価値・原則・学びを全員に浸透させる手助けをします。
そのため、プロジェクトリーダーのように、開発するプロダクトの方向性を決めたり、コントロールしたりはしません。
あくまで、スクラムを全員に浸透させ、円滑にスクラムが進むように、手助けするのが役割です。

  • スクラムチームのコーチとなり、スクラムのプロセスでリーダーシップを発揮する。
  • チームに課題や障害があるとき、迅速に解決できるようにファシリテートする。
  • 外部からの妨害からチームを守り、チームが価値を生み出すことに集中できるようにする。

開発チーム

実際に、プロダクトを設計・開発・テストできるチームです。

  • 自己組織化し、プロダクトオーナーの要求を達成する方法を、自ら決定しなければならない。
  • 機能横断的で、エンジニア・プログラマ・UIデザイナなどといった、プロダクトを開発するのに必要な人たちが、1つの開発チームとなります。
  • 1つの開発チームは、5人〜9人だと言われています。
    • 大きなプロジェクトでは、小さな開発チームを複数持ちます。
    • ただし、その場合でも、各チームは機能横断的なチームメンバーとなっている必要があります。

プロダクトバックログ

プロダクトバックログは、一言で言うと「実現したい要求リスト」です。
最終的には、プロダクトオーナーが責任を持って管理します。
また、プロダクトバックログの要求の一つひとつを「プロダクトバックログアイテム」と呼びます。

  • 優先順位の高い順番に並び替えられている。
  • プロダクトバックログには、新規機能や既存機能への改修のほか、バグ改修、保守作業なども含まれます。
  • プロダクトバックログは誰が追加しても良いですが、最終的にはプロダクトオーナーが責任を持ちます。
  • プロダクトバックログアイテムに対し、開発チームが見積もりを行います。
  • プロダクトバックログは随時更新します。

スクラムのイベント・活動

スプリント

スクラムでの開発は、短期間にタイムボックス化された反復を繰り返して行われます。これを「スプリント」と呼びます。

  • 期間は、最長1ヶ月。
  • 期間は、毎回同じでなければならない。

期間が短期間で、かつ固定化されているので、ウォーターフォールと比較して、計画を立てるのが容易になります。

スプリント計画会議

スプリントの初日に実施し、そのスプリントでの作業を計画します。
これにも時間制限があり、スプリントが2週間の場合、最大で4時間で終わらせる必要があります。

  • チーム全員が参加する。
  • プロダクトバックログの中から、スプリントに当てはまる分だけ、最も優先順位の高いアイテムを選びます。
    • チームが少し余力を持った状態とすべきと言われています。あまりカツカツになると、チームの作業効率が落ちるためです。「持続して」開発できる量にする必要があります。
  • 選んだプロダクトバックログに対し、「どのように」完成させるか決め、タスクに分解します。

デイリースクラム

スプリント計画会議で、そのスプリントで何をどのようにやるか合意できたら、スプリントの実施がスタートします。
スプリントの実施中、チームの状況を検証・適応するための機会が、デイリースクラムです。

  • 毎日同じ時刻に15分以内で行う。
  • 開発チームのためのミーティングである。
  • 開発チームメンバー全員が「昨日何をやったか」「今日何をやるか」「達成を妨げる障壁」を共有します。
  • デイリースクラムは問題解決の場ではないため、必要に応じて、必要なメンバーだけで別途ミーティングする。

スプリントの実施

スプリント計画会議で計画し、合意したアイテムについて、開発チームはスプリント内の「完成」を目指して開発を進めます。

  • スプリントの実施中に、開発チームは作業を「完成」させる必要があります。
  • 完成の定義は様々ですが、一般的なソフトウェア開発では、「設計・開発・テスト・ドキュメンテーションが完了していること」とすることが多いそうです。
  • 短いスプリントですが、テストはフルで行う必要があります。なぜなら、「完成」とは開発チームが、開発した機能を自信を持ってリリースできる状態にしておく必要があるためです。

スプリントレビュー

「完成」したプロダクトを、関係者全員にデモし、プロダクトの検査を行う機会です。
これにも時間制限があり、スプリントが2週間の場合、最大で2時間で終わらせる必要があります。

自分たちの開発したプロダクトに対して、検査と適応を行うスケジュール化された機会です。
これを、スプリント毎に必ず行うことで、スクラムチームは頻繁なフィードバックを得ることができます。

  • スプリントでの成果についてデモした上で話し合う。(検証)
  • NGであったり、更なる追加要望があれば、プロダクトバックログへの適応を行う。
  • 顧客やステークホルダーは、スプリントでの成果に追いつき、フィードバックをすることができる。
  • スクラムチームは、フィードバックを受けることで、自分たちの開発したプロダクトの正しい方向性や、価値について、より深く知ることができる。

スプリントレトロスペクティブ

スプリントの1番最後のイベントです。いわゆる「振り返り」です。スクラムチームやスクラムのやり方を検査し、次のスプリントへの適応をする機会です。
これにも時間制限があり、スプリントが2週間の場合、最大1時間半で終わらせる必要があります。

  • 良かった点、うまくいかなかった点を議論します。
  • その中から、改善点を見つけ、次のスプリントで実際に改善する項目を決めます。
  • スクラムでは、継続的な改善が大切だと言われていて、必ずスプリントの最後に振り返ることで、次のスプリントで「もっとうまくやる」ために、更なる高みを目指します。

ここまで終わったら、1スプリント終了です。翌日からは、1番初めに戻り、スプリント計画会議からスタートです。

さいごに

スクラムのフレームワークはシンプルですが、実際には様々なシチュエーションに応じて、柔軟に対応する必要があると思います。
スクラムガイドをルールとしつつ、各スプリントで、スクラムのやり方を良くしていきたいものですね。

おすすめ書籍

アジャイルサムライ−達人開発者への道− SCRUM BOOT CAMP THE BOOK エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection) カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

page_footer_300rect




page_footer_300rect




-Tech
-, ,

執筆者:


comment

メールアドレスが公開されることはありません。

CAPTCHA


関連記事

ReactNative画面遷移

1 はじめに2 React Navigation3 React Navigationのインストール4 実装5 さいごに6 おすすめ書籍 はじめに こんにちはnukkyです。 ブログを書きながらアプリを ...

ReactNativeデータ永続化

1 はじめに2 データ永続化の方法3 AsyncStorage4 react-native-async-storage4.1 インストール4.2 実装5 Realm5.1 インストール5.2 redu ...

C# マルチキャストデリゲートの備忘録

1 はじめに2 C#のデリゲートについて2.1 デリゲートの定義3 マルチキャストデリゲートについて3.1 追加方法3.2 削除方法4 さいごに5 おすすめ書籍 はじめに こんにちはsuzukiです。 ...

ReactNative開発のスタート、シミュレータでのデバッグ

1 はじめに2 改めてシミュレータの起動3 表示内容を変更してみる3.1 App.js3.2 表示テキストの変更3.3 シミュレータの更新「command + R」4 デバッグメニュー4.1 Real ...

icon

ドキュメント作成の技術「テクニカルライティング」とは

1 はじめに2 テクニカルライティングとは3 少しでも分かりやすく、簡潔にする3.1 一文一義3.2 長くしすぎない、繋げすぎない3.3 長さの目安は?4 伝わりやすく書く4.1 まず主題を書く4.2 ...

フォロー

follow us in feedly

page_side_300rect

2019年7月
« 6月 8月 »
 123456
78910111213
14151617181920
21222324252627
28293031 

アプリ情報

私たちは無料アプリもリリースしています、ぜひご覧ください。 下記のアイコンから無料でダウンロードできます。