一方、アジャイルアプローチは、互いに責任を持ち、プロジェクトの共同所有権を受け入れる緊密なチームを強調します。
一方、企業は契約プログラマーを使用して、実際の従業員を解雇することなく資金調達のピークと谷を管理できます。資金が不足している場合、請負業者は、チームの完全に統合されたメンバーであっても(そして従業員がそうでない場合であっても)、最初に取り掛かります。企業はまた、請負業者を限られた時間だけ維持することを好みます。これは、一部の請負業者が正社員として雇用される可能性があるため、多少緩和されます。
したがって、従業員と請負業者が混在するアジャイルチームを持つことと、それに伴う大幅に異なるステータスに根本的な矛盾があるかどうかについての私の質問は?
編集:答えは私がうまく直面している緊張を表現していない可能性があることを示しているので、別のショットを撮りましょう。
私は正社員です。アジャイルなアプローチ(少なくともここで実装されている)により、私は、正社員と請負業者の両方のすべてのチームメンバーを、まとまりのあるチームの同等のメンバーとして見ることができます。請負業者への企業アプローチは、私がそれらを過度に執着してはいけない使い捨てのリソースであると見なすように私を励ます。
他の人がこの緊張をどのように解決したか知りたいです。
多くのチームはアジャイルな請負業者とのみ協力しています。 ThoughtWorksのような一部の企業は、アジャイルチームを「売る」という考えに基づいています。私たちは、大規模な電話会社で働いている10人の請負業者のチームです。
私が問題を見つけたのは、同じチームに2つのレンタル会社があったときでした...しばらくすると、チームに問題が発生しました(とにかくアジャイルとは関係ありません)。
あなたの編集に応じて、状況を見るためのさまざまな目があります。したがって、起こり得る混乱を明確にするために、どの視点が適用されるかを理解することが役立ちます。
開発チームの観点から、請負業者と従業員の間に違いはありません。私たちは皆同じチームに属しており、同じ目標を持っています。チームメンバーの追加と削除は、従業員であろうと請負業者であろうと同じ混乱が生じます。すべてのチームメンバーが同じ責任を負います。
管理の観点では、違いがあります。同社は最も貴重なリソースである従業員を保護しようとしています。そのため、会社は請負業者よりも従業員を維持することを好むでしょう。請負業者がチームにとって非常に貴重であることが判明した場合、会社は請負業者を従業員に変換しようとする可能性があります。これらのタイプの決定は、日々の開発プロセスの外で行われます。
アジャイルプロセスは、日々の開発活動と、高品質の製品をどのように提供するかを管理することに、より関心があります。アジャイルプロセスは、採用/解雇/契約の決定などの管理責任ではなく、手元にあるリソースの使用方法に関係しています。
前の回答
これは根本的な矛盾ではありませんが、いくつかのトレーニング上の課題を提示しています。アジャイルプロセスは、非常に自然なメンタリング環境を促進します。基本的に、スタッフプログラマーは常に経験の声になってしまうでしょう。少なくともそれは、企業文化やチームがどのようにアジャイルを行うかの詳細に関係しているからです。
定期的な契約プログラマーの衰退と流れは、アジャイルを行うかどうかにかかわらず、同じ課題を提示します。契約社員にビジネスの方法を教える必要があります。これには、開発プロセスと請求が含まれます。彼らができるだけ早く貢献を開始できるように、システムの現在の設計について契約プログラマーを教育する必要があります。 希望は、契約社員は迅速な調査であり、プロジェクトへの貢献をすぐに開始できるということです。 On-the-Job-Training(OJT)は、ここではかなりうまく機能します。
結局のところ、新しい開発者や請負業者を雇うと、すぐに生産性が向上するまで、最初の生産性の打撃を受けることになります。実行すればするほど、チームのパフォーマンスに悪影響を及ぼします。 Hense、古い格言「すでに遅れたプロジェクトにさらに開発者を加えることはそれを後でする」。 (彼が他の人を引用していない限り、私はそれがフレッド・ブルックスであったと信じています)。
はい、これは確実に機能します。秘訣は:
a)契約の取り決めを適切に構成する-作品にお金を払っている場合、請負業者は、「作品」に費やす時間を短縮するために物事をまとめる以上のことをすることにほとんど関心がありません。
b)彼らが支払うすべてのセントが製品に直接入るわけではないことを経営陣に売り込みます。24時間体制で行われるトレーニング/計画/議論が行われ、最終的にはその製品を改善します。これは私にとって最も難しい部分でした。
c)適切な請負業者を選択してください。同じスタッフを継続的に雇うことができれば、アジャイル全体が報われ始めます。
また、一般的に、この種のシナリオはアジャイルプラクティスによって大いに助けられると主張します。常にチームに出入りする人々がいて、チェックアウト、起動、コーディングを開始できることは、それ以外の場合よりもさらに重要です。 。
アジャイルに非常に関心があり、優れたソフトウェアを作成する請負業者として、私がスラップダッシュコードを手助けできる場合は決して作成しない請負業者がいることを約束できます。
秘訣はそれらの請負業者を見つけることです。ブログ、スピーキングエンゲージメント、オープンソースコントリビューション、ワークショップ、推奨事項など、彼らがさらに余分に進む準備ができている証拠を探します。以前のアジャイルの経験について尋ね、彼らが自分の仕事を愛している証拠を探します。概して、私たちは私たちが一時的な採用者であることを理解しています。私たちの一部はこのように、契約間の時間を使用してスキルを磨き、知識を拡大しています。
あなたが本当に素晴らしい請負業者を見つけることができれば、彼らはそれを損なうのではなく、あなたのチームの結束力を高めるでしょう。プロジェクトの期間中はそのままにしておいて、チームが落ち着くまで待ちましょう。私たちは休暇を取って、必要に応じて次のプロジェクトのキックオフに出かけます。
一時的な契約はチームに悪影響を及ぼすとあなたが言ったとき、あなたは完全に正しいです。実際、ベロシティは特定のチーム構成にバインドされています。新しい到着または出発は、数か月間行った速度計算を無効にします。
ただし、請負業者が一時的でない場合は機能します。私は、チームが95%の請負業者と1人または2人の従業員で構築されたプロジェクトに取り組みました。プロジェクトがリリースされるまで、請負業者は2〜3年間滞在していました。リリース後、従業員がメンテナンスを行います。この作業方法は非常に一般的です。
要約する:
アジャイル、特にスクラムは安定したチームでそのすべての利点を提供します。