-1

誰もがアジャイルについて、そしてそれがいかに優れているかについて話し合っています。アジャイルにはいくつかの長所と短所があります。私はそれらを理論的に研究しました。多くのプロジェクトで働いてきた専門家がここにいるので、アジャイルが適していない場合と適していない場合の実際の 2 対 2 のシナリオを知りたいです。ありがとう

4

4 に答える 4

2

アジャイルは次の場合には不適切な場合があります。

  • 大きくなりすぎた管理を暴露する恐れがあります（一部のポジションは突然明らかに不要になります）
  • 人々は実際に楽しんで創造的なことをしたくはなく、9-17モードのありふれた仕事（処分されるのを待つことができないレガシーのくだらないソフトウェアの保守）を好みます
  • プロフェッショナリズムではなく政治が会社を運営している
  • 人的資源が会社を運営しています（アジャイルは人間に関するものであり、HRはそれらを物として扱います）
  • 顧客は、あなたが彼に必要なものを理解することを期待しています（アジャイルはあなたに彼が答えたくない質問をするようにさせます）
  • アジャイルは、誰もが習慣を変えることなく問題を解決する魔法の杖であることが期待されています（別の流行語、流行）
  • 開発は、互いに遠く離れた複数の場所に、異なるタイムゾーンで分散しています（通信が困難です）
  • あなたにはとがった髪のボスがいます;）

または一般的に：

  • 誤解されています
  • 組織は深刻な病理にむさぼり食われる
  • 誰も実際にそれを望んでいません
于 2013-01-27T03:59:03.237 に答える
2

アジャイルをうまく行うことができれば、それは常に良いことだと私は信じています。それがうまくできない場合、それは有害である可能性があると私は信じています. アジャイルに本質的に危険なものがあるからではなく、機能不全のプロセスを使用することを意味するからです。

したがって、アジャイルをうまく実行するための条件が存在しない場合、アジャイルは不適切です。

アジャイルの採用を台無しにする可能性のあるいくつかのこと:

  • チームメンバーはプロセスを理解しておらず、それを学ぶ時間も意欲もありません
  • チーム メンバーには、自分のプロセスをより詳細に制御するための経験や成熟度がありません
  • 管理には、成果物として詳細な長期計画が必要です
  • お客様は、最終出荷前に増分リリースに関するフィードバックを提供することを望まない
  • チーム内のメンバーの離職率が高い
  • 使用されているテクノロジでは、有効な長さのビルドおよびテスト サイクルが許可されていない (私は 3 時間のビルドおよびテスト サイクルでアジャイルを実行しました。これは非常に苦痛でしたが、ほぼ実行可能でした)、またはまったく許可されていません。
  • 問題のドメインは、ソリューションの漸進的な開発を認めていません (これが本当かどうかはわかりません。これに最も近いのは、暗号化を扱うときで、物事が完全に機能するか、まったく機能しない場合です) )

これらはある程度、治すことができます。知識のない、または経験の浅いチームは、知識のある、または経験豊富なメンバーの幹部によって指導される可能性があります。チームのリーダーは長期計画を作成し、チームにそれを無視させ、実用的なコードを提供することで経営陣が落ち着くことを期待できます。ビジネス アナリストまたは QA は、増分リリースに関するフィードバックを提供するための代理顧客として行動できます。分岐戦略とビルド サーバーを使用して、ビルドとテストをコミットとマージから切り離すことができます。ただし、これらの改善策が成功するとは限りません。問題が克服できないままである場合、アジャイルは成功しません。

于 2013-01-27T12:03:33.547 に答える
1

私はアジャイルに移行しようとしている多くの異なるチームと協力しました。成功したものもあれば、成功しなかったものもあります。私の経験に基づいて、私はそれを言うことができます：

  • アジャイルへの移行は、ソフトウェア作成者が製品の品質を（コンテキストでの意味が何であれ）改善したいので、チームとしてそれを達成する準備ができている場合に適しています。

  • アジャイルへの移行は、全員が現在の品質レベルに満足している場合や、チームとして働きたくない場合には適していません。

于 2013-01-27T11:36:44.923 に答える
0

並べ替えの答え: IT 企業が独自の製品を作成する場合、アジャイルが適しています。たとえば、ビジュアルスタジオはアジャイルな方法で数年間作られています。そして、「納期までの目安」が格段に良くなります。Agile はインターネット バンキングには適していません。もう 1 つの例は、米国に拠点を置くクライアントと開発チームまたはその一部がアジアにあります。時間の遅れは物事を複雑にします。

長い回答: まず、アジャイル プロジェクトを実行したい場合は、経営陣がそれを理解し、社内のプロセスがそれを受け入れる必要があります。それらを回避しようとすると、失敗します。管理と内部プロセスの重要性については、こちらをご覧ください: https://www.youtube.com/watch?v=4u5N00ApR_k管理者とチーム リーダーがアジャイル プロセスを理解することは、プログラマーよりも重要です。通常、反対のことが当てはまります。

第二に、クライアントの管理とプロセスはアジャイル プロセスを採用する必要があります。銀行や金融機関は、アジャイル契約に署名することは決してありません。彼らのプロセスには、複数のレベルでの綿密な計画と承認が必要です。アジャイルに対するクライアントの誤解がどのように失敗を引き起こすかをご覧ください: https://www.youtube.com/watch?v=lAf3q13uUpE

プロジェクトの種類よりも状況の方が重要であるという Tom Anderson の意見に完全に同意します。たとえば、固定契約に署名した場合 (管理者またはクライアントのいずれかの理由で)、詳細な要件がある可能性があります。詳細な要件がある場合は、スクラムを実行せずに「SCRUM BUT」を実行します。それはアジャイル哲学に反しています。

プロジェクトがアジャイルにもウォーターフォールにも適さない場合があります。ドメインを最もよく理解している会社の誰かにプロダクトオーナーの役割を割り当てて、社内でアジャイルを使用する方が良い場合があります。

アジャイル手法の適否は?

于 2014-10-09T12:05:14.773 に答える