수동 소득 아이디어 2023
Scrum에서 이상적인 구현 팀의 모습을 다루기 전에 팀의 책임이나 역할을 다시 살펴보는 것이 좋습니다.
역할 또는 주요 책임
구현 팀 또는 소프트웨어 프로젝트의 경우 개발 팀은 “ 완료의 정의”.
전문가 팀으로서 고객 또는 사용자의 이익을 위해 구현 과정에서 기술적 결정을 내립니다. 따라서 기술 구현 또는 구현의 “방법”에 대한 책임이 있습니다.
이러한 역할에 대한 이해는 이상적인 팀을 위한 많은 요구 사항으로 이어지며, 폭포수 모델과 비교하여 구현 팀을 “설정”하여 애자일 접근 방식의 성공을 위해 이를 고려하는 것이 가장 중요합니다. 우리는 고려해야 할 가장 중요한 6가지 사항을 보여줍니다.
1. 종단 간 책임
스크럼에서 구현 팀은 스프린트 내에서 완전한 기능을 갖춘 소프트웨어를 제공할 책임이 있으며, 이는 최대 4주의 시간 상자에 해당합니다. 스프린트 계획에서 팀은 스프린트에서 구현할 가장 높은 우선 순위 요구 사항의 수를 스스로 결정하여 알려진 오류 없이 테스트되고 배송 가능한 증분을 제공합니다. 필요한 모든 전제 조건(예: 인프라 또는 아키텍처)이 첫 번째 스프린트 전에 아직 준비되지 않은 경우 스프린트 제로를 수행하는 것이 합리적일 수 있습니다.
기술 구현 자체 외에도 이전 테스트 후 제공, 즉 프로덕션 관련 환경에서 소프트웨어 제공도 팀의 책임 영역의 일부입니다. 따라서 요청에서 배송까지의 전체 주기를 담당합니다.
또한 개발팀은 솔루션의 애플리케이션 도메인에 대해 학습하고 제품 백로그 작업을 도와 제품 소유자를 지원하는 책임이 있습니다. 특히 개발팀은 기술적인 관점에서 제품 백로그의 우선순위를 정할 때 관련 종속성을 지적하거나 필요한 우선순위를 재지정할 책임이 있습니다.
따라서 개발 팀은 제품 소유자의 확장된 작업대가 아니라 기술 구현의 핵심 작업 외에도 전문가 팀으로서 제품 소유자와 동등한 입장에서 능동적으로 기여할 의무가 있습니다. 솔루션의 비즈니스 가치를 극대화하는 것을 목표로 합니다.
2. 자율 근무가 성공의 열쇠
스프린트 내에서 팀과 작업은 스프린트 목표를 달성하기 위해 독립적으로 구성됩니다. 팀 외부의 관리자, 팀 리더 또는 수석 개발자가 팀의 개인에게 무엇을 해야 하는지 또는 작업을 수행하는 방법을 지시하지 않습니다.
Scrum의 팀은 고객 또는 사용자의 이익을 위해 작업을 가장 잘 해결하는 방법을 독립적으로(회사 사양 및 주어진 프레임워크 조건 내에서) 결정합니다.
팀은 지속적인 학습 프로세스를 수반하고, 각 스프린트 후 전달(스프린트 검토) 및 생성 프로세스(회고적)를 반영하고 다음 반복(PDCA)에서 구현하기 위해 얻은 지식을 기반으로 개선 사항을 식별합니다.
주장에 부응하기 위해 팀은 팀에서 의사 결정을 위한 다양한 기술(예: 시스템적 합의)을 마스터할 뿐만 아니라 지속적으로 자체 및 솔루션을 개선하기 위해 노력합니다.
그러나 조직적 맥락에서 팀 자율성은 팀 자체가 새로운 팀원을 받아들일지 여부를 결정하는 것을 의미하기도 합니다. 각각의 새로운 팀 구성원은 잠재적으로 팀 구조를 변경하므로 이러한 결정은 팀에서 지원해야 합니다.
3. 풀 스택 또는 T자형
이상적으로는 팀의 모든 개발자가 제품을 처음부터 끝까지 제공하는 데 필요한 모든 기술을 마스터합니다.
이것은 그들이 적어도 하나 또는 두 개의 영역에 대한 진정한 전문 지식을 가지고 있지만 동시에 팀에서 다른 작업을 수행할 수 있도록 다른 영역에서 가능한 가장 광범위한 기본 지식을 가지고 있음을 의미합니다.
조직이 고전적인 기능 기반 조직에서 스크럼으로 전환 중인 경우 이러한 기술은 처음에는 개인이 채웁니다. 스크럼을 사용하면 개인의 기술이 확장되어 원래 기능(예: 테스트 및 프로그래밍)을 더 이상 사람과 1:1로 매핑할 수 없습니다. 이상적으로는 팀 내에서 특정 역할이 정의되지 않습니다.
4. 교차 기능은 필수입니다
팀이 처음부터 끝까지 제품을 제공하는 책임을 다할 수 있으려면 필요한 모든 기술(소프트 기술 포함)이 팀에 나타나야 합니다.
일반적으로 다음과 같습니다.
- 임신
- 설계
- 개발(프론트엔드, 백엔드)
- 시험
- 선적 서류 비치
- 지속적 전달
- 스크럼
따라서 작업을 제대로 수행하려면 팀에 모든 적절한 기술이 필요합니다. 이 팀에는 테스터, 설계자, 설계자뿐만 아니라 프로그래머도 포함됩니다. 예를 들어, 진행 중인 소프트웨어 증분 테스트를 개발 팀의 일부가 아닌 별도의 테스트 팀에 맡기는 것은 실용적이지 않습니다.
또한 필요한 기술을 지속적으로 개선하고 최신 기술을 최신 상태로 유지해야 합니다. 여기에는 특정 프레임워크에 대한 지식뿐만 아니라 디자인 패턴, 애자일 기술(예: 테스트 주도 개발), DevOps, 도구 등과 같은 기술도 포함됩니다.
5. 상근 및 공동 배치 가능 <br
팀 구성원은 프로젝트를 위해 풀타임으로 또는 가용 근무 시간의 100%를 사용할 수 있어야 하며 개발할 제품에 대해 작업해야 합니다. 이것은 연속성을 보장하고 멀티태스킹으로 인한 낭비나 비효율성을 방지합니다. 따라서 여러 프로젝트를 “병렬로” 작업하는 팀원은 피해야 합니다.
팀 구성원은 팀 룸에서 이상적으로는 가능한 한 가깝게 함께 작업해야 합니다. 그렇지 않은 경우 일반적으로 의사 소통이 크게 감소하여 효과 및 효율성 측면에서 잠재적인 손실을 초래한다고 생각해야 합니다.
6. 스크럼의 적절한 팀 규모 <br
Scrum의 구현 팀은 팀 내에서 효율적인 의사 소통을 보장하기 위해 3~9명으로 작습니다. 9명 이상의 팀에서는 의사소통 효율성이 급격히 감소하고 결과적으로 구현도 저하됩니다.
Scrum의 팀은 주어진 작업에 대한 솔루션을 만들기 위해 함께 일하는 해당 분야의 전문가로 구성됩니다. 이러한 팀이 “잘 확립”되어 있을수록 팀에 대한 신뢰 수준이 높아져 효율성에 긍정적인 영향을 미칩니다. 따라서 팀 구성에 어느 정도의 연속성이 있는지 확인하기 위해 주의를 기울여야 합니다.
변경은 절대적으로 필요하거나 실제로 팀 구조에 도움이 되는 경우에만 이루어져야 합니다.
절대 피해야 할 12가지
요약하면, 당신이 반드시 해야 할 12가지 피하다 Scrum에서 구현 팀을 설정할 때 해야 합니다. 팀의 효율성, 효율성 및 동기 부여를 극대화하기 위한 테이크 아웃.
- 팀에서 처음부터 끝까지 제품을 제공하는 데 필요한 모든 기술을 사용할 수 있는 것은 아닙니다.
- 특정 역량은 한 사람 또는 팀의 일부만 사용할 수 있습니다.
- 팀은 여러 프로젝트를 동시에 진행합니다.
- 팀은 여러 위치에 분산되어 있습니다.
- 팀에는 다양한 책임과 계층이 있습니다(예: 수석 개발자, 팀 리더 등).
- 팀은 작업 세트를 수행하는 방법에 대한 지침을 받습니다.
- 팀은 다음 스프린트를 위해 구현할 수 있는 가장 높은 우선 순위 요구 사항의 수를 스스로 결정할 수 없습니다.
- 팀원 수는 9명 이상입니다.
- 팀에 영구적인 추가 개발 또는 노하우 구축을 위한 충분한 시간이 주어지지 않았습니다.
- 팀원이 적절한 Scum 교육 또는 인증(Scrum Developer, Scrum Master)이 없습니다.
- 팀은 정기적으로 재구성됩니다.
- 팀의 작업은 우선 순위에 따라 분배되는 것이 아니라 팀원의 기술에 따라 분배됩니다.
