애자일 환경에서 대규모 프로젝트에 대한 견적 제공
저희 회사는 처음으로 대규모 개발 프로젝트 문의를 받았으며 애자일 프로세스를 사용하고 싶습니다. 클라이언트는 응용 프로그램에 대한 비전을 가지고 있지만 요구 사항이 거의 없음을 공개적으로 인정하고 시간 단위로 요금을 청구해야 함을 인식합니다. 이 때문에 나는 애자일 접근 방식으로 그를 팔았습니다.
문제는 그가 예산을 책정하기를 원한다는 것입니다. 나는 고객이 그 숫자에 대한 예산을 책정하고 요구 사항이 변경 되더라도 머리와 책의 숫자는 그렇지 않기 때문에 견적을 포기하는 것에 대해 거의지지하는 많은 기사를 읽었습니다.
계약에서 가격 책정을 고려하는 여러 가지 방법이 있지만 거의 모든 방법 (하나만 저장)에는 선행 번호가 포함되어 있습니다. 이것은 Agile 개발의 전체 원칙을 위반하는 것 같습니다.
제 질문은, 만약 당신이 애자일 샵이라면이 애자일 개발의 Catch-22를 어떻게 피할 수 있을까요?
여기에 근본적인 질문이 있습니다.
클라이언트는 언제 완료되었다고 생각합니까?
그들이 6 월까지 끝날 것이라고 생각한다면, 당신은 애자일 팀을 배치합니다. 6 개월 동안 4-6 명입니다. 그것이 예산입니다. 본질적으로, 당신은 그들을 위해 곱셈을합니다. 팀 * 요금 * 6 개월.
대부분 6 월까지 완료 될 것이라고 생각하지만 그 이후에 더 많은 작업이있을 것이라고 생각한다면 아마도 9 개월의 작업을 고려하고있을 것입니다. 다시 말하지만, 당신은 그들이 스스로 할 수있는 곱셈을하는 것입니다. 팀 * 요금 * 9 개월.
가까운 미래에 당신이 개발팀이 될 것이라고 생각한다면 연말까지 프로젝트를 완료 할 수있는 가격을 제시하십시오. 팀 * 요금 * 12 개월.
각 릴리스의 우선 순위는 다시 지정할 수있는 기회이기 때문에, 당신은 당신이하는 일에 따라 작품의 개별 조각처럼 각 릴리스 가격 책정해야 합니다 해당 릴리스에 끝내야합니다. 우선 순위 체계이기 때문에 구축하는 것을 제어하고 단계별로 예산을 제어합니다.
종종 클라이언트는 특정 기능 세트의 비용이 얼마나되는지 알고 싶어합니다. 대신에 전체 예산에 대해 질문합니다 (어리 석음). 첫 번째 릴리스에서 얻을 수있는 내용과 첫 번째 릴리스의 비용을 보여주는 데 많은 시간을 할애하십시오.
결국 그들은 근본적인 진실을 보게 될 것입니다.
그들은 가장 중요한 것부터 가장 중요하지 않은 것까지 기능을 구매하고 있습니다 . 우선 순위를 올바르게 정하면 언제든지 돈을 쓰지 않고 유용한 것을 가질 수 있습니다.
완료는 상대적인 용어입니다. 더 이상 돈이 없기 때문에 일부 프로젝트는 "완료"되었습니다. 다른 것들은 더 이상 시간이 없기 때문에 이루어집니다. 드물게 (적어도 소프트웨어 개발에서) 할 일이 없어서 한 프로젝트가 아닙니다.
이 상황에서 우리는 첫 번째 작업 청크에 대한 추정치를 제공 한 다음 클라이언트가 원하는 수준으로 작업을 완료하는 데 필요한만큼 더 많은 스프린트를 구매할 수 있도록했습니다.
시스템을 더 많이 개발하고 클라이언트의 피드백을 스프린트 결과물에 통합하면 관련된 작업량과 관련 비용에 대해 더 나은 느낌을 받게됩니다.
편집 : 멋지다. 훌륭합니다! Agile 접근 방식, BTW good one!로 판매했다는 사실에서, 구현할 기능 측면에서 민첩한 관점에서 접근하는 것을 볼 수있을 것입니다. 이 " Intro to Scrum "팟 캐스트를 들어보십시오. 그들이 지금 당장 필요하다고 생각하는 모든 종소리와 휘파람을 가질 필요가 없을 것이라는 사실에 그들을 팔 수 있습니다.
HTH
건배,
Rob
여기에 핵심 사실이 있습니다. 비용을 추정하고 특정 배송 날짜에 대한 계약을 체결하고 전체 제공 기능 세트를 사용하도록 요청합니다.
세 가지를 모두 할 수는 없습니다.
"해서는 안되는"또는 "하지 않는 것이 현명 할 것"이 아닙니다. 당신은 (모든 실용적인 목적을 위해) 할 수 없습니다. 즉,이 세 가지를 모두 성공적으로 수행 할 확률은 극히 적습니다.
가장 좋은 대답은 비용과 일정, 그리고 빠른 반복과 정기적 인 피드백을 통해 반복적 인 프로세스에 전념 한 다음 , 고정 된 비용과 일정과 는 관계없이 수행되는 작업 이 전달 되도록 계약서를 작성하는 것입니다. 즉, 시간과 비용이 다 떨어질 때까지 새로운 기능 (및 수정)을 계속 제공합니다.
사실, 세 가지 모두에 가입 하더라도, 당신 이 할 수있는 최선은 어쨌든 세 명 중 두 명입니다. 그것에 대해 공개 할 수도 있습니다.
최근에 내가 아는 딱딱한 늙은 정부 계약자가“매춘부들이 말했듯이 먼저 그들을 위층으로 가져와야한다”고 표현한 방법입니다.
그것은 귀하의 질문에 대한 답은 아니지만 기억할 가치가 있습니다. 그들이 번호없이 위층으로 올라 오지 않는다면 (그리고 그렇지 않을 것입니다), 그들에게 번호를 주어야합니다.
소프트웨어 프로젝트를 후원하는 사람은 누구나 투자 할 가치가 있는지 여부를 평가할 수 있도록 투자에 대해 어떤 종류의 수익을 얻을 것인지에 대한 아이디어가 있어야합니다. 비용이 100 만 달러이고 12 개월이 걸리면 프로젝트를 수행 할 가치가 있습니다. 비용이 2 백만 달러이고 24 개월이 걸리면 가치가 없을 수 있습니다.
진짜 질문은 : 고객이 적절한 투자 수익을 실현할 수 있도록 시간 프레임과 예산 내에서이 프로젝트를 수행 할 수 있습니까? 그 질문에 대한 당신의 대답이 "예"가 아니라면, 그들은 당신을 고용하여 프로젝트를 수행해서는 안됩니다. 그렇지 않으면 그들은 단지 돈을 쓰고 주사위를 굴릴뿐입니다.
해당 질문에 대한 현재 답변이 "아직 알 수 없음"이면 프로젝트를 수행하도록 귀하를 고용해서는 안됩니다. 하지만 그렇다고해서 프로젝트가 가치가 있는지 확인하기 위해 당신을 고용해서는 안된다는 의미는 아닙니다. 이에 대한 좋은 컨설팅 회사의 유행어는 "예비 범위 지정 연습"입니다.
애자일 개발은 지출 된 비용, 달력 시간 및 기능 세트의 3 차원으로 곡선을 관리하는 것입니다. 예산과 일정이 고정 된 경우 기능 세트는 가변적이어야합니다. 이러한 제약 조건을 고려할 때 최종 기능 세트가 무엇인지 알 수 없습니다 . 하지만 당신은 할 수 있는지 알고 당신이 그 제약 조건 내에서 생산할 수있을거야 기능 세트는 클라이언트가 허용 찾을 수있는 범위 내에서 떨어진다.
당신은 이것을 알고 그것을 찾을 수 있습니다. 그것을 알아내는 것은 회사가 할 수있는 일이고 고객은 할 수없는 일입니다. 그것은 당신이 그들에게 제공 할 수 있고 그들이 당신에게 지불해야하는 서비스입니다. 무료로이 작업을 수행하려는 유혹을 피하고이를 판매 비용이라고 부릅니다. 프로젝트 범위 지정은 소프트웨어 개발만큼이나 전문 서비스의 일부입니다. 판매를 성사시키기 위해 이렇게하는 것이 아닙니다. 고객이 아직 충분한 정보를 가지고 있지 않은 비즈니스 결정을 내리는 데 도움이됩니다.
하지만 먼저 그들을 위층으로 데려 와야합니다.
이 답변은 정말 훌륭합니다. 공유 할 경험이 많지는 않지만 비유를 생각했습니다.
작년에 아내와 저는 부엌을 리모델링했습니다. 계약자는 추정치를 제공하는 대신 시간 및 자재에 대한 청구를 제안했습니다. 우리는 배관, 바닥 바닥 손상 등과 관련하여 무엇을 발견할지 몰랐기 때문입니다. 저는 집에서 일하고 있고 질문에 지속적으로 답변 할 수 있었기 때문에 동의했습니다. 계약자와 나는 좋은 관계를 가지고 있었기 때문에 무언가가 떠오르면 그는 자유롭게 내 사무실 문을 두드리며 우리는 그것에 대해 논의했습니다. 신속하게 결정을 내렸고 내가 원하는 방식으로 작업이 이루어졌습니다. 이는 빈번한 고객 리뷰 에 대한 애자일 우선 순위와 유사합니다 .
반대로 아내의 사촌도 집을 리모델링하고 있습니다. 그는 응급실 의사이며 리모델링하는 동안 현장에서 사용할 수 없습니다 . 그래서 그는 계약 업체가 그와상의하지 않고 주요 결정을 내리는 것에 대해 정기적으로 놀란다고 설명했습니다 ( "뭐? 나는 그 그림 창이 막히고 싶지 않았어요! 벽을 뜯어 내고 창문을 원래대로 재구성하세요!"). 이것은 물론 고통스럽게 비싸고 일정을 물 밖으로 날려 버립니다. 확실히 애자일이 아닙니다.
따라서 시간 및 자료 모드가 작동 할 것이라고 클라이언트를 설득하는 한 가지 방법은 피드백을 받기 위해 진행 상황을 자주보고하도록하는 것입니다. 이것은 이미 대부분의 Agile 방법론의 핵심 권장 사항이라고 생각합니다. 물론 시작하려면 고객이 컨설턴트에게 신뢰를 주어야합니다.
별도의 리소스 로 Mike Cohn의 " Agile Estimating and Planning " 이라는 주제에 대한 책을 검색하고 찾았습니다 . 해당 페이지에서 인상적인 Agile 전문가들의 칭찬 인용문을 읽어보십시오.
우선 애자일 접근 방식과 시간당 가격 책정을 그에게 팔아 주셔서 감사합니다. 그것은 매우 어렵습니다.
딜레마에 관해서는 대략적인 가격 견적과 포함 된 기능 / 범위를 그에게 제시해야한다고 생각합니다. 개발 과정에서 범위 / 비용을 변경할 중요한 내용이 나오면 고객에게 "중단-이건 훌륭하지만 우리가 논의한 원래 범위를 변경한다는 것을 이해합니다."라고 고객에게 말합니다.
이 시점에서 클라이언트는 동의하고, 원래 생각했던 것보다 더 많은 비용을 지불 할 것이라는 것을 인식하거나, 현재 새로운 개발을 중단 할 수있는 특권이 있습니다. 많은 애자일 프로젝트는 많은 미니 스테이지로 구축되어 가격 / 시간을 매우 정확하게 예측할 수 있습니다. 새로운 미니 스테이지가 시작되기 전에 귀하와 고객이 다음 작업과 이에 소요되는 시간 / 비용을 눈으로 확인하는 것이 중요합니다.
항상 그렇듯이 주요 매개 변수 인 품질, 기능 및 시간 (= 자원)이 있습니다. 우리는 더 이상 품질을 망치지 않기 때문에 기능과 리소스 만 남았습니다. 일정량의 리소스가 최소한 특정 기능 세트에 도달 할 것이라고 확신하는 경우가 종종 있습니다. 그럴듯한 기능 세트를 제공하는 리소스를 찾을 수있는 한이 정도면 상당수의 고객에게 충분하다고 생각합니다. 장점은 이동 중에 진행 상황을 제어 할 수 있으며 항상 취소 할 수있는 옵션이 있다는 것입니다.
이 작업을 수행 한 방법은 현재 속도를 사용하고 대략적인 복잡성 (스토리 수) 추정치를 기반으로 범위를 추정하는 것입니다. 범위 추정이 점차 더 좋아지고 더 좋아 지도록 애플리케이션 계획을 시작할 때이를 업데이트합니다.
예를 들어 6mos에서 2 년까지의 추정치를 제공합니다 (2 년 미만의 시간이 소요될 것이라고 확신하는 경우. 기능으로 분류 한 다음 해당 기능에 대한 계획을 세울 때 더 좋고 더 나은 추정치를 얻을 수 있습니다. 6mos 이후에 (다른 변경 사항이없는 경우) 확실하게 말할 수 있습니다. 2 ~ 3 개월 (총 8 ~ 9 개월) 후에 완료됩니다. 결국에는 다음과 같이 말할 수있는 지점에 도달합니다. 다음 반복 (2 주 ~ 1 개월) 후에 완료됩니다.
기능을 추가하면 완료까지 걸리는 시간이 늘어난다는 사실을 고객에게 알리는 것과이를 쌍으로 연결 한 다음, 기능을 삭제하거나 시간을 늘리는 등 진행 방법을 결정하도록해야합니다. 주어진 프로젝트에서 범위와 시간은 실제로 효과적으로 변경할 수있는 유일한 변수입니다. 품질과 자원은 거의 고정되어 있습니다. 실제로 리소스를 추가 할 수 있지만 일반적으로 초기에는 시간이 증가하고 품질이 저하되므로 시간이 긴 경우에만 작동합니다.
취할 수있는 한 가지 접근 방식은 고객에게 비교적 가깝다고 생각하는 일반적인 추정치를 제공하는 것입니다. 또한 백분율을 제공하십시오. 비율은 요구 사항 변경으로 인해 예산 할당량을 늘리거나 줄입니다.
예 : $ 10,000의 일반적인 추정치이지만 요구 사항이 모호하고 프로젝트가 코스를 쉽게 변경할 수 있기 때문에 +/- 30 % 가격 조정 옵션이 있습니다.
이렇게하면 클라이언트가 예산에 대한 일반적인 아이디어를 얻을 수 있고 프로젝트에 대한 비용을 유연하게 청구 할 수 있습니다.
이것은 정말 어려운 문제입니다. Robert Glass가 그의 저서 " Fact and Fallacies of Software Engineering (소프트웨어 엔지니어링의 사실과 오류) "에서 주제에 대해 무엇을 말하고 있는지 확인하십시오 . ( Amazon은 중고 책보다 적은 가격으로 새로운 책을 구입할 수 있습니다. [2009-01-05 12:20 -08 : 00 기준]; Google 도서에서도 구입할 수 있습니다. )
고객에게 Agile 접근 방식을 성공적으로 판매하고 시간 단위로 청구 했다면 프로젝트를 완료하는 데 드는 비용을 예상하지 마십시오! . 예산 목적으로 만 원한다고해도 하지 마세요! .
그 이유는 비용 추정치가 확실한 약속으로 취급되기 때문입니다. 그렇지 않다고 몇 번이나 고객이 그것을 이해한다고 몇 번이나 말하더라도 그것은 약속으로 취급 될 것입니다. 고객이 이해하더라도 상사는 이해하지 못하며, 말한 가격에 대해 법적으로 강요 할 수는 없지만 약속 한 것을 제공하지 않는 회사로 알려질 것입니다. 추정치를 제공하면 애자일의 모든 이점이 사라집니다.
내가 제안하는 것은 회계 연도가 끝나기 전에 (또는 고객이 관심을 갖는 다른 청구 기간) 그러한 금액 이상을 지출하지 않을 것이라고 말하는 것입니다. 프로젝트가 그때까지 완료 될 것이라는 말없이 재정적으로 계획하기에 충분할 것입니다.
이것은 나의이었다 대답 A와 폐쇄 형 질문 의 이야기 점과 관련. 나는 이것을 매크로 추정에 항상 사용합니다.
포인트로 전환했을 때 다음 두 가지 포인트를 충족 할 수있을 때만 결정했습니다. 1) 스위치를 정당화하고 팀을 설득 할 수있는 인수를 찾아서 주장하십시오. 2) 사용하기 쉬운 방법을 찾으십시오.
설득력 있는
이 주제에 대해 많이 읽어야했지만 마침내 저와 제 팀을 설득 한 주장을 발견했습니다. 작업에 걸리는 시간에 동의하는 두 명의 프로그래머를 찾는 것은 거의 불가능하지만 같은 두 명의 프로그래머는 거의 항상 동의합니다 두 개의 다른 작업이 표시 될 때 가장 큰 작업입니다.
백 로그를 '추정'하는 데 필요한 유일한 기술입니다. 여기서는 '추정'이라는 단어를 사용하지만이 초기 단계에서는 백 로그를 힘든 것에서 쉬운 것으로 주문하는 것과 비슷합니다.
백 로그에 포인트 넣기
이 단계는 전체 스크럼 팀의 참여로 수행됩니다.
다음 순서를 유지하면서 새 스프레드 시트에 스토리를 하나씩 놓으십시오. 가장 큰 스토리는 맨 위에 있고 가장 작은 것은 맨 아래에 놓으십시오. 모든 이야기가 목록에있을 때까지 그렇게하십시오.
이제 그 이야기에 요점을 둘 때입니다. 개인적으로 저는 Poker Planning Scale (1 / 2,1,2,3,5,8,13,20,40,100)을 사용하므로이 예제에서 사용할 것입니다. 목록의 맨 아래에는 미세 작업이있을 것입니다 (수행하는 데 4 시간 이하 소요되는 작업). 모든 마이크로 작업에 1/2의 가치를 부여하십시오. 그런 다음 스토리가 훨씬 더 크다는 것이 분명해질 때까지 (1 대신 2이므로 2 배 더 큼) 스토리에 값 1 (척도에서 다음)을 제공하여 목록을 계속 올립니다. 이제 값 '2'를 사용하여 2가 아닌 3이 분명하게 표시되어야하는 스토리를 찾을 때까지 목록을 계속하십시오.이 과정을 목록 맨 위로 계속하십시오.
참고 : 대부분의 포인트를 1과 13 사이로 유지하십시오. 처음에 큰 이야기 (20, 40, 100)가 많이있을 수 있으며 13보다 작거나 같은 덩어리로 나누어야합니다. .
그것은 포인트와 원래 백 로그에 대한 것입니다. 새로운 이야기가 있다면 그 목록과 비교하여 그것이 맞는지 (크거나 작은 프로세스) 확인하고 이웃의 가치를 부여하십시오.
속도 및 추정 (매크로 계획)
백 로그를 처리하는 데 걸리는 시간을 추정하려면 첫 번째 스프린트 계획을 수행하십시오. 팀이 고른 스토리에 첨부 된 총점을 확인하고 VOILA !, 이것이 첫 번째 속도 측정입니다. 그런 다음 백 로그의 총 포인트를 해당 속도로 나누어 필요한 스프린트 수를 알 수 있습니다.
그 속도는 처음 2-3 번 스프린트에서 변하고 안정 될 것이므로 항상 그 값을 주시하는 것이 좋습니다.
'IT이야기' 카테고리의 다른 글
| Immutable.js 레코드에서 한 번에 여러 필드를 설정하는 방법 (0) | 2021.05.02 |
|---|---|
| 낮은 디스크 워터 마크 [?? %] 초과 (0) | 2021.05.01 |
| 불완전한 유형의 잘못된 사용 (0) | 2021.05.01 |
| 객체(트리)를 재귀적으로 반복 (0) | 2021.05.01 |
| 'super'키워드로 제네릭 경계 지정 (0) | 2021.05.01 |