アジャイル

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

概要概要

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

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

リーン方法論

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

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

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

若い： 「廃棄物」と訳されています。トヨタで確認されたムダは7種類あり、8種類が後に追加されました。これらは：
- 欠陥： 欠陥の発見と修正に伴う努力
- 過剰生産： 需要に先んじて生産
- 待っています： 次の生産ステップ、中断などを待っています。
- 未使用の才能： 十分に活用されていない機能、不十分なトレーニングなど
- 輸送： 加工に不要な可動部品や製品
- 在庫： 完成した在庫と仕掛品
- モーション： 処理に必要な以上の移動または歩行
- 過剰な処理： 貧弱な工具や製品設計から
に：「表土」と訳されています。ムリは通常ムラから生じますが、ムダから生じることもあります。ムリは、故障、欠勤、安全上の問題などに現れます。
場合： 「不均一」と訳されています。 Muraは、顧客の需要の変動、製品ごとのプロセス時間、またはさまざまなオペレーターのサイクル時間の変動に見られます。ムラが減らされない場合、ムリ、したがってムダの可能性が高まります。サプライチェーンに開放性を持たせ、製品設計を変更し、すべてのオペレーターの標準作業を作成することで、村を減らすことができます。

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

Jidoka: 「人の手による自動化」と大まかに翻訳すると、「製造工程で品質を組み込む必要があります！」と規定されています。つまり、問題が発生するとすぐに機器が停止し、不良品の発生を防ぎます。
ジャストインタイム： 「必要なもの、必要なとき、必要な量」だけを作る。

TPSが進化するにつれて、これらのコアの柱と価値観は、 Jidoka そして JIT そして定着した：

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

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

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

リーン経営

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

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

リーン管理の5つのリーン原則。

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

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

リーンソフトウェア開発

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

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

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

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

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

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

トムとメアリーポッペンディークが出版「リーンソフトウェア開発：アジャイルツールキット」この本は、リーン製造における7つの廃棄物の形態に直接関連するリーン開発の7つの原則を詳述しています。 2つの異なるリーン出版物とアジャイル（次のセクションで説明）の類似点と相違点を次の図に示します。

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

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

目標

シャレットのリーンソフトウェア開発	アジャイルマニフェスト	ポッペンディークのリーン
1/3人間の努力 1/3開発時間 1/3時間 1/3投資 1/3適応する努力	個人と相互作用動作するソフトウェア顧客とのコラボレーション変化への対応

原則

シャレットのリーンソフトウェア開発	アジャイルマニフェスト	ポッペンディークのリーン
顧客満足お金の価値お客様の参加チームの努力すべてが変更可能ポイントソリューションではなくドメイン完了、構築しないでください今日の80％ソリューションミニマリズムは不可欠です技術を決定する必要性製品の成長は機能の成長です限界に注意	顧客満足要件の変更を歓迎します頻繁な配達サイクル利害関係者のコラボレーション信頼、サポート、モチベーションの文化対面コミュニケーション動作するソフトウェアはメトリックです持続可能な発展技術的な卓越性シンプルさ自己組織化チームチームの振り返り	無駄をなくす学習を増幅するできるだけ早く配信するできるだけ遅く決定するチームに力を与える製品の整合性を構築するプロセス全体を見る

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

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

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

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

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

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

個人と相互作用 プロセスとツールを超えて
動作するソフトウェア 包括的なドキュメント以上
顧客とのコラボレーション 契約交渉
変化への対応 計画に従うことを超えて

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

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

「私たちは次の原則に従います。

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

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

ウェブデザインでcmsはどういう意味ですか

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

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

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

エクストリームプログラミング
スクラム
Kanban

スクラム

スカムの簡単な歴史

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

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

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

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

スクラムアライアンス：2001年に作成されました。 認定スクラム 認定シリーズ。
Scrum.org ：SchwaberがScrumAllianceを去った後の2009年に作成されました。パラレルを設定する プロのスクラム 認定シリーズ。

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

erisbotdiscordの使い方

安全：スケーリングされたアジャイルフレームワーク
もっと少なく：大規模スクラム
[メール保護] e：ジェフサザーランドによって作成された大規模なスクラム

スクラム値

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

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

スクラム値の図

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

スクラムの原則の図

スクラムの概要

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

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

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

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

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

スクラムの主要な概念を概説するマインドマップ図。

スクラムの役割

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

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

スクラムの役割の図。

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

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

一目でわかるスクラムフレームワークの図。

スプリント計画：

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

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

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

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

スプリントの実行

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

Springの実行と列の図。

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

バーンダウンチャートのサンプル。

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

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

毎日のスタンドアップ

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

昨日は何をしましたか？
今日は何をするつもりですか？
仕事を完了するのを妨げる障害はありますか？

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

スプリントの完了

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

スプリントデモ

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

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

スプリント回顧展

スプリントデモの後、次のスプリント計画会議の前に、スクラムマスターは、チームが完了したばかりのスプリントを振り返り、何がうまくいったか、何がうまくいかなかったかについて話し合うスプリントレトロスペクティブを促進し、プロセスを継続的かつ段階的に改善できるようにします。時間の経過に伴う品質（カイゼン、反省）。チームがディスカッションを生成するのに役立つ、遡及的な形式や演習が多数あります。

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

製品バックログ管理

製品バックログの作成

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

バックロググルーミング

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

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

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

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

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

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

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

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

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

ストーリーポイント推定の図。

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

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

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

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

デザインポートフォリオの作り方

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

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

サンプルリリースバーンアップチャート。

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

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

スクラムの長所と短所

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

スクラムは、要件が明確に知られていない、および/または変更が予想されないプロジェクトに最適な方法論です。これはほとんどのプロジェクトに当てはまります。スクラムは、チームが自分で作業を整理できるようにし、進行状況と問題の両方に対する可視性、透明性、および説明責任を提供するため、経験豊富で意欲的なチームにも最適です。これらすべてにより、チームは時間の経過とともに改善され、生産性が向上します。

スクラムにはいくつかの欠点があり、状況によっては最善の方法ではありません。

透明性： スクラムは透明性と説明責任を高めます。これは、チーム内外の問題やパフォーマンスの低下としての長所と短所の両方であり、公開されます。これは不快な場合があり、継続的な改善のスクラムフレームワーク内で適切に処理されない場合、抵抗につながる可能性があります。
チームの経験とコミットメント： 経験の浅いおよび/またはコミットされていないスクラムチームまたはスクラムマスターは、スクラム方法論を誤って適用することによって深刻な問題を引き起こす可能性があります。誰もがすべてを行うため、スクラムチームには定義された役割はありません。そのため、技術的な経験を持つ献身的なチームメンバーが、スクラムプロセスに従い、時間をかけて改善する必要があります。組織の他の部分がスクラムに抵抗力がある場合、それは非常に有害な場合もあります。
スコープクリープ： 特に、利害関係者がスコープに追加することが許可されているため、終了日が定義されていない場合は、スコープクリープのリスクがあります。範囲と優先順位を変更できることはスクラムの主な利点の1つですが、規律が使用されていない場合は欠点になることもあります。
不十分に定義された作業： 定義と理解が不十分なユーザーストーリーまたはタスクは、やり直し、不正確な見積もり、スコープクリープにつながる可能性があります。スクラムはドキュメントよりもソフトウェアの作業に重点を置いていますが、製品の所有者は、必要なものを明確にし、会話やユーザーストーリーでそれを明確に伝えることができる必要があります。
スケーリング： スクラムは小規模なチームを対象としているため、大規模なチームでスクラムフレームワークを採用することは困難です。

Kanban

かんばんとは？

かんばんは、リーン値とアジャイル値の多く、およびスクラム値と原則のサブセットを適用する軽量プロセスですが、いくつかの基本的な違いもあります。かんばんは、視覚化、フロー、および進行中の作業の制限に重点を置いています。

かんばんは、「看板」または「看板」を意味する日本語です。トヨタのラインワーカーは、かんばん（実際のボード）を使用して、製造プロセスのさまざまなステップで追加の容量を通知しました。ソフトウェアでは、これは、スクラムボードと非常によく似たかんばんボードを使用して行われます。作業項目が持つことができるステータスごとに、ToDo項目と垂直列の優先バックログがあります。スクラムと同様に、作業項目はあるステータスから別のステータスに移動されます。ただし、かんばんでは、進行中の作業量は、チームのキャパシティに基づいて、各ステータスのアイテムの最大数に厳密に制限されています。既存の作業がプロセスの次のステップに移動されるまで、新しい作業を取り込むことはできません。スクラムでは、スプリントで計画されている作業量を制御することにより、進行中の作業が間接的に制限されます。

かんばんボードのサンプル

かんばんには、固定された反復やスプリントはなく、作業項目が1つのステージから次のステージにプルされる一定のフローがあります。これは、かんばんボードがリセットされないことを意味します。それはまた、スクラムの儀式の多くが使用されていないことを意味します。かんばんチームは、毎日スタンドアップミーティングを行うことがよくありますが、規定されていません。定期的に計画されているスプリント計画会議、スプリントデモ、またはスプリント回顧展はないため、プロセスはより軽量です。これらの儀式の活動のいくつかは、非公式なレベルで行われる場合と行われない場合があります。継続的な改善は、ある状態から別の状態へのアイテムの流れを追跡および分析し、発見された問題に基づいて一定の段階的な改善を行うことによって達成されます。

かんばんは、スクラムが果たす役割も規定していません。必要な役割はチームメンバーの役割だけですが、多くの場合、プロジェクトマネージャチームとバックログを管理します。多くの場合、単一のかんばんボードは、特定のステータスのアイテムのみを処理する複数の機能ベースの役割やチームにサービスを提供できます。たとえば、開発チームがToDoからInProgressにアイテムをプルしてテストに移動し、テストチームがテストでアイテムをテストしてDoneに移動する場合があります。

作業項目の優先順位付けとグルーミングのためのバックログ管理アクティビティの多くは、特定の作業項目が十分に理解され、作業の準備ができていることを確認するために実行する必要がありますが、作業項目の見積もりはオプションとして規定されています。

かんばんvs.スクラム

次の表では、スクラムとアジャイルを比較しています。

Kanban	スクラム
継続的デリバリー	タイムボックス化されたスプリント
プロセスとオーバーヘッドが少ない	スプリントの儀式と役割を規定している
個々のアイテムをすばやく完了することに重点を置いています	作業のバッチを迅速に完了することに焦点を当てています
サイクルタイムを測定します	スプリント速度を測定します
効率的な流れに焦点を当てる	予測可能性に焦点を当てる
個々のアイテムの仕掛品を制限します	スプリントレベルで仕掛品を制限する
個々の作業項目がプルされます	SprintPlanningでは作業がバッチでプルされます
規定された役割はありません	所定の役割（スクラムマスター、プロダクトオーナー、チームメンバー）
かんばんボードは、単一の部門横断的なチームまたは複数の専門チームを中心に編成できます	スクラムボードは、単一のクロスファンクショナルチームを中心に編成されています
変更はいつでも行うことができます->より柔軟	変更は、製品バックログでのみ許可されます。スプリント内での変更は許可されていません
必要なトレーニングが少なくて済みます	より多くのトレーニングが必要
漸進的な改善のみが必要なチームに適しています	基本的な変更が必要なチームに適しています

要約：パート1の終わり

このパートでは、ソフトウェア開発に使用される最も一般的な方法論のいくつかを確認しました。これで、リーン、アジャイル、スクラム、かんばん、およびリーン生産方式とTPSにおけるそれらの歴史的ルーツについて十分に理解できたはずです。シリーズの次のパートでは、次のような他のソフトウェア開発方法論のレビューと比較を続けます。滝、 JTBD 、および安全（および他のスケーリングフレームワーク）、およびハイブリッド方法論。したがって、それらすべてを1か所で簡単に説明できます。