개발 방법론 - 스프린트, 스크럼, 애자일
나는 가끔 떠오르는 아이디어로 코딩을 하는 경우가 있는데, 작업을 하다 보면 초반에는 어느 정도 그림이 나오면서 작업이 순조롭게 진행되다가 마무리 단계에서는 예상하지 못한 사소한 변경사항과 작업했던 내용을 전반적으로 수정해야 하는 상황이 발생해 소요시간이 대폭 증가한다. 참 아이러니하게 효율적이지 못한 방법으로 여태 코딩을 하지 않았나 싶다.
위 사진에 첫 번째 처럼 나는 코딩을 해왔고 그림이 어느 정도 모양이 나왔을 때, 사소한 수정사항과 변경사항이 눈에 띄기 시작한다. 마지막 결과가 나왔을 때는 정확한 수정사항이 도출되며, 고쳐야 하는 부분이 커져 작업시간은 급격하게 증가한다. 여태 내가 해왔던 스타일이다.. ㅠ
두 번째는 첫 번째와는 시작부터 다르다. 어느정도 밑그림이라는 설계로 시작한다. 대략적인 윤곽을 잡아서 가능한 변경사항을 세부적으로 조정을 한다. 그리고 설계도를 바탕으로 완성을 하게 된다. 기본적으로 완벽한 설계도를 바탕으로 만들게 된다면 결과물은 완벽하게 나올 수밖에 없다. 물론 설계단계에서 놓친 부분이 있다면 첫 번째와 같이 작업시간은 증가하겠지만, 첫 번째에서 끝 단계에서 발견했던 문제를 두 번째에서는 설계 단계에서 파악할 수 있다는 장점이 있어 효율적으로 보인다.
혼자 코딩하는데에도 문제가 있는데 다수의 인원은 어떨까.. 이렇게 소프트웨어 개발 방법론에 대해 공부해야 할 필요성을 느껴 간단한 설명과 개인적인 생각을 정리해본다. 개발론에서 자주 언급되는 애자일, 스크럼, 스프린트를 알아보자.
애자일(Agile)
애자일이라는 주제는 다소 이해하기 어려운 요소가 많고 보는 시각에 따라 다르게 이해할 수 있다고 한다. 애자일은 방법론이라고 이야기한다. '방법론'이라는 단어가 생소하다고 느껴진다면 '프로세스'로 바꾸어 생각해보자.
Agile의 사전적 의미는 날렵한, 민첩한. 으로 풀이되는데, 유연하게 일해서 빠르게 끝낸다는 의미인 것인가..
애자일 방법론은 요구사항이 당연히 변화한다는 것을 전제로 두고, 변하는 요구사항을 민첩하게, 재빠르게 대응하며 소프트웨어 개발을 하기 위한 방법론이라 한다.
기본적으로 폭포수 모델이라는 것을 알아야한다. 왜냐하면 폭포수 모델을 보완한 것이 애자일 개발 프로세스이기 때문이다.
폭포수 모델은 하나의 프로세스에서 떨어지면 올라갈 수 없는 것이 폭포수와 같아 붙여진 이름이다. 각 개발 단계에서 정확하게 매듭을 짓고 다음 단계로 넘어간다는 말이다. 폭포수의 단점은 각각의 프로세스가 종료되지 않으면 다음 단계가 실행할 수 없어 소요되는 시간이 크다, 요구분석에 오랜 시간이 걸린다, 등 학교에서 배웠던 것들이 조금씩 생각이 난다.
이 폭포수 모델은 크고 복잡한 시스템에는 적합하지 않다. 왜냐하면 다음 단계에 대한 이해나 경험이 없기 때문에 사전에 모든 요구사항을 반영할 수 없다는 것 이다. 예를 들어 고객은 실제로 동작하는 프로토타입을 경험해보지 않는다면 정확히 어떤 것들이 수정되어야 하는지 알 수 없가 없다. 분명 완성되어 고객이 사용했을 때, 수정사항이 발생할 것이다..
또한 설계 후 구현할 때의 난이도를 예측하기 어렵다는 단점도 존재한다. 설계시 이를 미리 예측해 반영해야 하는데, 설계가 완료 후 구현 단계에서 이를 파악할 수 있다..
그래서 폭포수 모델을 보완해 나온것이 애자일 모델이다.
폭포수 모델과 애자일 모델의 다른 점은 문서를 기반으로 개발하는 방법이 아니라, 실질적인 코드를 기반한 방법론이다. 폭포수 모델은 계획을 통해서 주도해 나갔다면 애자일은 앞을 예측하기보다는 일정한 주기를 갖고 끊임없이 프로토 타입을 만들며 그때그때 필요한 요구사항을 반영하고 수정하며 소프트웨어를 개발해 나가는 Adaptive Style이라고 할 수 있다.
그래서 애자일이 무엇이냐 한다면 특정 개발 방법론을 가리키는 말은 아니고 낭비없이 신속하게 개발을 가능하게 하는 다양한 방법론을 통틀어 말한다.
애자일 개발 프로세스로 불리는 스크럼(Scrum)
스크럼은 럭비에서 사용되는 용어이다. 럭비에서는 스크럼(Scrum)과 라인 아웃(Line Out)이라는 두 가지 기본 대형이 있는데, 이중 스크럼은 반칙으로 경기가 중단됐을 때 쓰는 대형이다.
이런 형식의 대형으로 스크럼은 하나의 팀이라는 단어를 개발에 적용시켜 효과적인 결과를 얻기 위함이라고 한다.
스크럼 개발 프로세스
1. 제품 기능 목록 작성
사용자의 요구사항 목록으로 폭포수 모델과는 다르게 단계가 끝나더라도 수정이 가능하다. 하지만 보통 한 주기가 끝날 때까지 제품의 기능 목록을 수정하지 않는다.
2. 스프린트 계획 회의
스프린트는 전력질주라는 뜻으로 반복적인 개발 주기를 의미한다. 반복 주기는 스프린트 계획 회의를 통해 결정하고 보통은 2~4주로 정한다고 한다. 개발 팀의 경험과 노하우가 풍부하다면 2주 정도의 짧은 주기로 정하지만 요구사항의 변화가 잦고 개발 팀의 역량이 부족하다면 4주 정도의 기간을 스프린트의 주기로 설정한다. 이때 정한 주기를 반복적으로 개발한다.
구현 목록은 스프린트 계획 회의에서 걸정하고 작업 목록 작성이 완료되면 스프린트 주기는 완성된다. 스프린트 주기가 결정되면 개발 팀원들은 역량에 맞게 해당 기간 내에 작업을 전력질주해야 한다.
스프린트 주기가 결정됐다면 스프린트의 목표와 내용이 팀원의 동의 없이 바뀔 수 없다.
3. 스프린트 수행
정해진 스프린트 기간 동안 결과물을 개발을 진행한다.
3.1 일일 스크럼 회의
매일 진행하는 일일 스크럼 회의는 짧게 15분 정도의 시간으로 진행 상황 점검이나 어제 작업한 일, 문제점, 개별 팀원 진척 상황 등을 회의한다고 함. 물론 조직마다 다르겠지만..
4. 스프린트 개발 완료 및 검토회의
모든 스프린트 주기가 끝나 결과물이 완성된다. 최종 제품이 나오면 스프린트 검토 회의를 진행하고 처음에 고객이 했던 제품이 얼마나 부합되는지 시연 후 개선점 등 피드백을 받게 된다.
5. 스프린트 회고
스프린트 활동을 되돌아보며 개선점을 검토한다. 여기선 팀의 단점보다는 강점을 찾아 극대화하는 것에 중점을 둔다. 또한 문제점을 확인하고 기록하는 정도로만 회고를 진행한다.
여기까지 간단하게 스크럼 방식을 살펴보았다. 스크럼 방식의 장단점을 알아보자
스크럼 방식 장점
- 스프린트마다 실행 가능한 결과물을 통해 사용자와 충분한 의견을 나눌 수 있다.
- 일일회의를 통해 팀원 간의 신속한 조율이 가능
- 다른 개발 방법론에 비해 비교적 단순하고 실천 지향적
스크럼 방식 단점
- 추가 작업 시간이 필요(스프린트가 끝날 때마다 실행 가능한 결과물이 필요하므로 작업 시간이 더 필요하다)
- 프로세스 품질 평가 불가
여기까지 애자일, 스크럼, 스프린트에 대해서 알아보았다. 개인적으로 매일 스크럼 회의를 진행하고 문서기반이 아닌 코드를 기반으로 한 스크럼 방식을 좀 더 나아보인다.
출처
소프트웨어 개발 방법론 (애자일 / 스크럼 )
안녕하세요! 오늘은 조금 생소한 단어들을 공부해보려고 해요 :) 혹시 애자일 / 스크럼..이런 단어들을 들어보신적 있으신가요? 저는 아직 소프트웨어 개발 현업에서 종사하고 있지는 않아서 이
zeddios.tistory.com