추정은 어렵습니다. 소프트웨어 개발자에게 있어서 가장 어려운 부분은 아니라면 가장 어려운 측면 중 하나입니다. 제품 소유자가 전체 팀과 비즈니스에 영향을 미치는 결정을 내리는 데 도움이 되는 수많은 요소를 고려해야 합니다. 영향이 크기 때문에 개발자부터 고위 경영진에 이르기까지 모든 과민하게 반응하는 것은 놀라운 일이 아닙니다. 하지만 그것은 실수입니다. 애자일 스토리 포인트는 단지 추정치에 불과합니다. 피의 맹세가 아닙니다.
작업의 과소 평가한 대가로 주말에 일할 필요는 없습니다. 그럼 이제 애자일 추정치를 최대한 정확하게 만드는 몇 가지 방법을 살펴보겠습니다.
제품 소유자와 공동 작업
애자일 개발에서 제품 소유자는 백로그(제품에 대해 원하는 모든 기능 및 수정 사항에 대한 간단한 설명이 포함된 정렬된 작업 목록)의 우선 순위를 지정해야 합니다. 제품 소유자는 비즈니스의 요구 사항을 캡처하지만 구현의 세부 사항을 항상 이해하지는 못합니다. 따라서 좋은 평가를 통해 제품 소유자는 각 작업 항목의 작업 수준에 대한 새로운 인사이트를 얻을 수 있으며, 이것은 각 항목의 상대적 우선 순위에 대한 평가로 피드백이 됩니다.
엔지니어링 팀이 추정 프로세스를 시작할 때 일반적으로 요구 사항 및 사용자 스토리에 대한 의문이 생깁니다. 긍정적인 신호입니다. 이러한 질문은 팀 전체가 작업을 더 완벽하게 이해하는 데 도움이 됩니다. 특히 제품 소유자의 경우 스토리 포인트를 통해 작업 항목을 세부적인 작업과 추정치로 분할하면 모든(또한 잠재적으로 숨겨진) 작업 영역의 우선 순위를 지정할 수 있습니다. 그러므로 개발 팀에서 추정치를 얻은 후에 제품 소유자가 백로그에서 항목의 순서를 바꾸는 것은 드문 일이 아닙니다.
애자일 스토리 포인트 추정은 팀의 활동
모든 팀원(개발자, 설계자, 테스터, 배포자 등 모두)을 참여시키는 것이 핵심입니다. 각 팀원은 제품 및 사용자 스토리를 전달하는 데 필요한 작업에 대해 서로 다른 관점을 제시합니다. 예를 들어, 제품 관리에서 새로운 웹 브라우저를 지원하는 것과 같이 단순해 보이는 작업을 수행하려는 경우 개발 및 QA 팀이 의견을 제시해야 합니다. 이들 팀은 경험에서 무언가 복잡한 일이 표면 아래서 벌어질 수 있음을 말해줄 수 있기 때문입니다.
마찬가지로 설계 변경에는 설계 팀의 의견뿐 아니라 개발 및 QA 팀의 의견도 필요합니다. 광범위한 제품 팀의 일부를 추정 프로세스에서 제외하면 품질 추정치가 낮아지고 주요 기여자가 포함되어 있지 않다고 느끼기 때문에 사기가 떨어지고 소프트웨어 품질이 저하됩니다.
따라서 팀이 외부와 단절된 상태에서 추정하지 않도록 하세요. 이것은 실패로 이어지는 빠른 길입니다!
스토리 포인트를 사용해 보시겠습니까? 먼저 Jira에 등록하거나 로그인하세요
스토리 포인트와 시간 비교
기존 소프트웨어 팀은 일, 주, 월 등 시간 형식으로 추정치를 제공합니다. 그러나 많은 애자일 팀이 스토리 포인트로 전환했습니다. 스토리 포인트는 제품 백로그 항목 또는 기타 작업을 완전히 구현하는 데 필요한 전반적인 노력의 추정치를 표현하기 위한 측정 단위입니다. 팀은 작업 복잡성, 작업량, 위험 또는 불확실성과 관련하여 스토리 포인트를 할당합니다. 작업을 더 작은 조각으로 더 효과적으로 나누기 위해 값을 할당하므로 불확실성을 해결할 수 있습니다. 이것은 시간이 지나면서 팀이 일정 기간 동안 얼마나 많은 성과를 달성할 수 있는지 이해하고 솔루션에 대해 합의하고 약속할 수 있게 합니다.직관적이지 않은 것처럼 들릴지 있지만, 이 추상화는 팀이 작업의 어려움에 대해 더 엄격한 결정을 내리도록 강요하기 때문에 실제로 유용합니다. 스토리포인트를 사용하는 몇 가지 이유는 다음과 같습니다.
- 날짜는 일상에 불가피하게 존재하는 프로젝트와 무관한 작업(팀원이 포함되었을 수 있는 인터뷰, 회의 또는 이메일)을 고려하지 않습니다.
- 날짜에는 정서적인 애착이 있습니다. 상대적 추정은 이 정서적인 애착을 제거합니다.
- 각 팀은 약간 다른 척도로 작업을 추정합니다. 즉, 속도(포인트로 측정)가 자연스럽게 달라집니다. 따라서 속도를 무기로 정치적 결정을 내릴 수는 없습니다.
- 각 스토리 포인트 값의 상대적 활동에 동의하면 많은 논쟁 없이 신속하게 포인트를 할당할 수 있습니다.
- 스토리 포인트는 시간이 아닌 난이도에 따라 문제를 해결한 팀원에게 보상합니다. 이를 통해 팀원들은 시간 소비가 아닌 가치 제공에 집중할 수 있습니다.
안타깝게도 스토리 포인트는 오용되는 경우가 많습니다. 스토리 포인트는 팀원들을 판단하고, 자세한 타임라인과 리소스를 할당하고, 생산성 척도로 오인하는 경우 잘못됩니다. 대신 팀은 스토리 포인트를 사용하여 작업의 규모와 작업의 우선 순위를 파악해야 합니다. 스토리 포인트 및 추정 관행에 대한 심층적인 논의를 보려면 이 업계 전문가와의 원탁 회의를 확인하고 더 많은 애자일 추정 팁을 읽어보세요.
스토리 포인트 및 계획 포커
스토리 포인트로 시작하는 팀은 계획 포커라는 연습을 사용합니다. Atlassian에서 계획 포커는 회사 전체에서 일반적인 관행입니다. 팀은 백로그에서 항목을 가져와 간략하게 논의하고 각 구성원은 마음속으로 추정치를 공식화합니다. 그런 다음 모든 사람이 자신의 추정치를 반영하는 번호가 적힌 카드를 제시합니다. 모두가 동의한다면 훌륭합니다! 그렇지 않은 경우 다른 추정치의 근거를 이해하는 데 시간을 할애하세요(너무 많은 시간이 아닌 단 몇 분). 그러나 추정은 높은 수준의 활동이어야 합니다. 팀이 바람직하지 않은 방향으로 너무 멀리 갔다면 잠시 쉬어가는 시간을 갖고 토론의 수준을 높이세요.
시도해 볼 준비가 되셨습니까?
더 스마트하고 쉬운 추정
어떤 개별 작업도 16시간을 초과해서는 안 됩니다. (스토리 포인트를 사용하는 경우, 예를 들어 20포인트를 상한선으로 결정할 수 있습니다.) 높은 신뢰도를 사용해 개별 작업 항목을 해당 신뢰도보다 더 크게 추정하기는 너무 어렵습니다. 이러한 신뢰도는 백로그 맨 위에 있는 항목에 특히 중요합니다. 어떤 작업이 팀의 16시간(또는 20포인트) 임계값을 초과하는 것으로 추정되면 이는 더 세분화된 작업으로 분할하고 다시 추정할 것을 요구하는 신호입니다.
백로그의 더 깊은 곳에 있는 항목의 경우 대략적인 추정치를 제공합니다. 팀이 실제로 이러한 항목에 대한 작업을 시작할 때까지 요구 사항이 변경될 수 있으며 애플리케이션도 분명히 변경될 것입니다. 따라서 이전 추정치가 정확하지 않을 것입니다. 전환 가능성이 있는 작업을 추정하는 데 시간을 낭비하지 마세요. 제품 소유자에게 제품 로드맵 우선 순위를 적절하게 지정하는 데 사용할 수 있는 대략의 수치를 제공하기만 하면 됩니다.
과거 추정에서 학습
회고는 팀이 추정치의 정확성을 포함하여 과거 반복에서 얻은 인사이트를 통합하는 시점입니다. 많은 애자일 도구(예: Jira)는 스토리 포인트를 추적하므로 추정치를 훨씬 더 쉽게 돌아보고 다시 보정할 수 있습니다. 예를 들어 팀이 스토리 포인트 값 8로 전달한 마지막 5개의 사용자 스토리를 가져와서 각 작업 항목의 작업 수준이 비슷한지 논의합니다. 그렇지 않은 경우 이유를 논의합니다. 향후 추정 논의에서 인사이트를 활용합니다.
애자일의 다른 모든 것들과 마찬가지로 추정도 하나의 관행입니다. 시간이 갈수록 더 좋아질 것입니다.
관련 리소스
