나는 주로 프로젝트에서 폭포수 방법론을 사용했지만 이제는 내 지평을 민첩한 방법론으로 확장하고 있습니다. 내가 지금까지 읽은 내용과 어쩌면 내가 잘못 읽은 것에서 민첩성은 작은 폭포를 의미합니다. 1-2 년에 걸쳐 큰 폭포 대신에 몇 주 또는 몇 달 동안 지속되는 작은 폭포가 있습니다.
내 이해가 맞습니까? 아니면 그보다 더 있습니까? 민첩한 철학은 무엇입니까?
답변:
간단한 수준에서 그렇습니다. 간단히 폭포 매 2 주 수행하면 민첩하지 않습니다 (민첩의 절반이다), 그러나 그것은 반복이다.
폭포수 모델은 요구 사항, 아키텍처, 설계, 구현, 검증 (테스트), 검증 (수락 테스트) 및 릴리스와 같은 단계를 정의합니다. 반복 방법론에서는 모든 반복 내에서 이러한 각 단계를 수행합니다. 둘 사이에 겹칠 수 있지만 요구 사항을 도출 및 포착하고 구현을 위해 시스템의 아키텍처와 디자인을 채택하고 새로운 기능을 개발하거나 결함을 수정하고 새 모듈을 테스트 한 다음 수용 할 수 있도록 고객에게 제시 테스트 및 배포.
그러나 반복적이고 점진적인 것보다 민첩해야 할 것이 더 많습니다. 민첩한 세입자는 민첩한 소프트웨어 개발 선언문에 담겨 있습니다. 선언문에는 4 가지 핵심 사항이 있습니다.
프로세스 및 도구에 대한 개인 및 상호 작용
개별 사람들을 자주 참여시킵니다. 많은 구현은 자기 조직 및 자기 지시 팀을 중심으로 이루어집니다. 거의 모든 사람이 고객 또는 고객의 목소리를 가진 사람과 자주 상호 작용합니다. 따라야 할 공식적인 절차와 도구를 사용하는 대신, 프로젝트를 진행하는 사람들이 프로젝트를 수행하는 방법을 최대한 활용하여 최상의 방법으로 프로젝트를 수행 할 수 있습니다.
포괄적 인 문서에 대한 작업 소프트웨어
소프트웨어 프로젝트에서 기본 목표는 소프트웨어 제공입니다. 그러나 일부 프로젝트에서는 가치가없는 문서가 낭비됩니다. Scott Ambler는 Agile / Lean Documentation 에 대한 좋은 기사를 썼습니다 . 문서를 제작하는 것이 아니라 팀, 미래 개발자, 고객 또는 사용자에게 가치를 더하는 문서를 선택하는 것입니다. 부가 가치가없는 문서를 작성하는 대신 소프트웨어 엔지니어가 대신 소프트웨어 및 관련 테스트를 작성합니다.
계약 협상을 통한 고객 협업
약관과 시간표 및 비용을 미리 정의하지 않고 고객과 지속적으로 노력합니다. 예를 들어, 사용자 스토리 형식으로 요구 사항을 캡처하고 해당 포인트를 지정할 수 있습니다. 몇 번의 반복 후에 속도 (점 / 반복)를 설정하고 팀이 반복에서 구현할 수있는 기능 수를 결정할 수 있습니다. 고객이 어떤 기능이 가장 가치가 높은지에 대한 피드백을 제공하므로 언제 프로젝트가 완료되는지 결정할 수 있습니다. 빈번한 배송 및 고객 상호 작용으로 여러 가지 상황이 발생할 수 있습니다. 요구 사항이 충족되고 프로젝트는 유지 보수 및 최종 수명 종료로 결론을 내립니다. 프로젝트에서 프로젝트가 실패하고 고객이이를 일찍보고 취소 할 수 있습니다.
계획에 따라 변경에 응답
큰 설계 나 최종 계획이없고 설계 나 계획이 변경 될 때마다 재 작업을 수행해야합니다. 보유한 정보에 따라 지속적으로 견적을 추정하고 수정합니다. 프로젝트 상태 및 내부 변경시기에 대한 통찰력을 제공하기 위해 메트릭을 신중하게 선택합니다. 고객과의 요구 사항을 자주 추가, 제거 및 우선 순위를 정합니다. 궁극적으로, 당신은 변화가 유일한 상수라는 것을 이해합니다.
민첩하다는 것은 고품질의 부가 가치 소프트웨어를 신속하게 제공함으로써 사람들에게 집중하고 그들의 요구를 충족시키는 것을 의미합니다. 고객의 요구가 변화함에 따라 부가 가치에 중점을 두어야하는 요구에 적응할 수 있습니다. 민첩한 방법론의 구체적인 구현이 있지만 모두 사람에 초점을 맞추고 작업 소프트웨어를 적시에 제공하며 빠르게 변화하는 환경에 적응합니다.
나는 그것을 넣는 간단한 방법이라고 말할 것입니다. 그렇습니다. 물에 닿으면 작은 물이 흐르지 만 그 뒤에는 훨씬 더 많은 물이 흐릅니다. 프로젝트 접근 방식을 변경하는 전체 방법론 ... 필요한 사고 방식은 말할 것도 없습니다.
애자일에 대해 진지한 경우 다음과 같은 웹 캐스트 시리즈를 참조하십시오.
민첩을 잊어 버리고 "폭포"가 무엇을 의미하는지 생각하십시오.
모든 사람이 최종 제품이 해결해야하는 문제를 파악하려고하는 요구 사항 단계가 있습니다. 사람들은 이것에 대해 잠시 동안 주장한 다음 모두 일련의 요구 사항에 서명합니다. 이 시점에서 범위가 정의되고 계약이 체결되며 고객은 이탈하여 정의 된 요구 사항을 해결하는 제품이 나올 때까지 기다릴 수 있습니다.
다음에는 하나의 디자인 단계가 있습니다. 설계자 (개발자 일 수도 있고 그렇지 않을 수도 있음)는 서명 된 요구 사항을 충족시키기 위해 시스템이 어떻게 협력해야하는지에 대해 논쟁합니다. 요구 사항을 이해하지 못하는 경우 문제가 발생할 수 있습니다. 즉, 고객에게 돌아가서 요구 사항 단계를 다시 열거 나 (다른 사인을 얻음) 최소한 변경 관리를 조치로 설정해야 함을 의미 할 수 있습니다. . 종종 디자이너들은 단순히 최선의 추측을합니다. 논리 데이터 모델과 새로운 시스템 및 작동 방식을 설명하는 많은 UML이 나타날 수 있습니다. 그런 다음 사인온합니다.
이제 개발자는 서명 된 디자인을 기반으로 실제로 코딩을 시작합니다. 디자인을 제대로 이해하지 못하는 경우 문제가 발생할 수 있습니다. 즉, 설계자로 돌아가서 디자인 단계를 다시 열거 나 (다른 사인을 얻음) 최소한 변경 관리를 행동으로 설정해야 함을 의미 할 수 있습니다. . 설계자들은 혼란이 실제로 요구 사항으로 돌아가는 것을 인식 할 수 있는데, 이는 요구 사항 토론, 사인 오프 및 추가 변경 관리를 다시 열어야 함을 의미합니다. 종종 마감일이 다 된 프로그래머는 단순히 최선의 추측을합니다. 기능 코드를 만들기 위해 할 수있는 일을합니다. 그런 다음 테스트를 위해 릴리스합니다.
이제 시스템 테스트 단계가 시작됩니다. 테스터는 요구 사항 및 디자인에 대한 이해를 바탕으로 테스트하고 버그 추적 / 변경 관리 시스템에 결함으로 인식되는 사항을 등록하여 개발자가 문제를 다음과 같이 보지 않는 한 다시 개발을 시작하게합니다. 설계 결함 등을 설계로 다시 보냅니다. 결국 시스템 테스트가 통과되고 사인온됩니다.
마지막으로 고객이 돌아와서 새 시스템에서 사용자 승인 테스트를 수행합니다. 여기서 테스터가 테스트하고 개발자가 개발하고 설계 한 솔루션이 실제로 원하는 솔루션인지 결정합니다. 그렇지 않은 경우 잠재적으로 설계 단계로 돌아가거나 요구 사항을 다시 방문해야합니다.
폭포 뒤의 아이디어는 단계가 완료되면 되돌아 가기가 어렵고 매우 바람직하지 않다는 것입니다. 각기 다른 사람들이 서로 다른 단계에 관여하기 때문에 여러 가지 핸드 오프가 있습니다. 각 핸드 오프는 잘못 해석되고 정보가 손실 될 위험이 높습니다. 고객이 원하는 것을 말하는 시점과 구축 한 것을 보는 시점 사이에는 실제 요구 사항이 크게 변경 될 수있는 시간 사이에도 상당한 차이가 있습니다.
민첩한 방법론은 모든 이해 당사자 간의 강력한 의사 소통과 협력에 중점을 둡니다. "계약 협상에 대한 고객 협업"원칙은 일련의 사인 오프 및 핸드 오프를 거치지 않아도되며, 대신 고객과 협력하여 각 반복이 퍼즐 조각의 요구 사항을 결정 함을 의미합니다. 모든 플레이어가 가능한 한 직접 통신하여 테스트, 디자인 및 작업 코드를 즉시 형성합니다 (인계 비용 및 위험 제거). 작업 코드는 고객이 신속하게 테스트 할 수있어 시간 지연 위험이 없습니다. 모든 활동은 하향 흐름이 아닌 협업 소용돌이에서 발생합니다.
민첩한 방법론이 수행하려는 작업에 대한 훌륭한 개요를 보려면 Allistair Cockburn의 Agile Software Development : The Cooperative Game을 적극 권장 합니다.