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

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

アジャイル

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

「アジャイル」とは「 アジャイルソフトウェア開発 、」アジャイル原則に従った開発へのアプローチ。しかし、一体何が「アジャイル原則」ですか？を見てみましょう アジャイルマニフェスト とで アジャイルの12の原則 、アジャイル開発の基礎を築きます。マニフェストから：

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

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

アジャイルは、考えて決定を下すためのフレームワークです。

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

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

アジャイルマニフェストは、数十年にわたって出現したさまざまな経験と実用的なソリューションの結果です。

スクラム

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

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

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

「人々が複雑な適応問題に対処しながら、可能な限り最高の価値のある製品を生産的かつ創造的に提供できるフレームワーク。」

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

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

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

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

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

arm vs arm64 vs x86

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

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

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

セレンパイソンによるウェブスクレイピング

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

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

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

Kanban

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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