애자일 모델의 종류 쉽게 이야기

출처: mohamed_hassan on Pixabay

 

민첩하고 빠르게 움직이며 시장의 변화에 대응하자는 모델인 애자일 모델

고객과의 긴밀한 협력을 중시하고 나보다는 우리 그리고 융합을 원하는 애자일 모델의 종류에는 어떤 것들이 있을까요?

 

Q. 애자일 모델에는 어떤 종류가 있나요?

 

 애자일 모델에는 크게 스크럼(Scrum) 기법과 XP(eXtreme Progrmming) 기법이 있습니다.

왜 2개로 나누어져 있고 각각은 어떤 특징은 가지고 있을까요?

 

Q. 스크럼(Scrum) 기법이란 뭔가요?

 

 스크럼 기법은 팀 단위로 움직인다!라는 특징이 있습니다. 팀 중심으로 보다 빠르게 개발 효율성을 높이겠다는 것이죠. 아무래도 팀 단위로 빠르게 움직이다 보니 단기간 개발에 적합한 기법입니다.

팀원 구성은 PO, 스크럼 마스터, 개발팀 이렇게 구성되어있고 여기서 개발팀은 단순히 개발만 하는 사람만을 말하는 것은 아니고 디자이너, 개발자를 비롯해 제품 개발에 직접적으로 연관된 사람들을 이야기합니다.

 

Q. 그럼 각 구성원들은 무슨 일을 하는 걸까요?

 

 우선 PO(Product Owner) 제품의 책임자이죠? 일단 PO는 제품의 책임자로 요구사항을 작성하는 주최자입니다. 하여 백로그(Backlog)를 작성하죠. 요구사항이 생기면 백로그화 시켜서 업데이트를 해줍니다.
Backlog: 사용자의 요구사항이 작성된 문서 (이때 사용자의 요구사항은 단순히 '클릭을 원함'과 같이 작성하는 것이 아니라 서술형 '매일 오후 9시 컴퓨터를 킬 때 전원 버튼을 누르는데...'와 같은 형태로 작성된 것을 말합니다.)에 우선순위까지 결정된 것

 

 스크럼 마스터는 매일매일 스크럼 회의를 주최하는 사람입니다. 단기간에 개발하기 때문에 매일매일 회의를 하여 개발 방향과 현재 진행상황과 목표 상황과 같은 전체적인 내용을 브리핑하는 것입니다. 쉽게 말하면 업무를 닦달하는 사람이죠.

 

 개발팀은 제품의 개발을 위해 업무를 진행하는 사람들을 말합니다. 제품을 디자인하거나 개발을 하죠.

 

Q. 스크럼 기법은 개발을 어떻게 진행할까요?

 

 우선 제품 백로그를 세웁니다.

 

 그 후 스프린트 계획 회의를 하게 되는 데 이 스프린트 계획 회의 단계에서 우선순위가 높은 백로그를 선정하고 Task 단위로 잘라서 분배합니다. 그리고 각 Task 기간을 산정하게 되죠. 그다음 각 Task의 기간을 모아 단기 일정을 수립하게 됩니다.

 

 그다음 스프린트를 진행합니다. 제품 개발을 진행하는 것이죠. 단기간으로 개발을 진행하는 것이다 보니 개발 기간은 길지 않습니다. 보통 2~4주 정도로 개발을 진행하고 개발 과정 중에는 서로의 의사소통을 활발히 교환합니다.

 

 그렇게 개발된 결과물을 가지고 스프린트 검토회의를 진행합니다. 검토회의에서 요구사항을 얼마나 잘 반영했는가? TEST를 하게 되고 테스트가 완료되었다면 개발이 완료되는 것이고 그렇지 않다면 사용자의 의견을 다시 백로그에 반영하고 다음 스프린트에 반영합니다. 그리고 다시 스프린트 검토회의를 거치게 되는 것이죠.

 

 마지막 단계로는 스프린트 회고 작성입니다. 이 전체 과정에 대한 회고록을 작성, 검토하는 것이죠.

 

Q. XP(eXtreme Programming) 기법은 뭔가요?

 

 XP 기법은 최근 핫한 기법으로 알고 있습니다. 의사소통을 가장 중요하게 생각하고 상대방과 상대방의 의견을 존중합니다. 어떤 문제가 발생했을 때 책임을 나눠가진다는 특징도 있습니다. 원팀인 거죠!

'근무시간에만 최선을 다해! 야근은 하지 마! 여러 사람과 의견을 나누면서 진행하자!'인 거죠.

가장 고객과 가까운 기법이며 고객의 참여와 개발과정의 신속함이 중요합니다.

가장 큰 특징으로는 테스트를 할 때 고객이 직접 테스트를 한다는 점입니다. 그렇다 보니 고객 만족이 극대화되죠.

 

Q. XP 기법은 개발이 어떻게 진행될까요?

 

 우선 고객의 요구사항이 가장 중요합니다. 고객이 테스트를 원하면 테스트 시나리오도 전달합니다.

 

그 후 공개 계획을 수립하게 되고 사용자와 소통, 사용자의 요구사항을 정확하게 구현하기 위한 시제품을 구현합니다. 고객들과 많은 이야기를 나누고 그 나눈 이야기를 기초로 기간 산정을 하게 됩니다. 이 과정을 Spike라고 합니다.

 

 기간이 대략적으로 산정이 되었기 때문에 Iteraction(반복) 과정을 거칩니다. 공개 계획을 세분화시켜 거 구체적인 계획을 세우고 개발이 진행되는 것이죠.

 

 Iteraction 단계를 다 거치고 나면 완제품이든 아니면 부분적으로 만든 일부 기능이든 인수 검사를 진행하게 됩니다.

이 인수검사 단계에서 무엇이 문제인지 어떤 것을 더 수정하면 좋을지 어떤 오류가 있는지 찾아내고 다시 개발을 진행합니다. 이 인수검사 단계에서는 고객이 직접 검사합니다.

 

 만약 인수 검사 단계에서 고객이 만족한다면 제품을 외부에 배포 혹은 발표하게 됩니다. 

 

애자일에서는 고객의 요구사항을 정말 중요하게 생각하는데요.

요구사항에 대해서 조금만 더 알아봅시다.

 

Q. 요구사항이란 뭘까요?

 

 요구사항이란 사용자 즉 고객이 나는 이런 기능이 필요해요.라고 말하는 모든 것 혹은 운영에 필요한 제약조건 및 서비스와 관련된 모든 조건을 말합니다.

SW 개발을 어떻게 해야 하는 가에 대한 가이드라인도 요구사항이라 말할 수 있습니다.

 

 이 요구사항은 프로젝트를 유지 보수할 때 필요한 기준과 근거를 제공해주고 개발에 참여하는 모든 이해관계자들이 의사소통을 원활하게 할 수 있도록 도와줍니다.

 

Q. 요구사항에는 어떤 종류가 있을까요?

 

 요구사항에는 크게 기능 요구사항과 비기능 요구사항이 있습니다.

 

 기능 요구사항이란 시스템이 어떤 기능을 수행하는지에 대한 사항 그리고 시스템이 수행할 기능! 사용자가 제공받고자 하는 서비스를 이야기합니다.

 

 비기능 요구사항이란 기능 요구사항이 아닌 보안 관련된 문제, 성능은 어떻게 해야 하는 것이 좋을지에 대한 문제, 품질이 좋은지 나쁜지에 대한 문제와 관련된 내용을 비기능 요구사항이라고 합니다. 법적인 문제 역시 비기능 요구사항입니다.

 

그 외 사용자 요구사항(사용자 관점에서 본 것)과 시스템 요구사항(개발자 관점에서 본 것)이 있습니다.

 

Q. 요구사항에도 어떤 과정이 있을까요?

 

 요구사항은 도출 작업 -> 요구사항 분석 -> 요구사항 명세 -> 요구사항 확인 과정을 거치게 됩니다.

 

요구사항 도출 작업이란 요구사항을 식별하고 어떤 요구사항인가? 이해하는 과정을 말합니다.

 

요구사항 분석이란 모든 요구사항을 다 받아들일 수 없기 때문에 비용, 일정에 대한 제약을 설정하여 소프트웨어의 개발 범위를 파악해보는 것입니다.

 

요구사항 명세란 요구사항 명세서 즉 문서를 이야기합니다. 이 문서는 쉽게 이해할 수 있도록 서술해야 합니다. 그리고 빼놓지 않고 명확하게 표기해주는 것이 중요합니다. 누가 봐도 알 수 있게 말이죠.

 

요구사항 분석이란 요구사항 명세서가 잘 적혀있나? 정확한가? 확인하는 단계입니다.