(オリジナル英語記事 -  Comprehensive Scrum Guide)

スクラムは、チームワーク、説明責任、明確に定義された目標に向けた反復的な進歩を強調するプロジェクト管理のためのフレームワークです。フレームワークは単純な前提から始まります。見られることまたは知られることができるものから始めます。その後、進行状況を追跡し、必要に応じて微調整します。

スクラムの3本の柱

スクラムの基盤は経験主義であり、知識は経験から来るものであり、私たちは知られていることから決定を下すべきです。スクラムを支える3本の柱があります。

スクラムの3本の柱

スクラムの3本の柱

なぜスクラム?

スクラムは一度に機能を提供し、ウォーターフォールは単に段階を提供します。典型的なウォーターフォールスタイルの開発は段階的な段階的なプロセスで、プロジェクトが終了するまで価値がありません。スクラムはそのモデルを頭に入れ、将来大きなリリースに焦点を当てるのではなく、数週間ごとに新しい機能を提供します。

スクラムは複雑な作業を単純な部分に分割し、大規模な組織を小さなチームに分割し、広範囲にわたるプロジェクトをスプリントと呼ばれる一連の短い期間に分割します。

滝とスクラム

滝とスクラム

反復的かつ漸増的に構築することによって、企業は顧客が本当に必要とする製品とサービスをより早くより効果的に提供することができます。スクラムを使用すると、すべての小さな開発サイクルの最後に顧客からのフィードバックを受け取り、組み込むことができます。つまり、結果は実際の使用ではなく、実際の使用によって形成されます。これにより、顧客と主要な利害関係者を密接に関与させ、関与させることがはるかに容易になります。

アジャイル対スクラム

アジャイル手法は、SDLCプロセスにおける開発とテストの継続的な反復を支援するプラクティスです。アジャイルは製品を小さなビルドに分割します。スクラムは、ビジネス価値の提供に最短時間で集中できるようにするため**の、反復可能で逐次的なアジャイルソフトウェア開発プロセスの1つにすぎ**ません。

アジャイル対スクラム

アジャイル対スクラム

スクラムフレームワークは通常、要件が変更される可能性が高い、またはほとんどの場合プロジェクトの開始時にはわからないという事実を扱います。スクラムの特徴は次のとおりです。

  • 軽量
  • わかりやすい
  • 習得が難しい

スクラムの利点

スクラムが組織、チーム、製品、および個人に提供する利点は次のとおりです。

  1. より良い品質:ビジョンや目標を達成するためのプロジェクトが存在します。スクラムは、品質が可能な限り高いことを確認するために継続的なフィードバックと公開のためのフレームワークを提供します。スクラムは以下の慣行により品質の確保に役立ちます
  2. 市場投入までの時間の短縮:スクラムは、エンドユーザーに従来の方法よりも30から40パーセント早く価値を提供することが証明されています。
  3. 投資収益率の向上:市場投入までの時間の短縮は、スクラムプロジェクトがより高い投資収益率(ROI)を実現する主な理由の1つです。収益やその他の目標となるメリットが早くもたらされるため、累積が早いほど、長期にわたって総収益が高くなります。これは正味現在価値(NPV)計算の基本的な原則です。
  4. チームの士気向上:仕事を楽しんでいる幸せな人々と仕事をすることは満足でき、やりがいのあることです。自己管理は、通常マネージャまたは組織によって行われる決定をスクラムチームのメンバーの手に委ねます。
  5. チームコラボレーションの強化:スクラムチームがプロジェクトや製品に責任を負うとき、彼らは素晴らしい結果を生み出すことができます。スクラムチームは、チームの参加とコミュニケーションを強化することで、コラボレーションし、品質とプロジェクトパフォーマンスの所有権を獲得します。

スクラムフレームワーク

スクラムは簡単です。それは織り込まれた必須コンポーネントの大規模なコレクションの反対です。スクラムは方法論ではありません。スクラムは経験的な科学的方法を実行します。スクラムは、予測不可能性に対処し、複雑な問題を解決するために、人と自己組織化を尊重しながら、プログラムされたアルゴリズムアプローチをヒューリスティックアプローチに置き換えます。下の図は、Ken Schwaber氏とJeff Sutherland氏の著書「Software in 30 Days」で説明されているように、計画からソフトウェア配信までを経て作成されたスクラムインアクションを表しています。

スクラムフレームワーク

スクラムフレームワーク

スクラムプロセスの構成要素

スクラムフレームワーク自体は非常に単純です。それは、ほんの少しの規則、役割成果物、およびイベントを含む、いくつかの一般的なガイドラインだけを定義します。それにもかかわらず、これらのコンポーネントのそれぞれは重要であり、特定の目的を果たし、そしてフレームワークをうまく使用するために不可欠です。

スクラムフレームワークの主なコンポーネントは以下のとおりです。

下の図はSCRUMフレームワークの重要な要素を示しています。このプロセスはアジャイルソフトウェアツールであるScrum Process Canvasによって適用されています。

スクラムフレームワーク

スクラムフレームワーク

スクラムの役割

組織がスクラムを採用することにした場合、最初に理解するべきことの1つは、スクラムの役割が従来のプロジェクト実行の役割とどのように異なるかです。スクラムには3つの主要な役割しかありませんが、それらは自動的に私たちのほとんどになじみのあるタイトルと一致しません。それぞれの簡単な定義から始めましょう。

プロダクトオーナー

製品の所有者は、ビジネスまたはユーザーコミュニティを代表する人物にとってのスクラム開発の役割であり、ユーザーグループと協力して製品リリースに含まれる機能を決定する責任があります。プロダクトオーナーの主な責任は以下のとおりです。

  • 短期および長期目標を含む、製品およびサービスの方向性と戦略を策定する。
  • 製品またはサービスに関する知識を提供する、またはそれらへのアクセスを提供する。
  • 開発チームに対する顧客のニーズを理解し説明する。
  • 製品またはサービスの要件を優先順位付けして管理します。
  • 収益性を含め、製品またはサービスの予算に関連するすべての責任を引き継ぎます。
  • 製品またはサービス機能のリリース日を決定します。
  • 毎日、開発チームと協力して質問に答え、決定を下します。
  • スプリントに関連する完成した機能を承認または拒否する。
  • 各スプリントの最後に開発チームの主な実現例を示してください。
  • 製品バックログの責任者

スクラムマスター

スクラムマスターは、アジャイル開発チームの進行役です。スクラムは、アジャイルの原則に従って、チームが自己組織化してすばやく変更を加えることを可能にする方法論です。スクラムマスタは、情報の交換方法に関するプロセスを管理します。スクラムマスターの主な責務は以下のとおりです。

  • コーチとして行動し、チームがスクラムの価値観や実践に従うのを助けます。
  • 障害を取り除き、チームを外部の干渉から保護するのに役立ちます。
  • チームとステークホルダーとの間の良好な協力関係を促進する
  • チーム内の常識を促進する。
  • チームを組織の混乱から守ります。

スクラムチーム

スクラムチーム(別名、開発チーム)は、製品またはサービスを提供するためにすべての技術的ニーズを満たさなければならない3人から9人で構成されています。それらはスクラムマスターによって直接ガイドされますが、それらは直接管理されません。それらは自己組織化され、用途が広く、必要なすべてのタスクを完了するのに十分な責任を負う必要があります。

開発チームは、分析、設計、開発、テスト、テクニカルライティングなど、あらゆるスプリントの可能性を秘めた製品を提供する責任があります。スクラムチームにとって次のような特徴があります。

  • チームは自己組織化する必要があります。与えられた割り当てを完了するために、すべてのチームコンポーネントが独自の努力を管理する必要があります。アジャイルスクラムでは、チームリーダーやラインマネージャーの姿はありません。誰もが自分の活動を実行し、チームの成功に貢献するのに十分なだけの努力を払わなければなりません。失敗すると、みんな失敗します。
  • チームは機能横断型でなければなりません。チームメンバー全員が、うまく機能してすぐに使えるサービスまたは製品を提供するために必要なすべての知識とスキルを一緒に持っていなければなりません。スペシャリストは必要な場合に使用できますが、特定のギャップを埋めるために知識をチームに移すコーチとしてのみ使用できます。
  • 製品の所有者になるには、ビジネスビジョンが必要です。プロダクトオーナーは顧客の声を代表し、彼らのニーズをスクラムマスターチームと開発チームに変換する必要があります。これは通常フルタイムの仕事です。
  • スクラムマスターはラインマネージャーではありません。彼らは必要なコーチを開発チームに提供するのを助け、またチームが直面するあらゆる障壁を取り除くのを助けます。

スクラム成果物

SCRUM成果物は、チームに入ってきて現在チームで作業中のワークロードを定義するのに役立ちます。たとえば、ユーザーストーリー、リリースバックログ、バーンアップチャートなど、他にも多くの成果物があります。ただし、コア3つに集中します。

製品バックログ

製品バックログは、製品チームが必要としている/欲しい機能を提示するユーザーストーリーの集まりです。通常、製品所有者がこのリストを担当します。

スプリントバックログ

スプリントバックログには、現在のスプリントに含めることができるストーリーのコレクションが含まれています。スプリントバックログとスプリントへのアイテムの包含の関係について注意する2つの重要な点。1)チームはスプリントに追加する内容を決定します。したがって、チームはそれらの品目の配達の所有権と責任を引き受けます。2)スプリントバックログからアイテムを削除してスプリントに追加する前に、チームはそれらがバックログ内に必要なすべての情報を持っていることを確認する必要があります。通常、チームはアイテムを追加する前に存在していなければならないアイテムのチェックリストを定義します。

製品バックログとスプリントバックログ

スプリントバックログは、スクラムスプリント中に完了することがスクラムチームによって識別されたタスクの一覧です。スプリント計画会議中に、チームはいくつかの製品バックログアイテム(通常はユーザーストーリーの形式)を選択し、次の図に示すように各ユーザーストーリーを完了するために必要なタスクを特定します。

製品バックログとスクラムバックログ

製品バックログとスクラムバックログ

バーンダウンチャート

バーンダウンチャートは、時間に対する作業のグラフ表示です。未解決の作業(またはバックログ)は、横軸に沿って時間とともに縦軸に表示されることがよくあります。つまり、優れた作業のランチャートです。すべての作業がいつ完了するかを予測するのに役立ちます。スクラムなどのアジャイルソフトウェア開発方法論でよく使用されます。ただし、バーンダウンチャートは、時間の経過とともに測定可能な進捗を含むプロジェクトには適用できます。傑出した作品は、時間またはストーリーの観点から表現することができます。

バーンダウンチャート

バーンダウンチャート

スクラムイベント

コミュニケーションが鍵です!スクラムは、チームの全側面と透過的な作業に依存しています(スクラムの柱#1)。この基本理念を念頭に置いて、この手法は、次の表に示すように、検査と適応という2つの他の柱を確実にするためのいくつかの重要なイベントを中心に構成されています。

イベント

検査

適応

スプリント計画

デイリースクラム

  • スプリントゴールへの進捗

  • スプリントバックログ

  • デイリープラン

  • 製品の増分

  • 製品バックログ(リリース)

  • 市場 - ビジネス環境

  • 製品バックログ

スプリント回顧展

  • チーム&コラボレーション

  • 技術とエンジニアリング

  • 完了の定義

  • 実用的な改善

注:下の図に示すように、各スプリントの実行中にスクラムには5つの主要な会議があります。

スプリント実行

スプリント実行

スプリント計画

すべてのスプリントは計画から始まります。チームは、スプリントの一環としてどのアイテムが配信されるのかを識別し、それにコミットする必要があります。以下の図に示すように、可能なアイテムは常にスプリントバックログから取得されます。

スプリント計画会議

スプリント計画会議

これはスクラムマスターが輝くことができる時間です。製品の所有者は、ビジネス/顧客の観点から彼らが必要とする側面を特定し、SCRUMチームは、彼らが納品できると思うアイテムを特定し、SCRUMマスターは両方を受け入れ、両方の長所を確実に満たします。

デイリースクラムミーティング

チームがスプリントの一環として配信することを約束しているアイテムを特定したら、チームは毎日の立ち上げ会議を開きます。この会議の中心的な目的は、チーム内の全員(およびオブザーバー)に、実行中のタスクのステータスと進捗状況を完全に把握させることです。

  • 彼らがしたこと
  • 彼らが今日やってくるのは
  • それらを止めるもの

デイリースクラムミーティング

デイリースクラムミーティング

この毎日の更新はチームにインスタンスのフィードバックを提供し、提供します。これらの会議は、短く、一人あたり3分以内にぎっしりと開催されることを意味します。

ご了承ください:

観察者は観察するためにそこにいます、SCRUMマスターは可能であればチームへの外部の中断と気を散らすことを軽減しなければなりません。

スプリントレビュー会議

Sprint Review / Demo会議がSprintの最後に行われ、Incrementを検証します。チームはDoneの定義に従ってSprint Goalに重点を置いてIncrementをデモンストレーションします。プロダクトオーナーは、配信された増分を確認して承認します。

スプリント回顧展

スプリント回顧展は通常スプリントで行われる最後のことです。スプリントレビューの直後に多くのチームがそれを行います。スクラムマスターと製品所有者の両方を含むチーム全体が参加するべきです。スクラムの回顧展を最長1時間スケジュールすることができますが、通常はこれで十分です。振り返ってみると、チームは3つの重要な側面を特定することができます。

  1. 何を始めたらいいですか?
  2. うまくいかなかった(そして再びやるのをやめる)何が?
  3. 何が上手くいったのでしょう(そして続けていくべきですか?)

スプリント回顧展

スプリント回顧展

このアプローチの目的は、チームの効率を継続的に向上させることです。

バックログをプロジェクトのロードマップと考えてください。プロジェクトの完成のために構築または実行する必要があるすべてのリストを作成するためにチームが共同作業するとき、プロジェクトの必要なすべてのニーズが満たされるように、このリストを変更してプロジェクト全体に追加できます。

スプリント

スクラムフレームワークでは、スクラム製品バックログからのエントリの実装に必要なすべてのアクティビティはスプリント内で実行されます(「反復」とも呼ばれます)。スプリントは常に短いです:通常約2〜4週間。各スプリントは、以下に示すように定義されたプロセスに従います。

アジャイルスクラムスプリント

アジャイルスクラムスプリント

前述したように、製品バックログ内の項目は優先順位付けされ、スプリントバックログに選択されます。スプリントに含まれる大きなアイテムは少数です。単一のアイテムでも作業を過小評価した場合の影響は、スプリントに大きな影響を与えます。そして、大きなアイテムは見積もりや理解が難しくなる傾向があるので、スプリントが失敗する可能性はさらに高まります。経験豊富なスクラムチームは、複雑で大きな項目(つまり、ユーザーの機能や叙事詩)を小さなユーザーストーリーに分割する(またはその後タスクやサブタスクに分割する)ために時間と労力を費やします。

エピック

叙事詩は仕事の大部分を捕えます。これは本質的に「大規模なユーザーストーリー」で、いくつかの小さなストーリーに分割できます。それは叙事詩を完成するためにいくつかのスプリントがかかるかもしれません。だから我々が開発のために叙事詩を取るとき、それはより小さなユーザストーリーに分解されなければならない。

プロジェクトサイクルの早い段階で、エピックが登場しました。これらは非常に高水準で、マーケティングを中心とした、機能的な点です。

私達はそれらについて何かを伝えるために大きな物語を「叙事詩」と呼びます。私は映画に関してこれを考えるのが好きです。私があなたに言うならば、特定の映画はあなたにその映画について何かを伝える「アクション - アドベンチャー映画」でした。おそらくいくつかのカーチェイス、おそらくいくつかの撮影などがあります。同様に、物語を「叙事詩」と呼ぶことは、時に追加の意味を伝えることができます。

ユーザーストーリー

ストーリーは、製品要件またはビジネスケースの簡単な説明です。通常、ストーリーは、ソフトウェアが何を達成すべきかを読者に理解しやすくするために、わかりやすい言葉で表現されます。製品の所有者はストーリーを作成します。スクラムユーザーは、ストーリーを1つ以上のスクラムタスクに分割します。

ユーザーストーリーは通常、エンドユーザーに表示される機能です。ユーザーストーリーは、「私は何をしたいのですか。ユーザーストーリーは顧客/ユーザーに価値をもたらします。それは顧客/ユーザーからの製品要求です。

たとえば、「顧客として、昨年の購入を確認して来年の予算を確保できるように、アカウントを作成できるようにしたい」としています。

タスク

一方、タスクは、より技術的な性質であり、通常、コードのようなもの、デザインするもの、そのようなもののためのテストデータを作成するもの、自動化するものなどです。これらは一人の人間によって行われることが多いです。タスクはユーザーストーリー形式では書かれていません。タスクにはより技術的な性質があります。

例:「ユーザーインターフェイスのAngularマテリアルデザインを評価する」または「App Storeにアプリを送信する」。

視覚的パラダイムについて

ビジュアルパラダイムは、変化の激しい今日の環境において、組織が競争力を維持しながら変化に迅速に対応できるように支援します。当社の受賞歴のある製品は、中小企業、コンサルタント、世界中の優良企業、大学、政府機関など、32万人以上のユーザーから信頼されています。2018年にアジャイル機能をさらに強化したVisual Paradigmは、スクラムチームがソフトウェアアプリケーションを作成、管理、展開する方法を自動化するためのスクラムプロセスキャンバスを導入しました。これまでにないスピードと規模でチームのパフォーマンスを継続的に向上させることができます。

スクラムプロセス全体を1ページで管理する

  • 目を引く最新のステータスで楽しく楽しいダッシュボードでスクラムフレームワークを自動化します。
  • 1ページの視覚的に実行可能なキャンバスでバックログ、異なるスクラムロールの複数のスプリントを管理
  • 共有キャビネットにアーカイブするためのスクラム成果物および関連文書への即時アクセス、レビューおよび生成を許可する
  • 自明の指示、サンプル、および必要なドキュメントテンプレートを使用して、スクラムイベントと関連アクティビティを自動化します。

コメント

コメントフォーム
記事の評価
  • リセット
  • リセット