アジャイルアプローチは、請負業者をスタッフに配置することと互換性がありますか？

一方、アジャイルアプローチは、互いに責任を持ち、プロジェクトの共同所有権を受け入れる緊密なチームを強調します。

一方、企業は契約プログラマーを使用して、実際の従業員を解雇することなく資金調達の山と谷を管理できます。資金が不足している場合、請負業者はチームの完全に統合されたメンバーであっても（そして従業員がそうではない場合であっても）、最初に実行します。企業はまた、請負業者を限られた時間だけ維持することを好みます。これは、一部の請負業者が正社員として雇用される可能性があるため、多少緩和されます。

したがって、従業員と請負業者が混在するアジャイルチームを持つことと、それに伴う大幅に異なるステータスに根本的な矛盾があるかどうかについての私の質問は？

編集：答えは、私がよく直面している緊張を表現しなかった可能性があることを示しているので、別のショットを撮らせてください。

私は正社員です。アジャイルアプローチ（少なくともここで実装されている）を使用すると、正社員と請負業者の両方のすべてのチームメンバーを、まとまりのあるチームの同等のメンバーと見なすことができます。請負業者に対する企業のアプローチは、私がそれらを過度に執着してはいけない使い捨てのリソースであると見なすように私を励ます。

他の人がこの緊張をどのように解決したか知りたいです。

多くのチームはアジャイルな請負業者とのみ連携します。ThoughtWorksのような一部の企業は、アジャイルチームを「売る」という考えに基づいています。私たちは、大規模な電話会社で働いている10人の請負業者のチームです。

私が問題を見つけたのは、同じチームに2つのレンタル会社があったときでした...しばらくすると、チームに問題が発生しました（とにかくアジャイルとは関係ありません）。

はい、これは確実に機能します。秘訣は：

a）契約の取り決めを適切に構成します-作品にお金を払っている場合、請負業者は物事をまとめて「作品」に費やす時間を減らす以上のことにはほとんど興味がありません
b）彼らが支払うすべてのセントではないあなたの経営を売ります製品に直接入ります-トレーニング/計画/議論が24時間行われ、最終的にはこの製品を改善します。これは私にとって最も難しい部分でした。
c）適切な請負業者を選ぶ-同じスタッフを継続的に雇うことができれば、アジャイル全体が報われ始めます。

私はまた、一般的にこの種のシナリオはアジャイルプラクティスによって大いに助けられると主張します-常にチームに出入りする人々がいる場合、チェックアウト、起動、コーディングを開始できることは、それ以外の場合よりもさらに重要です。 。

あなたの編集に応じて、状況を見るためのさまざまな目があります。したがって、潜在的な混乱を明確にするために、どの視点が適用されるかを理解することが役立ちます。

開発チームの観点から、請負業者と従業員の間に違いはありません。私たちは皆同じチームに属しており、同じ目標を持っています。チームメンバーの追加と削除は、従業員であろうと請負業者であろうと同じ混乱が生じます。すべてのチームメンバーが同じ責任を負います。

管理の観点からは、違いがあります。同社は最も貴重なリソースである従業員を保護しようとしています。そのため、会社は請負業者よりも従業員を維持することを好みます。請負業者がチームにとって非常に貴重であると判明した場合、会社は請負業者を従業員に変換しようとする可能性があります。これらのタイプの決定は、日々の開発プロセスの外で行われます。

アジャイルプロセスは、日々の開発活動と、高品質の製品をどのように提供するかを管理することにより関心があります。アジャイルプロセスは、雇用/解雇/契約の決定などの管理責任ではなく、手元にあるリソースの使用方法に関係しています。

前の答え

これは根本的な矛盾ではありませんが、いくつかのトレーニング上の課題を提示しています。アジャイルプロセスは、非常に自然なメンタリング環境を促進します。基本的に、スタッフプログラマーは常に、少なくとも企業の文化やチームがどのようにアジャイルを行うかの詳細に関係する場合には、常に経験の声になります。

契約プログラマーの定期的な衰退と流れは、アジャイルを行うかどうかにかかわらず、同じ課題を提示します。契約社員にビジネスのやり方を教える必要があります。これには、開発プロセスと請求が含まれます。彼らができるだけ早く貢献し始めることができるように、システムの現在の設計について契約プログラマーを教育する必要があります。希望は契約社員が迅速に研究している、と本当にすぐプロジェクトに貢献し始めることができるということです。On-the-Job-Training（OJT）は、ここではかなりうまく機能します。

つまり、新しい開発者や請負業者を雇うと、すぐに生産性が向上するまで、最初の生産性が低下するということです。実行すればするほど、チームのパフォーマンスに悪影響を及ぼします。Hense、古い格言「すでに遅れたプロジェクトにさらに開発者を加えることはそれを後でする」。（彼が他の人を引用していない限り、私はそれがフレッド・ブルックスであったと信じています）。

アジャイルに非常に関心があり、優れたソフトウェアを生産している請負業者として、私が手助けできるならばスラップダッシュコードを決して生成せず、常に彼らが取り組んでいることに心を注ぐ請負業者がいることを約束できます。

秘訣はそれらの請負業者を見つけることです。ブログ、スピーキングエンゲージメント、オープンソースコントリビューション、ワークショップ、推奨事項など、彼らがさらに余分に進む準備ができている証拠を探します。以前のアジャイルの経験について質問し、彼らが自分の仕事を愛している証拠を探します。概して、私たちは私たちが一時的な採用者であることを理解しています。私たちの一部はこのように、契約間の時間を使用してスキルを磨き、知識を拡大しています。

あなたが本当に素晴らしい請負業者を見つけることができれば、彼らはそれを損なうのではなく、あなたのチームの結束力を高めるでしょう。プロジェクトの期間中、私たちを所定の位置に置いておき、その後、チームがランプダウンするのを待ちます。私たちは休暇をとり、必要に応じて次のプロジェクトのキックオフに出かけます。

一時的な契約はチームに悪影響を及ぼすとあなたが言ったとき、あなたは完全に正しいです。実際、ベロシティは特定のチーム構成にバインドされています。新しい到着または出発は、数か月間行った速度計算を無効にします。

ただし、請負業者が一時的でない場合は機能します。私は、チームが95％の請負業者と1人または2人の従業員で構築されたプロジェクトに取り組みました。プロジェクトがリリースされるまで、請負業者は2〜3年間滞在していました。リリース後、従業員がメンテナンスを行います。この作業方法は非常に一般的です。

要約する：

アジャイル、特にスクラムは、安定したチームでそのすべての利点を提供します。