고정 범위 + 고정 마감일 + 고정 가격 계약을 "민첩한"작업에 사용할 수 있습니까?

우리가 내부적으로 사용하는 일부 프로젝트는 Scrum이며 여전히 "모든 것을 고정"하고 있습니다. 우리는 부분적으로 혼합 된 성공을 거두었습니다 (고객은 번 다운 차트의 가시성을 좋아합니다). 우리가 작업하는 프로젝트 유형을 민첩한 방법으로 성공적으로 실행할 수 있습니까?

글쎄, 나는 주로 "민첩한"환경에서 일했지만 (우리는 링고를 사용하지는 않지만) 고정 비용으로 일했습니다. 회사가 무료로 모든 것을 할 여유가 없으며, 고객이 원하는 것을보다 명확하게 파악함에 따라 요구 사항이 변경되고 진화하기 때문에 일반적으로 비용이 많이 든다.

고정 비용 부분에 대한 초기 요구 사항은 일반적인 반복 환경에서 수행되는 것보다 훨씬 더 신중하게 수행되어야하므로 프로세스의 반복이 덜 줄어 듭니다. 고정 비용 부분을 고객에게 다소 만족스럽게 충족시킨 경우 계약의 "플러스"부분이 반복 될 수 있습니다.

반대 질문을하고 싶습니다.

범위를 고정 + 고정 기한 +는 이제까지 일에 할 가격 계약 고정 할 수 기간을 ?

"좋은 / 빠른 / 저렴한 선택"이라는 말은 바보 같은 엔지니어링 농담이 아닙니다. 그의 가치가있는 모든 프로젝트 관리자는 프로젝트 관리 삼각형 에 대해 알고 있습니다 .

비용, 범위 및 일정이 모두 고정되어 있다고 말씀하셨습니다. 그것은 기동성 또는 오류의 여지를 남기지 않습니다. 없음 . "품질"을 속성으로 보도록 선택할 수 있지만 "실제"속성은 아니며 다른 속성 (비용 / 범위 / 스케줄)에서 파생 된 메타 속성과 비슷합니다.

문제는 프로젝트가 인간에 의해 계획되고 실행되는 한 실제로는 결코 일어나지 않는다는 것 입니다.

• 자격을 갖춘 건축가와 디자이너가 엄청난 세부 사항을 작성하지 않은 한 요구 사항과 사양은 모든 경우를 다루지 않습니다. 그리고 그렇다하더라도 여전히 오류의 가능성이있다.

• 예상치 못한 비용이 발생하여 예산 초과가 발생할 수 있습니다. 가입이 만료되었습니다. 제조업체가 사용중인 제품에 대한 지원을 중단했으며 새 제품을 찾아야합니다. 시간당 계약자는 출발 위협에 따라 요금을 올렸습니다. 팀 전체가 파업을 시작하여 10 %의 추가 인상과 1 주일의 휴가를 요구했습니다.

• 일정이 미끄러집니다. 예측할 수없는 문제가 발생합니다. 5 년 동안 사용한 차트 구성 요소는 클라이언트가 계속 사용중인 Windows 95와 호환되지 않습니다. 64 비트 Windows에서 모호한 버그로 인해 심각한 UI 결함이 발생하고 거의 일주일 동안이를 추적하고 해결 방법을 개발합니다 (실제로 발생했습니다). 선임 개발자가 버스에 부딪 히고 새로운 것을 모집하고 훈련해야합니다. 배송 예정일이 항상 잘못되었습니다. 항상.

  Hofstadter의 법칙을 참조하십시오 :

  Hofstadter의 법칙 : Hofstadter의 법칙을 고려하더라도 항상 예상보다 오래 걸립니다.

민첩한 방법은 비용, 일정 및 범위를 다루는 것입니다. 대부분의 경우 특히 범위 와 때로는 일정 을 다루는 것에 관한 것이므로 풀 버전 대신에 끔찍한 사용자 스토리로 시작하고 개정을 계획하는 이유입니다. 다른 방법론은 다른 용어를 사용하지만 모두 동일한 기본 전제입니다. 빈번한 릴리스와 각 릴리스의 스케줄 및 범위 재조정.

이것은 수없는 느낌을 A (또는 청구 됨) 인 프로젝트 중 고정 범위 또는 정해진.

경우 하나 개의 프로젝트 속성 (비용 / 범위 / 일정) 수정되었습니다, 나는 당신을 말할 것 수있는 민첩한 방법론에 대한 좋은 적합하지.

경우 이 개 프로젝트 속성이 고정되어, 다음 프로젝트는 확실히 민첩 방법론에 적합하지.

경우 세 가지 속성이 고정되어, 다음 프로젝트는 아마 실패 할 것입니다. 실제로 배송되면 원래 일정이 크게 퍼지거나 고객이 약속 한 내용을 실제로 전달했다고 생각하여 자신을 속일 수 있습니다.

이 계약서가 여전히 테이블에 있으면 거부 할 것을 촉구합니다. 이미 받아 들였다면, 당신의 영혼에 하나님의 자비가 있기를 바랍니다.

나는이 인용문을 좋아한다 :

“스크럼은 고정 날짜 변수 범위 또는“고정 범위”(항상 증가하는 변수) 날짜에 적합합니다. 고정 날짜 고정 범위를 수행하는 경우 새로운 일자리를 찾기 위해 몇 달 동안 구입하는 폭포수 또는 RUP를 권장합니다.”~ Michael James

물론 품질 막대가 현저하게 낮게 유지되는 한. 나는 "배달 시간 / 품질 / 가격"이라는 오래된 철 삼각형을 믿는 사람입니다. 두 가지를 선택할 수 있지만 다른 하나는 수레입니다. 배송 시간과 가격 (및 기능)을 고정한 것처럼 들리므로 실제로 제공 할 수있는 유일한 것은 품질입니다.

즉, 번 다운 차트를 사용 중이고 우선 순위가 가장 높은 항목이 먼저 지정된 경우 지정된 금액으로 지정된 기간 동안 가장 중요한 항목을 몇 개 수행하는 것이 좋습니다. 최소한 클라이언트는 프로세스가 끝날 때마다 산출물을 사용하여 프로세스를 다소 제어하고 있으며 가장 중요한 것을 말할 수있는 능력을 가지고 있음을 알게 될 것입니다.

그렇지 않으면 정해진 시간, 기능 세트 및 가격을 약속하는 것은 어리석은 일이며, 품질이 떨어지고 유지 관리가 용이하지 않은 코드를 만드는 영웅적인 노력으로 이어질 것이라고 생각합니다. 민첩한 마법의 먼지가 아닙니다.

고정 가격 / 고정 기한 / 고정 범위는 폭포 에서처럼 민첩하게 수행 할 수 있습니다.

폭포수에서 시간 추정은 정확하지 않으며 세부 사항은 원래 사양과 다르게 구현됩니다. 다시 말해, 기한 / 범위는 정확히 미리 알 수 없습니다.

민첩하게 스프린트 제로를 수행하여 사용자 스토리의 백 로그를 생성하고 몇 가지 추정을 수행 할 수 있습니다. 그런 다음 고정 된 마감일까지 고정 된 가격으로 가치 이야기를 만나기로 동의합니다. 범위는 달성하려는 가치 스토리의 관점에서 고정되어 있으며 사용자 스토리에 대한 약속은 없습니다.

다시 말해, 중요한 것을 제공하고 수익 / 저축 등과 관련이없는 특정 설계 결정에 대해서는 약속하지 않습니다. 프로젝트가 제공하기로되어 있습니다.

나는 Bruce에게 어느 정도 동의합니다. 폭포 나 RUP에 익숙하지는 않지만 이에 대해서는 언급 할 수 없습니다.

내가 최근에 읽었고 정말로 잘 알고 있다고 생각한 것은 애자일에서도 계획을 무시한다는 것입니다. 반복이 일단 완료되면 철저한 계획 세션이 필요하지만 필수는 아니지만 반복을 통해 계획하는 것입니다.

나는 끊임없이 변화하는 엔터테인먼트 산업에서 일합니다. 팀은 새로운 목표 또는 수정 된 목표에 맞추기 위해 스프린트 중간에 스토리를 "재 계획"할 수있는 어느 정도의 융통성 / 유연성이 필요합니다.

개발자가 스프린트 중간에 스토리를 진행할 때 제품 소유자에게 멀리 가라고 지시하기 때문에 지속적인 계획이라는 아이디어가 마음에 듭니다. 팀이 여전히 유효한 스토리를 작업하고 제품 소유자가 성가신 경우에 좋습니다. 그러나 스프린트 중에 스토리가 중복되는 경우가 있으며, 제품 소유자가이를 파악하고 팀이 변경된 목표 / 스토리를 다시 맞추는 것이 필수적입니다. 민첩성이 무엇입니까?