애자일 vs 폭포의 효율성 / 효과에 관한 연구가 있습니까?

다른 날 회의에서 애자일은 폭포와 비교할 때 개발 시간이 60 %에 불과하다고 주장했습니다. 이 주장을 확인하거나 반박하려고하지 않습니다. 두 가지 방법론을 비교 한 연구가 있는지 알아내는 것이 흥미 롭습니다.

두 가지를 비교 한 연구가 있습니까?

이 책 "만들기 소프트웨어 무엇 정말 작품과 우리는 생각하는 이유를" 좋은 과학적인지지와 XP, 스크럼, 동적 소프트웨어 개발 및 린을 포함하여 민첩한 방법, 몇 가지 챕터를 가지고있다. O'Reilly에서 기대하는 바와 같이 고품질입니다. 편집자 중 한 명이 신뢰할 수있는 컴퓨터 과학 저자, 편집자 및 발표자 인 Greg Greg 였습니다 .

이 책 자체는 민첩한 많은 것을 포함하여 여러 연구를 요약합니다. 한 섹션은 Dybå, T.의 "하나보다 두 개의 머리가 더 좋을까 ? 한 쌍의 프로그래밍 효과에 관한 연구 "를 포함하는 연구를 요약합니다 . Arisholm, E .; Sjøberg, DIK; 한니, JE; 셜, F .; 와 " 애자일 소프트웨어 개발의 실증 연구 : 체계적인 검토 "으로는 Dybå 및 Torgeir Dingsøyr을 찢었다.

일반적인 의미는 대부분의 민첩한 관행이 유익하지만 페어 프로그래밍과 TDD 및 기타 민첩한 임차인의 효과가 원하는만큼 강하지 않다는 것입니다. TDD가 실제로 약간 중독성이있을 수 있다는 혼란스러운 각주도 있습니다 *.

이 책은 모두 하나의 응집 된 전체로 수행 된 많은 연구에 액세스 할 수있는 좋은 방법입니다. 몇 가지가 있습니다 블로그 및 기타 사이트 책을 검토 웹은.

* 반드시 내 의견은 아닙니다!

제목을 싫어하는 한, 균형 민첩성 및 규율 : 난처한 지침서에 귀하와 관련된 일부 정보가 포함되어 있다고 생각 합니다. 이 책은 소프트웨어 엔지니어링 프로세스 및 소프트웨어 프로젝트 관리 전문가 Barry Boehm과 Richard Turner의 두 권입니다. 이 책은 민첩하고 계획 중심적인 방법론의 다양한 측면을 살펴보고, 비교 및 ​​대조하며, "두 세계에서 가장 좋은"상황을 달성하기 위해 이들을 통합하는 방법에 대해서도 설명합니다.

균형 민첩성 및 훈련의 부록 E에는 다양한 민첩하고 계획 중심적인 방법의 비용과 이점에 관한 풍부한 경험적 정보가 포함되어 있습니다. 그러나 시간 효율성과 관련된 데이터는 없습니다. 그러나 데이터를 살펴보면 이것이 의심스럽지 않은 것처럼 보입니다. 일부 프로젝트는 민첩한 방법을 적용 할 때 노력이 줄어들고 일정이 빨라지고 결함이 줄어 듭니다. 그러나 다른 프로젝트를 사용했습니다. 이 섹션에서는 다양한 산업 분야의 다양한 프로젝트, 사용 된 프로세스 유형 및 프로젝트 진행 과정에서 경험 한 내용에 대해 설명합니다.

부록 E에는이 데이터를 제공하는 사례 연구가 많이 있습니다. 많은 사람들이 특정 산업이나 특정 조직에 초점을 맞추기 때문에 무작위로 명명을 시작하기에는 너무 많은 것이 있습니다. 사례를 살펴 보려면 팀, 프로젝트, 조직 및 산업과 본질적으로 유사한 사례를 찾아서 합리적으로 유효한 결론을 도출하는 것이 좋습니다.

에서 신속한 개발 : 길들이기 와일드 소프트웨어 일정 , 요구 사항의 구조, 원하는 안정성, 위험 관리, 일정 제약, 프로세스의 양의 이해의 수준을 이해의 수준을 : 스티브 맥코넬은 라이프 사이클 방법론을 선택할 때 고려해야 할 요인을 식별 오버 헤드, 중간 프로젝트 "과정 수정", 고객에게 가시성을 제공하는 능력, 가시성을 제공 할 수있는 능력, 개발 팀 및 관리의 정교함. 조직 문화와 같은 다른 것들도 있기 때문에 아마도 어디에도 완전한 목록이 없을 것입니다.

정확히 같은 프로젝트를하더라도 팀 요소도 있습니다. 계획 중심의 나선형 방법론을 사용하여 소프트웨어를 구성 적으로 제공 한 팀을 Scrum에 투입하면 생산성이 떨어지고 스 래싱이 증가하며 새로운 프로세스 모델을 극복해야합니다. 성공하기까지. 다른 방법론이 더 적합하더라도 비즈니스가 실제로 소프트웨어를 실제로 제공해야하는 경우가 항상 있습니다. 그렇기 때문에 프로세스 개선 노력이 빈번하지 않고 장기적으로 진행되는 노력입니다. 주요 변경 사항이 팀에 충격을 주었으며 (방법론이 종이에 더 적합 할지라도) 생산성이 저하 될 수 있습니다.

프로세스의 효율성 또는 효율성 이상의 것이 많으며 계획 중심 환경과 민첩한 환경에서 작업하는 동일한 팀의 스냅 샷을 단순히 볼 수는 없습니다. 의사 결정시 산업 및 조직 컨텍스트, 프로젝트 속성, 팀, 고객 등을 고려해야합니다.

내가 읽은 내용을 바탕으로 동료 평가에 동의하지 않을 것입니다. 비슷한 계획 중심 프로젝트보다 성능 지표와 관련하여 민첩한 프로젝트가 60 % 덜 효율적인 사례 연구를 찾을 수있을 것입니다. 그러나 민첩성이 80 % 적은 노력, 50 % 적은 시간, 제품에 대한 높은 고객 만족도를 보여주는 연구도 있습니다.

연구를하지 않았지만 경험을 전달하고 싶습니다.

언급 된 방법론의 효과는 분석가에 따라 크게 달라집니다.

훌륭한 제품 소유자가 있다면 예를 들어 SCRUM은 사양이 나쁜 폭포 방식보다 확실히 빠릅니다.

나쁜 제품 소유자의 민첩성은 사양이 좋은 폭포보다 확실히 느립니다.

그러나 정확한 요구 사항을 충분히 일찍 알지 못하는 경우가 많으며 민첩한 방법론은 피드백주기가 더 빠릅니다. 즉, 불확실한 지형에서는 민첩성이 합리적인 비용으로 고품질 제품을 제공하는 더 좋은 방법입니다. 예를 들어, 민첩한 프로젝트가 해결되지 않으면 취소하기가 쉬워 손실을 최소화 할 수있는 등의 여러 가지 이점이 있습니다.

민첩한 방법론은 위험을 줄이는 반면 폭포는 때로는 더 빠를지라도 상당히 금전적 인 도박 일 수 있다고 말할 수 있습니다.

애자일은 개발 시간에서 60 %에 불과했습니다.

참된.

그러나 이것은 절름발이입니다.

민첩한 방법은 일반적으로 더 빠른 가치를 제공합니다.

Waterfall은 전달 된 내용에 관계없이 일정을 고수하며 많은 시간이 지날 때까지 가치가없는 경우가 많습니다.

더욱이.

"개발 및 테스트 시간"과 별도로 "개발 시간"을 측정 할 수 있습니다.

애자일에는 일반적으로 테스트가 포함됩니다. 그래서 느려 보입니다.

폭포 개발은 테스트와 완전히 분리 될 수 있습니다. 따라서 코드는 더 빨리 "테스트 할 준비가되었습니다". 그러나 훨씬 후에 "완료"되지 않습니다.

그래서. 그들은 완전히 옳습니다. 그들이 무엇을 측정했는지.