애자일 프로젝트 기반의 소프트웨어 요구공학 개념

애자일 프로젝트 기반의 소프트웨어 요구공학

2015.10  정리. 오상문 (sualchi@daum.net)

참고: 이 글은 Software Requirements 도서에서 애자일 관련 부분을 정리한 것입니다.

 

애자일 프로젝트

애자일 개발(Agile development)은 2011년 “애자일 소프트웨어 개발 선포”를 통해 공식적으로 발표되었습니다. 애자일 개발이란 작은 단위로 지속적인 협력을 통해 신속하게 소프트웨어를 개발하는 방법의 총칭입니다.애자일 특징은 다음과 같습니다.-       작은 단위로 개발-       단위 결과물의 빠른 개발 진행-       이해관계자의 지속적인 협력-       점진적 전개의 순환 반복 개발애자일 방법의 많은 접근 유형 중에서 대표적인 것들은 다음과 같습니다. -       Scrum -       Extreme Programming -       Lean Software Development -       Feature-Driven Development -       Kanban애자일 개발 접근법들은 다른 ‘예측(계획 중심) 접근’과는 다르게 근본적으로 ‘적응(변화 주도) 접근’이라는 점 이외에도 구별되는 특성들이 있습니다. 폭포수 모델과 같은 예측 방식은 소프트웨어를 만들기 전에 광범위한 계획 및 문서를 수행하여 프로젝트 위험을 최소화 시키려고 합니다. 프로젝트 관리자와 사업분석가는 사전에 전달되는 모든 이해관계자 자료를 전달받게 됩니다. 만약 요구사항이 처음부터 잘 이해되고 프로젝트 기간 중에 안정적으로 유지될 수 있다면 폭포수 모델도 유용할 것입니다..

 

애자일 프로젝트를 위한 요구사항

애자일이나 전통 프로젝트에서 개발자는 정확하게 올바른 기능을 구현할 수 있는 정보가 필요합니다. 다만 애자일과 전통 프로젝트는 여러 면에서 요구사항을 구분해서 다루어야 합니다. 특히요구사항 활동의 깊이, 시기, 요구사항 문서 범위가 그러합니다.

 

폭포수 모델의 한계 프로젝트 팀은 완전한 요구사항을 만들고, 디자인하고, 코드를 작성한 이후에 최종적으로 솔루션을 테스트하는 선형 순서를 가진 개발 모델입니다.

 

폭포수 모델의 장점

-팀은 오류를 수정하는 비용이 상대적으로 훨씬 많이 드는 개발, 테스트, 유지보수 중에 잡을 수 있는 오류를 요구사항 분석과 설계라는 초기 단계에 잡을 수 있습니다. -요구사항이 정확하면 예산 및 자원 할당 측정, 정확한 완료 기일을 추정하기도 쉽습니다. (

그러나 대부분의 소프트웨어 개발은 그리 간단하지 않지요.)

 

폭포수 모델의 문제

-일부 프로젝트는 완전히 순차형 폭포수 모델을 따릅니다. 프로젝트 변경의 일정 부분을 예측하고 그것을 처리하는 메커니즘을 넣고, 각 개발 단계 사이에 겹치는 부분과 피드백 과정이 대부분 있음에도 불구하고 전체 요구사항을 초기에 정확하게 설정하기 위해서 엄청난 노력이 필요합니다.-요구사항이 만들어진 후에 제품이 고객에게 전달되기까지 너무 오랜 시간이 걸립니다. (그 사이에 변경된 요구사항을 고려하지 못하죠.)-폭포수 모델을 이용하는 대형 프로젝트는 납기가 늦어지거나, 특성이 미흡하거나, 사용자 기대를 충족하지 못하곤 합니다. -폭포수 모델 프로젝트는 요구사항에 의존하는 개발 계층 때문에 실패할 수도 있습니다. (요구사항이 항상 맞는 것도 아니고 계속 변화합니다.)-이해관계자들은 긴 프로젝트를 진행하는 도중에 종종 그들의 요구사항을 변경하며, 소프트웨어 개발은 이들 변화에 효과적으로 대응하기 어렵습니다. 프로젝트 초기에 이해관계자는 정확히 무엇을 원하는지 모를 수 있기에 프로젝트 진행 과정에서 종종 변경이 요구되곤 합니다. -윈스턴 로이스(Winston Royce (1970))는 폭포수 모델(명칭은 아니지만)에 대해 처음 언급한 것으로 알려졌는데, 실제로 접근하는 상황의 “위험과 실패”도 다루고 있습니다. 그는 오늘 날 여전히 경험하는, 즉 테스트 단계까지도 요구사항이 발견되지 않는 것과 같은 문제를 다루고 있습니다. 이상적으로는 요구사항 정의, 설계, 코딩, 테스트의 순서로 수행되는 단계이지만, 일부 이들 단계의 중첩과 그들 사이의 순환을 설명하고 있습니다. 로이스도 전체 개발 노력에 진입하기 전에 요구사항과 설계의 프로토타입 시뮬레이션의 사용을 제안했습니다. 수정된 폭포수 모델은, 성공의 척도가 다양하기는 하지만, 오늘날 많은 프로젝트에 활용되고 있습니다.

 

애자일 개발 접근

애자일 개발 방식은 폭포수 모델의 일부 제한사항을 해결하려고 시도합니다. 애자일 방법(스크럼, 스프린트로도 알려진 애자일 개발론)은 반복이라는 짧은 사이클 개발 단위로, 반복 및 증분 진행하는 것에 초점을 맞춥니다. 반복 기간은 짧게는 1 주일에서 길게는 한 달 정도로 진행됩니다. 각 반복하는 동안에 개발 팀은 고객에 의해 설정된 우선 순위에 따라 기능의 작은 세트가 제대로 작동하는지 테스트하고 고객의 허용 기준에 맞는지 유효성을 검사합니다. 이후에는 존재하는 기능을 수정하고, 확장하고, 새로운 것을 추가하고, 발견된 결함을 고치게 됩니다. 이런 과정을 통해 잘못된 방향으로 너무 멀리 가기 전에 지속적인 고객 참여를 통하여 초기 방향의 문제와 변화를 탐지할 수 있습니다. 사이클 결과물이 단지 작은 부분의 구성일지라도, 각 반복 끝에서 잠재적인 소프트웨어 몸체를 가질 것입니다.

 

요구사항에 대한 애자일의 기본 관점

애자일 프로젝트에 적용되는 요구사항 관점은 다른 프로젝트에서 잘 적용할 수 있으며 좋은 생각입니다.

 

고객 참여

소프트웨어 개발 과정에서 고객의 협력은 프로젝트 성공 가능성을 높여줍니다. 이것은 폭포수 모델뿐만 아니라 애자일 개발에서도 마찬가지입니다. 두 방식의 차이점은 고객 참여의 시기입니다. 폭포수 프로젝트에서 고객은 전형적으로 초기

 단계에서 사업분석가의 이해, 문서화, 요구사항 확인을 돕는 정도입니다. 또한 고객은 나중에 인수 테스트 중에야 제품이 자신의 요구사항을 충족하는지에 대한 피드백을 제공하게 됩니다. 그에 비해서 개발 단계에서는 아주 적은 시간만 참여하게 되며, 이것은 고객 요구 변화에 맞게 프로젝트가 변화할 수 있는 기회가 줄어들게 됩니다.

애자일 프로젝트에서 고객(또는 그들을 대표하는 제품 소유자)은 프로젝트 전반에 걸쳐 지속적으로 참여합니다. 일부 애자일 프로젝트에서는 초기의 계획 순환 기간에, 제품 개발을 위한 예비 로드맵에 기여할 사용자 스토리를 정의하고 우선순위를 정하기 위해 사용자는 프로젝트 팀과 협업합니다. 사용자 스토리는 전형적으로 전통적인 기능 요구사항보다 덜 상세하므로, 사용자는 반복 주기에서 설계와 개발 활동 기간의 입력과 설명을 제공할 수 있어야 합니다. 또한 한 주기가 완료되면 새롭게 개발된 기능에 대한 테스트를 하고 피드백을 제공해야 합니다. 일반적으로 제품 소유자, 고객, 최종 사용자는 사용자 스토리 또는 다른 요구사항 작성에 참여해야 하지만, 이들이 효과적인 요구사항 방식에 훈련되지 않았을 수 있습니다. 조잡하게 작성된 사용자 스토리는 요구사항의 명확한 의사소통에 충분하지 않을 것입니다. 사용자 스토리를 누가 작성하는 것과는 상관없이, 그것을 구현하기 이전에 훌륭한 비즈니스 분석 기술을 가진 사람이 그 스토리를 검토하고 편집해야 합니다.

 

문서 상세화 수준

-폭포수 프로젝트에서 개발을 시작한 후에는 개발자아 고객은 거의 상호작용을 하지 않으므로, 요구사항은 시스템 동작, 데이터 관계, 상세한 세부사항에서 사용자 경험의 요구를 확정해야 합니다.-애자일 프로젝트에서 개발자와 고객의 긴밀한 협력은 일반적으로 기존 프로젝트보다 요구사항이 덜 상세하게 설명될 수 있음을 의미합니다. 대신에 사업 분석가들 또는 요구사항에 대한 책임이 있는 다른 사람들은 필요하면 대화와 문서를 통해 정확하게 만듭니다(2013 IIBA).-사람들은 애자일 프로젝트 팀은 요구사항을 작성하지 않아도 된다고 생각하곤 합니다. 그건 맞지 않습니다. 대신에 애자일 방법은 개발자와 테스터를 정확하게 안내하기 위한 최소 문서 수준으로 만드는 것을 권장합니다. 개발 및 테스트 팀이 필요로(또는 규정 또는 표준을 만족시키기 위해 요구되는) 하는 것 이상의 문서들은 낭비일 뿐입니다.-특정한 사용자 스토리는 위험하거나 중요한 기능으로 이루어진 전형적인 인수 테스트 폼으로 제공되는 세부사항이 필요할 수도 있습니다.

 

백로그와 우선순위 작업 애자일 프로젝트에서 제품 백로그(Backlog)는 팀이 수행할 작업 요청 목록을 포함합니다(2013 IIBA). 전형적으로 제품 백로그는 사용자 스토리로 구성되지만, 일부는 다른 요구사항, 비즈니스 프로세스, 수정할 결함을 가진 백로그도 포함합니다. 각 프로젝트는 단지 하나의 백로그를 포함해야 합니다 (Cohn 2010). 따라서, 결함은 새로운 사용자 스토리에 대한 우선순위에 대한 백로그에 표시해야 합니다. 일부 팀은 새로운 사용자 스토리 또는 예전 스토리의 변경으로 결함을 재수정합니다. 백로그는 스토리 카드나 도구에서 관리될 수 있습니다. 순수 애자일주의자는 카드 사용을 선호하지만, 큰 프로젝트나 분산된 팀들에게는 실용적이지 못합니다. 백로그의 우선순위 작업은 다가올 주기에 진행하거나 백로그에서 삭제될 작업 항목을 선택하는 지속적인 활동입니다. 백로그 아이템에 할당된 우선순위는 다음 주기까지는 지속해서 유지해야 합니다(Leffingwell 2011). 비즈니스 요구사항에 백로그 아이템을 추적하는 것은 우선순위 작업을 용이하게 합니다. 애자일 프로젝트뿐만 아니라, 모든 프로젝트에서 백로그에 남은 작업은 관리되어야 합니다.

 

시기

애자일 프로젝트는 근본적으로 전통적인 개발 프로젝트와 같은 유형의 요구사항 활동이 필요합니다. 사용자에게서 요구사항을 추출하고, 적절한 세부 수준의 각종 문서 요건을 분석하고, 요구사항이 프로젝트의 비즈니스 목표를 달성하는 지 확인할 필요가 있습니다. 그러나 세부 요구사항은 애자일 프로젝트 초기에 한꺼번에 작성되는 것은 아닙니다. 대신에 높은 수준의 요구사항(전형적으로 사용자 스토리에 포함된 것)은 초기 계획 및 우선순위에 대한 제품 백로그를 채우기 위해 도출됩니다.사용자 스토리는 구현을 위한 특정 주기에 할당되고, 각 세부사항은 주기를 진행하는 동안에 더분명해집니다. 그러나 중요한 성능, 가용성, 사용성 등 품질 목표)를 성취하기 위해 초기에 고려될 수 있도록 시스템의 구조가 비기능 요구사항에 대해 알아야 하는 것은 중요합니다.

 

 

[그림] 표준 요구사항 활동은 각 애자일 주기 반복 내에서 발생

 

에픽(서사시), 사용자 스토리 및 특성사용자 스토리는 어떤 사용자 요구를 분명히 하고, 의사소통을 구체화하기 위한 시작점으로서 역할을 하는 간결한 문장입니다. 사용자 스토리는 애자일 개발자들의 요구사항을 해결하기 위해 특별히 만들어졌습니다. 여러분은 사용자 요구사항을 알아보기 위해 유스 케이스 이름, 특성, 또는 프로세스 흐름을 선호할 수 있습니다. 요구사항의 이러한 종류를 설명하기 위해 선택하는 형식은 중요하지 않습니다. 사용자 스토리가 일반적으로 애자일 프로젝트에 사용되기에, 여기서는 주로 사용자 스토리를 언급합니다.사용자 스토리는 한 주기에서 모두 구현되는 크기로 만들어져야 합니다. 마이크 콘(Mike Cohn (2010)) 한 주기에서 모두 구현할 수 없는 너무 장황한 사용자 스토리를 에픽(epics; 서사시)라 정의했습니다. 이런 에픽은 여러 주기에 걸쳐 있으므로 작게 분할해야 합니다. 에픽을 작게 만들어서 사용자 스토리로 넣는 것을 종종 스토리 분해(story decomposition)라고 합니다(IIBA 2013). 

[그림] 에픽은 작은 에픽으로 만든 후에 사용자 스토리로 만든다.

 

특성(feature)은 사용자에게 가치를 제공하는 시스템 기능의 그룹입니다. 애자일 프로젝트 맥락에서, 특성은 개별 사용자 스토리, 다중 사용자 스토리, 개별 에픽, 다중 에픽들을 포함합니다. 예를 들어, 휴대폰 카메라의 줌 특성은 다음과 같은 서로 다른 사용자 스토리들을 가능하게 하기 위해 개발될 수 있습니다.-엄마로서, 딸의 조부모와 공유할 수 있도록 학교 공연 동안 내 딸의 인식 사진을 찍고 싶다. -조류 관찰자로서, 새들을 식별하려는 거리에서 조류의 명확한 사진을 찍고 싶다.비즈니스 요구사항에 맞춰 이야기의 가장 낮은 수준을 확인하면 팀이 그 고객에게 가치를 제공 할 수 있는 기능의 작은 세트를 확인할 수 있습니다. 이런 개념은 Mark Denne과 Jane Cleland-Huang에 의해 언급된 것처럼, 최소한의 시장성 특성(MMF; minimum (or minimal, or minimally) marketable feature)이라고도 불려집니다(2003).[중요] 여러분이 애자일 프로젝트에서 요구사항을 개발할 때, 스토리, 에픽, 특성 등으로 불려지는 것에 너무 걱정하지 말고, 사용자의 만족도를 위해 개발자를 안내해줄 수 있는 높은 품질의 요구사항을 개발하는 것에 더 집중해야 합니다.

 

<출처: Software Requirements, Karl Wiegers and Joy Beatty 저>