アジャイル開発手法を採用したプロジェクトの途中で、予算の制約により 3 つのソフトウェア テスト請負業者を手放す必要がありました。経営陣の姿勢は、これを補うために常勤の団体を均等に投入することです。アジャイル開発はこの混乱を許しますか? 似たような状況になった人がいるか知りたいのですが、どのように対処されましたか?
4 に答える
9
私は、9 人の開発者とかなり順調に進んでいるプロジェクトに参加していました。さまざまな理由により、2 か月の間に 5 人を解雇し、3 人を新たに追加する必要がありました。私たちはほとんどの XP プラクティスに従っていました (100% XP であるとは言えませんが、それに近づいていました)。速度は一時低下しましたが、ゼロにはなりませんでした。
- コードの所有権がないということは、退職者が特別な知識を持っていないことを意味し、その知識は比較的十分に共有されていませんでした。
- 単体テストは、実行可能な方法でコードを文書化するという優れた仕事をしたので、新しい人々は何が起こっているのかを見て、より安全な方法で変更を加えることができました.
- ペアプログラミングのおかげで、人々はすぐに慣れることができました。
- 短いイテレーションにより、速度が低下したものの、速度が急速に回復し始めたことを示すことができ、ビジネス ユーザーはまだ価値を生み出しているという自信を得ることができました。
- イテレーション計画会議は、新しい人が要件を理解し、コード ベース全体を実行するのではなく、イテレーションの目標に集中するのに役立ちました。
理想的な状況ではありませんでした。アジャイルはそれを改善するのに役立ちましたが、それでもまだ痛いです。それでも関係者全員の多大な努力が必要でした。彼ら全員が本当に優れた開発者であり、チーム プレーヤーでなければ、うまくいかなかったでしょう。推測することしかできませんが、チームは十分に優れていたので、おそらくアジャイルがなくてもやり遂げることができたでしょうが、アジャイルのおかげでよりスムーズになったと思います. それがたくさんのチャンプだったら、何もうまくいかなかったでしょう。
于 2008-12-13T19:52:47.910 に答える
4
まあ、どの方法論も、チームの損失の混乱やそれが単に非現実的であることを考慮に入れる必要があります. 解雇されるか、辞任するか、単に死亡するかどうかにかかわらず、人々は去っていきます。新しい人には実績がなく、少なくとも最初のうちはチームの速度に影響します。プロジェクトを分析してください。過去に成功したことが証明されていることを続けてください。最初の 1 か月は生産性が 1/2 になると仮定し (これは私が行ったことです)、彼らが取り組んでいるプロジェクトの複雑さに応じてスライドさせます。
于 2008-12-13T16:54:52.640 に答える
0
どんなタイプのアジャイルをしますか？
一般的に言えば問題ありません。テストを続行するには、チームタスクを変更する必要があります。テストをやめないでください！最初に開発が計画されていたであろうテストに時間をかける必要があります。
于 2008-12-13T15:11:22.520 に答える
0
私たちはスクラム方法論を使用していますが、これは確かにこれを可能にします。実際、まさにこの種の状況を中心に構築されています。ビジネスはバックログのどの部分に取り組むかを決定するため、そのスプリントで利用できるリソースの量に応じて、利用可能なリソースをスプリントごとに変更できます。助言した
于 2008-12-13T16:58:37.967 に答える