민첩한 개발 방법론에 대한 대안이 있습니까?


47

두 가지 주요 소프트웨어 개발 방법론은 폭포와 민첩성입니다. 이 두 가지를 논의 할 때, 그것들을 구별하는 특정 관행 (쌍 프로그래밍, TDD 등 대 기능 사양, 큰 선행 디자인 등)에 종종 초점을 맞추고 있습니다.

그러나 이러한 관행은 철학에서 나온다는 점에서 실제 차이점은 훨씬 더 깊습니다.

폭포의 말 : 변화는 비용이 많이들므로 최소화해야합니다.
애자일의 말 : 변화는 불가피하므로 변화는 저렴합니다.

내 질문은 TDD 또는 기능 사양에 대해 어떻게 생각하든 폭포수 개발 방법론이 실제로 실행 가능한가?

소프트웨어의 변화를 최소화하는 것이 귀중한 소프트웨어를 제공하려는 사람들에게 실용적인 선택이라고 생각하는 사람이 있습니까? 아니면 불가피한 변화를 관리하기 위해 어떤 상황에서 가장 잘 작동하는지에 대한 질문입니까?


1
흥미로운 질문입니다. 답변을 기대합니다.
DevSolo


3
@ FarmBoy-좋은 질문입니다. 나는 민첩한 철학을 조금 다르게 본다. "애자일의 말 : 변화는 불가피하므로 변화 비용을 결정하는 데 비용이 적게 듭니다."라고 적었습니다. 변경은 여전히 ​​매우 비쌀 수 있지만 민첩하게 신속하고 저렴하게 파악하여 변경 비용을 항상 알 수 있습니다. 다른 말로 표현하면 사람들은 민첩한 변화를 겪고 있기 때문에 비용이 적게 든다고 생각하게됩니다. 프로세스에 관계없이 일부 변경은 비용이 많이 듭니다.
Mike Two

1
@Yannis Rizos : 왜 단일 커뮤니티 투표없이이 흥미로운 질문을 혼자서 끝내고 있습니까?

1
Pierre303 @ 때문에 토론 질문 여기에 이 질문을 가져왔다.
Ryathal

답변:


59

물론 폭포는 가능합니다. 그것은 우리를 달로 데려 왔습니다!

그리고 여기서 말하는 민첩한 코치입니다!

프로젝트 관리 방식과 관련된 문제를 명확하게 식별 할 수 없으면 변경할 이유가 없습니다.

AgileWaterfall 방법론 의 대안으로 귀하의 방법론 을 제안 합니다. 특정 비즈니스, 특정 팀, 제품, 작업 방식, 회사 문화에 적합합니다. Scrum이 방법론 대신 간단한 프레임 워크 라고 불리는 이유 입니다.

당신이 좋아하는 블로그에있는 누군가가 아무 것도하지 않고 문제를 겪는 것만 큼 멍청하기 때문에 방법론을 구현하고 싶다.


10
당신의 방법론에 하나는 나에게 말한다 다음 애자일 코치는 스크럼은 뒷면까지 부팅을 얻을 수있는 유일한 방법입니다)
마티 Verburg

1
@karianna : 나는 구체적으로 스크럼을하지만 때로는 적절하지 않습니다. 다른 한편으로, 나는 또한 팀이 문제를 해결할 것이라고 생각하는 보스에게 SCRUM을 판매하려고 시도하는 것을 보았습니다. 그들은 문제가 상사 나 PM이 아니기 때문에 실패했습니다. 단일 규칙이 없습니다. 각각의 경우 솔루션. 그렇습니다. 대부분의 조직 문제는 민첩한 기술로 해결할 수 있지만 민첩성은 은총이 아닙니다.

5
달만이 아닙니다. 우주 왕복선은 임베디드 시스템에 ~ 1M 줄의 C 코드를 가지고있었습니다. ~ 30 년 동안 그들은 단지 2 개의 버그만 생산 빌드에 포함 시켰습니다.
Dan Neely

2
폭포는 또한 최초의 우주 비행사 3 명을 죽였습니다. 이 Apollo 프로그램을 Waterfall의 포스터 자식으로 사용한다는 주장은 기껏해야 무지합니다. Waterfall은 완전한 재정적 지원 프로그램 인 두 프로그램과 원래 사양이 "우주 트럭"에 대한 엔지니어 일 때 취약하고 값 비싼 "우주 페라리"인 두 프로그램 모두를 책임지는 것으로 언급되었습니다. SpaceX가 Waterfall에 대해 동의하지 않을 것이라고 확신합니다.

4
@ DanNeely 우주 왕복선 소프트웨어의 고품질 수준은 싸지 않았습니다. 분명히 가격은 코드 라인 당 $ 1000의 크기였습니다 .

21

먼저, 나는 당신의 진술에 동의하지 않을 것입니다 :

폭포의 말 : 변화는 비용이 많이들므로 최소화해야합니다.
애자일의 말 : 변화는 불가피하므로 변화는 저렴합니다.

내 해석은 다음과 같습니다

Waterfall의 말 : 고객은 원하는 것을 알고 있습니다.
애자일의 말 : 고객은 자신이 원하는 것을 알지 못하므로 몇 가지 다른 버전을 만들어야합니다.

내가 본 "폭포"의 가장 좋은 구현은 매우 큰 금융 고객과의 대규모 통합 프로젝트였으며 약 40 개 이상의 하위 프로젝트가 관련되었습니다. 우리가 제공 한 데스크톱 및 웹 사이트 패키지는 40 개 이상의 하위 프로젝트 중 하나 일뿐입니다. 나는 그들이 다른 사람들의 돈을 과도하게 날려 버렸다고 생각했지만, 물건을 모아서 40 개 이상의 다른 배를 모두 함께 형성했습니다. 프로젝트는 목표 날짜 ( 프로젝트 동안 목표가 한 번 움직 였음)에 시작되었으며 더 검소하고 기민하게 할 수 있다고 생각했지만 시간과 사양에 따라 완료되었습니다. 라이브 밤 일정은 약 100 페이지 길이였으며 그 중 약 40 페이지는 관련된 모든 종류의 사람들의 비상 연락 연락처 세부 정보였습니다. 이 고객에게 깊은 인상을 받았습니다.

또는, 우리가하는 일을 수행하고 가장 최근의 불만 / 버그 보고서가 무엇인지를 수행 하고 민첩하게 부를 있습니다.


8
Agile Dilbert에 따르면
Peter K.

11
"폭포의 말 : 고객은 자신이 원하는 것을 알지 못하므로 앉고 나서 이야기하고 해킹을 시작하기 전에 원하는 것에 동의
합시다

+1 : 아주 좋은 대답입니다. 민첩한 커뮤니티에는 하나의 기본 문제가 있다고 생각합니다. 민첩성은 특정 클래스의 프로젝트 및 고객에 대해 특정 상황에서는 좋지만, 더 빠르고 체계적인 접근 방식이 더 나은 선택이라는 요구 사항이 변경되지 않는 프로젝트가 있다는 것을 알지 못합니다 . 민첩한 커뮤니티는 접근 방식이 더 나은 선택 영역을 현실적으로 식별하려고 노력해야한다고 생각합니다 (그러한 영역이 존재한다고 생각합니다).
조르지오

6
@scrwtp-그리고 Agile은 "고객이 원하는 것을 알지 못하고, 말하거나 생각할 수없고, 생각하지 않으며, 5 분마다 마음이 바뀝니다. 얼굴에 무언가를 밀어야합니다. 의미있는 답변을 얻으려면 " 와. 내가 적을 때 그것은 정말 불행하게 들린다.
Michael

1
@scrwtp : 백만 달러짜리 질문은 다음과 같습니다. "앉아서 이야기하고 동의 할 수있는"믿음이 실행 가능한가? 그 대답은 다음과 같습니다. 그것은 많은 변수에 달려 있습니다 : 프로젝트가 얼마나 큽니까? 우리는 그것이 얼마나 큰지 알고 있습니까? 고객이 우리와 "앉아"야하는 시간은 얼마나됩니까? 우리는 소프트웨어 개발을 건설과 관련시키기 위해 수십 년 동안 노력해 왔으며 이는 거의 100 % 규범입니다. 소프트웨어 개발은 ​​"완전 반동"과 "100 % 규정"사이의 중간에 있습니다. 대부분의 상점에서, 그것은 "완전한 반동"에 더 가깝기 때문에 민첩한 채택입니다.
Calphool

21

당신은 말하기 시작합니다 :

두 가지 주요 소프트웨어 개발 철학은 폭포와 민첩성입니다.

이것은 거짓입니다. 이 이분법은 민첩한 커뮤니티에 의해 구성되어 자신을 배치 할 상대를 만들었습니다. 애자일이 유행하기 전에 사람들은 소프트웨어 구축에 대한 수많은 다른 접근 방식에 대해 이야기했습니다. 그것들은 오늘날에도 여전히 존재하지만 어쨌든 그들은 종종 민첩한 지지자들에 의해 "폭포"라고 불리는 큰 혼란에 빠지게됩니다.

저는 10 년 넘게 OPEN / Metis 와 그 변형을 사용하여 큰 성공을 거두었습니다. 확실히 민첩하지 않으며 폭포가 아닙니다. 수천 명의 개발자가 매일 민첩하지 않은 방법을 사용하여 항공기, 생활 필수 시스템, 뱅킹 등에 매우 복잡한 소프트웨어를 만듭니다.

물론, 민첩한 대안이 있습니다.


6
해당 링크에서 OPEN / Metis가 무엇인지 신속하게 이해할 수 없습니다. (보통 방법론을 다운로드 할 필요는 없습니다.) 제 질문은, 특히 변화를 다루는 데 철학이 무엇입니까? 변경을 최소화하거나 변경 비용을 줄이려고합니까? 저의 질문은 민첩한 관행이 아니라 민첩한 철학에 관한 것입니다.
Eric Wilson

OPEN / Metis에는 점진적으로 시스템을 구축하는 반복 라이프 사이클이 있습니다. 정보 시스템의 개발의 목적은 일부 변경에 영향을 미치기 때문에 변경은 일어날뿐만 아니라 일어날 때 것으로 인정됩니다 . 그러나 변경 비용은 적절한 수명주기 및 관련 관행을 통해 제어 및 관리됩니다.
CesarGon

1
"방법론 다운로드"에 대한 귀하의 의견과 관련하여, 귀하는 방법론을 다운로드하지 않습니다. 방법론을 설명하는 문서를 다운로드하십시오. 그렇지 않으면, 당신은 그들에 대해 어떻게 배우는가? XP, Scrum 등을 설명하는 수많은 책을보십시오.
CesarGon


10

예, 문제 영역에 따라 다양한 소프트웨어 개발 기술을 모두 사용할 수 있습니다. "코스 말"입니다.

예를 들어, 원자력 발전소를 제어하거나 NASA 우주 왕복선을 운전하기위한 소프트웨어를 작성 중입니다. 이런 종류의 문제 영역은 아마도 폭포 (또는 더 엄격한) 접근법에 더 적합 할 것입니다. 가능한 경우 모든 문제를 미리 정리하십시오 (또는 BOOM!).

최신 웹 2.0 / 3.0 / 버지 마케팅 용어 UI를 작성 하시겠습니까? 애자일은 훨씬 더 나은 방법입니다 (빠른 피드백과 변경이 필요합니다).

방법론이 다음과 같은 경우에도 적용 할 수있는 소프트웨어 기술 원칙이라고 부르는 것이 있습니다.

  • 소스 컨트롤
  • 빌드 및 CI
  • 페어 프로그래밍
  • TDD
  • 나는 ^ % $$ &

그리고 더.

당신이 무엇을하든, 방정식의 양쪽에있는 열광자를 듣지 말고, 당신, 팀 및 문제 영역에 맞는 것을하십시오.


여유가 있으면 폭포가 작동합니다. 위의 누군가는 NASA의 달 프로젝트 소프트웨어 비용이 코드 당 약 $ 1000라고 주장했습니다. 대부분의 상점은 코드 한 줄에 1 ~ 10 달러 정도가 필요하며 이러한 상황에서는 민첩성이 더 좋습니다. 그러나 민첩성이 전반적으로 더 나은 품질을 제공한다고 가정하지는 않습니다. 기본적으로 소프트웨어가 정확하거나 소프트웨어가 올바르지 않다는 것을 알게되면 솔루션을 알아내는 것이 더 저렴하다는 것을 알기 위해 많은 돈을 낼 수 있습니다.
Mikko Rantalainen

2

문제는 소프트웨어의 복잡성에서 비롯됩니다. 폭포는 물리학은 결코 변하지 않기 때문에 교량 건설 및 도로 포장과 같은 작업에 적합합니다. 물론 언젠가 우리는 새로운 아스팔트를 개발할 것이지만 도로 건설 방식에 혁명을 일으키지 않을 것입니다. 다리의 서스펜션에있는 강철은 올바른 크기이거나 그렇지 않습니다. 소프트웨어로 할 수있는 것처럼 실제 건설 프로젝트를 방해하거나 스터브 할 수 없습니다.

소프트웨어 변경. 소프트웨어가 빠르게 변경됩니다. 무어의 법칙에 따르면 칩의 트랜지스터 수는 18-24 개월마다 두 배가됩니다. 결과적으로 프로그램의 코드 줄 수는 두 배가됩니다. 따라서 이러한 코드 줄 사이의 복잡성은 2 ^ (2t)와 같은 bigO로 증가합니다.

소프트웨어가 빠르게 변화하고 복잡성이 기하 급수적으로 증가합니다.

소프트웨어 비용을 제어 할 때 곱셈 또는 덧셈이 아닌 지수 요소 를 제어하려고합니다 . 코드를 변경하면 기하 급수적으로 복잡성이 증가하고 프로젝트가 진행됨에 따라 기하 급수적으로 복잡해집니다.

변화 불가피하다. 프로그래밍의 본질은 클래스와 사용자 정의 메소드로 언어를 확장하여 언어 자체를 변경합니다. 도로 건설과 같은 다른 공학 분야에서는 그렇게 할 수 없습니다. 캘리포니아 주 캔자스에 도로를 포장하기 위해 새로운 포장 도로를 발명하지는 않습니다.

민첩한 방법은 또한 향후 릴리스 및 버그 수정을 처리하기위한 플랫폼을 제공합니다. 버전이 지정된 소프트웨어를 개발하기위한 관리 도구, 프로세스, 교육을받은 직원이 있습니다. 폭포 방식을 사용하면 사소한 버그 수정까지 처리 할 수 ​​있도록 팀을 재교육해야합니다.

어쨌든 내 2 센트.


2
물리 법칙만큼 절대적인 소프트웨어 설계에는 많은 측면이 있습니다. 애자일은 폭포 또는 다른 방법론과 같은 도구이며 다른 사람들이 게시 한 것처럼 이해가되지 않는 비즈니스 사례가 많이 있습니다. Boeing이 비행 제어 소프트웨어의 민첩한 프로세스 중간에 있다고 말한 비행기에서 비행기를 타기 위해 당신을봤을 때 나는 놀랐을 것입니다. 이유.
Hounshell

그리고 당신의 주장에 더 많은 구멍을 뚫기 위해 지금 은 캔사스와 캘리포니아 사이의 도로에 적합하지만 뉴욕과 보스턴 사이의 도로에는 적합하지 않은 도로 설계가 있습니다. 그리고 아스팔트를 다루는 새로운 기술이 항상 나오고 있습니다.
Hounshell

2
마지막으로 "폭포 방법을 사용하면 사소한 버그 수정을 처리하기 위해 팀을 재교육해야합니다."라고 말합니다. 그것은 폭포 과정이 어떻게 작동하는지에 대해 너무 무지합니다. 모든 소프트웨어 개발 시나리오에 부적합한 방법에 대해 이해하기 전에 좋은 폭포 상점을 시험해보십시오.
Hounshell

1
안녕 스테판, 모든 소프트웨어 요구 사항이 지속적으로 변경되는 것은 아닙니다.
Paul Nathan

1
사업은 항상 바뀐다 ; 변화하지 않고 적응하는 사업은 죽어가는 사업입니다. 시간은 상수 이며 변화와 잘 상호 작용하지 않습니다. 변화를 인정한다는 철학을 가진 시스템은 변화를 수용 수 있습니다.

2

이 질문에 대답하기 위해, 적어도 일반적인 경우에는 소프트웨어에 대한 대안이있을 수 있습니다. 소프트웨어의 본질이라고 생각합니다. 정보 인 소프트웨어는 무료로 복제 할 수 있습니다. 다리나 집과는 다릅니다. 이것은 실제로 집을 짓고 비교적 간단한 영역에서 운영 할 수 있다는 것을 의미합니다. 어느 시점에서 원샷 방식을 사용하지 않습니까?

그러나 소프트웨어는 중복 비용이 없기 때문에 왜 같은 일을 두 번 하시겠습니까? 소프트웨어는 제조 과정에서 벗어나는 경향이 있습니다. 따라서 모든 소프트웨어가 새로운 제품을 만드는 경우, 우리는 항상 어느 정도까지는 우리가 무엇을하는지 알지 못하는 복잡한 도메인에서 운영되고 있습니다. 또는 사전에 아는 것이 비싸고 그렇게함으로써 알아내는 것이 더 저렴합니다. 복잡하고 위험한 도메인에서 실험을 시도하고 증가시키고 반복하고 싶습니다.

원자력 발전소와 플라이 바이 와이어 시스템은 종종 폭포수를 만들고 싶은 소프트웨어의 예로 제공됩니다. 그러나 셔틀 항공 전자 시스템이 반복적으로 개발되지 않았습니까? 캐나다와 미국의 항공 교통 관제 시스템도 마찬가지였습니까?

그리고 OPEN / Metis가 반복적이고 점증 적이라면 다른 일반적인 민첩한 관행과 관련이 없더라도 민첩한 철학을 가지고있는 것처럼 들립니다.


2
이제 민첩성이 반복적이고 점진적으로 신용을 얻으려고합니까? '92 년에 개발을 시작한 이후로 반복적이고 점진적으로 폭포 개발의 핵심 부분이되었다는 것을 잊지 마십시오.
Dunk

1

Waterfall 방법은 가장 확실하게 실행 가능하며 다른 접근 방식과 마찬가지로 철학적으로 견고합니다. Waterfall은 Agile보다 훨씬 길었지만, 한 방법이 다른 방법 보다 낫다 는 주장은 아닙니다 .

전체 문제 영역과 고객이 소프트웨어 패키지에서 달성하고자하는 사항에 대해 매우 명확하게 이해 한 경우 Waterfall 방법을 사용합니다. 계약을 체결 할 때 고정 가격을 제시했을 가능성이 있으며 고객은 합의 된 요구 사항을 벗어날 수 없다는 것을 이해합니다. 귀하의 프로세스는 다양한 개발 단계 사이에 일련의 사인 오프 (sign-off)를 거쳐야하는 프로세스이며, 각 단계가 다른 팀 (때로는 다른 회사)에 의해 완료되는 경우가 종종 있습니다. 다른 사람과 접촉하십시오. 폭포가 외부 계약자에게 입찰 할 때 군사 및 정부 프로젝트에 좋은 효과가 적용되는 경우가 종종 있습니다. Waterfall 및 기타 유사한 접근법이 나쁜 평판을 얻는 곳은 개발자가 문제를 겪을 때입니다. 평가 불충분, 우발 시간없이 계획된 일정, 문제 영역에 대한 이해가 불완전하거나 불완전합니다. 이 문제는 진정으로 방법론의 결함이 아니라 적용에 있습니다.

애자일과 방법론의 비교는 잘못된 것입니다. 애자일은 방법론이 아니며, 철학이거나, 소프트웨어 개발 방법을 살펴볼 수있는 다른 방법을 나타내는 포괄적 용어라고 말하는 것이 좋습니다. 방법론은 도구 일 뿐이므로 그 가치는 항상 애자일이라는 의미 의 핵심 인 개인과 상호 작용보다 작을 것 입니다.

소프트웨어의 변화를 최소화하는 것이 귀중한 소프트웨어를 제공하려는 사람들에게 실용적인 선택이라고 생각하는 사람이 있습니까?

변경을 최소화 할 수있는 모든 기회는 개발자와 고객 모두에게 중요합니다. 변경으로 인해 일정이 미끄러지거나 일정을 충족하기 위해 기능이 누락 될 수 있습니다. 프로젝트 가치에 영향을 미치는 변경의 영향을 관리하는 방법입니다.

아니면 불가피한 변화를 관리하기 위해 어떤 상황에서 가장 잘 작동하는지에 대한 질문입니까?

관행은 변경 관리에 도움이되거나 변경을 완전히 무시할 수 있습니다. 중요한 것은 개발 관행, 고객과의 관계 관리 및 이러한 사항이 관련된 모든 당사자에게 효과적으로 작동하는지 여부입니다.

모든 의도와 목적을 가진 우리 민첩한 애자일 은 귀하가 귀하에게 적합한 방법을 선택한다는 것을 이해합니다. 특정 접근 방식이 마음에 들면 따르십시오. 필요에 맞지 않으면 변경하십시오. 소프트웨어 제작 방법은 실제로 보유한 리소스를 최대한 활용하고 프로젝트를 실패로 이끌 수있는 관행을 최소화하는 방법으로 귀결됩니다. 특정 프로젝트가 있습니다.

"좋아, 이제 우리는 민첩하다"라고 말하는 것과 실제로는 민첩한 철학에 따라 실제로 살고 일하는 것입니다. Waterfall, Incremental, Spiral, SCRUM, XP, FDD 또는 다른 방법을 사용하든 기본적으로 다음과 같은 가치가있는 민첩 합니다.

  • 프로세스 및 도구에 대한 개인 및 상호 작용
  • 포괄적 인 문서에 대한 작업 소프트웨어
  • 계약 협상을 통한 고객 협업
  • 계획에 따라 변경에 응답

이러한 가치를 성공적으로 적용하기 위해 도구, 방법 및 경험을한데 모은 곳.


2
와. 여기에는 너무 많은 이상한 것들이 있습니다. 폭포가 더 길다는 것을 근거로 실행 가능합니까? 국방 계약에 근거하여 폭포가 정당화 되는가? 고객의 최선의 이익을 위해 변화를 최소화 할 수있는 모든 기회가 있습니까? 당신이 이것에 관심이있는 것 같아서, 나는 당신이 어디에서 왔는지 이해하려고 노력했지만, 뭔가 빠졌습니다.
Eric Wilson

1
@EricWilson Waterfall은 애자일 철학이 논의되기 오래 전부터 더 오랫동안 사용되어 왔으며 성공적으로 사용되었습니다. 그것이 존재하기 때문에 실행 가능하며 올바르게 적용하면 그것을 사용하려는 사람들에게 효과적입니다. 나는 그것의 사용을 정당화하지는 않았지만, 그것이 효과가있는 곳에서 개인적인 경험을했던 예를 지적했을뿐입니다. 그렇습니다. 몇 가지 놀라운 실패도 보았습니다. 변화를 최소화 할 수있는 기회를 찾지 않고 변화를 가져올 기회를 원하지만 현명하게해야합니다. 그렇지 않으면 고객이 원하는 것보다 적거나 마감 기한이 지났습니다.
S.Robins 2012

0

예, Waterfall, Spiral, Iterative 및 기타 하이브리드 프로세스 모델은 모두 실행 가능하지만 변경은 불가피합니다. 프로세스는 단순히 변화를 처리하는 방법 이상의 문제이며, 가장 큰 결정 요인은 문제를 얼마나 잘 이해 / 이해하는지, 얼마나 정확하게 계획하고 예측할 수 있는지입니다.

소프트웨어 개발 프로세스의 범위가 다양하고 많은 회사들이 주어진 프로젝트를 위해 종종 변화하는 프로세스 모델의 자체 버전을 합성하기 때문에 "두 가지 주요 소프트웨어 개발 방법론은 폭포와 민첩성"이라는 말은 별다른 의미가 없습니다. 소프트웨어 개발에는 두 가지 이상의 실행 가능한 접근 방식이 있습니다. Waterfall과 Agile은 "변화"스펙트럼의 반대편 끝에있는 경향이 있지만 이러한 경쟁 방법론을 다음과 같이 대표하는 것이 합리적입니다.

폭포의 말 : 변화는 비용이 많이들므로 최소화해야합니다.

애자일의 말 : 변화는 불가피하므로 변화는 저렴합니다.

그러나 그것은 전체 이야기가 아닙니다. 비즈니스는 계획하고 예측할 수 있어야하지만 소프트웨어는 창조적 인 과정이며 추정치는 종종 틀립니다. 빠르고 저렴한 삼각형을 기억하십니까? 네 번째 차원, 프로세스를 추가하면 추정치가 잘못되고 프로젝트가 지연 될 위험이있는 경우 프로세스 노력을 줄이면 스케줄이 압축 될 수 있습니다. 소프트웨어는 실행 가능한 (변경 가능) 프로세스이며 Agile, Iterative, Spiral은 모두 짧은 간격으로 증분 기능을 제공 할 수있는 기능을 제공합니다.

Waterfall 및 기타 요구 사항 구동 프로세스 모델에는 변경 처리를위한 제어 기능이 있으므로 Waterfall이 변경을 최소화한다고 말하는 것은 정확하지 않습니다. Waterfall가 변경을 인식하고 관리하며 변경의 영향을 전달한다고 말하는 것이 더 정확합니다. 요구 사항이 있고 사전에 설계하십시오. 제품을 구축하거나 요구 사항 (기능)을 완전히 정의해야하는 경우 하이브리드 모델 중 하나를 사용하게됩니다.

그리고 추정치가 틀릴 때 종종 일정 (철 삼각형의 네 번째 구간)이 일정을 충족시키기 위해 희생됩니다.


나는 불쾌하지 않았다. 다양한 회사에서 5 년 동안 개발 한 결과, 저는 2 년 만에 만났으며 하나는 단지 대수로 지목되었습니다. 나선? 들어 본 적이 없어
Eric Wilson


나는 현실 세계에서 그들을 만나지 않았다는 것을 의미했습니다. 모든 종류의 것들이 웹에 존재하지만, 나는 2010 년에 다시 질문을했기 때문에 지금 그들을 사냥하지 않을 것입니다.
Eric Wilson

-1

성숙한 민첩성과 폭포 접근 방식은 서로 구별 할 수 없습니다. 폭포 접근 방식의 목표에 대한 귀하의 가정이 잘못되었습니다. 그들은 모두 양질의 소프트웨어를 생산한다는 목표를 가지고 있습니다. 회사 전체에 대한 탄탄한 개발 방식이없는 경우 채택시 마찰을 최소화 할 수있는 방법을 찾아야합니다. 결국 짧은 개발주기, 탄탄한 QA 팀 및 개발을 주도하는 비즈니스는 최고의 노치 소프트웨어를 생산하는 데 가장 중요한 요소입니다.


1
나는 당신의 의견에주의를 기울일 것입니다. 폭포에는 재능있는 사람들이 필요합니다. 그렇지 않으면 얼굴이 평평해질 것입니다. 잘 디자인하는 법을 배우기가 어렵습니다. 코딩 학습은 비교적 쉽습니다. IMO는 대부분의 개발자가 민첩성을 선호하는 주된 이유입니다.
Dunk

4
민첩한 말을 할 수 있습니다. 지도가없는 주니어 개발자는 신속하게 민첩성을 엉망으로 만들 수 있습니다.
Charles Lambert
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.