계약으로 정의 된 프로젝트에서 애자일 소프트웨어 개발을 사용할 수 있습니까?

최근에 Agile Software Development에 관해 동료 개발자와 대화를 나누었습니다. 원칙을 이해하고 있지만 지속적으로 변화하는 요구 사항으로 인해 프로젝트가 영원히 지속될 가능성이있는 것 같습니다. 그러나 적어도 내가 일하는 곳에서는 프로젝트가 계약이기 때문에 완료에 도달해야합니다.

즉, 일부 프로젝트의 경우 고객이 불완전한 응용 프로그램을 사용할 수 없기 때문에 첫 번째 반복에는 몇 개월이 걸릴 수 있습니다. 일부 프로젝트의 경우 완료를 먼저 정의한 다음 반복으로 나누고 각 반복 후에 정의를 세분화 할 수 있다고 생각합니다. 그러나 항상 이 정의가 있어야합니다 .

애자일 소프트웨어 개발이 변화하는 요구 사항을 수용한다면 그것이 어디에서 끝나는 지 어떻게 알 수 있습니까? 최종 결과가 항상 변할 때 어떻게 프로젝트 예산을 책정 할 수 있습니까?

애자일 소프트웨어 개발은 ​​애자일 제품보다 애자일 프로세스에 관한 것입니까?

OP의 의견에서 그는 고객을 위해 개발 서비스를 제공하는 컨설팅 상점에서 일하는 것처럼 보입니다 ... 나는 혼란을 일으키는이 사고 방식 때문에 생각합니다. 잘 알고 있지만 언급하지 않은 사실을 진술하십시오.

애자일은 계약에 의해 정의 된 소프트웨어 개발과 호환되지 않습니다.

• 계약은 딱딱해야하고 X는 Y를 지불해야합니다. X + M을 원하면 Y + (M * N)
• 계약은 반드시 만족할 수 있어야하며, 그렇지 않으면 법적 접촉이 아닙니다. (연락처가 관련된 경우 엄격한 변경 관리 프로세스를 거쳐야합니다.)

많은 컨설팅 상점들이 애자일을 주장하며 거짓말을하고 있습니다. 그들은 애자일이 버즈 단어 상태에 도달했기 때문에 말합니다.

애자일은 프로그래머가 풀 타임이고 예산에 대한 이야기가 거의없는 내부 개발에 가장 적합합니다. 타임 프레임과 기능.

가장 중요한 일을 먼저 수행하는 데 집중한다면 다음과 같은 경우 프로젝트가 완료됩니다.

• 당신은 당신이 예산을 돈을 보냈다.
• 예산이 책정 된 시간이 지났습니다.
• 더 이상 아무것도 추가하거나 변경하고 싶지 않습니다.
• 우선 순위가 가장 높은 다음 변경은 비용이 들지 않습니다.

비즈니스에서 더 이상 반복하지 않기로 결정하면 중지합니다. 당신은 이것이 상당한 금액의 가치가 전달 된 후에, 그러나 당신이 수익을 감소시키는 영역으로 너무 멀어지기를 희망합니다.

그것은 항상 귀하의 상황에서 의미하는 것이 무엇이든 "사업"에 의해 주도되어야합니다. 사내 개발 환경에서 소프트웨어 개발 상점 또는 실제 비즈니스 스폰서의 고위 관리자 일 수 있습니다. 다음 반복 비용이 다음 반복에서 제공 할 수있는 기능의 이점을 능가하는 시점을 결정합니다.

절대 그게 아름다움입니다.

이 프로젝트는 결코 완성하지 않습니다 . 또 다른 릴리스, 또 하나의 이정표에 도달했지만 돈이 흘러가는 한 항상 추가 할 기능이 하나 더 있고 더 나은 조각을 하나 더 만들고 버그를 하나 더 수정합니다. 더 이상 필요하지 않으면 프로젝트가 종료되지만 완료되지는 않습니다. 요구 사항-> 프로젝트-> 제품-> 끝이있는 Waterfall 모델과 달리, 이것은 지불을받는 한 영원히 회전 할 수있는 루프입니다.

이 기술에서 자주 언급되는 비즈니스 기능이 아닌가?

여기에는 오해가 있습니다. 애자일은 프로젝트 요구 사항을 변경하도록 권장하지 않습니다. 대신 작업을 낭비하거나 중요한 개발 영역을 희생하지 않고도 변경이 가능합니다.

모든 엔지니어링 프로젝트에는 네 가지 기본 제약이 있습니다. 범위, 비용, 시간 및 품질. Waterfall은 이것이 정적 인 것으로 가정합니다. 그것은 잘못된 가정입니다. 이 중 하나 이상이 항상 변경됩니다. 스코프 크립, 슬래시 예산 및 기타 "알 수없는 미지수"는 항상 프로젝트를 방해하여 제약 조건을 변경합니다. Waterfall은이를 예상하지 못하므로 프로젝트가 발생하면 바람직하지 않은 방식으로 프로젝트가 변경됩니다. 아직 추가되지 않은 중요한 기능은 사라지거나 빠르게 완료되거나 릴리스가 취소되거나 PM이 새로운 개발자에게 돈을 던져서 모든 것이 올바르게 완료되도록 도와 주므로 비용이 많이 든다.

반대로 애자일 (Agile)은 제약 조건이 변경 될 수 있도록하며 실제로는이를 예상합니다. 소유자의 우선 순위에 따라 작고 사용 가능한 청크에서 작업을 수행하므로 청크는 프로젝트 소유자에게 즉시 유용합니다. 따라서 미지수가 큰 시간대에 큰 계획을 세우지 않음으로써 미지에 대한 노출을 줄입니다. 타임 라인이 변경되면 팀을 추가하거나 덜 중요한 기능을 "범위를 벗어난"상태로 만들 수 있으며 팀이 이미 구축 한 시스템에는 영향을 미치지 않습니다.

또한 필요한 품질로 지정된 범위를 생성하는 데 필요한 시간과 비용을 더 잘 추정 할 수 있습니다. 사람들은 큰 일자리를 추정하는 데 악명이 높다. 제대로하려면 많은 경험과 선불 계산이 필요합니다. 대조적으로, 사람들은 일반적으로 하루, 또는 일주일 또는 이틀 안에 무엇을 할 수 있는지 잘 판단합니다. 이렇게하면 안정적인 속도로 역사적인 속도를 기반으로 남은 작업 시간과 비용을 추정 할 수있는 정상 상태를 빠르게 생성합니다.

엔드 포인트를 정의하는 것은 옳습니다. 애자일 프로젝트는 영원히 지속될 수 있습니다. 그러나 기존 SLDC도 마찬가지입니다. 고객은 종종 더 많은 돈과 업그레이드 희망 목록으로 돌아옵니다. 차이점은 프로젝트 전체를 볼 때 "분석", "디자인", "개발"및 "유지 관리"사이에 명확한 선이 없다는 것입니다. 그것은 모두 벽돌에 의해, 스프린트에 의해 스프린트가 발생합니다. 어느 시점에서든 소유자는 프로젝트를 "완료"라고 부르고 싶을 수 있으며, 그들이 지불 한 "벽돌"의 총계는 견고한 "벽"으로됩니다. 원래 계획했던 것만 큼 높거나 확장되지는 않았지만 제대로 제자리에 있고 작업을 수행하며 나중에 최소한으로 해체 할 수 있습니다.

모든 기능이 구현되고 모든 버그가 수정되면 종료됩니다.

마감일이 확정되고 요구 사항도 수정 된 경우 그러면 이것은 문제가되지 않습니다. 그러나 마감 기한이 정해졌지만 요구 사항이 변경되면 프로젝트를 성공적으로 진행하기 위해해야 ​​할 일이 있습니다.

고정 가격 파트 1, 그렇게 나쁜 이유는 무엇입니까?

고정 가격 부분 2, 민첩하게 고정하십시오!

민첩한 개발의 큰 가정은 사용하는 방법론에 관계없이 요구 사항이 항상 변경된다는 것입니다. 물론 요구 사항 문서를 작성하고, 실행 계획을 수립하고, 최종적으로 제공 할 수 있으며 요구 사항이 변경되지 않은 것처럼 보일 수 있습니다. 계획이 변경되지 않았을 수도 있지만 시장 변화와 고객에 대한 제품에 대한 이해가 높아지면 고객이 원하는 것에 대한 요구 사항이 바뀔 것입니다. 애자일은 이러한 일정을 고정 된 일정으로 숨기지 않고 대신 불가피한 프로세스 변경에 대응하는 프로세스를 제안합니다.

완료되면 고정 일정 완료에서 제품이 고객이 소프트웨어를 현재 상태로 배송 및 마케팅 할 수있는 충분한 비즈니스 가치를 제공 할 수있는 장소로 전환됩니다. 행해지는 것은 일정을 지키는 방식이 아니라 제공하는 가치에 훨씬 더 묶여 있습니다.