수동 소득 아이디어 2023
스프린트 계획이란 무엇입니까?
스크럼에 따르면 스프린트 계획은 모든 스프린트의 중요한 부분입니다. 스프린트 계획에서 다음 스프린트는 매우 상세하게 계획됩니다.
개발 팀은 제품 소유자와 “완료의 정의” 측면에서 이 스프린트에서 구현될 내용에 대해 논의합니다.
스프린트 계획은 1개월 스프린트에 대해 최대 8시간으로 제한됩니다. 더 짧은 스프린트는 일반적으로 시간이 더 적게 걸립니다(평균 4시간). 스크럼 마스터는 이벤트가 발생하고 참가자가 이벤트의 목적을 이해하도록 합니다.
스프린트 계획은 다음 질문에 답합니다.
- 다가오는 Sprint의 제품 증분에는 무엇이 포함됩니까?
- 제품 증분을 전달하는 데 필요한 작업은 어떻게 완료됩니까? <br
누가 스프린트 계획에 참여합니까?
- 개발팀
- 제품 소유자
- 스크럼 마스터<br
스프린트 계획은 어떻게 작동합니까?
제품 책임자는 다가오는 스프린트에서 달성해야 할 비즈니스 목표를 제시합니다. 그런 다음 스크럼 팀은 함께 스프린트 목표를 만들고 개발 팀은 제품 백로그에서 스프린트 백로그로 전송하여 스프린트 목표 달성에 기여하는 적절한 항목을 선택합니다.
먼저, 이 스프린트에서 구현할 수 있는 요구 사항, 즉 소프트웨어 증분의 모양이 결정됩니다. 이를 위해 제품 백로그에서 가장 우선 순위가 높은 항목은 상대적으로 높은 수준의 세부 정보를 가져야 하며 모든 당사자가 잘 이해할 뿐만 아니라 명확하고 해석의 여지가 없어야 합니다.
제품 백로그의 단일 항목 상태를 “스프린트 준비(줄여서 “준비”).
이를 위해 우선순위에 따라 스프린트 계획에 포함할 요소를 공동으로 선택합니다. 팀은 먼저 “무엇”을 구현하고 스프린트를 통해 달성할 목표를 계획합니다. 그런 다음 두 번째 단계에서는 목표를 “어떻게” 구현해야 하는지입니다.
Scrum의 구현 팀만이 구현할 항목의 수를 결정합니다. 스프린트 목표가 생성됩니다. 그런 다음 개발 팀은 스프린트 목표를 달성하기 위한 계획을 세웁니다. 필요한 단계는 일반적으로 실제 작업 보드에서 논의되고 문서화됩니다. 회의가 끝나면 스프린트에 대한 세부 계획이 만들어집니다.
스프린트를 계획할 때 반드시 고려해야 할 5가지 포인트!
1. 개발팀의 비현실적인 역량 평가
스프린트에서 구현할 수 있는 것은 개발 팀의 가용 역량에 크게 좌우됩니다. 종종 개발자는 스프린트에서 너무 많은 작업을 수행하고 스프린트에서 구현 능력에 영향을 미치는 휴가, 휴일, 질병, 다른 또는 새로운 팀원 지원, 리팩토링, 백로그와 같은 측면에 충분한 주의를 기울이지 않습니다. 개선 및 기타 회의.
따라서 현실적인 용량 계획이 수행되는지 확인하십시오.
2. 품질에 대한 인식 부족 또는 기술적 부채 무시
개발팀이 새로운 기능 개발에만 몰두하고 지속적인 리팩토링을 통해 제품의 내부 품질을 개선할 수 있는 충분한 역량을 요구하지 않으면 문제가 발생합니다. 스프린트 중에 발생하는 기술 부채 및 오류는 적시에 제거되지 않는 경우가 많습니다.
제품 소유자 또는 이해 관계자가 이 작업의 필요성을 인식하지 못하고 개발 팀이 이 시점에서 자신을 주장하지 않으면 개발할 제품의 품질과 실행 가능성이 점점 더 나빠질 것입니다. 따라서 기술적 우수성 또는 사용자를 위한 비즈니스 가치를 극대화하는 가치 있는 제품의 개발은 불가능합니다.
기술 부채를 정리하고 코드 기반을 지속적으로 개선하는 것(예: 코드 검토 또는 페어 프로그래밍)도 우선 순위인지 확인하십시오. 일반적으로 코드 베이스를 지속적으로 개선하려면 각 스프린트에서 용량의 약 20%를 사용해야 합니다.
3. 너무 많거나 적은 계획
스프린트 계획 중에 개발자는 다가오는 스프린트의 각 개별 작업을 자세히 계획하고 하위 작업을 스스로 추정합니다. 물론 이것은 민첩한 구현 및 지속적인 학습 프로세스 구축의 정신이 아닙니다. 너무 상세한 계획은 일반적으로 불균형한 노력으로 이어지고 따라서 스프린트 중에 다시 조정하면 낭비됩니다. 일반적으로 구현을 시작할 수 있으려면 개발 팀이 스프린트 계획 과정에서 작업의 약 1/4을 계획하는 것으로 충분합니다.
스프린트 계획의 목적은 개발팀이 사용자 스토리와 수용 기준의 형태로 구현해야 할 사항을 충분히 이해하는 것입니다. 이는 스프린트 계획의 파트 1에 해당합니다. 스프린트 계획의 파트 2에서는 스프린트 목표를 달성하기 위해 완료해야 할 작업을 합의하고 작업을 기록합니다. 작업은 배포되지 않습니다. 팀 구성원은 완료의 정의에 정의된 작업을 완료할 때마다 스프린트 중에 새 작업을 수행합니다.
하위 작업의 민첩한 추정도 적합하지 않습니다. 오히려 추정의 목적은 제품 또는 스프린트 백로그에 있는 항목의 내용과 방법과 관련하여 개발자의 편차가 있는 평가를 결정하는 것입니다. 사용자 스토리 수준의 대략적인 추정(예: 스토리 포인트를 통해)이면 충분합니다.
너무 적은 계획도 효과적이지 않습니다. 스프린트 계획 파트 2의 생략은 개발 팀이 공통 초안(아키텍처, 디자인)을 결정하고 어떤 기술 부채를 줄일 것인지 또는 누구와 어떤 작업을 위해 누구와 함께 할 것인지에 대해 합의할 기회를 박탈합니다. 페어 프로그래밍 세션은 함께 작동합니다.
목표를 달성하기 위해 필요한 만큼의 계획이 있는지 확인하십시오. 개발 팀은 스프린트 목표를 달성하고 가치 있는 소프트웨어 증분을 제공하기 위해 구현해야 할 사항과 이를 구현하는 방법을 잘 이해하고 있어야 합니다.
4. 팀장, 차장 또는 기타 역할 혼란
스크럼은 팀의 집단 지성을 사용합니다. 역할이 명확하게 분배되고 정의됩니다. 제품 소유자는 각 프로젝트 또는 회사의 기술 프레임워크 내에서 구현의 내용을 담당하고 개발 팀은 기술적인 방법을 담당합니다. 스크럼 마스터는 스프린트 계획의 구현을 지원하고 조직의 장애물을 제거합니다. 3가지 역할 모두 동등한 위치에서 작동하며 아무도 다른 역할의 팀 리더 또는 감독자가 아닙니다.
개발팀 내에서도 기획 업무를 인계하거나 팀원 개개인에게 업무를 할당하는 팀장이 없다.
예를 들어 개발팀의 특정 사람들만 스프린트 계획에 참여하는 대리 시스템도 없습니다. 전체 스크럼 팀이 스프린트 계획에 참여하고 적극적으로 참여합니다. 그렇지 않으면 투명성이 떨어지고 팀 구조와 “전송 오류”가 발생할 수 있습니다.
예외: 다양한 스크럼 팀이 더 높은 수준의 스프린트 계획에서 개별 팀 구성원으로 표시되는 Nexus 또는 LeSS와 같은 확장 프레임워크로 작업합니다.
물론 구현 과정에서 스크럼 팀은 아키텍처, 디자인, 데이터 보호, 정보 보안 등의 맥락에서 전사적 사양 및 표준을 고려해야 합니다. 그러나 해당 역할은 스크럼 구현 과정에서 정의된 작업이 없으므로 스프린트 계획에서도 마찬가지입니다. 그럼에도 불구하고 구현 과정에서 스크럼 또는 개발자 팀에 대한 질문을 명확히 하기 위해 즉시 사용할 수 있어야 합니다.
개발 팀이 팀 리더 역할 없이 자율적으로 작업할 수 있는지 확인하고 모든 소프트웨어 증분을 통해 사용자의 결과를 극대화하는 것을 목표로 하십시오.
5. 제3자 예측 및 Sprint Backlog Bazar
실제로 가장 일반적인 반 패턴 중 하나는 개발 팀이 구현 방법을 자율적으로 결정하는 전문가 팀으로 인식되지 않는다는 것입니다. 팀은 스프린트에서 구현될 수 있는 것에 대한 유효한 예측을 할 수 있다고 신뢰하지 않습니다.
실행 가능한 작업의 스프린트 예측은 전적으로 개발 팀의 팀 기반 결정입니다. 대신 실제로는 스크럼에서 제공되지 않는 제품 소유자, 이해 관계자 또는 기타 역할이 개발 팀의 예측 후 예측을 생성하거나 “확실히 더 있습니다” 바자회를 시작하는 것을 관찰할 수 있습니다.
이것은 많은 부정적인 결과를 초래하므로 어떤 대가를 치르더라도 피해야 하는 행동입니다. 예를 들어, 개발팀은 더 이상 스프린트 목표 달성에 대한 책임을 지지 않으며, 팀은 인력 이동에 이르기까지 과도한 부담과 좌절감을 느끼게 됩니다.
