스크럼의 프로세스

스프린트 계획

스프린트 계획은 스크럼 스프린트의 초기 단계입니다. 스프린트 중에 작업을 수행하는 범위와 방법을 결정합니다. 전체 스크럼 팀이 계획에 참여합니다.

스프린트는 특정 작업을 완료해야 하는 명확하게 정의된 기간입니다. 스프린트는 시작하기 전에 계획이 필요합니다. 우선 스프린트의 기간과 목표를 결정해야 합니다.

계획 워크샵에서 작업 목록과 스프린트 목표가 합의됩니다. 각 구성원이 성공에 집중할 수 있도록 팀에 올바른 작업 동기를 부여하는 것이 중요합니다.

스프린트가 제대로 계획되지 않으면 팀이 실패할 수 있습니다. 작업이 비현실적인 것으로 판명되었기 때문에 개발자는 기대에 부응할 수 없습니다.

스프린트를 계획할 때 고려해야 할 질문:

• 고객 또는 소프트웨어 소유자는 달성 방법을 설명하면서 스프린트의 목표를 발표합니다. Scrum 팀은 이 목표를 달성하기 위해 향후 스프린트에서 어떤 작업을 완료할 수 있는지 알아냅니다.
• 개발자는 소프트웨어 고객과 합의한 작업 계획을 그들 사이에 배포합니다.
• 제품의 고객(소유자)은 항상 스프린트 계획 작성에 참여합니다. 그는 목표를 설정하고 프로그래밍 팀은 스프린트에서 목표를 달성할 수 있는지 알아내야 합니다.
• 계획은 계획에 추가할 수 있는 정보인 제품 백로그를 사용해야 합니다.
• 팀 구성원은 결과를 달성하기 위해 필요한 것이 무엇인지 명확히 이해하고 계획 회의를 종료해야 합니다. 스프린트 백로그에 향후 작업 순서를 표시할 수 있습니다.

계획은 주당 2시간을 초과해서는 안 됩니다. 스크럼 마스터는 모든 사람에게 시간 제한이 있음을 설명해야 합니다. 모든 업무 문제가 신속하게 해결되면 회의가 평소보다 일찍 끝날 수 있습니다. 그러한 회의에는 최소 기간이 없습니다.

작업 평가

작업의 복잡성을 평가하는 것은 그것을 과장할 필요가 없습니다. 계획 프로세스는 정확하지는 않지만 적어도 개발의 복잡성에 대한 대략적인 평가가 필요합니다. 팀은 스프린트의 목표를 이해할 뿐만 아니라 팀의 역량과 목표를 비교해야 합니다.

복잡성을 평가하기 위해 모든 사람에게 일반적인 의류 크기(L, XL, XXL)를 사용할 수 있습니다. 물론 이것은 정확성을 보장하지는 않지만 여전히 그렇습니다.

복잡성 평가를 보다 정확하게 하기 위해서는 상호 이해가 필요합니다. 팀원들은 자신의 의견을 공개적으로 공유하고 제품 소유자에게 질문하는 것을 두려워하지 않아야 합니다.

작업이 완료된 후 팀에 대한 비판은 다음 스프린트를 계획할 때 예측이 덜 낙관적이라는 사실로 이어질 수 있습니다. 이렇게 하면 팀이 실수를 반복하지 않고 향후 부정적인 평가를 받지 않도록 보호할 수 있습니다.

포인트, 포인트 및 시간의 난이도 평가

일반적으로 개발 팀은 시간이 지남에 따라 작업의 복잡성을 예측합니다. 그러나 일부 애자일 팀은 포인트 또는 포인트로 난이도를 평가하기로 선택합니다. 이는 백로그 항목 또는 기타 할당된 작업을 구현하는 데 필요한 총 비용을 더 잘 나타냅니다.

점수는 작업의 복잡성과 양에 따라 부여됩니다. 또한 가능한 위험이 고려됩니다. 이 방법을 사용한 채점은 작업을 작은 단계로 효과적으로 나누는 데 도움이 됩니다.

계획할 때 채점 방법(점수)을 정기적으로 사용함으로써 팀은 작업을 완료하는 데 필요한 시간을 더 정확하고 정확하게 이해할 수 있습니다. 이외에도 다른 장점도 있습니다.

• 예상 시간은 프로젝트와 직접적으로 관련되지 않은 작업을 고려하지 않지만 확실히 나타납니다. 메신저를 통해 업무 문제를 논의하고 회의를 여는 등 팀원에게도 시간이 걸립니다.
• 감정은 날짜 선택에 영향을 줄 수 있습니다. 작업을 평가할 때 점수를 매기면 이 요소가 제거됩니다.
• 작업의 복잡성에 대한 평가와 그에 따른 작업 완료 속도는 팀마다 다를 수 있습니다. 포인트 작업은 속도의 지표로 간주될 수 없습니다. 즉, 팀에 심리적 압박이 없습니다.
• 인건비와 복잡성을 올바르게 분배함으로써 참여자 간에 수행되는 작업의 포인트를 충돌 없이 신속하게 나눌 수 있습니다.
• 작업을 완료하여 받는 점수는 소요 시간이 아니라 복잡성에 따라 다릅니다. 따라서 프로그래머는 시간이 얼마나 걸리는지보다는 효율성 향상에 대해 생각할 것입니다.

복잡성 추정의 단점은 종종 오용된다는 것입니다. 예를 들어 이 방법은 직원을 평가하는 데 사용할 수 없습니다.

팀은 할당된 작업의 양을 더 잘 이해하고 우선 순위를 올바르게 지정하기 위해 채점 시스템을 사용해야 합니다.

일일 스크럼 회의

워크샵은 중요합니다. 워크샵에서 팀원은 의견을 공유하고 의사 소통하며 추가 조치에 동의합니다. 팀 정신을 고양하고 최신 소식을 알리기 위해 일일 스크럼 회의도 필요합니다.

스탠드업은 소프트웨어 소유자, 프로그래머 및 스크럼 마스터와 같은 주요 프로젝트 참가자의 간단한 회의입니다. 스탠드업의 구조는 세 가지 질문으로 구성됩니다.

• 우리는 어제 무엇을 할 수 있었습니까?
• 오늘 우리는 무엇을 하고 있습니까?
• 결과를 달성하는 데 방해가 되는 것은 무엇입니까?

이러한 질문을 하면 개발이 촉진되고 팀 내의 문제를 식별하는 데 도움이 됩니다. 각 참가자가 공동의 목표를 달성하는 데 어떻게 도움이 되는지 소통할 때 팀 내 상호 이해가 향상됩니다.

스탠드업을 수행하는 방법에 대한 단일 템플릿이 없다는 것을 기억하는 것이 중요합니다. 각 팀은 팀의 특성에 따라 자체 모델에 따라 회의를 진행합니다.

이제 완벽한 기립을 위해 무엇이 필요한지 논의하고 효과적인 기립의 예에 대해 알아보겠습니다.

먼저 모든 사람에게 적합한 시간을 선택해야 합니다. 일반적으로 같은 사무실의 팀을 위한 스탠드업은 근무일 시작 시간(아침 9시에서 10시 사이)에 열립니다. 이를 통해 하루 일정을 더 잘 계획할 수 있습니다. 팀원이 다른 지역에서 근무하는 경우 모든 사람에게 적합한 시간이 선택됩니다. 예를 들어 일부 팀원이 캘리포니아와 시드니에 거주하는 경우 스탠드업은 캘리포니아 시간으로 15:30에 시작됩니다. 물론 저녁 식사 후 스탠드 업이 모든 사람에게 편리한 것은 아니지만 바다 건너편에 있는 동료들과 연락을 유지할 수 있습니다.

스탠드 업 생산성을 추적하십시오. 너무 오래 회의를 열지 마십시오. 주의 집중이 최상으로 유지되어야 합니다. 가능하면 스탠드업을 15분 이상 하지 마십시오.

공을 사용하십시오. 차례로 서로에게 던질 수 있습니다. 그래서 모두가 토론에 참여할 것입니다. 이 게임은 그룹의 관심을 유지하는 데 도움이 됩니다. 팀 회고를 사용하십시오. 스탠드업은 많은 애자일 방법론에서 사용되며 회고에서 스탠드업의 효과에 대해 논의하는 것을 막지는 않습니다. 누군가는 매일, 다른 팀은 일주일에 두 번 만납니다. 만약 팀이 스탠드업으로 이득을 보기 어렵다면 그 이유를 찾아 무언가를 바꾸십시오.

스프린트 리뷰

스프링 리뷰는 스프린트의 마지막 단계에서 수행됩니다. 제품 증분을 확인하고 백로그를 조정해야 합니다. 전체 스크럼 팀과 모든 이해 관계자가 스프린트 결과 검토에 참여합니다. 회의는 프로젝트 참가자의 상호 작용을 개선하기 위해 편안한 형식으로 진행됩니다.

스프린트 결과 검토에는 다음 요소가 포함됩니다.

• 소프트웨어 소유자는 백로그에서 완료된 것과 완료되지 않은 것을 보여줍니다.
• 프로그래머들은 무엇이 잘 되었는지, 어디에서 어려움이 나타났는지, 어떻게 제거되었는지에 대해 토론합니다.
• 개발 팀은 스프린트 동안 작업 결과와 그들이 받은 제품 증분을 보여줍니다.
• 제품 소유자는 현재 백로그에 대한 자신의 생각을 공유합니다. 또한 다음 목표에 대한 예측과 구현 기한을 제공합니다.
• 모든 사람이 시장 평가 및 사용자 관심사에 따라 다음에 수행할 최선의 방법을 논의합니다.
• 백로그에 추가할 시기, 예산 및 전망에 대한 의견 교환이 있습니다.

그 결과 후속 스프린트에 대한 새로운 목표가 포함된 업데이트된 백로그가 생성됩니다. 상황에 따라 백로그가 변경될 수 있습니다.

스프린트 회고전

Sprint Retrospective는 작업 흐름을 개선하는 방법을 논의하는 워크숍입니다. 또한 다음 스프린트에 대한 개선 계획을 작성합니다. 회의는 일반적으로 스프린트 검토 후에 이루어지며 소요 시간은 3시간을 넘지 않습니다. 회의를 이끄는 것은 스크럼 마스터입니다.

Sprint Retrospective의 주요 목표는 다음과 같습니다.

• 스프린트 분석(참가자의 작업, 결과 및 문제).
• 후속 스프린트에서 작업 흐름을 개선하기 위해 가능한 솔루션에 대해 논의하십시오.
• 프로젝트를 구현하는 동안 팀 구성원이 개선 사항을 구현하기 위한 계획을 작성합니다.

스크럼 마스터는 팀 구성원을 초대하여 개발 효율성을 개선하는 방법에 대한 제안을 합니다. 팀은 제안에 대해 논의하고 구현을 위한 특정 방법과 기술을 제안합니다.

Sprint Retrospective가 끝나면 팀은 다음 스프린트에서 구현할 몇 가지 개선 제안을 강조해야 합니다. 제안은 언제든지 구현할 수 있지만 Sprint Retrospective는 팀의 관점에서 가능한 적응을 더 깊이 살펴볼 수 있는 기회를 제공합니다.

여기에서 스크럼 방법론에 대한 논의를 마칩니다. 주제별 문서 또는 첫 직장에서 이에 대해 자세히 알아볼 수 있습니다.