스크럼 작업

사용자 스토리

사용자 스토리는 개발 중인 소프트웨어에 대한 요구 사항을 설명하는 효과적인 방법입니다. 이러한 이야기에는 소프트웨어 사용자를 대신하여 간략한 조언이 포함되어 있습니다.

Scrum 방법론에서 목표 설정은 일반적으로 고객 또는 소프트웨어 소유자의 특권이므로 개발 프로세스에 영향을 미치는 주요 방법으로 간주됩니다. 각 사용자 스토리에는 텍스트의 양과 프레젠테이션의 복잡성에 제한이 있습니다. 역사는 대부분 작은 시트에 기록되며 그 자체로 볼륨이 제한됩니다.

사용자 스토리 덕분에 클라이언트의 희망 사항을 문서화하고 시장 요구에 신속하게 대응할 수 있습니다.

사용자 스토리는 승인 테스트 절차를 포함하지 않기 때문에 요구사항의 단순한 척도로 간주되어야 합니다. 사용자 스토리 편집은 입학 절차를 준수해야 합니다. 이렇게 하면 사용자 스토리가 목표를 달성할 수 있습니다.

스토리 구조는 다음과 같습니다. “<사용자 유형> 사용자로서 <결과>를 얻기 위해 <작업>을 수행하고 싶습니다."(제품 소유자로서 원하는 ...). 이러한 구조는 단순할 뿐만 아니라 모든 사람이 이해할 수 있습니다.

사용자 스토리 사용의 이점:

• 이야기는 작고 만들기 쉽습니다.
• 모든 이해 관계자가 프로젝트 및 지원 작업에 대해 논의하도록 돕습니다.
• 지속적인 유지 보수가 필요하지 않습니다.
• 사용하는 경우에만 관련이 있습니다.
• 고객과의 상호작용을 개선합니다.
• 덕분에 프로젝트를 작은 단계로 나눌 수 있습니다.
• 요구 사항을 제대로 이해하지 못한 프로젝트 작업을 촉진합니다.
• 작업 평가를 단순화합니다.

사용자 스토리의 단점:

• 사전 합의가 없으면 절차상 합의의 근거로 활용하기 어려울 수 있습니다.
• 이를 사용하려면 전체 프로젝트에서 고객과의 긴밀한 접촉이 필요하므로 때때로 작업 흐름이 어려워집니다.
• 대규모 프로젝트에서 확장할 때 단점이 있습니다.
• 개발자의 전문적인 수준과 직접 관련이 있습니다.
• 토론을 시작하는 데 사용되지만 토론을 종료할 수는 없으며 시스템 문서화에는 사용되지 않습니다.

백로그

제품 백로그는 우선 순위에 따라 컴파일된 목록 형식의 현재 작업입니다. 목록은 프로젝트의 로드맵(로드맵)과 그 안에 명시된 사항을 기반으로 구성됩니다. 가장 중요한 작업은 일반적으로 목록의 맨 위에 있습니다. 이것은 어떤 작업을 먼저 수행해야 하는지 이해하는 데 필요합니다.

개발 팀은 고객의 희망에 관계없이 백로그 작업 완료 속도를 선택하지만 과거 스프린트의 자격과 경험을 기반으로 합니다. 프로그래머를 "조정"하는 것은 매우 바람직하지 않습니다. 팀 자체는 자체 고려 사항 및 기능에 따라 백로그에서 작업을 선택합니다. 실행은 중단 없이(Kanban) 또는 여러 번의 반복(Scrum) 없이 이루어집니다.

두 가지 중요한 백로그 조건

제품 백로그의 핵심은 로드맵, 제안, 실행 조건으로 구성됩니다. 에픽에는 조건과 사용자 스토리가 포함되어 있습니다. 일반적인 로드맵 예제를 자세히 살펴보겠습니다.

“Teams in Space” 웹사이트의 생성은 로드맵의 첫 번째 제안입니다. 에픽 (그림에서 녹색, 파란색 및 청록색으로 표시됨)과 각 에픽에 대한 사용자 스토리 로 나누어야 합니다 .

소프트웨어 고객은 여러 사용자 스토리에서 하나의 목록을 구성합니다. 필요한 경우 스토리가 실행되는 순서를 변경하여 개발자가 먼저 가장 중요한 서사시(왼쪽) 중 하나를 처리하거나 할인된 티켓 예약이 어떻게 작동하는지 확인할 수 있습니다. 이렇게 하려면 에픽에서 스토리를 구현해야 합니다(오른쪽). 두 옵션 모두 아래에서 볼 수 있습니다.

고객은 어떤 요소를 기준으로 우선순위를 정해야 합니까?

• 사용자와의 관련성.
• 피드백의 존재.
• 개발의 복잡성.
• 작업 간의 관계("B"를 완료하려면 먼저 "A"를 수행해야 함).

작업의 우선 순위는 고객이 결정하지만 다른 당사자는 이에 대한 의견을 표명할 수 있습니다. 백로그의 성공 여부는 무엇보다도 고객과 프로그래머의 의견에 달려 있습니다. 함께하면 더 나은 결과를 달성하고 완제품을 적시에 납품할 수 있습니다.

백로그를 유지하는 방법

백로그가 이미 생성된 경우 추가 작업 과정에서 주기적으로 백로그를 변경해야 합니다. 소프트웨어 고객은 각각의 새로운 반복 계획 전에 백로그가 제대로 컴파일되었는지 확인해야 합니다. 이렇게 하면 마지막 반복 분석 후 우선 순위를 명확히 하거나 무언가를 변경하는 데 도움이 됩니다. 애자일에서 백로그를 조정하는 것을 "그루밍", "정제" 또는 "백로그 유지 관리"라고도 합니다.

백로그가 이미 비교적 큰 경우 고객은 단기 및 장기 실행별로 작업을 그룹화해야 합니다. 단기 과제는 이 지위를 부여받기 전에 면밀히 검토해야 합니다. 사용자 스토리를 작성하고 팀 내의 모든 뉘앙스를 찾아야 합니다.

장기 작업의 경우 개발자가 평가를 제공하는 것이 매우 바람직합니다. 이렇게 하면 우선 순위를 정하기가 더 쉬워집니다. 변경 사항이 있을 수 있지만 팀은 작업에 대한 이해를 높이고 작업을 더 빨리 완료할 수 있습니다.

백로그는 고객과 프로그래밍 팀 간의 중요한 구성 요소입니다. 고객은 고객 피드백, 예측 또는 새로운 요구 사항에 따라 항상 우선 순위를 변경할 수 있습니다.

작동 중에 직접 변경하지 않는 것이 좋습니다. 이것은 워크플로와 프로그래머의 감정 상태에 나쁜 영향을 미칩니다.

스프린트

스프린트는 이전에 합의된 작업량을 완료해야 하는 짧은 기간입니다. 스프린트는 Scrum 및 Agile 방법론을 기반으로 합니다. 올바른 스프린트를 선택하면 애자일 팀이 고품질 소프트웨어를 개발하는 데 도움이 됩니다.

“스크럼을 사용하면 명확한 기간(스프린트)으로 여러 반복으로 제품을 개발할 수 있습니다. 이는 대규모 프로젝트를 더 작은 작업으로 나누는 데 도움이 됩니다.”라고 Atlassian의 Jira 책임자인 Megan Cook은 말합니다.

스크럼은 스프린트를 어떻게 계획하고 실행합니까?

스크럼 방법론의 저자에 따르면 미래의 스프린트를 계획하려면 모든 사람이 별도의 회의에서 만나야 합니다. 이 이벤트에서 팀원들은 두 가지 주요 질문에 대한 답을 찾아야 합니다. 이 스프린트에서 수행해야 하는 작업과 최선의 방법은 무엇입니까?

소프트웨어 고객, 스크럼 마스터 및 프로그래머는 작업 목록을 결정하는 데 관여합니다. 고객은 백로그에서 스프린트의 목표와 작업을 설명합니다.

그런 다음 팀은 스프린트의 작업을 완료할 계획을 개발합니다. 선택한 작업 항목과 함께 이 계획을 스프린트 백로그라고 합니다. 계획 회의 후 팀은 작업을 시작합니다. 개발자는 백로그에서 작업을 선택하고 작업이 완료되면 각 작업의 상태가 "진행 중"에서 "완료"로 변경됩니다.

스프린트 동안 팀은 매일 스크럼 회의(스탠드업)를 열어 현재 문제와 진행 상황을 논의합니다. 이러한 회의는 스프린트 완료에 영향을 줄 수 있는 어려움을 식별하는 데 필요합니다.

스프린트가 완료되면 팀은 결과 검토(데모)에서 작업 결과를 보여줍니다. 프로젝트의 각 참가자는 결과를 알 수 있습니다. 완성된 코드를 프로덕션 환경에 병합하기 전에 익숙해져야 합니다.

회고전은 스프린트의 사이클을 완성합니다. 여기에서 팀은 향후 스프린트에서 개선해야 할 영역을 식별합니다.

주의해야 할 것과 하지 말아야 할 것

대부분의 젊은 팀은 스프린트를 워크플로에 처음 도입하는 데 어려움을 겪습니다. 문제를 방지하려면 우선적으로 주의를 기울여야 하는 작업 목록을 검토하는 것이 좋습니다.

우리가 뭘해야 하죠:

• 팀이 스프린트의 목적과 성공 방법을 이해하고 있는지 확인하십시오. 이것은 모두가 함께 성공적인 결과를 향해 나아가기 위해 필요합니다.
• 명확하고 이해할 수 있는 백로그가 있어야 합니다. 백로그가 올바르게 유지되지 않으면 워크플로우를 손상시킬 수 있는 문제가 될 수 있습니다.
• 여름 휴가 및 기타 요인을 고려하여 예상 작업 속도가 정확한지 확인하십시오.
• 스프린트 계획에 적극적으로 참여하십시오. 스토리, 버그 및 과제에 대한 계획을 확장하도록 팀원을 격려합니다.
• 개발자가 종속성 문제를 해결할 수 없는 작업을 거부합니다.
• 계획이 승인되면 프로젝트 관리 프로그램(Jira 카드 등)에 데이터를 입력할 직원을 임명합니다.

피해야 할 사항:

• 많은 이야기를 남용하지 말고 작업 속도를 냉정하게 평가하고 스프린트에서 완료하기 어려운 작업을 할당하지 마십시오.
• 작업의 품질에 유의하십시오. 코드의 품질 관리 및 버그 수정에 충분한 시간이 있는지 확인하십시오.
• 모든 팀원이 스프린트의 내용을 명확하게 이해했는지 확인하십시오. 속도를 쫓지 마십시오. 팀 전체가 함께 움직여야 합니다.
• 추가 작업으로 개발자에게 과도한 부담을 주지 마십시오. 곧 또 다른 스프린트가 시작됩니다.
• 팀이 업무량이나 기한에 대해 우려를 표시하는 경우 그들의 의견을 고려해야 합니다. 문제를 처리하고 필요한 경우 수정하십시오.

스크럼 보드

스크럼 보드는 스크럼 팀의 작업이 어떻게 수행되는지 보여주는 도구입니다. 이러한 게시판에 종이, 벽 또는 전자 형식(JIRA, Trello)으로 정보를 표시할 수 있습니다.

스크럼 보드에는 할 일, 진행 중 및 완료라는 세 가지 이상의 열이 있습니다. 다음은 예제 보드입니다.

스크럼 보드에는 계획을 위해 이전에 승인된 백로그의 모든 정보가 포함되어 있습니다. 일반적으로 비즈니스 작업 카드는 위에서 아래로 우선 순위에 따라 보드에 고정됩니다. 특정 유형의 작업(코드 작업, 디자인 작업 등)으로 나눌 수 있습니다.

작업의 일부가 완료되면 카드가 보드를 가로질러 다음 열로 이동합니다. 번다운 차트의 일별 "남은 작업"은 팀 작업의 진행 상황을 가시적으로 표시하는 데 도움이 됩니다.

플립 차트 보드를 사용할 수도 있습니다. 그 위에 종이스티커에 작품명을 적어 보드에 붙였다. 작업이 완료되는 즉시 스티커는 다른 열로 이동됩니다.

번다운 차트

번다운 차트는 완료된 작업량과 남은 작업량을 보여줍니다. 매일 업데이트되며 모든 관심 당사자가 사용할 수 있습니다. 스프린트 작업의 진행 상황을 표시하려면 그래프가 필요합니다.

두 가지 유형의 차트가 있습니다.

• 스프린트에서 작업 진행 상황을 보여주는 번다운 차트.
• 제품 출시까지의 작업 진행 상황을 보여주는 번다운 차트(데이터는 여러 스프린트에서 요약됨).

차트 예시:

이 예는 심리학을 사용합니다. 차트는 완료된 작업의 수가 아니라 남은(완료되지 않은) 수를 보여줍니다.

즉, 팀이 100개 작업 중 90개 작업을 수행했다면 모든 것이 준비되었다는 잘못된 느낌이 있을 수 있습니다. 결국, 90개에서 100개 작업으로 진행해도 아무 것도 변경되지 않습니다.

남은 작업 수를 표시하면 매번 작업이 점점 줄어들고 있음을 알 수 있습니다. 이것은 무의식적으로 프로젝트 참가자가 목표를 더 빨리 달성하도록 자극합니다. 보드에 완료되지 않은 작업이 있어서는 안됩니다.