애자일의 핵심은 요구사항을 다루는 방법에 있다

[그림 1] 많은 사람들이 가지고 있는 애자일에 대한 오해 / 출처: 딜버트 카툰

[그림 1]과 같이 많은 사람들이 애자일은 포스트잇으로 설계를 대신하고 오로지 코딩을 통해 결과물을 만들어내는 방법론으로 오해하고 있다. 하지만 조금만 애자일을 학습해보면 오히려 폭포수 개발방법론에 비해 더욱 정교한 소프트웨어 공학적 접근을 하고 있다는 사실을 알게 된다.

요구사항 관점에서 애자일은 다음 두 가지 특징이 있다.

 

▶ 애자일은 요구사항을 가치창출 관점에서 바라본다

프로젝트는 항상 비즈니스 기회에서 출발한다. 이를 해결하기 위한 아이디어들을 요구사항으로 구체화하고 구현을 통해 시장에 적용되면 비소로 그 반응을 통해 성공여부를 확인할 수 있다.

이 과정에서 무수히 많은 아이디어들은 본래의 의도와 다르게 시장의 피드백을 통해 사장되게 마련이다.

애자일은 프로젝트 과정 안에 시장으로부터의 피드백 공정을 포함하고, 가치창출을 극대화 하기 위해 시행착오(요구사항 변경)를 수용함으로써 비즈니스에 좀 더 적극적으로 대응하는 특징을 가지고 있다.

 

▶ 애자일에서 개발은 요구사항 탐색 과정이다

게임의 판을 바꾸는 일은 고객이 말해주지 못하는 요구를 발견하는 데에서 시작한다. 당연히 시행착오가 필요하다. 이를 위해서는 현업부서, 설계자, 개발자, 테스터 모두 함께 요구사항 탐색에 나서야 한다. 개발자 친화적인 설계기법(UML 등) 대신에 모두가 이해하기 쉬운 기법들을 애자일이 추구하는 이유다. 

애자일은 전략수립에서 코딩과 테스트까지의 전 과정을 철저하게 각 요구사항 단위로 진행시킨다. 이를 통해 요구사항 탐색과 개발의 과정은 동기화 되어 같은 생명주기를 갖는 것이 애자일의 중요한 특징이다.

 

애자일에는 다양한 요구사항 접근법이 존재한다

SW개발 방법론이란 이해관계자의 Needs로부터 출발하여 프로그램 함수가 구현해야 하는 기능 요건까지 점진적으로 탐색하고 구체화하여 시스템을 완성해 나가는 공학적 접근법을 말한다.

애자일 개발 방법론으로 널리 알려진 스크럼이나 칸반은 개발 라이프 사이클을 만드는 기초 프로세스에 불과하다. 여기에 SW 엔지니어링 Practice들이 탑재 되어야만 비로서 완전한 방법론이 된다.

이 과정에서 애자일 회고는 개발 Process를 주기적으로 점검하고 새로운 Practice를 탐색하게 만드는 중요한 장치가 된다.
요구사항을 다루는 효과적인 기법들은 상당히 다양하게 존재한다. ‘openpracticelibrary.com’ 과 같은 사이트들을 통해서 무료로 구할 수 있고 학습할 수 있다.

요구사항을 효과적으로 다루기 위해서는 [그림2]와 같이 목표를 설정하는 Practice, 목표달성에 적합한 Feature를 찾는 Practice, 마지막으로 구현의 단위가 될 요구사항을 식별하는 Practice가 필요하다.

 

[그림 2] 요구사항을 탐색하는 Practice 예시

 

목표 탐색은 ‘Design thinking’으로 시작한다

“디자인 씽킹은 사람의 요구, 기술의 가능성 및 비즈니스 성공에 대한 요구사항을 통합하기 위해 디자이너의 방법론(일하는 방식)에서 가져온 혁신에 대한 인간 중심의 접근 방식입니다”

- IDEO CEO 팀 브라운(Tim Brown)

모든 일은 첫 번째 단추를 잘못 채우면 험난한 과정을 겪을 수 밖에 없다. 프로젝트의 첫 번째 단추는 ‘Why’에서 출발하는 것이다. 하지만 많은 프로젝트가 ‘What’으로부터 출발함으로써 험난한 여정을 겪고 있다. 예들 들면 ‘CRM시스템 구축’과 같은 목표 설정이다. 명확한 ‘Why’의 설정은 요구사항을 탐색하는데 있어 등대와 같은 역할을 한다.

애자일의 12가지 원칙 중 첫 번째 원칙은 다음과 같다.

애자일 개발은 고객중심 사고를 바탕으로 접근한다. 사용자가 자신의 요구사항을 알지 못하는 경우에는 소프트웨어 개발이 어려워진다. 디자인 씽킹은 명확하게 정리되지 않은 사용자의 니즈(needs)를 이해하고, 이를 해결할 수 있는 기회를 찾아 내기 위한 접근법이다.

 

구현 대상을 기능 주입(Feature Injection) 방식으로 탐색한다

Chris Matts에 의해 제안된 Feature Injection 개념은 고객에게 제공될 가치(Value)를 찾고 이것을 마치 구멍처럼 생각해서 이를 메울 수 있는 Feature를 찾아 주입하는 방식으로 접근하자는 것이다.

매년 IT프로젝트 통계자료인 카오스 레포트를 발간하는 Standish Group에 따르면 개발된 소프트웨어의 40%는 한번도 사용되지 않으며 25%는 거의 사용되지 않는다고 한다. 고객에게 제공하는 Value가 없었거나 잘못된 방향으로 요구사항을 정의했기 때문이다. 특히 폭포수 개발과 같이 초기에 모든 요구사항을 확정하려고 하는 경우 더욱 이러한 문제가 발생한다. Feature

Injection 접근은 이러한 문제 예방에 도움이 된다.

Feature Injection은 [그림 3]과 같이 3단계 Step을 따른다.
 

1) Hunt the value: 비즈니스 가치에 대한 모델을 통해 전략을 수립(ex. 가치제안캔버스)
2) Inject the features: 모델을 기반으로 비즈니스 가치를 제공하는 기능 목록 생성
3) Spot the examples: 예시를 통해 요구사항의 가정을 검증하고 구현 사항을 구체화

 

[그림 3] Feature Injection 개념 / 출처: https://agileprague.com/agile-business-analysis.htm

 

애자일 요구사항은 ‘Shift Left’로 검증한다

Shift Left는 [그림 4]와 같이 테스트 프로그램을 프로그램보다 먼저 작성함으로써 빠른 피드백을 추구하는 접근법을 말한다. 특히 DevOps가 애자일의 필수 Practice로 자리 잡으면서 Shift Left모델이 확산되고 있다. 폭포수 개발에서 흔히 겪게 되는 통합테스트 또는 인수테스트 시점에 요구사항의 문제점이 식별되어 프로젝트가 어려움에 봉착하는 문제를 예방할 수 있다.

요구사항을 명확하게 하는 가장 손쉬운 방법은 테스트 통과기준을 구체화하는 것이다. 이를 BDD와 TDD 개발 Tool을 이용하여 테스트 프로그램화 함으로써 프로젝트 공정에서 가장 긴 시간을 차지하는 테스트 시간 단축을 통해 전체 일정이 단축되는 효과도 부수적으로 얻어진다.

[그림 4] Shift Left Model (출처: Scaled Agile Framework)

소프트웨어 공학에서 요구공학이 차지하는 비중이 상당히 크다. 애자일 개발방법론 또한 공학적 접근법을 충실하게 따르고 있다. 다만 과거 정보공학 방법론이나 객체지향 방법론과 같이 하나의 방법론을 통해 A부터 Z까지 가이드 해 주는 것이 아니라 각 팀이 주도적으로 팀에서 채택하고 있는 방법론을 성장시키는 것을 전제로 하고 있다. 때문에 유용한 Practice를 학습하고 접목하는 것은 오롯이 각 애자일 팀의 몫이다.

IT프로젝트의 성공을 좌우하는 것은 요구사항이다. 올바른 요구사항을 찾아서 바르게 적용해야 한다. 이는 어떤 방법론을 적용하더라도 마찬가지로 중요하다. 요구사항을 어떻게 찾고 구현할 것인가에 차이가 있을 뿐이다. 프로젝트 결과를 성공으로 이끌기 위해서는 요구사항을 효과적으로 관리할 수 있는 방법을 지속적으로 학습하고 적용하여야 한다. 

- 끝 -