スクラム-クイックガイド

アジャイルは、ソフトウェア開発業界の大きな流行語の1つになっています。しかし、アジャイル開発とは正確には何ですか？簡単に言えば、アジャイル開発はソフトウェア開発チームやプロジェクトを実行する別の方法です。

何が新しいかを理解するために、従来の方法を要約してみましょう。従来のソフトウェア開発では、開発を進める前に製品要件を確定していました。

ウォーターフォールモデル

この特性を持つ最も一般的に使用されるソフトウェア開発モデルは、次の図に示すウォーターフォールモデルです。ただし、ほとんどの場合、新しい機能が追加され、以前の要件も変更される可能性があります。ウォーターフォールモデルは、このような継続的な要件の変化に対応するように構成されていません。さらに、ユーザーは、製品が完全に利用可能になるまで、製品の機能を明確にすることはできません。

反復型インクリメンタルモデル

反復型インクリメンタルモデルでは、開発は限られた数の最終的な優先順位付けされた要件から始まります。成果物は、製品の実用的な増分です。要件からコード開発に至るまでの一連のアクティビティは、反復と呼ばれます。インクリメントの機能と、新しい、変更された、保留中の要件のいずれかまたはすべてに基づいて、次のロットの要件が後続の反復に与えられます。後続の反復の結果は、製品の作業増分が強化されます。これは、製品が必要な機能を達成するまで繰り返されます。

ユーザーは通常、開発作業に関与しておらず、通信ギャップが発生して機能が正しくない可能性があります。関与は開発チームにとって前向きですが、チームの時間を要求し、遅延を追加する可能性があります。さらに、反復中の非公式の要件変更は混乱を招く可能性があり、スコープクリープを引き起こす可能性もあります。この前提で、アジャイル開発が生まれました。

アジャイル開発

アジャイル開発は反復型開発に基づいており、チームのコラボレーションを通じて要件とソリューションが進化します。タイムボックス化された反復アプローチを推奨し、変更に対する迅速で柔軟な対応を促進します。これは理論的なフレームワークであり、開発チームが従うべき特定のプラクティスを指定していません。スクラムは、従う必要のあるプラクティスを定義する特定のアジャイルプロセスフレームワークです。

アジャイルメソッドの初期の実装には、Rational Unified Process（1994）、Scrum（1995）、Crystal Clear、Extreme Programming（1996）、Adaptive Software Development、Feature Driven Development（1997）、およびDynamic Systems Development Method（DSDM）（1995）が含まれます。これらは現在、まとめてagile methodologies、2001年にアジャイルマニフェストが公開された後。

アジャイルマニフェスト

アジャイルマニフェストは2001年にソフトウェア開発者のチームによって発行され、変化する要件、顧客の関与に対応し、開発チームに与える必要のある重要性を強調しています。

アジャイルマニフェストは次のとおりです。

「私たちは、ソフトウェアを開発し、他の人がそれを行うのを助けることによって、ソフトウェアを開発するより良い方法を発見しています。この作業を通じて、私たちは価値を得るようになりました。

プロセスとツールを介した個人と相互作用
包括的なドキュメントを介した作業ソフトウェア
契約交渉をめぐる顧客のコラボレーション
計画に従った切り替えへの対応

つまり、右側のアイテムには価値がありますが、左側のアイテムにはもっと価値があります。」

…アジャイルソフトウェア開発のマニフェスト、著者：Beck、Kent、他。（2001）

アジャイルマニフェストアイテムの定義

左側のマニフェスト項目は次のように説明できます。

マニフェストアイテム	説明
個人と相互作用	重要性は以下に与えられる必要があります：チームメンバーの自己組織化と自己動機付けチームメンバー間の仕事、説明、情報のための継続的な相互作用
作業ソフトウェア	動作するソフトウェアを短期間で提供することで、チーム内で顧客の信頼と保証を得ることができます。
顧客とのコラボレーション	開発チームとの顧客の絶え間ない関与は、必要な変更のコミュニケーションを確実にします。
変化への対応	提案された変更への迅速な対応に焦点を合わせます。これは、短時間の反復で可能になります。

アジャイルマニフェストの重要な要素は、人々と彼らのコラボレーション能力を信頼しなければならないということです。このため、開発された特定のアジャイル手法は、プロジェクトのライフサイクル全体を通じてチームワークとコラボレーションを強調することにより、チームメンバーの能力を活用します。

アジャイルの主要原則

アジャイルマニフェストは、次の原則に基づいています。

原理	説明
満足と配達	早期かつ継続的に機能するソフトウェアによる顧客満足度。
歓迎の変化	開発の後の段階でも、要件の変更を歓迎します。
頻繁に配信	動作するソフトウェアを頻繁に（毎月ではなく毎週）配信します。
コミュニケーションが鍵	開発者とビジネスマンの密接な関係を日常的に確保します。
環境と信頼	やる気のある個人を中心にプロジェクトを構築します。彼らに必要なサポートを与え、彼らを信頼してください。
対面コミュニケーション	効率的かつ効果的なコミュニケーションを確保するために、対面での会話を奨励します。
進歩の尺度としてのソフトウェア	動作するソフトウェアは、進歩の主要な尺度です。
持続可能な発展	開発全体を通して一定のペースを維持する能力を備えた持続可能な開発を促進します。
詳細への注意	卓越した技術と優れたデザインへの継続的な注意。
少ない力	シンプルさが不可欠です。
自己組織化チーム	状況の変化に効果的になるためのチームの定期的な注意。

アジャイル手法

動的システム開発方法論（DSDM）

これは、ソフトウェアプロジェクトのためのアジャイルフレームワークです。これは、従来のアプローチを微調整するために使用されました。DSDMの最新バージョンはDSDMAternと呼ばれます。Aternという名前はArcticTernの略です。これは、優先順位付けやコラボレーションなどの自然な作業方法である方法の多くの機能を表す、長距離を移動できる海鳥です。

スクラム

これは最も人気のあるアジャイルフレームワークであり、特にチームベースの開発環境内でタスクを管理する方法に重点を置いています。スクラムは反復型および増分型の開発モデルを使用し、反復の期間は短くなります。スクラムは実装が比較的簡単で、迅速かつ頻繁な配信に重点を置いています。

エクストリームプログラミング（XP）

これはアジャイルソフトウェア開発の一種です。生産性を向上させ、新しい顧客の要件を採用できるチェックポイントを導入することを目的とした、短い開発サイクルでの頻繁なリリースを提唱しています。この方法論の名前は、従来のソフトウェアエンジニアリング手法の有益な要素が極端なレベルにまで引き上げられるという考えに由来しています。（エクストリームプログラミングは、より高品質のソフトウェアをより生産的に生産するために人々を組織化するソフトウェア開発分野です。）XPは、最終製品の品質に大きな違いをもたらす新しいアプローチで、分析、開発、およびテストの各フェーズに対応します。

テスト駆動開発（TDD）

これは、非常に短い開発サイクルの繰り返しに依存するソフトウェア開発プロセスです。最初に開発者は、目的の改善または新しい機能を定義する自動テストケースを作成し、次にそのテストに合格するための最小限のコードを生成します。最終的に、新しいコードを許容可能な標準にします。

リーン

これは、エンドカスタマーの価値の創造以外の目標のためのリソースの支出が無駄であり、したがって排除の目標であると見なす生産慣行です。製品またはサービスを消費する顧客の観点から作業すると、価値という用語は、顧客が喜んで支払うアクションまたはプロセスとして定義されます。リーンは、少ない労力で価値を維持することに重点を置いています。

かんばん

高水準の生産を改善し、維持するためのシステムです。かんばんは、組織が在庫費用を管理するために採用する戦略であるジャストインタイム（JIT）を実現するための1つの方法です。かんばんは、生産システム全体の運用をサポートする効果的なツールとなり、改善を促進するための優れた方法であることが証明されました。

結論

過去10年間で、成功事例の量は増え続けており、企業はアジャイルプラクティスを使用してIT開発チームとプロジェクトの成功とパフォーマンスを劇的に改善しています。これにより、アジャイルは、メディアやテクノロジー、大企業、さらには政府など、さまざまな業界で広く採用されるようになりました。

アジャイルフレームワークは、チームが以下の恩恵を受けるのに役立ちます。

納品/市場投入までの時間の短縮
不確実性とリスクを軽減する
顧客価値に焦点を当てることにより、投資収益率（ROI）を向上させる

これらのさまざまなアジャイル手法の中で、スクラムは過去20年間で世界中で非常に成功していることが証明されています。

スクラムは、複雑な製品を開発および維持するためのフレームワークです。KenSchwaberとJeffSutherlandがスクラムを開発しました。一緒に、彼らはスクラムルールの後ろに立っています。

スクラムの定義

スクラムは、人々が複雑な適応問題に対処しながら、可能な限り最高の価値のある製品を生産的かつ創造的に提供できるフレームワークです。

スクラムは、1990年代初頭から複雑な製品開発を管理するために使用されてきたプロセスフレームワークです。スクラムは、製品を構築するためのプロセスや手法ではありません。むしろ、さまざまなプロセスや手法を採用できるフレームワークです。スクラムは、製品管理と開発の実践の相対的な有効性を明らかにし、改善できるようにします。

スクラムフレームワークは、スクラムチームとそれに関連する役割、イベント、アーティファクト、およびルールで構成されます。フレームワーク内の各コンポーネントは特定の目的を果たし、スクラムの成功と使用に不可欠です。

スクラムのルールは、イベント、ロール、およびアーティファクトをバインドし、それらの間の関係と相互作用を管理します。スクラムのルールは、このチュートリアル全体で説明されています。

Note-業界全体で、スクラムはドキュメントがないことを意味し、スクラムチームは開発者のみで構成されているという誤解があります。完全にそうではありません。これらについては、後のセクションで説明します。

スクラムプロセスフレームワーク

スクラムでは、規定されたイベントを使用して規則性を作成します。すべてのイベントはタイムボックス化されたイベントであり、すべてのイベントに最大期間があります。イベントについては、以降の章でさらに詳しく説明します。

スプリント

スクラムの中心はスプリントです。これは、リリース可能な製品の増分が作成される2週間または1か月のタイムボックスです。新しいスプリントは、前のスプリントの終了直後に開始されます。スプリントは、スプリント計画、毎日のスクラム、開発作業、スプリントレビュー、およびスプリント回顧展で構成されます。

スプリント計画では、スプリントで実行される作業はスクラムチームによって共同で計画されます。
デイリースクラムミーティングは、スクラムチームがアクティビティを同期し、その日の計画を作成するための15分のタイムボックスイベントです。
スプリントレビューはスプリントの最後に開催され、増分を検査し、必要に応じて製品バックログに変更を加えます。
スプリントレトロスペクティブは、スプリントレビューの後、次のスプリント計画の前に発生します。この会議では、スクラムチームは自分自身を検査し、次のスプリント中に実施される改善の計画を作成します。

結論

スクラムは、規則性をもたらすための特定のルール、イベント、および役割を定義するプロセスフレームワークです。ただし、基本的なスクラムルールに違反しない限り、ニーズに基づいて任意の組織に適合させることができます。

スクラムチームは、スクラムマスター、プロダクトオーナー、チームの3つの役割で構成されています。

スクラムマスター

スクラムマスター（正式な用語は「スクラム」の後にスペースがありませんが、スクラムマスターと呼ばれることもあります）は、スクラムプロセスのキーパーです。彼/彼女は責任があります-

プロセスをスムーズに実行する
生産性に影響を与える障害を取り除く
重要な会議の開催と促進

プロダクトオーナー

プロダクトオーナーは、製品の価値とチームの仕事を最大化する責任があります。これがどのように行われるかは、組織、スクラムチーム、および個人によって大きく異なる場合があります。

プロダクトオーナーは、プロダクトバックログの管理を担当する唯一の人物です。製品バックログ管理には以下が含まれます-

製品バックログアイテムを明確に表現する。
目標とミッションを最もよく達成するための製品バックログアイテムの注文。
チームが実行する作業の価値を最適化します。
製品バックログがすべての人に表示され、透過的で、明確であることを確認し、チームがさらに取り組むことを示します。
チームが製品バックログの項目を必要なレベルまで理解していることを確認します。

プロダクトオーナーは上記の作業を行うか、チームに行わせることができます。ただし、プロダクトオーナーはこれらのタスクについて引き続き責任を負います。

プロダクトオーナーは委員会ではなく一人です。プロダクトオーナーは、プロダクトバックログで委員会の要望を表す場合がありますが、プロダクトバックログアイテムの優先度を変更したい場合は、プロダクトオーナーに連絡する必要があります。

プロダクトオーナーが成功するには、組織全体が彼または彼女の決定を尊重する必要があります。プロダクトオーナーの決定は、プロダクトバックログの内容と順序に表示されます。異なる要件のセットから作業するようにチームに指示することは許可されておらず、チームは他の誰かの発言に基づいて行動することも許可されていません。これはScrumMasterによって保証されています。

チーム

チームは自己組織化され、部門の枠を超えています。つまり、チームは、プロジェクトに適切かつ関連するアナリスト、デザイナー、開発者、テスターなどで構成されます。

業界の一部の人々は、このチームを開発チームと呼んでいます。ただし、そのような参照は、チームが開発者のみを持ち、他の役割を持たないという論争を引き起こしています。それが単なる誤解であることは明らかな理解です。ソフトウェア製品を開発するには、すべての役割が必要であり、それがスクラムの本質です。チームは共同で機能します。部門の枠を超えたチームは、チームに属していない他のチームに依存することなく作業を遂行するために必要なすべての能力を備えているため、時間と労力を節約できます。スクラムのチームモデルは、柔軟性、創造性、生産性を最適化するように設計されています。

最適なチームサイズは、機敏性を維持するのに十分小さく、スプリント内で重要な作業を完了するのに十分な大きさです。チームのサイズは、可能であれば5人から9人の範囲に保つ必要があります。チームメンバーが5人未満の場合、相互作用が減少し、生産性の向上が小さくなります。メンバーが9人を超えると、調整が必要になります。

スクラムチームは、情報の円滑な流れと問題の迅速な解決を確実にするために、日常的に緊密に協力しています。スクラムチームは、製品を反復的かつ段階的に提供し、フィードバックの機会を最大化します。完全な製品の増分配信により、潜在的に有用なバージョンの作業用製品を常に利用できるようになります。

ScrumMasterは訓練を受けた責任者であり、以下に説明するようにサービスを提供します-

プロダクトオーナーへのスクラムマスターサービス

スクラムマスターは、次のようないくつかの方法でプロダクトオーナーにサービスを提供します。

効果的な製品バックログ管理のためのテクニックを見つける。
スクラムチームが明確で簡潔な製品バックログアイテムの必要性を理解するのを支援します。
経験的環境での製品計画を理解する。
プロダクトオーナーが、価値を最大化するためにプロダクトバックログを調整する方法を知っていることを確認します。
敏捷性を理解し、実践する。
必要に応じてスクラムイベントを促進します。

スクラムチームへのスクラムマスターサービス

スクラムマスターは、次のようないくつかの方法でスクラムチームにサービスを提供します。

自己組織化とクロスファンクショナルでスクラムチームを指導する。
スクラムチームが高価値の製品を作成するのを支援します。
スクラムチームの進歩に対する障害を取り除く。
要求または必要に応じてスクラムイベントを促進します。
スクラムがまだ完全に採用および理解されていない組織環境でスクラムチームを指導する。

組織へのScrumMasterサービス

ScrumMasterは、次のようないくつかの方法で組織にサービスを提供します。

スクラムの採用において組織を主導し、指導します。
組織内でのスクラム実装の計画。
従業員と利害関係者がスクラムと経験的な製品開発を理解して制定するのを支援します。
スクラムチームの生産性を向上させる変化を引き起こします。
他のスクラムマスターと協力して、組織におけるスクラムの適用の有効性を高めます。

結論

スクラムプロセスフレームワークは、一連のイベントと対応するアーティファクトを使用して表示できます。スクラムイベントはタイムボックス化されたイベントです。つまり、プロジェクトでは、すべてのスクラムイベントに事前定義された最大期間があります。これらのイベントにより、プロジェクトに関与するすべての人にプロジェクトの進捗状況を透明にすることができます。スクラムの重要なイベントは-

スプリント
スプリント計画
毎日のスクラムミーティング
スプリントレビュー
スプリント回顧展

スプリント

スプリント中に、実用的な製品Incrementが開発されます。通常、期間は2週間または1か月であり、この期間はプロジェクト内のすべてのスプリントで一定のままです。プロジェクト内のスプリントごとに期間を変えることはできません。新しいスプリントは、前のスプリントの終了直後に開始されます。

スプリントゴールは、スプリントの目標セットです。増分を構築している理由について、チームにガイダンスを提供します。これは、スプリント計画会議中に作成されます。要件の詳細が学習されると、スプリントの範囲が明確になり、プロダクトオーナーとチームの間で再交渉されます。したがって、各スプリントは、スプリント、構築されるものの定義、設計、およびスプリントの構築をガイドする柔軟な計画、開発作業、および結果として生じる製品の増分に関連付けられます。

スプリントゴールが廃止された場合は、スプリントをキャンセルする必要があります。これは、組織が方向を変えた場合、または市場や技術の状況が変わった場合に発生する可能性があります。スプリントは製品の所有者のみがキャンセルできますが、他の人も同じ影響を及ぼします。

スプリントの期間が短いため、スプリント中のキャンセルが意味をなさないことはめったにありません。スプリントのキャンセルはリソースを消費するため、別のスプリントに再編成するために、それらは非常にまれです。

スプリントがキャンセルされ、スプリント中に作成された作業の一部が潜在的にリリース可能である場合、プロダクトオーナーは通常それを受け入れます。不完全なスプリントバックログアイテムはすべて、製品バックログに戻されます。

スプリント計画

スプリントで実行される作業は、スプリント計画会議で計画されます。スプリント計画会議は、2週間のスプリントで最大4時間、1か月のスプリントで最大8時間の期間です。ミーティングが行われ、必要なすべての出席者が出席し、スケジュールされたミーティングの目的を理解していることを確認するのは、スクラムマスターの責任です。スクラムマスターは会議をモデレートして、時間通りに話し合いと終了の維持を監視します。

スプリント計画は、次の2つの質問に焦点を当てています-

Sprint Incrementで提供する必要があり、提供できるものは何ですか？
Sprintの実行に必要な作業はどのように達成されますか？

この会議へのインプットは-

製品バックログ
最新の製品インクリメント
スプリント中のチームの予想能力
チームの過去のパフォーマンス

スクラムチームは、スプリント中に開発できる機能について話し合います。プロダクトオーナーは、プロダクトバックログアイテムについて説明します。チームは、スプリントで何を達成できるかを評価するのに最適なアイテムを、スプリントの製品バックログから選択します。チームは、アナリスト、デザイナー、開発者、テスターで構成されています。作業は共同で実行されるため、再作業が最小限に抑えられます。

次に、スクラムチームがスプリントゴールを考え出します。スプリントゴールは、チームが製品増分を構築している理由についてチームにガイダンスを提供する目標です。次に、チームは、スプリント中に選択した機能を実際の製品の増分に組み込む方法を決定します。このスプリント用に選択された製品バックログアイテムとそれらを提供するための計画は、スプリントバックログと呼ばれます。

スプリント中の作業は、スプリント計画中に見積もられ、サイズや労力が異なる場合があります。スプリント計画会議の終わりまでに、作業は1日以下の期間のタスクに分割されます。これは、作業の割り当てを容易にし、完了を追跡できるようにするためです。チームは、作業が多すぎたり少なすぎたりすることに気付いた場合、選択した製品バックログアイテムを製品所有者と再交渉できます。

チームは、他の人（スクラムチームの一部ではない）をスプリント計画会議に招待して、技術的またはドメインのアドバイスを得たり、見積もりを支援したりすることもできます。

毎日のスクラムミーティング

デイリースクラムミーティングはチームのための15分間のミーティングであり、前回のデイリースクラムミーティング以降の作業をすばやく理解し、次の24時間の計画を作成するために毎日実施されます。この会議は、デイリースタンドアップミーティングとも呼ばれます。

デイリースクラムミーティングは、複雑さを軽減するために毎日同じ時間に同じ場所で開催されます。

会議中に、各チームメンバーは説明します-

チームがスプリントの目標を達成するのに役立った昨日、彼は何をしましたか？
チームがスプリントの目標を達成するのを助けるために、彼は今日何をしますか？
彼またはチームがスプリントの目標を達成するのを妨げる障害がありますか？

デイリースクラムはステータス追跡イベントと誤解されていますが、実際には計画イベントです。

会議への入力は、チームがスプリント目標の達成に向けてどのように行っているかであり、出力は、スプリント目標の達成におけるチームの取り組みを最適化する新しい計画または改訂された計画である必要があります。

スクラムマスターはデイリースクラムミーティングを調整し、ミーティングの目的が確実に達成されるようにしますが、ミーティングはチームの責任です。

必要に応じて、チームはデイリースクラムミーティングの直後にミーティングを行い、詳細な話し合いを行ったり、スプリントの残りの作業を再計画したりすることができます。

デイリースクラムミーティングのメリットは次のとおりです-

チーム内のコミュニケーションを改善します。
スプリントへの影響を最小限に抑えるために、障害の早期除去を容易にするために、障害がある場合はそれを特定します。
迅速な意思決定を強調し、促進します。
チームの知識レベルを向上させます。

スプリントレビュー

スプリントレビューは、すべてのスプリントの最後に開催されます。スプリントレビュー中に、リリースされている増分のプレゼンテーションがレビューされます。この会議では、スクラムチームと利害関係者が協力して、スプリントで何が行われたかを理解します。これと、スプリント中の製品バックログへの変更に基づいて、参加者は、価値を最適化できる次のステップに到達します。したがって、スプリントレビューの目的は、フィードバックと進捗状況を一致して取得することです。

スプリントレビューは通常、2週間のスプリントでは2時間、1か月のスプリントでは4時間開催されます。

スクラムマスターは次のことを保証します-

会議が行われます。
参加者は目的を理解しています。
会議は必要な議題に焦点を合わせており、必要な期間内に完了します。

スプリントレビューには次の側面が含まれます-

参加者には、プロダクトオーナーから招待された、スクラムチームと主要な利害関係者が含まれます。
プロダクトオーナーは、スプリント中に完了したプロダクトバックログアイテムと完了していないアイテムについて説明します。
チームは、スプリント中に何がうまくいったか、どのような問題が発生したか、そしてそれらの問題がどのように解決されたかについて話し合います。
チームは、完了した作業をデモンストレーションし、インクリメントに関する質問がある場合はそれに回答します。
次に、グループ全体が次に何をすべきかについて話し合います。したがって、スプリントレビューは、後続のスプリントのスプリント計画に貴重な情報を提供します。
次に、スクラムチームは、製品増分の次に予想されるリリースのタイムライン、予算、潜在的な機能、および市場を確認します。
スプリントレビューの結果は、更新された製品バックログです。これは、次のスプリントの製品バックログの可能性のあるアイテムを定義します。

スプリント回顧展

スプリントレトロスペクティブは、スプリントレビューの後、次のスプリント計画の前に発生します。これは通常、2週間のスプリントの場合は1時間の会議であり、1か月の期間のスプリントの場合は3時間の会議です。

スプリントレトロスペクティブの目的は-

人、人間関係、プロセス、ツールに関して、前回のスプリントからの学習を組み合わせます。
うまくいった主な項目と潜在的な改善点を特定します。
製品の品質を向上させるための改善を実施するための計画の作成。

スプリントレトロスペクティブは、次のスプリントの結果をより効果的にするために、スクラムチームがスクラムプロセスフレームワーク内で内省し、改善する機会です。

Reference

スクラムアーティファクトは、開発中の製品、実行されたアクティビティ、およびプロジェクトで計画されているアクティビティを理解するために、スクラムチームと利害関係者が知っておく必要のある重要な情報を提供します。次のアーティファクトはスクラムプロセスフレームワークで定義されています-

製品バックログ
スプリントバックログ
バーンダウンチャート
Increment

これらはスクラムプロジェクトで最低限必要なアーティファクトであり、プロジェクトアーティファクトはこれらによって制限されません。

製品バックログ

製品バックログは、最終製品の一部として必要な機能の順序付きリストであり、製品に加えられる変更の要件の単一のソースです。

製品バックログには、将来のリリースで製品に加えられる変更を構成するすべての機能、機能、要件、拡張機能、および修正がリストされています。製品バックログアイテムには、説明、注文、見積もり、および値の属性があります。これらのアイテムは通常、ユーザーストーリーと呼ばれます。プロダクトオーナーは、コンテンツ、可用性、注文など、プロダクトバックログに責任を負います。

製品バックログは進化するアーティファクトです。それの最も初期のバージョンは、最初に知られていて最もよく理解された要件だけを含むかもしれません。製品バックログは製品として開発され、それが使用される環境が進みます。製品バックログは、それを効果的にするために必要なものを組み込むために絶えず変化します。製品が存在する限り、その製品バックログも存在します。

構築中の製品が使用されて価値が上がるにつれて、製品バックログはより大きく、より網羅的なリストになります。ビジネス要件、市場の状況、またはテクノロジーの変化により、製品バックログが変化し、ライブアーティファクトになります。

製品バックログの改良とは、製品バックログアイテムに詳細、見積もり、優先順位を追加することを意味します。これは、プロダクトオーナーとチームによって実行される継続的なプロセスです。スクラムチームは、いつどのように改良を行うかを決定します。

製品バックログアイテムは、製品所有者または製品所有者の裁量でいつでも更新できます。

通常、高次の製品バックログアイテムは、低次のアイテムよりも明確で詳細です。より正確な見積もりは、より明確で詳細に基づいて行われます。順序が低いほど、詳細は少なくなります。

今後のスプリントの候補要件となる可能性のある製品バックログアイテムは、これらのアイテムがスプリント中に開発できるように改良されています。1つのスプリント内でチームが開発できる製品バックログアイテムは、スプリント計画会議で選択する準備ができていると見なされます。

スプリントバックログ

スプリントバックログは、スプリント用に選択された製品バックログアイテムのセットに加えて、製品の増分を提供し、スプリント目標を実現するための計画です。

スプリントバックログは、次のインクリメントでどの機能が利用可能になるか、およびその機能を実用的な製品のインクリメントとして提供するために必要な作業についてのチームによる予測です。

スプリントバックログは、理解できる十分な詳細を備えた計画ですが、チームはデイリースクラムで追跡します。チームはスプリント全体でスプリントバックログを変更し、スプリントバックログはスプリント中に出現します。この出現は、チームが計画を実行し、スプリント目標を達成するために必要な作業についてさらに学習するときに発生します。

新しい作業が必要になると、チームはそれをスプリントバックログに追加します。作業が実行または完了すると、推定残り作業が更新されます。計画の要素が不要であると見なされると、それらは削除されます。スプリント中にスプリントバックログを変更できるのはチームだけです。スプリントバックログは、チームがスプリント中に達成することを計画している作業の非常に目に見えるリアルタイムの画像であり、チームにのみ属します。

インクリメント

増分は、スプリント中に完了したすべての製品バックログアイテムの合計と、以前のすべてのスプリントの増分を組み合わせたものです。スプリントの終了時に、新しい増分は機能する製品である必要があります。つまり、使用可能な状態である必要があります。プロダクトオーナーが実際にリリースすることを決定したかどうかに関係なく、動作状態にある必要があります。

スクラムチームは、インクリメントと見なされるものについてコンセンサスを得る必要があります。これはスクラムチームごとに大きく異なりますが、チームメンバーは、作業を完了することの意味について共通の理解を持っている必要があります。これは、製品Incrementの作業がいつ完了するかを評価するために使用されます。

同じ理解により、チームはスプリント計画中に選択できる製品バックログアイテムの数を知ることができます。各スプリントの目的は、リリース可能な機能の増分を提供することです。

チームは、スプリントごとに製品機能の増分を提供します。このインクリメントは使用可能であるため、プロダクトオーナーはすぐにリリースすることを選択できます。増分の理解が開発組織の規則、標準、またはガイドラインの一部である場合、すべてのスクラムチームは少なくともそれに従う必要があります。開発組織の慣例ではない場合、スクラムチームは製品に適したインクリメントの定義を定義する必要があります。

各増分は、以前のすべての増分に追加され、徹底的にテストされ、すべての増分が連携して機能することを確認します。

スクラムチームが成熟するにつれて、増分の定義が拡張され、より高い品質のためのより厳しい基準が含まれることが期待されます。1つの製品には、その製品で行われるすべての作業の標準であるインクリメントの定義が必要です。

スプリントバーンダウンチャート

スプリントの任意の時点で、スプリントバックログに残っている作業の合計を合計できます。チームは、スプリント目標を達成する可能性を予測するために、すべてのデイリースクラムに残っているこの合計作業を追跡します。スプリント全体で残りの作業を追跡することにより、チームはその進捗状況を管理できます。

スプリントバーンダウンチャートは、スクラムチームが費やした作業の傾向を把握するためのプラクティスです。これは、スプリント目標に向けたスプリントの進捗状況を監視するのに役立つ手法であることが証明されています。

プロダクトオーナーは、少なくともすべてのスプリントレビューに残っているこの合計作業を追跡します。プロダクトオーナーは、この金額を以前のスプリントレビューで残っている作業と比較して、目標の希望する時間までに計画された作業を完了するための進捗状況を評価します。この情報はすべての利害関係者と共有されます。

結論

スクラムの役割、イベント、アーティファクト、およびルールは避けられません。スクラムの一部のみが実装されている場合、結果はスクラムではありません。スクラムは完全に実装する必要があり、他の手法、方法論、および実践と連携すればうまく機能します。

Reference

ご理解のとおり、ユーザーストーリーは一般的に製品の機能を説明するために使用され、スクラムアーティファクトの一部を形成します– Product Backlog そして Sprint Backlog。

ユーザーストーリー

ソフトウェア開発では、製品の機能が重要な役割を果たします。これは、ユーザーが最終製品で最終的に使用したい機能です。これらは、一般的な用語では要件として知られています。ソフトウェア開発プロジェクトの成功は、ユーザーの要件を正確かつ適切に理解し、それらを最終製品に実装することにあります。したがって、要件または製品の機能を開発プロジェクトチームに完全に知らせる必要があります。

1999年、ケントベックは製品機能のユーザーストーリーという用語を思いつきました。彼は、ユーザーストーリーは、システムが彼のために何ができるかではなく、彼または彼女が何を望んでいるかに関してユーザーの観点からナレーションされていると説明しました。したがって、ビューは製品ごとに完全に変わり、ユーザーストーリーはすべてのアジャイルフレームワークの要件の事実上の標準になりました。

スクラムプロジェクトでは、製品バックログはユーザーストーリーのリストです。これらのユーザーストーリーは優先順位が付けられ、スプリント計画会議のスプリントバックログに取り込まれます。

見積もりもユーザーストーリーに基づいており、製品のサイズはユーザーストーリーポイントで見積もります。

ユーザーストーリーの構造

ユーザーストーリーの構造は次のとおりです-

<ユーザのタイプ>、

私が欲しい<いくつかのタスクを実行するために>、

だから<私はいくつかの目標/利益/値を達成することができます>。

銀行の顧客がATMから現金を引き出すシナリオのユーザーストーリーがどのように構成されているかを見てみましょう。

ユーザーストーリー：顧客の現金引き出し

として Customer、

したい withdraw cash from an ATM、

そのため I don't have to wait in line at the Bank

ユーザーストーリーの受け入れ基準

各ユーザーストーリーには受け入れ基準も定義されているため、ユーザーストーリーの実装の正確さは、受け入れ基準に基づく受け入れテストに合格することで確認されます。

以下は、ユーザーストーリーの顧客による現金の引き出しの例のサンプル受け入れ基準です。

Acceptance Criterion 1:

Given アカウントが信用できること

そしてカードは有効です
そしてディスペンサーには現金が含まれています、

When 顧客が現金を要求する

Then アカウントから引き落とされていることを確認します

そして、現金が分配されることを確認してください
そして、カードが返されることを確認してください。

Acceptance Criterion 2:

Given アカウントが引き落とされていること

そしてカードは有効です

When 顧客が現金を要求する

Then 拒否メッセージが表示されていることを確認します

そして、現金が分配されないことを確認してください
そして、カードが返されることを確認してください。

ユーザーストーリーの作成

プロダクトオーナーは、プロダクトバックログ、つまりユーザーストーリーに責任があります。ただし、製品の所有者だけがユーザーストーリーを書くという意味ではありません。スクラムチームの誰もがユーザーストーリーを書くことができ、要件が洗練され、新しい機能が追加されると、アクティビティをプロジェクト全体に広げることができます。

ユーザーストーリーの非機能要件

非機能要件をユーザーストーリーに組み込むことも可能です。与えられたATMの例では、ユーザーが24時間365日利用できるATMは非機能要件であり、ユースケースで説明できます。

ユーザーストーリーの管理

ユーザーストーリーは、製品バックログで管理されます。ユーザーストーリーは優先度に従って並べられています。最も優先度の高いユーザーストーリーは詳細レベルに絞り込まれ、最も優先度の低いユーザーストーリーはより詳細なレベルに保たれます。すべてのスプリントについて、最も優先順位が高く、したがってよりきめ細かいユーザーストーリーがスプリントバックログに取り込まれます。ユーザーストーリーを製品バックログに追加する場合は、最初にその優先度が決定され、優先度に従ってその場所に従って配置されます。ユーザーストーリーはいつでも優先順位を変更できます。必要に応じて、ユーザーストーリーを削除することもできます。

ユーザーストーリーのメリット

ユーザーストーリーの主な利点は、ユーザー中心の定義自体にあります。これは、最終的には、関連するユーザーシナリオで製品を使用するのはユーザーであるためです。エンドユーザーをチームメンバーに接続します。
ユーザーストーリー自体の構文は、ユーザーが達成したい目標、利益、または価値を確実に捉えます。
受け入れ基準はユーザーストーリー自体の一部を形成するため、スクラムチームに追加の利点があります。
プロジェクトの実行中にユーザーストーリーに変更を加えることができます。ユーザーストーリーの範囲が大きくなる場合は、より小さなユーザーストーリーに分割する必要があります。合格基準の条件も変更できます。
各スプリントの終了時に作業成果物の増分がユーザーに配信されると、スクラムチームはスプリントレビューミーティングでユーザーからフィードバックを得ることができます。これにより、フィードバックを製品に継続的に組み込むことができます。

結論

スクラムのユーザーストーリーは、ユーザーをスクラムチームに近づけ、土壇場での驚きを防ぎます。

スプリントの追跡は通常、バーンダウンチャートを使用して行われます。バーンダウンチャートは、残りの作業を日単位の時間数で示します。たとえば、2週間のスプリントを考えてみましょう-

Sprint Duration： 2週間

No. of Days per Week：5

No. of Hrs. per Day：6

No. of Resources：6

したがって、スプリント開始時の残りの合計作業量は2 * 5 * 6 * 6 = 360時間です。

したがって、理想的なシナリオでは、残りの作業で36時間の作業が削減され、バーンダウンチャートは次のようになります-

スプリント作業が毎日計画どおりに行われる場合、スクラムの進行状況はほぼ理想的なバーに一致します。

スプリント作業が遅れ、時間のコミットメントが満たされない場合、バーンダウンチャートは次のようになります-

ただし、バーンダウンチャートは毎日作成され、ずれは早期にわかっているため、スプリントのタイムラインに合わせて修正措置を講じることができます。チームがタイムラインに合わせてストレッチすると、バーンダウンチャートは次のようになります-

したがって、スプリントの任意の時点で、スプリントに残っている作業の合計を視覚化でき、スプリントのタイムラインを満たす可能性を高めることができます。

結論

バーンダウンチャートは、スクラムチームが進捗状況と、スプリントの目標を達成するために何をする必要があるかを追跡するのに役立ちます。

スクラムプロジェクトでは、見積もりはスプリント計画会議中にチーム全体で行われます。見積もりの目的は、スプリントのユーザーストーリーを優先度と、スプリントのタイムボックス中に配信するチームの能力によって検討することです。

プロダクトオーナーは、優先順位が付けられたユーザーストーリーが明確であり、見積もりの対象となることを保証し、それらがプロダクトバックログの先頭に表示されます。

スクラムチーム全体が製品増分の配信を担当するため、製品増分のサイズとそれに必要な労力に基づいて、スプリントのユーザーストーリーを選択するように注意が払われます。

製品の増分のサイズは、ユーザーストーリーポイントの観点から推定されます。サイズが決定されると、過去のデータ、つまり生産性と呼ばれるユーザーストーリーポイントごとの作業量を使用して作業量が推定されます。

スクラム推定手法

ユーザーストーリーのスクラム推定は、各ユーザーストーリーの難易度の観点から行われます。難易度を評価するために、特定のスケールが使用されます。

スクラム推定で使用されるスケールにはいくつかのタイプがあります。以下はいくつかの例です-

数値サイズ（1から10）
Tシャツのサイズ（XS、S、M、L、XL XXL、XXXL）
フィボナッチ数列（1、2、3、5、8、13、21、34など）
犬の品種（チワワ、………、グレートデーン）

推定手法は通常、スクラムチーム全体がスケールの値に精通し、快適になるように選択されます。最も一般的に使用され、最も人気のある手法は、フィボナッチ数列に基づくプランニングポーカーです。

プランニングポーカーテクニック

プランニングポーカー推定手法では、ユーザーストーリーの推定値は、プランニングポーカーをプレイすることによって導き出されます。スクラムチーム全体が関与し、迅速で信頼性の高い見積もりが得られます。

プランニングポーカーはカードのデッキでプレイされます。フィボナッチ数列が使用されているため、カードには1、2、3、5、8、13、21、34などの番号が付いています。これらの番号はストーリーポイントを表しています。各推定量には、カードのデッキがあります。カードの数字は、チームメンバーの1人がカードを持っているときに、すべてのチームメンバーに見えるように十分に大きくする必要があります。

チームメンバーの1人がモデレーターとして選ばれます。モデレーターは、見積もりが行われているユーザーストーリーの説明を読みます。見積もり担当者に質問がある場合は、プロダクトオーナーが回答します。

各見積もり担当者は、自分の見積もりを表すカードを個人的に選択します。すべての推定者が選択を行うまで、カードは表示されません。その際、すべてのチームメンバーがそれぞれの見積もりを確認できるように、すべてのカードが同時に裏返され、保持されます。

最初のラウンドでは、見積もりが異なる可能性が非常に高くなります。高推定量と低推定量は、推定の理由を説明します。すべての議論は理解のみを目的としており、個人的には何も行われないように注意する必要があります。モデレーターは同じことを確認する必要があります。

チームは、ストーリーとその見積もりについて、さらに数分間話し合うことができます。

モデレーターは、特定のストーリーが作成されるときに役立つディスカッションについてメモを取ることができます。話し合いの後、各推定者はカードを再度選択して再推定します。カードは、全員が推定するまで再び非公開にされ、推定されると同時に裏返されます。

見積もりがストーリーに使用できる単一の見積もりに収束するまで、このプロセスを繰り返します。見積もりのラウンド数は、ユーザーストーリーごとに異なる場合があります。

プランニングポーカー見積もりの利点

プランニングポーカーは、3つの見積もり方法を組み合わせています-

Expert Opinion：専門家の意見に基づく見積もりアプローチでは、専門家は何かにかかる時間や大きさを尋ねられます。専門家は、彼または彼女の経験または直感または直感に基づいて見積もりを提供します。

専門家の意見の見積もりは、通常、それほど時間はかからず、いくつかの分析方法と比較してより正確です。

Analogy：アナロジー推定は、ユーザーストーリーの比較を使用します。見積もり中のユーザーストーリーは、以前に実装された同様のユーザーストーリーと比較されます。推定は実証済みのデータに基づいているため、これにより正確な結果が得られます。

Disaggregation：分解の推定は、ユーザーストーリーをより小さく、推定しやすいユーザーストーリーに分割することによって行われます。スプリントに含まれるユーザーストーリーは、通常、開発に2〜5日の範囲です。したがって、より長い時間がかかる可能性のあるユーザーストーリーは、より小さなユースケースに分割する必要があります。このアプローチはまた、比較可能な多くのストーリーがあることを保証します。

結論

プランニングポーカーは、楽しく、しかも生産的な見積もりのアプローチです。最終的な見積もりが到着する前にセッションが議論のために開かれているので、チームが合意に達するのは簡単であり、手元のユーザーストーリーの実装の広い視野も持っています。

スクラムツールは、スクラムプロジェクトの計画と追跡を容易にします。これらは、製品バックログの管理、スプリントバックログ、スプリントの計画と追跡、バーンダウンチャートの表示、毎日のスクラムミーティングの実施、およびスクラムレトロスペクティブの実施のための単一の場所を提供します。

利用可能なスクラムツールにはさまざまな種類があります。無料（オープンソース）のものもあれば、有料のものもあります。また、ツールの蒸留版を入手できるものもあります。ただし、すべての機能とスケーラビリティを取得するには、フルバージョンを購入する必要があります。

利用可能なスクラムツール

以下は、現在市場で入手可能ないくつかのスクラムツールのリストです。オープンソースツールにはアスタリスクが付いています。

Axosoft	Airgile	アジャイルコックピット	Jira（GreenHopper）	混ざり合う
Scrumwise	スクラム用Agilo	バナナスクラム	国木	OnTime Now
バージョン1	AgileWrap	デイリー-スクラム	間隔	パンゴスクラム
Acunote	アジャイル追跡ツール*	ディガボード*	iMetaの敏捷性	ピボットトラッカー
アジャイルアジェンダ	アジャイルタスク	EasyBacklog	アイススクラム*	pmScrum
アジャイルベンチ	アジャイルスープ	PMTについて説明する	ハンソフト	Prjプランナー
アジャイルバディ	アジャイルマネージャー	アジャイルエクスプレス*	GravityDev	プロジェクトカード
アジャイルファント*	アジャイルログ	ファイアスクラム*	支点*	クォンタムウィスパー
クイックスクラム	Retrospectiva *	スクラム	スクラムファクトリー*	不器用
ラリー開発	スクリンチ*	スクラムダッシュボード*	スクラムエッジ	スクラムパッド
Redmineのバックログ	スクラム2ゴー	スクラムデスク	スクラムを行う	ツイートスクラム
Scrumrf	スクラムタイム*	Scrumwise	ソリューションファクトリを選択	タックル*
アーバンタートル	ScrumTool	スクラムワークス	タイムボックス	ピリッとしたオレンジスクラム

結論

一般的にアジャイル、具体的にはスクラムは、文書化作業がないことを意味するものではありません。スクラムアーティファクトが定義され、スクラムの計画と追跡が十分に確立されています。

スクラムツールは、スクラムプロジェクトに関する情報の取得と追跡を容易にします。ツールの選択は、他のツールのニーズに加えて、組織が必要とする機能によって異なります。

スクラムは、顧客、チームメンバー、および関連する利害関係者間の継続的なコラボレーションをサポートします。タイムボックス化されたアプローチと製品所有者からの継続的なフィードバックにより、常に重要な機能を備えた製品が機能します。さらに、スクラムは、プロジェクトのさまざまな役割にさまざまなメリットをもたらします。

お客様へのメリット

スプリントの期間は短く、優先順位の高いユーザーストーリーがすべてのスプリント計画で取り上げられます。これにより、すべてのスプリント配信で、顧客が必要とする機能がすぐに含まれるようになります。さらに、顧客が変更要求を出した場合、それは現在のスプリントに吸収されるか、次のスプリントに含まれます。したがって、開発チームは顧客の要件に非常に迅速に対応します。

組織にとってのメリット

組織は、優先順位の高いユーザーストーリーの開発に必要な作業に集中できるため、オーバーヘッドとやり直しを減らすことができます。顧客にとってのスクラムの特定の利点により、開発チームの効率の向上、顧客満足度、ひいては顧客維持と顧客参照が可能になります。それは組織の市場の可能性を高めます。

プロダクトマネージャーにとってのメリット

プロダクトマネージャーは、プロジェクトでプロダクトオーナーの役割を果たします。製品の所有者の責任は、顧客満足を確保することです。スクラムは迅速な対応、作業の優先順位付け、変更の吸収を容易にするため、製品マネージャーは作業が顧客のニーズに合っていることを簡単に確認でき、それによって顧客満足度が保証されます。

プロジェクトマネージャーにとってのメリット

プロジェクトマネージャーは、プロジェクトでスクラムマスターの役割を果たします。スクラムの協調的な性質により、簡単で具体的な計画と追跡が容易になります。バーンダウンチャートを使用して残された作業を理解し、デイリースクラムミーティングにより、プロジェクトマネージャーは常にプロジェクトの状態について認識できます。この認識は、プロジェクトを監視し、問題を迅速に見つけて対処するために不可欠です。

開発チームへのメリット

スプリントのタイムボックス化された性質と、すべてのスプリントの終了時の作業成果物の増分配信により、開発チームは、自分の作業がすぐに使用されることを確認することに熱心になります。組み込みのチームコラボレーションにより、チームは自分の仕事を楽しむことができます。すべてのスプリントのユーザーストーリーは顧客の優先順位に基づいているため、チームは自分の仕事が評価されていることも理解しています。

スクラム認定は、スクラムアライアンスによって提供されます。以下の認定が提供されています-

認定スクラムマスター（CSM）
認定スクラムプロダクトオーナー（CSPO）
認定スクラムプラクティショナー（CSP）
認定スクラムコーチ（CSC）
認定スクラムトレーナー（CST）

認定スクラムマスター（CSM）

認定スクラムマスターは、スクラムアライアンスのメンバーになり、スクラムマスターの役割を果たし、その他の認定を受けるための基本的な認定です。認定には、CSMコースへの参加が必要です。その後、受験者はスクラムメンバーシップとCSMオンライン試験の詳細を指定した電子メールを受け取ります。試験を受けた後、受験者にはCertified ScrumMaster（CSM）認定が与えられます。

認定スクラムプロダクトオーナー（CSPO）

認定スクラムプロダクトオーナーは、スクラムアライアンスのメンバーになり、プロダクトオーナーの役割を果たし、その他の認定を受けるための基本的な認定です。

認定スクラムプラクティショナー（CSP）

Certified Scrum Practitionerは、経験豊富なスクラムマスターとプロダクトオーナーの認定です。候補者は、少なくとも1年間、スクラムマスターまたはプロダクトオーナーである必要があります。候補者は、指定された役割で行ったことの詳細な説明を含む申請書を提出する必要があります。

候補者がスクラムマスターの役割またはプロダクトオーナーの役割を必要な期間積極的に実践している場合、候補者はCSM認定またはCSPO認定の直後にCSP認定を取得することができます。

認定スクラムコーチ（CSC）

認定スクラムコーチは、コーチングに焦点を当てている人のための認定です。認定には、候補者が過去5年間に少なくとも1500時間、スクラムの採用と習得を通じてスクラムチームを指導したことが必要です。

認定スクラムトレーナー（CST）

認定スクラムトレーナーは、CSMまたはCSPOクラスを教えたい人のための認定です。申請者は、CSMまたはCSPOのいずれかを持っている必要があり、申請する前に少なくとも1年間はCSPである必要があります。

以下はスクラムに関するいくつかのFAQです-

Question: What is the difference between Scrum and Agile Development?

Answer ：アジャイル開発はソフトウェア方法論ですが、スクラムはアジャイルに続くプロセスフレームワークの1つです。

Question: Are Sprints and Iterations the same?

Answer：スクラムのスプリントと反復型インクリメンタルモデルの両方が、実用的な製品の増分を提供します。ただし、これらは次の点で異なります。

スプリントとイテレーションのライフサイクルは異なります。
スプリントはタイムボックス化されていますが、イテレーションはタイムボックス化されていません。
スプリントの期間は、反復の期間と比較してはるかに短いです。

Question: Is Scrum Master a job title or a role that someone with an existing job title fills?

Answer：スクラムマスターは、役職を持つ人が果たす役割です。通常、プロジェクトマネージャーの役割を果たしている人は、ScrumMasterの役割も果たしています。

Question: Can Product Owner and ScrumMaster’s roles be played by the same person?

Answer：いいえ、所有権が異なるためです。プロダクトオーナーは、プロダクトバックログ、ユーザーストーリーの優先順位付け、およびスプリントに割り当てられたユーザーストーリーによる作業成果物の増分の検証を処理します。

Question: Is it that Scrum Projects need not have any Documentation?

Answer ：いいえ。スクラムプロジェクトは、他のプロジェクトと同様に、ユーザーストーリー、デザイン、テストケースなどのドキュメントが必要です。

結論

アジャイルとスクラムは同じではありません。スクラムは、アジャイルを適応させるプロセスフレームワークの1つです。フレームワークには優れたコラボレーションと自己組織化も必要であるため、経験豊富なチームメンバーがいるチームにはスクラムをお勧めします。スクラムルールに厳密に従わないと、プロジェクトが失敗する可能性があります。したがって、チーム全体でスクラムの概念を正しく理解する必要があります。スプリントは期間が短く、タイムボックス化されているため、スクラムマスターがプロジェクトを継続的に監視している場合でも、ジョブのスクラムの詳細を学習する時間はありません。