ASD(Adaptive Software Development)는 1990년대 초 프로젝트 관리자인 John Highsmith와 Sam Bayer가 개발한 민첩한 소프트웨어 개발 프레임워크입니다. 이것은 민첩한 RAD(Rapid Application Development) 프레임워크의 추가 개발로, 1주일 기간으로 나누어지는 약 1개월 프로젝트용으로 설계되었습니다(스크럼 스프린트와 유사).
2000년에 처음 출판된 Highsmith의 저서 Adaptive Software Development는 애자일 프레임워크의 이론과 적용을 설명합니다. 저자는 ASD가 “실제 노력의 불확실성과 복잡성에 적응하기 위해 RAD 접근 방식에 엄격함과 규율을 더한다”고 주장합니다.
프레임워크는 세 단계로 구성됩니다.
- 추측
- 협력
- 배우다
민첩한 소프트웨어 개발 프레임워크인 ASD는 소프트웨어 개발 프로세스의 향후 반복을 정의하기 위해 사용자 피드백 및 협업에 특히 중점을 둡니다.
ASD는 일반적으로 가정하는 것처럼 소프트웨어 개발과 같은 복잡한 시스템에는 복잡한 규칙이 필요하지 않다는 접근 방식을 기반으로 합니다. 하이스미스는 몇 가지 간단한 규칙만으로도 복잡한 시스템을 만들 수 있으며 최소한의 접근 방식이 실제로 효율성을 향상시킨다고 주장합니다.
적응형 소프트웨어 개발의 또 다른 고유한 기능은 소프트웨어 개발이 “재미” 있어야 하며 최고의 소프트웨어는 우연히 나온다는 믿음입니다. 훌륭한 소프트웨어로 이어지는 환경의 합류를 “창출”이라고 합니다.
협업 및 생산성 도구 역사상 가장 빠르게 성장하는 SaaS이자 이미 공개 기업인 Slack은 Highsmith가 비상이라고 부르는 최근의 훌륭한 예입니다. Slack은 상업적으로 성공하지 못한 게임 제품을 작업하는 팀의 사이드 프로젝트의 결과입니다.
이러한 필요성 때문에 팀은 시장에 나와 있는 기존 제품에 만족하지 않았기 때문에 필요에 맞는 협업 도구를 만들었습니다. Slack을 만드는 데 도움을 준 실제 게임인 Glitch는 새롭고 독창적인 대규모 멀티플레이어 온라인 롤플레잉 게임(MMORPG)을 만들기 위한 자본 집약적인 시도였지만 결국 실패했습니다. 그러나 협업을 용이하게 하기 위해 개발된 도구는 큰 성공을 거두었습니다. 2020년 6월에 상장된 슬랙은 2009년에 설립되어 현재 약 255억 달러의 가치를 지닌 회사입니다.
Slack은 기존의 광고 지출 없이 심지어 최고 마케팅 책임자(Chief Marketing Officer)도 없이 단 8개월 만에 10억 달러의 가치를 달성한 것으로 유명해졌습니다. 실제로 사내 팀은 몇 달 동안 Slack의 초기 반복을 광범위하게 사용하여 필요에 따라 새로운 기능을 구축했습니다.
Slack은 적응형 소프트웨어 개발 프레임워크를 사용하여 개발되지 않았을 수 있습니다. 그러나 무작위 개발과 결합된 짧은 반복과 상세한 사용자 피드백으로 출시된 방식은 “Emergence”에 대해 많은 것을 말해줍니다.
그만큼 소프트웨어 개발 팀을 위한 Slack 핸드북 Highsmith의 저서 Adaptive Software Development에 자세히 설명된 프레임워크에 대한 엘리베이터 피치처럼 읽습니다.
ASD 프레임워크는 소프트웨어 개발 내에서 질서를 만들고 동시에 창발의 자유를 얻기 위해 몇 가지 지침으로 축소되었습니다. 결정론 대신 출현이 명시적으로 권장됩니다.
ASD는 결과 지향적 프레임워크이며 수행된 작업보다 결과의 품질에 더 중점을 둡니다.
이 세 단계는 적응형 소프트웨어 개발의 동적 특성을 반영합니다. ASD는 명시적으로 결정론을 출현으로 대체합니다. 라이프 사이클의 단순한 변화를 훨씬 넘어 리더십 스타일에서 시작됩니다. 적응형 소프트웨어 개발에는 추측, 협업 및 학습으로 구성된 역동적인 수명 주기가 있습니다.
짧은 적응형 개발 주기는 작업 지향성 부족을 방지합니다. 민첩한 프레임워크에 고유한 한 가지 접근 방식은 개발 수명 주기 단계가 이제 반복 접근 방식으로 대체된 이전 폭포 방법론을 기반으로 한다는 사실입니다.
폭포수 방법론의 계획, 구축 및 실행 단계는 단순히 추측, 협업 및 학습으로 대체되었습니다. 단계 이름은 복잡한 시스템에서 ASD가 가정하는 예측 불가능성을 의도적으로 반영합니다.
적응형 소프트웨어 개발 수명 주기는 작업이 아닌 애플리케이션 기능으로 정의된 산출물에 초점을 맞춥니다.
적응형 소프트웨어 개발의 3단계는 다음과 같은 기본 주장을 다룹니다.
- 학습 없이는 협력이 어렵습니다. 협업 없이는 학습이 어렵습니다.
- 학습 없이는 추측이 어렵습니다. 학습은 추측 없이는 어렵습니다.
- 협력 없이는 추측이 어렵습니다. 추측 없이는 협력이 어렵다.
ASD의 3단계를 자세히 살펴보겠습니다.
ASD 프레임워크는 수명 주기의 첫 번째 단계에 대한 “계획”이라는 용어가 최종 결과에 대해 너무 결정적이고 확신이 있기 때문에 거부합니다. 그것은 혁신을 위한 프로젝트 공간을 남겨두는 열린 추측 단계로 대체됩니다.
ASD 수명 주기의 추측 단계에서는 향후 프로젝트 및 반복 주기에 대한 계획 및 목표 설정을 구현합니다. 첫 번째 추측 단계에서는 최종 제품에 대한 대략적인 프레임워크를 제공하는 프로젝트 미션이 정의됩니다.
반복은 임무 완수를 향한 여정의 주기이며, 각각의 새로운 추측 단계는 탐색과 실험의 기회를 제공합니다.
협업 단계는 다음 원칙을 기반으로 합니다.
- 복잡한 애플리케이션은 만들어지는 것이 아니라 진화합니다.
- 복잡한 애플리케이션은 많은 양의 정보를 수집, 분석 및 문제에 적용해야 합니다.
- 많은 양의 정보나 데이터를 수집, 분석 및 적용하려면 학제간 지식이 필요합니다.
- 학제간 지식은 협력을 통해서만 증진될 수 있습니다.
협업 단계는 기존의 프로젝트 관리 기술과 새로운 가능성을 허용하는 협업 환경 사이의 균형에 의해 주도됩니다.
ASD 프레임워크로 작업하는 애자일 소프트웨어 개발 팀은 지식 기반을 지속적으로 확장할 것으로 예상됩니다. 이것은 각 반복 후에 발생하는 학습 단계에서 발생합니다. 여기에는 다음이 포함됩니다.
- 기술 검토
- 프로젝트 리뷰
- 포커스 그룹 및 기타 메커니즘을 통한 사용자 피드백
팀이 큰 실수가 아닌 작은 실수로부터 배울 수 있도록 반복은 짧아야 합니다. 사용자 경험을 프로세스로 가져오는 개발 팀과 사용자는 각 학습 단계에서 가정을 재평가해야 합니다. 이 평가의 결과(예: 기본 가정의 변경)는 다음 반복 주기의 방향을 나타냅니다.
- 사명 지향적
- 기능 기반
- 반복적 인
- 타임 박스
- 위험 지향적
- 변화에 개방
- 복잡한 소프트웨어 제품의 신속한 개발을 위해 설계되었습니다.
- 짧은 반복은 비용이 많이 드는 실수나 잘못된 결정을 피하는 데 도움이 됩니다.
- 계획되지 않은 방향을 탐색할 수 있는 많은 기회로 Emergence를 허용합니다.
- 개발 팀과 프로젝트 스폰서 간의 높은 수준의 투명성.
- 최종 사용자와 그들의 피드백은 개발 프로세스에 밀접하게 통합되어 긍정적인 결과의 가능성을 높이고 협업 단계에서 지식의 다양성을 높입니다.
- 짧은 반복의 집중 테스트는 버그와 취약점을 줄입니다.
- 좋지 않은 결과에 대한 책임을 타인에게 전가할 수는 없습니다.
- 환경의 불확실성은 적응형 사고방식을 가진 숙련된 팀을 필요로 합니다.
- 프로젝트 미션만으로 구성된 느슨한 출시 계획은 집중력을 잃기 쉽다는 것을 의미합니다.
- 반복 주기 전반에 걸쳐 높은 사용자 참여가 항상 쉬운 것은 아닙니다.
- 반복할 때마다 집중 테스트를 수행하면 기본 비용이 증가합니다.
- 프로젝트를 자주 변경하면 문서가 줄어들 수 있습니다. 이는 변경 사항이 진화하는 제품에 포함되면 소급적으로 완화될 수 있습니다.
적응형 소프트웨어 개발 프레임워크는 사용자를 프로젝트에 참여시키거나 이를 조정할 수 있다고 확신하는 경우 민첩한 개발을 위한 좋은 접근 방식이 될 수 있습니다. 또한 제품은 지속적으로 진화해야 합니다.
또한 위험을 완화하기 위한 지속적인 테스트와 새로운 아이디어와 방향을 탐색할 수 있는 충분한 자유를 허용해야 합니다. 일반적으로 기본 비용이 증가합니다.
ASD는 신속한 개발 및 릴리스가 우선시되는 경우에 고려되어야 합니다.
다음과 같은 경우 다른 애자일 개발 프레임워크가 더 적합할 수 있습니다.
- 최종 제품이 어떻게 생겼는지에 대한 명확한 아이디어가 있습니다.
- ASD가 가져오는 불확실성을 처리하기 위한 팀의 경험과 적응력이 부족합니다.
- 개발 팀은 사용자 피드백 및 공동 작업에 대한 광범위하고 심층적인 액세스 권한이 없습니다.