스크럼은 방위 계약에 장점이 있습니까?

12

어제 워터 쿨러에서 들었습니다. "스크럼은 방위 계약이 아닙니다."

나는 많은 시나리오에서 스크럼이 작동하도록 맞춤화 될 수 있다고 생각한다는 견해에 동의하지 않는 경향이 있으며 방어가 그 중 하나라는 것을 알 수 있습니다. 이것은 내 동료들 (우리 중 많은 사람들이 방위 계약에서 일하고 있음) 사이에 상당히 많은 논쟁을 불러 일으켰습니다.

이것을 적절한 질문으로 만들기 위해 : 누군가가 방위 계약 상황에서 스크럼을 성공적으로 사용했거나 협력 한 경험이 있습니까? 무엇이 효과가 있었으며 무엇이 효과가 없었으며 바닐라 스크럼에 어떤 수정이 있었습니까?

development-process scrum development-methodologies

— 숀 매든
소스

3

애자일은 폐기물을 제거하기 위해 노력합니다. 민첩하게 성공하려는 조직은 그 목표에 부합해야합니다. 정치 조직은 다른 우선 순위를 갖는 경향이 있습니다.

— Martin Wickman

5

"스크럼은 방위 계약에서 자리를 차지할 수 없습니다."

내 경험상 주요 장애는 고객입니다. 대부분의 정부 기관은 DNA에 폭포 모델을 가지고 있습니다. 폭포수 단계에서도 계약이 이루어집니다. 먼저 요구 사항, 디자인, 구현에 자금을 지원합니다. 고전적인 폭포 이론에서 그들은 다른 회사가 다른 단계를 수행하게 할 수 있다고 생각할 수도 있습니다.

IMO를 통해 해결할 수있는 방법이 있습니다. 폭포와 같은 선행 요구 사항과 디자인을 수행 한 다음 구현시 요구 사항을 반복적 인 사용자 사례로 나눕니다. 내부 테스트 / 전문가 사용자를 사용하여 각 반복을 평가하십시오. 고객에 따라 참여에 관심이 있거나 없을 수 있습니다. 순수한 스크럼은 아니지만 최선을 다할 수 있습니다.

— 더그 티
소스

3

Air Force Reseach Laboratory 시설에서 생산 소프트웨어 개발, 신속한 프로토 타입 제작, 계약 작업의 검증 및 검증에서 세 번째로 3 팀의 인턴으로 근무했습니다. 두 개발 위치는 모두 민첩했습니다. 실제로, 생산 위치는 고객 상호 작용 (3 ~ 6 개월마다 현장에서 고객에게 제공되는 소프트웨어)이 줄어들면서 스크럼과 매우 가까웠으며 2006 년이었습니다. 고객의 구매와 이해가 가장 큰 것에 동의합니다 문제는 있지만 일부 정부 기관 (또는 적어도 팀)은 실제로 애자일 방식을 수용하고 있습니다.

— Thomas Owens

@Thomas Owens이 의견은 좋은 답변입니다.

— 휴고

1

Scrum을 완전히 구현하는 것은 어려울 수 있지만 일부 Scrum 사례를 채택하는 것이 유리할 수 있습니다. 예를 들어, 요구 사항 수집을 수행하는 방법에 관계없이 릴리스 및 데모가 자주있을 수 있습니다. 정기 회고에서 여전히 혜택을 누릴 수 있습니다. 린 (Lean)이나 칸반 (Kanban)과 같은 다른 프로세스를 살펴보고 팀에 도움이 될만한 것이 있는지 확인하십시오.

하나의 프로세스를 독단적으로 따르는 대신, 팀, 프로젝트 및 산업 분야에서 프로세스를 어떻게 개선 할 수 있는지 생각해보십시오. 프로세스 문제 . 팀의 방법론은 제공되는 소프트웨어에 큰 영향을 미칩니다.

— 에 포터
소스