애자일 스토리 포인트 대 시간: 소프트웨어 개발을 더 잘 예측하는 방법

소프트웨어 개발 프로세스에 대해 생각을 정리하는 것은 어려울 수 있습니다. 아이디어가 떠오르고 개발자에게 접근할 때 처음 두 가지 질문은 구현 비용과 구축 시간 입니다. 추정은 앱 개발의 첫 번째 단계 중 하나입니다.

이 기사에서는 최신 소프트웨어 개발에서 가장 널리 사용되는 두 가지 추정 모델인 Agile 스토리 포인트 대 시간을 비교합니다 .

Agile에서 시간을 추정하는 방법, 두 추정 모델의 요점을 파악하고, 차이점을 이해하고, 개발자가 다른 모델보다 하나를 선택하는 이유를 알아보려면 계속 읽으십시오.

시간은 이해하기 매우 쉽고 오랫동안 소프트웨어 개발의 주요 추정 모델이었습니다. 작업 시간 또는 작업자 시간이라고도 하는 시간은 개발자가 프로젝트에 소비 하는 시간 입니다.

그렇다면 이미 간단하고 간단한 추정 모델이 있는 경우 스토리 포인트는 무엇이며 왜 등장했을까요?

내용물:

1. 스토리 포인트가 정확히 무엇인가요?
2. Agile에서 스토리 포인트를 계산하는 방법은 다음과 같습니다.
3. 스토리 포인트 추정의 장점
4. 스토리 포인트 추정의 단점
5. 시간 추정의 장점
6. 시간 추정의 단점
7. 스토리 포인트를 시간으로 변환할 수 있습니까?
8. 스토리 포인트 대 시간: 소프트웨어 개발을 위해 무엇을 선택해야 합니까?

스토리 포인트가 정확히 무엇인가요?

스토리 포인트는 Agile 및 Scrum 고유의 상대적 추정 모델입니다. 그들은 개발의 세 가지 측면을 다룸 으로써 제품을 만들기 위한 노력을 추정합니다.

• 제품에 필요한 작업량

• 제품 기능의 복잡성

• 개발에 영향을 미칠 수 있는 위험 및 불확실성

프로젝트 평가 초기에 개발자는 제품이 가지고 있는 가장 작고 단순한 사용자 스토리( 예: 가입 사용자 스토리)를 선택하고 1포인트 사용자 스토리로 설정합니다. 이것이 기본 스토리입니다 . 복잡성 비교에 사용될 사용자 스토리입니다. 다른 모든 사용자 스토리에는 기본 스토리와 비교하여 개발해야 하는 복잡성에 따라 여러 스토리 포인트가 할당됩니다.

표면적으로는 단순해 보이지만 각 스토리의 스토리 포인트 수는 누가 결정합니까?

Agile에서 스토리 포인트를 계산하는 방법은 다음과 같습니다.

시간과 마찬가지로 제품에 대해 작업할 사람들은 일반적으로 개발을 위한 스토리 포인트를 추정합니다. 그러나 추정 프로세스는 스토리 포인트와 약간 다릅니다.

스토리 포인트를 사용자 스토리에 할당하기 위해 여러 개발자 가 참여합니다. 최소한 두 개는 있어야 하지만 회사는 모든 개발자에게 업계에서 플래닝 포커(Planning Poker) 라고 부르는 게임을 하여 기여하도록 요청할 수 있습니다. 게임의 규칙은 다음과 같습니다.

1. 각 개발자는 계획 포커 카드 세트를 받습니다.

2. 개발자는 사용자 스토리를 선택하고 복잡성과 필요한 개발 노력에 대해 논의합니다.

3. 각 개발자는 스토리에 할당할 점수에 해당하는 카드를 제출합니다.

4. 스토리 포인트 추정치가 동일한 경우 추정 포인트 수가 스토리에 할당됩니다.

5. 제안된 스토리 포인트가 다른 경우 개발자는 다수가 승인한 여러 포인트가 나올 때까지 사용자 스토리를 논의합니다.

6. 개발자는 다음 사용자 스토리를 선택합니다.

7. 3~5단계를 반복합니다.

모든 활동이 원격으로 진행되었을 때 이 프로세스가 수정되었습니다. 카드와 회의가 아닌 온라인 토론, Zoom 회의, 메신저 등을 통해 스토리 포인트를 결정합니다.

다음과 같이 보입니다.

물론 스토리 포인트를 추정하는 데 관련된 모든 개발자가 프로젝트에서 작업할 것이라는 의미는 아닙니다. 그러나 스토리 포인트 시스템의 주요 이점은 문제의 프로젝트뿐만 아니라 유사한 기능을 가진 향후 프로젝트에서도 사용할 수 있는 다소 보편적인 프레임워크 를 생성한다는 것입니다.

스토리 포인트를 추정하는 데 자주 사용되는 두 가지 옵션이 있습니다. 다음과 같이 포인트를 할당할 수 있습니다.

• 임의의 정수 사용(1, 2, 3… 13,14,15 등)

• 피보나치 수열의 숫자 사용(1, 2, 3, 5, 8, 13… 55, 89, 144 등)

피보나치 수열은 근사치를 위한 약간의 여백을 남기기 때문에 전개를 추정하는 데 더 편리한 옵션입니다. 숫자 순서 모델은 편리한 비교를 위해 너무 정확합니다.

개발 중 및 프로젝트 사이에서 사용자 스토리가 원래 예상보다 더 복잡하거나 덜 복잡하게 되면 할당된 스토리 포인트가 변경될 수 있습니다.

스토리 포인트 추정의 장점

스토리 포인트를 할당하는 과정이 조금 복잡해 보이더라도 당황하지 마세요. 스토리 포인트가 있는 용량 계획에는 장점이 있습니다.

1. 스토리 포인트는 개발자 독립적입니다.

각 스토리에 대한 스토리 포인트는 여러 개발자가 협상을 통해 할당하는데, 그 이유는 특정 제품과 특정 개발자가 아닌 '평균'에 숫자가 할당되기 때문입니다. 이것이 왜 좋은 일입니까?

일이 일어납니다. 때로는 프로젝트의 개발자가 프로젝트를 떠나 교체될 수 있습니다. 병에 걸리거나 육아휴직이나 안식년을 선택하거나 단순히 회사를 떠날 수도 있습니다. 아마도 그들은 프로젝트에 대해 자격이 부족하거나 자격이 초과된 것으로 판명될 것입니다.

교체될 때 새 개발자는 다른 작업 속도를 가질 수 있으므로 제품을 만드는 데 필요한 작업 시간을 다시 추정해야 합니다.

스토리 포인트 는 이 문제를 최소화합니다 . 여러 개발자가 할당하여 특정 사용자 스토리가 얼마나 복잡한지 일반적으로 보여줍니다. 스토리 포인트는 특정 회사의 모든 개발자에게 적용됩니다. (하지만 스토리 포인트 추정치는 회사마다 정확하지 않을 수 있습니다.)

2. 스토리 포인트로 개발 시간 재계산 용이

스토리 포인트를 사용한 애자일 시간 추정에서 팀은 속도라는 용어를 사용하여 단일 스프린트에서 릴리스된 스토리 포인트 수를 나타냅니다.

팀은 지속적으로 속도를 모니터링하며 처음에는 매우 다양합니다. 팀은 일주일에 5개의 스토리 포인트, 다음 주에는 20개의 스토리 포인트에 해당하는 기능을 출시할 수 있습니다. 그러나 그것은 시작에 불과합니다. 프로젝트가 진행됨에 따라 속도 그래프가 균일해집니다 .

시간과 함께 팀 구성원이 변경되면 마감 시간을 조정하기 위해 관련된 각 작업을 다시 평가해야 합니다. 스토리 포인트에서는 이것이 필요하지 않습니다. 팀은 전체 속도의 변화를 알고 다음 스프린트 이후에 프로젝트 마감일을 조정할 수 있습니다.

스토리 포인트는 팀 성과를 전체적으로 평가 하므로 작업별로 재평가할 필요가 없습니다.

3. 스토리 포인트는 팀 성과를 모니터링하는 데 좋습니다.

다른 시간에 유사한 프로젝트 및/또는 작업을 수행하는 팀이 있는 경우 속도를 통해 각 팀의 진행 상황을 쉽게 표시할 수 있습니다. 얼마나 개선되었습니까? 어떤 팀이나 개발자가 어려움을 겪고 있으며 추가 교육이 필요할 수 있습니까? 학습 곡선은 무엇입니까? 다른 팀이 더 나은 성과를 낼 수 있을까요?

Velocity는 팀의 성과를 현장에서 뿐만 아니라 지속적으로 평가할 수 있는 훌륭한 도구입니다.

4. 스토리 포인트로 시작 시간 추정이 더 정확합니다.

속도를 추적함으로써 팀은 한 스프린트에서 얼마나 많은 스토리 포인트를 출시할 수 있는지 매우 정확하게 알 수 있습니다. 앱 개발 팀이 속도를 계산하는 데 시간이 걸리지만 일단 계산되면 예상 출시 날짜를 쉽게 예측할 수 있습니다.

또한 팀 구성원, 요구 사항 또는 기능의 수/복잡성의 변경으로 인해 재추정에 많은 어려움을 겪지 않습니다.

5. 예측 속도를 높이기 위해 향후 프로젝트에 스토리 포인트를 재사용할 수 있습니다.

회사가 특정 틈새 시장(또는 여러 분야)에 정통하고 유사한 기능 세트로 하나 이상의 제품을 구축하는 것은 드문 일이 아닙니다. 스토리 포인트로 추정되는 프로젝트 하나라도 완료한 후 개발자는 이 추정치를 새로운 프로젝트에 참조할 수 있습니다 . 이렇게 하면 추정 시간이 단축됩니다.

그러나 상황이 바뀔 수 있으므로 각 프로젝트의 속도를 계속 추적하는 것이 중요합니다.

6. 스토리 포인트는 팀워크를 향상시킵니다.

전통적으로 개발 회사에는 여러 팀의 개발자가 있으며 각각 별도의 프로젝트를 수행합니다. 몇 시간 안에 추정할 때 추정하는 것은 프로젝트에서 작업하는 개발자입니다. 이것은 일반적으로 좋은 일입니다. 그 일을 하는 사람보다 시간이 얼마나 걸릴지 누가 더 잘 알겠습니까?

그러나 스토리 포인트의 복잡성을 추정 하면 같은 분야의 개발자가 협력할 수 있는 기회가 제공됩니다. 이는 다른 방법으로는 거의 발생하지 않는 일입니다. 이러한 종류의 팀워크는 경험을 공유하고 서로에게 동기를 부여할 수 있는 좋은 기회입니다.

스토리 포인트 추정의 단점

논쟁에는 항상 다른 면이 있습니다. 그것이 얼마나 훌륭한 시스템이 탄생하느냐 하는 것입니다. 복잡도 기반 추정도 단점 이 있으며, 장점이 더 많은지 여부는 각 팀이 스스로 결정해야 합니다.

1. 스토리 포인트는 한 명 이상의 개발자가 할당해야 합니다.

스토리 포인트 모델의 장점은 객관성과 미래 추정 가치입니다. 그러나 그것이 사실이 되려면 두 명 이상의 개발자 가 평가를 수행해야 합니다 . 팀이 하나인 소규모 회사나 한 분야에 전문가가 한 명뿐인 회사(예: 디자이너 또는 iOS 개발자 한 명)의 경우 스토리 포인트는 많은 이점을 가져오지 않습니다. 이러한 소규모 회사는 전통적으로 추정 모델로 근로 시간을 선택합니다.

2. 스토리 포인트 추정에는 상당한 백로그가 필요합니다.

스토리 포인트의 잠재력을 최대한 활용하려면 팀에서 상당한 시간 을 투자해야 합니다. 팀에서 이전에 작업한 적이 없는(또는 풀타임으로 작업한 적이 없는) 기능이 있는 프로젝트에서 작업하는 경우 처음 2~3개의 스프린트는 성능 면에서 예측하기 어려울 것입니다. 물론 팀에 백로그 항목이 많을수록 통계 데이터가 풍부하기 때문에 추정치가 더 정확할 수 있습니다. 그러나 스토리 포인트는 바로 사용할 수 있는 시스템이 아닙니다.

3. 스토리 포인트는 예산 책정을 위해 더 복잡합니다.

스토리 포인트는 개발자와 고객의 마케팅에 중요할 수 있는 정확한 마감일과 출시 날짜를 설정하는 데 유용합니다. 그러나 앱 개발 비용을 추정할 때는 덜 편리합니다 .

문제는 개발자가 코드 작성(또는 디자인 작성 또는 테스트)뿐만 아니라 프로젝트에 시간을 할애한다는 것입니다. 연구, 토론(팀 내부 및 클라이언트와 함께)에 약간의 시간이 소요됩니다. 변경 작업 등에 소요됩니다. 스토리 포인트를 추정하는 데 소요된 시간도 프로젝트에 소요된 시간이지만 스토리당 포인트에는 포함되지 않습니다.

스토리 포인트로 추정할 때 예산 책정이 가능하지만 일반적으로 프로젝트에 소요된 시간과 돈을 동일시하는 것이 더 빠르고 쉽습니다.

4. Velocity는 팀별로 계산됩니다.

이것이 의미하는 바는 팀이 프로젝트 간에 혼합하는 경우 각 개발자 조합 에 대한 속도를 별도로 계산 해야 한다는 것입니다. 따라서 한 팀에 대한 추정이 다른 팀에 대해 반드시 사실이 아닐 수 있으며 단일 팀 구성원을 변경하더라도 잠재적으로 이전 추정이 무효화될 수 있습니다.

반면에 복잡성 추정을 사용하여 가장 성능이 좋은 조합을 찾을 수 있습니다. 시간이 걸리겠지만.

시간 추정의 장점

일부 Agile 팀은 스토리 포인트를 사용하지만 많은 팀은 아직 근무 시간에서 전환하지 않았습니다. 거기에는 중요한 이유가 있습니다. 그들도 덮읍시다.

1. 시간은 친숙한 모델입니다.

혁신은 훌륭하지만 시간이 걸립니다. 개발자와 그들의 고객은 모두 근로 시간 추정에 정통합니다. 많은 사람들에게 아이디어는 "고장난 것이 아니라면 고치지 마십시오."입니다. 시스템이 실행 가능한 추정치를 제공하는 한 왜 다른 것으로 전환합니까?

추정치의 정밀도 차이는 일부 개발자가 작업 방식을 변경하기에 충분하지 않을 수 있습니다.

2. 클라이언트는 일반적으로 시간당 비용을 지불합니다.

이것은 약간의 설명이 필요합니다. 클라이언트의 경우 복잡도 기반 추정이 혼란스러울 수 있습니다 . 또한 클라이언트에게 예산이 출시 날짜(종종 그렇습니다)보다 더 중요한 경우 스토리 포인트는 고객과 관련이 없습니다.

3. 시간 기반 추정은 한 명의 개발자가 수행할 수 있습니다.

소규모 팀이나 프리랜서의 경우 스토리 포인트는 여러 관점이 필요하기 때문에 거의 쓸모가 없습니다. 참조가 없으면 스토리 포인트에서 추정하는 것은 불필요한 번거로움입니다.

반면에 시간은 프로젝트에서 작업하는 개발자가 스스로 상당히 정확한 추정 을 할 수 있는 방법을 제공 합니다 .

팀 속도도 마찬가지입니다. 프리랜서나 부분 아웃소싱처럼 팀이 매번 바뀔 때 모니터링 속도는 거의 의미가 없습니다. 여기서 시간 기반 추정이 더 나은 선택입니다.

시간 추정의 단점

팀이 추정 모델로 시간 사용을 중단하기로 결정한 이유는 다음과 같습니다.

1. 전적인 추정에 대한 부담이 크다.

한편으로는 자신에게만 의존하기 때문에 시간 요구 사항을 예측하는 것이 더 쉬울 수 있습니다.

반면에 예상치를 달성하지 못하면 큰 타격을 입습니다. 작업 시작을 기다리는 팀이 귀하의 작업을 완료하는 데 의존하는 경우 더욱 그렇습니다.

더욱이 약속한 것을 이행해야 한다는 압박감으로 인한 스트레스는 잘 진행되고 있는 작업을 방해할 수 있습니다.

2. 한 개발자의 추정치는 항상 팀의 추정치보다 정확하지 않습니다.

개별 추정치는 주관적이며 추정자의 감정적, 심리적 상황과 관련이 있습니다.

일부 개발자 는 자신을 과대평가하고 나중에 유지하기 위해 애쓰는 시간 프레임을 설정 하는 경향이 있습니다. 이것은 개발을 방해할 뿐만 아니라(벌금이 있는 경우 팀에 추가 비용을 부과함) 개발자에게 스트레스와 소진을 유발 합니다.

다른 사람들 은 자신의 기술을 과소평가하여 객관적으로 필요한 것 이상으로 개발을 연장합니다. 불안과 일을 지나치게 생각하고 확인하고 다시 확인하는 습관은 종종 개발 마감일을 나중으로 설정하고 마감일 전에 작업을 완료 하는 경우 는 드뭅니다 . 팀 입력을 통해 보다 객관적인 추정이 가능합니다.

3. 작업이 클수록 몇 시간으로 예측하기가 더 어렵습니다.

이는 비개발 상황과도 관련이 있습니다. 세 페이지짜리 대학 소책자를 읽는 데 시간이 얼마나 걸릴지 말하기는 쉽지만 전쟁과 평화 를 끝내는 데 얼마나 걸릴지 예측하기는 더 어렵습니다.

개발도 마찬가지입니다. 약간의 경험이 있는 개발자 는 작은 작업을 쉽게 예측할 수 있습니다. 그러나 작업이 클수록 프로젝트 내부와 외부에서 발생하는 더 많은 일이 개발에 영향을 줄 수 있습니다. 시간 기반 추정은 스토리 포인트의 마진을 제공하지 않으므로 추정이 더 거칠어집니다.

4. 약간의 유연성

시간 기반 추정은 개발자 기반입니다. 제품 작업을 하는 팀원 중 한 명이 프로젝트 중간에 변경하는 경우 팀은 아직 개발 중이거나 향후 스프린트가 예정된 모든 영향을 받는 사용자 스토리 를 다시 계산 해야 합니다. 프로젝트의 단계와 원래 개발자와 새 개발자의 기술 차이에 따라 많은 작업이 필요할 수 있습니다. 시간 기반 시간 추정은 매우 엄격합니다.

스토리 포인트를 시간으로 변환할 수 있습니까?

고객은 스토리 포인트를 추정하는 팀에 애자일 스토리 포인트 매핑을 시간 으로 변환 하도록 요청할 수 있습니다. 최신 소프트웨어 개발 동향에 익숙하지 않은 대부분의 사람들은 스토리 포인트를 무엇으로 만들어야 할지 모를 것입니다.

그러나 클라이언트가 스토리 포인트가 몇 시간인지 묻는 경우 명확하게 대답할 수 없습니다. 복잡성 기반 추정의 주요 구성 요소 중 하나는 스토리를 완성하는 데 드는 노력입니다. 그러나 노력이 보낸 시간으로 직접 변환되지는 않습니다 . 시간은 스토리 포인트보다 더 모호한 방식으로 불확실성을 해결합니다.

작업이 복잡할수록 더 많은 불확실성과 위험이 존재합니다. 스토리 포인트를 시간으로 변환하고 속도에만 의존하는 것은 그러한 많은 위험을 설명하지 않습니다. 위험과 불확실성에 관해서 는 시간 기반 추정이 스토리 포인트보다 더 근사하기 때문 입니다.

스토리 포인트를 할당할 때 피보나치 수열 을 사용하면 어느 정도 개발 시간의 불확실성을 설명할 수 있지만 직접 변환을 정확히 허용하지는 않습니다.

여기 예가 있습니다.

1층 스토리(기본 스토리)를 완료하는 데 2시간이 걸린다고 가정해 보겠습니다.

13층짜리 이야기 는 아무 일도 잘못되거나 방해가 되지 않는 경우 최상의 시나리오에서 26시간 이 걸릴 수 있습니다. 예를 들어 사용된 API가 완벽하게 맞는 경우 엔드포인트에서 엔드포인트로. 그렇지 않은 경우에, 이야기는 어디 (30) 50 시간 말 사이 필요할 수 있습니다 - 얼마나 많은 불일치에 따라 달라집니다. 개발자가 아직 해당 API로 작업하지 않은 경우 어떻게 될지 미리 말할 수 있는 사람은 없습니다.

따라서 스토리 포인트를 시간으로 변환할 때 불확실성을 해결하기 위해 기하급수적인 성장 에 대한 승수 가 필요합니다. 그리고 그 승수는 팀마다 다릅니다.

스토리 포인트 대 시간: 소프트웨어 개발을 위해 무엇을 선택해야 합니까?

보시다시피 스토리 포인트와 시간은 모두 개발자가 프로젝트를 추정하는 데 유효한 선택입니다.

대체로 아웃소싱 업체는 시간에 의존하는 경향이 있는 반면 더 많은 제품 회사가 스토리 포인트를 선택한다고 말할 수 있습니다.

고정 가격 모델을 사용하는 회사는 일반적으로 시간 기반 추정을 사용합니다. 스크럼을 선호하는 팀은 말 그대로 스크럼에서 태어나고 이 방법론에 고유한 스토리 포인트를 선택하는 경우가 많습니다.
다년간의 경험을 통해 우리는 다음과 같이 보게 되었습니다.

• 출시일을 정확하게 예측하는 것이 예산을 맞추는 것보다 더 중요하다면 스토리 포인트로 이동하십시오.

• 정확한 출시 날짜보다 예산이 더 중요하다면 시간을 고려하십시오.

또는 무엇보다도 두 가지를 결합하십시오.

스토리 포인트 는 모니터링 속도가 차이를 만드는 긴 프로젝트에서 작업하는 개발 팀에게 매우 편리합니다.

시간 은 예산 부족에 대해 걱정하는 고객에게 중요합니다. 또한 시간은 단기 프로젝트에 더 적합합니다.

복잡성 기반 시스템은 Scrum 자체와 마찬가지로 아직 상당히 젊고 계속 발전하고 있습니다. 두 추정 모델을 결합하고 각 스토리 포인트를 시간 단위로 빠르게 변경하는 시스템을 작동하면 두 모델의 장점을 모두 제공하면서 단점을 최소화할 수 있습니다.