수정 길이/고정 가격 프로젝트에서 스크럼 사용? [닫은

Question

나는 스크럼 초보자이며 회사에서 스크럼을 구현하려고합니다. 바이 인을 얻는 것은 문제가되지 않습니다. 그것은 내 회사이며 개발자는 이와 같이 일하는 것을 기쁘게 생각합니다.

문제는 수익의 75%가 고정 길이/고정 가격 프로젝트에서 파생된다는 것입니다.

Ken Schwaber는 그의 저서 인 Scrum의 Agile Project Management에서 책 끝의 부록에서 고정 길이/고정 가격 프로젝트에 대한 입찰 주제를 다룹니다.

많은 영혼 검색을 마친 후 Ken은 잠재 고객이 다르게 생각하도록 설득 할 수있는이 상황에서만 유용하다는 것을 파생했습니다. 고객은 용서할 수있는 일을 훨씬 빨리 얻고 모든 기능을 구현할 필요가 없을 가능성이 비용을 절약 할 수있는 대가로 많은 불확실성 (최종 비용 및 최종 배송 날짜)으로 괜찮아 야합니다.

나는 이것이 수정 길이/수정 가격 프로젝트에서 스크럼을 구현하는 유일한 방법이라고 확신하지 않습니다.

나는 다른 사람들이 어떻게 수정 길이/수정 가격 프로젝트에 성공적으로 입찰하고 이익을 얻었는지 알고 싶습니다.

Answer 1

예. 나는 당신이 할 수 있다고 생각합니다. 보다 폭포는 작동하지 않습니다.

"고정 가격 상자 밖으로 나가는 것"은 대화가 어려운 것이 아닙니다. 고객도 실패를 보았습니다. 그들은 요구 사항 문서로 오랫동안 지연되는 것을 보았습니다. 그들은 끝없는 변화 순서를 보았습니다. 그들은 그것을 좋아하지 않습니다.

그러나 고객이 다른 것을 다르게 관리하고 싶지 않다고 확신한다면 하이브리드 접근 방식을 취해야합니다.

가격을 책정하는 것은 민첩하지 않습니다. 당신은 고유 한 고객을 배치 할 목적으로 가격을 책정해야합니다. 분명히, 당신은 가격을 정당화하기 위해 어떤 종류의 마스터 계획을 가질 것입니다. 대부분,이 마스터 플랜에서 원하는 것은 백 로그입니다. 다른 세부 사항은 가상의 계획 가정에 지나지 않습니다. [그들은 언제나 계획 가정, 그러나 일부 PM은 초기 계획이 신성한 오라클이라고 생각합니다. 그렇지 않습니다.

그런 다음 작고 민첩한 점진적인 단계로 실행합니다. 사용자를 일찍 그리고 자주 참여시켜야하며 대화가 일어나도록해야합니다. 하지만! 백 로그의 각 변경 사항은 범위, 비용 또는 일정의 잠재적 변화로 검사되어야합니다.

모든 스프린트가 끝나면 백 로그 변경은 잠재적으로 프로젝트 범위 및 계약 변경 일 것입니다.

애자일은 고객과의 범위 변경을 적극적으로 작업하고 생산적으로 작업하기 때문에 위험을 줄입니다. 범위를 정의 (및 동결)하려고 시도하는 것은 부가 가치 활동이 아니므로 그만하지 마십시오. 범위를 추측으로 취급하고 각 스프린트에서 범위 변경을 수행하십시오.

Answer 2

입찰과 이익에 대해 잘 모르겠지만 SCRUM 방법론은 확실히 고정 길이/가격 프로젝트에 적용될 수 있습니다. 요구 사항이 알려지고 견고하면 제품 백 로그에 넣을 수 있으며 요구 사항 및 시간 제한에 따라 스프린트를 계획 할 수 있습니다. 여전히 매일 스크럼 회의, 번 다운 차트 등의 이점을 활용하여 프로젝트가 추적 할 수 있는지 확인할 수 있습니다.