애자일 접근 방식은 계약직 직원과의 호환성이 있습니까?

한편, 민첩한 접근 방식은 서로에게 책임을지고 프로젝트의 공동 소유권을 허용하는 긴밀한 팀을 강조합니다.

반면, 회사는 계약 프로그래머를 사용하여 실제 직원을 해고하지 않고 자금의 최고점과 최저점을 관리 할 수 ​​있습니다. 자금이 부족한 경우, 계약자는 계약자가 팀의 완전 통합 멤버이고 직원이없는 경우에도 먼저 가야합니다. 회사는 또한 계약 업체를 제한된 시간 동안 만 유지하는 것을 좋아합니다. 이는 일부 계약 업체를 정규 직원으로 고용 할 수있는 가능성으로 인해 다소 완화됩니다.

따라서 직원과 계약 업체가 혼합 된 민첩한 팀을 구성하는 것과 근본적으로 다른 지위가 있는지에 대한 나의 질문은 무엇입니까?

편집 : 대답은 내가 직면하고있는 긴장을 표현하지 않았을 수 있음을 나타냅니다. 그래서 다시 촬영하십시오.

저는 영구 직원입니다. 민첩한 접근 방식 (적어도 여기에서 구현 된대로)은 모든 팀 구성원, 영구 직원 및 계약자 모두를 응집력있는 팀의 동등한 구성원으로 볼 것을 권장합니다. 계약자에 대한 회사의 접근 방식은 계약자가 우리가 지나치게 애착되어서는 안되는 소모품이라고 생각합니다.

다른 사람들이이 긴장을 어떻게 해결했는지 궁금합니다.

많은 팀이 민첩한 계약자와 만 협력합니다. ThoughtWorks와 같은 일부 회사는 민첩한 팀을 "판매"한다는 아이디어를 기반으로합니다. 우리는 동일한 계약 회사에서 근무하는 10 개 계약 업체로 구성된 큰 통신 회사를 위해 일하고 있습니다.

내가 문제를 보았던 곳은 같은 팀에 2 개의 신체 임대 회사가 있었을 때였 다.

예, 이것은 확실히 작동 할 수 있습니다. 비결은 다음과 같습니다.

a) 계약 배치를 적절하게 구성하십시오-만약 당신이 조각을 지불하고 있다면 계약자들은 "조각"에 더 적은 시간을두기 위해 물건을 때리는 것보다 훨씬 더 많은 일에 관심이 거의
없습니다. b) 그들이 지불하는 모든 센트가 아니라 시계에있을 교육 / 계획 / 토론이 진행되어 궁극적으로 해당 제품이 향상됩니다. 이것은 저에게 가장 어려운 부분이었습니다.
c) 올바른 계약자를 선택하십시오-동일한 승무원을 계속 고용 할 수 있다면 애자일 전체가 보상을 받기 시작합니다.

또한 일반적으로 이러한 종류의 시나리오는 민첩한 관행에 크게 도움이된다고 주장합니다. 만약 사람들이 항상 팀을 떠나고 떠나는 경우, 체크 아웃, 시작 및 코딩 시작이 다른 것보다 훨씬 중요합니다. .

편집 한 내용에 따라 상황을 살펴볼 여러 가지 눈이 있습니다. 따라서 잠재적 인 혼란을 명확히하기 위해 어떤 관점이 적용되는지 이해하는 것이 도움이됩니다.

개발 팀의 관점에서는 계약자와 직원간에 차이가 없습니다. 우리는 모두 같은 팀에 속해 있으며 모두 같은 목표를 가지고 있습니다. 팀 구성원 추가 및 제거는 직원이든 계약자이든 동일한 장애를 갖습니다. 모든 팀원에게는 동일한 책임이 있습니다.

관리 관점에서는 차이가 있습니다. 이 회사는 가장 귀중한 자원 인 직원을 보호하려고합니다. 따라서 회사는 직원을 계약자보다 유지하는 것을 선호합니다. 계약자가 팀에게 귀중한 것으로 판명되면 회사는 계약자를 직원으로 전환하려고 시도 할 것입니다. 이러한 유형의 의사 결정은 일상적인 개발 프로세스 외부에 있습니다.

민첩한 프로세스는 일상적인 개발 활동 및 고품질 제품 제공 방법 관리와 관련이 있습니다. 민첩한 프로세스는 고용 / 화재 / 계약 결정과 같은 관리 책임에 대한 관심이 적고 현재 자원을 사용하는 방법에 더 관심이 있습니다.

이전 답변

근본적인 모순은 아니지만 몇 가지 훈련 문제가 있습니다. 민첩한 프로세스는 매우 자연스러운 멘토링 환경을 조성합니다. 본질적으로 직원 프로그래머는 최소한 기업 문화와 팀이 민첩하게 행동하는 방식과 관련하여 항상 경험의 목소리가 될 것입니다.

계약 프로그래머가 정기적으로 유출되는 것은 민첩한지 여부에 관계없이 동일한 과제를 제시합니다. 계약 직원에게 비즈니스 수행 방식을 교육해야합니다. 여기에는 개발 프로세스 및 청구가 포함됩니다. 계약 프로그래머에게 가능한 한 빨리 기여를 시작할 수 있도록 현재 시스템 설계에 대해 교육해야합니다. 희망은 계약 직원이 신속하게 연구하고, 정말 신속하게 프로젝트에 기여 시작할 수 있다는 것입니다. OJT (On-the-Job-Training)는 여기서 잘 작동합니다.

요약하자면, 새로운 개발자와 계약자를 고용 할 때 초기 속도에 도달 할 때까지 초기 생산성 저하를 겪게됩니다. 많이할수록 팀의 성과에 부정적인 영향을 미칩니다. Hense, 오래된 격언 "이미 늦은 프로젝트에 더 많은 개발자를 추가하면 나중에 만들 수 있습니다". (다른 사람을 인용하지 않는 한, 그것이 Fred Brooks라고 생각합니다).

Agile을 매우 중요하게 생각하고 우수한 소프트웨어를 생산하는 계약자로서, 도움이 될 수 있으면 슬랩 대시 코드를 생성하지 않을 계약자가 항상 있다고 약속 할 수 있습니다.

요령은 그 계약자를 찾는 것입니다. 블로그, 말하기, 참여, 오픈 소스 기고, 워크샵, 권장 사항 등과 같은 추가 정보를 얻을 수 있다는 증거를 찾아보십시오. 이전 민첩한 경험에 대해 물어보고 자신의 업무를 좋아한다는 증거를 찾으십시오. 우리는 대체로 계약직 사이의 시간을 사용하여 기술을 연마하고 지식을 넓히기 위해 임시 직원임을 알 수 있습니다.

정말 훌륭한 계약자를 찾을 수 있다면, 팀을 방해하지 않고 팀의 응집력을 향상시킵니다. 프로젝트 기간 동안 우리를 제자리에두고 팀이 무너지면서 가자. 휴가가 필요한 경우 다음 프로젝트를 시작할 예정입니다 (필요한 경우).

임시 계약이 팀에 부정적인 영향을 미친다고 말하면 완벽하게 옳습니다. 실제로 속도는 특정 팀 구성에 국한됩니다. 새로 도착 또는 출발하면 몇 달 동안 수행 한 속도 계산이 무효화됩니다.

그러나 계약자가 임시가 아닌 경우에는 작동 할 수 있습니다. 팀이 한두 명의 직원과 계약 한 95 % 계약자 프로젝트를 진행했습니다. 계약자는 프로젝트가 출시 될 때까지 2 ~ 3 년 동안있었습니다. 릴리스 후 직원은 유지 보수를 수행합니다. 이 작업 방식은 매우 일반적입니다.

요약:

민첩하고 특히 Scrum은 안정적인 팀 에서 모든 이점을 제공 할 것 입니다.