アジャイルで成功するには何が必要ですか？
一部の組織ではアジャイルの採用が失敗する可能性があります。ウォーターフォールが唯一の（真の）方法である会社で働いていましたが、彼らがプロジェクトでアジャイルを試して失敗したからです。
それをまだ覚えている人たち（私はジュニア）に尋ねたところ、本当に起こった悪い悪夢を思い出させているように、私は懸命にシャットダウンされました。
プロジェクトが失敗した理由がわかりません。アジャイルが失敗する理由はいくつかの企業ですが、その理由は主に経済的であるウェブ上で発見されたリソースがあります。だから私はここにいくつかのフィードバックをお願いすることを考えた。
一部の組織でアジャイルの採用が失敗する理由は何ですか？または、別の言い方をすると、アジャイルで成功するには何が必要ですか。
アジャイルの考え方とアジャイルの方法を理解してサポートするには、経営陣、クライアント、開発者がそれぞれ必要です。さらに詳細に：
- 管理者は、真実を聞くことに慣れている必要があります。これは、彼らが伝統的に期待するものとは対照的に（つまり、「はい、プロジェクトは順調に進んでいる」11か月間です...突然「おっと、期限を数週間遅らせる必要があります」 ...えーと、数か月...えーと...」彼らはまた、各当事者に自分の仕事を任せる（そして責任を負わせる）ことに慣れていなければなりません。最も目立つのは、開発者が技術的な決定と見積もりを行うことです。したがって、厳密な制御とマイクロ管理はありません。
- クライアントは、アジャイルが単に「注文する」だけでなく、開発プロセスに深く継続的な関与を必要とし、それから数か月後に納品を受け取ることを理解する必要があります。また、Big Fixed Requirement仕様の欠如と、最初に要求されたものを提供するための開発チームのコミットメントの明らかな欠如によって、彼らは快適でなければなりません。
- 開発者は、責任を負い、意思決定を行い、オープンにコミュニケーションし、チームとして働くことに慣れている必要があります。つまり「コードの所有権」、「孤独なカウボーイ」、チーム自体が解決できる問題について他者を非難することはありません。
私の経験では、失敗したアジャイルプロジェクトの背後にあることが最も多いのが最初のポイントですが、他の2つも問題を引き起こす可能性があります。
更新
「管理」とは、直接のプロジェクトマネージャーだけでなく、より高いレベルも意味します。 @Michaelが非常に正しく指摘したように、多少の外部関係者（QAや外部タスク割り当て者など）もアジャイルプロジェクトの成功/失敗に影響を与える可能性がありますが、私はそれぞれのリーダーが許可した場合にのみ可能であると考えています。または、組織内で責任とコマンドラインが明確でない場合。
必要なもの：
- 非常に喜んでオープンで正直。あらゆる種類のレイヤー境界にわたって信頼が必要なため、可視性がすべてです。
- 本当にが真実を聞きたい顧客とマネージャ。
- 必要なものに合うように自分の役割を再定義する意思がある現在。
- 動作していないプロセスを変更する自由現在。
- 間違いを認めようとする人そしてそれを元に戻す。
- ビルド環境とテスト環境を一緒に投入する機能随意。 （これは、人々が信用するよりも重要であり、より高価です。）
- 壁を満たすことができる限り多くのホワイトボード。
とてもシンプルに思えますが、これらの多くはこの業界では大きな疑問です。
アジャイルプロジェクトは、キープレーヤーがアジャイルになることを拒否した場合、または（悪いことに）プロジェクトの成功に正直に興味がないか、完全にプロジェクトを妨害した場合、失敗することがよくあります。後者は（他の多くのものと同様に）あらゆるプロジェクトを殺すことができますが、アジャイルプロセスは人々により多くの柔軟性を与え、それは破壊的な政治をする柔軟性を含みます。
例：
- QAは、1か月に及ぶ手動のテストサイクルに合格しない限り、顧客はソフトウェアを見ることができないと主張しています。
- 経営陣は非現実的な期限を課す
- 顧客は要件の優先順位付けを拒否します（「彼らallが最優先されます！」）
- 直接の利害関係者ではないが、政治的影響力を持つ人は、関係のない長いタスクを主要なチームメンバーに割り当て続け、プロジェクトマネージャーはこれを防ぐことができません。
私自身の個人的な経験からしかアドバイスをすることができません。
私がアジャイルで完全に失敗した雇用主の1人。作業はアドホックベースで行われ、テストは存在せず、要件は電子メールと会議の議事録に文書化されました。使用された唯一の開発方法は無政府状態、または「ファイアアンドフォーゲットコーディング」でした。ある種のソフトウェアエンジニアリング手法の実装は、開発者が働きすぎて、ある種のストーリー追跡プロジェクト管理ソフトウェアをセットアップできなかったため、不可能でした。
別の雇用主では、私たちのチームには、アジャイルのベストプラクティスを確立するために必死に努力した英雄的なメンバーがいました-カンバンボード、問題追跡、TDDとBDDを使用しました（アジャイル自体ではないが、アジャイルグループに存在する傾向がある） 。残念ながら、ストーリーポイント、見積もりセッション、キャパシティプランニング、バーンダウンチャート、速度グラフなど、作業をスムーズに進めることができる一種の有用なアジャイルプロジェクト管理機能がありませんでした。アジャイルがうまくいかないという典型的な症状として、かんばんボードがいっぱいになりすぎたとき、より大きなボードを購入しました：/
私が現在いる場所では、ストーリーポイントを2週間の反復、TDD、毎日のスタンドアップ、反復ごとのタイムボックスレトロスペクティブ、およびほとんどのペアプログラミングによる容量計画の方法として使用しています。これは、経営陣の全面的な賛同とクライアント教育の結果です。
アジャイルが会社で成功するためには、次のものが必要だと思います。
- アジャイルを理解し、ツールを適切に使用するプロジェクトマネージャー。
- アジャイルを理解し、オープンで正直であり、アジャイルの分野で必要な開発者
- クライアントからの賛同。彼らはアジャイルの利点を認識し、与えられた時間枠で何が開発できるかに関して開発者からの助言を喜んで聞く必要があります。
編集：毎日のスタンドアップや短いイテレーションなどが役立つ理由を理解することも重要です。
アジャイルの失敗に関する私の経験は、経済学とは何の関係もありませんが、企業/部門/個人の政治と関係があります。
個人レベルでは、個性が衝突する人が何人かいます。アジャイルチーム、またはさらに悪い場合はペアのプログラミングチームに彼らを強制することは、お互いの嫌悪感を沸点にエスカレートします。これは非常に厄介で、非常に速くなり、サボタージュの行為が現実のショーに値するものとなり、スクラム会議が円形の非難の発射部隊になり、さらに悪い場合もあります。
その上に、開発管理があります。これが2つの異なる方法でうまくいかないのを見てきました。
1つ目は、「カーゴカルトアジャイル」です。マネージャーは、マニフェストと、それらを使用する理由と時期、即興の理由を理解せずに、マニフェストと正確に読んだクラス/本/ウェブサイトをすべてフォローするように要求します。アジャイルマネージャーは、呪文を正確に踏襲しているため、魔法が起こるのを待っているかのようです。このアジャイルのプロクラスティアン実装は、プロジェクトの失敗につながる多くの問題を引き起こす可能性があります。
もう1つは「アジャイルインネームオンリー」です。スプリントやスクラムなどの用語が使用されますが、実際には、マイクロマネージメント、コマンドチェーンの上下を行き来する不正、長期にわたる無用のステータスミーティングなどの古い慣行を単にラベル付けしているだけです。 。プロジェクトは以前と同じように失敗しますが、今ではアジャイルは不十分な管理ではなくそれのせいにすることができます。
その上には、プロジェクトのクライアント/顧客による賛同の欠如があります。これらの人々は独自の部門の優先順位を持ち、それが経営陣によって彼らの仕事の不可欠な部分であることが明らかにされない限り、開発チームとの協力に抵抗することができます。これは、部門の政治や企業の方針によって悪化する可能性があります。たとえば、運用とマーケティングの両方がプロジェクトに入力し、チームはどちらも合意できないため、最終的に車輪を回転させてしまいます。もう1つの例は、時間管理と請求に関する企業ポリシーが競合を引き起こす場合です。実際、外部の顧客は内部の顧客よりも扱いが簡単であることがわかりました。彼らはプロセスから得た注意を好み、彼らが自分のお金の価値を得ていることを知っていました。
IMO「アジャイル」は、慣行の大規模な賛同がなければ失敗します。つまり、アジャイルは「顧客」（通常は別の部門またはマネージャー）が次のことを理解していることに依存しています。
- 彼らはソフトウェアに何をしてほしいのか100％知らない
- 完了したと思っていても、完了するまでにどれくらいかかるかわかりません。
- それらはtoldどれだけ時間がかかり、それを受け入れる必要があるか、またはreduce機能が期限に間に合うようにする
- 彼らは反復ごとに機能を選択する必要があり、not完全な100％完全なアプリケーションを一度に取得します。
これらすべては、ほとんどのマネージャーが飲み込むのが非常に難しいものであり、IMOはアジャイルを実行するのが難しい最大の理由です-マネージャーは「x日付で実行される」と言い、その日付までに「魔法で」実行することに慣れています（開発者が80時間週に投入した後）そして、開発チームがこれから行うことを理解するのは180です教えてくださいこのプロジェクトは3か月で完了し、あなたが受け入れる唯一の選択肢は受け入れることですそれまたはそれをより早く終わらせるための要件を減らします。
第二に、開発チームへの信頼がなければなりません。上記の＃1と連携して、専門家として採用された人々の意見を実際に信頼しているマネージャーはほとんどいません。開発者がプロジェクトにxの時間がかかると言い、xが経営者が考えるよりも大きい場合、それはnever "I do n'tソフトウェアの記述方法がわからないので、開発者はおそらく正しいでしょう」は、「3か月ほどかかると言って仕事でうんざりしたくない開発者にとっては」ということです。
3番目に、開発チームはアジャイルの背後にいる必要があります。つまり、手抜きをしたり、絶え間ないフィードバックや「これは正しいですか？xが発生したとき、Yはどうしたらいいですか？」という質問を無視しないということです。 TDDやペアプログラミングに従っていない場合でも、開発チームはアジャイルプロセス（スプリント、反復など）を実行できる十分な能力を備えている必要があります。これには、適切にタスクを見積もることができ、すべての機能を優先する必要はないこと、作業のバックログがあっても問題ないこと、人々を酷使してはならないことを理解できるリード/マネージャーが必要です。