개발자는 작업을 평가하기 위해 어떤 방법을 사용합니까?

안녕하세요 여러분! 개발을 시작하는 데 필요한 이론은 매우 광범위합니다. 일부 전문가(Java 및 기타 언어의 백엔드 개발자)는 더 많은 것을 가지고 있는 반면, 다른 전문가(예: JavaScript - React Native의 프런트엔드 개발자)는 약간 더 적은 것을 가지고 있습니다. 그러나 두 사람 모두 기술적 지식뿐만 아니라 "조직적" 지식도 많이 보유하고 있어야 합니다. 이 "조직적" 지식은 프론트엔드와 백엔드 개발자의 교차점 중 하나입니다. 오늘 저는 이러한 비기술적, 조직적 지식의 한 측면, 즉 작업 평가 (추정) 에 대해 이야기하고 싶습니다 . 그리고 저는 Agile 방법론(실제로 가장 인기 있는 것으로 간주됨)에서만 작업했기 때문에 해당 하위 부분인 Scrum 에서 Scrum 의 맥락에서 작업 평가를 고려할 것입니다 . 평가라고도 불리는 평가는 어렵다고 바로 말씀 드리겠습니다. 개인적으로 개발자로서 이것은 이 작업에서 가장 어렵고 바람직하지 않은 측면 중 하나입니다. 작업 평가에 영향을 미칠 수 있는 다양한 요소를 고려해야 합니다. 동시에 추가 개발 계획은 귀하의 예측을 바탕으로 이루어질 것입니다.

평가가 제대로 나오지 않으면 어떻게 되나요?

개발자가 최종적으로 소요될 것보다 작업에 더 많은 시간을 소비한다면 추정치가 매우 부정확하기 때문에 그가 최고의 전문가가 아닌 것처럼 보일 수 있습니다. 말하자면, 하늘의 손가락입니다. 동시에 개발자가 예상 시간에 투자하지 않으면 고객의 제품/새 기능 출시 계획이 위태로워집니다. 이것은 사업이고 사업은 돈을 의미하며 그러한 펑크를 좋아하는 고객은 거의 없습니다. 이것이 실제로 제가 추정을 좋아하지 않는 이유입니다. 때로는 작업을 완료하는 데 필요한 정확한 시간을 결정하는 것이 너무 어렵기 때문입니다.

시간은 어떻게 평가되나요?

일반적으로 추정은 시간 단위 또는 스토리 포인트 단위로 수행됩니다. 개인적으로는 스토리 포인트 평가 과정에 훨씬 더 가깝습니다 . 시계가 물리적인 것이라면 실수할 수 있는 것, 스토리 포인트는 좀 더 추상적인 것입니다. 일반적으로 소프트웨어 개발 팀은 시간, 일, 주, 월 등의 시간 형식으로 추정치를 제공합니다. 이러한 시간 추정은 주로 개인적인 경험, 추측 또는 직관에 기초합니다. 이 경우 개발자는 작업을 살펴보고 소요 시간을 추정하기만 하면 됩니다. 결과적으로 작업 완료 기한에 영향을 미칠 수 있는 요소가 너무 많기 때문에 정확하지 않은 경우가 거의 없습니다. 따라서 Agile 방법론에 따라 작업하는 많은 팀은 스토리 포인트를 사용합니다. 그것을 알아 봅시다.

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

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

• 시간 간격의 부정확한 추정을 피할 수 있습니다.
• 시간에 따른 추정과 달리 간접비는 팀 구성원과 고객 간의 커뮤니케이션, 다양한 팀 논의 및 계획, 예상치 못한 상황 등을 더 잘 고려할 수 있습니다.
• 각 팀은 서로 다른 척도에 따라 작업을 채점합니다. 즉, 속도(포인트로 측정)도 달라집니다.
• 각 스토리 포인트 할당 척도를 정의하면 큰 논란 없이 빠르게 포인트를 분배할 수 있습니다.

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

불행하게도 스토리 포인트는 종종 다른 목적으로 사용됩니다. 스토리 포인트가 사람을 평가하고, 상세한 기한과 자원을 정의하는 데 사용되며, 성과의 척도로 잘못 사용될 경우 결함이 있을 수 있습니다. 대신 팀은 이를 사용하여 각 작업의 작업량/복잡성을 이해하고 우선순위를 정해야 합니다. 스프린트가 끝나기 전에 완료할 수 있도록 더 어렵다고 평가된 부분을 먼저 수행해야 할 수도 있지만, 쉬운 부분은 나중에 다시 미룰 수 있습니다. 스크럼 방법론 의 맥락에서 스프린트가 무엇인지 상기시켜 드리겠습니다 . 이 기간은 개발 초기에 팀과 고객 간의 합의에 의해 결정됩니다. 이는 2주, 한 달 또는 기타 기간이 될 수 있습니다. 일반적으로 작업 추정은 완료된 작업이 고객에게 전달되는 스프린트 종료까지 완료 가능한 작업량을 계획하기 위해 스프린트 시작 시 수행됩니다. 이는 제품 개발 진행 상황을 확인하고, 고객으로부터 피드백을 받고, 고객의 비전에 따라 프로젝트 개발을 조정하는 데 도움이 됩니다. 하지만 여전히 우리는 약간 빗나갔습니다. 추정으로 돌아가 보겠습니다. 단 한 명의 개발자가 작업을 평가하는 것은 너무 주관적입니다. 따라서 원칙적으로 이것은 팀 작업입니다. 팀 평가에는 몇 가지 기술이 있습니다. 오늘 우리는 그 중 가장 많이 사용되는 스크럼 포커( Scrum poker)를 살펴보겠습니다 . 이 기술을 사용하려면 이 스크럼 포커 의 리더와 같은 관리자가 필요합니다 . Scrum Master 또는 PM을 전문으로 하는 사람이 될 수 있습니다 .

스크럼 포커란?

스크럼 포커 (또는 플래닝 포커)는 합의 도달을 기반으로 하는 평가 기술입니다. 주로 앞으로의 작업의 복잡성이나 소프트웨어 개발 중에 해결해야 할 작업의 상대적인 양을 평가하는 데 사용됩니다. 스크럼 포커는 개발 과정에서 일반적인 관행이며 이것이 어떤 종류의 짐승인지 확실히 알아야 한다는 점을 바로 지적하겠습니다 . 이 프로세스를 위해 우리는 일반적으로 특정 작업에 대한 팀 평가를 구성할 수 있는 일종의 애플리케이션이나 웹사이트를 사용합니다. 어떻게 이런 일이 발생하나요? 팀은 백로그 항목(새 작업, 기능)을 선택하고 이와 관련된 가능한 함정 및 기타 미묘한 차이에 대해 간략하게 논의합니다. 그런 다음 각 참가자는 자신의 난이도 등급을 나타내는 숫자가 있는 카드를 선택합니다. 아, 그리고 추정할 때 흔히 사용하는 수열이 아닌 피보나치 수열을 사용합니다 . 피보나치 수는 스크럼 포커 에서 매우 인기가 있습니다. 그 이유는 시간이 지남에 따라 숫자 사이의 간격이 커지기 때문입니다(피라미드 수준을 연상시킵니다). 엄청나게 복잡하고 적은 수의 스토리 포인트를 달성할 수 없는 작업이 있습니다. 특이한 카드에 대한 설명:

알 수 없는 끝점 수

무한히 긴 작업

쉬고 싶어

좀 더 드문 추정 방법:

• 티셔츠 사이즈 - S, M, L, XL
• 또는 개 - 치와와, 퍼그, 닥스훈트, 불독 등(제 생각에는 이것은 작업을 평가하는 가장 이상한 단위입니다 =D)

그런 다음 팀은 여러 개발자가 동일한 문제에 대해 제시한 추정치를 비교하고, 동의하면 좋습니다! 그렇지 않다면 평가(인론)의 차이가 발생한 이유를 논의할 필요가 있다. 그 후에 우리는 플러스나 마이너스 모두가 동의할 단일 추정에 공동으로 도달할 수 있습니다. 그렇다면 심각한 소프트웨어 프로젝트를 계획하는 데 포커가 사용되는 이유는 무엇일까요? 결국 이것은 왠지 이상합니다. 실제로 이러한 게임화는 팀원들이 독립적으로 생각하고 팀원들과 동시에 결과를 보여주도록 장려합니다. 이는 결국 다른 팀 구성원의 견해에 의존하는 것을 방지합니다. 그렇지 않으면 경험이 부족한 개발자는 경험이 많은 팀 구성원의 평가를 보고 의존하게 되며, 이는 자신의 평가의 유용성을 무효화하게 됩니다. 그러나 결과가 동시에 공개되면 이는 본질적으로 불가능합니다. Scrum Poker 일정 앱의 예는 Atlassian에서 제공됩니다 .

과제 평가의 예

팀에서 스토리 포인트 평가를 위한 특정 척도를 식별했다고 가정해 보겠습니다. Scrum Poker는 작업으로 시작 하고 다음과 같이 평가합니다.

• 이전에 유사한 기능을 구현한 적이 없습니다. - +3
• 중간 규모 작업의 기능 - +2
• 작업 구현이 매우 복잡합니다. - +3
• 이 기능에 대한 테스트 작성이 매우 복잡함 - +3

결과적으로 당신은 11개의 스토리 포인트를 얻지만 그러한 카드가 없기 때문에 13을 제공합니다. 다른 동료가 작업을 평가합니다.

• 전에도 비슷한 문제를 겪었습니다 - +1
• 중간 규모 작업의 기능 - +2
• 작업 구현의 평균 복잡성은 +2입니다.
• 이 기능에 대한 테스트 작성의 평균 복잡성 - +2

결과적으로 그는 7개의 스토리 포인트를 얻지만 피보나치 수에는 그런 것이 없으며 가능한 가장 가까운 숫자인 8의 카드를 놓습니다. 이에 따라 다른 팀원들은 주관적인 견해를 바탕으로 추정치를 제공합니다. 다음으로, 결과를 보여주고 8점을 준 한 개발자를 제외하고 거의 모든 동료가 13점을 주었다는 것을 발견했습니다. 이 경우 그에게 최저점을 주고 이유를 제시합니다. 예를 들어 그들은 다음과 같습니다. 그는 이전에 동일한 문제로 작업했는데 생각보다 어렵지 않았고 결국 나머지 팀원들에게 솔루션을 13에서 8 스토리로 변경하도록 설득했습니다. 이 일을 맡은 사람은 누구든지 도와주겠다고 말하면서 알아낼 것입니다. 아니면 결국 그는 스스로 그것을 할 것입니다. 그리고 일반적으로 다른 사람들이 그의 주장을 듣는지 여부는 중요하지 않습니다. 어떤 식 으로든이 작업에 등급이 지정되고 팀은 다음 작업에 익숙해지기 때문입니다. 처음에는 추정치가 정확하지 않을 것이며 다음 기간(스프린트) 동안 수행할 작업량에 대한 추정치도 부정확할 것입니다. 결국 이러한 추정은 추정을 바탕으로 정확하게 이루어집니다. 약 3개월 정도 시간이 지나면 팀은 작업을 더 정확하게 추정하기 시작하고 팀이 스프린트당 완료할 수 있는 평균 작업량이 표시됩니다. 그러나 이는 작업 범위에 대한 일반적인 계획이며 시간에 관한 것이며 이 경우 영향을 미치는 다양한 요소가 있을 수 있습니다. 예를 들어, 개발자 중 한 명이 2주 동안 휴가를 떠났습니다. 즉, 일정량의 계획된 작업(계획된 기능)을 지워야 합니다. 또는 새로운 개발자가 팀에 왔지만 그에게 전적으로 의존할 필요는 없습니다. 왜냐하면... 온 보딩 이라고 하는 프로젝트에 적응하는 데 필요한 시간을 고려해야 합니다 . 프로젝트의 복잡성에 따라 2주 정도 걸릴 수도 있고 일주일 정도 걸릴 수도 있습니다. 오늘은 그게 전부입니다. 문제 추정과 같은 비기술적 지식 부분에 대한 지식이 약간 향상되었으면 좋겠습니다. 이 주제와 스크럼의 세부 사항에 대해 더 깊이 알고 싶다면 Jeff Sutherland가 쓴 "SCRUM"이라는 책을 읽어 보시기 바랍니다. 결과에 대해서는 장담할 수 없습니다. 아마도 그 후에는 스크럼 마스터가 되고 싶은 성가신 욕망을 갖게 될 것이기 때문입니다. =D