私は IT 業界に 10 年間携わっていますが、「伝統的に」管理されたプロジェクト チーム (管理の行き届いたチームと管理の行き届いていないチームの両方) で働いてきました。
「新しい」スクラムまたは XP タイプのプロジェクト管理について聞いたことがありますが、その一部になりたいと思っていました (S/W の人々として、私たちは常に新しいものが好きだと思います) が、機会がありませんでした。
私の質問はこれです - 「新しい」方法に移行したあなたの経験は何ですか? XP の開発方法を使用した場合、プロジェクトの成功率は向上しましたか、それとも適切に管理された従来のプロジェクトと同じですか?
これは政治的な問題ではなく、あなたが新しい世界に移動したか、少なくとも一度は経験した経験にすぎません。
前もって感謝します
XPのことを聞く前は、初期の仕事で本当に優秀なマネージャー（Mike）がいました。彼はエンジニアの管理に慣れていて、ソフトウェアの管理に移行しました。いくつかの悪い仕事の経験の後、私は彼のスタイルと、彼と一緒に仕事をする前後の典型的なプロジェクト管理を振り返りました。
マイクはすべてを紙の上でやった。彼はノートとインデックスカードを持っていました。彼は、経営陣から求められたものはすべて、管理可能なタスクに変換され、多くの場合、ノートカードに書き込まれると主張しました。彼は、明確に説明できない、または明確な目的を持っているものに誰かが取り組むことを拒否しました。彼はVPに「もっと速いとはどういう意味ですか？」と尋ねるでしょう。「レポートはどのような種類の指標を表示することを目的としていますか？」「なぜこれを優先すべきなのか？」彼は、何をする必要があるのか、そして「行われた」とは何を意味するのかを書き出すのに、ほぼ無限の忍耐力を持っているようでした。
XPの本を最初に読んだとき、「マイクの働き方」としてどれほど親しみがあったかに驚かされました。
アジャイルは、一連のベストプラクティスを実装し、それらが環境でどのように機能するかを評価することを目的としているようです。動作しない場合は変更してください。彼らが働くとき、彼らに固執しなさい。
従来のプロジェクト管理の本当の問題は、ほとんどの場合、実際には存在しないということだと思います。RUPやCodeComplete、さらにはアジャイルを使用していると主張しているショップの数に驚いていますが、実際にはプロジェクト管理として認識できるものは何もありません。確かに、会議があります。そして人々はプロジェクトマネージャーと呼ばれました。しかし、「プロジェクトXで何が行われたか」、「プロジェクトYで何が残されているか」などの簡単な質問をすると、誰も答えを得ることができません。彼らは電子メールを掘り下げるか、コミカルに不正確なMSプロジェクトファイルを指し示す必要があります。
ある人がダイエットをしていると主張し、何を食べているのか、どのように運動しているのかについての質問に答えられなかった場合。彼らが本当にダイエットをしていることを受け入れますか？
行くときは古い荷物を持っていきます。つまり、以前に持っていたプロジェクト管理の悪い慣行はまだ残っているということです。
しかし、私たちと顧客の間のループを閉じ始めたとき、状況は大きく改善したと言えます. 顧客からのフィードバックとプロトタイピングがより頻繁かつ頻繁に行われるようになると、顧客が「これは私が望んでいたものではありません」と言う瞬間がはるかに少なくなります。
私は仕事の前に（わずかに変更された）スクラムを使用しましたが、ここに私の考えがあります：
これらは素敵な答えですが、誰もがプロジェクト管理と開発/設計方法論を混同していると思います。
開発者にとって、XP＆Co。のすばらしい教訓は、リリースサイクルが短く、要件の変更がプロジェクトの自然な一部として受け入れられるという意味で、より進化的なアプローチです。また、顧客は解決策を提案しますが、設計者と開発者は問題を理解する必要があります。
管理者への教訓：開発者は交換可能な仕様からコードへのコンバーターではありません。開発者の個々の長所と短所は、特定のトピックの生産性に10以上の違いをもたらす可能性があります。知識と経験はチームで最も価値のあるスキルであり、開発者は各耳を教えることができます。管理者は、望ましい結果を強制するために開発者が何を するかを理解する必要はありません。
XP＆Co。は通常、これらのソリューションと問題を組み合わせて、会社を変革しています。運命にあり、遅れ、脱線したプロジェクトを片手で救う英雄的なXPコンサルタントは、開発と管理の間のバッファーとして大きな役割を果たします。しかし、何を学ぶべきかを見ているのであれば、これらの側面を分離する必要があります。
近年私が学んだことは、虫は人格のせいではなく、スペックが変わっても空が落ちないということです。設計エラーは依然として最も費用がかかるものの、「完璧な」設計は1つではないことを学びました。一つのことを正しくする代わりに、多くの詳細の中で間違いがないというセーフガードを実装する必要があります-そして私は「正しい」と「間違っていない」の間の余裕を私たちの利益のために使うことを学びました。
私はアジャイルアプローチが行ういくつかのことを気に入っていますが、従来のアプローチが行ういくつかのことも高く評価しています。
どちらも機能し、2 つを組み合わせても機能します。これが現在、私のチームに最も適していると思います。私はインクリメンタル開発を実装しましたが、それは本当に役に立ちます。反復開発は少し難しく、まだ取り組んでいます。ただし、さまざまな構成要素があり、利害関係者 (および PM) の多くは従来のアーティファクトとマイルストーンを好みます。そのため、適切なバランスを見つけ続ける必要があります。
また、方法論よりもさらに重要なのは、それを実装する人々であることもわかりました。良い人は、方法論に関係なく、良い仕事をして物事を成し遂げる方法を見つけます。ただし、適切に調整されていないリソースは、最高の方法論を使用して、悪い結果をもたらす方法を見つけることができます。
私は、数か月前にスクラムを開始したチームに所属していますが、物事をより迅速に完了し、「無駄」 (破棄されるプロジェクト) を大幅に減らしているようです。私たちの小さなチーム (4 人の開発者) からの私の観察です。
アジャイル/XP プラクティスへの全体的な移行は、多くの点で、プロジェクト/開発プロセスに品質を前面に押し出すことで、非常にポジティブであることがわかりました。実際に成功を収めるには、経営陣とチームからの賛同が必要です...いくつかの提案:
私の経験では、従来のアプローチよりもスクラムを使用することを好みます。これは、通常、プロジェクトが少なくとも 6 か月間実行され、現在のプロジェクトが 1 年以上実行されているように見えるプロジェクトの長さの間、要件が変更されないままになることはあまりないためです。 .
また、プロジェクト管理者が存在せず、誰もが「うまく機能させる」ために奔走する場合もあります。チームがどれだけうまくまとまるかという問題がありますが、それは誰かのコードではなくチームのコードであるため、エゴはめったに現れません。他のすべての人に物事をそのように見せようとします。
私が使ってきたスクラムとアジャイルのアプローチのいくつかは、大きな滝ではなく、急流のようになってしまうことがあります。つまり、要件の収集 - 分析と設計 - 実装 - テスト - デプロイと更新された要件のサイクルが何度も繰り返されているようで、最終的に何が得られるかを最初に述べるのは非常に困難です。プロジェクトのスポンサーが、変更されることのない非常に詳細な要件を提供できない限り。