スクラム実践ナビ

3.開発（スプリント）

スプリント

スプリントとは、スクラムチームが一定量の作業を完了させる際の、短く区切られた期間を指します。期間を細かくタイムボックスに区切り、その中で計画し、設計・実装・検証を行い、フィードバックを受けてプロダクトを見直し完成度を高めていく、という繰り返しの１サイクルです。

各種イベントのタイムボックスをご紹介します（Scrum Guideから引用）。

スプリント期間別スクラムイベントのタイムボックス占率
スプリント1週間2週間4週間85%
スプリントプランニング最大2時間最大4時間最大8時間6%
デイリースクラム1日15分4%
スプリントレビュー最大1時間最大2時間最大4時間3%
レトロスペクティブ最大1時間最大1.5時間最大3時間2%

スプリントプランニング

スプリントの開始にあたり、当該スプリントで実現する機能をスクラムチーム全員で共有し、開発チームでタスクに分割、詳細見積りを行います。

大まかな流れを解説します。

プランニングの準備を行う

プロダクトオーナーが優先度の高いプロダクトバックログを着手可能（Ready）状態にします。

目標とスコープを決める

  1. プロダクトオーナーが当該スプリントで実現したい機能と、その達成に必要なプロダクトバックログを開発チームに説明します。
  2. 開発チームは1スプリント内で完成させられそうなプロダクトバックログのアイテム数を見積もります。
  3. 当スプリントにて開発するバックログアイテムについて、プロダクトオーナーと開発チームが合意してスコープを確定させます。
  4. スプリントゴールを設定します。

開発作業計画を立てる

スプリントで開発するバックログアイテムと、スプリントゴールが決まったのちに、開発チームはバックログアイテムを完成させるのに必要なタスクを洗い出し、スプリントでの計画を行います。当該スプリントで対応するバックログアイテムがタスクにまで分解されたものをスプリントバックログと言います。

バックログアイテムの実装

開発の進め方

スプリントバックログアイテムのうち、優先順位の高いものにメンバーのリソースを集中させます。
また、リリース直前に技術的な問題に直面する、というリスクを回避するため、プロダクトのリリース有無にかかわらず、スプリントごとにリリース可能な状態にまで開発します。性能テストや脆弱性テストが必要な場合には、リリース遅延のリスク低減のために、あらかじめ作業計画時に明確化します。

【リソースの集中】
全メンバーがそれぞれの担当機能（バックログアイテム）を、各々一斉に着手し同時に設計、実装を進めた場合、スプリントレビュー時に動くソフトウェアを1つもレビューできない、となるリスクを回避するためです。

開発中のコミュニケーション

プロダクトオーナーと開発チームは直接コミュニケーションを行うことが理想的であり、同じ部屋での作業が望ましいです。物理的な距離がある場合でも、オンライン会議などでチームの透明化や意見の言いやすい雰囲気を実現させましょう。

設計

その時点でわかっている要件の範囲で必要十分な設計を行い、開発を繰り返す中でソフトウェアと設計の改善を並行して進めます。要件の変更に素早く対応するため、変更時のソースコードの影響範囲が明確で限定的になるようなアーキテクチャを考える必要があります。

サーバー構築時の設計では、想定される初期のユーザーに過不足なく対応でき、その後のリソースの変化に柔軟に対応できるようオープンクラウドサービスの利用などが効果的です。

コーディング

短期間で動作可能なソフトウェアを作るためには生産性の向上が求められます。

アジャイル開発で用いられることの多いの技術を一部ご紹介します。

技術概要
オブジェクト指向オブジェクト指向によるプログラミングは再利用性が高く、読み易いコードを書くことができます。（動作（プログラムの振る舞い）とデータが1つの単位で定義されているカプセル化によりデータの更新やリセットのタイミングが分かりやすいです）
デザインパターンオブジェクト指向で開発するクラスの再利用性を高めることができる23個の設計パターンです。プログラムを組み上げる際に動かすことだけを考えるのではなく、作る際の効率、作った後の保守のしやすさ、拡張のしやすさを考えやすくなります。
テスト駆動開発（TDD）XP（eXtreme Programming）のプラクティスのひとつです。テストを先に作成し、その後に処理ロジックを作ります。（テストを考えるには、まずインターフェイスの設計を行い、その後内部（処理ロジック）を作成します）
一般的にはアプリケーションと同量のテストコードを書くため、コーディング作業自体では時間がかかりますが、テスト実行までを考慮すると、テストコードが同時に出来上がったほうが効率的になる場合が多いです。
リファクタリング外部から見た振る舞いを変えず、理解を容易にするようソフトウェアの内部構造やコードをきれいにして、機能追加などの変更に迅速に対処できるようにします。
ペアプログラミングXP（eXtreme Programming）のプラクティスのひとつ。1人がドライバーとしてキーボード入力し、もう1人がナビゲーターとしてロジックなどのアドバイスを行う開発手法です。フェーズ単位で分業化され、ドキュメントが整備されているウォーターフォール開発では非効率と捉えられがちですが、プログラムを作成しながら設計も行うアジャイル開発ではプログラム品質やテスト効率の向上に加え、スキル共有にも寄与することが多いです。
マイクロサービスシステムのアーキテクチャの柔軟な構成であるマイクロサービスは、プログラムをサービスという単位で分割し、ある役割を持った単独で完結できる機能を持つソフトウェアのコンポーネントです。各サービスは疎結合で、サービス感の連携はAPIを介して行います。機能単位で他との依存度が低く、小さなプログラムを動かしながら開発し、評価し、サービスインするアジャイル開発はマイクロサービスと相性が良いです。

他システムとの連携

他のソフトウェアからの利用を想定したオープンなAPIで公開されていることが理想的です。また、ウォーターフォール開発で実装される機能との連携を予定している場合、ソフトウェアの完成タイミングが合わないことでリリースに影響しないよう、モックなどを活用して対策し、実連携はリリース前の総合的なテストで担保する、などの工夫が必要です。

テスト

ソースコードを書いたらすぐにテストを行うことで、問題の原因箇所の範囲が小さくなり、原因の特定や修正にかかる時間を抑えることができます。スプリントバックログのタスクの粒度を1日以下に設定できていれば、1回にテストするソースコードの規模は最大でも1日分となります。
ソースコードはこまめにマージさせ、少しずつコーディングとテストを繰り返し開発することに学び慣れることが重要です。また、テストコードの書き方を学習する時間を1〜数時間確保し、代表で学んだ人がサポートしてチームで共有するなどの対策を考えることも必要です。

デイリースクラム

毎日、同じ時間に同じ場所で行う、最大で長さ15分のミーティングです。スプリントゴールやバックログの進捗、チームの直面している課題などの共有を行い、次の24時間で実施すべき作業計画を明確にすることが目的です。
開発チームからスクラムマスターへの報告イベントではなく、スプリントゴールの達成に向けてチームで状況を共有する場です。進捗状況の共有のためタスクボード（スクラムボード）やバーンダウンチャート・バーンアップチャートを使用します。
その場でできない課題の解決や計画の見直しは別枠での開催にします。

ドキュメントの作成

アジャイルソフトウェア開発宣言にある通り『包括的なドキュメントよりも動くソフトウェアを優先』しますが、必要になるものは作成します。開発チームやプロダクトオーナーが理解のずれを防いだり共有を促進する目的などで必要と判断したドキュメントはバックログに追加し優先順位をつけて作成します。

作成されるドキュメントの例をご紹介します。

対外的に必要なドキュメント備考
顧客への納品物として必要なもの契約上必要なもの、ベンダーの規定で必要なもの
引き継ぎのために必要なものプロジェクトの要員追加・変更が想定される場合など
連携システム向けに作成するものAPIの仕様書など
報告のために作成するもの品質分析のレポート、進捗報告のレポートなど

プロジェクト管理

4つの管理要素が存在するのでご紹介します。

管理 概要
品質管理 ・要件定義や設計工程での品質管理は行わず、実装に対するテストで品質を担保します。
・品質管理にはブランチを活用します。ブランチごとにパスすべきテスト要件を整理し、必要なテストをパスしたソースコードだけがブランチにマージされるようにします。
・ソースコードに手を入れるたびにテストが必要なため、テストコードを作成しテストを自動化します。
進捗管理 プロジェクトの進捗管理 ・プロジェクト全体計画（リリースプランニング）とプロダクトバックログ、開発チームのベロシティを使用してリリースバーンダウンチャートを作成し、進捗の透明化を図ります（直近のバックログアイテムしか見積りされていない場合には、全体の見通しは立ちません）
スプリントの進捗管理 ・デイリースクラムにてチームで状況を共有し、チームで進捗を管理します。
・進捗状況を可視化するためのツールとしてタスクボード（スクラムボード）やバーンダウンチャート・バーンアップチャートを使用することが多いです。
変更管理 ・要件は優先順位も含めてプロダクトオーナーの管理するプロダクトバックログに記載されており、仕様の変更やスプリントレビューでのフィードバックもバックログリファインメントにて反映され、以降のスプリントで対応されます。
・スプリント期間中の仕様変更については、プロダクトオーナーと開発チームが相談し、当該スプリントで吸収するのか（吸収する場合には他のスプリントバックログアイテムに影響を与えないのか）、あるいは以降のスプリントのタスクとしてプロダクトバックログに管理するのかを決めます。
課題管理 ・デイリースクラムでチーム内の課題や阻害要因の共有を行います。
・スプリント期間中に発生した課題は、プロダクトオーナーと開発チームが相談し、当該スプリントで吸収するのか（吸収する場合には他のスプリントバックログアイテムに影響を与えないのか）、あるいは以降のスプリントのタスクとしてプロダクトバックログに管理するのかを決めます。

【品質管理】
スプリントでソフトウェアを作っていくアジャイル開発では一度に作るソースコードの行数が少なく、信頼できるテスト密度やバグ密度の取得が難しいため、統計的に信頼できる数値の取得が難しいです。また品質要件と開発スピードはある程度相反する要素でもあり、相互のバランスをとることが重要です。

【スプリントの進捗報告】
ステークホルダーへの報告が必要な場合、チーム内と同様の情報で目的を果たせないか検討し、どうしても報告書などが必要になる場合は、プロダクトオーナーが進捗の報告会議に出席しチームの状況をレポートします。