スクラム方法論: 役割、イベント、アーティファクト

スクラムの方法論は、アジャイルな製品およびソフトウェア開発チームのニーズに適応しなかったウォーターフォール方式などの厳格なプロジェクト管理アプローチへの対応として開発されました。 スクラムの方法論について詳しく説明しますが、その前に、簡単なスクラムの定義から始めましょう。

スクラム方法論とは?

スクラムは、複雑な製品およびソフトウェア開発プロジェクトでのチーム コラボレーションを促進するプロジェクト管理フレームワークです。 良いニュースは、スクラムが理解しやすいことです。 悪いニュースは、マスターするのが難しいことです。

スクラム方法論は、プロジェクト管理におけるチームワークを強調します。 それは説明責任を強調し、明確に定義された目標に向けた反復的な進歩です。 スクラムはアジャイル ソフトウェア開発の一部であり、チームはアジャイルを実践します。 名前はラグビーのスポーツに由来します。スクラムは全員が特定の役割を果たすフォーメーションですが、全員が戦略の迅速な採用に向けて取り組んでいます。

スクラムを成功させるために必要なコラボレーションは、クラウドベースの作業およびプロジェクト管理ソフトウェアである ProjectManager によって促進され、スクラム チームがどこで作業していても接続できます。 当社のプラットフォームはコアと連携してリアルタイム データを提供し、スクラム チームがスプリント中にタスクにコメントしたり、ファイルを共有したりできるようにします。 今日から無料で始めましょう。

スクラム フレームワーク

スクラムは、価値、役割、イベント、成果物で構成されるフレームワークです。 これらの要素が連携して、チームが作業をより適切に管理するのに役立つアジャイルなプロジェクト管理方法論を提供します。 スクラムのフレームワークは単純でなければなりません。 これは、従来のプロジェクト管理方法論ではなく、製品およびソフトウェア開発のフレームワークです。

スクラムの価値

スクラム値という用語は、実際にはスクラム フレームワークに適用されるアジャイル値を指します。 これらは、アジャイルのベスト プラクティスとして機能する単純なステートメントです。 アジャイルの価値観は、アジャイル方法論の指針となる原則を含むドキュメントであるアジャイル マニフェストに由来します。 それらが何であるかを簡単に説明しましょう。

• プロセスとツールよりも個人と相互作用:プロセスとツールはソフトウェア開発において重要ですが、個人と、それらのプロセスやツールとの相互作用の方がより重要です。
• 包括的なドキュメントよりも動作するソフトウェア:アジャイル マニフェストの前は、ソフトウェア開発者はドキュメントに重点を置いていました。 この値は、ドキュメントは重要ですが、ソフトウェアの開発に集中することがスクラム チームの主な目標であるべきであることを示しています。
• 契約交渉よりも顧客の協力:この価値観は、顧客と協力して高品質の製品を作成することが、古いソフトウェア開発の時代に行われていた製品開発を制限する厳格な契約を作成することよりもはるかに重要であることを説明しています。
• 計画に従うよりも変化に対応する:この価値観は、アジャイルとは厳格なプロジェクト計画ではなく、反復的な製品開発サイクルに基づいて変化にシームレスに適応するプロジェクト管理方法論であることを示しています。

スクラムの役割

プロジェクト管理のすべてと同様に、スクラムの方法論では人が実行される必要があります。 この目的のために、スクラム マスター、プロダクト オーナー、および複数のチーム メンバーで構成される開発チームという 3 つのスクラム ロールを定義します。

スクラム マスターは、その名前が示すように、スクラム方法論の専門家です。 彼は、スクラム チームの全員がフレームワークの仕組みを理解し、アジャイル環境への適応を支援することを保証します。 彼はスクラムミーティングをリードしています。

スクラム プロダクト オーナーは、プロダクト ログを管理し、スプリント計画を監督し、スクラム ミーティングに積極的に参加します。 ある意味では、彼らはプロジェクト マネージャーとしての役割を果たします。なぜなら、バックログ グルーミングを主導し、ユーザー ストーリーに優先順位を付けてチームワークを改善するためです。

スクラム開発チームは、ソフトウェアまたは製品を開発するすべてのチーム メンバーで構成されています。 プロダクト オーナーと緊密に連携し、スクラム マスターの提案に従う必要があります。

スクラムイベント

これらのスクラム イベントまたはスクラム セレモニーは、チームのコラボレーションを促進し、製品またはソフトウェアの開発ライフ サイクルを通じて、スクラム チーム メンバー間に一定のコミュニケーション ラインがあることを確認します。

スプリント計画

プロダクト バックログを使用して、チームは最も優先度の高いアイテムから始め、この目的を達成する方法を決定します。 スプリント計画の良いヒントは、デューデリジェンスを行い、準備ができている項目からのみ開始することです。 また、計画は短いプロセスであることを忘れないでください。詳細に行き詰まらないようにしてください。 目標を達成するために取り組むだけです。 計画を協力的に保ちます。 チームは、製品所有者と利害関係者にも質問する必要があります。

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

これらは 15 分間のミーティングで、スクラム チームの全員がその日に取り組む予定のタスクについて話し合い、直面している障害や困難を共有します。 この毎日のスクラム ミーティングを長くする必要はありません。スプリント レビューやスプリント回顧展など、より複雑なトピックを調査するためのミーティングが他にもあるからです。

スプリントレビュー

スプリントを振り返って、何がうまくいき、何がうまくいかなかったかを確認します。 次に、情報を取得して将来のスプリントに適用して、ポジティブな点を再現し、ネガティブな点を減らすことができます。 参加者に感謝の意を表し、簡単な自己紹介を行い、ディスカッションの基本ルールを設定して、スプリント レビュー プロセスを開始します。

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

スプリント回顧会議は、スクラム チームが最後のスプリントを振り返り、何がうまくいったか、何がうまくいかなかったかを判断するためのスペースを提供します。 ユーザー ストーリーに優先順位を付けて製品のパフォーマンスを向上させるために、関係者や顧客からのフィードバックも収集されます。

バックロググルーミング

このサイクルが完了すると、バックログに戻り、優先リストの一番上にある次の準備ができているアイテムを取得して、最初からやり直します。 バックログのグルーミングは、以前の経験に基づいて作業の優先順位を付け、可能な限り効率的にするために作業を継続的に改善することにより、スクラム プロセスを改善することで構成されます。

スクラム アーティファクト

スクラム方法論では、アーティファクトという用語は、スクラム チームがアジャイル環境で製品を開発するために使用する主要な概念を指します。 すべてのスクラム チームが必要とする最も重要なアーティファクト (製品バックログ、スプリント バックログ、製品インクリメント) について説明します。

• プロダクト バックログ:プロダクト オーナーは、実行する必要がある作業のリストを作成し、優先順位に従って並べ替えます。 これは、プロジェクトのバックログを構築しています。 彼らはこれを行うために、必須アイテム、重要度の低いアイテム、および割り当てられた時間枠に収まらないアイテムを決定します。 つまり、各アイテムの価値が明確でなければなりません。 それらの影響、リスク、およびアイテムが学習プロセスにどのように役立つか?
• スプリント バックログ:スプリント バックログは、スクラム チームが 1 つのスプリントで作業する一連のユーザー ストーリーとして簡単に定義できます。 最も重要なユーザー ストーリーが常に取り組まれており、どれも見過ごされていないことを確認することが重要です。
• 製品インクリメント: 製品インクリメントという用語は、スプリント中に完了したすべての製品バックログ項目を指し、完了したすべてのバックログ項目とユーザー ストーリーの合計を表すためにも使用できます。

スクラム方法論の理論は、時間とともに進化してきました。 スクラムの専門家は、実際には 7 つのスクラム成果物があることを示唆しています。 この拡張されたビジョンは、スクラム チームの目標をさらに定義するのに非常に役立ちます。

スクラムの歴史

起源

スクラム プロセスの起源は 1990 年代初頭です。 Jeff Sutherland と Ken Schwaber は、1995 年にテキサス州オースティンで開催された Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) カンファレンスでこのプロセスを発表しました。開発プロセス。"

ただし、スクラムという名前は、1986 年に経営の専門家である竹内博隆氏と野中郁次郎氏によって発表された「The New New Product Development Game」という論文から受け継がれました。 彼らは、プロジェクトの成功のためのチームコラボレーションの重要性を強調する手段として、ラグビーに関連するスクラムという言葉を使用していました.

この論文は、新しい複雑なプロジェクトを開発する際のパフォーマンスが、タスクではなく目的を与えられた小さな自己組織化チームからどのように恩恵を受けるかを示した研究について報告しました。 優れたチームは方向性を与えられたチームですが、それらの目標を達成するための独自の戦術を作成する自律性を備えています

スクラムとソフトウェア開発

次に、スクラム フレームワークは、適応型プラクティスに関するこの研究をソフトウェア開発に適用しました。 その過程で、Schwaber は、プロセス制御研究エンジニアである Babatunde A. Ogunnaike Tunde 教授を採用して、スクラムが他の方法論とどのように連携するかを調べました。

ウォーターフォールやその他の伝統的に構造化されたプロセスなどの方法論は、スクラム フレームワークと整合していないと判断されました。 Tunde 教授は、経験的なアプローチがスクラムで最も効果的なプロセスであると結論付けました。

2001 年までに、Sutherland と Schwaber、および他の 15 人のソフトウェア開発リーダーが、アジャイル ソフトウェア開発のためのマニフェストを作成しました。 その後まもなく、Agile Alliance が設立され、Schwaber が初代会長になりました。 Schwaber は、2001 年に、スクラムに関する最初の本、Agile Software Development with Scrum を Mike Beedle と共著しました。

2000年代のスクラム

スクラム アライアンスは、2002 年に Schwaber 会長が Mike Cohn と Esther Derbry と共に設立しました。 その後、Certified ScrumMaster プログラムを使用して、認定部門を組織に追加しました。 2006 年、Sutherland は Scrum, Inc. を設立し、認定スクラム コースを教え続けています。

スクラム コミュニティの変化は続き、2009 年に Schwaber が Scrum Alliance を離れて、プロフェッショナル スクラム シリーズを提供する Scrum.org を立ち上げました。

それ以来、スクラムは、2010 年にスクラム ガイドが最初に発行され、2011 年と 2013 年に更新され、プロジェクト管理においてグローバルな役割を果たしてきました。現在、プロジェクト管理で最も使用されているアジャイル フレームワークの 1 つとして知られています。

大規模なチームと連携することも増えています。 スクラム オブ スクラムは、スクラムを大規模なグループにスケーリングするためのテクニックの使用に適用されます。

スクラムはアジャイルにどのように適合しますか?

スクラムはアジャイル プロセスの一部ですが、それだけではありません。 アジャイルは大きなテントですが、スクラムは重要な柱です。 スクラムは、アジャイル開発を実装できるフレームワークと考えてください。

アジャイルには従うべき一連のステップがないため、スクラムはプロジェクトにアジャイルを適用する手段を提供します。 エクストリーム プログラミングや機能駆動型開発など、アジャイル開発で使用できるフレームワークは多数ありますが、スクラムのシンプルさと自律性がセールス ポイントです。

スクラムは、他のアジャイル プラクティスへのエントリ ポイントとしても使用できます。 また、ソフトウェアのフレームワークだけでなく、他の多くの種類のプロジェクトにも役立ちます。

スクラム用語集

スクラムのフレームワークを定義する前に、スクラム環境内で作業するときに使用されるより一般的な用語のいくつかの短いリストを次に示します。

バーンダウン チャート:バーンダウン チャートは、時間と比較して多くの労力が残っていることを示します。

バーンアップ チャート:時間に対するメジャーの増加を測定します。

デイリー スクラム:その日の作業に関する短いスクラム ミーティング。

完了の定義: 完了の定義 (DOD) は、7 つのスクラム成果物の 1 つです。 これは、スクラム チームによって合意された受け入れ基準です。

開発チーム:すべてのスプリントに関連する作業を管理する責任があります。

Engineering Standards:プロジェクトの漸進的な開発のための共有基準。

製品バックログ:製品バックログは、特定の順序で行われる作業です。

プロダクト バックログの改良:プロダクト オーナーとチームがプロダクト バックログに詳細を追加すること。バックログ グルーミングとも呼ばれます。

プロダクト オーナー:プロダクトとチームを担当するマネージャー。

スクラム:複雑なプロジェクトでのチーム コラボレーションのフレームワーク。

スクラム ボード:スクラム ボードは、スクラム チームが作業を管理するのに役立ちます。

スクラムバン:スクラムバンは、スクラムとかんばんのプロジェクト管理を組み合わせたハイブリッドな方法論です。

スクラム マスター:スクラム マスターの役割は、専門知識でチームを支援するコーチに似ています。

スクラム チーム:プロダクト オーナー、チーム、およびスクラム マスター。 スクラムの役割の詳細をご覧ください。

自己組織化:プロジェクトの目標の範囲内でのチームの自律性。

スプリント:短いタスクで、1 つのタスクが別のタスクの完了直後に続きます。

スプリント バックログ:チームがスプリントを完了するために必要なもの。

スプリントの目標: スプリントの目的。

スプリント計画:スプリント計画は、スクラム チームが次のスプリントを計画する春のイベントです。

スプリント振り返り: スプリントの簡単な事後分析。

スプリント レビュー: スプリントの短いレビューで、次のスプリントに改善を加えるのに役立ちます。

利害関係者:通常、プロジェクトの開始者である非チーム メンバー。

速度:スプリント中にプロジェクトの増分に変わった製品バックログの平均量。

ProjectManager はスクラム チームを支援します

スクラムの方法論には、コラボレーションと柔軟性が必要です。 クラウドベースの作業およびプロジェクト管理ソフトウェアである ProjectManager は、スクラム チームを結び付け、アジャイル環境で作業するために必要なツールを提供します。 私たちのツールはリアルタイムのデータを提供し、全員がどこにいても、どのように働いていても、プロジェクトでどのような役割を担っていても、常に最新の情報を伝え、コミュニケーションを維持します。

スクラム ボードの作成と管理

当社の複数のプロジェクト ビューは、他の部門がガント チャートまたはシート ビューで共同作業できることを意味します。 ただし、スクラム チームはスクラム ボード ビューを使用します。これにより、ユーザー ストーリーのバックログを管理し、スプリントを計画するときに協力することができます。

また、スクラム ボードは、製品所有者とスクラム マスターに進捗状況を追跡し、潜在的なボトルネックを把握するための可視性を提供します。これは、リソースを再割り当てすることで迅速に解決できます。

リアルタイム ダッシュボードでスクラム ワークフローを追跡する

自己主導型のチームの邪魔をしたくはありませんが、彼らが何をしているかを知る必要があります。 当社のリアルタイム ダッシュボードは、6 つのプロジェクト メトリックを追跡します。 粗悪品のような段取りは必要ありません。 当社のカスタム ワークフローを使用すると、アクションを自動的に設定するトリガーを適用して、チームが自分の仕事に集中できるようになります。 さらに、タスクの承認により、ステータスの変更を制御できます。

スクラム チームと協力する

チームが 1 つの屋根の下で作業している場合でも、複数のタイム ゾーンで作業している場合でも、当社のクラウドベースのツールを使用すると、共同作業を行うことができます。 チーム メンバーはタスク レベルでコメントしたり、そのタスクに割り当てられていない他のメンバーにタグを付けて会話に参加させたり、画像やドキュメントを共有したりできます。 メール通知とアプリ内アラートにより、全員が最新の情報をすぐに入手できます。

当社のソフトウェアはスクラムに理想的であるだけでなく、ウォーターフォールや多くのプロジェクト管理方法のハイブリッドなどの従来の方法論でも機能します。 当社のツールを使用すると、組織内の機敏ではない他の部門と協力できます。 これは、成功を収めるために必要な唯一の作業およびプロジェクト管理ツールです。

ProjectManager は、プロジェクト マネージャーがどのような方法論を選択したかに関係なく、作業のあらゆる段階でプロジェクト マネージャーを支援する独自のプロジェクト管理ソフトウェアです。 クラウドベースであるため、リアルタイムのデータを収集し、チームのコラボレーションを支援するツールを備えており、スケジュールと予算内で維持するための監視と管理を備えたスクラムに必要な自律性をチームに提供します。 この 30 日間の無料試用版を利用して、それがあなたとあなたのチームにどのように役立つかを確認してください。