스크럼은 요구 사항이 변경되지 않는 프로젝트에 추가 오버 헤드를 생성합니까?

Gunther Verheyen 의 Scrum-A Pocket Guide를 읽고 있습니다 .

Standish Group의 2011 년 카오스 보고서는 전환점을 나타냅니다. 기존 프로젝트와 Agile 방법을 사용한 프로젝트를 비교하는 데 광범위한 연구가 수행되었습니다. 보고서는 소프트웨어 개발에 대한 민첩한 접근 방식으로 소프트웨어가 정해진 시간과 예산 및 약속 된 범위 내에서 제 시간에 제공되어야한다는 기존의 기대와는 달리 훨씬 더 높은 수율을 달성 함을 보여줍니다. 이 보고서는 애자일 프로젝트의 성공률이 3 배이며, 기존 프로젝트에 비해 실패한 애자일 프로젝트의 횟수가 3 배 줄었다는 것을 보여줍니다.

그래서 동료 중 한 명과 함께 요구 사항이 변경되지 않는 약 / 군사와 같은 일부 프로젝트의 경우 애자일 (특히 스크럼)은 모든 회의에 오버 헤드가되고 더 논리적이라고 말합니다. 예를 들어 폭포를 사용합니다.

내 관점은 프로세스를보다 투명하게 만들고 팀의 생산성을 높이기 위해 그러한 프로젝트에 Scrum을 채택해야한다는 것입니다. 또한 스크럼 이벤트는 스프린트 계획에 1 개월 스프린트 동안 8 시간 동안 앉아 있지 않아도되기 때문에 시간이 많이 걸리지 않을 것이라고 생각합니다. 우리는 모두 같은 페이지에 있고 작업을 시작하기 위해 5 분을 절약 할 수 있습니다.

그렇다면 스크럼은 요구 사항이 변경되지 않는 프로젝트에 추가 오버 헤드를 생성합니까?

요구 사항이 변경되지 않는 프로젝트가 있다고 말하는 것은 잘못된 가정이라고 생각합니다. 국방 산업과 제약 산업 제작 소프트웨어 모두에서 일하면서 소프트웨어가 주제 전문가 (내부 또는 외부)의 손에 들어가면 피드백이 있다고 말할 수 있습니다. 때때로이 피드백은 요구 사항이 충족되는 방식에 있으며 다른 경우에는 실제로 요구 사항 자체가 잘못되었거나 불완전한 것입니다.

민첩성은 피드백주기를 줄이고 소프트웨어를 다른 사람의 손에 더 빠르게 전달하고, 피드백을 받고, 고객이 소프트웨어를 수락하기로 결정할 때 제공되는 것이 가치를 더할 수 있도록 다음 단계를 결정하는 것에 관한 것입니다. 항공 우주, 자동차 또는 의료 기기와 같은 도메인에서 찾을 수있는 맞춤형 하드웨어가있는 임베디드 시스템과 같은 영역에서도 통합 및 프로토 타입을 위해 얇게 기능을 제공하여 소프트웨어 및 하드웨어 시스템이 최종 사용자에게 도움이되는 의도 된 방식으로 작업하십시오.

피드백주기의 길이 감소는 위험 감소에 큰 요소입니다. 프로젝트 관리 관점에서 2-4 주 동안 프로젝트에 자금을 지원하고 진행 상황을 정기적으로 파악하면 진행 상태를 확인할 수 있습니다. 얇은 기능 조각을 제공 할 수 있으므로 대상 상태를 향해 점진적으로 작업하고 도달 할시기를 예측할 수 있습니다. 시간이 제약 조건이되면 가장 먼저 수행되는 작업이 높은 값의 함수이거나 높은 값의 함수를위한 작동기이므로 낮은 값의 함수를 범위를 정할 수 있습니다. 언제든지 노력을 계속할 가치가 있는지 또는 다른 방향으로 가고 프로젝트가 너무 늦기 전에 중단 할 가치가 있는지 결정할 수 있습니다.

가장 짧은 대답은 그렇습니다. Scrum은 더 비싼 접근 방식으로 설계되었지만 프로젝트라고 부르는 경우 거의 중요하지 않으며 결국 거의 항상 ROI가 더 좋아질 것입니다.

더 완전한 대답은 다음과 같습니다.

일반적으로 프로세스 제어에는 정의 된 프로세스 제어, 통계적 프로세스 제어 및 황제 프로세스 제어의 세 가지 형태가 있습니다. 정의 된 공정 제어가 가장 저렴합니다. 이것은 자주 반복되는 작업이 시간이 지남에 따라 작업을 수행하는 "최상의"방법을 찾기 위해 개선 된 것이 가능합니다. 소프트웨어 개발의 CI / CD는이 범주에 속합니다. 빌드 프로세스의 변형을 원하지 않으므로 프로세스를 표준화하고 만족할 때까지 조정 한 다음 자동화하십시오. 자동화 된 프로세스는 배포를 통해 수동으로 싸우는 것보다 실행 비용이 훨씬 저렴합니다.

통계적 프로세스 제어는 그 다음으로 가장 저렴하지만 알려진 프로세스의 변형을 설명합니다. 계획에 따라 진행되는 의료 절차는이 범주에 속합니다. 매번 우회 수술을 재발 명하고 싶지 않습니다. 기본 과정을 따르고 변형을 조정합니다. 이것은 비교적 낮은인지 부하와 상당히 높은 성공률을 가지고 있습니다.

다음은 경험적 프로세스 제어입니다. 프로세스가 진행됨에 따라 검색해야하기 때문에 훨씬 비쌉니다. 학습은 엄청나게 높지만 생산성과 효율성의 대가입니다. 그러나 이전에 수행 된 프로젝트가 거의 없기 때문에 거의 모든 프로젝트 작업에이를 필요로합니다. 물론 예외가 있습니다. 상황에 따라 약간 벗어난 시도 된 지침에서 작업하기 때문에 대규모 활성 디렉토리 환경을 설정하는 것이 더 통계적입니다. 그러나 프로젝트가 이전에 수행 된 정확한 작업을 수행하는 것이 아니라면 거의 확실하게 Emperical Process Control이 필요합니다.

Scrum을 다시 Scrum으로 가져 오기 위해 Scrum은 Emperical Process Control의 문제점을 해결하도록 설계되었습니다. 따라서 다른 접근 방식보다 더 많은 오버 헤드가 있습니다. 그러나 대부분의 프로젝트에는이 방법이 필요하기 때문에 논쟁의 여지가 있습니다.

의학과 군사 프로젝트에 대한 대응책에는 결함이있는 논리처럼 들립니다. 500 대의 비행기를 주문하고 있다면, 정확히 무언가를 재생성하고 있으며 스크럼은 유리하지 않을 것입니다. 새 비행기를 건설 중이고 요구 사항이 변경되지 않으면 해당 비행기를 비행하지 않습니다.

물론, 명확한 요구 사항이 사전에있는 프로젝트가있는 경우 개발자 앞에서 폭포 형으로 덤프하고 2 년 후 다시 꿈의 소프트웨어를 만나볼 수 있습니다.

그러나 대부분의 소프트웨어 프로젝트는 이와 다릅니다.

일반적으로 고객은 필요한 것을 알지 못합니다. 완전하고 구체적인 요구 사항을 제공 할 수 없습니다. 반복적 인 접근 방식이 여기에 도움이됩니다. 작은 것을 구축 한 다음 고객에게 피드백을 요청하십시오. 그렇습니다. 이번 데모에서는 "낭비"시간과 다음 반복 계획을 세웁니다. 그러나 한 스프린트에 대해 잘못된 것을 구축 한 다음 요구 사항을 신속하게 수정하는 것이 프로젝트 전체에 대해 잘못된 것을 구축하는 것보다 훨씬 낫습니다. 즉, 선행 요구 사항으로 인해보다 효율적인 개발이 가능하지만 반복적 인 접근 방식이 더 효과적 입니다.

유용한 소프트웨어를 구축하려면 개발자가 요구 사항을 올바르게 이해해야합니다. 늦기 전에 오해를 발견하는 좋은 방법은 무엇입니까? 반복적 인 접근 방식이 도움이 될 수 있습니다. 그러나 요구 사항 문서 작성자를 통해서만 필터링 된 정보를 얻는 대신 개발자가 고객과 공동 작업하는 것이 중요합니다.

마지막으로, 프로젝트 기간 동안 세상은 여전히 ​​멈춰 있지 않습니다. 외부 시스템 변화, 우선 순위 변화, 사람 변화. 짧은 프로젝트를 제외하고는 소프트웨어 프로젝트의 요구 사항이 변하지 않는 척하는 것은 좋지 않습니다.

이러한 모든 프로세스 수준의 이점은 민첩한 접근 방식의 큰 이점을 놓치지 않습니다. 올바르게 수행하면 민첩성이 모든 사람을 더 행복하게 만듭니다 . 이 중 가장 큰 것은 민첩한 기술이 짧은 시간 동안 실제 가치를 제공하는 데 집중한다는 것입니다. 이는 개발 프로세스에 대한 가시성을 제공하고 이해 관계자에게 프로젝트에 대한 합리적인 수준의 제어를 제공하며 먼 목표를 향해 노력하는 것보다 훨씬 동기 부여가됩니다. 이와 관련하여 민첩한 팀이 주로 자체 구성한다는 아이디어가 있습니다. 일상 업무에 대한 통제력을 느끼면 사람들은 가치를 느끼게되므로 최선을 다할 가능성이 높아집니다.

폭포 스타일 프로젝트가 자신의 자리를 가질 수 있다는 것은 동료의 잘못이 아닙니다. 그리고 당신은 어떤 민첩한 관행이 시간을 낭비하는 의식이 될 수 있다고 잘못하지 않습니다. 그러나 민첩하고 반복적 인 접근 방식, 특히 더 나은 위험 관리 및 개인에 대한 존중의 이점을 무시하는 것은 완전히 어리석은 일입니다. 이것들은 모든 프로젝트에서 원하는 것입니다. 필요한 경우 팀은이 중 일부를 내부적으로 구현하려고 시도 할 수 있지만 모든 사람이 탑승하면 프로세스가 더 잘 작동합니다.

나는 이것이 @Cort Ammon의 말을 바꾸는 것일 수도 있지만 다음은 내 취향입니다.

프로젝트의 외부 요구 사항 ( "제공 물"을 설명)이 유일한 요구 사항은 아닙니다. 외부 요구 사항이 변경되지 않더라도 "내부"요구 사항은 변경되거나 작업 할 때 변경 될 수 있어야합니다. 개발자는 접근 방식의 장애물이나 문제를 발견하게되며 이는 팀 내 다른 사람들의 작업에 영향을 미칩니다. 매일 일어나면 이러한 내부 변화로 모든 사람을 최신 상태로 유지할 수 있습니다.

다음을 고려하십시오.

• 기능 요구 사항이 고정되어 있어도 기술 요구 사항에 따라야합니다. 그리고 이것은 반복에 의해 더 잘 이루어질 수 있습니다. 프로젝트 중간에 문제를 해결하는 더 나은 방법을 발견 할 수 있습니다.

• 일부 요청은 너무 일반적이거나 모호 할 수 있습니다 : "사용하기 편하다", "안전하다". 완성되지 않은 시스템의 보안 성 또는 유용성을 분석하기는 어렵습니다. 일부는 숨겨진 의미를 갖거나 잘 이해하지 못할 수 있습니다.

• 일부 요구 사항이 개선 될 수 있습니다. 200ms에 응답하는 것은 좋지만 100이 더 좋습니다. 최상의 결과를 목표로 삼을 수 있지만 프로젝트 중에 필요한 경우 희생하십시오.

• 계약서에 기록되지 않은 숨겨진 요청이 발견 될 수 있지만 프로젝트가 실패에서 성공으로 바뀔 수 있습니다. 프로젝트를 제공하더라도 고객이 만족하지 않을 수 있습니다. 초기 단계에서 프로젝트에서 더 저렴하게 디자인 할 수있는 새로운 기능을 추가하고 청구하기 위해 계약을 변경해야 할 수도 있습니다.

• 주어진 시간에 요구 사항을 충족하지 못할 수도 있습니다. 소프트웨어 프로젝트가 결코 늦지 않은 것처럼 아닙니다. 따라서 최고의 가치를 제공하면 어떤 기능을 제거해야하는지 재협상 할 수 있습니다.

• 더 빨리 무언가를 제공하면 통합에 도움이되고이 프로젝트가 결과를 제공 할 수 있음을 보여줄 것입니다.

모든 요구 사항이 완벽하게 배치된다면, 그러한 요구 사항을 가능한 빨리 달성하는 하향식 접근법이 존재한다고 주장 할 수 있습니다. 그러나 이것들이 좋은 요구 사항이라면 어떻게해야하는지가 아니라 무엇을해야하는지 알려줍니다. 그들이 그것을 만드는 방법을 말해 주면, 나는 그것을“요구 사항”대신에“작업 지시 사항”이라고 부르기로 선택하고 우리는 다른 종류의 문제에 대해 논의 할 것입니다.

따라서 요구 사항을 구현하는 회사 나 팀 내부의 "방법"을 개발하는 프로세스는 항상 있습니다. 경험적으로 말해서, 우리는 디자이너 팀이 이러한 요구 사항을 충족시키기 위해 높은 수준의 시스템을 설계 한 다음 해당 높은 수준의 시스템의 세부 사항을 사용하여 세부 사항을 구체화하는 소규모 팀에 "요구 사항"을 제공하는 계층 적 접근 방식에 크게 의존합니다.

폭포 과정에서 이것은 디자인과 구현 사이의 단방향 화살표에서 볼 수 있습니다. 그러나 이러한 요구 사항은 고객이 제공 한 것과 같이 결석으로 설정되지 않습니다. 이들은 내부적으로 정의되어 있으며 반복 프로세스를위한 공간이 있습니다. 실제로, 우리는 디자이너가이 반복 부족을 설명하기 위해 프로세스에서 상당한 마진을 두거나 반복 프로세스를 찾는 것을 발견했습니다.

SCRUM 및 기타 여러 관련 민첩한 방법은이 반복 프로세스를 수행 할 수있는 엄격한 프레임 워크를 제공합니다. 민첩한 접근 방식의 상표는 이러한 반복 패턴을 어려운 요구 사항의 외부 계층에 중점을두기보다는 프로세스의 핵심으로 최적화하는 것을 고려한다는 것입니다. 다른 사람들이 언급했듯이 실제 고정 요구 사항은 드물지만 그 존재에도 불구하고 SCRUM은 반복 접근 방식을 방법론으로 사용하여 내부에 맞는 계약 방식을 제어합니다.

이것이 성공했는지 여부는 공개 토론의 문제입니다. 다른 사람들은이를 위해 많은 메트릭을 제공했습니다. 나는 그 아래에서 발생하는 반복이 위의 계약 시스템에 올바르게 적용되도록하는 것이 리더십의 힘에 달려 있다는 것에 주목할 것이다. 이는 개발에 대한 모든 접근 방식에서 사실이지만,보다 하향식 접근 방식이 "정상적"이고 훈련 된 리더라고 가정하기 때문에 민첩한 접근 방식에서 더 잘 보입니다.