最適なワークフローの選択
この単元を完了すると、次のことができるようになります。
- 作業の管理にスクラムを使用する場合と Kanban を使用する場合を説明する。
- 割り込み駆動型の作業を定義する。
- 一部のチームが Scrumban を使用する理由を説明する。
Salesforce では 70% のチームがスクラムを使用し、20% が Kanban を使用しています。残りのチームは両方を組み合わせて使用しています。これらは互換的に使用できるツールです。
では、成功するためにどちらのワークフローが適しているかをチームはどのように判断するのでしょうか? スクラムか Kanban か、その両方か? 結局のところ、それはチームが行う作業の種類と、作業がどれほど揮発性で割り組駆動型かによります。それを判断する方法について説明します。
まず、どのワークフローを使用するかを検討するときには、次のことを自問します。
- チームは大きなプロジェクトの予測可能性と生産性に重点を置いているか?
- チームはどの程度先まで計画できるか?
- 新しい作業は本当に緊急か?
- 新しい作業をどれだけ早く完了させる必要があるか?
チームは大きなプロジェクトの予測可能性と生産性に重点を置いているか?
次の 2 つの異なる種類の作業プロジェクトを見てみましょう。
スクラムの事例
チームが新しい Web サイトを作成する必要があると想像してください。チームは作業を小さなプロジェクトに分割できます。小さな作業項目が完了すると、チームは、スプリントごとに進行状況をレビューし、調整を行って、プロジェクト全体が成功するようにします。プロジェクトに予測可能な実行スケジュールが必要な場合は、ワークフローとしてスクラムを使用するのが適しています。
Kanban の事例
チームはサービスの停止に対処する必要がありますか? それが割り込み駆動型の作業の例です。2 週間先のサービス停止について知っていて計画できるとは限りません。アーキテクチャ、サービス、プラットフォームのサポートに従事するチームは、随時発生し、優先順位を変更させるような項目に取り組むことがよくあります。
この場合、Kanban の方が適したプロセスです。Kanban の柔軟なワークフローを使用すれば、このような予期しない停止にも対応できるためです。
チームはどの程度先まで計画できるか?
チームがどれだけの計画を完了し、プロジェクトを達成できるかを決定する必要があります。バックログに大きなプロジェクトを分割した小さな項目が多数あり、事前に計画しやすい場合、チームはスクラムを使用します。
チームの優先順位は頻繁に変更されますか? 一度に 2 週間の作業範囲を決定するのは困難ですか? 25% 以上の作業がスプリントの途中で変更されますか? 事前に通知されない新しい作業項目に対応する必要があるチームには、Kanban の方が適しています。これを割り込み駆動型の作業と呼んでいます。
新しい作業は本当に緊急か?
割り込み駆動型の作業に該当するのはどのようなものでしょう?
理想的には、チームに対する変更を制限できることが望ましいです。新しい作業項目を緊急または優先と分類する前に、チームはいくつかのことを考慮します。
- このプロジェクトによって時間がかかったり士気が下がったりする中断が発生するか?
- この中断によって、チームがより価値の高い作業を完了できなくなるか?
- この中断によって、チームが最も重要なことを最初に完了できなくなるか?
Kanban は、作業が本当に割り込み駆動型でなければチームの役に立ちません。作業が割り込み駆動型であるか、ないか (したがって、スクラムの方が適しているか) を判断するには、次のような方法があります。
- 「この必要な作業はビジネスが停止するようなものか、または今すぐ実行しなければビジネスを失うことにつながるか?」を自問します。そうでない場合も多く、それらの作業項目は計画が適切でなかったために緊急に必要になっています。
- この必要な作業の根本原因は何で、なぜそれが計画フェーズでは特定されなかったのでしょう?
- 事前に計画しなかったためか?
- 新しい関係者またはお客様の要望か?
- 製品が機能していないのか?
その緊急作業が単に不適切な計画の結果であれば、Kanban に移行するほど割り込み駆動型であるとは言えません。
新しい作業項目をどれだけ早く完了させる必要があるか?
優先度の高い割り込みは、競争力が高く成功している会社では日常茶飯事です。重要なことは、それらの緊急割り込みをどのように管理するかです。
ですから、緊急の要望が来たときには、「あなたまたは関係者は、緊急の作業項目が完了するのを、どれくらい待てますか?」と尋ねます。スクラムと Kanban は異なるタイムラインでプロジェクトを処理するため、これを尋ねるのは重要です。できるだけ早く作業を行う必要がある場合は、Kanban を使用した方が混乱が少なくて済みます。
スクラムではバックログの 2 週間という期間に焦点を絞って作業量を制限していることに注意してください。Kanban では、進行中の作業の制限を使用してマルチタスクを防ぐことによって作業量を制限しています。
次の表は、スクラムと Kanban のワークフローの主な違いについて説明したものです。お客様が構築中のアプリケーションに新しい機能を要望したと想像してください。
スクラム | Kanban | |
|---|---|---|
誰が優先順位を付けるか? | 製品所有者が製品バックログで優先順位を付ける。 | 製品所有者が製品バックログで優先順位を付ける。 |
どこへ行くか? | 製品バックログは次のスプリントで並び替えられる。 | 製品バックログは、処理能力があり対応可能な次の人のために、継続的に並び替えられる。 |
いつ作業を開始するか? | スプリントの計画中に、チームは次のスプリントの作業を決定する。 | 作業に取り組むための処理能力があればすぐ開始する。 |
なぜ遅延が発生するか? | スクラムでは、チームがスプリントのコミットメントを完成させることに重点が置かれ、スプリントの途中での割り込みは推奨されない。 | Kanban では、作業の効率的なフローに重点が置かれるため、常にバックログの最上位が次に作業する項目になる。 |
どれだけの時間で成果を出せるか? | スプリントの状況に応じて、2 週間以上。 | 完了し次第すぐ。 |
頻繁に指示を変更し、計画の中断を最小限に抑え、緊急の作業をすばやく開始する必要がある場合は、Kanban を使用します。
大規模に計画されたプロジェクトを管理していて、チームが 2 週間の作業に責任を持つことができ、関係者がチームの作業の開始をスプリントの終了時まで待てる場合は、スクラムを使用します。
両方使用することも可能: Scrumban
Salesforce の多くのチームは、スクラムと Kanban の両方の一部を使用して作業を管理することで、メリットを得ています。チームは定期的な間隔で計画とレビューを行うスクラムの構造を好むことがよくあります。これによって、進行状況を管理しやすくなります。また、Kanban の進行中の作業の制限を使用して、Kanban による中断を最小限に抑えて緊急の作業に対応しています。
このトレイルでは、検査と適応の精神を使用してお客様に最大限の価値を提供するための一般的なテーマと作業方法について取り上げました。
