다음을 통해 공유

스크럼 및 모범 사례

  • 아티클

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

스프린트 계획 모임

스프린트 계획의 대부분은 제품 소유자와 팀 간의 협상을 통해 초점을 결정하고 향후 스프린트에서 해결하기 위한 작업을 포함합니다. 계획 모임을 4시간 이하로 제한하여 시간 상자를 지정하는 것이 유용합니다.

모임의 첫 번째 부분에서 제품 소유자는 팀과 만나 스프린트에 포함될 수 있는 사용자 스토리를 논의합니다. 제품 소유자는 정보를 공유하고 팀이 해당 스토리에 대해 가지고 있는 질문에 답변합니다. 이 대화는 데이터 원본 및 사용자 인터페이스 레이아웃과 같은 세부 정보를 표시할 수 있습니다. 또는 응답 시간 기대치와 보안 및 유용성에 대한 고려 사항을 표시할 수 있습니다. 팀은 백로그 항목 양식 내에서 이러한 세부 정보를 캡처해야 합니다. 모임의 이 부분에서 팀은 빌드해야 하는 사항을 알아봅니다.

스프린트를 계획할 때 백로그를 캡처하고 추가하기 위한 다른 요구 사항을 발견할 수 있습니다. 잘 정의되고 우선 순위가 올바른지 확인합니다.

또한 계획 노력의 일환으로 스프린트 목표를 설정하면 팀이 각 스프린트에 가장 중요한 것에 집중할 수 있습니다.

스프린트를 계획한 후에는 주요 관련자와 계획을 공유할 수 있습니다.

다음 리소스에서 자세히 알아볼 수 있습니다.

스프린트 목표 설정

스크럼 팀은 스프린트 목표를 사용하여 스프린트 활동에 집중합니다. 스프린트 계획 모임에서 이 목표를 설정하는 경우가 많습니다. 목표는 스프린트가 끝날 때까지 팀이 달성하고자 하는 것을 요약합니다. 목표를 명시적으로 명시함으로써 핵심 목적의 팀 내에서 공유 이해를 만듭니다. 스프린트 목표는 우선 순위에 대한 충돌이 발생할 때 팀을 안내하는 데 도움이 될 수도 있습니다.

참호에서 팁: 스프린트 목표 정의

스프린트 목표는 제품 소유자와 팀이 해당 스프린트를 달성하기 위한 궁극적인 대상으로 간주하는 것을 정의합니다. 실제로 관계가 없는 백로그 항목을 임의로 선택하는 것이 아니라 팀이 수행해야 하는 작업을 캡처하는 짧은 텍스트입니다. 일반적으로 제품 소유자는 다음 스프린트에 대해 많은 항목을 선택하기 전에 스프린트 목표를 내놓습니다. 해당 스프린트의 항목은 모두 공통 목표에 적합해야 합니다.

스프린트 목표는 기능 지향적일 수 있지만 배포 자동화 또는 테스트 자동화와 같은 대규모 프로세스 구성 요소가 있을 수도 있습니다.

예시:

  • 이 스프린트는 간단한 사용자 스토리에 초점을 맞춥니다. 제안된 솔루션이 작동하는지 증명하는 데 사용합니다.
  • 이 스프린트는 웹 사이트의 관리 섹션을 제대로 보호하는 보안 기능 구현을 중심으로 진행됩니다.
  • 이 스프린트는 가장 중요한 결제 게이트웨이를 통합하여 자금 수집을 시작할 수 있도록 하는 것입니다.

스프린트 목표를 설정하면 팀이 집중력을 유지하는 데 도움이 됩니다. 스프린트 내에서 작업의 우선 순위를 더 쉽게 정의할 수 있으며 관련자와 관련된 최종 사용자의 수를 제한하는 데 도움이 될 수 있습니다.

스프린트 검토 중에 스스로에게 물어봐야 할 가장 중요한 질문은 스프린트 목표를 달성할 수 있었는지 여부입니다. 완료한 스토리의 개수는 두 번째로 발생합니다. 목표를 달성하면 모든 스토리가 완료되지 않더라도 스프린트가 성공합니다.

Jesse Houwing, Visual Studio devops Ranger 및 Avanade 네덜란드에서 일하는 선임 컨설턴트가 기여했습니다.

성공적인 심사 모임에 대한 팁

버그 수정은 다른 작업과의 절충을 나타냅니다. 심사 모임을 사용하여 프로젝트 범위, 예산 및 일정 충족과 관련된 다른 우선 순위에 대해 각 버그 수정이 얼마나 중요한지 확인합니다.

  • 수정할 버그와 우선 순위 및 심각도를 할당하는 방법을 평가하기 위한 팀의 기준을 설정합니다. 상당한 가치(또는 상당한 지연 기회 비용) 또는 기타 프로젝트 위험의 기능과 관련된 버그에는 더 높은 우선 순위와 심각도가 할당되어야 합니다. 심사 조건을 다른 팀 문서와 함께 저장하고 필요에 따라 업데이트합니다.
  • 심사 조건을 사용하여 수정할 버그와 상태, 우선 순위, 심각도 및 기타 필드를 설정하는 방법을 결정합니다.
  • 개발 주기에 있는 위치에 따라 심사 기준을 조정합니다. 초기에는 심사하는 대부분의 버그를 수정할 수 있습니다. 그러나 주기의 뒷부분에서 수정해야 하는 버그 수를 줄이기 위해 심사 기준을 높일 수 있습니다.
  • 버그를 심사한 후에는 개발자에게 할당합니다. 그런 다음 개발자는 수정을 구현하는 방법을 조사하고 결정할 수 있습니다.

기술 부채 관리

팀의 전반적인 지속적인 개선 활동 집합의 일부로 버그 표시줄 및 기술 부채를 관리하는 것이 좋습니다. 다음과 같은 관심 있는 리소스를 찾을 수 있습니다.

참호에서 팁: 버그 관리

Agile 버그 관리: 옥시모론이 아님
작성자: Microsoft의 Visual Studio Cloud Services 수석 프로그램 관리자인 Gregg Boer

모든 스프린트에서 알려진 버그 부채 해결

모든 스프린트에서 팀은 버그 백로그에서 다시 기본 버그를 살펴보고 알려진 버그 집합을 0 또는 0에 가까운 0으로 낮추기 위해 용량을 바칩니다. 하루, 1주일 또는 전체 스프린트이든 관계없이 먼저 버그를 수정합니다. 스프린트 내에서 나중에 발견된 버그는 초기 약정의 일부로 간주되지 않습니다. 우선 순위가 높지 않으면 다음 스프린트에 대한 버그 백로그에 배치됩니다.

많은 팀이 약정 기반 조직에서 작업합니다. 종종 경영진은 팀의 약속을 이행할 수 있는 능력에 높은 가치를 줍니다. 알려진 버그 집합에 대해 용량 계획을 수행하면 스프린트 계획이 보다 결정적이 되어 약정을 충족할 기회가 늘어납니다. 스프린트 중에 발견된 모든 새 버그는 초기 약정의 일부가 아니며 다음 스프린트에서 해결할 수 있습니다.

기업 전체에서 버그 부채 관리

부채가 지속적으로 제거되는 문화로 전환하는 조직은 다음 질문을 다루고 있습니다. 정확히 무엇을 해야 할지 말하지 않고 팀이 버그 수를 줄이려면 어떻게 해야 할까요? 리더십은 팀이 변경되기를 원하지만 팀이 어떻게 변화하는지 결정할 수 있는 자율성을 부여합니다. 한 가지 옵션은 버그 한도를 사용하는 것입니다.

예를 들어 엔지니어당 3개의 버그로 구성된 버그 한도를 고려해 보세요. 따라서 10명으로 구성된 팀은 버그 백로그에 30개 이상의 버그가 없어야 합니다. 팀이 한도를 초과하면 새로운 기능에 대한 작업을 중지하고 버그 한도를 밑도는 것으로 예상됩니다. 팀은 항상 상한선에 있을 것으로 예상되지만, 팀은 이를 어떻게 할 것인지 결정합니다. 버그 한도는 팀이 버그 부채를 너무 오랫동안 수행하지 않도록 합니다. 팀은 버그가 처음에 주입되는 실수를 통해 배울 수 있습니다.

버그 한도는 버그 백로그의 버그를 나타냅니다. 기능이 개발된 스프린트 내에서 찾아서 수정된 버그가 포함되지 않습니다. 이러한 버그는 부채가 아닌 실행 취소 작업으로 간주됩니다.

버그가 기술적인 부채에 영향을 주지만 모든 부채를 나타내는 것은 아닙니다.

소프트웨어 설계가 잘못되거나, 코드가 잘못 작성되거나, 단기 수정이 모두 기술적인 문제에 영향을 줄 수 있습니다. 기술적인 문제는 이러한 모든 문제에서 발생하는 추가 개발 작업을 반영합니다.

PPI, 사용자 스토리 또는 버그로 기술 문제를 해결하기 위한 작업을 추적합니다. 기술적인 문제를 발생시키고 해결하는 팀의 진행 상황을 추적하려면 작업 항목과 추적하려는 세부 정보를 분류하는 방법을 고려해야 합니다. 모든 작업 항목에 태그를 추가하여 선택한 범주로 그룹화할 수 있습니다.

스크럼 마스터의 역할

스크럼 마스터는 스크럼 프로세스를 사용하여 건강한 팀을 구축하고 기본 수 있습니다. 그들은 스크럼 방법의 적절한 고용에 스크럼 팀을 안내, 코치, 가르치고, 지원합니다. 스크럼 마스터는 팀이 장애를 극복하고 팀을 상당한 생산성 향상으로 이끌 수 있도록 변경 에이전트 역할을 합니다.

스크럼 마스터의 핵심 책임은 다음과 같습니다.

  • 팀이 스크럼 프로세스를 채택하고 따르도록 지원합니다. 예를 들어 매일 스크럼 모임이 45분 동안 지속되는 공개 토론이 되도록 해서는 안 됩니다.

  • 스프린트가 시작된 후 제품 소유자 또는 팀 구성원이 작업을 추가하지 않도록 방지합니다.

  • 팀이 앞으로 나아갈 수 없는 차단 문제를 제거합니다. 이 작업을 수행하려면 새 빌드 컴퓨터에 대한 구매 주문 승인 또는 팀 내 충돌 해결과 같은 작은 작업을 완료해야 할 수 있습니다.

  • 팀에서 발생하는 충돌 및 문제를 해결하고 프로세스에서 학습할 수 있도록 지원합니다.

  • 숨겨진 문제를 드러내는 질문을 하고 사람들이 의사 소통하는 것이 전체 팀에서 잘 이해되는지 확인합니다.

  • 주요 문제가 되는 잠재적인 문제로부터 팀을 식별하고 보호합니다. 버그가 발견된 직후에 버그를 수정하는 것이 더 저렴해지듯이, 작고 관리하기 쉬운 경우 팀 문제를 해결하는 것이 더 쉽고 덜 방해가 됩니다.

  • 스프린트 검토 모임 중에 팀이 불완전한 사용자 스토리를 표시하지 못하도록 합니다.

  • 비즈니스 이해 관계자에게 데이터를 수집, 분석 및 제시하여 팀이 어떻게 개선되고 성장하는지 보여 줍니다. 예를 들어 팀이 버그를 줄이면서 전달한 값의 양을 늘리면 비즈니스 관련자와의 정기적인 통신을 통해 값을 표시합니다.

좋은 스크럼 마스터는 뛰어난 의사 소통, 협상 및 충돌 해결 기술을 가지고 있거나 개발합니다. 그들은 사람들이 말하고 쓰는 단어를 적극적으로 듣습니다. 그들은 또한 그들의 메시지를 전달 하는 방법을 듣고, 예를 들어 그들의 신체 언어, 얼굴 표정, 보컬 속도, 그리고 다른 비언어적 통신.

버그가 발견된 직후에 버그를 해결하는 것이 더 저렴해지듯이, 주요 문제로 성장하기 전에 작고 관리하기 쉬운 팀 문제를 해결하는 것이 더 쉽고 덜 파괴적입니다.

매일 스크럼 모임

매일 스크럼 모임은 팀이 다음 날 해야 할 일에 집중할 수 있도록 도와줍니다. 집중력을 유지하는 것은 팀이 스프린트 약정을 충족하는 능력을 극대화하는 데 도움이 됩니다. 스크럼 마스터는 모임의 구조를 적용하고 모임이 정시에 시작되고 15분 이내에 완료되도록 해야 합니다.

스크럼 모임의 세 가지 측면은 다음과 같습니다.

  • 모두가 일어섰다. 일어서면 모임의 초점을 맞추고 짧게 유지하는 데 도움이 됩니다.
  • 정시에 시작 및 종료되며 매일 같은 위치에서 동시에 발생합니다.
  • 모두가 참여하며, 각 팀 구성원은 세 가지 스크럼 질문에 답변합니다.
    • 가장 최근의 스크럼 이후 무엇을 성취했나요?
    • 다음 스크럼 전에 무엇을 수행할 수 있나요?
    • 내 작업에 영향을 줄 수 있는 차단 문제 또는 장애는 무엇인가요?

참고 항목

스크럼 모임의 초점은 한 팀 구성원에서 다른 팀 구성원으로 전달해야 하는 작업의 상태 있습니다.

팀 구성원은 질문에 신속하고 간결하게 답변하기 위해 노력해야 합니다. 예시:

"어제 데이터베이스에서 가져온 새 데이터 요소를 반영하도록 클래스를 업데이트했고 인터페이스에 표시되도록 했습니다. 이 작업이 완료되었습니다. 이제 새 데이터 요소가 저장 프로시저 및 테이블의 다른 데이터 요소로 올바르게 계산되는지 확인합니다. 저는 오늘 이 일을 완수할 수 있다고 믿습니다. 내 계산을 검토할 사람이 필요합니다. 장애나 차단 문제가 없습니다."

이 응답은 팀 구성원이 수행한 작업, 팀 구성원이 수행할 계획 및 팀 구성원이 코드를 살펴보는 데 도움이 되도록 하는 내용을 전달합니다.

다음 예제와 대비합니다.

"어제 수업에 대해 작업했는데, 제대로 작동합니다. 오늘, 나는 인터페이스에서 작동합니다. 차단 문제가 없습니다."

팀 구성원은 자신이 작업한 클래스나 완료할 인터페이스 구성 요소에 대해 충분한 세부 정보를 제공하지 않습니다. 사실, 성취된 단어는 결코 나타나지 않았습니다.

보고서 출력 중에는 아무도 중단하지 않는 것이 중요합니다. 각 사람은 세 가지 질문에 대답할 충분한 시간이 있어야 합니다.

회의 후, 사람들이 책상으로 돌아오거나, 상당한 양의 대화가 필요한 경우 후속 회의에서 더 심층적이고 후속 논의가 이뤄져야 합니다.

많은 팀이 "가상 주차장" 방법을 사용하여 토론을 지연합니다. 주제가 팀 구성원이 추가 토론이 필요하다고 생각함에 따라 조용히 화이트 보드 또는 플립 차트로 걸어 가서 주차장에 주제를 나열 할 수 있습니다. 모임이 끝나면 팀은 나열된 항목을 처리하는 방법을 결정합니다.

스프린트 검토 모임

스프린트의 마지막 날에 스프린트 검토 모임을 수행합니다. 팀에서는 스프린트에서 완료된 각 제품 백로그 항목을 보여 줍니다. 제품 소유자, 고객 및 관련자는 자신의 기대치를 충족하는 사용자 스토리를 수락하고 새로운 요구 사항을 식별합니다. 고객은 종종 데모를 본 후 요구 사항을 더 완벽하게 이해하고 보고 싶은 변경 내용을 식별할 수 있습니다.

이 모임에 따라 일부 사용자 스토리는 완료된 것으로 수락됩니다. 불완전한 사용자 스토리는 제품 백로그에 다시 기본. 새 사용자 스토리가 백로그에 추가됩니다. 두 스토리 세트 모두 다음 스프린트 계획 회의에서 순위가 매겨지고 예측되거나 다시 예측됩니다.

이 모임과 회고 회의 후에 팀은 다음 스프린트를 계획합니다. 비즈니스 요구 사항이 빠르게 변경되므로 제품 소유자, 고객 및 이해 관계자와의 이 모임을 활용하여 제품 백로그의 우선 순위를 다시 검토할 수 있습니다.

스프린트 회고 모임

회고는 잘 정기적으로 수행되는 경우 지속적인 개선을 지원합니다.

스프린트 회고 회의는 일반적으로 스프린트 검토 회의 후 스프린트의 마지막 날에 발생합니다. 이 모임에서 팀은 스크럼의 실행과 조정이 필요할 수 있는 사항을 살펴봅니다.

논의에 따라 팀은 하나 이상의 프로세스를 변경하여 자체 효율성, 생산성, 품질 및 만족도를 향상시킬 수 있습니다. 이 모임과 그 결과로 개선된 사항은 자기 조직의 민첩한 원칙에 매우 중요합니다.

참고 항목

팀의 회고를 지원하려면 Marketplace 회고전 확장을 설치하는 것이 좋습니다 . 이 확장은 프로젝트 마일스톤에 대한 피드백 수집, 피드백 구성 및 우선 순위 지정, 팀이 시간이 지남에 따라 개선할 수 있도록 실행 가능한 작업을 만들고 추적하도록 지원합니다.

팀 스프린트 회고전 중에 이러한 영역을 해결합니다.

  • 팀의 일반적인 효율성, 생산성 및 품질에 영향을 주는 문제입니다.

  • 팀의 전반적인 만족도 및 프로젝트 흐름에 영향을 주는 요소입니다.

  • 불완전한 백로그 항목의 원인은 무엇인가요? 팀에서 향후 이러한 문제를 방지하기 위해 수행할 수 있는 작업은 무엇인가요?

    예를 들어 팀의 한 개인만 수행할 수 있는 여러 작업이 있는 팀을 생각해 보세요. 고립된 전문 지식은 스프린트의 성공을 위협하는 중요한 경로를 만들었습니다. 개별 팀원은 추가 시간을 투입했고, 다른 팀원들은 더 많은 도움을 줄 수 없다는 좌절감을 느낍니다. 앞으로 팀은 시간이 지남에 따라 이 문제를 해결할 수 있도록 eXtreme 프로그래밍을 연습하기로 결정했습니다.

팀으로서 스프린트 중 문제 발생을 최소화하기 위해 하나 이상의 프로세스를 조정할지 여부를 결정합니다.

팀은 개선을 구현하기 위해 몇 가지 작업을 수행해야 할 수 있습니다. 예를 들어 실패한 빌드가 너무 많아 부정적인 영향을 받은 팀은 연속 통합을 구현하기로 결정했습니다. 프로세스를 중단하고 싶지 않았기 때문에 프로덕션 빌드에서 켜기 전에 평가판 빌드를 설정하는 데 몇 시간이 걸렸습니다. 이 작업을 나타내기 위해 스파이크를 만들고 나머지 제품 백로그에 대해 작업하도록 구성했습니다.