アジャイル開発手法の1つであるスクラムは、明確な目標に向けたチームワーク、説明責任、反復的な進捗に力点を置いたプロジェクト管理のフレームワークです。スクラムの3つの柱は、透明性、検査、適応です。
次のような場合は、スクラムを使うことをおすすめします。
プロジェクトの要件が変化し、発展する場合
継続的なフィードバックが要求される場合
確定したリリース日を約束する必要がない場合
プロジェクトチームが自律性を要求する場合
スクラムは、不明な点が多いプロジェクトや、時間の経過とともに進化するプロジェクトに適しています。スクラムではこれらの変更を非常に効果的に処理できるので、新しい情報や機能に簡単に対応できます。
スクラムチームには、3つの特定のロールと1つの任意のロールが必要です。
プロダクトオーナー
スクラムマスター
開発チーム
カスタマー(任意)
これらの3つのロールは同等であり、それぞれに特定の責任があります。
ロールと責任 | ||
|---|---|---|
プロダクトオーナー | カスタマーとビジネスを表します。
| |
スクラムマスター | チームが価値を提供するために必要なすべてのものを持っていることを保証します。開発チームの使用人リーダーとして行動します
| |
開発チーム | 動作するソフトウェアの納品に注力します。 開発チームは、部門の枠を超え、自己管理され、自己組織化された専門チームです。その自律性はスクラムをユニークなものにし、プロセスの中核となります。このアプローチからは、強力なチームの絆と、人々が仕事に力を与えられていると感じる前向きな職場環境が生まれます。
| |
カスタマー カスタマーはプロダクトオーナーの場合もあるので任意 | 社内での開発ではほとんどの場合、カスタマーはプロダクトオーナーです。 社外での開発では、カスタマーは以下の責任を負います。
|
 |
アジャイルでは、プロジェクトはイテレーションで進みます。各イテレーションの内容(イテレーションバックログ)は、ビジネスバリュー、エピック、過去のベロシティ(ストーリーポイントを納品する能力)を考慮したバックログ項目リストを定義することで、スクラムマスターとプロダクトオーナーが提案します。これをイテレーション計画ミーティングと言います。
提案された内容をチームメンバーと協議し、チームがイテレーションバックログをコミットできるよう、ストーリーポイントの見積もりをレビューします。プランニングポーカーをはじめ、このミーティングを実施する方法はいくつかあります
イテレーション中、チームは毎日短い時間ミーティング(デイリースクラムミーティング)を行い、進捗状況だけでなく、あらゆる問題や技術的な困難について話し合います。
イテレーションの最後には、完成したすべての要素を(リリースの一部として)出荷する準備ができている必要があります。イテレーション中に遭遇した困難について報告し、ベロシティを確認し、次のイテレーションのための改善を話し合うための事後会議を実施する場合があります。
プロダクトバックログには、将来のリリースでプロダクトに加える変更となるすべての特徴、機能、要件、強化、修正をリストアップします。プロダクトバックログは、ウォーターフォール手法に見られる要件定義に代わるものです。
プロダクトバックログには、次の特徴があります。
それぞれがカスタマーに付加価値を与える必要がある。
プロジェクト中、いつでも変更が発生する。
低レベルのタスクを説明する必要はない。
優先順位をつけ、プロダクトバックログの順番を決める。
通常は、すべてストーリーポイントで見積もる。
プロダクトオーナーは、プロセスの進行中でもプロダクトバックログをメンテナンスすることが要求されます。
プロダクトバックログは、バックログ項目で構成されます。
バックログ項目は、チームが1回のイテレーションで完了できる程度の小さな作業単位です。バックログ項目は、タスクに分割されます。
ユーザー目線のバックログ項目をプロダクトバックログに入れることができます。この場合、プロダクトバックログは、ユーザーストーリーのかたちで記述されます。
ユーザーストーリーは、高レベルの要件定義であり、開発者がそれを実装するための工数を見積もることができるだけの情報を含んだものです。ユーザーストーリーは、堅実でコンパクトな表現を使い、ユーザーの視点から説明された機能です。特定のクラスのユーザーのニーズと、得られる価値を反映したもので、非常にシンプルなフォーマットを使用します。
“<特定のクラスのユーザー>として(役割)、<何らかの価値あるいは利益を得る>ために(目的)、<何かを実行できる>ようになりたい(要望)。"
 |
ただし、ユーザーストーリーの作成は必須ではありません。バックログ項目は、プロジェクトチームとステークホルダーが理解できる限り、少しのキーワードや短い文章で入力することもできます。
 |
イテレーション計画ミーティングには、プロダクトオーナー、スクラムマスター、プロジェクトチーム全員が参加します。まれですが、外部のステークホルダーが招待されて出席する場合もあります。
イテレーション計画ミーティングでは、プロダクトオーナーはチームに最も優先度の高い機能について説明し、イテレーションの目標を定義します。次に、優先順位をつけ、見積もりを行った後、そのイテレーションで作業するバックログ項目を決定します。
イテレーションは、継続的な開発サイクルでのタイムボックスイベントです。イテレーション内で、チームは計画された量の作業を完了し、レビューの準備を整える必要があります。この用語は主にスクラム手法で使用されます。アジャイルアプローチでの一般的な用語は、(Sciformaでも採用されている)イテレーションです。
イテレーションの平均的な長さは、2から4週間です。
スクラム手法を使う場合、作業見積は時間ではなく、ストーリーポイントで行います。
ストーリーポイントは、バックログ項目またはその他の作業を完全に実装するために必要な総工数の見積もりを表す測定単位です。ストーリーポイントで見積もる場合、各バックログ項目にポイント値が割り当てられます。
ストーリーポイントの見積もりには、よく次のようなスケールが使われます。
フィボナッチ数列（0.5、1、2、3、5、8、13、21...）
直鎖状配列（1、2、3、4、5、6、7、8…） – Sciformaで使用
共同作業となるため、プランニングポーカーを使う企業もあります。
プロダクトオーナーは、見積もる必要のあるバックログ項目を紹介します。チームメンバーは質問をし、プロダクトオーナーが詳細を説明します。
チームメンバーは、配られたカードの中から自分が見積もった数字を選択します。
すべてのチームメンバーの見積もりが終わったら、同時にカードを公開します。全員が同じカードならば、新しいバックログ項目を選択し、同じプロセスを繰り返します。異なる場合は、合意に達するまで話し合います。
バックログ項目の見積もりが終わったら、ストーリーポイントをチームベロシティと比較します。
チームベロシティは、完了した実際のストーリーポイントに基づいたもので、通常は過去のすべてのイテレーションの平均値です。チームベロシティは、次のイテレーションで計画し、完了できるバックログ項目の数を計画するために使用されます。
ただし、次のイテレーションに入れることができるバックログ項目を知るには、プロジェクトチームキャパシティも考慮する必要があります。キャパシティとは、イテレーションに対してどれだけの可用性があるかです。したがって、チームメンバーが休暇中、病気などの理由で変化します。
イテレーションバックログは、プロダクトバックログのサブセットです。イテレーションバックログは、プロダクトバックログから選んだ、そのイテレーションで完了できるバックログ項目です。
プロダクトバックログとは異なり、イテレーションバックログはイテレーション期間中は変更されません。イテレーション計画が終わると、バックログ項目とそれを完了するための手順は、イテレーションの期間中凍結されます。イテレーション終了時に未完成のバックログ項目がある場合、それはプロダクトバックログに追加され、次のイテレーションで対処されます。
大まかに言えば、プロジェクトはエピック、テーマ、または機能としてスタートし、その後バックログ項目に分解されます。
タスクは、必要に応じてバックログ項目をさらに細分化するために使用されます。タスクは、作業を追跡するための最小単位です。タスクは、チームの1人が完了できる作業です。通常、各バックログ項目には複数のタスクが関連付けられています。クロスファンクショナルチームなので、1つのバックログ項目のタスクを請け負うことで、チームメンバーは自分の専門知識の領域で並行して作業し、チームとして項目を完了することができます。
したがって、バックログ項目をタスクに分割することは、実行する作業にどのようにアプローチするかを決定するのに役立ちます。このレベルまでくると、未知の問題も明らかになります。
デイリースクラムミーティング(別名デイリースタンドアップミーティング)の目標は、何が起こっているかをチーム全員にすぐに知らせることです。15分にタイムボックス化されたミーティングでは、スクラムマスターが各チームメンバーに次の3つの質問をします。
昨日、何をやったか
スクラムマスターは、どのタスクが「完了」しているか、進行中のタスクが期待どおりに完了するかどうかを知りたいと考えます。見積もりが増えたり、新しいタスクが発見された場合、バーンダウンチャートが変更されます。
今日、何をするか
この質問は、ガントチャートに代わるものです。依存関係は常に変化しています。この質問に答えると、前の質問で明らかになった依存関係の変更に応じてチームの方向を変えることにより、プロジェクト戦略が毎日見直されます。
作業を妨げる障害物があるか
この質問の最も重要な効果は、チームに割り当てられた、またはエスカレーションされた障害のリストを作成することです。スクラムマスターの主な責任は、バックログを管理し、優先順位を付けて、この障害が完全に解消されることを保証することです。
タスクボードとは、イテレーションのプロジェクトチームの進捗状況を視覚的に表示したものです。現在のイテレーションバックログのスナップショットが表示され、まだ開始されていないタスクとバックログ項目、進行中、実行済みの項目を確認することができます。
タスクボードは、デイリースクラムミーティング中に毎日更新されます。
 |
バーンダウンチャートは、残された作業と時間の関係をグラフで表したものです。
 |
チャートのX軸は常に時間(通常は日数)を示します。
Y軸は、イテレーションの残りの作業を表します。これは、残りのタスク(タスク数)または残り工数(ストーリーポイント/時間)のどちらかで表されます。
進捗ラインは、イテレーションの進捗状況を示します。これは、残り作業の見積もりに応じて毎日更新されます。イテレーションが進むにつれて、チームが順調に進んでいるかどうか、修正措置が必要かどうかが示されます。
ガイドラインは、グラフの左から右に下向きに描かれた対角線です。イテレーションの進捗ラインは、理想的にはガイドラインにできるだけ近いものにする必要があります。チームがイテレーション全体を通して一定のペースですべてのストーリーを完了することができれば、進捗ラインはガイドラインとほぼ重なります。
イテレーション進捗ラインがガイドラインより上にある場合は、プロジェクトチームが予定より遅れており、さらに多くの作業を完了する必要があることを意味します。
イテレーション進捗ラインとガイドライン接近している場合、プロジェクトチームがそのベロシティを維持すれば、すべての作業が完了することを意味します。
イテレーションの進捗ラインがガイドラインより下にある場合は、プロジェクトチームが予定より進んでおり、イテレーションの終了日までにすべての作業を完了することを意味します。この場合、イテレーションに新しいバックログ項目を追加し、イテレーションの終了日まで確実に作業をするようにすることができます。
イテレーションの終了時に、プロダクトオーナーはプロジェクトチームと主要なステークホルダーをイテレーションレビューミーティングに招待します。この会議では、完了した作業について全員がフィードバックを提供できるよう、デモを行って結果を検査します。
イテレーションレビューの目的は、ステータスの更新やステークホルダーへのプレゼンテーションを提供することではありません。現在のインクリメントに関するフィードバックを収集し、処理することです。
イテレーションレビューミーティングの典型的なアジェンダは次のとおりです。
プロダクトオーナーが、完了したバックログ項目と未完了のバックログ項目について説明します。
プロジェクトチームは、イテレーション中に何がうまくいったか、どのような問題が発生したか、どのようにそれを解決したかを話し合います。
プロジェクトチームは、「完了」した作業をデモンストレーションし、インクリメントに関する質問に回答します。
プロダクトオーナーは、現状のプロダクトバックログについて話し、必要に応じて、進捗状況に基づいたプロジェクトの目標日と納期を予測します。
次に何をすべきかをグループ全体で協議するイテレーションレビューは、今後のイテレーションバックログに貴重な情報を提供します。
イテレーションレトロスペクティブ(振り返り)分析は、イテレーションレビューの後、次のイテレーション計画の前に行います。この会議は終了したばかりのイテレーションについて話し合うため、プロジェクトチーム、スクラムマスター、プロダクトオーナーが参加します。
チームメンバーにとっての振り返りの目標は、直前のイテレーションで作業をどのように進めたかを互いに話し合い、プロジェクトの目的を達成し、生産性を向上するためのより良い方法を見つけることです。すべてのメンバーが失敗と今後の改善について話し合い、学んだ教訓を追跡します。
イテレーションレトロスペクティブ分析は、ウォーターフォールのポストモーテム会議と比較できます。ただし、プロジェクトの終了時ではなく各イテレーションの終了時に行うため、プロセスをより頻繁に調整し、小さな改善を定期的に実装することができます。
アジャイル組織は、市場や環境の変化に迅速に対応する組織です。高度なアジャイル組織は、新しい競合他社の出現、テクノロジーの急速な進歩、全体的な市況の突然の変化にうまく対応します。
アジャイルチームではないものは?
アジャイルチームは、タスクフォースなど、ビジネスのさまざまな分野のさまざまな人々で構成される単なるプロジェクトチームではありません。
アジャイルチームは、開発者だけではなく、マトリックスチームでもありません
アジャイルチームとは?
アジャイルチームとは、外部のスキルに頼らずにプロダクト(またはプロダクトの次のイテレーション)を提供できる程度に自己完結している人々で構成されるクロスファンクショナルグループです。
 |
アジャイルチームは、別の作業の優先度が高いという理由だけでプロダクトやチームを移動しない人々の専任グループです。
アジャイルチームは自己組織化されています。したがって、必要に応じてチームメンバーを交換、再トレーニング、再編成することにより、機能的な内部チーム構造を作成する責任と権限を持っています。
アジャイルチームは自己管理されています。チームメンバーは、監督されていない状態でも、活動を計画、実行、監視、管理する責任があります。
アジャイルは適応性のあるアプローチと考え方であることを覚えておいてください。プロジェクトでアジャイルが機能するように組織を適応させるのは、各企業の責任です。
