민첩한 소프트웨어 개발 : 변화하는 사용자 요구 사항에 * 재정적으로 * 어떻게 대응합니까?


13

SE와 다른 사이트에서이 "민첩한 개발"관련 내용을 읽을 때 항상 궁금했던 점이 있습니다.

"전통적인"소프트웨어 엔지니어링에서는

  1. 사용자 요구 사항을 수집하고
  2. 이러한 요구 사항에 따라 사양을 작성하십시오.
  3. 고객에게 제공하고 지금까지 수행 한 작업에 대해 청구합니다.
  4. (거친) 기술 설계를 수행하여 구현 비용을 추정 할 수 있습니다.
  5. 사용자에게 구현에 대한 가격 견적을 제공합니다.
  6. 고객이 사양에 서명하고 제안을 수락 할 때까지 기다립니다.
  7. 설계, 구현, 테스트,
  8. 계산서.

프로세스가 진행되는 동안 요구 사항이 변경되면 원하는 변경 사항에 대한 제안 (가격과 함께)을 보내거나 변경이 작은 경우 무료로 제공하고 고객을 좋아하고 고객이 너무 자주하지 않는 경우) .

따라서 빈번한 요구 사항 변경이 프로세스의 일부인 애자일 프로젝트에서 어떻게 (재정적으로) 작동합니까?

  • 모든 디자인 변경에 대한 제안을 작성하십니까? (이것은 엉망이 아닐까요?)
  • 또는 고정 가격을 협상 하고 고객이 요구 사항을 너무 자주 변경하지 않기를 바랍니다 . (위험 할 수 있으므로이 기회를 사용하여 프로젝트 완료를 수락하기 전에 몇 년 동안 새로운 기능을 요청하는 고객을 알고 있습니다.)
  • 아니면 필요한 총 시간을 고객에게 청구합니까? (사전 비용을 모르는 고객에게는 위험 할 수 있습니다.)

5
차이점은 "자주 요구 사항 변경이 프로세스의 일부"라는 것이 아니라 프로세스에서 명시 적으로 인정되는 부분이라는 것입니다.

답변:


13

이상적인 민첩한 세계에서는 선불 가격과 시간에 동의하지만 범위는 아닙니다 . 고객은 최소 유용한 제품이 아니라 그들이 진정으로 원하는 제품보다, 무엇을 결정하고, 그 추정한다 아니라 짧은 합의 된 시간 수의.

그런 다음 반복해서 전달하고 원하는대로 마음을 바꾸지 만 동의 한 시간을 초과하지는 않습니다. 이론적으로, 그리고 실제로는 실제로 원하는 제품이 아니라 실제로 필요한 제품이됩니다.

그리고 그들이 원래의 합의 된 가치 이후에 계속해서 당신에게 추가 시간을 지불하고 싶다면, 그것도 좋습니다. 스토리 카드, Greenhopper 등을 통해 진행 상황을 충분히 눈에 띄게 만들면 고객이 새로운 것을 추가 할 때마다 잃어버린 (또는 적어도 우선 순위를 낮추는) 기능을 고객에게 매우 명확하게 만들 수 있습니다. 경박 한 변화에 대한 중지.

여기서 주목할만한 두 가지 위험이 있습니다. 첫 번째는 민첩성을 미리 이해하지 못하면 고객이 겁을 먹을 수 있다는 것입니다. 그가 모든 위험을 감수하고있는 것 같습니다. 오직 경험 만이 그가 실제로 그렇지 않다는 것을 보여줍니다.

두 번째는 전체 과정에서 참여 해야 하며 그렇지 않으면 모든 사람이 패배하게됩니다. 많은 고객은 너무 늦을 때까지 얼마나 참여해야하는지 이해하지 못합니다.

그러나 당신이 회사로서 그것을 충분히 설명한다면, 모두가 승자입니다.


2
애자일은 실제로 고객 경험과 기대를 관리하는 데 중점을 둡니다. 마감일까지 몇 가지 기능을 효과적으로 작성하더라도 고객은 프로젝트 종료시 필요한 것을 얻는다는 점을 분명히하는 것이 중요 합니다. 핵심은 계약서 내에 특정 세부 사항을 너무 많이 지정하지 말고 계약서에 문구를 작성하여 고객이 마음을 바꾸는 것이 결과적으로 제공 할 수있는 것보다 더 많은 것을 얻는다는 것을 의미하지는 않는다는 데 동의합니다. 계약에 서명하기 전에도 고객 참여가 필수적입니다.
S.Robins

+1-첫 번째 단락은 애자일이 당신에게 줄 수있는 것에 대한 간결하고 간결한 설명입니다. "두 번째는 그들이 참여해야한다는 것"또한 매우 중요합니다.
ozz

구하기 힘든 목표는 나쁜 평가를 수행 할 때, 추가 시간을하는 사람들을 중지하고 반복 / 스프린트 목표를 달성하는 것입니다. 우리가이 나쁜 연습을 할 때마다 가짜 속도로 끝납니다. 그렇기 때문에 첫 번째 단락에서는 목표가 작동하고 최선을 다하며 일정 시간 동안 필요에 따라 범위를 조정하는 것임을 알고 시간을 어떻게 관리해야하는지 설명하기 때문에이 답변에 투표합니다.
Lorenzo Solano

이는 민첩한 프로젝트 계약 유형이 고정 가격이되어서는 안된다는 것을 의미합니까?
Ben Cheng

4

일부 사람들 은 과거 고정 가격 프로젝트에서 민첩성을 사용할 수있는 솔루션 제공 하려고 시도 했습니다 . 개인적으로는 불가능하다고 생각합니다.

특히 스크럼은 제품 소프트웨어 회사에 적합 하며 서비스 회사에서는 덜 사용됩니다.

반복, 일일 스탠드 업, 번 도어 등과 같이 프로젝트에서 민첩성을 사용할 수 있지만 특정 가격으로 일정량의 물건을 제공하고 계약보다 적은 금액을 제공하면 문제가 생길 것입니다.

민첩성 les 소스를 제공하지 마십시오 . 주어진 문제에 대한 적절한 해결책을 사용해야합니다.


하지만이 가능합니다 vraiment을 ) 소프트웨어 개발 팀의 클라이언트가 내부 응용 프로그램 관리자 (들)보다는 회사의 클라이언트 인 경우 작동 할 수있는 고정 가격 계약의 경우. 소프트웨어 개발자는 응용 프로그램 관리자 및 비즈니스 분석가에게 사용자 사례를 제공하고 고객을 대신하여이를 수용하고 있습니다. 회사가 잘못 관리되고 계약을 충족하지 않으면 프로젝트 범위와 계약 요구를 전달하지 않았기 때문에 소유주가 해당 개인에게 있습니다.
maple_shaft

1
@maple_shaft : 그렇습니다. 실제로 가능하고 재 지정되었습니다. 내가 추가 한 링크는 그것이 효과가 있다고 주장하는 사람들의 링크입니다. 그러나 고객은 이러한 방식으로 작업을 수행해야합니다 (고정 가격 및 시간에 대한 범위 또는 불확실한 가격 및 시간에 대한 특정 범위).

3

이것은 실제로 Agile 프로그래밍 또는 사용하는 모델과 관련이 없습니다. 프리랜서로 일하면서 Waterfall과 V 모델을 혼합하여 사용했지만 여전히 같은 문제가 있습니다. 고객이 세부 설계 중에 무언가를 변경하려면 어떻게해야합니까? 구현하는 동안 그가 변경하면 어떻게됩니까?

사용해야하는 접근 방식은 고객과 관계에 따라 다릅니다.

고객이 할 수있는 시간에 지불하지 않거나, 가능할 때마다 당신을 고소하려한다는 사실을 알고 있기 때문에,이 고객을 위해해야 ​​할 모든 일에 반드시 연락해야하는 사람이라면 요구 사항의 작은 변화. 엉망이 아닙니다. 잘 정리되어 있다면 개발 중에 새로운 요구 사항을 수용하기가 어렵지 않을 수 있습니다. 그러나 시간과 돈을 잃는다는 것은 확실하며, 구현하는 데 2 ​​시간이 걸리는 변경 제안을 서명하는 것이 다소 이상합니다.

다른 고객의 경우 잘 작동하는 접근 방식은 다음과 같습니다.

  • 첫 번째 오퍼에 서명 할 때 예상 비용과 최대 비용을 지정하십시오. 예상 비용은 합법적 인 것을 의미하지 않으며 단지 추정 일뿐입니다. 최대 비용은 합법적 가치가 있습니다. 고객에게 제품 비용이 3,000 달러이고 최종적으로 3,157.24 달러라고 말하면 고객은 여전히 ​​3,000 달러를 지불해야합니다. 실제로 대부분의 경우 실제 비용은 주어진 최대 값보다 적으며 추정치에 더 가깝습니다.

  • 고객이 요구 사항 변경을 요청하면 해당 비용을 추정하고 실제 비용 및 상태와 비교합니다. 제품을 거의 완성했으며 실제 비용이 $ 2,108.36이고 변경 비용이 $ 150로 추정되는 경우에는 그대로 두십시오. 반면 최대 값에 도달 할 위험이있는 경우 고객에게 전체 비용을 함께 재평가해야한다고 알립니다.


3

애자일과 '제안 작성'은 반 추론처럼 보입니다. :)-후자는 생산적인 소프트웨어 엔지니어링이 아닙니다. : D

자, 이제 농담을 마치고 다시 실제 상황으로 돌아갑니다.

" 애자일 에서는 어떻게 작동 합니까?" -계약이 복잡하지만 명확하게하기를 바랍니다. 애자일은 '신뢰'와 '동역'이라는 원칙에 기반을두고 있습니다. 즉, 고객은 비용이 조금 더 들거나 비 침해적일 경우 추가 비용이 들지 않는다는 것을 언제 어디서나 변경할 수 있음을 이해합니다.

이것은 무엇을 의미 하는가? 계약은 우리가 (고객이) 초기 비용 추정치와 우리가 처리 할 수있는 +/- 편차 %를 수정한다는 것을 의미합니다. 계약의 일부이지만 고객을 염두에두고).

이제 설계 변경이 들어 오면 예측 및 계획에 민첩 해집니다. 팀을 구성하고 변경 요인을 계산하는 데있어 복잡하고 '스토리 포인트'견적을 요청하십시오. 일부 속도 추정치로 인해 속도를 곱하고 스케줄을 추정 할 수 있습니다. 팀과 상대 급여를 아는 경우 스토리 당 비용을 산출하는 것이 상대적으로 쉬워야합니다 (모든 직원의 평균 급여를 평균하지 말고 평균 결함에 굴복하십시오).

재무와 관련하여 고객에게 돌아 가야합니까? 아니. 반드시 그런 것은 아닙니다. 고객이 우선 순위를 정하고이를 백 로그의 올바른 위치에 삽입하게합니다. 백 로그의 크기 (아직 그렇지 않은 경우)를 알고 재정 (스토리 포인트 당 비용)을 기반으로 하여 주어진 예산으로 수행 할 수없는 우선 순위가 낮은 요구 사항을 알고 있습니다. $$ 계약에 따라 가능한 기능의 추정치와 함께 우선 순위가 지정된 백 로그를 표시하십시오. 그런 다음 그들이 도착했을 때 더 많은 돈을 지불 할 의사가 있는지 결정하도록하십시오. 그들이 무료로 원한다면 ... 당신은 스탠드를 가지고 그들에게 더 많은 비용을 말할 것입니다.

고객이 볼 수있는 곳에이 그래프를 표시 할 수 있으면 재무 상태를 지속적으로 되 돌리지 않고도 도움이됩니다.

도움이 되었기를 바랍니다!


1

다른 사람들의 경험은 아마도 다를 수 있지만, 내가 본 것을 본 한 가지 방법은주의해야 할 몇 가지 사항이있는 "전통적인"것과 거의 동일합니다.

  1. 변경을 위해 약간의 오버 헤드를 생성합니다 (예 : 10 %)
  2. 내장 된 비용을 넘어서 큰 변화를 평가하고 별도로 청구하거나 집계하고 청구합니다 (프로그래밍은 아니지만, 예를 들어, 초기 비용에 종종 3 개의 개정, 후속 개정 또는 총 재실행이 포함되는 설계 작업이 있습니다) 특별한)

종종 애자일 프로젝트는 "핵심"항목으로 시작하여 필요에 따라 모듈 방식으로 나선다 (필자는 관련 프로젝트에서 약간의 일이 발생 함). 따라서 핵심 제품부터 시작하여 매핑 응용 프로그램이라고 가정하겠습니다. 첫 번째 구현은 현재 위치 (고객이 처음 주문한 위치)를 중심으로하는지도 일뿐입니다.

그런 다음 고객은 주변의 특정 명소를 한 방울 떨어 뜨리기를 원합니다. 좋아, 그것은 꽤 큰 조각 (상대적으로 말하면)이므로 새로운 "모듈"또는 구매 주문으로 청구합니다. 해당 핀의 색상이나 디자인과 같은 변경 사항은 해당 주문 비용에 내장되어 있습니다. 길 찾기 및 오버레이는 다른 구매 주문이 진행된 후 등으로 요청되지 않았기 때문에 다른 구매 주문입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.