마감일 맞추기: 개발자가 노력을 추정하는 데 사용하는 방법

여러분, 안녕하세요! 소프트웨어 개발을 시작하기 위해 알아야 할 엄청난 양의 이론이 있습니다. 일부 전문가(예: Java 및 기타 언어를 사용하는 백엔드 개발자)는 더 많이 알고 있는 반면 다른 전문가(예: JavaScript 및 React Native를 사용하는 프런트엔드 개발자)는 조금 덜 알고 있을 수 있습니다. 즉, 두 그룹 모두 기술적 지식뿐만 아니라 "조직적" 지식도 보유하고 있어야 합니다. 이 "조직적" 지식은 프런트엔드 및 백엔드 개발자가 겹치는 영역 중 하나입니다. 오늘 저는 이 비기술적이고 조직적인 지식의 한 측면에 대해 이야기하고 싶습니다. 오늘 우리는 노력 추정 에 대해 이야기할 것입니다 . 애자일 방법론을 사용한 경험만 있기 때문에(가장 인기 있는 것으로 간주됨), 보다 구체적으로 Scrum 프레임워크의 경우 Scrum 의 맥락에서 노력 추정을 고려할 것입니다 . 처음부터 노력 추정이 어렵다고 말해야 합니다. 나에게 그것은 개발자로서 내 직업에서 가장 도전적이고 불쾌한 측면 중 하나입니다. 작업에 필요한 노력의 추정치에 영향을 줄 수 있는 고려해야 할 여러 가지 요소가 있습니다. 또한 향후 개발 계획은 귀하의 추정치를 기반으로 합니다.

잘못된 견적을 제공하면 어떻게 됩니까?

개발자가 작업에 소요되는 시간보다 작업에 소요되는 시간이 훨씬 더 많다고 추정하는 경우 추정이 너무 부정확하기 때문에 개발자의 전문성을 의심할 수 있습니다. 즉, 그것은 거친 추측이었습니다. 동시에 개발자가 예상 시간 내에 작업을 완료하지 못하면 제품이나 새로운 기능을 출시하려는 고객의 계획을 위태롭게 합니다. 이것은 사업이고 사업은 돈입니다. 그러한 전표에 만족하는 고객은 거의 없습니다. 사실, 그것이 제가 추정을 좋아하지 않는 이유입니다. 때로는 작업을 완료하는 데 필요한 시간을 정확하게 결정하는 것이 매우 까다롭기 때문입니다.

시간 추정 방법

일반적으로 견적은 시간 또는 스토리 포인트 단위로 이루어집니다. 개인적으로 선호하는 것은 스토리 포인트를 사용하여 추정 프로세스를 수행하는 것입니다 . 구체적인 물리적 개체에 대해 오해하기는 어렵지만 스토리 포인트는 좀 더 추상적입니다. 소프트웨어 개발 팀은 일반적으로 예상 시간을 시간, 일, 주, 월 단위로 제공합니다. 이러한 예상 시간은 주로 개인적인 경험, 추측 및/또는 직관을 기반으로 합니다. 이 경우 개발자는 단순히 작업을 살펴보고 소요 시간에 대한 가정을 표현합니다. 결과적으로 작업 기간에 영향을 줄 수 있는 요소가 너무 많기 때문에 이러한 추정치는 정확하지 않습니다. 그렇기 때문에 애자일 방법론을 사용하는 많은 팀에서도 스토리 포인트를 사용합니다. 다이빙하자!

스토리 포인트는 무엇입니까?

스토리 포인트는 특정 기능을 완전히 구현하는 데 필요한 총 노력의 추정치를 표현하기 위한 측정 단위입니다. 즉, 우리는 친척 에 대해 이야기하고 있습니다.복잡성. 팀은 작업의 복잡성, 작업량, 위험 또는 불확실성을 기반으로 스토리 포인트에서 추정치를 할당합니다. 이러한 값은 일반적으로 작업을 보다 효율적으로 더 작은 조각으로 나누어 모호성을 제거하기 위해 할당됩니다. 시간이 지남에 따라 팀은 주어진 시간 내에 달성할 수 있는 것을 이해하고 후속 작업을 보다 정확하게 계획하는 데 도움이 됩니다. 이것은 완전히 직관에 반하는 것처럼 들릴 수 있지만 이 추상화는 실제로 유용합니다. 팀이 작업의 복잡성에 대해 어려운 결정을 내리도록 합니다. 계획할 때 스토리 포인트를 사용하는 몇 가지 이유를 살펴보겠습니다.

• 부정확한 시간 추정을 피할 수 있습니다.
• 시간 단위로 추정한 것과는 달리 스토리 포인트를 사용하면 팀 구성원과 고객 간의 커뮤니케이션, 다양한 팀 토론 및 계획 활동, ​​예상치 못한 상황과 같은 간접 비용을 설명할 수 있습니다.
• 각 팀은 서로 다른 척도를 사용하여 작업을 추정합니다. 즉, 역량(포인트 단위로 측정)이 다릅니다.
• 각 스토리 포인트 할당에 대한 척도를 정의하면 큰 논란 없이 신속하게 포인트를 할당할 수 있습니다.

스토리 포인트를 사용하지 않는 방법

불행히도 스토리 포인트는 종종 오용됩니다. 스토리 포인트는 사람들을 평가하고 상세한 기한과 리소스를 정의하는 데 사용되며 성과 측정으로 오인될 때 오해의 소지가 있습니다. 대신 팀은 이를 사용하여 각 작업의 범위/복잡성을 이해하고 우선 순위를 설정해야 합니다. 더 어렵다고 여겨지는 부분을 먼저 처리해야 스프린트가 끝나기 전에 완료할 수 있고 더 쉬운 작업은 나중에 처리할 수 있습니다. 스크럼 방법론 의 맥락에서 스프린트가 무엇인지 상기시켜 드리겠습니다 . 이 기간의 길이는 개발이 시작될 때 결정되며 팀과 고객 간에 합의됩니다. 이 기간은 2주 또는 한 달 또는 기타 기간일 수 있습니다. 일반적으로 스프린트가 끝날 때까지 완료된 작업이 고객에게 전달될 때까지 완료할 수 있는 작업을 계획하기 위해 각 스프린트가 시작될 때 예상 작업량을 계산합니다. 데모는 제품 개발 진행 상황을 확인하고, 고객으로부터 피드백을 받고, 고객의 비전에 따라 프로젝트의 궤적을 조정하는 데 도움이 됩니다. 그러나 우리는 조금 벗어납니다. 추정치로 돌아가 봅시다. 단 한 명의 개발자가 모든 작업에 대한 견적을 제공하도록 하는 것은 너무 주관적일 수 있습니다. 따라서 이 프로세스는 일반적으로 팀 작업입니다. 팀에서 추정치를 생성하는 데 사용할 수 있는 몇 가지 기술이 있습니다. 오늘 우리는 가장 인기 있는 기술인 스크럼 포커를 살펴볼 것입니다 . 이 기술에는 스크럼 포커 의 중재자 역할을 할 관리자가 필요합니다 . 이것은 스크럼 마스터 또는 가능하면 PM 인 사람이 될 수 있습니다 .

스크럼 포커란?

스크럼 포커 또는 플래닝 포커는 합의에 도달하는 것을 기반으로 하는 추정 기법입니다. 주로 앞으로 작업의 복잡성이나 소프트웨어 개발 작업의 상대적 크기를 추정하는 데 사용됩니다. 스크럼 포커 라고 바로 말할게일반적인 소프트웨어 개발 관행이며 그것이 무엇인지 알아야 합니다. 일반적으로 팀이 특정 작업에 대한 견적을 공동으로 생성하는 데 도움이 되는 앱이나 웹 사이트가 포함됩니다. 어떻게 이런 일이 발생합니까? 팀은 백로그(새 작업, 일부 기능)에서 무언가를 가져와 가능한 함정 및 이와 관련된 기타 뉘앙스에 대해 간략하게 논의합니다. 그런 다음 각 참가자는 복잡성 추정치를 반영하는 숫자가 있는 카드를 선택합니다. 아, 한 가지 더, 이러한 추정을 할 때 일반 숫자가 아닌 피보나치 수열 의 숫자를 사용합니다. 피보나치 숫자는 스크럼 포커 에서 인기가 있습니다., 그들 사이에 점점 더 큰 간격이 있기 때문입니다 (피라미드 수준과 유사). 일부 작업은 매우 복잡하며 적은 수의 스토리 포인트로 벗어날 수 없습니다. 다음과 같은 의미를 지닌 특이한 카드가 있습니다.

알 수 없는 끝점 수

무한히 긴 작업

쉬고 싶어

덜 일반적인 추정 방법은 다음을 사용합니다.

• 티셔츠 사이즈 — S, M, L, XL
• 개 품종 — 치와와, 퍼그, 닥스훈트, 불독 등(개인적으로 이것은 노력 추정을 위한 가장 이상한 측정 단위라고 생각합니다 =D)

그런 다음 팀은 동일한 작업에 대해 다른 개발자가 제공한 추정치를 비교합니다. 그들이 동의한다면 좋습니다! 그렇지 않은 경우 다른 추정치에 대한 이유(인수)를 논의해야 합니다. 그 후 팀은 함께 작업하여 모든 사람이 어느 정도 수용할 수 있는 단일 추정치를 형성합니다. 그렇다면 심각한 소프트웨어 프로젝트를 계획하는 데 포커가 사용되는 이유는 무엇입니까? 이것이 이상하다는 것을 인정해야 합니다. 사실 이러한 종류의 게이미피케이션은 팀원들이 독립적으로 생각하고 팀원들과 동시에 추정치를 공개하도록 유도합니다. 이렇게 하면 일부 팀원이 다른 팀원의 의견에 의존하는 상황이 발생하지 않습니다. 이렇게 하지 않으면 경험이 적은 개발자가 경험이 많은 팀원이 제공한 추정치를 보고 집중할 것입니다. 그리고 그것은 그들 자신의 추정치를 덜 유용하게 만들 것입니다. 그러나 추정치를 동시에 표시하면 이것이 본질적으로 불가능합니다. Atlassian 제안계획 프로세스에서 사용하기 위한 스크럼 포커 앱 .

노력 추정의 예

팀에서 추정치에 스토리 포인트를 할당하기 위해 다음 척도를 설정했다고 가정합니다. 각 작업에 대해 스크럼 포커가 진행되며 다음과 같이 추정치를 제공합니다.

• 이전에 비슷한 기능을 구현한 적이 없습니다: +3
• 기능은 평균 크기입니다: +2
• 구현은 매우 복잡할 것입니다: +3
• 기능에 대한 테스트 작성은 매우 복잡합니다: +3

각 구성 요소를 합하면 총 11개의 스토리 포인트를 얻지만 그러한 카드가 없으므로 13개를 제안합니다. 동료가 작업에 대해 다음 추정치를 제시합니다.

• 그는 이전에 유사한 작업을 수행한 적이 있습니다. +1
• 기능은 평균 크기입니다: +2
• 구현은 평균 복잡도: +2
• 기능에 대한 테스트 작성은 평균 복잡성: +2

그의 중간 결과는 7개의 스토리 포인트이지만 피보나치 수열에는 해당 숫자가 존재하지 않으므로 가장 근사한 숫자인 8로 카드를 제출합니다. 다른 팀원들도 주관적인 견해를 바탕으로 추정을 합니다. 그런 다음 모든 사람이 자신의 카드를 보여주고 8을 제안한 개발자 한 명을 제외하고 거의 모든 동료가 추정치를 13으로 제시했음을 알게 됩니다. 이 경우 그는 자신의 추정치가 낮은 이유를 설명하도록 허용됩니다. 그가 다음과 같은 정당성을 제공한다고 가정합니다. 그는 이전에 동일한 작업을 수행했으며 보기보다 어렵지 않습니다. 궁극적으로 그는 이 작업을 수행하는 사람을 돕겠다고 말하면서 나머지 팀원들에게 마음을 13개에서 8개 스토리 포인트로 바꾸도록 설득합니다. 아니면 그가 스스로 할 것입니다. 어쨌든 그렇지 않다. 다른 사람들이 그의 주장을 받아들이는지 여부는 중요하지 않습니다. 어떤 식으로든 작업에 추정치가 할당되고 팀은 다음 작업을 고려하기 위해 이동할 것이기 때문입니다. 처음에는 다음 기간(스프린트)에 완료할 계획인 작업량의 추정치와 마찬가지로 추정치가 부정확합니다. 결국 이러한 추정은 추정을 사용하여 이루어졌습니다. 얼마 후, 아마도 3개월 후 팀은 작업에 필요한 시간을 더 정확하게 추정하기 시작하고 팀이 스프린트에서 수행할 수 있는 평균 작업량이 분명해집니다. 그러나 이것은 업무 범위에 대한 전반적인 계획을 세우는 과정입니다. 주로 시간에 초점을 맞추지만 이 경우에는 여러 관련 요소가 있을 수 있습니다. 예를 들어 개발자가 2주 동안 휴가를 갔다고 가정합니다. 일정량의 계획된 작업(계획된 기능)을 잘라야 합니다. 또는 새로운 개발자가 팀에 합류했지만 아직 완전히 적응하지 못해서 프로젝트에 익숙해질 수 있는 시간을 주어야 한다고 가정합니다.온보딩 프로세스. 프로젝트의 복잡성에 따라 2주가 될 수도 있고 일주일이 걸릴 수도 있습니다. 오늘은 그게 다야! 소프트웨어 개발에 필요한 비기술적 측면인 노력 추정에 대한 지식이 약간 향상되었으면 합니다. 이 주제와 스크럼에 대해 더 자세히 알고 싶다면 Jeff Sutherland의 책 "SCRUM"을 읽어 보시기 바랍니다. 나는 결과에 대해 어떤 약속도 할 수 없습니다. 왜냐하면 그것을 읽은 후에는 스크럼 마스터가 되고 싶은 성가신 욕구가 생길 것이기 때문입니다 =D