차례:
소프트웨어 프로젝트 추정
Pixabay
소개
추정은 어렵습니다. 불행히도 그것은 또한 매우 필요합니다. 회사는 예상치를 사용하여 출시 일정을 계획하고, 고객에게 약속을하고, 제안 된 기능을 구현할 가치가 있는지 여부를 결정하고, 팀의 속도를 추적하고, 작업의 우선 순위를 효과적으로 지정합니다. 경영진은 종종 기능이나 결과물이 언제 생산 될 준비가되는지 알고 싶어합니다. 결국 소프트웨어 개발은 사소한 투자가 아닙니다. 예상치가 없으면 프로젝트 관리자는 어떻게 평가할까요? 인간이 미래를 정확하게 예측할 수 있다면 사람들은 2 %의 시간 동안 경마에서 이기지 못할 것입니다. 추정은 큰 수수께끼입니다. 기업은 직원들에게 불가능한 일, 즉 미래를 예측하도록 요청하는 것이 필수적이며 필요합니다.
먼저, 몇 가지 인기있는 추정 방법을 검토해 보겠습니다 (흥분을 놓친 경우). 그런 다음 이것이 우리와 우리의 프로젝트에 어떤 의미가 있는지 살펴볼 수 있습니다.
점쟁이 모델
이 모델은 견적을 생성하는 데 거의 노력이 필요하지 않습니다. 에스티 메이터는 기능을 구현하고 테스트하기 위해 수행해야하는 작업에 대해 약간 생각한 다음 숫자를 버립니다. "… (긴 멈춤)… 음… 6 주"처럼 들립니다. 그런 다음 모두 고개를 끄덕이고 계속 진행합니다. 그들은 요구 사항에 대해 알고있는 것을 이야기하면서 프런트 엔드에서 꽤 오랜 시간을 보낼 수 있습니다 (아마도 완전한 그림은 아닙니다). 이 세심한 분석은 그들의 추정치를 더 신뢰할 수있게 만듭니다. 프로젝트가 끝날 무렵에는 추정치가 현실과 너무 멀어진 이유에 대한 합리적 근거가 항상 있습니다. 희생양이 될 수있는 예상치 못한 상황이 항상 존재합니다. 모델에 심각한 결함이 있다는 사실은 누구에게도 발생하지 않는 경우가 많습니다.
그렇다면이 과정을 어떻게 개선 할 수 있을까요? 알아! 분해 기법 (즉, 분할 및 정복)을 사용할 수 있습니다. 이 접근 방식은 프런트 엔드에서 기능 또는 프로젝트의 전체 범위를 알고 있다고 가정합니다. 모든 기능은 한 입 크기의 청크로 나뉩니다. 각 청크를 추정 (점쟁이 스타일) 한 다음 전체 기능 / 프로젝트 추정치를 얻기 위해 추가합니다. 이것은 확실히 더 복잡한 접근 방식이지만 두 가지 이유로 더 나은 것 같습니다.
- 작업 덩어리가 작을수록 안정적으로 추정하기가 더 쉽습니다.
- 여전히 오류 (+/- 약간)의 기회가 있지만 모든 것을 더하면 오류가 서로 상쇄되고 전체적인 추정치를보다 신뢰할 수 있다는 가정이 있습니다.
이 접근 방식의 근본적인 결함은 개별 기여자 (실제로 작업을 수행하는 사람들)가 보편적으로 과소 평가한다는 것입니다. 그들은 여전히 위와 주변의 것보다 훨씬 낫지 만 높은 기준은 아닙니다. 개발자가 일정보다 빨리 무언가를 수행하여 스스로를 놀라게 한 사례를 모두 보았 기 때문에 이것은 그렇지 않은 것 같습니다. 그러나 이것은 추세가 아니라 단일 데이터 포인트입니다. 사람들은 실제로 카지노에서 때때로 이깁니다. 1 년 동안 매일 카지노에서 돈을 쓰면 처음보다 적은 돈을 벌게됩니다. 1 ~ 2 년 동안 추정치와 실제치를 추적하면 추정치가 현실에 미치지 못한다는 것을 알게 될 것입니다. 많은 기업가들은 개발자들이 자신의 추정치를 느리게 채우고 여분의 시간을 "금판"또는 주식 확인에 사용하고 있다고 절대적으로 확신하지만,데이터는 그렇지 않다는 것을 보여줍니다. "취소"전략은 작동하지 않습니다.
그래서, 이제 무엇입니까? 점쟁이 모델을 버리고 크기 기반 접근 방식으로 전환합시다. 인간은 완료 시간을 예측하는 데 꽤 끔찍하지만 실제로 우리는 무언가가 얼마나 큰지 말하는 데 꽤 능숙합니다. 우리는 특히 비교 크기 조정에 능숙합니다 ("그것보다 크지 만 저기있는 것보다 작습니다"). 시간이 아니라 크기 나 복잡성으로 생각하면 우리의 두뇌는 더 안정적으로 처리합니다. 그런 다음 크기 값을 가져와 멋진 마법 공식을 기반으로 프로젝트의 실제 시간을 계산할 수 있습니다! 그리고 그 때 인기있는 기능 포인트 모델이 장면에 등장합니다 (왼쪽 단계).
기능 점수 분석 (FPA)
기능 포인트 분석을 위해 애플리케이션에서 외부 입력, 외부 출력, 외부 쿼리, 외부 인터페이스 파일 및 내부 논리 파일의 다섯 가지 유형을 식별해야합니다 (정의에 대해 너무 걱정하지 마십시오. 나중에 조사 할 수 있음). 이들 (함수)의 각 예에는 관련 복잡성 (낮음, 평균 또는 높음)이 있습니다. 아래 표를 사용하여 각 기능이 할당되는 포인트 수를 파악합니다.
이제 모든 함수에 대한 점수를 더하면 프로젝트에서 457 개의 함수 점수와 같은 숫자를 얻을 수 있습니다. 그런 다음 시간 수를 계산하는 공식이 필요합니다. 마지막 프로젝트에 따르면 "배송 률"은 1 인당 월 15 기능 포인트였습니다. 그것은 대략 30 명의 사람이 일할 가치가 있습니다. 12 명으로 구성된 제 팀에게는 2 개월 반이 조금 넘게 걸릴 것입니다. 타다!
이것은 확실히 이전 모델보다 더 복잡합니다. 사실, 인식해야 할 4 가지 주요 복잡성 영역이 있습니다.
- 다섯 가지 구성 요소 유형이 반드시 직관적 인 것은 아니며 목록에 항목을 추가하거나 잘못된 버킷에 할당하는 것을 잊기 쉽습니다.
- 실제로 기능 포인트를 생성하는 데 사용되는 테이블에는 유효성 검사에 많은 노력이 필요한 매직 넘버가 포함되어 있습니다. 내 팀에 대한 신뢰할 수있는 추정치를 생성하기 위해이 수치가 올바르게 보정 되었습니까?
- 전달률 (퍼즐의 중요한 부분)은 팀의 생산성에 따라 계산됩니다. 새 숫자를 얼마나 자주 계산해야합니까? 실제로 이것에 대한 지침은 거의 없습니다.
- 낮음, 평균 또는 높음의 복잡성은 무엇입니까? 모든 사람이 이해할 수 있도록 어떻게 정의합니까? 정확한 계산이 계산의 정확성에 중요하지 않습니까?
이 매우 간단한 예에는 몇 가지 움직이는 부분이 있으며 더 복잡한 복잡성 모델과 작동 할 수있는 기타 데이터 (예: 비용 비율, 지원 속도, 결함 밀도 등)에 대해서는 논의하지 않았습니다. 움직이는 부품이 많을수록 오류가 발생할 가능성이 높아집니다. 지금 추정이 너무 복잡합니까? 추정에 많은 시간을 할애하는 데 개발자에게 비용을 지불하지 않습니다. 고객에게 견적을 판매 할 수 없습니다. 작동하는 소프트웨어가 필요합니다. 거기에 다른 것이 있습니까?
민첩하게
이제 애자일 스크럼을 간략하게 살펴 보겠습니다 (비교하기에 충분합니다). 앞서 언급했듯이 인간은 시간을 예측할 때 끔찍하며 비교 크기 조정에 능숙합니다. 이해해야 할 몇 가지 용어는 다음과 같습니다.
- 스프린트-타임 박스 기간 (보통 2 주).
- 사용자 스토리-스프린트에서 한 사람이 수행 할 수있을만큼 작은 개별 작업입니다. 이것이 우리가 추정하는 것입니다.
가장 많이 사용되는 전략은 추정을 위해 피보나치 수열 (0, 1, 2, 3, 5, 8, 13)을 사용하는 것입니다. 이것은 선형이 아닙니다. 스케일을 높이면 간격의 크기가 증가합니다. 중요한 점은 그 격차가 사소한 차이에 대해 논쟁 할 이유가 없을만큼 충분히 넓어야한다는 것입니다. 3을 초과하면 4와 5 또는 7과 8의 차이가 무시할 수 있으므로 어느 것이인지 해시하는 데 시간을 소비하는 것은 의미가 없습니다. base-2 시퀀스도 작동합니다 (0, 1, 2, 4, 8, 16 등).
“하지만 잠깐, 이것은 단지 숫자 일뿐입니다. 무슨 뜻이에요? 포인트는 몇 시간입니까?” 점수는 시간과 직접 연관되도록 의도 된 것이 아닙니다. 왜냐하면 만약 그들이 그렇게했다면 팀은 몇 시간 안에 추정으로 돌아가서 그것을 어떻게 든 점수로 전환하고 싶기 때문입니다. 앞서 논의한 바와 같이, 우리의 추정치의 정확성은 크기 비교에서 비롯되며 무언가에 걸리는 시간을 추정하지 않습니다. 팀에 시간 단위로 생각할 수있는 능력을 부여하면 정확한 추정 능력이 손상됩니다.
보정 연습을 시작했다고 가정 해 보겠습니다. 팀을 방으로 끌어와 10-12 개의 사용자 스토리 목록을 안내합니다. 작지만 가장 작지 않은 것을 선택하고 먼저 수행하십시오. 그것을 검토하고이 이야기가“3”이라고 발표하십시오. 당신은 요구하지 않습니다. 당신은 말하고 있습니다. 그런 다음 다음 이야기로 넘어갑니다. "3 점이라면 이건 뭐지?" 이제 팀은 다른 스토리와 비교하여 스토리의 크기를 조정합니다. 결국, 그들은 "1", "2"등을 구성하는 것이 무엇인지 꽤 좋은 아이디어를 갖게 될 것입니다. 그들은 추정하지 않습니다. 시간은 중요하지 않습니다. 이미 숫자가있는 다른 스토리와 비교하여 스토리의 크기를 조정합니다. 그런 다음 눈금자라는 문서에 시퀀스의 각 숫자에 대한 예제 스토리를 넣을 수 있습니다. "5"가 무엇인지 확실하지 않은 경우 참조로 사용할 수 있습니다.
이제 여기에 열쇠가 있습니다. 이 작업을 수행하는 마법 소스는 "속도"입니다 (팀이 스프린트에서 3-4 스프린트에 걸쳐 평균적으로 완료 할 수있는 포인트 수). 스프린트가 2 주이고 8 명으로 구성된 팀의 평균 속도가 35 포인트라고 가정 해 보겠습니다. 640 시간의 작업 (8 x 80 시간)으로 35 점을 달성합니다. 한 기능이 작업을 시작하는 데 약 100 포인트가 소요된다는 것을 알게되면 약 6 주 작업과 ~ 1900 시간이라는 것을 압니다. 팀은 일관되게 스토리 크기를 조정하는 데 매우 능숙하며이를 활용하여 프로젝트 계획을 수행합니다. 이 계산은 스프린트마다 지속 시간이 일치하기 때문에 작동합니다.
장기적인 높은 수준의 계획을 수행하기 위해 리드에게 높은 수준의 기능을 중간 한 줄짜리 스토리로 나누고 포인트 값을 부여하도록 요청할 수 있습니다. 어느 정도의 정확도가 손실되지만 이미 이해하고있는 모델을 활용하고 있습니다. 더 정확한 경로는 기능 수준에서 상대적 크기 조정입니다. "이 기능은 40 포인트 기능보다 크고 저기있는 120 포인트 기능보다 작으며 방금 수행 한 65 포인트 기능보다 약간 큽니다." 스토리는 "서사시"로 그룹화됩니다. 각 기능이 서사시라면 마지막에 해당 기능을 완료하는 데 걸린 포인트를 알 수 있습니다. 그 기록을 유지하고 릴리스 계획에 사용할 수 있습니다.
결론
오늘날 사용되는 방법론이 많이 있습니다. 각각 장단점이 있습니다. 어떻게 든 우리는 올바른 결정을 내릴 수 있도록 추정의 정확성을 최대화하는 방법을 알아 내야합니다. 그렇다고 우리 추정치가 정확해야한다는 의미는 아닙니다. 유용 할만큼 정확해야합니다. 추정을 이해하지 못한다면 팀이 좋은 일을하지 않았기 때문에 추정이 정확하지 않다고 가정 할 수 있습니다. 그들은 정확하게 추정하지 않았거나 프로젝트에서 올바르게 실행하지 않았습니다. 구타는 견적이 개선 될 때까지 계속됩니다. 그러나 추정치를 약속으로 사용해서는 안됩니다. 오늘날 우리가 가지고있는 제한된 정보를 기반으로 한 가장 좋은 추측입니다. 새로운 정보가 나오면 견적을 재검토해야합니다. 다른 것은 불가능을 기대하고 있는데, 이는 팀이 아닌 리더십의 문제입니다.
스크럼의 접근 방식은 기능 점수 분석에서 보는 것보다 훨씬 간단합니다. 그리고 매직 넘버가있는 매직 테이블보다 훨씬 더 신뢰할 수 있다고 말하고 싶습니다. 비용 대비 최대의 효과를 얻습니다 (합리적으로 높은 정확도로 최소한의 노력). 노력의 관점에서 보면 팀이 이해하고 사용할 수있는 무거운 프로세스를 생성하지 않습니다. 애자일의 추정 부분은 모든 사람이 추정되는 작업의 세부 사항을 이해하면 실제로 매우 빠르게 발생할 수 있습니다. 허공에서 숫자를 끌어내는 것보다 확실히 낫습니다. 속도를 활용하는 것은 매우 중요한 일을합니다. 이는 과거 데이터를 계산에 가져옵니다. 스프린트마다 속도를 다시 계산합니다. 시간이 지남에 따라 처리량이 변경되기 때문에 이는 매우 중요합니다. FPA를 사용하는 팀은 이전 프로젝트에서 제공 속도를 도출 할 수 있습니다.어떤 경우에는 몇 달 전이었습니다. 그 이후로 많은 것이 변했을 것입니다. 제 제안은 여러분이 애자일을 탐구하고 스토리 포인트와 속도를 이해하는 데 실제로 노력하는 것입니다. 그것이 당신이 이해하는 것이라고해서 몇 시간 안에 추정에 의존하지 마십시오. 나는 당신이 나중에 자신에게 감사 할 것이라고 믿습니다.