ここでだれもがっかりさせるつもりはありません。 アジャイルが実際にほとんどの企業に適していない理由について、私の考えを共有したいと思います。
まず、開発者にとってアジャイルとは何ですか？ アジャイルは何よりもまず規律です。 あなたがより効率的に働くことを可能にするが、何のためにも決してない規律。 アジャイルには開発者の何かが必要です。
アジャイルは規律です
チーム内の情報が迅速に広まり、問題がすぐに広がるように、Agilは毎日の朝のミーティング- スタンドアップ -を規定し、誰もが昨日何をしたか、何をしたか、どのような問題に遭遇したかを簡単に説明します。
それは良い考えですが、...これは仕事を始めたばかりの私のお気に入りの時間であり、自分でコーヒーをedれました。ニュースや新鮮なジョークを調べるのに約30分かかります。 それどころか、私は一丸となって、昨日の報告をすべきでしょうか？
コードは、 簡単に変更でき、いつでも別の人にいつでも変更できるように、 シンプルで読みやすいものでなければなりません。 これを行うには、コードを絶えずレビューしてリファクタリングする必要があります。 自分のコードを発案者として扱う人は、個人的なas辱としてコードを絶えず変更する必要性を認識しています。 「ここで試してみて、 作成しました。今度は再び変更しますか？...」
そしてもちろん、見知らぬ人があなたの汚い足を見て、変えているという事実を好む人はほとんどいません。
プロジェクトが機能することを確認するには、 単体テストを作成する必要があります 。 つまり、コードは2倍になり、2倍の作業が開発者にかかっています。 そして何のために？ それでも、テストは100％の保証を与えるものではなく、すべてのバグを見つけることはありません。 テスターがそれらを探してみましょう、彼らはこのために存在します！
- プロジェクトがクライアントの希望どおりに機能することを確認するには、 受け入れテストを作成する必要があります 。 そして、彼らには非常に多くの問題があります...彼らはゆっくりであり、常に壊れています...しかし、一体何があなたの手ですべてを呼ぶのが簡単ではないのですか？ さらに、このためのテスターがあります。
異なる開発者からの変更を統合するときにプロジェクトがバラバラにならないように、アジャイルは継続的統合サーバーを提供します。 ここに別のものがあります、頭に浮かびます！ 現在、ビルドが壊れていることを示すいくつかの左の文字が私の受信トレイに注がれています。 そして、私はいくつかのサーバーに登って、テストが赤である理由を理解する必要がありますか？ はい、おそらく、私はそれとは何の関係もありません、なぜ私は時間を費やしますか！
設計上のすべての問題を常に議論するために、継続的なコードレビューを行い、即座にエラーを見つけ、友人に注文を送信します 。友人はペアプログラミングを注文しました。 間違いなく、開発者はこれを最も恐れています。 できたらいいのに！ 一日中、誰かが私の隣に座ってくれます。 ミスで鼻を突く。 メールも、ニュースも、冗談も読まないでください。 いや、火事だ！ 彼が別のスタイルを持っている場合はどうなりますか？ 私たちの意見は異なるべきですか？ 彼がブラケットを同じ行に配置するのが好きなら、私は次のように？ 私たちは一日中議論しますか？ ありがとう、そんな親切はいりません。
開発者が問題領域をよりよく理解し、迅速に簡単な解決策を提供できるようにするには、顧客との直接的なコミュニケーションが必要です。 ああ、ああ、私は電話で同僚と話すことを好むが、クライアントとは...
アジャイルは、
許可する
予測可能な時間枠で高品質の実用製品を作成します。しかし、ここに問題があります。 理にかなっている
望むなら
予測可能な時間枠で高品質の実用製品を作成します。そして、ここで最も重要なことに注目します。ほとんどの開発者にとって、これは最優先事項ではありません。 はい、それは悲しい真実です。
コンフォートゾーン
平均的な開発者は、ある種の複雑なキャッチーなモジュールを作成することに興味があります（たとえ誰も必要としない場合でも）。 私が話していることを知っています、私自身もそうでした。 commons-langのような既存のライブラリを使用するよりも、StringUtilsクラスを書くことに興味がありました。 面白いからといって。 このがらくたを作成するプロセスは興味深いです。 そして、クライアントはどうですか？ はい、彼には何も起こりません。私は6か月待っていましたが、まだ待ちます。 ここで、StringUtilsを終了し、その問題に対処します。
そして最も重要なこと：平均的な開発者は、コンピューターでの快適さを高く評価しています。 私の職場は私の家です。 ここでは、デスクトップ、音楽、オーディオプレーヤー、そこにあるプログラム、テーブル上のフレーム内の画像など、必要に応じてすべてを設定します。 ここにも自分のカップがあります。 ここには快適地帯があります。 ただ私と私のコンピューターです。 まあ、はい、時々上司とテスターが入って、私の世界に突入しますが、これは一時的なものです。 彼らは話して去ります。 そして再び、私の世界に平和が君臨します。
これは事実です。普通の開発者は誰もこの空間に入れたくないのです！ 何言ってるの？ ペアプログラミングは生産性を向上させますか？ バグの数を減らしますか？ コード設計を改善しますか？ うーん...いや、信じられない。 はい、とにかく、2つを別々に2倍にします。 これが、アジャイルが機能しない会話が生まれる方法です。
だから：
ほとんどの開発者にとって、会社やその他すべての成功よりも、ソフトウェアを動かすことよりも自分の快適さが重要です。
より深い問題
したがって、アジャイルはほとんどの開発者には適していません。 アジャイルは、通常の快適さを奪い、個人のデスクトップを奪い、ルールに従って動作するようにします。 そしてこれは、会社がより良くなり、顧客が満足したことを確実にするためだけです。
会社の成功よりも会社の開発者にとってあなた自身の快適さが重要ですが、アジャイルはあなたを助けません。 これらの高価なトレーニング、スクラム、リーン、TDDなどの暴力的な実装は必要ありません。 これはすべてno-pa-mo-zhitです。 問題はより深い。
モチベーションを得るには？
アジャイルは、会社の経営者が思いつくことができる動機付けに加えて、独自の動機付けも提供します。 信じてください。少し慣れると、 ピンポンプログラミングなどのアジャイルプラクティスが非常に楽しいことがわかるでしょう。 Vlad911が言ったように、
ペアプログラミングは、モチベーションを高める素晴らしい方法です。 パートナーは、何をすべきか、どのようにそれを行うかについて、常に同意することができます。そうすることで、日常的な仕事にならないようにします。
コードをコミットすること、それが正常に機能することを確認することは、それ自体が大きな喜びです。
そして最後に、最大の動機の1つは、奇妙なことに、クライアントとの活発なコミュニケーションです。 比較：上司があなたのところに来て、「さて、最後にそれを終えましたか？」と尋ねると、そしてクライアントがあなたのところに来て、「うわ、あなたはやった！ 上司を正当化するのは簡単です。私は集会に参加し、コードを保持し、バグを修正しました。 クライアントでは、このようなトリックは機能しません。 作業を行う必要があります、または...他のオプションはありません。
したがって、プロジェクトの成功に興味がある場合は、アジャイルを使用してください。 自分にとって快適なゾーンがより重要な場合は、コーヒーを入れてニュースを読み始めてください。 アジャイルはまだあなたに合いません。
