발견 추정을 위해 애자일 스프레드시트 사용하기

이 문서에는 Agile 검색 추정치를 개발하는 데 도움이 되는 미리 형식이 지정된 스프레드시트가 포함되어 있습니다. 여기에는 주요 예제를 따라가는 데 도움이 되는 정보도 포함되어 있습니다. 여기에서 템플릿에서 편집 가능한 복사본을 만들 수 있습니다(파일>사본 만들기 또는 파일>다운로드).

고객은 내가 팀을 구성하거나 MVP 요구 사항을 알기 전에 Agile 견적을 제공하도록 요청하는 경우가 많습니다. 이 초기 단계에서 저는 속도, 스프린트 수 또는 이러한 추정치를 계산하기 위한 팀 비용과 같은 기존 측정항목에 액세스할 수 없습니다. 그러나 고객은 답을 원합니다. 2~6개월 안에 가상의 제품을 출시할 수 있습니까? (일반적으로 낮은) 예산으로 실현 가능합니까?

애자일 스프레드시트를 입력합니다.

스프레드시트는 애자일 사고방식에 적합하지만 종종 간과되는 선택입니다. 이들은 협업을 장려하는 첨단 기술의 첨단 도구입니다. 즉, 제품의 비용과 품질이 요구 사항을 충족하는 한 고객은 도구가 "Agile 승인"되었는지 여부에 신경 쓰지 않을 것입니다. 스프레드시트의 진정한 가치는 모든 경험 수준의 프로젝트 관리자와 이해 관계자에게 액세스할 수 있다는 점입니다.

많은 전문 프로젝트 관리 도구는 빠르게 움직이는 프로젝트에 대한 경험이 없는 사용자에게 너무 가파른 학습 곡선을 가지고 있습니다. 따라서 고객, 제품 소유자 및 개발자가 요구 사항 및 인건비를 업데이트하는 것이 더 쉬울수록 현실적인 견적에 더 빨리 도달할 수 있습니다. 미리 형식이 지정된 스프레드시트를 사용하여 프로젝트 관리자는 값과 매개변수를 조정하여 변동하는 리소스 또는 타임라인의 변화에 ​​따른 효과를 입증할 수 있습니다.

스프레드시트는 동료와 지식을 공유할 수 있는 좋은 방법이기도 합니다. 내가 사용하는 스프레드시트는 Toptal 동료와 함께 작성했으며 그 이후로 사본을 만들어 필요에 맞게 수정했습니다. 여러분도 그렇게 하시길 권합니다.

이 기사에서는 클라이언트와 이해 관계자가 프로젝트 목표에 맞춰 개발을 진행할 수 있도록 하는 성공적인 발견 추정치를 제공하는 방법을 보여줍니다. 다음은 공백을 채우고 뒤에 서 있을 수 있는 초기 단계 견적을 제공하는 방법입니다.

제품 비전과 로드맵을 먼저 다루십시오

고객이 고정된 예산으로 데이트 웹사이트를 개발하기를 원하지만 제품의 세부 사항이 모호하다고 가정해 보겠습니다. 팀 비용과 속도를 알지 못하는 상태에서 제품 비전은 이해 관계자가 디자인 목표에 동의하고 팀 전체의 투명성을 촉진해야 하기 때문에 시작하기에 가장 좋은 곳입니다.

저는 직관적인 내러티브 스타일의 Scrum.org 제품 비전 형식을 좋아합니다. 다음과 같이 보입니다.

제품 비전이 설정되면 새 스프레드시트 탭에 제품 로드맵을 추가하여 고객에게 장기 프로젝트 일정을 알릴 수 있습니다. 로드맵에는 각 제품 로드맵 버전의 목표, 주요 기능 및 기한이 나열되어야 합니다.

로드맵 버전은 시장 궤적을 안내하는 제품의 계획된 소비자 또는 클라이언트 대면 버전입니다. 첫 번째 로드맵 버전은 시장에 데뷔할 수 있는 제품입니다. 후속 로드맵 버전은 제품 비전과 일치하는 강력한 새 기능으로 시장 출시를 나타냅니다.

Microsoft를 예로 들면: Windows 8은 로드맵 버전일 가능성이 높습니다. Windows 10은 새롭고 바람직한 기능이 많이 포함된 또 다른 로드맵 버전이었습니다.

제품 비전과 로드맵이 완성되면 클라이언트에게 MVP를 약속할 시간입니다.

Triple Constraint Chart로 MVP 기능 협상

삼중 제약 차트를 사용하여 시간과 비용에 대한 고객의 기대치를 형성해야 하는 순간입니다.

Waterfall 접근 방식에서 고정된 기능은 시간과 비용을 지시하고 상세한 프로젝트 계획에 따라 개발이 진행됩니다. 반대로 Agile의 고정 비용과 일정은 제품의 기능을 결정하고 이러한 기능은 보다 유연한 프로젝트 비전을 기반으로 지속적으로 우선 순위가 조정됩니다.

Triple Constraint 차트는 첫 번째 릴리스에 원하는 모든 기능을 포함하면 개발 시간과 풍선 비용이 증가한다는 것을 클라이언트가 보여줍니다. 대신 클라이언트와 협력하여 MVP에 대해 "필수" 기능만 선택하고 향후 릴리스에 대한 나머지 기능을 표로 작성하십시오.

스프레드시트를 사용하면 클라이언트의 변화하는 요구 사항에 따라 기능을 그룹화하고 다른 버전, 릴리스 및 우선 순위에 재할당할 수 있으며 이러한 변경 비용을 즉시 표시할 수 있습니다.

MVP 기능을 식별하는 동안 SME(주제 전문가)에게 작업한 유사한 프로젝트를 기반으로 프로젝트 단계를 나열하는 데 도움을 요청하십시오. 이 단계를 사용하여 나중에 에픽을 만들 수 있습니다. 이러한 입력이 준비되면 견적 작성을 시작할 수 있습니다.

티셔츠 사이즈로 시작하기

첫 번째 백로그를 시작하려면 제품 소유자에게 제품 기능에 대한 자세한 설명을 요청한 다음 난이도에 따라 각 기능에 티셔츠 크기를 할당합니다.

티셔츠 크기는 절대값을 갖기 전에 각 개발 작업의 상대적 복잡성과 기간을 보여줍니다. 프로젝트 계획을 진행하면서 이러한 상대적 크기를 스토리 포인트 및 작업 시간으로 변환합니다.

예를 들어, 고객이 데이트 사이트에서 일련의 팝업을 개발하기를 원하면 시간이 많이 걸리지만 간단합니다. 그 작업 복잡성을 "작음"으로 특성화할 수 있지만 노력은 "중간"이 될 것입니다. 이것을 "SM"으로 축약할 수 있습니다. 반면에 새 API에 대한 백엔드 연결을 개발하는 것은 필요한 모든 문서와 테스트로 인해 더 복잡한 작업이 될 것입니다. 이를 위해 필요한 기술과 관심은 노력과 기술 수준 모두에서 "Large"로 만들 수 있습니다. "LL".

티셔츠 크기 조정을 마치면 미래의 각 팀원에 대한 상대적인 작업량과 기술 요구 사항을 알 수 있습니다. 그런 다음 개발 팀의 기술 전문가가 티셔츠 크기를 시간 범위 및 스토리 포인트와 연관시키는 데 도움을 줄 수 있습니다.

매개변수 설정

이제 스프레드시트를 작동하고 추정치를 계산할 준비가 되었습니다. 매개변수 탭을 만들어 시작합니다. 이것은 계산의 키 역할을 하며 여기에 입력하는 값은 백로그/사용자 스토리 및 릴리스별 요약 추정에 사용되는 공식에 입력됩니다.

다음은 매개변수 탭에 필요한 모든 것입니다.

통화. 여기에서 통화 변환을 입력합니다. 예를 들어, 고객의 예산이 브라질 헤알인 경우 현재 환율을 달러 또는 유로로 입력할 수 있습니다.

시작 날짜. 예상 개발 시작 날짜는 프로젝트 일정을 만드는 데 사용됩니다. 각 예에서 시작 날짜는 10월 25일입니다.

초기 예산. 예산은 모든 MVP 기능이 예산에 맞는지 여부를 보여주는 제약 조건을 제공합니다.

티셔츠 사이즈. 티셔츠 크기를 표로 입력하고 각 크기 조합에 스토리 포인트와 시간 범위를 할당합니다. 이 예에서는 SS의 경우 1~2시간, LL의 경우 33~48시간을 사용합니다.

스프린트 시간은 최대 티셔츠 크기의 시간을 제한한다는 점을 명심하십시오. 스프린트가 1주일인 경우 가장 큰 크기는 40시간을 초과할 수 없습니다. 이것이 작업에 티셔츠 크기를 할당할 때 SME와 상담하는 것이 중요한 이유 입니다.

시간당 요금. 이 표를 사용하여 각 역할에 대한 급여를 문서화하십시오. 백엔드 개발자의 비율이 다른 경우 둘의 평균을 사용하십시오.

간접비. 총 프로젝트 노력의 일정 비율을 상태 회의, 피드백 세션 및 프로젝트 수정과 같은 관리 작업에 할당합니다. 10퍼센트(또는 각 참가자의 주당 근무 시간 중 4시간)가 시작하기에 좋은 장소이지만 더 복잡한 프로젝트의 경우 오버헤드가 더 높을 수 있습니다.

우연성. 이는 추정치의 잠재적 변동을 나타냅니다. 0%의 우발 상황에서 시작하면 스프레드시트에 입력한 값을 감안할 때 최상의(예: 가능성이 없는) 예산과 일정이 표시됩니다. 이 예의 뒷부분에서 비용과 프로젝트 기간의 잠재적인 상한을 보여주기 위해 50%의 대략적인 규모(ROM) 차이로 비상 사태를 늘릴 것입니다. 더 정확한 숫자를 얻으면 우발 상황이 줄어들 것입니다.

Epic으로 각 릴리스 크기 조정

우리는 고객의 시간과 돈을 낭비하지 않도록 전체 제품의 대략적인 크기부터 시작합니다. 사이징이 제안된 예산 및 마감일에 얼마나 근접했는지에 따라 클라이언트는 프로젝트를 포기하거나 더 자세한 견적에 투자하기로 결정할 수 있습니다. 이 시점에서 자세한 내용이 없기 때문에 백로그/사용자 스토리 탭에서 주요 기능을 에픽으로 입력합니다. 그런 다음 각 에픽에 대해 SME 및 개발 리더가 매개변수 탭의 티셔츠 크기 테이블을 기반으로 각 개발 스택에 대해 제안한 시간을 입력합니다.

먼저 "EPIC?" 열을 선택합니다. "Epic"만 선택되어 있는지 확인하십시오.

다음으로, 에픽 설명을 작성하고 개발 스택의 각 열에 대한 시간을 입력합니다. 예를 들어, "보안 연결 및 로그인"이라는 서사시는 UI 개발에 약 8시간, 백엔드에 40시간 등의 시간이 소요됩니다.

대부분의 경우 "점" 열의 셀에는 "34*"가 표시됩니다. 매개변수 탭으로 돌아가면 34포인트가 33시간에서 48시간 사이의 시간당 범위에 해당하는 것을 볼 수 있습니다. 스프린트 기간이 일주일이면 그 시간은 너무 많습니다.

세부 사항이 더 확보되면 이 시간을 줄여야 하며, 그렇지 않으면 서사시를 보다 관리하기 쉬운 이야기로 분할해야 합니다. 그러나 시간을 위해 Points 열을 무시하고 대략적인 추정을 계속하겠습니다.

이제 릴리스별 요약 추정 탭으로 이동합니다. 스프레드시트 상단에 매개변수 탭에 정의된 "간접비" 및 "우발 상황" 값이 표시됩니다. 에픽 또는 사용자 스토리별로 추정치를 표시하도록 선택할 수 있는 버튼도 있습니다.

아직 표시할 사용자 스토리가 없으므로 "에픽 모드" 버튼을 확인하세요.

이제 MVP의 대략적인 비용과 일정, 덜 긴급한 기능 및 향후 릴리스(R3 및 R4)의 업데이트를 확인할 수 있습니다. 이 예에서 고객이 모든 MVP 에픽을 첫 번째 버전에서 시작하도록 요청했기 때문에 두 번째 릴리스(R2)는 비어 있습니다.

이제 가장 낙관적인 총 비용 $28,810를 볼 수 있습니다. 이 수치는 MVP에서 R4까지의 각 릴리스 비용의 합계입니다.

우리는 또한 R4 개발 스택의 가장 최근 완료 날짜에 해당하는 제품 배송을 위한 가장 짧은 일정을 예상하고 있습니다. 프로젝트 관리자는 이러한 느린 개발 스택이 전체 릴리스의 속도를 결정하기 때문에 "중요한 경로"라고 부릅니다.

이 경우 중요한 경로는 1월 31일이 완료 날짜인 프런트 엔드 개발입니다.

이제 최악의 예산과 가장 긴 타임라인을 시뮬레이션하기 위해 매개변수를 조정할 때입니다.

비상 사태를 50%로 조정

우리는 여전히 제품에 대한 노력과 전문 지식 요구 사항에 대해 상대적으로 거의 알지 못하므로 매개변수 탭에서 50%의 ROM 우발 상황을 추가합니다. 프로젝트에 대한 자세한 내용을 알게 되면 우발 상황은 줄어들 것입니다.

다시 말하지만, 0% 우발 상황에서의 총 프로젝트 추정치는 다음과 같습니다.

그리고 여기에서는 50%의 우발 상황입니다.

이는 전체 프로젝트에 대한 ROM 추정치가 $28,810에서 $41,860 사이임을 의미합니다. 최상의 경우와 최악의 경우 클라이언트의 20,000달러 예산은 위시리스트에 있는 모든 기능을 포함하기에 충분하지 않습니다.

50% 우발 상황에서 전체 프로젝트 완료 날짜는 현재 0% 우발 완료 날짜보다 6주 늦은 3월 14일입니다.

한편 MVP는 1월 10일에 준비된다.

프로젝트를 포기하는 대신 클라이언트는 더 짧은 일정에 목표 예산에 더 가까워질 수 있는지 확인하기 위해 더 자세한 견적을 요청합니다.

마감일을 맞추기 위해 우선순위를 다시 지정하십시오.

클라이언트가 MVP의 목표 날짜를 10월 25일 시작일로부터 2개월 후인 12월 25일로 설정했다고 가정합니다.

현재 1월 10일 MVP 완료 날짜를 앞당기기 위해 클라이언트는 다음 릴리스(R2)까지 두 개의 MVP 에픽을 연기하는 데 동의했습니다.

스프레드시트는 이 조정의 계단식 효과를 계산합니다. 이 경우 MVP 타임라인은 12월 27일로 단축됩니다. 프런트 엔드 및 백 엔드 개발은 완료하는 데 가장 오래 걸리기 때문에 이 시뮬레이션에서 중요한 경로입니다.

이 정보를 바탕으로 프론트엔드 및 백엔드 완료 날짜를 다른 개발 스택과 맞추기 위해 두 명의 개발자를 더 추가하기로 결정할 수 있습니다. 이렇게 하려면 MVP "주당 시간" 행에서 시간을 40시간에서 80시간으로 늘립니다.

프론트엔드 및 백엔드 개발 스택 모두 11월에 완료되고 QA가 새로운 주요 경로가 됩니다(완료 날짜는 12월 20일). 비용은 변경되지 않습니다. 각 스택의 총 작업 시간이 동일하게 유지되기 때문입니다. 1명의 개발자가 2주(80시간) 일하는 것이 아니라 2명의 개발자가 1주일(80시간)을 일하고 있다.

스프레드시트는 또한 정규직과 시간제 근로의 차이를 설명합니다. UI 개발자가 파트타임으로 일한다고 가정해 봅시다. UI "주당 디자인 시간"을 20으로 변경하여 배송 지연을 시뮬레이션할 수 있습니다.

풀타임 일정으로 UX/UI는 11월 29일에 완료됩니다.

파트타임으로 UX/UI는 12월 27일에 완료됩니다.

다시 한 번, 비용은 변하지 않지만 UX/UI가 새로운 주요 경로가 되어 MVP의 타임라인을 12월 27일까지 연장합니다.

리소스와 클라이언트의 기한이 주어지면 허용 가능한 임계 경로에 도달할 때까지 이 시행착오 접근 방식을 계속할 수 있습니다. 적절한 기한이 정해지면 견적을 미세 조정하기 시작할 때입니다.

사용자 스토리로 견적 수정

50%의 우발 상황 추정치는 고객의 예산을 벗어나므로 우발 상황을 낮추고 보다 현실적인 추정치를 얻을 수 있도록 변수를 수정하는 것이 좋습니다.

이렇게 하려면 개발자 및 SME와 협력하여 에픽을 자세한 사용자 스토리로 나누십시오. 스토리는 에픽보다 더 잘 정의되어 있으므로 더 정확하게 크기를 조정할 수 있습니다.

그런 다음 새 정보를 기반으로 매개변수 탭의 값을 조정합니다. 예를 들어 SME 및 개발 팀은 각 역할에 대해 보다 정확한 요율을 설정하고 티셔츠 크기 및 포인트 할당을 조정하려고 할 수 있습니다. 이러한 새로운 매개변수를 사용하면 계산에 대한 자신감을 높이고 비상 사태를 25%로 낮출 수 있습니다.

에픽을 어떻게 더 작고 자세한 사용자 스토리로 나눴는지 살펴보겠습니다.

각 스택의 예상 시간을 수동으로 입력해야 하는 장대한 추정과 달리 스토리 추정은 티셔츠 크기를 지름길로 사용합니다. 여기에서 매개변수 탭에 입력한 티셔츠 크기가 유용합니다.

Backlog/User Stories 탭의 "T-shirt Sizing"에서 개발자와 SME가 각 스토리의 스택에 할당한 크기 조합을 입력합니다. 여기에서 스프레드시트 수식은 매개변수 탭의 해당 시간을 자동으로 채웁니다. 최대 크기인 LL은 합의된 스프린트 기간 내에 완료될 수 있도록 34포인트 미만으로 유지되어야 합니다. 여전히 34점 이상인 스토리는 세분화해야 합니다.

모든 스토리에 34개 미만의 포인트가 할당되었는지 확인한 후 "스토리"만 보려면 릴리스별 요약 추정 탭에서 "에픽 모드" 버튼을 선택 취소합니다.

이제 새로운 숫자 집합이 표시됩니다.

모든 작업을 자세히 설명하고 MVP 기능만 고집한 후 일정과 비용은 이제 클라이언트의 요구 사항과 일치합니다. 균형이 예산 범위 내에 있기 때문에 클라이언트는 MVP를 진행하고 추가 릴리스를 커밋하기 전에 테스트하기로 결정합니다.

당신의 것으로 만드십시오

스프레드시트는 사용이 간편하며 공식에 대한 몇 가지 기본 지식(매크로 필요 없음)만 있으면 거의 모든 요구에 맞게 조정할 수 있습니다. Excel 지식이 녹슬다면 Udemy 및 edX의 온라인 과정이 이러한 기술을 연마하는 데 도움이 될 것입니다.

이 문서에서는 발견 추정치를 다루었지만 동일한 스프레드시트를 사용하여 번업/번다운 차트를 생성하고, 타임라인을 조정하고, 이후 단계의 속도와 스프린트를 기반으로 추정치를 계산할 수 있습니다. 나는 Jira, Asana, Trello와 같은 응용 프로그램을 보완하기 위해 사용자 정의된 스프레드시트를 사용하고 프로젝트 관리 키트의 강력한 도구임을 유지합니다. 나는 그들이 당신에게 유용하고 다재다능하다는 것을 증명하기를 바랍니다.

기성품 프로젝트 관리 도구보다 사용자 지정 스프레드시트를 선호합니까? 의견에 이유 또는 이유를 알려주십시오.