SE와 다른 사이트에서이 “민첩한 개발”관련 내용을 읽을 때 항상 궁금했던 점이 있습니다.
“전통적인”소프트웨어 엔지니어링에서는
- 사용자 요구 사항을 수집하고
- 이러한 요구 사항에 따라 사양을 작성하십시오.
- 고객에게 제공하고 지금까지 수행 한 작업에 대해 청구합니다.
- (거친) 기술 설계를 수행하여 구현 비용을 추정 할 수 있습니다.
- 사용자에게 구현에 대한 가격 견적을 제공합니다.
- 고객이 사양에 서명하고 제안을 수락 할 때까지 기다립니다.
- 설계, 구현, 테스트,
- 계산서.
프로세스가 진행되는 동안 요구 사항이 변경되면 원하는 변경 사항에 대한 제안 (가격과 함께)을 보내거나 변경이 작은 경우 무료로 제공하고 고객을 좋아하고 고객이 너무 자주하지 않는 경우) .
따라서 빈번한 요구 사항 변경이 프로세스의 일부인 애자일 프로젝트에서 어떻게 (재정적으로) 작동합니까?
- 모든 디자인 변경에 대한 제안을 작성하십니까? (이것은 엉망이 아닐까요?)
- 또는 고정 가격을 협상 하고 고객이 요구 사항을 너무 자주 변경하지 않기를 바랍니다 . (위험 할 수 있으므로이 기회를 사용하여 프로젝트 완료를 수락하기 전에 몇 년 동안 새로운 기능을 요청하는 고객을 알고 있습니다.)
- 아니면 필요한 총 시간을 고객에게 청구합니까? (사전 비용을 모르는 고객에게는 위험 할 수 있습니다.)
답변
이상적인 민첩한 세계에서는 선불 가격과 시간에 동의하지만 범위는 아닙니다 . 고객은 최소 유용한 제품이 아니라 그들이 진정으로 원하는 제품보다, 무엇을 결정하고, 그 추정한다 아니라 짧은 합의 된 시간 수의.
그런 다음 반복해서 전달하고 원하는대로 마음을 바꾸지 만 동의 한 시간을 초과하지는 않습니다. 이론적으로, 그리고 실제로는 실제로 원하는 제품이 아니라 실제로 필요한 제품이됩니다.
그리고 그들이 원래의 합의 된 가치 이후에 계속해서 당신에게 추가 시간을 지불하고 싶다면, 그것도 좋습니다. 스토리 카드, Greenhopper 등을 통해 진행 상황을 충분히 눈에 띄게 만들면 고객이 새로운 것을 추가 할 때마다 잃어버린 (또는 적어도 우선 순위를 낮추는) 기능을 고객에게 매우 명확하게 만들 수 있습니다. 경박 한 변화에 대한 중지.
여기서 주목할만한 두 가지 위험이 있습니다. 첫 번째는 민첩성을 미리 이해하지 못하면 고객이 겁을 먹을 수 있다는 것입니다. 그가 모든 위험을 감수하고있는 것 같습니다. 오직 경험 만이 그가 실제로 그렇지 않다는 것을 보여줍니다.
두 번째는 전체 과정에서 참여 해야 하며 그렇지 않으면 모든 사람이 패배하게됩니다. 많은 고객은 너무 늦을 때까지 얼마나 참여해야하는지 이해하지 못합니다.
그러나 당신이 회사로서 그것을 충분히 설명한다면, 모두가 승자입니다.
답변
일부 사람들 은 과거 고정 가격 프로젝트에서 민첩성을 사용할 수있는 솔루션 을 제공 하려고 시도 했습니다 . 개인적으로는 불가능하다고 생각합니다.
특히 스크럼은 제품 소프트웨어 회사에 적합 하며 서비스 회사에서는 덜 사용됩니다.
반복, 일일 스탠드 업, 번 도어 등과 같이 프로젝트에서 민첩성을 사용할 수 있지만 특정 가격으로 일정량의 물건을 제공하고 계약보다 적은 금액을 제공하면 문제가 생길 것입니다.
민첩성 les 소스를 제공하지 마십시오 . 주어진 문제에 대한 적절한 해결책을 사용해야합니다.
답변
이것은 실제로 Agile 프로그래밍 또는 사용하는 모델과 관련이 없습니다. 프리랜서로 일하면서 Waterfall과 V 모델을 혼합하여 사용했지만 여전히 같은 문제가 있습니다. 고객이 세부 설계 중에 무언가를 변경하려면 어떻게해야합니까? 구현하는 동안 그가 변경하면 어떻게됩니까?
사용해야하는 접근 방식은 고객과 관계에 따라 다릅니다.
고객이 할 수있는 시간에 지불하지 않거나, 가능할 때마다 당신을 고소하려한다는 사실을 알고 있기 때문에,이 고객을 위해해야 할 모든 일에 반드시 연락해야하는 사람이라면 요구 사항의 작은 변화. 엉망이 아닙니다. 잘 정리되어 있다면 개발 중에 새로운 요구 사항을 수용하기가 어렵지 않을 수 있습니다. 그러나 시간과 돈을 잃는다는 것은 확실하며, 구현하는 데 2 시간이 걸리는 변경 제안을 서명하는 것이 다소 이상합니다.
다른 고객의 경우 잘 작동하는 접근 방식은 다음과 같습니다.
-
첫 번째 오퍼에 서명 할 때 예상 비용과 최대 비용을 지정하십시오. 예상 비용은 합법적 인 것을 의미하지 않으며 단지 추정 일뿐입니다. 최대 비용은 합법적 가치가 있습니다. 고객에게 제품 비용이 3,000 달러이고 최종적으로 3,157.24 달러라고 말하면 고객은 여전히 3,000 달러를 지불해야합니다. 실제로 대부분의 경우 실제 비용은 주어진 최대 값보다 적으며 추정치에 더 가깝습니다.
-
고객이 요구 사항 변경을 요청하면 해당 비용을 추정하고 실제 비용 및 상태와 비교합니다. 제품을 거의 완성했으며 실제 비용이 $ 2,108.36이고 변경 비용이 $ 150로 추정되는 경우에는 그대로 두십시오. 반면 최대 값에 도달 할 위험이있는 경우 고객에게 전체 비용을 함께 재평가해야한다고 알립니다.
답변
애자일과 ‘제안 작성’은 반 추론처럼 보입니다. :)-후자는 생산적인 소프트웨어 엔지니어링이 아닙니다. : D
자, 이제 농담을 마치고 다시 실제 상황으로 돌아갑니다.
” 애자일 에서는 어떻게 작동 합니까?” -계약이 복잡하지만 명확하게하기를 바랍니다. 애자일은 ‘신뢰’와 ‘동역’이라는 원칙에 기반을두고 있습니다. 즉, 고객은 비용이 조금 더 들거나 비 침해적일 경우 추가 비용이 들지 않는다는 것을 언제 어디서나 변경할 수 있음을 이해합니다.
이것은 무엇을 의미 하는가? 계약은 우리가 (고객이) 초기 비용 추정치와 우리가 처리 할 수있는 +/- 편차 %를 수정한다는 것을 의미합니다. 계약의 일부이지만 고객을 염두에두고).
이제 설계 변경이 들어 오면 예측 및 계획에 민첩 해집니다. 팀을 구성하고 변경 요인을 계산하는 데있어 복잡하고 ‘스토리 포인트’견적을 요청하십시오. 일부 속도 추정치로 인해 속도를 곱하고 스케줄을 추정 할 수 있습니다. 팀과 상대 급여를 아는 경우 스토리 당 비용을 산출하는 것이 상대적으로 쉬워야합니다 (모든 직원의 평균 급여를 평균하지 말고 평균 결함에 굴복하십시오).
재무와 관련하여 고객에게 돌아 가야합니까? 아니. 반드시 그런 것은 아닙니다. 고객이 우선 순위를 정하고이를 백 로그의 올바른 위치에 삽입하게합니다. 백 로그의 크기 (아직 그렇지 않은 경우)를 알고 재정 (스토리 포인트 당 비용)을 기반으로 하여 주어진 예산으로 수행 할 수없는 우선 순위가 낮은 요구 사항을 알고 있습니다. $$ 계약에 따라 가능한 기능의 추정치와 함께 우선 순위가 지정된 백 로그를 표시하십시오. 그런 다음 그들이 도착했을 때 더 많은 돈을 지불 할 의사가 있는지 결정하도록하십시오. 그들이 무료로 원한다면 … 당신은 스탠드를 가지고 그들에게 더 많은 비용을 말할 것입니다.
고객이 볼 수있는 곳에이 그래프를 표시 할 수 있으면 재무 상태를 지속적으로 되 돌리지 않고도 도움이됩니다.
도움이 되었기를 바랍니다!
답변
다른 사람들의 경험은 아마도 다를 수 있지만, 내가 본 것을 본 한 가지 방법은주의해야 할 몇 가지 사항이있는 “전통적인”것과 거의 동일합니다.
- 변경을 위해 약간의 오버 헤드를 생성합니다 (예 : 10 %)
- 내장 된 비용을 넘어서 큰 변화를 평가하고 별도로 청구하거나 집계하고 청구합니다 (프로그래밍은 아니지만, 예를 들어, 초기 비용에 종종 3 개의 개정, 후속 개정 또는 총 재실행이 포함되는 설계 작업이 있습니다) 특별한)
종종 애자일 프로젝트는 “핵심”항목으로 시작하여 필요에 따라 모듈 방식으로 나선다 (필자는 관련 프로젝트에서 약간의 일이 발생 함). 따라서 핵심 제품부터 시작하여 매핑 응용 프로그램이라고 가정하겠습니다. 첫 번째 구현은 현재 위치 (고객이 처음 주문한 위치)를 중심으로하는지도 일뿐입니다.
그런 다음 고객은 주변의 특정 명소를 한 방울 떨어 뜨리기를 원합니다. 좋아, 그것은 꽤 큰 조각 (상대적으로 말하면)이므로 새로운 “모듈”또는 구매 주문으로 청구합니다. 해당 핀의 색상이나 디자인과 같은 변경 사항은 해당 주문 비용에 내장되어 있습니다. 길 찾기 및 오버레이는 다른 구매 주문이 진행된 후 등으로 요청되지 않았기 때문에 다른 구매 주문입니다.