O'Sorry:アジャイル方法論の何が問題なのか

アジャイルという用語を使用すると、多くの場合、人々は特定のものではなく、正しいことを意味します。 たとえば、アジャイルではなくテストを書きませんでした-チームとの集会を開催しませんでした-アジャイルではなく、時間追跡を記入しませんでした-再びアジャイルではありません。 誰もがアジャイルという用語を独自の方法で解釈するという事実には、その起源に関連する客観的な理由があります。









黒板の言葉



すべてのアジャイルの動きの源が2001年 2月にユタ州のスキーリゾートで行われた集会であったことは周知の事実です。 このイベントのイニシエーターであるロバートC.マーティンが言ったように、前に会ったことがなく、将来会う予定もない賢い人々のグループがそこに集まりました。 会議の目的は一つでした-出席者全員を結びつける共通の何かを表現することです。



プロセスの参加者によって書かれた多くの記事があります[ 1 ]、[ 2 ]、[ 3 ]アジャイルマニフェストが作成された方法について。 起こっていたことの本質は次のとおりでした:各参加者はカードに自分の視点を表現するアイデアを書き留め、カードをカテゴリに分類した後、全員が満場一致である4つのポイントが明らかになりました。 さらに、それらは美しく調合されました:





つまり、右側にあるものの重要性を否定することなく、左側にあるものをさらに重視しています。



この文書は、マーティン・ファウラーが認めているように、投票によってアジャイルという言葉が選ばれた名前を出す必要がありました-非常に適切な言葉ではありません。



マイナー加算



さらに、アジャイルマニフェストは12の原則によって拡張されましたが、最終承認には数ヶ月の電子メール通信が必要でした。



ちなみに、原則の1つは、2週間から2か月の頻度のリリースです。これは、現代の標準(1日数回のリリース)と比較すると、古風に聞こえます。



他の点では、すべてが順調に進んでいないため、別の例を次に示します。「 作業ソフトウェアは、プロジェクトの進捗状況の主な指標です。 」 これは、テストおよびリリースされたアプリケーションが誰にとっても有用であることをまったく意味しないという理由だけで、疑わしい指標です。



予期しない結果



このイベントには、一般の人々から遠く離れた17人が参加しました。 彼らの業績と業界への貢献の短いリストを見つけることができます



猫の下
  1. Kent Beck -XP共同設立者、TDD、xUnit、ソフトウェアデザインパターン。
  2. マイクビードル-2番目のスクラムアダプター。
  3. Arie van Bennekum-実用的。
  4. アリスターコックバーン - クリスタルメソッドソフトウェアデザインパターン
  5. ウォードカニンガム -最初のWiki、デザインパターン、XP共同創設者を開発し、統合テスト用のフレームワークを発明しました。
  6. Martin Fowler-コードリファクタリングと依存性注入、UML、デザインパターン、XP。
  7. James Grenning-世界中のトレーニング、コーチ、コンサルティング、組み込みシステム向けのTDD
  8. ジム・ハイスミス - 適応型ソフトウェア開発 (方法論)。
  9. Andrew Hunt-実用的なプログラマーの本の共著者。
  10. Ron Jeffries -XP共同設立者。
  11. ジョン・カーン -一般的に立派な人。
  12. ブライアンマリック - ソフトウェアテストのクラフト (書籍)。
  13. Robert C. Martin-堅固な原則、 ソフトウェアの職人技クリーンコード (書籍)。
  14. Steve Mellor - Shlaer – MellorメソッドExecutable UMLの開発者。
  15. Ken Schwaber-スクラム共同設立者、 www.agilealliance.org
  16. ジェフサザーランド -スクラム共同設立者。
  17. Dave Thomas-実用的なプログラマーの本の共著者。






テクノロジーと方法論に関連してアジャイルのクリエーターのリストを視覚化すると、興味深い画像が得られます。







一般に、参加者は3つのカテゴリに分類できます。



  1. エンジニア:ロバートC.マーティン、たとえば、主にテクノロジーの開発に影響を与えた人々。
  2. マネージャー:Ken Schwaber、Jeff Sutherland-方法論の開発に大きく貢献しましたが、テクノロジーには貢献しませんでした。
  3. 管理エンジニア:Kent BeckとWard Cunningham-どちらもテクノロジーと方法論の影響を受けています。


驚くべきことに、アジャイルの恩恵を最も受けたのはマネージャーでした。

XPおよび他の同様の方法論を持つエンジニアマネージャーは、これについてもう少し詳しく説明します。



最も興味深いのは、その結果、エンジニアが反対し、アジャイルとの戦いさえ始めたことです。 たとえば、ロバートC.マーティンはこのイベントの主な主催者の1人でしたが、今では反対するだけでなく、 ソフトウェアクラフツマンシップ宣言をまとめました。 柔軟性は柔軟性ですが、私たちはプロであり、ハックワークやラッシュに陥ることなく、プロとしてふさわしい仕事をしなければなりません。



XPおよびその他の廃止された方法論



XP、ASDまたはCrystalのアプローチには非常に合理的な理由があり、さらに多くの理由があります。 これらの方法論には多くの共通点があるので、XPの例でそれらの問題点を見てみましょう。他の方法とは異なり、少なくともメモリにポップアップ表示されるからです。



おそらくXPの主な問題は、詳細すぎることです。 XPの本には160ページが含まれています 。各プロジェクトには独自の仕様があるため、このような量のリーダーシップを大量開発で完全に実装できるとは考えにくいです。



さらに、作業の組織化の原則に加えて、XP は膨大な数の実装方法とより高価な方法を課しています。 ペアプログラミングは完全に賢明な手法ですが、特定のレベルの品質とコードの所有権を達成するための手段にすぎません。 少ない労力で同じ結果を達成できるとしたらどうでしょう? しかし、たとえば、問題を迅速に修正するなど、別の方法で作業すると、さらに多くのことが実現できますか?



しかし、XPで提示された個々の技術概念は業界標準になりました。 これで、継続的インテグレーションまたは毎日の展開で誰も驚かなくなります。 しかし、問題の事実は誰もがそれを持っているということです。



すべてのスクラム



すべてのアジャイル方法論の中で、スクラムのみが広く普及しており、その普及率は大部分が正当化されています。 はい、これは複雑な方法論です。 はい、非常に多くの場合、スクラムは正しく実装されていません。 はい、スクラムの作業は技術的な負債を増やす傾向があります。 はい、もっとたくさん。 それでも、スクラムは市場に出回っている最高のものです。 それを有意義かつ意図的に適用すると、結果は次のようになります。

問題は、スクラムに代わる良い選択肢がなく、競争がないことです。 そして、これは業界全体にとっても、特にスクラムコミュニティにとっても不健康な状況です。



申し訳ありません



多くの民間の方法論がアジャイルの旗の下で発明されており、おそらく著者にとってはうまく機能しますが、それらは業界全体に適用可能ですか? スクラムに代わる優れた選択肢がないのはなぜですか? スクラムはアジャイルの前に登場しましたが、アジャイルベースの方法論が同じレベルで作成されることを期待する理由はありますか?



アジャイルは、いくつかの賢く成功した人々の一般的な考えを表現する4つのステートメントです。 しかし、それらのそれぞれは価値観の非常に大きな全体像を持ち、これは彼らがその時点での個人的な経験に基づいて合意した最小値に過ぎません。 当然のことながら、マニフェストには多くの問題があります。



不完全性 -「映画に行く」または「映画館に行く」などの2つの良いアイデアのうち、機械的に一般を隔離しようとすると、「どこかに行く」ことができます。 彼らの仕事において、各参加者は多数の原則に導かれたので、全員が同意した最小値が成功を達成するのに十分ではなかったと仮定することは非常に合理的です。



表面的 -コードはドキュメントよりも重要であり、エンジニアが組み立てたことはすぐに明らかになります。 クライアントのタスクを解決することは、官僚的な手続きを観察することよりも重要です。おそらくこれはより正しいでしょう。



不確実性 -一見しただけではすべてが明確に見えますが、これらの原則が特定の状況に陥るとすぐに、正しい決定は明らかになりません。 さらに、必要に応じて、発生した視点のいずれかを確認する記事を見つけることができます。



素朴な利他主義 -協力は、罰則が来るまで条件に同意するよりも重要です。 マニフェストをサブスクライブする要件は、4つのステートメントすべてに同意する必要があることを意味します。 しかし、状況が許さない場合はどうでしょうか? 4つ目に従わないことに対して罪悪感を感じることなく、3つだけ従うことはできますか?



狭い聴衆 -マニフェストの訴求は開発に向けられますが、顧客はどうですか? 顧客が古い方法で作業を続けている場合、ルールが開発側からのみ変更されることを期待するのは単純です。



マニフェストの主な目標は、プロセス、方法論、開発自体が異なる方法で実行できることを開発業界に示し、人々に考えさせることでした。 この意味で、マニフェストは完全な成功を認識する必要があります。 内容に関しては、これは好奇心document盛な文書であり、私たち全員が従わなければならない基本原則ではなく、ゼロの始まりを開発するという緊急の問題を反映しています。



まだ機敏



アジャイルイニシアチブの主な成果は約束でした-あなたは異なって働くことができます。 目標を達成するための別の方法を探したり、問題に対する非標準的な解決策を試したり、仕事を整理する上で創造的になったり、自分の専門分野よりも幅広いものを調べたり、試したり、ミスをしたりできます。



これはすべてアジャイルの前に行うことができましたが、何か新しいものを提供するためには大きな勇気と権威が必要でした。 アジャイルにより、問題について率直に話し、重要な解決策について議論することができました。



All Articles