-パニックではなく、そこで虐殺を手配します。
「大当たり」
かなり長い間、私は投稿、記事、さらには書籍全体に目を向けてきました。そのタスクは、読者にスクラムの実行方法に関するヒントを伝えることです。 一般に、それらはすべて同じタイプであり、ほとんどの人が提案されたプラクティス、その目的、および重要性を誤って理解しているという前提に基づいて構築されています。 これらの情報源は、スクラムがまだ機能していることを積極的に証明しており、価値の採用、企業レベルでの思考の再構築、会議やその他のニュアンスの組織化の複雑さについて話している。結果によれば、キャリッジと小さなカートが入力されるたびに。 Ken SchwaberとJeff Sutherlandでさえ、スクラムを「 軽量で、理解しやすく、習得しにくい 」と説明しているため、問題は本当に存在するようです[1]。 しかし、それは単なる練習ですか？ たぶん、人々はスクラムの本質を理解していないのでしょうか？ 何かが深刻なお金を稼ぎ始めたとき、それがこの船の導きの光になるのは利益であることは秘密ではありません。 おそらく、これらのすべてのトレーニング、認定、およびスクラムマスタープロジェクトマネージャーが元のメッセージを覆い隠すために急いで再トレーニングされたのでしょうか？ そうです。 しかし、そうですか？ この作品は、他のどの技術よりも技術的な観点から、わずかに異なる角度から問題を見ようとする試みです。
Steve McConnellは、著書Perfect Codeで次のように書いています。「 複雑さの管理は、ソフトウェア開発の最も重要な技術的側面です。 私の意見では、複雑さの管理は非常に重要であるため、主要な技術開発の必須事項である必要があります。 アイデア自体は新しいものではありません-シンプルさへの欲求はソフトウェアの歴史全体に浸透しており、今でも培われています。 「 シンプルさが信頼性の鍵です 」とダイクストラは言いました。 「 複雑さの管理はプログラミングの真髄です 」とカーニガンは繰り返します。 そして突然、スクラムに適用されるように、「マスターするのが難しい」という定義に出くわします。 これは何？ 明らかな矛盾があります。 私たちは実際に複雑さに苦しんでいますが、なぜ明らかに複雑な開発方法論が必要なのでしょうか？ ナンセンス？ しかし、おそらく答えは、スクラムが方法論ではないという事実に正確にあるでしょう。 開発ではありません。
前の段落の終わりがあなたを戸惑いに陥れたという考えを認めます。
さて、最初に最初に、次に2番目に、それを理解しましょう。 元のソースを見てみましょう。
「 スクラムは、複雑な適応問題を解決し、同時に生産的かつ創造的に最高品質の製品を開発できるフレームワークです。 」
私たちが最初に気づくのは「フレームワーク」という言葉です。KenSchwaberがこの定義そのものを主張していることは注目に値します。 しかし、技術的な観点から見るとフレームワークとは何ですか？ これは、システムの構造を定義する外部フレームワークです。 この種のフレームワークの特徴的な機能の1つは、制御反転の原理の実装です。 Inversion of Controlは、主に依存性注入メカニズムに関連して今日広く使用されている概念です。 ただし、実践が示すように、人々はIoCとDIの概念を混同するだけでなく、時にはそれらを識別することさえあります。 これをきっぱりと扱いましょう。 簡単なプログラムを考えてみましょう。
static class Program { static void Main() { A(); B(); C(); } }
メインのMainメソッドは、最初に関数Aを呼び出し、次にB、最後にCを呼び出します。これは、ライブラリ関数またはいくつかの内部アプリケーションメソッドです。 したがって、実行されるアクションのセットとシーケンスを決定するのはプログラムであり、それ自体を制御します。 この制御フローは直接と呼ばれます。 この流れの方向が反対方向に向けられている場合、ハリウッド原則とも呼ばれるものを取得します-電話しないで、あなたに電話します（またはより専門的な言葉で：電話しないで、電話します）。 フレームワークは、拡張ポイントを提供することにより、まさにそのようなアプローチを実装します。 開発者として、これらのポイントにコードを接続します。これらのポイントは、外部フレームワークがこれを行う必要があると判断したときに呼び出されますが、フレームワーク自体のコードは変更されません。 これがフレームワークを通常のライブラリとは異なるものにし、同様の制御フローは逆変換と呼ばれます。
では、何がありますか？ スクラムがフレームワークである場合、これは外部フレームワークの一種であり、それ自体は変更せず、独自のメカニズムを組み込むことができる制御フローを提供します。 これらの仮定を確認してください。
スクラムは実行の流れを制御しますか？ はい、もちろんです。 それは、スプリントの反復的な増分概念を提供し、各スプリント内のアクションのリストを定義し、さらには毎日のルーチンを設定します。 質問はありません。
スクラムは同じですか？ そしてまたはい。 著者は、これを文字通りプレーンテキストで語っています。「 フレームワークの各要素は特定の目的を果たし、スクラムの成功と使用の鍵です。 」別の直接ヒット。
しかし、このフレームワークには、グルーミング、スタンドアップ、レトロスペクティブの間にあるこれらのまさに拡張ポイントに何を埋め込むのでしょうか？ 明らかに、開発自体とそのすべてのコンポーネント：設計、テスト、設計、構築、リファクタリングなど。 また、スクラムはこのプロセスに入ることを決して試みず、それを変更する試みも、独自の契約条件を決定する試みも行いません。 適切なフレームワークと同様に、彼は対話するビジネスロジックについて何も知りません。 つまり、ソフトウェアを開発する代わりに、他のものを埋め込むこともできます。 実際、今日、スクラムは金融、医療、高等教育に適応しています。 一部の愛好家は、家を建てたり、家事をしたり、結婚式を開催するためにそれを使用しています。 しかし、ちょっと。 ブラックボックスのように、開発をフレームワークに組み込んだ場合、この外部フレームワークが開発自体を管理しないことはわかりませんか？ まさに！
しかし、その後、彼は何をしますか？ 答えを探す必要はありません。元のソース「 複雑な適応問題を解決します」に戻ってください。 特に、「 製品管理と開発プラクティスの相対的な有効性を示しています 」と、そのような観察の結果は「 それらを改善する機会 」です。
危機にwhatしているものをより明確に理解するために、歴史に短い遠足を取ります。 ボブおじさんとしても広く知られているロバート・マーティンは、彼の演説「プログラミングの未来」[3]で、柔軟なプロセスの出現のための2つの前提条件を概説しています。 それらの1つは、私たちとあなたが一般的に認識していることです。90年代に、ソフトウェア開発の世界は活発に変わり始め、ウォーターフォールは失敗し始めました。 したがって、私たちは、すべての結果的な特性を持つ動的なビジネスに焦点を当てた新しいアプローチを必要としていました。市場への迅速な適応の必要性、絶え間ない変化の傾向など。 ケントベックがアジャイルの主な目標の1つを「 開発とビジネスの境界線を曖昧にする 」と言ったのも無理はありません。 ベックが実際に「癒し」という言葉を使用したことを考慮すると、このステートメントにさらに感銘を受けることができます。 しかし、ビジネスだけの観点から状況を見るのは間違っているでしょう。 有名なアジャイルマニフェストの著者のリストを開くと、これらの人々のほとんどすべてが筋金入りの技術者であることがわかります。 彼らがビジネスの問題だけでなく、ある種の独自の純粋に技術的な問題も解決したと仮定するのは論理的です。 そして、本当にそうです。 同じBob Martinの経験的推定によると、プログラマーの数は5年ごとに2倍になります。 つまり、一般的に言えば、すべての開発者の半数は、5年を超えない経験を持つ人です。 これは問題ですか？ おそらくはい。 繰り返しますが、問題の本質は特定の期間ではなく、経験の量にあります。なぜなら、率直に言うと、時間と知識レベルの相関関係が存在し、非常に高いからです。 したがって、柔軟な方法論は、ソフトウェア製品を開発するためのより理解しやすく、便利で収益性の高いモデルを提供することでビジネスのニーズを満たすことを試みるだけでなく、プログラマーチームの不十分なプロフェッショナリズムの問題にも対処します。
フレームワークであるスクラムは、リトマス論文のように、これらの2つの領域の問題を可能な限り迅速に特定し、それらに迅速に対応できるようにする組織的なツールを提供します。 しかし、もうありません。 要件の扱い方がわからず、開発者がすべての期限と予算からはみ出した低品質のコードを記述した場合、スクラム自体はまったく変更しません。 最大の誤解は、その使用だけで内部プロセスを最適化できると人々が期待しているという事実に正確にあります。 「 あなたの期待はあなたの問題です 」と、ある悪名高いフットボール選手が言っていました。 また、スクラムマスターのタスクは、フレームワークのイベント、アーティファクト、ルールを厳密に熱心に監視することではなく、発生する問題を特定して排除することです。 そして、これは、良いユーザーストーリーと悪いユーザーストーリーを区別できるだけでなく、特定のエンジニアリングプラクティスの導入など、開発の技術的側面にも直接影響を与えなければならないことを意味します。 4つの値と12の原則はアジャイル氷山の一角に過ぎず、命名規則、進化的設計、コードレビュー、テストによる開発、リファクタリング、継続的統合、設計パターン、ペアプログラミング、その他多くの技術的手法をサポートしています。 覚えておいてください：開発上の問題を組織的な結論だけで解決することは不可能です。 スタンドアップやレトロスペクティブ自体から、最高のコードはリポジトリに表示されません。 しかし、スクラムツールの助けを借りて、技術分野のチームの問題を特定し、それらに技術的なソリューションを適用するのに十分な余裕がある場合、彼はそこにいるチャンスがすべてあります。
そして、誰もあなたの「機能するクリーンなコード」を辱することはできません[4]。
[1] スクラムガイド
[2] スティーブマッコネル「完璧なコード」
[3] プログラミングの未来
[4]ロンジェフリーズ