プロジェクト管理の青写真パート1：アジャイル、スクラム、かんばん、リーンの包括的な比較

概要

今日のソフトウェア開発では、多くの方法論が使用されています。 ウォーターフォール、アジャイル、スクラム、かんばん、リーン、エクストリームプログラミングなどの流行語を聞いたことがあるかもしれません。

この記事では、これらの用語を定義し、それらが互いにどのように関連しているか、およびそれらが互いにどのように異なるかについて説明します。 前述の流行語の多くは、元々トヨタ生産方式（TPS）に基づいていたリーン生産方式の概念に基づいているため、最初にこれについて説明します。

リーン方法論

リーン生産方式とリーン生産方式の起源

「リーン」という用語は、元々ヘンリー・フォードに触発された豊田佐吉、豊田喜一郎、大野耐一によって開発されたトヨタ生産方式（TPS）に基づく製造モデルを表すために造られた製造に由来します。 TPSは、「すべての廃棄物を完全に排除する」という哲学に焦点を当て、1950年代から1970年代にかけて製造業に革命をもたらしました。 TPSは、「世界を変えた機械」が出版された1990年に「リーン生産方式」として知られるようになりました。

TPSは、トヨタで3つの幅広い種類の廃棄物を特定しました。

• ムダ： 「廃棄物」と訳されています。 トヨタで確認されたムダは7種類あり、8種類が後に追加されました。 これらは：
  • 欠陥：欠陥の発見と修正に伴う努力
  • 過剰生産：需要に先んじて生産
  • 待機中：次の生産ステップ、中断などを待機しています。
  • 未使用の人材：十分に活用されていない機能、不十分なトレーニングなど
  • 輸送：加工に必要のない可動部品または製品
  • 在庫：完成した在庫と仕掛品
  • モーション：処理に必要な以上の動きや歩行

  • 過剰な処理：不十分な工具または製品設計から

• ムリ： 「表土」と訳されています。 ムリは通常ムラから生じますが、ムダから生じることもあります。 ムリは、故障、欠席、安全上の問題などに現れます。
• 村： 「不均一」と訳されています。 Muraは、顧客の需要の変動、製品ごとのプロセス時間、またはさまざまなオペレーターのサイクル時間の変動に見られます。 ムラが減らされない場合、ムリ、したがってムダの可能性が高まります。 サプライチェーンに開放性を持たせ、製品設計を変更し、すべてのオペレーターの標準作業を作成することで、村を減らすことができます。

TPSは、次の2つのコアコンセプトを適用することにより、無駄をなくすように努めました。

• じどか： 「人の手による自動化」と大まかに言い換えると、「製造工程で品質を取り入れなければならない！」と規定されています。 つまり、問題が発生するとすぐに機器が停止し、不良品の発生を防ぎます。
• ジャストインタイム： 「必要なもの、必要なときに、必要な量だけ」を作成します。

TPSが進化するにつれて、これらのコアの柱と価値観は、JidokaとJITの概念に基づいて構築され、定着しました。

• 継続的改善：
  • 課題：長期的なビジョンを形成し、夢を実現するための勇気と創造性で課題に対処する
  • カイゼン：事業運営を継続的に改善し、常に革新と進化を推進し、一度に1つのムダを排除します
  • げんちげんぶつ：げんちげんぶつを練習し、情報源に行き、正しい決定を下し、コンセンサスを構築し、最高のスピードで目標を達成するための事実を見つけます
• 人の尊重：
  • 尊重：他者を尊重し、お互いを理解するためにあらゆる努力をし、責任を負い、相互信頼を築くために最善を尽くします
  • チームワーク：個人および専門家の成長を刺激し、開発の機会を共有し、個人およびチームのパフォーマンスを最大化する
• アンドン：ステータスまたはトラブルの視覚的指標
• 平準化：平準化または平準化を意味します
• 反省：内省を意味します。 効率を改善するために、労働者はより良いものを見つけるために現在のプロセスの背後にある仮定に挑戦する必要があります。
• かんばん：生産を制御するための視覚的なツールとして使用される看板
• ポカヨケ：ミスプルーフまたはエラープルーフとも呼ばれます
• プルシステム：材料は必要に応じてワークステーションに引き込まれます
• セイリ：無駄を映す原理です。 セイリは、不要なものは削除するように指示します。 これには、TPSの元の7つの廃棄物すべてが含まれます
• 標準化：人間の動きを中心にすべてのジョブを整理し、ムダなしで効率的な制作シーケンスを作成します。 これは、品質、一定のペースにつながり、継続的な改善を可能にします。

次の図は、コアコンセプトとコアバリューが互いにどのように関連しているかを示しています。

リーン経営

トヨタ製品システムとリーン生産方式は時間とともに進化し、管理を含む多くの分野で適用されました。

リーン経営は、継続的な改善と人々の尊重というコアバリューを適用し、それを5つの規範的なリーン原則のセットにまとめました。これは、無駄を継続的に改善して排除するために何度も繰り返されます。

1. 値の特定：製品ファミリーごとにエンドカスタマーの観点から値を指定します。
2. バリューストリームのマッピング：各製品ファミリのバリューストリームのすべてのステップを特定し、価値を生み出さないステップを可能な限り排除します。
3. フローの作成：製品が顧客に向かってスムーズに流れるように、価値を生み出すステップをタイトな順序で実行します。
4. プルの確立：フローが導入されたら、顧客が次のアップストリームアクティビティから価値を引き出すようにします。
5. 完璧を求める：価値が指定されると、価値の流れが特定され、無駄なステップが削除され、フローとプルが導入されます。プロセスを再開し、無駄のない完璧な価値が生み出される完璧な状態に達するまで続けます。

リーン管理のこれらの原則およびその他の側面は、Womack＆Jonesが1996年に「リーン思考」を発表したときに形式化されました。

リーンソフトウェア開発

それ以来、リーンは管理、ソフトウェア開発、およびその他の分野に適用されてきました。

1980年代と1990年代に、従来のウォーターフォール手法を使用して実行されたプロジェクトがますます長くかかっていたため、ソフトウェア開発業界は危機に近づいていました。 これにより、ビジネスニーズの特定とソフトウェアソリューションの提供の間に大きな遅れが生じることがよくありました。 この遅れは、航空宇宙産業など、特定の要件を持つ特定の産業では、数年、あるいは数十年で測定されることもありました。

これらの複数年の期間中に、要件、システム、さらにはビジネス全体が変化しました。 多くの場合、プロジェクトは途中でキャンセルされるか、スコープを完了しますが、プロジェクトの開始時に特定されたビジネスニーズを満たさなくなったことがわかります。

ウォーターフォールの方法論は、彼らがおそらく何が必要かわからなかったとしても、彼らが契約を書くことを余儀なくされたので、すべてを考えることに対して利害関係者に報いました。 ウォーターフォールの方法論では、要件または設計段階で決定を下す必要がありました。これらの決定は、契約を変更してプロジェクトにコストを追加せずに変更することは非常に困難でした。 ソフトウェアプロジェクトの大部分が完全に失敗したか、遅れて予算を超えて提供されたか、必要なものを提供できなかった。

この一般的な欲求不満は、ウォーターフォールを改善しようとするさまざまな思考リーダーにつながりました。 初期の例には、プロトタイプを迅速に開発し、ビジネスと協力して要件をさらに開発することにより、要件と設計フェーズを短縮することで無駄を削減することに焦点を当てたRapid Application Development（RAD）が含まれます。 また、小さなプロジェクトが完了し、継続的な反復で機能が追加される反復型開発への動きもありました。 これらの方法論は役に立ちましたが、ウォーターフォールに関連する主要な問題を解決しませんでした。

1990年代から2000年代初頭にかけて、何人かの著者がリーン原則をソフトウェア開発に適用することに関する本を出版しました。 ロバート・シャレット博士は、1993年に「リーンソフトウェア開発」を、2003年に「リーンソフトウェア開発の12の原則」を発表しました。

TomとMaryPoppendieckは、2003年に「リーンソフトウェア開発：アジャイルツールキット」を公開しました。この本では、リーン生産方式の7つの廃棄物に直接関連する、リーン開発の7つの原則について詳しく説明しています。 2つの異なるリーン出版物とアジャイル（次のセクションで説明）の類似点と相違点を次の図に示します。

リーンとアジャイルの違い

Charette博士によると、リーンとアジャイルの主な違いの1つは、アジャイルがボトムアップであるのに対し、リーンはトップダウンであるということです。

アジャイルフレームワーク

アジャイルの起源とアジャイルマニフェスト

CharetteとPoppendiecksが本を出版したのとほぼ同時に、同じ問題を解決するためにアジャイルフレームワークが作成されました。 2001年2月、アジャイルの先駆者のグループがユタ州スノーバードで開催された悪名高いスノーバード会議に集まり、解決策を考え出しました。

その結果がアジャイルマニフェストであり、変化する要件と顧客のニーズに適応し、無駄を削減し、段階的で反復的なアプローチを使用してより迅速に利益を提供しようとする方法論の一連の価値と原則を示しました。

アジャイルマニフェストは次のように読みます。

「私たちは、ソフトウェアを開発し、他の人がそれを行うのを支援することによって、ソフトウェアを開発するためのより良い方法を発見しています。 この作業を通じて、私たちは価値を得るようになりました。

• プロセスとツールを介した個人と相互作用
• 包括的なドキュメントで動作するソフトウェア
• 契約交渉を通じた顧客のコラボレーション
• 計画に従った切り替えへの対応

つまり、右側のアイテムには価値がありますが、左側のアイテムにはもっと価値があります。」

マニフェストの価値観と一致しているのは、アジャイルマニフェストの背後にある12の原則です。

「私たちはこれらの原則に従います。

1. 私たちの最優先事項は、価値のあるソフトウェアを早期かつ継続的に提供することでお客様を満足させることです。
2. 開発の後半であっても、要件の変更を歓迎します。 アジャイルプロセスは、顧客の競争上の優位性のために変更を利用します。
3. 動作するソフトウェアを数週間から数か月まで頻繁に配信し、より短いタイムスケールを優先します。
4. ビジネスマンと開発者は、プロジェクト全体を通して毎日協力する必要があります。
5. やる気のある個人を中心にプロジェクトを構築します。 彼らに必要な環境とサポートを提供し、仕事を成し遂げるために彼らを信頼してください。
6. 開発チームとの間で情報を伝達するための最も効率的で効果的な方法は、対面での会話です。
7. 動作するソフトウェアは、進歩の主要な尺度です。 アジャイルプロセスは持続可能な開発を促進します。
8. スポンサー、開発者、およびユーザーは、無期限に一定のペースを維持できる必要があります。
9. 卓越した技術と優れた設計への継続的な注意が敏捷性を高めます。
10. シンプルさ、つまり行われていない作業の量を最大化する技術は不可欠です。
11. 最高のアーキテクチャ、要件、および設計は、自己組織化チームから生まれます。
12. チームは定期的に、より効果的になる方法を検討し、それに応じて行動を調整および調整します。」

上記の価値観と原則は、Jidoka、JIT、Genchi Genbutsu、Kaizen、Hansei、Heijunkaなどのリーン原則の適用であり、廃棄物の削減です。

ソフトウェア開発に適用されるアジャイル原則

アジャイルは、アジャイルの一連の価値観と原則を適用するすべてのプロセスに適用される包括的なフレームワークです。

いくつかの例は次のとおりです。

• エクストリームプログラミング
• スクラム
• かんばん

スクラム

スカムの簡単な歴史

スクラムは、複数の人々によって別々に発明されたアジャイルの原則を適用するフレームワークであり、そのうちの何人かはアジャイルマニフェストに署名しました。

• 竹内弘高と野中郁次郎は当初、ホワイトペーパー「新製品開発ゲーム」で製造業の文脈で「スクラム」という用語を紹介しました。 1986年にハーバードビジネスレビューに掲載されました。
• Jeff Sutherland、John Scumniotales、Jeff McKennaは、1993年にEaselCorporationでスクラムを実装しました。
• Ken Schwaberは、1990年代に彼の会社であるAdvancedDevelopmentMethodsでスクラムになるものを使用しました。

SchwaberとSutherlandは、1990年代を通じて協力して、ソフトウェア開発のコンテキストでフレームワークを開発および改良し、さまざまな会議で講演しました。 SchwaberはMikeBeedleと協力して、2001年の著書「AgileSoftwareDevelopmentwithScrum」でこの方法を説明しました。

Schwaberはさらに、主要なスクラム認証局の両方を作成しました。

• スクラムアライアンス：2001年に作成されました。認定スクラム認定シリーズを設定します。
• Scrum.org：Schwaberがスクラムアライアンスを去った後、2009年に作成されました。 並行するプロフェッショナルスクラム認定シリーズを設定します。

スクラムはもともと小さなチーム（7人以上またはマイナス2人のメンバー）向けに設計されていたため、時間の経過とともに、スクラムフレームワークの大規模なチームやプロジェクトへのスケーリングに対処するためにいくつかのフレームワーク/認証機関が作成されました。

• SAFe：Scaled Agile Framework
• LeSS：大規模スクラム
• Scrum @ scale：JeffSutherlandによって作成されたScrumat Scale

スクラム値

スクラムアライアンスによると：

スクラムは、チームが短いサイクルで製品を提供するのに役立つ、シンプルでありながら非常に強力な一連の原則と実践であり、迅速なフィードバック、継続的な改善、および変化への迅速な適応を可能にします。

スクラムは、アジャイルの原則を適用するソフトウェアを開発するための、規範的で段階的かつ反復的なフレームワークです。 スクラムの値と原則は、以下のチャートに概説されており、リーンおよびアジャイルの値と原則と大きく一致しています。

スクラムの概要

作業は、スプリントと呼ばれる短いタイムボックスの反復に分割されます。これは通常1〜3週間です。 これは、ウォーターフォールの詳細な計画とはまったく対照的です。 現在のスプリントで計画されている作業は、製品バックログ（Pull System、Heijunka）と呼ばれる作業項目の優先バックログの先頭から選択され、スプリントが開始されると修正されます。 目標は、各スプリントの最後に動作するソフトウェアを用意して、迅速なフィードバックを可能にすることです。

スプリントの最後に、チームは、完了した作業、スプリントがどのように進んだかを確認し、次のスプリントを計画するために集まります。 スプリントの長さ、およびスプリントの儀式とリズムは、スプリントごとに固定されています。

スプリントは、スプリントでの作業を完了するために必要なすべてのスキルを含む部門の枠を超えたチームによって実行されます。 毎日の計画と進捗状況の追跡は、スクラムボードやスプリントバーンダウンチャートなどの視覚的なアーティファクトを使用して行われます。

スプリントでの作業は、優先順位付けされたバックログから取得されます。 これらの方法に従うことで、時間の経過とともに要件を変更でき、エンドユーザーからの絶え間ないフィードバックが促進されます。

以下のマインドマップ図は、次のセクションで説明するScumの主要な概念の概要を示しています。

スクラムの役割

スクラムには3つの役割があります。

• スクラムマスター：スクラムマスターは、スクラムチームの使用人リーダーです。 彼らは、コラボレーションを促進し、障害を取り除き、スクラムプロセスを実施および保護し、チームを保護するチームのコーチです。 これは通常、スプリントの儀式を整理して促進し、プロダクトオーナーが適切に優先順位を付けて手入れをしたバックログを確保し、チームがスプリントに過剰にコミットするように圧力をかけられないようにし、スコープがスプリントに追加されないようにすることを意味します。スプリントは、完了の定義が遵守されていることを確認します。 チームメンバー（元気源部）にはタスクを割り当てず、プロジェクトの実施については責任を負いません。
• プロダクトオーナー：プロダクトオーナーは、製品の配送を担当する「単一の絞り可能なネック」です。 プロダクトオーナーは、構築したいもののビジョンを定義し、そのビジョンをチームと組織に伝えます。 製品の所有者は、ビジネスと市場の要件を所有し、製品のバックログの作成と管理を通じて実行する必要のあるすべての作業に優先順位を付けます。 彼らは、どの機能をいつ出荷するかを決定します。 チームやその他の利害関係者と協力して、製品バックログの項目を全員が確実に理解できるようにします。 彼らは、スプリントデモでスプリントで完了した作業を受け入れるか拒否します。
• チームメンバー：スクラムチームは、通常5〜7人のメンバーで構成される自己組織化されたクロスファンクショナルチームです。 プロジェクトの全員が協力して互いに助け合い、必ずしもアーキテクト、プログラマー、デザイナー、テスターなどの異なる役割に縛られる必要はありません。 全員が一緒に一連の作業を完了します。 スクラムチームは、各スプリントを完了することができる作業量を計画し、計画を所有します（GenchiGenbutsu）。

スクラムフロー、アクティビティ、およびセレモニー

上で説明したように、スクラムには定義されたフローと一連の儀式と活動があります。 スプリントの流れは次のとおりです。

スプリント計画：

スプリントが始まる前に、スクラムマスターは、スプリント計画会議と呼ばれるスクラムチームと製品所有者との会議を促進します。この会議では、製品所有者が次のスプリントの目的を特定し、チームは目的に従って作業を計画します。

これは通常、次のアクティビティで実行されます。

• スプリントキャパシティ：チームは、日数、チームメンバーの数、休日などを考慮して、スプリントのキャパシティを決定します。
• スプリントの目的：製品の所有者は、スプリントの目的を特定します。 製品のバックログが目的に応じて優先順位が付けられ（つまり、関連するストーリーが一番上にある）、手入れが行き届いていることが重要です。
• 作業の選択：ストーリーまたはタスクは、推定容量に達するまで、バックログの先頭からスプリントにプルされます。 ストーリーが引き込まれると、プロダクトオーナーはストーリーを説明し、チームからの質問に答え、プロダクトオーナーとスクラムチームがストーリーをよく理解するまで、必要に応じてストーリーを更新します。 このアクティビティが完了すると、チームは最初のスプリントスコープを提案します。
• タスクの内訳：スクラムチームは、ストーリーをどのように完成させ、すべての受け入れ基準とDoDに対処するかを計画することに重点を置いて、各ストーリーについて詳細に話し合います。 ストーリーを完了するために必要なサブタスクのリストを作成します。 サブタスクのリストが完了すると、ストーリーの見積もりが確認され、必要に応じて更新されます。
• スプリントコミットメント：すべてのストーリーが分解され、見積もりが更新されると、提案された最初のスプリントスコープがレビューされます。 ストーリーはスプリントから削除され、バックログに戻されたり、追加のストーリーが追加されたりする場合があります。 これが完了すると、スクラムチーム（スクラムマスターや製品所有者ではない）のみがスプリントでの作業を完了することを約束し、スプリントが開始されます。

スプリントのためにコミットされた作業または範囲の合計量は、ストーリーポイントで測定されます。

スプリントの実行

スプリント中に、チームメンバーは、スプリントのTo Doリストの一番上から作業項目（ユーザーストーリー、タスクなど）を引き出して作業します。 さまざまなチームメンバーがさまざまな作業項目またはそのサブタスクに取り組みます。 必要に応じて、スクラムボード上でアイテムを1つの列から次の列に移動することで（通常は[実行] >[進行中]>[テスト]>[完了]またはそのバリエーション）、アイテムのステータスを更新します。

進捗状況は、完了し、残りの作業量をストーリーポイントで測定したバーンダウンチャートを使用して追跡されます。 残りのストーリーポイントはY軸に表示され、残りの時間はX軸に表示されます。 ストーリーが完了すると、バーンダウンチャートが更新されます。

毎日、スクラムマスターは以下に焦点を当てています。

• 毎日のスタンドアップミーティングを促進して、その日の計画を立て、進捗状況を確認します（以下を参照）。
• チームがその日の計画を立てていることを確認します
• 障害物を取り除きます
• スプリントスコープとチームを注意散漫から保護します
• チームがバーンダウンチャートやその他のスクラム統計を維持するのに役立ちます

毎日のスタンドアップ

スプリントの毎日の初めに、スクラムマスターは、スクラムチームと製品所有者との短い15分間の会議を促進して、その日の計画を立て、スプリントの進捗状況を確認します。 これは、全員がスクラムボードの前に立って、会議の各人がスプリントボードの特定の項目を参照して、2分以内に次の質問に答える短い会議です。

• 昨日は何をしましたか？
• 今日は何をする予定ですか？
• 仕事を終えるのを妨げる障害はありますか？

これにより、誰もが何に取り組んでいるのか、どのような進歩があったのか、あるいはなされていないのかを確認し、障害や必要な支援を特定することができます。

スプリントの完了

スクラムマスターは、次のスプリントを計画する前に、2つのセレモニーがスプリントを終了するのを容易にします。

スプリントデモ

スプリントの最後に、スクラムマスターは、完成した各ストーリーが製品所有者とチームの他のメンバーに作業ソフトウェアでデモンストレーションされるスプリントデモミーティングを促進します。 プロダクトオーナーは、すべての受け入れ基準が満たされた場合にストーリーを受け入れるか、ストーリーを拒否します。 ストーリーが拒否された場合、不足が特定され、ストーリーは優先順位に従って製品バックログに戻され、後で完了するか、まったく完了されません。 多くの場合、プロダクトオーナーが受け入れないストーリーの部分は、別のストーリーに分割され、元のストーリーは閉じられます。

スプリントごとに完了したストーリーポイントの総数（Velocity）が計算され、スプリントが閉じられます。 速度は、チームの出力レベルを追跡するために使用され、機能またはリリースがいつ完了するかを見積もるために使用されます。

スプリント回顧展

スプリントデモの後、次のスプリント計画会議の前に、スクラムマスターは、チームが完了したばかりのスプリントを振り返り、何がうまくいったか、何がうまくいかなかったかについて話し合うスプリント回顧展を促進し、プロセスを継続的かつ段階的に改善できるようにします時間の経過に伴う品質（Kaizen、Hansei）。 チームが議論を生み出すのを助けるために使用できる回顧的な形式や演習がたくさんあります。

改善アクションアイテムのリストが作成され、アイテムが製品バックログに追加されたり、DoDまたはチーム憲章が変更されたりする場合があります。

製品バックログ管理

製品バックログの作成

スプリントを計画または実行する前に、製品所有者は作業の製品バックログを作成する必要があります。 バックログは通常、製品所有者によって書かれたストーリーと呼ばれる機能開発アイテムから始まり、時間の経過とともに、チームのメンバーによって作成される可能性のある開発またはQAタスク、スパイク、欠陥などが追加されます。 バックログのすべてのアイテムは優先順位に従って配置されます。

バックロググルーミング

最初の製品バックログが作成され、優先順位が付けられると、進行中のバックロググルーミングプロセスが引き継ぎます。 目標は、スプリント計画会議中にスプリントに引き込まれる準備ができるように、少なくともバックログの上位アイテムを常に十分に手入れして推定することです。 これは通常、スクラムマスターが進行役を務める製品マネージャーおよびチームと定期的に継続的なバックロググルーミングミーティングを行うことによって行われます。

ミーティングの前に、ストーリーのリストがチームに送信され、グルーミングミーティングのレビューと準備ができるようになります。 グルーミングミーティングでは、受け入れ基準、複雑さ、リスク、サイズ、実装戦略などの観点から各項目が議論されます。受け入れ基準およびストーリーの他の詳細は、チーム、製品所有者、およびスクラムマスターまでレビューおよび改訂されます。ストーリーを共通に理解している。 その時点で、ストーリーはプランニングポーカーと呼ばれる手法を使用してストーリーポイントで推定されます。

ストーリーポイントの見積もり

ストーリーポイントは、ストーリーが以前の既知のよく理解されている作品と比較される相対的なサイズ設定を使用する作業の単位です。 あなたはいつも、他の作品と「この物語は大きいのか、小さいのか、それともほぼ同じサイズなのか」という質問をしています。

フィボナッチスケール（1、2、3、5、8、13、21…）は最も一般的に使用されるスケールであり、各増分は前のスケールの約2倍です（つまり、5ポイントのストーリーは多かれ少なかれ2倍です）スリーポイントストーリーとしては大きい）。 Tシャツのサイズ（XS、S、M、L、XL）や魚（ミノー、金魚、マス、マグロ、クジラなど）のような他のスケールが使用されることもあります。 何かのサイズを別のサイズと比較できるスケールであればどれでも機能します。

ストーリーポイントは、開発、テスト、設計、および完了の定義に必要なその他のタスクを含む、ストーリーを実装するためのチームの全努力を表しています。 見積もりでは、作業量、複雑さ、およびリスクが考慮されます。 ストーリーの相対的なサイズが決定されると、スケール上のサイズが見積もりとして割り当てられます。

チームは、チーム全体が参照ストーリーとして理解する「最も中程度」のサイズのストーリーを選択することにより、最初に推定のベースラインを確立することにより、ストーリーポイントの推定プロセスの準備をします。 大きくなったり小さくなったりするいくつかの追加のリファレンスストーリーも選択されています。

ストーリーポイントの見積もりは、グルーミングミーティング中に行われ、PlanningPokerを使用したスプリント計画中に行われることもあります。

1. 各チームメンバー/見積もり担当者は、カードのセットを持っています。
2. バックログ項目は、上記のように一度に1つずつ説明されます。
3. 項目が完全に議論されると、各見積もり担当者は、見積もりを表すカードを個人的に選択します。
4. すべての見積もり担当者が見積もりを行うと、同時にカードを公開します。
   • すべての見積もりが一致する場合、見積もり担当者は別のバックログアイテムを選択し、同じプロセスを繰り返します。
   • 見積もりが異なる場合、見積もり担当者は問題について話し合い、合意に達します。

ストーリーポイント推定の利点は次のとおりです。

• クイック：見積もりは、すでに完了した製品バックログアイテムに関連しています。
• 十分に正確：範囲の概要を示し、将来の作業を計画し、優先順位を付け、期待を管理するのに十分正確です。
• 不確実性を受け入れる：ストーリーポイントは未知の時間範囲を指定します。 ストーリーポイントの特定のフィボナッチのようなシーケンスから選択すると、不確実性を捉えることができます。
• チームスポーツ：すべての人（開発者、設計者、QA、製品マネージャー）が参加します。 複数の視点を使用して作業のサイズを決定しますが、作業を行うチームメンバーのみが見積もりを行うことができます
• チーム速度の測定：チームがスプリントで行う作業量と、作業に費やした時間の量を測定します。 チームが向上するにつれて、同じサイズのストーリーをより早く完成させ、時間の経過とともにストーリーポイントの速度を上げることができます。

リリースの見積もりと追跡

ストーリーポイントの見積もりは、次の手法を使用したリリース計画のコンテキストでも使用されます。

1. サイズ設定するすべてのストーリーを一覧表示します
2. 小さいものから大きいものの順に並べてください
   • 1番目と2番目のユーザーストーリーを取り上げます。
   • どちらが大きいかを決定し、大きい方を下に置きます
   • 次に、次の1つを取り、他の2つと比較してどこに収まるかを決定します
   • すべてのストーリーがリストに含まれるまで（最小から最大の順序で）このプロセスを繰り返します。
3. ストーリーのサイズを変更する

チームの速度と組み合わせたリリース内のすべてのストーリーのストーリー推定により、リリースがいつ完了するかを推定し、その進行状況を追跡できます。 これは、リリースバーンアップチャートによく示されます。

スクラムアーティファクトと用語

• 製品バックログ：特定の製品のすべての作業項目のバックログリスト。機能（ストーリー）、技術タスク、スパイク、および欠陥を含めることができます。
• リリースバーンアップ：リリースレベルでの進行状況を示し、SprintVelocityを使用してリリースがいつ終了するかを予測するために使用されるグラフィカルチャート。 完成したストーリーポイントはY軸に表示され、スプリントはX軸に表示されます。
• スプリントバックログ：特定のスプリントで完了するすべての作業項目のバックログリスト。 スプリントバックログの内容は、スプリント計画会議で合意されます。
• スクラムボード：スプリントのためにコミットされた作業の進行状況を追跡するテーブルスタイルのボード。 ステータスは上部の縦の列に表示され、作業項目は完了するまで各ステータス間を移動します。 スクラムボードは、スプリント計画会議中に入力され、スプリントの終了時にリセットされます。
• スプリントバーンダウン：スプリントの長さ全体にわたってストーリーポイントで測定された完了および残りの作業の量を示すグラフチャート。 残りのストーリーポイントはY軸に表示され、残りの時間はX軸に表示されます。
• スプリント速度：スクラムチームがスプリントで完了するストーリーポイントの数。
• 障害物のバックログ：チームが作業を継続できるようにするために、スクラムマスターが対処する必要のある障害物のリスト。 チームメンバーがブロックされると、チームとスクラムマスターに可視性を提供するために、障害物のバックログにアイテムが追加されます。
• エピック：エピックは、複数の関連するユーザーストーリーで構成される大量の作品です。
• ユーザーストーリー：ユーザーストーリーは、エンドユーザーの観点からのソフトウェア機能の説明です。 ユーザーストーリーは、ユーザーのタイプ、ユーザーが望むもの、およびその理由を説明します。 ユーザーストーリーは、要件の簡単な説明を作成するのに役立ち、受け入れ基準が含まれています。 ユーザーストーリーは、プロダクトオーナーによって作成および維持されます。
• タスク：タスクは、スクラムマスターまたはチームメンバーによって入力される作業の一部であり、ユーザーストーリーに直接または間接的に関連している可能性があります。 それらは通常、本質的に技術的なものであり、受け入れ基準が含まれます。
• スパイク：スパイクは、ユーザーストーリーを実装または推定する方法を決定する前に、調査、プロトタイプ作成、および/またはアーキテクトが必要な場合に使用される特殊なタイプのタスクです。
• サブタスク：サブタスクは、ユーザーストーリーまたはタスクを完了するための実装ステップとして入力されるタスクです。 それらは通常、スプリント計画会議中にチームによって入力されます。
• ストーリーポイント推定：フィボナッチスケールに基づく相対的なサイズ推定スケール（1、2、3、5、8、13、21…）
• 受け入れ基準：プロダクトオーナーがストーリーの完了を受け入れる前に完了する必要がある、すべてのストーリーに含まれるストーリー固有のテスト可能なアイテムのリスト。
• 完了の定義（DoD）：ストーリーが完了したと見なす前に完了する必要がある一般的な手順または基準のリスト。 チームはこれに同意し、すべてのストーリーにリストされる必要がないように文書化します。

スクラムの長所と短所

スクラムの主な利点は、アジャイルの価値観と原則、およびSeiri、Jidoka、Just-in-Time、Kaizen、Genchi Genbutsu、Heijunka、Pull System、Iterationsなどのリーンコンセプトを適用できることです。 これらの原則を適用することで、プロジェクトチームは継続的なフィードバックを受け取り、変化する要件と不確実性に迅速に適応し、無駄を減らし、可視性と透明性を高め、継続的な改善に努めることができます。 スクラムは、製品バックログの最も重要な項目に常に焦点を合わせ、常に機能するソフトウェアを生成する短い反復でのみ機能することにより、顧客に焦点を合わせ、顧客が好きなもの（および嫌いなもの）を確認し、必要に応じて変更を加えることができます。 プロセスと管理のオーバーヘッドコストが小さいため、より迅速で安価な結果が得られます。

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

かんばん

かんばんとは？

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

かんばんvs.スクラム

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.