アジャイルソフトウェア開発の魅力は何ですか？

アジャイルソフトウェア開発は、最近ではかなり楽しい流行語になりつつあります。

開発者として、私は反復開発の実際的な価値を理解していますが、（ほとんどの場合）ソフトウェア開発へのアジャイルアプローチを採用することは開発者の選択ではありません。トップダウンの管理選択です！クリスタル、アジャイルメソッド、dsdm、rup、xp、スクラム、fdd、tddのいずれであっても、名前を付けてください。開発者の選択ではありません。

世の中のすべてのマネージャーにとって、（私の経験では）ほとんどのマネージャーがコードの一部に触れさえしていないときにアジャイル開発を選択する最大の理由は何ですか？

変化する要件、迅速な配信

アジャイルは、変化するニーズにより迅速に（またはまったく）適応し、それらの変更をより迅速に顧客に提供できる可能性があるため、魅力的です。

これが、多くの企業がアジャイル/スクラムを使用するときに失敗する理由です：マネージャーは、（より速いリリース日を設定し、要件を頻繁に変更する）強力な能力によって、開発者に見積もりを頼る責任があることを理解していません。アジャイルが機能するためには、マネージャーは積極的にスコープをカットする必要があります。

彼らは両方の力を望んでいます。

トレンドをフォロー

時々、人々は物事をしますが、それは彼らが乗り出している（アジャイル）ことのメリットのためではなく、単にそれが人気があり、他の人々が同じことをしようとしているからです。

「なに？Macrojamはアジャイルをやっているのか？なぜ私たちはそうではないのか？遅くはない、私たちはアジャイルだ、くそー！」

一部の人々は、アジャイルであることが実際に何を必要とするのかをよく考えていません。それは単に彼らの存在を正当化するための手段です。羊、仲間からの圧力など

コーディング自体は、マネージャーがメソッドとしてアジャイルを選択することを確信できる主な理由ではありません。変化する要件と優先順位にすばやく対応できるという事実は魅力的です。最終的に「マネージャー」は、エンドユーザー/顧客/彼のマネージャーにソリューションを提供する必要があります。

プロジェクトの開始時に重要と思われた機能をプロジェクトの途中で廃止し、より関連性の高い新しい要件に置き換えることができれば、それは大きな利点です。

また、重要なことは、ほとんどの場合（たとえばスクラムのように）、各中間配信を本番環境に投入する準備がほぼ整っていることです。同時に、最も緊急の機能が最初に開発されました。そのため、何らかの企業の決定のためにプロジェクトがキャンセルされた場合、経営陣は、機能し、本番環境に投入できるものになってしまうと確信しています。

お役に立てれば。

増加の可視性で何が起こっているのかだ上、その増加の生産性

1. マネージャーは通常、アジャイルがもたらす可視性、特にスクラムに関心があります。これは、マネージャーを対象とするセミナーで最も使用されるセールスポイントの1つです。

2. 高い生産性も一般的に使用されており、デモンストレーションが容易であるため（可視性のおかげで）魅力的です。一部のアジャイルエバンジェリストは、既存の従業員から優れた生産性を約束します。「何？私はすでにレモンのようにそれらを押しています、そして、あなたは私がさらにもっと得ることができると言います」？

多くのマネージャーは、アジャイルを使用して従業員をもう少し粉砕します。ある会社では、バーンダウンチャートを怠け者の狩猟機として使用しているのを見ました。

結果？の多くのチームdistress。彼らはアジャイルがすべての問題を解決すると思っていましたが、それは正反対でした。問題は他の場所にありました。

私は積極的にそれと戦っています。そのため、アジャイル手法よりもアジャイル手法よりも高い可能性がある場合は、perverted経営陣が行うこともあるので、社内では言及しないことをお勧めします。

その質問への答えは本を埋めることができます。

主な理由の1つは、アジャイル開発が成果物に焦点を合わせていることだと思います。ここで最も緊急なことを正確に伝えることに常に焦点を当てています。

もう1つの理由は、アジャイルプロセスが従うストーリーベースの計画および推定プラクティスにより、何をいつ配信できるかについて、はるかに優れた推定値が得られることです。

ストーリーベースの計画がいかに効果的であるかの良い例は、私が働いていたプロジェクトです。数か月間（アジャイル開発を採用する前）、プロジェクトリーダーは期限内に納品できると信じていましたが、それは締め切りから約18か月でした。すべての開発者は、それはおそらく非現実的だと感じていました。アジャイル計画を開始した後、プロジェクトリーダーは状況を楽観的に評価していました。しかし、数回のスプリントの後、プロジェクトリーダーは、チームが単に予想された時間にすべての要件を提供する能力を持っていないことに気付きました。そして、それは今ではまだ締め切りから12ヶ月以上でした。

そのため、アジャイルプラクティスにより、現実がはるかに早く明らかになります。

最後に、アジャイルチームは、コード駆動型開発、頻繁なリファクタリング、継続的インテグレーション、ピアコードレビュー/ペアプログラミングなど、より良いコード品質を作成するプラクティスを採用する傾向があります。それほど焦点を合わせないでください。

ほとんどのマネージャーは、自分の人生でコードに触れたことさえありません！

私は12年間デベロッパーでしたが、現在は5年間マネージャーを務めていました。5年間で、コード化されたマネージャーから主に純粋なマネージャーに徐々に移行しました（バグを修正したり、プロトタイピング演習を行ったりします）。

アジャイル開発を行うことを選択した最大の理由は何ですか

• 可視性または成功の速さ/失敗の速さ-私たちは、6か月から24か月のサイクルを持つ製品開発ショップです。動作するテスト済みの機能を使用した反復開発は、プロジェクトのステータスをより適切に反映しました。
• 変更-私たちの環境では、要件と時間が固定される傾向があります。しかし、あまりにも定期的にビジネスを行うと、方向性が急激に変化します。反復的で目に見える開発により、プロジェクトが方向を変えやすくなりました。
• ストーリーベースの要件と反復開発により、要件の技術的側面を必ずしも理解していないビジネスや、一部の詳細のビジネスドライバーを完全に理解していないビジネスでの作業が容易になりました。過去の取り組みでは、高レベルの仕様またはマーケティング要件のドキュメントでは必ずしも十分ではありませんでした。現在、プロジェクトの発展に伴い、市場調査と顧客調査を並行して行うことができます。
• プロセスの変更には、TDD、自動テストと手動テスト、より厳しいテストサイクル（QCグループはなく、QAグループのみ）、品質に関連する高い評価と努力など、多くの開発属性が伴いました（私たちはより多くのツールと指標）。

他の方法でこれを達成することもできましたが、アジャイルな方法論とアイデアを活用することで非常に役立ちました。

また、プロセスの改善を続けています。たとえば、事前の設計作業と実装直前の設計のバランス。すべての決定を定期的に確認して、過去の設計決定を延期できたかどうかを判断します。そして、物事がうまくいかない場合、エラーが特定されるまで、さらに多くの先行作業が必要でした。多くの場合、障害は詳細な分析を必要とするコーナーケースです。その詳細を取得するための努力は、多くの場合、途中でそれを把握してリファクタリングするコストと同じです。チームは、これらのタイプのエラーに対してペナルティを課せられず、より積極的になるよう奨励されています。

多くの企業がアジャイルを「実行」しているのを見てきました。残念ながら、アジャイルを採用している人はほとんどいません。私が言いたいのは、繰り返し開発を行い、毎日のスタンドアップ（ほとんどのチームが座っている）がチームをアジャイルにしないことです。TDD、リファクタリング、継続的インテグレーション、顧客プレゼンス、SOLIDプラクティスにより、チームはアジャイルになります。それらがなければ、あなたはただ輪になって回っています。

アジャイルのメッセージがもたらす魅力はたくさんあります。変化への適応性が最大であること。残念ながら、プロジェクトの管理方法を変更したからといって、コードの適応性が向上するわけではありません。より多くの企業がこれを実現するまで、失敗したアジャイルプロジェクトについてますます耳を傾けます。

バズワードの部分については知りません。私はこれをずっと正式なプロセスや特定されていないプロセスでずっとやっています。私は彼らのウェブサイトを構築したので、クライアントに文字通り肩越しに見てもらいました。約50通のメールを保存し、クライアントはこのプロセスについて何かを学びました-簡単ではありません。

ユーザーがソフトウェアに実行させたいことすべてを書き留めるのに長い時間を要し、アプリを試してから2秒以内に発見したいと思うものを構築するのに長い時間を要するという考え方彼らは吐き気を催すことを期待していません。プロジェクトまたはアプリケーションをいくつかの妥当な部分に分割して、別の部分を構築する前に構築してフィードバックを得るのはどれくらい難しいですか？

これは過度に単純化されており、実際の開発者の慣行に対応していないことは知っていますが、最も非技術的なマネージャーや顧客にさえ販売することは難しくありません。他にどのようなアプローチがより魅力的ですか？クライアントは、ウォーターフォールプロジェクトで開発中にプログラマが6〜12か月間髪を失っていることを本当に気に入っていますか？このように家を建てるために誰かを雇いますか？

管理はこれらのことを開発者に押し付けません。開発者とチームは、イニシアチブを取り、より良い仕事をするために努力する必要があります。経営陣の仕事は、これらのイニシアチブをサポートすることです。

私のキャリアでかなりの量のコードを書いたマネージャーとして、私はあなたがこれに答えようとしている人ではないかもしれません。いずれにせよ、最近のアジャイルへの魅力は、顧客のニーズにより迅速に対応し、仕様、コーディング、テスト、顧客間のフィードバックループを短縮することに最も関係があると思います。これらの理由から、アジャイル開発を推進しています。

アジャイルプロセスとコーディング/開発のプラクティスを台無しにすべきではないと思います。たとえば、スクラムはコードの開発方法を教えてくれません。変更を歓迎するのはプロセスだけです。

結局のところ、それは開発者に力を与えることです。階層の一番下にいる人だけが、何をする必要があるのか​​、どのようにそれを行うのかを本当に理解している唯一の人であるという事実を認めることです。彼らが完全にコントロールできるようにするのではなく、実際の意思決定から遠ざけるのはなぜですか？