アジャイルなアプローチは、カウボーイにとって言い過ぎの言い訳です
アジャイルアプローチは、要件が曖昧で、エンドユーザーのアイデアを形作るために多くの対話が必要なプロジェクトに最適です。
しかし...私の専門的な仕事では、「アジャイル」アプローチが使用されている会社に行き着きますに関する言い訳としてなぜ事前の設計に力を入れなかったのか;要件がよく理解されているとき。
アジャイルアプローチがなければ、ニースのハイレベルな仕様でここに座っていて、何かが発生したときに1日ごとに同じ画面と機能を再訪する必要がないと思わずにはいられません。そんなことは考えていなかった。
アジャイル手法のメリットは、カウボーイのテクニカルリードに不自由であるという言い訳に勝るほど十分ですか？
更新：皮肉なことに、私は認定スクラムマスターになりました。スクラムコースで発表された論文の1つは、最良の開発プロセスは、設計の決定を行う単一の専門家またはグルがいるプロセスでしたが、それには明らかな弱点があります。スクラムは、高品質のソフトウェアを作成する責任を「チーム」に移します。つまり、標準以下のチームが、他のアジャイル開発プロセスや非アジャイル開発プロセスと変わらないと思うスパゲッティをかき混ぜることを回避できるということです。
カウボーイスタイルのプログラミングの言い訳としてアジャイル開発を使用している場合、アジャイル開発を実際にフォローしているのではないと思います。カウボーイは、どんなプロセスを与えても、常にカウボーイになります。
アジャイルはBDUFよりも貧弱な開発慣行のせいではありません。問題は、実践を適用する際の規律またはその欠如にあります。 BDUFプラクティスの目的は、プロジェクトの方向性を特定し、事前にリスクを決定することです。アジャイルプラクティスの目的は、迅速に方向を変えるのに十分な柔軟性のある開発の状態を維持することです。アジャイルプロジェクトでは、非常に詳細なユーザーストーリーを準備できるため、チームは将来の方向性を認識し、反復ごとに2または3のみを選択して完全に実装できます。問題は、どの方法論を使用しても同じままです。経営陣はカウボーイに不運な行動をさせています。
[BDUF：Big Design Up Front]
anythingのようなアジャイルは、悪い振る舞いをカバーするため、またはチームが彼らが責任を負っていないと考える問題を解決するために使用することができます。
ただし、ScrumのようないくつかのAgile方法論の魔法は、組織内の問題について多くの可視性を提供することです。チーム内の問題を含みます！
その後、それらが発生したときにそれらを解決する機会が与えられます。
問題がカウボーイにある場合、これは最初の反復の後で非常にはっきりします。問題が他の場所にある場合は、すぐにそれが表示されます。
奇妙なことに、私が関わってきた「アジャイル」プロジェクトから、単純にコーディングを始めたいというカウボーイの欲求よりも、要件収集フェーズをスキップすることは、管理の言い訳に似ています。 haveと対話するエンドユーザーがいないため、私のプロジェクトは非常にイライラしています。代わりに、私たちは、顧客が望んでいると思うものを見つけるためにセールスと話し、それから会議を呼び出し、それをマネージャーに説明し、マネージャーが開発者にタスクの割り当てを開始するディレクターがいます。 「良い」プロジェクトでは、PPプレゼンテーションを参照する必要がありますが、通常は、ある機能がどのように機能するかを尋ねるスクラムミーティングに毎日費やし、マネージャーが質問を書き留めます。それはディレクターに尋ねます。それは時間の浪費ですが、「アジャイル」です！
私もウォーターフォールのファンであるとは言いません。私もこれまでいらいらするスコープクリープに対処しているからですが、アジャイルは常に問題への譲歩であり、効果的な対処方法ではありませんでした。初期の反復テストと多くの紙のプロトタイプを備えた優れたデザインは、はるかに効果的であるようです。
アジャイル開発の抗弁がカウボーイによる失敗の責任ではないと言っているのを見ています。アジャイルでの成功には、勤勉さと知性が必要です。
同じ譲歩を他の方法論に適用する限り、これは合理的な立場のようです。カウボーイによって引き起こされたプロジェクトの失敗についてアジャイルを非難できない場合、カウボーイによって引き起こされたプロジェクトの失敗について非アジャイル手法を非難することはできません。
次に、アジャイルとカウボーイの間に相関関係（因果関係ではない！）があるかどうかを議論できます。逸話的な証拠だけで、私はそこにあると信じています。経営者に気付かれずにカウボーイの練習をするのに良い方法だと思われますか？
もちろん、カウボーイが方法論全体に均等に分散していない可能性があることを認め、カウボーイがプロセスの使用の成功を損なうことを認めた場合、プロセスが成功したかどうかをテストすることは非常に困難になりました。 1つのプロセスの方が（コンテキスト内で）優れているという主張は、偽証不可能に近くなります。これは、自分の職業について多くの主張の科学的根拠がないことを恥ずかしく思う原因の1つです。
（ちなみに、私はアジャイル「ウォーターフォール」の代替手段を呼ぶのは嫌いです。ウォーターフォールプロセスは誰もが攻撃するストローマンのようですが、実際に繰り返しなしで使用した人はほとんどいません。）
アジャイルはあなたのチームのために働いている限り問題ありません。
多くの人が悪いチームを良いチームに変える方法としてそれを販売しており、それはそのようには機能しません。あなたは悪い人を連れて行き、突然彼らを有用にするプロセスを適用することはできません。
私はアジャイルの背後にある多くのアイデアが好きですが、何度も目にする失敗は、マネージャーが「アジャイルプロセス」の厳密なセットを推進していることです。 -整理。
「カウボーイ」に関する限り、私がこれまで取り組んできたすべてのアジャイルチームにとって、プロセスは彼らを暴走させるよりも遅くするのに役立ちます。私は、アジャイルがenable "カウボーイコーダー"に役立ったという状況を経験したことはありません。
優れたチームの場合、それはうまく機能しているように見えます（この場合も、優れたチームがあれば、ほとんどのプロセスはうまく機能しているように見えますが、おかしな方法ではありませんか？）。
他のチームの場合、私の経験では、悪い人々がより良くなるのを助けることは決してありませんが、それは時々が生産的な人々を落とすのに役立ちます。
全体として、私は重要なことは良いチームを作り、彼らに必要なことを伝え、それから邪魔にならないことだと思います。流行語の文字列を適用しても、悪いチームを持つという問題を解決できるとは思えません。
（上記のことを理解していない場合、私は少なくとも「Capitol-A Agile」のファンではありません。一方、カウボーイを奨励しているとは思いません。）
アジャイルが適切に行われると、「カウボーイ」テクニカルリードと「ヒーロー」プログラマーを抑制する効果があるはずです。この効果が見られない場合は、アジャイル実装に重要なものが欠けていることを示している可能性があります。
「アジャイル」は本当にインターフェースであり（ここではオブジェクト指向のメタファーを使用しています）、インスタンス化することはできません。それの具体的な実装が[〜＃〜] xp [〜＃〜]である場合は、多くの規律を備えた一連の技術的なプラクティスに従う必要があるため、カウボーイプログラミングの余地はほとんどありません。もう1つの可能性は、自己組織化されたScrumチームのチームワークがそれを抑制し続けることです。
また、カウボーイのコーダーは、あまりテストできないコードを書く傾向があり、テストを書くのが嫌いです。誰もがTDDを行うことは、カウボーイの態度を支配し、開発者にアーキテクチャについてもう少し考えさせることができると思います。もちろん、完璧な方法論はありません。
私は現在、これが当てはまるショップで働いていますが、特定の個々のカウボーイよりも組織文化に関係しています。
組織は常に、比較的緩やかな「非公式のアジャイル」アプローチを採用しています。本当にアジャイルだとは言いませんが、それはより「アジャイルの名前」ですが、実際には存在しない単純な方法論です。異なるチームは異なる方法で動作しますが、全体的な組織文化には、非常に緩やかな「名前のアジャイルのみ」プロセス以外の方法論がないため、全体としては比較的カウボーイでカオス的です-特に統合においては（そしてその多くがあります） ）。
物語の教訓は-はい、これは起こります。今のところ就職活動だったら、気をつけてね。ショップがアジャイルであると主張している場合-面接でかなり難しい質問をして、アジャイルの単なる誤称だけではないことを確認します。
ユーザーがフィードバックを提供できるのは、ユーザーが使用できるアプリケーション、データを入力できる画面を持っている場合のみです。そうして初めて、要件文書で私たちが言おうとしていたことを真に理解します（クライアントは署名しますが、誰もが独自のバージョンの意味を持っています）。アジャイル開発ではない場合、それは予算を超えるウォーターフォールプロジェクトになりますが、アプリケーションを提供すると変更されます。最初のバージョンは、ユーザーが要件がどうあるべきかを議論するためのプロトタイプにすぎません。ですから、予算超過というよりは俊敏性と呼んでいます。
確かに、一部の環境ではアジャイルは規律のない言い訳として使用されています。本当の問題は、なぜ私たちが何らかの方法論を持っているのかを見失ったことです。個人的には、システムのアーキテクチャは非機能的な品質属性に対処することになっているという意味で、方法論はアーキテクチャ上の問題であると感じています。方法論はこれらの同じ属性のいくつかに対処する必要があります（保守性、開発生産性、知識の伝達、他）
方法論をプロセス属性のコントロールとして表示することは、いくつかのことを意味します。1）メトリックがなければ、ある方法論の有効性を別の方法論と比較することはできません。2）重要な属性（配信時間とコード）について積極的な意思決定を行う必要があります。品質対知識の伝達）。
メトリクスと具体的な目標の両方がなくても、「マジックフェザー」として方法論を選択するだけで、堅持すればソフトウェアを提供できるようになります。
ここで、アジャイル、XP、スクラムなどの不利な発言者が、特定の方法論の方法論の脆弱性について話します。議論は：なぜすべてのルールに従うための規律を欠いている1人の個人によって妨害されることができる方法論を使うのか？質問は有効です。ただし、これは症状であり、原因ではありません。正確で意味のある（それが難しい部分の）プロセスメトリックのセットが定義され、テストされ、タイムリーなフィードバックが与えられれば、特定の方法論が成功とはほとんど関係がないことがわかると思います。 （逸話的に言えば、無数の方法論を使用して成功したプロジェクトを見てきましたが、同じ方法論を使用すると2倍のプロジェクトが失敗します）
それでは、メトリックは何ですか？それらは、プロジェクトごと、チームごと、および時々異なります。配信スケジュールが重要な場合に役立ちます。私が個人的に使用したのは、見積もりスキルと品質です。ほとんどの開発者は、1週間以下のタスクを正確に見積もることができます。したがって、1つのアプローチは、プロジェクトを1週間の開発者のタスクに分割し、推定を行った人を追跡することです。プロジェクトが進むにつれて、彼らは彼らの見積もりを変更するかもしれません。タスクが完了した後、オフが10％（1日の半分）を超える場合は、これをバグと同様に扱います-見積もりがオフになった理由を特定します（つまり、データベーステーブルが考慮されなかった）。是正措置（つまり、推定にDBAを関与させる）を行い、次に進みます。この情報を使用して、週あたりの推定バグ数、開発者あたりのバグ数、KLOCあたりのバグ数、開発者あたりのバグ数、KLOCなどのメトリックを作成できます。これらの数値をチームWikiに投稿すると、深刻な社会的プレッシャーと管理の観点からは、数週間後に、その後の開発週の予測モデルを生成できます。
だから何？そのとき、方法論が登場します。プロセスの品質を満たすことができない予測モデルがある場合は、方法論の一部を追加または削除して、モデルへの影響を確認できます。確かに、失敗を恐れて開発プロセスを試してみたいと思う人はいませんが、すでに一貫して高い予測可能な率で失敗しています。個々の変更を加えて結果を測定することで、アジャイルがチームにとって完璧な方法論であることがわかるかもしれませんが、理想的なRUP、ウォーターフォール、またはベストプラクティスのホッジポッドを簡単に見つけることができます。
したがって、私が提案するのは、プロセスと呼ばれるものについて心配するのをやめ、開発プロセスの目標に関連するチェックを導入し、そのプロセスを改善するためにさまざまな手法を試してみることです。
カウボーイのコーダーは、物事をすばやく成し遂げるのが好きなので、優れています。多くの場合、大局的な問題やコードの品質についてそれほど心配していません。そのため、「カウボーイコーダー」はしばしば代名詞です。彼らの方法は、プロジェクトの遅れによる機会費用リスクを軽減します。
カウボーイではないコーダーは、安全で規律ある秩序立った方法で作業を行うことを好みます。彼らはそれを正しく構築し、一度構築するのが好きです。彼らは永遠に情報を収集し、what-ifを考慮し、誰も読まない大きなドキュメントを作成し、システムを遅らせたり遅らせたりすることで知られています。彼らの方法は、質の悪いソフトウェアのリスクを軽減しようとします。
アジャイル手法の優れた点は、短い時間制限のある作業の反復を強制することにより、両方のタイプのコーダーの強みを活かして、コーダーに小さな高品質の作業を迅速に作成するように要求することです。また、イテレーションごとに、納期遅れの機会費用リスクと品質の低いソフトウェアのリスクの両方が軽減されます。
誰も自分をカウボーイのコーダーとは考えていないのはおかしい。多くのポスターが1つである、または1つであったことに賭けています;）
私はここにニースの高レベルの仕様を付けて座っています。他のものが登場するなど、それを考えていなかったので、同じ画面と機能を1日ごとに再訪する必要はありません。
これは、彼が取り組んでいる「アジャイル」プロジェクトに関する私の同僚の経験と一致しているようです（私は自分自身で行ったことはありません）。彼はそれをテストし終えたときと同じように、いくつかの仕様にコードの一部を書くように求められます。彼はそれを変更して再テストする必要がある新しい要件に移動する準備ができています。彼はそれがイライラしていると思います。
私はアジャイルをバッシングしていません。チームがアジャイルを適切に実行していないと思います。しかし、カウボーイが「アジャイル」という用語を使用することで、中途半端なデザインはネガティブではなくポジティブなデザインであることを納得させることができます。
アジャイルが事前の設計/仕様にほとんど重点を置かない理由は、要件が変更される可能性があるからではありません。より深い理由は、要件が安定している場合でも、仕様は次のような傾向があることです。
正しくない-要件の取得に失敗しました。
不整合-ライター/リーダーがキャッチするのを不可能にするのに十分な情報が含まれているため、矛盾に満ちています。
分離-実行中の（縮退しているが）システムからの貴重なフィードバックは組み込まれていません。