ロール
スクラム チームのメンバーは、3 つのうちの少なくとも 1 つのロールを果たします。 ほとんどの個人は、ソフトウェアを作成する責務のあるチーム ロールを果たします。 さらに、製品所有者は、顧客の意図がチームに反映されるようにし、スクラム マスターはチームと製品所有者がスクラム プロセスに効率的に従うことができるようにします。
このトピックの内容
チーム
チームは、ソフトウェアの作成を担当する個々のユーザーで構成されます。 スプリントの開始時にユーザー ストーリーを選択し、スプリント期間中にユーザー ストーリーの実装とテストに共同で取り組み、スプリント レビュー時に完成したソフトウェアを提供します。 チームは、自己組織化によってチーム自体とその作業をチーム自体で管理し、 メンバーの連携によって製品バックログのユーザー ストーリーを提供するのに必要なスキルを備えます。 MSF for Agile Software Development v5.0 では、エンジニアリング領域や専門分野などの基準でチーム内のロールを分類することはしません。
良いチームとは
良いソフトウェア チームを作るのは困難で、そのための時間もかかります。 外科チーム、バスケットボール チーム、牧羊犬と調教師など、良いチームの例は身の回りでたくさん見つけることができます。 チームのメンバーがそれぞれの特技を持つこともありますが、チームは一体となって動き、成功も失敗もチーム全体のものです。
良いソフトウェア チームも、共通のゴールに向かって協力して働くメンバーから成ります。 ソフトウェア チームは、それぞれが専門のタスクだけを担当する専門家の単なる集団であってはありません。 チームは、各個人のスキルを集約して全体としてさらに優れたスキルおよび専門知識を備えるグループである必要があります。 チームは、コラボレーション、コミュニケーション、信頼、および公開性を通じて成功し、そのメンバーの個人の能力以上の力を全体として発揮することができます。
良いチームは、正しく機能するソフトウェアを提供するために必要な人員およびスキルを備えています。 チームの正規メンバーは、プロジェクトを遂行するのに必要なスキルのほとんどまたはすべてを備えている必要があります。 デザイナー、オペレーション要員、アーキテクト、特定のテクノロジの専門家などの専門分野に特化した個人は、フルタイムで参加できない場合があります。 チームは、外部の専門家を一時的に招くことができます。 ただし、正規のチーム メンバーは、作業を完了するうえで必要なスキルのほとんどをカバーできる人員で構成する必要があります。
チームの主な責務
チームの主要な責務は、完成したソフトウェアに対する顧客の期待とチームの基準の両方を満たすソフトウェアを作成することです。 チームの責務は、スプリント計画会議に始まり、スプリント レビュー会議で終わります。 スプリント計画会議で、チームはユーザー ストーリーをタスクに分割します。 スプリント レビュー会議で、チームは、正しく機能するソフトウェアを製品所有者および多くの場合顧客に提示します。
チームは、その結果についても責任を負います。 選択した作業の定義と実行、およびチーム メンバー間の共同作業をチーム自体で管理して、チームの有効性を最適化します。 チームは、次のアクティビティを通じて、結果の向上に努める必要があります。
完了の基準を定義し、各タスクを完了してから次を開始する。
効果的なエンジニアリング手法を採用する。
詳細については、「エンジニアリング手法」を参照してください。
製品所有者が効果的なユーザー ストーリーを作成し、優先度を付けるのを手助けする。
ユーザー ストーリーを見積もる。
スクラム マスター
スクラム マスターは、スクラム プロセスに従った正常なチームを構築および維持する必要があります。 また、チームが障害に対処できるように支援する役割を担います。
良いスクラム マスターの条件
良いスクラム マスターになるには、優れたコミュニケーション、交渉、および衝突の解決に関するスキルを持っているか、身に付ける必要があります。 チームの発展のために、これらのスキルを毎日用います。 他の人が話すおよび書く言葉を積極的に聞いたり見たりするだけでなく、どのようにメッセージを伝えているか (身ぶり、表情、話す速度、およびその他の非言語的コミュニケーション) に注意する必要があります。 質問をすることで隠れた懸案事項を明らかにし、他の人の発言の内容を確認してください。 これらのスキルを用いて、チームの潜在的な懸案事項を識別し、実際の懸案事項とならないように支援します。 バグは見つけてからすぐに修正する方がコストがかかりません。また、チームの懸案事項は大きくなって制御不能になってからよりも、小さくて扱いやすいうちに修正する方が簡単で混乱が起きません。 チームの生産性を大幅に上げようとするときに、チーム、製品所有者、およびその他のビジネス上の利害関係者が安心できるようにしてください。 チームがどのように改善および成長しているかを示すような方法で、データを収集、分析して、ビジネス上の利害関係者に提示してください。 たとえば、チームが生み出す価値が大幅に増加する一方で、発生するバグが減少している場合、ビジネス上の利害関係者に対してその改善された点を示す必要があります。
スクラム マスターの主な責務
主な責任は、チームと製品所有者がスクラム プロセスに従うようにすることです。 たとえば、毎日のスクラム会議が 45 分間も続くオープンなディスカッションにならないようにする必要があります。 さらに、製品所有者が開始されたスプリントに作業を追加するようチームに依頼することがないようにします。 ユーザー ストーリーが完全には終了していない場合は、スプリント レビュー会議でチームがそれらのストーリーを提示しないようにします。
処理を妨げる懸案事項にチームが直面することがないように支援します。 新しいビルド コンピューターの発注書を承認するなどの小さいタスクを実行したり、チームのメンバー間の衝突を解決するなどの、より大きくて難しいタスクを実行したりする必要がある場合があります。 チームが手間のかかるやり取りに時間を費やしている場合、正常な状態に戻り、将来的により効率的に作業できるよう支援する必要があります。
製品所有者
製品所有者の主な役割は、顧客とチーム間の調整です。 製品所有者は、顧客や利害関係者の意見に振り回されることになります。
良い製品所有者の条件
顧客要件を分析し、これをユーザー ストーリーとしてまとめる必要があります。 顧客が要求する機能と、それらがスケジュールに与える影響について顧客に理解してもらえるように、高い交渉能力が求められます。 顧客と話し合いながら、チームが最も価値のある製品またはシステムをインクリメント方式で生成できるように、製品バックログの優先順位を付ける必要があります。 構築しようとしているシステムのビジネス領域または業種について専門知識を有している必要があります。 たとえば、病院の医療システムを構築するチームには、医療および健康保険におけるバックグラウンドが必要です。 この知識がないと、製品バックログの優先順位を付けたり、製品バックログ項目についてチームに説明したりするときに、効果的に行うことはできません。 また、システム上での資本回収期間、経費償却、および資本予算と経費予算について理解できるなど、基本的な財務知識があることも有用です。 スクラム プロセスとそのコミットメントについて理解していることも、チームの成功にとって重要です。
製品所有者の主な責務
主な責務は、顧客および利害関係者の要件をチームに伝え、チームからの質問に答えることです。 製品バックログを更新し、優先順位を付ける必要があります。 製品バックログを管理するには、顧客、利害関係者、およびチームと定期的にコミュニケーションを取る必要があります。 少なくとも 1、2 週間ごとにミーティングを持つことが必要です。 ユーザー ストーリーの実装順序は、資本回収期間やチームが実行する作業量に影響します。 製品所有者は、ユーザー ストーリーのシーケンスがどのように作業に影響するのかを、チームの手助けを受けて理解します。 そして、これらの順位決定の影響について、利害関係者に理解してもらう手助けをする必要があります。 また、機能の実装方法についてチーム内で疑問が発生した場合に、チーム メンバーからの問い合わせを受けるようにすることで、詳細な仕様書を用意しなくても済むようにします。 チームがスムーズに活動するためには、チームからの質問にすぐに (数時間で) 答えられる必要があります。 これができないと、チームの成果の質が低下します。
注意
仕様書の詳細レベルは、チームが開発しているアプリケーションの種類など、多くの要因によって異なります。 多くのアプリケーションにおいて、適切に作成されたユーザー ストーリーと、オープンなコミュニケーションが、最も効果的な仕様書となります。 ただし、ラボ テストを行うアプリケーションでは、時間の経過と共に発生するさまざまな変更の影響を詳しく分析できるように、詳細な仕様書が必要になる場合があります。
また、チームおよび利害関係者と共に承認テストを構築します。 承認テストにより、特定のユーザー ストーリーが完成し、スプリント レビューにかけることができる状態であるかどうかを判断できます。 チームと利害関係者の両方に対するリスクを理解して特定し、まとめる必要があります。