두 가지 주요 소프트웨어 개발 방법론은 폭포와 민첩성입니다. 이 두 가지를 논의 할 때, 그것들을 구별하는 특정 관행 (쌍 프로그래밍, TDD 등 대 기능 사양, 큰 선행 디자인 등)에 종종 초점을 맞추고 있습니다.
그러나 이러한 관행은 철학에서 나온다는 점에서 실제 차이점은 훨씬 더 깊습니다.
폭포의 말 : 변화는 비용이 많이들므로 최소화해야합니다.
애자일의 말 : 변화는 불가피하므로 변화는 저렴합니다.
내 질문은 TDD 또는 기능 사양에 대해 어떻게 생각하든 폭포수 개발 방법론이 실제로 실행 가능한가?
소프트웨어의 변화를 최소화하는 것이 귀중한 소프트웨어를 제공하려는 사람들에게 실용적인 선택이라고 생각하는 사람이 있습니까? 아니면 불가피한 변화를 관리하기 위해 어떤 상황에서 가장 잘 작동하는지에 대한 질문입니까?
답변
물론 폭포는 가능합니다. 그것은 우리를 달로 데려 왔습니다!
그리고 여기서 말하는 민첩한 코치입니다!
프로젝트 관리 방식과 관련된 문제를 명확하게 식별 할 수 없으면 변경할 이유가 없습니다.
Agile 및 Waterfall 방법론 의 대안으로 귀하의 방법론 을 제안 합니다. 특정 비즈니스, 특정 팀, 제품, 작업 방식, 회사 문화에 적합합니다. Scrum이 방법론 대신 간단한 프레임 워크 라고 불리는 이유 입니다.
당신이 좋아하는 블로그에있는 누군가가 아무 것도하지 않고 문제를 겪는 것만 큼 멍청하기 때문에 방법론을 구현하고 싶다.
답변
먼저, 나는 당신의 진술에 동의하지 않을 것입니다 :
폭포의 말 : 변화는 비용이 많이들므로 최소화해야합니다.
애자일의 말 : 변화는 불가피하므로 변화는 저렴합니다.
내 해석은 다음과 같습니다
Waterfall의 말 : 고객은 원하는 것을 알고 있습니다.
애자일의 말 : 고객은 자신이 원하는 것을 알지 못하므로 몇 가지 다른 버전을 만들어야합니다.
내가 본 “폭포”의 가장 좋은 구현은 매우 큰 금융 고객과의 대규모 통합 프로젝트였으며 약 40 개 이상의 하위 프로젝트가 관련되었습니다. 우리가 제공 한 데스크톱 및 웹 사이트 패키지는 40 개 이상의 하위 프로젝트 중 하나 일뿐입니다. 나는 그들이 다른 사람들의 돈을 과도하게 날려 버렸다고 생각했지만, 물건을 모아서 40 개 이상의 다른 배를 모두 함께 형성했습니다. 프로젝트는 목표 날짜 ( 프로젝트 동안 목표가 한 번 움직 였음)에 시작되었으며 더 검소하고 기민하게 할 수 있다고 생각했지만 시간과 사양에 따라 완료되었습니다. 라이브 밤 일정은 약 100 페이지 길이였으며 그 중 약 40 페이지는 관련된 모든 종류의 사람들의 비상 연락 연락처 세부 정보였습니다. 이 고객에게 깊은 인상을 받았습니다.
또는, 우리가하는 일을 수행하고 가장 최근의 불만 / 버그 보고서가 무엇인지를 수행 하고 민첩하게 부를 수 있습니다.
답변
당신은 말하기 시작합니다 :
두 가지 주요 소프트웨어 개발 철학은 폭포와 민첩성입니다.
이것은 거짓입니다. 이 이분법은 민첩한 커뮤니티에 의해 구성되어 자신을 배치 할 상대를 만들었습니다. 애자일이 유행하기 전에 사람들은 소프트웨어 구축에 대한 수많은 다른 접근 방식에 대해 이야기했습니다. 그것들은 오늘날에도 여전히 존재하지만 어쨌든 그들은 종종 민첩한 지지자들에 의해 “폭포”라고 불리는 큰 혼란에 빠지게됩니다.
저는 10 년 넘게 OPEN / Metis 와 그 변형을 사용하여 큰 성공을 거두었습니다. 확실히 민첩하지 않으며 폭포가 아닙니다. 수천 명의 개발자가 매일 민첩하지 않은 방법을 사용하여 항공기, 생활 필수 시스템, 뱅킹 등에 매우 복잡한 소프트웨어를 만듭니다.
물론, 민첩한 대안이 있습니다.
답변
예, 문제 영역에 따라 다양한 소프트웨어 개발 기술을 모두 사용할 수 있습니다. “코스 말”입니다.
예를 들어, 원자력 발전소를 제어하거나 NASA 우주 왕복선을 운전하기위한 소프트웨어를 작성 중입니다. 이런 종류의 문제 영역은 아마도 폭포 (또는 더 엄격한) 접근법에 더 적합 할 것입니다. 가능한 경우 모든 문제를 미리 정리하십시오 (또는 BOOM!).
최신 웹 2.0 / 3.0 / 버지 마케팅 용어 UI를 작성 하시겠습니까? 애자일은 훨씬 더 나은 방법입니다 (빠른 피드백과 변경이 필요합니다).
방법론이 다음과 같은 경우에도 적용 할 수있는 소프트웨어 기술 원칙이라고 부르는 것이 있습니다.
- 소스 컨트롤
- 빌드 및 CI
- 페어 프로그래밍
- TDD
- 나는 ^ % $$ &
그리고 더.
당신이 무엇을하든, 방정식의 양쪽에있는 열광자를 듣지 말고, 당신, 팀 및 문제 영역에 맞는 것을하십시오.
답변
문제는 소프트웨어의 복잡성에서 비롯됩니다. 폭포는 물리학은 결코 변하지 않기 때문에 교량 건설 및 도로 포장과 같은 작업에 적합합니다. 물론 언젠가 우리는 새로운 아스팔트를 개발할 것이지만 도로 건설 방식에 혁명을 일으키지 않을 것입니다. 다리의 서스펜션에있는 강철은 올바른 크기이거나 그렇지 않습니다. 소프트웨어로 할 수있는 것처럼 실제 건설 프로젝트를 방해하거나 스터브 할 수 없습니다.
소프트웨어 변경. 소프트웨어가 빠르게 변경됩니다. 무어의 법칙에 따르면 칩의 트랜지스터 수는 18-24 개월마다 두 배가됩니다. 결과적으로 프로그램의 코드 줄 수는 두 배가됩니다. 따라서 이러한 코드 줄 사이의 복잡성은 2 ^ (2t)와 같은 bigO로 증가합니다.
소프트웨어가 빠르게 변화하고 복잡성이 기하 급수적으로 증가합니다.
소프트웨어 비용을 제어 할 때 곱셈 또는 덧셈이 아닌 지수 요소 를 제어하려고합니다 . 코드를 변경하면 기하 급수적으로 복잡성이 증가하고 프로젝트가 진행됨에 따라 기하 급수적으로 복잡해집니다.
변화 는 불가피하다. 프로그래밍의 본질은 클래스와 사용자 정의 메소드로 언어를 확장하여 언어 자체를 변경합니다. 도로 건설과 같은 다른 공학 분야에서는 그렇게 할 수 없습니다. 캘리포니아 주 캔자스에 도로를 포장하기 위해 새로운 포장 도로를 발명하지는 않습니다.
민첩한 방법은 또한 향후 릴리스 및 버그 수정을 처리하기위한 플랫폼을 제공합니다. 버전이 지정된 소프트웨어를 개발하기위한 관리 도구, 프로세스, 교육을받은 직원이 있습니다. 폭포 방식을 사용하면 사소한 버그 수정까지 처리 할 수 있도록 팀을 재교육해야합니다.
어쨌든 내 2 센트.
답변
이 질문에 대답하기 위해, 적어도 일반적인 경우에는 소프트웨어에 대한 대안이있을 수 있습니다. 소프트웨어의 본질이라고 생각합니다. 정보 인 소프트웨어는 무료로 복제 할 수 있습니다. 다리나 집과는 다릅니다. 이것은 실제로 집을 짓고 비교적 간단한 영역에서 운영 할 수 있다는 것을 의미합니다. 어느 시점에서 원샷 방식을 사용하지 않습니까?
그러나 소프트웨어는 중복 비용이 없기 때문에 왜 같은 일을 두 번 하시겠습니까? 소프트웨어는 제조 과정에서 벗어나는 경향이 있습니다. 따라서 모든 소프트웨어가 새로운 제품을 만드는 경우, 우리는 항상 어느 정도까지는 우리가 무엇을하는지 알지 못하는 복잡한 도메인에서 운영되고 있습니다. 또는 사전에 아는 것이 비싸고 그렇게함으로써 알아내는 것이 더 저렴합니다. 복잡하고 위험한 도메인에서 실험을 시도하고 증가시키고 반복하고 싶습니다.
원자력 발전소와 플라이 바이 와이어 시스템은 종종 폭포수를 만들고 싶은 소프트웨어의 예로 제공됩니다. 그러나 셔틀 항공 전자 시스템이 반복적으로 개발되지 않았습니까? 캐나다와 미국의 항공 교통 관제 시스템도 마찬가지였습니까?
그리고 OPEN / Metis가 반복적이고 점증 적이라면 다른 일반적인 민첩한 관행과 관련이 없더라도 민첩한 철학을 가지고있는 것처럼 들립니다.
답변
Waterfall 방법은 가장 확실하게 실행 가능하며 다른 접근 방식과 마찬가지로 철학적으로 견고합니다. Waterfall은 Agile보다 훨씬 길었지만, 한 방법이 다른 방법 보다 낫다 는 주장은 아닙니다 .
전체 문제 영역과 고객이 소프트웨어 패키지에서 달성하고자하는 사항에 대해 매우 명확하게 이해 한 경우 Waterfall 방법을 사용합니다. 계약을 체결 할 때 고정 가격을 제시했을 가능성이 있으며 고객은 합의 된 요구 사항을 벗어날 수 없다는 것을 이해합니다. 귀하의 프로세스는 다양한 개발 단계 사이에 일련의 사인 오프 (sign-off)를 거쳐야하는 프로세스이며, 각 단계가 다른 팀 (때로는 다른 회사)에 의해 완료되는 경우가 종종 있습니다. 다른 사람과 접촉하십시오. 폭포가 외부 계약자에게 입찰 할 때 군사 및 정부 프로젝트에 좋은 효과가 적용되는 경우가 종종 있습니다. Waterfall 및 기타 유사한 접근법이 나쁜 평판을 얻는 곳은 개발자가 문제를 겪을 때입니다. 평가 불충분, 우발 시간없이 계획된 일정, 문제 영역에 대한 이해가 불완전하거나 불완전합니다. 이 문제는 진정으로 방법론의 결함이 아니라 적용에 있습니다.
애자일과 방법론의 비교는 잘못된 것입니다. 애자일은 방법론이 아니며, 철학이거나, 소프트웨어 개발 방법을 살펴볼 수있는 다른 방법을 나타내는 포괄적 용어라고 말하는 것이 좋습니다. 방법론은 도구 일 뿐이므로 그 가치는 항상 애자일이라는 의미 의 핵심 인 개인과 상호 작용보다 작을 것 입니다.
소프트웨어의 변화를 최소화하는 것이 귀중한 소프트웨어를 제공하려는 사람들에게 실용적인 선택이라고 생각하는 사람이 있습니까?
변경을 최소화 할 수있는 모든 기회는 개발자와 고객 모두에게 중요합니다. 변경으로 인해 일정이 미끄러지거나 일정을 충족하기 위해 기능이 누락 될 수 있습니다. 프로젝트 가치에 영향을 미치는 변경의 영향을 관리하는 방법입니다.
아니면 불가피한 변화를 관리하기 위해 어떤 상황에서 가장 잘 작동하는지에 대한 질문입니까?
관행은 변경 관리에 도움이되거나 변경을 완전히 무시할 수 있습니다. 중요한 것은 개발 관행, 고객과의 관계 관리 및 이러한 사항이 관련된 모든 당사자에게 효과적으로 작동하는지 여부입니다.
모든 의도와 목적을 가진 우리 민첩한 애자일 은 귀하가 귀하에게 적합한 방법을 선택한다는 것을 이해합니다. 특정 접근 방식이 마음에 들면 따르십시오. 필요에 맞지 않으면 변경하십시오. 소프트웨어 제작 방법은 실제로 보유한 리소스를 최대한 활용하고 프로젝트를 실패로 이끌 수있는 관행을 최소화하는 방법으로 귀결됩니다. 특정 프로젝트가 있습니다.
“좋아, 이제 우리는 민첩하다”라고 말하는 것과 실제로는 민첩한 철학에 따라 실제로 살고 일하는 것입니다. Waterfall, Incremental, Spiral, SCRUM, XP, FDD 또는 다른 방법을 사용하든 기본적으로 다음과 같은 가치가있는 민첩 합니다.
- 프로세스 및 도구에 대한 개인 및 상호 작용
- 포괄적 인 문서에 대한 작업 소프트웨어
- 계약 협상을 통한 고객 협업
- 계획에 따라 변경에 응답
이러한 가치를 성공적으로 적용하기 위해 도구, 방법 및 경험을한데 모은 곳.