애자일 추정 기법 : 애자일 프로젝트의 진정한 추정

agile estimation techniques

애자일 프로젝트의 진정한 추정 : 애자일 추정에 대한 예제가 포함 된 완전한 통찰력

다양한 수준에서 애자일 추정을 수행하는 것이 매우 중요합니다. 이는 지정된 기한 내에 원하는 제품을 구현, 테스트 및 고객에게 제공하는 데 사용할 전체 노력을 적절한 계획, 관리 및 추정하기 위해 수행됩니다.

애자일 프로젝트의 예상치가 부족하면 원치 않는 제품을 제공하여 고객이 만족하지 못하게 될 수있는 적절한 계획 및 관리가 없을 수 있습니다.

스토리 포인트 추정은 Planning Poker, Bucket System, Affinity Mapping 등과 같은 다양한 기술을 사용하여 Agile 프로젝트에서 수행됩니다. Agile Project Plan Template, Release Plan Template, Sprint Plan Template, RoadMap Template과 같은 다양한 수준의 다양한 추정 템플릿이 이러한 목적에 사용됩니다. , 사용자 스토리 템플릿 등

학습 내용 :

• 소개
• 애자일의 스토리 포인트 추정
• 권장 도구
• 다양한 애자일 추정 기법
  • # 1) 기획 포커
  • # 2) 티셔츠 사이즈
  • # 3) 도트 투표
  • # 4) 버킷 시스템
  • # 5) 큰 / 불확실한 / 작은
  • # 6) 선호도 매핑
  • # 7) 주문 방법
• Agile에서 예산 계산
• 애자일 개발 프로젝트의 추정 템플릿
  • 1) 애자일 프로젝트 계획 템플릿 :
  • 2) 애자일 릴리스 계획 템플릿 :
  • 3) 민첩한 제품 백 로그 템플릿 :
  • 4) 애자일 스프린트 백 로그 템플릿 :
  • 5) 애자일 테스트 계획 템플릿 :
  • 6) 애자일 사용자 스토리 템플릿 :
  • 7) 애자일 로드맵 템플릿 :
• 애자일 프로젝트의 추정 단계
  • # 1) 제안 또는 프로젝트 수준 추정
  • # 2) 릴리스 수준 추정
  • # 3) 스프린트 레벨 추정
• 결론
• 추천 도서

소개

다음은 Agile Estimation의 3 가지 주요 수준입니다.

# 1) 프로젝트 또는 제안 수준 프로젝트 개발의 초기 단계에서 빠른 기능 포인트 분석을 사용하는 것입니다.

# 2) 릴리스 레벨 우선 순위에 따라 사용자 스토리의 순서를 정의하는 데 도움이 될 수있는 스토리 포인트를 사용자 스토리에 할당하는 것이 포함되며 현재 릴리스에서 가져올 수있는 스토리와 나중에 가져올 수있는 스토리를 결정하는 데 도움이 될 수 있습니다.

# 3) 스프린트 레벨 사용자 스토리를 작업으로 나누고 복잡성에 따라 작업에 예상 시간을 할당하는 것입니다. 여기에서는 작업 상태와 함께 작업을 담당하는 사람도 정의합니다.

이 정보는 나중에 Agile 프로젝트의 예산을 계산하는 데 사용할 수 있습니다. 예산 계산은 사전 및 사후 반복 작업 또는 기타 이유로 인해 프로젝트가 예산을 초과하지 않도록하는 데 중요합니다.

애자일의 스토리 포인트 추정

스토리 포인트 추정은 상대적인 크기를 사용하여 제품 백 로그 항목을 대략적으로 추정하기위한 비교 분석입니다. 사용자 스토리를 추정하는 팀원은 제품 소유자, 스크럼 마스터, 개발자, 테스터 및 스테이크 보유자입니다.

다음은 상대적 크기 조정의 최종 결정에 도달하는 몇 가지 단계입니다.

#1) 모든 사용자 스토리를 분석하고 기본 또는 참조 스토리를 식별합니다. 상대적 크기 조정에 중요합니다. 이 스토리는 현재 제품 백 로그 또는 이전에 수행 한 백 로그에서 선택할 수 있습니다. 이 이야기는 모든 구성원의 동의를 얻어 참고 이야기로 선정되어야한다.

#두) 현재 제품 백 로그에서 다른 스토리를 선택하면 팀 구성원은 스토리의 요구 사항을 이해하면서 제품 소유자와 질문이나 의문 사항을 자유롭게 논의 할 수 있습니다. 제품 소유자는 모든 질문과 의심을 명확히 할 책임이 있습니다.

#삼) 사용자 스토리를 구현하는 동안주의해야 할 사항의 목록을 작성하십시오. 이는 도구의 메모 섹션에 메모를 작성하거나 스토리 카드에 글 머리 기호를 추가하여 수행 할 수 있습니다. 이것은 대부분 스크럼 마스터가 수행합니다.

# 4) 다음은 참가자들 사이에서 몇 가지 일반적인 질문입니다.

• 디자인: 작업을 시작하기 전에 우리가 알아야 할 사전 및 필수 지식은 무엇입니까?
• 코딩 : 이 사용자 스토리를 구현하는 데 필요한 코딩 양입니다. 이전에 유사한 사용자 스토리를 본 적이 있습니까?
• 단위 테스트 : 이 사용자 스토리에 대한 단위 테스트를 수행하는 데 필요한 모의 객체가 있습니까?
• 통합 테스트 : 이 이야기가 같은 모듈과 다른 모듈의 다른 기능에도 영향을 줍니까?
• 수락 테스트 : 고객이 원하는 제품을 납품하기 위해주의해야 할 점은 무엇입니까?
• 전문적 지식: 참가자 중 이전에 비슷한 이야기를 한 적이 있고 그에 대한 전문가가 있습니까?

# 5) 선택한 스토리에 대해 상대적 크기 조정을 수행합니다. 동일한 양의 작업과 노력이 필요한 경우 동일한 번호를 지정하십시오. 참조 스토리에 할당 된 점수. 더 많은 노력이 필요하면 더 높은 가치를 할당하십시오. 노력이 덜 필요하면 더 낮은 값을 할당하십시오.

# 6) 완료 정의에 따라 선택한 사용자 스토리의 상대적 크기를 확정하기 위해 모든 참가자와 합의에 도달합니다.

문자를 int C ++로 변환

# 7) 모든 제품 백 로그 항목의 상대적 크기 조정이 완료된 후 모든 사용자 스토리가 동일한 번호인지 확인하십시오. 할당 된 점수의 일관성을 유지하려면 동일한 노력과 크기가 필요합니다.

권장 도구

# 1) 애자일 포커

애자일 포커 원격 및 공동 위치 팀 모두를위한 빠르고 편리한 계획 및 예측을위한 잘 알려진 Jira 용 앱입니다.

Agile Poker는 Planning Poker®, Wideband Delphi 및 Magic Estimation (Silent Grouping, Affinity Estimation, Swimlanes Sizing 또는 Relative Estimation이라고도 함)의 세 가지 산업 표준 추정 방법에서 영감을 받아 간단하고 쉽게 시작할 수 있습니다.

다양한 애자일 추정 기법

애자일 프로젝트에서 추정을 수행하는 많은 기술이 있습니다. 추정을 수행하는 주요 원칙에는 상대 추정, 추정을 수행해야하는 항목에 대한 더 많은 정보를 얻기위한 토론 및 할당 된 작업에 대한 전체 팀의 헌신을 보장하는 것이 포함됩니다.

주로 7 가지 애자일 프로젝트 추정 기법이 있습니다.

# 1) 기획 포커

• 이 추정 기법에서는 추정을해야하는 모든 사람들이 Planning Poker 세션을 위해 동그란 원 안에 앉아 있습니다.
• 각 견적자는 0,1,2,3,5,8,13,20,40 및 100과 같은 값의 계획 포커 카드 세트를 가지고 있습니다. 이러한 값은 팀이 추정하는 스토리 포인트 또는 측정 값을 나타냅니다.
• 세션이 시작될 때 제품 소유자 또는 고객은 모든 기능과 요구 사항을 설명하는 사용자 스토리를 읽습니다.
• 이야기를 읽은 후 평가자 및 제품 소유자 / 고객과의 토론이 진행됩니다. 견적자는 제품 소유자에게 질문을하거나 의심을 명확히 할 수 있습니다.
• 토론 후 모든 견적자는 사용자 스토리를 추정하기 위해 하나의 카드를 선택해야합니다. 모든 추정자가 동일한 값을 제공하면 최종 추정치가됩니다.
• 값이 다르면 가장 높은 값과 가장 낮은 값을 제공하는 추정자가 의견을 설명하고 합의가 이루어질 때까지이 값을 선택한 이유를 설명합니다.
• 작을 때 좋은 기술입니다. 항목의 수는 소규모 팀으로 추정됩니다.

=> 자세한 내용은 포커 추정 기법 계획 .

# 2) 티셔츠 사이즈

• 티셔츠의 경우와 마찬가지로 XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large) 크기가 표시됩니다. 유사한 접근 방식이 여기에서 따릅니다. 항목은 티셔츠 크기로 추정됩니다.
• 이것은 항목의 큰 백 로그를 대략적으로 추정하는 완벽한 기술입니다.
• 빠르고 대략적인 추정이 필요할 때 유용합니다. 나중에 이러한 크기는 요구 사항에 따라 아니오로 변환 될 수 있습니다.
• 상대적인 규모 (대부분 중간 규모)는 팀 구성원 또는 평가자들이 상호 논의하고 동의 한 후 결정됩니다. 그런 다음 중간 크기에 할당 된 상대적 크기에 따라 항목에 아니요가 할당됩니다.
• 불리: 누군가에게 L로 보이는 것은 누군가에게는 XL로 보일 수 있습니다.
• 모든 견적자는 항목에 자신의 크기를 할당합니다. 논의하고 불일치를 해결 한 후 최종 추정치를 얻기위한 합의에 도달합니다.

# 3) 도트 투표

• 이는 기본적으로 제품 백 로그의 우선 순위가 가장 높은 스토리에서 가장 낮은 순위의 스토리로 순서를 결정하는 순위 방식입니다. 이것은 앞으로 나아가 야 할 가장 중요한 이야기를 선택하기 위해 수행됩니다.
• 이를 시작하려면 노란색 스티커를 사용하거나 투표를받는 것과 구별되는 방식으로 벽이나 보드에 설명과 함께 모든 사용자 스토리를 게시합니다.
• 모든 이해 관계자에게 4 ~ 5 개의 점이 부여됩니다 (대부분 스티커, 펜 또는 마커 형태로 점을 만드는 데 사용할 수 있음).
• 모든 이해 관계자는 자신이 선호하는 사용자 스토리에 대한 투표를 요청합니다.
• 제품 소유자는 제품 백 로그 항목을 가장 선호하는 항목 (가장 많은 점이없는 항목)에서 가장 낮은 항목 (가장 적은 개수의 점이있는 항목)으로 주문합니다.
• 결정된 순서에 불만족하는 이해 관계자가 거의없는 경우 일 수 있습니다. 이 경우 사용자 스토리는 토론 후 높은 우선 순위, 낮은 우선 순위, 중간 우선 순위의 3 개 그룹으로 나뉩니다. 우선 순위가 높은 사용자 스토리가 벽에 게시되어 투표를받습니다. 이는 모든 이해 관계자의 동의하에 최종 주문이 이루어질 때까지 수행됩니다.

# 4) 버킷 시스템

• 큰 아니오 때 좋은 기술입니다. 항목의 큰 번호로 추정됩니다. 참가자. Planning Poker보다 빠르고 합리적입니다.
• 값이 0,1,2,3,4,5,8,13,20,30,50,100, 200 인 다른 버킷이 생성되며 필요한 경우 확장 할 수 있습니다. 이 버킷은 테이블에 순차적으로 배열 된 값을 나타내는 카드 일뿐입니다.
• 스토리는 추정자가 적절하다고 판단하는 곳에 배치해야합니다. 예상되는 모든 항목은 카드에 적혀 있습니다.
• 무작위로 항목을 선택하여 버킷 8에 넣습니다. 이것은 참조 용으로 만 사용됩니다. 무작위로 다른 스토리를 선택하고 모든 기능과 요구 사항을 그룹과 논의하고 합의에 따라 적절한 버킷에 배치합니다. 마찬가지로 세 번째 항목을 선택하여 적절한 버킷에 배치합니다.
• 그룹이 선택한 첫 번째 항목이 버킷 8 대신 버킷 1에 속해야한다고 생각하는 경우 버킷 순서를 변경할 수도 있습니다.
• Divide and Conquer 접근 방식을 따릅니다. 나머지 항목은 모두 참가자에게 나누어집니다. 모든 참가자는 다른 참가자의 승인없이 항목을 배치 할 수 있습니다.
• 항목은 올바르게 배치되어야합니다. 버킷 사이에 항목을 놓을 수 없습니다.
• 참가자가 제품 백 로그 항목을 이해하지 못하거나 다른 참가자가 사용자 스토리 배치를 완료 한 경우 사용자 스토리를 다른 참가자에게 전송할 수 있습니다.
• 마지막으로 모든 참가자가 온 전성 검사를 수행합니다. 참가자가 항목에 할당 된 잘못된 버킷을 발견하면이를 다른 참가자에게 알리고 논의 할 수 있습니다. 이는 전체 제품 백 로그에 대한 합의가 이루어질 때까지 수행됩니다.
• 진행자는 온 전성 검사가 완료되지 않는 한 항목을 이동하지 않는지 확인해야합니다.
• 이는 또한 제품 백 로그 항목의 우선 순위를 달성하기 위해 수행됩니다.

# 5) 큰 / 불확실한 / 작은

• 이것은 대략적인 버전이며 Large, Small 및 Uncertain의 세 가지 크기 만있는 버킷 시스템의 단순화입니다.
• 참가자 또는 평가자는 항목을 범주 중 하나에 배치하도록 요청받습니다. 먼저 간단한 사용자 스토리를 선택하여 크고 작은 범주에 배치합니다. 그런 다음 복잡한 항목이 사용됩니다.
• 제품 백 로그에 비교 가능한 항목이있을 때 좋은 기술입니다.

# 6) 선호도 매핑

• 팀이 작고 아예 없을 때 좋은 기술입니다. 백 로그 항목 수가 적습니다.
• 첫 번째 단계는 Silent Relative Sizing입니다. 벽면에는 'Smaller'라고 적힌 카드가 가장 왼쪽에, 'Larger'가 적힌 카드가 가장 오른쪽에 놓입니다. 제품 소유자는 모든 참가자에게 항목의 하위 집합을 제공합니다. 모든 참가자는 카드를 구현하는 데 필요한 노력을 고려하여 벽에있는 카드의 크기와 비교하여 각 항목의 크기를 지정해야합니다. 다른 팀원과의 논의없이 참가자가 단독으로 결정합니다. 참가자의 의심을 명확히하기 위해 제품 소유자 또는 이해 관계자가 참석합니다. 너무 애매해서 팀원이 추정을 위해 이해할 수없는 제품 백 로그 항목은 별도로 배치됩니다. 5-20 분 걸립니다.
• 벽 편집 : 팀원은 벽에있는 항목의 위치를 ​​변경할 수 있습니다. 그들은 다른 팀원들과 설계 및 구현 요구 사항을 논의 할 수 있습니다. 이 활동은 벽에 거의 변화가 없을 때 종료 될 수 있습니다. 약 20-60 분 소요 .
• 올바른 위치에 항목 배치 : 토론 후 팀은 제품 백 로그 항목을 상대적이고 적절한 위치에 배치합니다. 여기에서는 티셔츠 크기, 피보나치 시리즈 등을 사용하여 항목의 크기를 상대적으로 추정 할 수 있습니다.
• 제품 소유자 당면 과제 : 제품 소유자는 팀에서 수행 한 추정치에서 약간의 불일치를 발견 할 수 있으며 팀과 더 많은 기능 또는 항목에 대한 요구 사항을 논의해야합니다. 토론 후 최종 추정이 이루어집니다.
• 프로젝트 백 로그 관리 도구로 내보내기 : 최종 추정에 대한 정보가 손실되지 않았는지 확인하려면 제품 백 로그 관리 도구로 내보내십시오.

# 7) 주문 방법

• 큰 경우 좋은 기술입니다. 항목 및 작은 번호. 의 사람들이 있습니다.
• 제품 백 로그 항목에 대한 정확한 상대적 크기를 제공합니다.
• 낮은 것에서 높은 것까지의 스케일이 준비됩니다. 모든 항목이 무작위로 배치됩니다. 각 참가자는 저울에서 한 번에 한 항목을 이동하도록 요청받습니다. 이동은 위, 아래 또는 차례를 다른 구성원에게 전달할 수 있습니다.
• 이는 모든 참가자가 만족할 때까지 계속되고 스케일에서 항목을 이동하고 싶지 않습니다.
• 또한 제품 백 로그 항목의 우선 순위를 제공합니다.

Agile에서 예산 계산

예산 계산은 Agile 프로젝트에서 중요한 역할을합니다. 이는 제공된 실제 예산이 얼마인지, 더 많은 예산이 필요한지, 다른 제품 백 로그 항목에 대한 예산을 어떻게 나눌 것인지 확인하기 위해 수행됩니다.

이전 프로젝트에서 수집 한 데이터를 사용하고 수학 공식을 사용하여 현재 프로젝트의 예상 예산을 얻습니다.

다음은 Agile 프로젝트에서 예산을 계산하는 일련의 단계입니다.

#1) 프로젝트의 모든 요구 사항을 나열하고 견적 플래닝 포커, 버킷 시스템, 피보나치 시리즈 등을 사용합니다. 모든 팀원은 사용자 스토리를 명확하게 분석하고 이해 한 후 나열된 요구 사항에 대한 추정치에 동의해야합니다. 사용자 스토리에 구현할 기능을 기반으로 추정이 이루어집니다.

#두) 스프린트라는 반복 기간과 여기에 할당 된 제품 백 로그 항목을 결정합니다. 보통 2 ~ 3 주 정도 소요됩니다. 사용자 스토리는 최우선 순위의 사용자 스토리에서 시작하여 더 낮은 우선 순위로 이동하고 마지막에 최하위 사용자 스토리의 순서로 선택됩니다. 이는 첫 번째 Sprint에서 어떤 사용자 스토리를 선택해야하고 나중에 어떤 스토리를 가져올 수 있는지 결정하는 데 도움이됩니다.

#삼) 완료해야 할 작업의 양과 구현에 남은 시간을 명확하게 보여주기 위해 번 다운 차트를 준비합니다. 기본적으로 애자일 팀의 진행률을 제공합니다. 팀의 행동 방식과 예상되는 행동 방식에 대한 명확한 그림을 제공합니다.

팀 진행 상황은 다음과 같이 완료된 작업, 남은 노력, 이상적인 번 다운 및 남은 작업으로 측정됩니다.

# 4) 장비 구매, 도구, 인프라 지원, 사용할 소프트웨어 도구에 대한 라이선스 받기, 프로젝트 관리 도구, 바이러스 백신 설치 및 업데이트와 같은 추가 비용을 추가합니다.

# 5) 사전 및 사후 반복 예산을 추가합니다. 모든 애자일 멤버는 교차 기능을 수행해야하지만 한계가 있습니다. 전문 지식을 벗어난 팀 구성원이 수행 한 모든 작업은 사전 반복 작업 또는 사후 반복 작업으로 간주됩니다. 이 사전 및 사후 반복 작업에는 구현을위한 추가 예산이 필요합니다.

# 6) 숨겨진 위험을 주시하십시오. Agile 프로젝트의 위험은 다음과 같습니다 : 프로젝트의 예산 초과 위험, 팀 구성원 부재, 구성원이 명확하거나 완전한 지식을 갖고 있지 않음, 구성원이 필요한 기술을 가지고 있지 않음, 기한 초과 등.

애자일 개발 프로젝트의 추정 템플릿

Agile 개발 프로젝트의 다양한 수준에서 준비된 많은 추정 템플릿이 있습니다. 유일한 목적은 요구 사항 또는 항목을 구현하고 진행 상황을 추적하는 데 필요한 추정치를 명확하게 설명하는 것입니다.

주요 템플릿은 다음과 같습니다.

1) 애자일 프로젝트 계획 템플릿 :

요구 사항의 기능을 제공하는 데 필요한 시간과 그 상태에 대한 높은 수준의보기를 제공합니다. 또한 특정 작업을 담당하는 사람을 언급합니다.

(참고 : 확대 된 이미지를 클릭하십시오)

2) 애자일 릴리스 계획 템플릿 :

요구 사항에 해당하는 작업의 릴리스 세부 정보와 함께 실행해야하는 상태 및 Sprint를 제공합니다.

3) 민첩한 제품 백 로그 템플릿 :

프로젝트에 대해 정의 된 전체 제품 백 로그를 설명합니다. 상태, 우선 순위, 스토리 포인트 및 Sprint에 할당되었는지 여부 또는 결함과 같은 추가 작업이 있는지 여부와 함께 Sprint의 작업에 대한 세부 정보를 제공합니다.

4) 애자일 스프린트 백 로그 템플릿 :

특정 Sprint의 백 로그에 언급 된 사용자 스토리에 대한 설명을 제공합니다. 사용자 스토리에 할당 된 총 스토리 포인트와 이들이 서로 다른 작업으로 분할되는 방식을 제공합니다. 또한 해당 작업의 상태와 해당 작업에 대해 매일 수행되는 작업이 무엇인지 제공합니다.

5) 애자일 테스트 계획 템플릿 :

전체 테스트 시나리오를 하위 시나리오로 나눕니다. 구현 날짜, 예상 결과, 실제 결과, 상태 등과 같은 하위 시나리오에 대한 세부 정보를 제공합니다.

또한 프로젝트 이름, 호환 가능한 브라우저, 테스트중인 애플리케이션 버전, 선택한 시나리오의 테스트 케이스 ID, 작성자, 테스트 한 사람, 설명 등을 언급합니다.

6) 애자일 사용자 스토리 템플릿 :

테스트 할 특정 기능에 필요한 역할은 무엇이며 사전 요구 사항 (환경 설정 및 링크 활성화 됨)은 무엇이며 예상되는 결과는 무엇입니까?와 같은 사용자 스토리 분석과 관련된 세부 정보를 제공합니다.

7) 애자일 로드맵 템플릿 :

회사의 프로젝트에 단기 및 장기적으로 방향을 제시합니다. 회사 내에서 기대치를 설정하는 데 도움이됩니다. 그리고 프로젝트가 어디로 향하고 있는지에 대한 개요.

애자일 프로젝트의 추정 단계

애자일 프로젝트에서 추정은 아래와 같이 3 단계로 이루어집니다.

• 프로젝트 / 제안 수준 : 전체 애플리케이션의 전체 기능 크기는 높은 수준의 요구 사항 만 사용할 수있는 경우 QFPA (Quick Function Point Analysis) 방법을 사용하여 추정됩니다.
• 릴리스 레벨 : 스토리 포인트는 아니오를 결정하는 데 도움이되는 사용자 스토리에 할당됩니다. 프로젝트 내에서 계획된 릴리스의 릴리스 및 스프린트에서 수집 할 사용자 스토리의
• 스프린트 레벨 : 예상 시간은 스프린트 내에서 사용자 스토리의 작업에 할당됩니다. 이는 스프린트에서 사용자 스토리를 전달하기위한 개발의 약속을 보장하기 위해 수행됩니다.

S1, S2, S3, S4, S5, S6은 스프린트입니다.

# 1) 제안 또는 프로젝트 수준 추정

프로젝트에 대한 매우 높은 수준의 추정치입니다. 제품 백 로그 항목의 총 요구 사항 수에 중점을 둡니다. 기능 포인트는 기능 요구 사항에 대한 자세한 설명이 문서화되기 전에 소프트웨어 / 프로젝트의 크기를 추정하는 데 사용됩니다.

기능 포인트는 소프트웨어의 크기를 계산하는 보편적 인 방법입니다. 소프트웨어 프로젝트에서 발견되는 기능에 중점을 둡니다. 기능 포인트는 요구 사항 또는 사용자 스토리를 숫자로 변환하는 메트릭입니다.

프로젝트 초기 단계에서는 QFPA (Quick Function Point Analysis) 방법을 채택하는 것이 좋습니다.

빠른 기능 포인트 분석 방법은 높은 수준의 요구 사항 만 사용할 수있는 경우 FP를 추정하기위한 고유 한 접근 방식입니다.

총 기능 크기를 계산하는 방법은 무엇입니까?

• 도메인 전문가의 도움을 받아 애플리케이션의 모든 기능을 이해합니다.
• 애플리케이션의 가능한 모든 기능을 식별하고 나열합니다.
• 데이터 저장 기능은 내부 로직 파일 (애플리케이션 내부에 저장된 데이터)과 외부 인터페이스 파일 (참조 용으로 만 사용되는 데이터)으로 분류됩니다.
• 트랜잭션 기능은 외부 입력 (외부 소스에서 애플리케이션으로 들어오는 데이터), 외부 출력 (파생 된 데이터가 애플리케이션에서 외부로 이동) 및 외부 문의 (하나 이상의 외부 입력 및 외부 출력에서 ​​검색된 데이터)로 분류됩니다.
• 평균 복잡성을 계산하여 각 함수의 FP 크기를 계산합니다.
• 모든 기능의 FP 크기를 합산하여 애플리케이션의 전체 기능 크기를 얻습니다.
• FP 분석에 전문 지식을 가진 두 명 이상이 독립적으로 계산하고 결과를 일치시키고 차이점을 해결해야합니다.

프로젝트 수준 추정의 예 :

다음은 제품 백 로그에서와 같이 프로젝트에 대한 요구 사항 목록입니다.

• 사용자는 사용자 이름과 비밀번호를 제공하여 웹 사이트에 로그인 할 수 있어야합니다.
• 로그인 성공 후 사용자는 오른쪽 및 왼쪽 창이 정의 된 기본 페이지로 이동해야합니다.
• 사용자는 애플리케이션에서 로그 아웃 할 수있는 옵션이 있어야합니다.
• 유효한 사용자는 현재 자격 증명을 제공하여 암호를 변경할 수 있습니다.

팀은 프로젝트 크기를 추정하기 위해 빠른 FP 추정을 사용합니다.

다음은 수행 된 분석입니다.

• 여기서 데이터 저장 기능은 로그인 및 비밀번호 변경을위한 사용자 자격 증명을 저장하는 것입니다.
• 자격 증명은 응용 프로그램 경계 내에 저장되므로 ILF (내부 논리 파일)에 저장됩니다.
• 트랜잭션 기능은 다음과 같습니다.
  • 사용자 로그인 및 메인 페이지 표시.
  • 사용자 로그 아웃 및 로그 아웃 화면 표시.
  • 비밀번호 변경 기능.

다음은 Quick Function Point Analysis를 사용하여 프로젝트 크기를 추정하기 위해 실행되는 단계입니다.

1 단계 : 모든 데이터 함수 나열

UFP (Unadjusted Function Point)는 Caper Jones Table에서 가져옵니다.

2 단계 : 모든 트랜잭션 기능 나열

UFP (Unadjusted Function Point)는 Caper Jones Table에서 가져옵니다.

3 단계 : Function Points에서 예상 프로젝트 크기 도출

UFP = 데이터 FP + 트랜잭션 FP

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22FP (VFP 가정 (값 조정 계수 = 1)

생산성 = 16FP / 월 (일반 표준)

노력 = FP / 생산성 = 월 22/16 명 = 월 1.37 명

이중 연결 목록 C ++ 예제

# 2) 릴리스 수준 추정

릴리스 수준 추정은 릴리스 계획 중에 수행됩니다. 프로젝트 수준 추정 후 다음 활동입니다. 우선 순위가 지정된 요구 사항은 사용자 스토리 형식의 제품 백 로그에서 가져옵니다.

사용자 스토리는 해당 릴리스에 대해 제공 될 소프트웨어의 크기를 추정하는 데 초점을 맞춘 릴리스 계획 중 스토리 포인트 측면에서 추정됩니다. 이러한 방식으로 각 릴리스의 릴리스 및 총 스토리 포인트가 계획되지 않습니다.

스토리 포인트는 기본적으로 다른 기능과 비교할 때 기능을 구현하는 데 필요한 상대적인 노력을 나타냅니다. 기본적으로 제품 백 로그 항목의 크기를 조정하기위한 것입니다.

스토리 포인트 추정은 다음을 기반으로 수행됩니다.

• 구현할 기능의 복잡성.
• 모든 구성원의 경험과 기술력.

S1, S2, S3, S4, S5는 스프린트입니다.

사용자 스토리에 스토리 포인트를 할당하는 단계 :

• 모든 팀원은 스프린트 백 로그에있는 사용자 스토리를 살펴 보는 테이블 주위에 모입니다.
• 하나의 스토리 포인트의 의미와 해당 노력이 결정됩니다.
• 팀원 중 한 명이 사용자 스토리를 읽은 다음 팀원에게 상대적인 스토리 포인트를 할당하도록 요청합니다.
• 팀원이 할당 한 스토리 포인트 사이에 유의미한 차이가 있으면 할당 한 스토리 포인트에 대한 설명을 제공하여 결국 합의에 도달합니다.
• 이 과정은 팀원들이 제시 한 추정치간에 큰 차이가 없을 때까지 3-4 회 반복됩니다.
• 스토리의 크기를 조정하면 스프린트 및 릴리스 내에서 촬영할 스토리 수를 결정하는 데 도움이됩니다.

릴리스 수준 추정의 예 :

여기에는 제품 백 로그라는 사용자 스토리의 우선 순위 목록을 만드는 것이 포함됩니다. 제품 소유자는 제품 백 로그를 생성하고 여기에 나열된 각 항목에 대한 비즈니스 가치를 제공합니다.

스토리 포인트 추정에 아래 방법을 사용할 수 있습니다.

• 숫자 크기 : 1에서 10
• 티셔츠 사이즈 : 각 요구 사항은 초소형 (XS), 소형 (S), 중형 (M), 대형 (L), 특 대형 (XL)으로 분류됩니다.
• 피보나치 시리즈 : 피보나치 수열 (1,2,3,5,8,13,21,34,…)을 통한 추정

피보나치 시퀀스를 통한 위의 사용자 스토리 추정 :

# 3) 스프린트 레벨 추정

스프린트 레벨 추정은 스프린트 계획 중에 수행됩니다. 우선 순위가 가장 높은 제품 백 로그 항목은 세부화, 설계, 분석, 개발, 테스트 케이스 생성, 테스트 케이스 실행, 사용자 승인 테스트 등과 같은 여러 작업으로 나누어집니다.

작업은 예상 시간, 즉 해당 사용자 스토리에 대해 해당 작업을 완료하는 데 필요한 시간으로 추정됩니다. 상향식 접근 방식은 비즈니스 요구 사항이 낮은 수준의 활동으로 분류되고 각 활동에 예상 시간이 할당되는 작업 추정에 사용됩니다.

추정의 목적은 개발 팀이 Sprint에 투입 할 수있는 사용자 스토리 수를 아는 것입니다. 개발은 약속에 익숙해야하며 제품 소유자는 팀이 약속을 이행 할 것이라고 확신해야합니다.

에스 작업에 예상 시간을 할당하기위한 팁 :

• 팀 구성원은 사용자 스토리를 선택하고 사용자 스토리에 해당하는 작업에 대한 실제 노력을 시간 또는 일 단위로 추정하도록 요청받습니다.
• 팀원들 사이에 이러한 추정치에 불일치가 있으면이를 논의하고 합의에 도달합니다.
• 작업이 6 시간 이상이면 더 작은 작업으로 분할됩니다.
• 예상 시간이 2 시간 미만인 작업이 둘 이상있는 경우 결합되어 새 작업을 구성합니다.

스프린트 레벨 추정의 예 :

Sprint Planning 회의에는 두 부분이 있습니다.

• 첫 번째 부분: 제품 백 로그에서 선택한 사용자 스토리의 요구 사항을 명확히하는 데 중점을 둡니다.
• 두 번째 부분 : 요구 사항을 작업으로 나누고이를 완료하는 데 필요한 시간을 예측하는 데 중점을 둡니다. 제품 백 로그 항목을 제공하는 데 필요한 모든 작업이 포함되어야합니다. 작업은 작아야합니다. 이상적으로는 작업 시간이 6 시간을 넘지 않아야합니다.

결론

Agile 프로젝트의 추정치는 올바른 방향, 계획 및 관리를 보장하는 데 중요한 역할을하며 향후 프로젝트를 수행하는 방법에 대한 단계를 제공합니다.

플래닝 포커, 버킷 시스템 등과 같은 스토리 포인트를 추정하는 기술은 값이나 숫자가 인쇄 된 카드 나 점을 사용하여이 번호를 할당합니다. 상대적인 크기 추정을 위해 사용자 스토리에.

유일한 목적은 최대 우선 순위에서 최소 우선 순위까지 ​​우선 순위가 지정된 순서로 항목을 설정하는 것입니다. 제품 백 로그 항목에 대해 추정 된 상대적 크기는 프로젝트에 필요한 예산을 추정하거나 계산하는 데 도움이됩니다.

애자일 프로젝트 추정에 대한 훌륭한 통찰력을 얻었기를 바랍니다. 아래 댓글 섹션에서이 튜토리얼에 대한 생각을 자유롭게 표현하십시오.

추천 도서

• 플래닝 포커로 애자일 추정 프로세스를 쉽게 만드는 방법
• Agile Vs Waterfall : 프로젝트에 가장 적합한 방법은 무엇입니까?
• 소프트웨어 테스트 추정 기법 (테스트 노력 추정 완료 가이드)
• VersionOne 자습서 : 올인원 민첩한 프로젝트 관리 도구 가이드
• Jira 포트폴리오 자습서 : JIRA 용 애자일 프로젝트 포트폴리오 관리 플러그인 (검토)
• 2021 년 최고의 애자일 프로젝트 관리 도구 TOP 10
• 성공적인 애자일 여정을위한 기초 : 올바른 방법, 도구 및 기법을 선택하는 방법
• 애자일 프로세스로의 성공적인 전환을위한 애자일 테스트 마인드를 개발하기위한 4 단계