スプリントはスクラム(アジャイル開発プロセス)における重要な概念です。スプリントとは、特定のユーザーストーリーを完了および確認しなければならない一定期間を指します。スクラムアプローチにより、ソフトウェア開発プロジェクト全体を通じて、継続的かつ頻繁に実行可能なソフトウェア機能を提供することが保証されます。
スプリントタスクボードとは何か?
スプリントタスクボックスはタイムボックスです。各スプリントには開始日と終了日があり、その期間中に選択されたユーザーストーリーの完了および確認が求められます。以下の図は、スプリントの主要な要素を示しており、ユーザーストーリーの集合、関与するスクラムメンバー、作業の割り当て、期間および終了日(右上隅)を含んでいます。

スプリントの開始時点で、プロダクトオーナー、ステークホルダー、開発チームが一同に集まり、優先順位を付け、スプリント内で達成するユーザーストーリーを選定します。異なる関係者にはプロジェクトやプロジェクトスケジュールに関して異なる好み、配慮、懸念があるため、会議の目的は、参加者全員が互いの意見を聞き、理解する機会を提供し、全員が合意できるユーザーストーリーのセットを導き出すことです。
スプリント期間
品質の高い作業を迅速に提供することは、ソフトウェアチームがアジャイル開発手法を採用したい理由の一つです。したがって、スプリント期間について万能の選択肢があるわけではありませんが、期間はできるだけ短い方が良いと一般的に合意されています。しかし、どれほど短くすべきでしょうか?
長期間のスプリントは好ましくありませんが、不自然に短いスプリント期間は、開発チームが重要な作業を完了する意欲を低下させたり、納品物の品質が悪くなる原因にもなります。
したがって、スプリント期間の選定は、プロダクトオーナー、スクラムマスター、データベースデザイナー、プログラマー、UXデザイナー、テスト担当者、アナリストなど、チーム全体の議論の結果です。しかし最終的には誰かが決定しなければなりません。その瞬間、スクラムマスターが通常答えを出すことになります。
伝統的にスプリントは3週間から1ヶ月程度ですが、近年では2週間のスプリントで成功しているチームが増えてきています。結局のところ、スプリント期間に固定された選択肢はありません。良いスクラムマスターは、スプリント期間を決定する上で協調性とファシリテーションのスキルを持ち、予定通りに作業が完了するようにします。以下は、スクラムマスターが検討する可能性のある要因です:
- 合意されたプロジェクトスケジュール
- 顧客/ステークホルダー/プロダクトオーナーの可用性(潜在的な疑問を明確化できる人)
- 顧客の働き方文化
- スクラムチームの能力
- スクラム経験
チームが合意に達した後は、今後のすべてのスプリントが同じスプリント期間を維持し、スプリントごとに頻繁に変更することはありません。しかし、スクラムチームがスプリントの効果性を継続的に検討し、全員にとって最適なスプリント期間を見つけることは良い実践です。
スプリント内の作業(ユーザーストーリー)の確認
スプリントが開始されると、開発活動はユーザーストーリーを中心に展開され、スプリントが進むにつれてより多くのユーザーストーリーが実装されていきます。しかし、ユーザーストーリーの完全な実装は物語の終わりではありません。まだ重要なステップが残っています——確認です。
ユーザーストーリーを確認するとは、実装された機能を試して、それが期待どおりに実装されたかどうかを判断することです。判断は、ユーザーストーリーを詳細化する際に設定された基準、すなわち確認項目の形で記述されたものに基づいて行うべきです。確認の際、プロダクトオーナーは実装された作業をテストできるテスト環境またはデバイスが提供されます。プロダクトオーナーは、ユーザーストーリーに記載された確認項目を1つずつ確認していきます。すべての項目が完了していると確認された場合、そのユーザーストーリーは確認されたとされます。もし何らかの項目が未完了または期待通りに動作しないことが判明した場合、プロダクトオーナーは開発チームに修正を依頼します。修正と確認のプロセスを繰り返し、ユーザーストーリーが完全に確認されるまで続けます。

いつ確認すべきか?
スプリントは、実際には継続的デリバリーのプロセスです。スプリントの終わりにユーザーストーリーを確認するのではなく、どのユーザーストーリーが完了した直後に確認を行うべきです。しかし、プロダクトオーナーが継続的な確認に参加できない場合、1~2時間程度の週次ミーティングを設定できます。その会議では、プロダクトオーナーがチームと共に完了したユーザーストーリーの確認を行います。また、スプリントに含まれる他のストーリーの実装中に発生した疑問を解消するための議論セッションも含まれます。
確認はテストと同等ではありません
前述したように、確認の目的はユーザーストーリーが適切に実装されていることを確認することです。判断は、ユーザーストーリーを詳細化する際に設定された確認項目に基づいて行われ、それ以上でもそれ以下でもありません。このチェックの範囲は、機能が本番環境で使用可能になることを保証するにははるかに不足しています。では、本格的なテストはいつ行うべきでしょうか?
異なるチームはソフトウェアテストに関して異なる実践を持っています。一部のチームは、スプリントごとのテストを好むため、スプリント終了時に統合テストやリグレッションテストなどを実施します。他のチームは、名の通りテストとバグ修正を目的として安定化スプリントを設けることを好む場合があります。そのスプリントでは新しい開発活動は一切行われません。
どのアプローチを選択しても、選択は誰か1人のものではなく、全員のものであることを忘れないでください。
Visual Paradigmは、あなたが必要なすべてのツールを提供していますアジャイルソフトウェア開発において、以下を含んでいますUMLユースケース図ツール, (アジャイル) ユーザーストーリー, スプリント, ストーリーボード と ワイヤーフレーム UXデザイン用、タスク管理ツール など