アジャイルアプローチはカウボーイにとって便利な言い訳にすぎませんか

アジャイルアプローチは、要件があいまいで、エンドユーザーのアイデアを形作るのに多くの相互作用が必要なプロジェクトに最適だと思います。

しかし...私の専門的な仕事では、「アジャイル」アプローチが前もってデザインに労力が費やされなかった理由の言い訳として使われている会社に行き着きます。要件が十分に理解されている場合。

アジャイルなアプローチがなかったら、いいハイレベルな仕様でここに座っていて、何か他のものができあがったときでも同じ画面と機能を二度と再訪する必要はないだろうと考えずにはいられませんそんなことは考えていませんでした。

アジャイル手法の利点は、カウボーイの技術的なリードに足りないという言い訳を上回るのに本当に十分なのでしょうか？

更新：皮肉なことに、私は認定スクラムマスターになりました。スクラムコースで発表された論文の1つは、最適な開発プロセスは、設計上の決定を下す単一の専門家または第一人者がいるが、明らかな弱点があるものであると述べました。スクラムは、品質の高いソフトウェアを作成する責任を「チーム」に移します。つまり、標準以下のチームは、他のアジャイル開発プロセスや非アジャイル開発プロセスと変わらないスパゲッティを排除できます。

カウボーイスタイルのプログラミングの言い訳としてアジャイル開発を使用している場合、実際にはアジャイル開発をフォローしていないと思います。カウボーイは、どんなプロセスを与えても、常にカウボーイになります。

アジャイルは、BDUFほど劣悪な開発手法のせいではありません。問題は、実践を適用する際の規律、またはその欠如にあります。BDUFプラクティスの目的は、プロジェクトの方向を特定し、リスクを事前に決定することです。アジャイルプラクティスの目的は、開発の状態を十分に柔軟に保ち、迅速に方向を変えることです。アジャイルプロジェクトでは、詳細なユーザーストーリーを準備できるため、チームは将来の方向性を認識し、完全に実装するために反復ごとに2または3のみを選択できます。問題はどちらの方法論が使用されても同じままです。経営陣はカウボーイを驚かせます。

[BDUF：Big Design Up Front]

アジャイルは、あらゆるものと同様に、悪い行動をカバーしたり、チームが責任を負わないと考えている問題を解決したりするために使用できます。

ただし、スクラムなどの一部のアジャイル方法論の魅力は、組織内の問題について多くの可視性を提供することです。チーム内に問題を含める！

その後、発生した問題を解決する機会が与えられます。

問題がカウボーイにある場合、これは最初のイテレーションの後で非常に目に見えます。問題が他の場所にある場合、すぐにそれを見るでしょう。

奇妙なことに、私が関わった「アジャイル」プロジェクトから、単純にコーディングを開始したいというカウボーイの欲求よりも、要件収集フェーズをスキップすることは管理上の言い訳のようです。我々はしていないので、私のプロジェクトは非常にイライラされている必要がありと対話する任意のエンドユーザーに。代わりに、営業担当者と話し合い、顧客が望むと思うものを見つけ、会議を呼び出してマネージャーに説明し、マネージャーがタスクを開発者に割り当てます。「良い」プロジェクトでは、参照するPPプレゼンテーションがあるかもしれませんが、通常、毎日のスクラムミーティングに費やして、ある機能がどのように機能するかを尋ね、マネージャーが質問を書き留めてディレクターに尋ねます。それは時間の大きな浪費です-しかし、それは「機敏」です！

私はウォーターフォールのファンであるとは言いません、私はあまりにもイライラするスコープクリープに対処しているので、私は常にアジャイルを問題への譲歩であり、それと戦うための効果的な方法ではないと考えてきました。初期の反復テストと多くの紙のプロトタイプを使用した優れた設計は、はるかに効果的であるようです。

アジャイル開発の防御は、カウボーイによる失敗に対して責任を負わないと言っています。アジャイルで成功するには、勤勉さと知性が必要です。

同じ譲歩を他の方法論に適用する限り、これは合理的な立場のようです。カウボーイに起因するプロジェクトの失敗をアジャイルのせいにできない場合、カウボーイに起因するプロジェクトの失敗の非アジャイル手法を責めることはできません。

次に、アジャイルとカウボーイの間に相関関係（因果関係ではない！）があるかどうかを議論できます。逸話的な証拠だけで、私はあると信じています。経営陣に気付かれることなくカウボーイの慣習をうまくやるには良い方法と考えられていますか？

もちろん、カウボーイが方法論全体に均等に分散されていない可能性があることを受け入れ、カウボーイがプロセスの使用の成功を損なうことを受け入れる場合、プロセスが成功したかどうかをテストすることは非常に困難になりました。1つのプロセスが（コンテキスト内で）より優れているという主張は、改ざん不可能に近くなります。これは、私が自分の職業について恥ずかしく思う原因の1つです。多くの主張を科学的に裏付けることができないからです。

（ちなみに、ウォーターフォールプロセスは誰もが攻撃するストローマンのように見えるので、アジャイルの代替物を「ウォーターフォール」と呼ぶのは嫌いですが、実際に反復なしで使用する人はほとんどいません。）

アジャイルは、チームで機能している限り問題ありません。

あまりにも多くの人が、悪いチームを良いチームに変える方法としてそれを売っていますが、それはそのようには機能しません。悪い人を連れて行って、彼らを突然役に立つようにするプロセスを適用することはできません。

私はアジャイルの背後にある多くのアイデアが好きですが、何度も見られる失敗は、マネージャーがアジャイルの概念全体に直面して飛ぶ厳格な「アジャイルプロセス」のセットをプッシュしているということです。 -組織化。

「カウボーイ」に関しては、私がこれまで行ってきたすべてのアジャイルチームにとって、プロセスは彼らを暴走させるよりも遅くするのに役立ちます。アジャイルが「カウボーイコーダー」を可能にする状況を経験したことはありません。

良いチームの場合、それはうまくいくようです（そして、あなたが良いチームを持っていれば、ほとんどのプロセスがうまくいくように見えますが、それがおもしろいのではないでしょうか？）

私の経験では、他のチームにとっては、悪い人が良くなることは決してありませんが、時には生産的な人を動かしません 。

全体として、重要なことは、優れたチームを構築し、必要なものを伝え、邪魔にならないようにすることだと思います。流行語の文字列を適用することで、悪いチームを抱える問題を解決できるとは思わない。

（もしあなたが上記から理解していないなら、私は少なくとも「Capitol-A Agile」のファンではありません。一方、それはカウボーイも励ましているとは思いません。）

アジャイルが適切に行われると、「カウボーイ」のテクニカルリードと「ヒーロー」のプログラマーを抑制する効果があります。この効果を観察しない場合、アジャイル実装に重要な何かが欠けている兆候である可能性があります。

「アジャイル」は本当にインターフェースであり（ここではオブジェクト指向のメタファーを使用しています）、インスタンス化できないことを付け加えます。あなたの具体的な実装がXPである場合、多くの規律を持った一連の技術的実践に従う必要があり、それはカウボーイプログラミングの余地をほとんど残しません。別の可能性は、自己組織化されたスクラムチームのチームワークがそれをチェックし続けることです。

カウボーイのコーダーは、あまりテスト可能でないコードを書く傾向があり、テストを書くことを好まない傾向があります。誰もがTDDを行うことで、カウボーイの態度を支配し、開発者にアーキテクチャについてもう少し考えさせることができると思います。もちろん、完璧な方法論はありません。

私は現在、これが当てはまる店で働いていますが、特定のカウボーイよりも組織文化に関係していることを除きます。

組織は常に比較的緩やかな「非公式のアジャイル」アプローチで運営してきました。私はそれが本当にアジャイルだとは言いませんが、それはより「名前のアジャイル」ではなく、実際には存在しない単なる方法論です。異なるチームは異なる動作をしますが、全体的な組織文化には非常にゆるい「名前だけのアジャイル」プロセス以外の方法論がありません。それは、特に統合においては比較的カウボーイ的で混oticとしたものです。 ）。

物語の教訓は-はい、そうです。私が現在就職活動をしているなら、私はこれに非常に注意するでしょう。ショップがアジャイルであると主張している場合-インタビューでかなり難しい質問をして、アジャイルの単なる誤称以上のものが実際にフォローされていることを確認します。

ユーザーは、使用できるアプリケーション、データを入力できる画面を持っている場合にのみフィードバックを提供できることがわかりました。そうして初めて、彼らは私たちが要求文書で言おうとしていたことを本当に理解します（クライアントは署名するが、誰もが独自の意味のバージョンを持っている）。アジャイル開発ではない場合、予算を超えたウォーターフォールプロジェクトになりますが、アプリケーションは配信されると変更されます。最初のバージョンは、ユーザーが要件をどのようにすべきかを議論するためのプロトタイプにすぎません。したがって、予算よりもアジャイルと呼びます。

一部の環境では、アジャイルは規律のない言い訳として使用されていると思います。本当の問題は、なぜ方法論があるのか​​見失ってしまったことです。個人的には、この方法論は、システムのアーキテクチャが非機能的な品質属性に対処することになっているという意味でアーキテクチャ上の問題であり、方法論はそれらの同じ属性（保守性、開発生産性、知識移転、など）

方法論をプロセス属性のコントロールとして見ると、次の2つのことを意味します。1）メトリックがないと、ある方法論の有効性を別の方法論と比較できない、2）重要な属性（配信時間とコード）品質と知識の伝達）。

指標と具体的な目標の両方を持たずに、単に「魔法の羽根」として方法論を選択するだけで、しっかりと握ればソフトウェアを提供できます。

さて、アジャイル、XP、スクラムなどの反対意見は、方法論の特定のカテゴリーの脆弱性について語っています。論拠：規律を欠いている一人の個人がすべての規則に従うために妨害される可能性のある方法論を使用するのはなぜですか？質問は有効なものです。ただし、それは症状であり、原因ではありません。正確で意味のある（それが難しい部分である）プロセスメトリックのセットが定義され、テストされ、タイムリーなフィードバックが与えられた場合、特定の方法論が成功とはほとんど関係がないことがわかります。（逸話的に言えば、私は無数の方法論を使用して成功したプロジェクトを見てきましたが、同じ方法論を使用すると2倍多く失敗します）

それでは、メトリックは何ですか？それらはプロジェクトごと、チームごと、そして時々異なります。配送スケジュールが重要な場合に役立ちます。私が個人的に使用したのは、スキルと品質の見積もりです。ほとんどの開発者は、1週間以下のタスクを正確に見積もることができます。したがって、1つのアプローチは、プロジェクトを1週間の開発者が行うタスクに分割し、誰が見積もりを行ったかを追跡することです。プロジェクトが進むにつれて、彼らは見積もりを変えるかもしれません。タスクが完了した後、10％（1日1/2）を超えてオフになっている場合、これをバグと同様に扱います。推定がオフになった理由（つまり、データベーステーブルが考慮されなかった理由）を特定し、是正措置（つまり、推定にDBAを関与させる）を行い、次に進みます。この情報を使用して、週ごとの推定バグ数、開発者ごとのバグ数、

だから何？それが方法論の登場です-プロセス品質を満たさない予測モデルがある場合、方法論の一部を追加または削除して、それがモデルにどのように影響するかを選択できます。確かに、失敗を恐れて開発プロセスを試してみたい人は誰もいませんが、私たちはすでに一貫して高い予測可能なレートで失敗しています。個々の変更を行って結果を測定することで、アジャイルがチームにとって完璧な方法論であることがわかりますが、RUP、ウォーターフォール、またはベストプラクティスの寄せ集めを理想的なものとして簡単に見つけることができます。

したがって、私の提案では、プロセスと呼ぶものについて心配するのをやめ、開発プロセスの目標に関連するチェックを実施し、そのプロセスを改善するためのさまざまな手法を試すことができます。

私はここにすてきな高レベルの仕様で座っていて、何か他のものができあがったりするので、2日おきに同じ画面と機能を再訪する必要はありませんでした。

それは私の同僚の「アジャイル」プロジェクトの経験と一致しているようです（私は自分自身に行ったことはありません）：彼はいくつかの仕様にコードの一部を書き、それをテストし終わった直後に彼はそれを変更して再テストすることを要求する新しい要件に移行する準備ができています。彼はそれをイライラさせます。

私はアジャイルをバッシングしていません。チームが適切にアジャイルを行っていないのではないかと思いますが、あなたが言うように、カウボーイは「アジャイル」という用語を使用して、中途半端なデザインがネガティブではなくポジティブであることを確信させることができます。

誰も自分自身をカウボーイコーダーと考えていないのは面白い。私は多くのポスターが1つであるか、1つだったことに賭けています;）

カウボーイコーダーは、作業を迅速に行うのが好きなので、優れています。彼らはしばしば、全体像の問題やコードの品質をそれほど気にしていないので、「カウボーイコーダー」はしばしばepi辞です。彼らの方法は、プロジェクトの遅れによる機会費用リスクを軽減します。

カウボーイ以外のコーダーは、安全で規律正しく秩序立った方法で仕事をすることを好みます。彼らはそれを正しく構築し、一度構築するのが好きです。彼らは、永遠に情報を収集し、what-ifを考慮し、誰も読まない大きな文書を作成し、システムを遅くまたは非常に遅く配信することで知られています。彼らの方法は、低品質のソフトウェアのリスクを軽減しようとします。

アジャイル手法の優れた点は、短い時間制限のある作業反復を強制することにより、両方のタイプのコーダーの長所を活用し、コーダーに小さな高品質の作業を迅速に作成させることです。また、各反復により、配信遅延の機会費用リスクと品質の低いソフトウェアのリスクの両方が軽減されます。

アジャイルが前もって設計/仕様にほとんど重点を置いていないのは、要件が変わる可能性があるためだけではありません。より深い理由は、要件が安定している場合でも、仕様が次のようになる傾向があることです。

• 正しくない-要件をキャプチャできません。

• 矛盾-作家/読者がそれらをキャッチするのを不可能にするのに十分な情報が含まれているため、矛盾に満ちています。

• 分離-実行中の（縮退している）システムからの貴重なフィードバックは組み込まれません。