brunch

You can make anything
by writing

C.S.Lewis

by Ruth Hyojin Nam Jul 31. 2024

[SW프로세스 II] 애자일 모델에 기반한 프로세스

소프트웨어 개발 프로세스의 또다른 모델인 애자일 중 Scrum 에 기반한 프로세스를 살펴보겠습니다. 


Agile model


애자일은 특정 개발 방법론의 명칭이라기 보다 '날렵하다, 민첩하다' 라는 의미로 다양한 방법론의 전체를 일컫는 것으로, 애자일 모델에는 익스트림 프로그래밍(XP), 칸반(Kanban), 스크럼(Scrum) 등의 방법론이 있습니다. 


애자일의 특징은 초기에 문서를 작성하느라 많은 시간을 보내는 대신 생산성과 품질을 높여서 작동하는 소프트웨어를 만들어서 고객의 손에 신속하게 전달하는 것을 목표로 합니다. 

또 개발이 진행되는 동안에도 고객의 개입을 허용하고 분석, 설계, 개발, 테스트를 동시에 수행함으로써 빠르고 반복적이고 점진적으로 작업이 진행되는 특징을 가지고 있습니다.




애자일 개발 방법론 중 살펴보게될 스크럼 개발 프로세스는, 

계획과 종료 단계는 명확하지만 설계, 개발, 테스트는 애자일 방법론의 실천 방법 및 활동을 이용하는 방법입니다. 스크럼 방법론은 계획 단계에서 최종 유저⋅고객⋅스크럼 팀⋅기타 이해 당사자들이 모여 개발할 제품에 대한 요구사항 목록과 이에 대한 우선순위를 결정하여 진행합니다. 스크럼 방법론에 대한 특징은 다음과 같습니다.


스크럼의 특징  

    스프린트(1~4주) 기간을 반복하여 개발을 진행하며 스프린트 기간이 넘으면 기간을 연장하지 않고 다음 주기로 업무를 배치한다.  

    스프린트가 진행되는 동안 선택된 항목(할 일 목록)들은 바뀌지 않는다.  

    스프린트 종료시점에 이해당사자들과 스프린트를 리뷰하고 팀이 만든 결과물을 데모(시연)한다. 이때 나온 피드백을 다음 스프린트에 반영한다.  

    스크럼은 스프린트의 종료 시점에 코드 통합 및 테스트 완료된 잠재적으로 출시가 가능한 작동하는 제품이 나와야 한다.  




스크럼에 기반한 협업 프로세스

스크럼 방법론에서 테스트는 개발 프로세스에서 테스트 대상에 따라 테스트 수행을 구체화하기 어려운 측면이 있습니다. 또, 고객의 피드백이 중요하기 때문에 고객의 참여 여부와 협력 정도에 따라 제품의 품질 차이가 발생할 가능성도 높습니다. 그래서 소프트웨어 테스팅 측면에서 개발 프로세스를 테스트 주도 개발TDD, Test Driven Development로 실천 방법을 제시하고 있으나 개발자 프로그래밍 레벨의 테스트에 제한되는 단점이 있습니다. 


이런 단점들을 해소하고 품질을 확보하기 위한 방법으로 개발과 병행하여 수행되는 테스트 프로세스를 정의하여 프로세스의 동시성을 확보하는 방법이 있습니다. 전체 애자일 개발 프로세스의 민첩성은 유지하면서 제품의 품질 향상을 도모하는 것이 주요 목적이며 스프린트 내 테스트를 반복적이고 점진적으로 수행함으로써 테스트 활동이 강화되고 결함은 줄이며 결함 수정 지연 시간은 감소하는 것을 목표로 하는 방법입니다. 

 

스크럼 프로세스는 스프린트 기간안에 요구사항을 분석하여 작업 목록을 도출하고 도출된 작업의 우선순위를 선정합니다. 이 후 작업을 수행할 작업자와 작업 시간을 할당하고 스프린트를 진행합니다. 기획, 디자인, 개발, 테스트 각 작업은 스프린트 기간 중에 동시에 진행되고 일일 진척 상황 미팅을 진행하여 각자의 작업 현황과 해결이 필요한 문제 상황 등 피드백을 공유합니다. 

스프린트가 종료되면 이해 당사자들과 함께 스프린트 리뷰를 진행합니다. 이때 결과물에 대한 인수 테스트와 데모를 수행하고 제품을 출시합니다. 리뷰 중 확인된 피드백은 다음 스프린트에 반영합니다. 




테스트 프로세스

스크럼 프로세스에서의 테스트 프로세스는, 

스프린트 전 요구사항 분석을 통해 작업 목록이 도출되면 전달된 목록을 기반으로 1)테스트 대상을 분석하고 범위를 선정하여 테스트 전략을 계획합니다. 계획이 수립되면 스프린트 기간 중에 테스트 범위를 대상으로 2)테스트 케이스를 설계하고 유저 스토리 기반으로 3)테스트를 수행합니다. 이때 발견한 결함을 기록하고 관리하며 수정 여부에 따라 테스트 활동을 반복합니다. 스프린트가 종료되고 제품을 출시하기 전 스프린트 반복 주기별로 배포된 3)코드를 통합하고 시스템 테스트와 인수 테스트를 최종적으로 진행합니다. 보고된 결함이 모두 수정되거나 또는 다음 스프린트로 이관되면 현재 스프린트의 결과물에 대한 테스트 종료를 보고하고 완료조건을 평가하여 제품을 출시합니다.


스크럼에서 테스트 프로세스의 특징을 스프린트 기간에 개발 작업이 진행되는 동안 테스트 설계와 시나리오 작성 그리고 테스트 실행이 설계와 함께 스프린트 타임박스 안에서 동시에 수행한다고 설명했습니다.

여기서 말한 동시 진행은 테스트 설계와 작성, 실행이 뒤섞여 순서 없이 진행되는 것이 아니라 각각의 수행 단계별로 고정된 일정은 없으나 같은 기간안에 절차를 갖고 업무가 진행되는 것을 의미합니다. 

예를 들어 스크럼 기간을 2주로 산정했다면 해당 기간 내에 기획과 개발의 설계, 구현이 진행되고 같은 기간 안에 절차에 따라 테스트 범위를 산정하여 테스트 케이스를 작성하고 테스트를 수행하는 것입니다. 다만 애자일의 특성상 변경과 변화가 지속적으로 발생하기 때문에 주어진 기간과 업무도 유연하게 대응하는 것이 필요합니다. 


스프린트 기간에 진행되는 테스트 실행은 테스트 가능한 페이지가 완성되면 유저 스토리 관점에서 기능 레벨 테스트를 수행하고 이후 유저 스토리를 기반으로 모듈 간 인터페이스를 포함한 유저의 비즈니스 또는 이벤트 시나리오에 대해 테스트를 수행합니다. 그리고 스프린트가 반복될 때마다 점진적 통합 테스트를 수행합니다.


스프린트가 종료되면 이해 당사자들과 함께 스프린트 리뷰를 진행합니다. 보고된 결함이 모두 수정되거나 또는 다음 스프린트로 이관되면 현재 스프린트의 결과물에 대한 완료조건을 평가하여 테스트 종료를 보고합니다. 리뷰 중 확인된 피드백은 다음 스프린트에 반영하는 것으로 프로세스가 종료됩니다. 

작가의 이전글 [SW프로세스 I] 폭포수 모델에 기반한 프로세스
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari