アジャイル、スクラム、かんばん：これらの言葉は本当に何を意味するのでしょうか？

ソフトウェア開発者が「新しいJavaScriptフレームワーク」または「新しいIDE」についてのニュースを聞いたとき、それが何であるかを明確にするためにさらに質問する必要はありません。 しかし、彼が「新しいアジャイルフレームワーク」について聞いた場合、彼はそれが何であるかを知っているふりをして、ホーマー-シンプソニアンのうなずきをするでしょう。平均？

現代のソフトウェア開発環境では、「アジャイル」、「スクラム」、「かんばん」などの言葉がますます耳になり、不適切に使用されることがよくあります。 この記事では、これらの用語のいくつかを説明し、明確にすることを試みます。

アジャイル

群衆の賢者になりたいのであれば、作業プロセスについて話しているときは、他のすべての文で「アジャイル」という言葉を使用する必要があります。 それはかなり広い範囲を持っており、あなたが話している主題について多くを知る必要はありません、そしてそれは本当に素晴らしい形容詞または副詞です：「アジャイルを考える」、「アジャイルアプローチ」、「アジャイル原則に従って」。 しかし、「アジャイル」とはどういう意味ですか？

「アジャイル」とは、「アジャイルソフトウェア開発」、つまりアジャイルの原則に従った開発へのアプローチを指します。 しかし、一体何が「アジャイル原則」なのか？ アジャイルマニフェストと、アジャイル開発の基礎を築くアジャイルの12の原則を見てください。 マニフェストから：

アジャイルの原則は、機能するソフトウェアの継続的な提供、チーム間の緊密なコミュニケーション、変化するニーズへの高い適応性を促進します。 仕事でこれらの価値観と原則に従うと、アジャイル環境で仕事をしていると言えます。 したがって、アジャイルソフトウェア開発は方法論ではなく、同じ原則に従うさまざまな方法論、フレームワーク、および手法のセットにすぎません。 「アジャイル」とは、考え、決断するための枠組みと言えます。

しかし、なぜ私たちの仕事でこれらの原則に従うことがそれほど重要なのでしょうか？

マニフェストと原則は、ソフトウェア開発の課題に対応して何十年にもわたって進化してきた最良のソリューションを探した結果です。 70年代、80年代、90年代を通じて、世界中のさまざまな開発者やチームが、問題解決の方法やアプローチを実験し、さまざまなフレームワークや手法（スクラムやエクストリームプログラミングなど）を発明し、さらには同じようになりました。並行してアイデア。 最後に、2001年2月に、17人の開発者が集まり、これらすべての多様なアイデアと経験の共通の分母を見つけました。 このようにしてマニフェストが作成されました。

スクラム

「アジャイル」な方法について、その意味を知らずに話すと、「スクラムやその他のアジャイルな方法論」という主題を知っている対話者の前で、滑って自分を明らかにするようなことを言うかもしれません。

スクラムは方法論ではありませんが、ゲーム・オブ・スローンズでの殺害の数よりも頻繁に呼ばれると聞いています。 スクラムはすべての質問に答えるわけではなく、直面するすべての状況に対応するための正確な手順を提供するものでもありません。 そして、おそらくこの誤った解釈の結果として、ほとんどのスクラムの実装も間違っています。チームは価値を得ることができません。 これは、おそらくスクラムについて最も愚かな発言になります。「スクラムは機能しません。」

スクラムとは何ですか？ スクラムガイドでは、スクラムを次のように定義しています。

つまり、これはフレームワークであり、他のフレームワークと同様に、間違った方法で使用される可能性があります。 スクラムを効果的に使用するには、スクラムによって設定された構造を採用するだけでなく、チーム全体でアジャイルの原則を深く理解し、理解する必要があります。

スクラムは、プロダクトオーナー、スクラムマスター、開発チームの役割で構成されています。

計画会議、毎日のスクラム、スプリントレビュー、スプリント回顧展の4つのスクラムセレモニーもあります。

そして、3つのアーティファクト：製品バックログ、スプリントバックログ、製品増分。

スクラムプロジェクトは、スプリントと呼ばれる通常の時間枠に編成されています。 それらは通常2週間続きます。

プロダクトオーナーは、プロジェクトの方向性を導く責任があります。 新しいタスクと機能が決定されると、製品の所有者はそれらを製品バックログに追加します。 スプリントは、開発チームが作業するバックログからタスクを選択し、それらがどのように実装されるかを計画する計画会議から始まります。 その後、開発が行われます。その間、開発チームはバックログを使用して進捗状況を追跡し、必要に応じてアクティビティを同期して計画を調整するために毎日の会議に出席します。 開発の結果は、製品の増分である必要があります。これは、製品に適用してすぐにリリースできるものです。 スプリントの最後に、製品の増分がスプリントレビューでプロダクトオーナーに提示され、さらに変更が必要な場合は製品のバックログが増加します。 その後、チーム全体がスプリントの回顧展に出席し、作業プロセスとその改善方法について話し合います。

スクラムを習得して理解するのは簡単ですが、採用するのは難しいです。 このフレームワークがプロジェクトに適している場合とそうでない場合がある理由はたくさんあります。 日常の開発だけでなく、文化的にも多くの変更が必要になることがよくあります。 スクラムは、さまざまな種類のスペシャリストを含む、長持ちする複雑な製品の開発に最適です。

スクラムが非常に人気があるのはなぜですか。また、従来のウォーターフォールモデルよりも優れているのはなぜですか。 簡単に言えば、製品と顧客により多くの価値を提供するからです。 滝のような「ヘビー級」の方法では、何ヶ月もの間誰もプロジェクトの何も見ないというホラーストーリーがたくさんあります。 スクラムでは、それは不可能です。

スクラムとは、エンドユーザーに提供される価値のすべてです。 スクラムを実際に利用する場合は、スプリントごとに価値のあるものを提供する必要があります。 価値を測定することができ、チームはまた、次の反復でより多くの価値を提供することを目標として、障害を検査して適応することを余儀なくされます。

ほとんどのソフトウェア開発では、超高層ビルを構築していません。 開始する前に計画全体を準備する必要はなく、最後までその計画に固執する必要があります。 私たちはソフトウェアを開発しており、さまざまな状況に適応し、開発中に製品要件を変更することができます。 長い間、多くの開発者はこれを8番目の大罪と見なしていましたが、製品の観点からは、予測可能性を最適化し、リスクを制御するための大きなメリットです。 スクラムはこの機能を中心に開発されており、その実装により、必要な変更に対処するための信頼性の高い効率的な方法が提供されます。

プランニングポーカー、ペアプログラミング、テスト駆動開発（TDD）、ビヘイビア駆動開発（BDD）など、多くの手法がスクラムと組み合わせて使用​​されます。 それらは実際にはスクラムの一部ではなく、互換性のある手法です。 スクラムと同時によく言われる方法のひとつがかんばんであり、この2つのことの関係については多くの混乱があります。

かんばん

スクラムとかんばんについて話すとき、群衆からよく聞かれる質問の1つは、「スクラムとかんばんのどちらが良いですか？」です。 そして、リンゴとオレンジを比較したり、「パンケーキとビールのどちらが良いか」と尋ねるようなものなので、何に答えればよいかわかりません。 どちらも優れています。

かんばんは、チームメンバーに負担をかけずに、ジャストインタイムの配信を目的としたシンプルな方法です。 目標は最後に最大の価値を提供することであるという点でスクラムに似ていますが、スクラムよりもはるかに柔軟性があります。

かんばんは、ソフトウェア開発コミュニティによって発明されたものではありません。 実際、トヨタの製造工程に端を発し、他の分野でも幅広く使用されています。 従う必要のある厳密な手順はなく、かんばんを実装して使用するための厳密な方法もありません。 それはむしろ、一連の原則と実践であり、ニーズに合わせてこれらの実践から選択することができます。 しかし、ソフトウェア開発で最も頻繁に使用されるかんばんの実装が1つあります。これには、作業の段階とタスクを表す列で構成されるかんばんボードの使用が含まれます。

列は、開発プロセスにおけるタスクの状態を表します。 最も単純な例は、「To Do」、「In Progress」、「Done」の3つの列で構成されています。 そのため、タスクは「To Do」に追加され、開発の開始時に「In Progress」に移動され、最後の列に移動されると「Done」と見なされます。 しかしもちろん、それはもっと複雑かもしれません：

バックログ→仕様の定義→開発の準備ができている→開発→コードレビュー→テスト→展開（→誰も実際に使用していない→完全に削除）。

すべての列にサブ列を含めることができます。 たとえば、「開発」は「計画」と「コーディング」に分けることができます。 「テスト」は、「ユニットテスト」と「統合テスト」などに分けることができます。 必要に応じて、コラムは専門家専用になる場合があります。 チームは、ニーズに応じて列とステージを定義します。 「プル」哲学によれば、タスクは、それらの需要が即時である場合にのみワークフローに入る必要があります。

このボードの目的は、かんばんの最初の重要なプラクティスであるワークフローを視覚化することです。 実際、かんばんはボードなしで実行できます。 これは、タスクの状態を示すさまざまな背景色を使用したGoogleスプレッドシートのタスクの単純なリストの場合もあれば、ガントチャート、図、表などの場合もあります。オフィスのバケットのセットであり、それぞれがタスクの状態、およびボールがタスクとして使用される場所。 ワークフローを視覚化し、プロセス全体に透明性を提供するだけです。

もう1つの重要な原則は、作業のバッチサイズを減らすことです。 簡略化すると、これはマルチタスクを回避することを意味します。 これは、同時に作業するタスクの量を減らすことを意味します。 チームに3人の設計者がいる場合、チームは「設計」列のタスクの最大数を3に設定する場合があります。

スクラムと同様に、かんばんもチームをプロセスの中で最も重要な人物と見なしています。 ただし、スクラムのように役割を提案するわけではなく、既存のプロセスに変更を加えないように、既存の役割を保持することができます。 同じことが継続的改善を意味します。かんばんは通常、継続的に学習して改善することをお勧めしますが、スクラムのSprint Retrospectiveのように、そのプロセスのためだけに特定のイベントを規定するわけではありません。

どちらを使うべきですか？

スクラムとかんばんは相互に排他的ではなく、実際には比較できません。 スクラムには定義された役割がありますが、かんばんは「一体、現在の役割と責任を維持します」と言います。 スクラムはあなたにあなたの働き方を変えることを強制します。 かんばんを使用すると、既存のプロセスから開始できます。 スクラムでは、イベントの明確なスケジュールがフレームワークによって規定されています。 かんばんではイベントはありません。 しかし、それらには多くの類似点があります。どちらも価値中心であり、チームメンバーはシステムの「ボス」として尊重され、基本的に同じ使命を持っています。つまり、無駄を継続的に排除し、障害物を取り除くことです。

しかし、「特定のプロジェクトや特定のチームで何を使用すればよいのか」という質問があります。 はるかに理にかなっています。 かんばんは、プロセスや文化の変更をそれほど必要とせず、ほとんどの場合、スクラムよりも採用が容易です。 一方、スクラムは、プロセスをガイドするための非常に多くの構造を提供します。これにより、全員が同じページにいる限り、大量のオーバーヘッドを排除できます。

しかし、両方の美しさは、どちらも厳密なルールのセットではないということです。 毎日の会議やレビューなど、自分に最適なスクラム要素を選んで選択することを妨げるものは何もありません。 そして、かんばんボードをスクラムに組み込むことができない理由はありません。

チーム全体がスクラムをよく理解している場合、スクラムは非常に効果的なフレームワークであることが証明されています。 しかし、私の経験では、一部のクライアントとスクラムで作業するのは難しいと感じています。 適切なスクラムの実装に必要なプロセスと文化の変更は、多すぎる可能性があります（特に、新しいGoogleを作成していると信じている人に対処する場合）。 一方、かんばんはより柔軟性があり、人々に変更を強いることはありません。 一部の著者はまた、かんばんは敏捷性への良い道であり、スクラムのより簡単な実装を提供すると言います。 他の人は、スクラムを使用すると、最後にかんばんにつながるはずだと言います。

真実は、すべてのプロジェクトが異なり、万能の解決策はないということです。 プロジェクトマネージャーとして、チームに最適なものを決定するのはあなた次第です。