말로만 들어왔던 애자일 방법론에 대해서 더 잘 이해하기 위해서 정리해보려고 합니다.
애자일이 중요시 여기는 것 들
애자일 방법론에서 강조하는 특징들을 정리해보겠습니다.
첫번째 — 협력
프론트엔드 개발팀 A씨는 최근 개발 속도를 2배로 향상 시킬 수 있는 엄청난 방법을 깨달았습니다. 하지만 팀 내에서는 서로 협력하는 문화가 없었기 때문에 A씨는 그 방법을 굳이 팀원들에게 공유하지 않았고, 본인만 높은 성과를 받으며 떵떵거릴 수 있었습니다. 하지만, 같은 팀원들은 A씨의 코드가 어색하고 읽기 힘들었고 A씨와 같이 일하고 싶지 않은 마음이 하나둘씩 생겨났습니다.
이해하기 쉽게 예시를 들어보았습니다. 애자일에서는 팀원 간 협력을 중요한 요소로 생각합니다.
두번째 — 피드백
일정에 쫓겨 개발만 하다보면 내 코드를 점검할 시간이 줄어들게 됩니다. 다른 사람들에게 내 코드를 보여주고 피드백을 받으면서 서로 같이 성장할 수 있게 됩니다.
애자일은 불확실한 상황에서 빛을 발합니다.
애자일이 추구하는 가치는 “처음부터 완벽한 계획”이 아닌 “간소한 계획과 유연한 대처”입니다.
각 단계가 순차적으로 실행되고 다시 돌아갈 수 없는 폭포수 모델은 소프트웨어보다는 제조업에 더 적합한 방법론이 아닐까 싶습니다. 소프트웨어는 변화가 매우 많기 때문에 짧은 주기의 개발 단위를 여러번 반복하는 “애자일” 방법론이 더 적합하다는 의견이 많습니다.
애자일의 장점
애자일 방법론을 사용하면,
- 점진적으로 테스트 할 수 있어서 버그를 더 빠르게 발견 할 수 있습니다.
- 수정과 변경에 유연합니다.
- 프로젝트를 시작할때 계획에 버리는 시간을 줄일 수 있습니다.
- 서비스가 더 빨리 출시됩니다.
물론 최종적으로 완성되는 시점은 애자일이나 워터폴이나 똑같습니다. 개발 속도가 빨라지는게 아닙니다. 다만, 애자일은 제품 초기 버전이 워터폴보다 훨씬 빠르게 출시되는 장점이 있습니다. 그래서 고객의 피드백을 더 빨리 받아서 제품을 개선 할 수 있는 것 이죠. 같은 개발 기간동안, 고객이 여러번 피드백해서 완성된 제품과 한번의 피드백도 없이 개발된 제품 둘중에 어떤게 더 매력적일지는 따로 말 안해도 아실거라고 생각합니다.
워터폴은 데드라인을 정해놓고 프로젝트가 진행됩니다. 예를들어, 디자인은 디자인 마감 기한 프론트 개발은 프론트 마감 기한을 꼭 지켜야 일정에 차질이 안생기죠. 그래서 어떤 사소한 버그를 발견하게 되어도 일정에 문제가 생길까봐 그냥 지나치는 경우도 종종 생기게 됩니다.
하지만, 애자일에서는 데드라인을 정하지 않고 현재 개발 진행 속도를 추정해서 언제쯤 완성되겠다라고 하는 막연한 기한을 지속적으로 수정하게 됩니다. 딱 정해둔 데드라인은 없지만 대략적으로 “다음달 말 쯤이면 그 기능이 완성될것같아요” 정도의 말은 해줄 수 있어야 합니다. 기한을 유연하게 잡아두어야 외부의 추가요청 / 수정요청을 쉽게 받아줄 수 있는 여유가 생기겠죠.
다만, 데드라인이 없기 때문에 애자일 속도(프로젝트 진행 속도)는 측정해야 합니다. 그래야 이 속도로 진행됬을때 대략 다음달 말쯤 완성될것이라는 기한 정도는 뽑아낼 수 있기 때문이죠. 일정을 맞추기 위해서 야근을 불사하는것은 애자일이 추구하는 가치와 맞지 않습니다.
애자일에서의 스프린트(Sprint)란?
‘sprint’란 전력질주라는 뜻입니다. 소프트웨어를 개발할때 한번의 장거리 달리기가 아니라 여러번의 단거리 전력질주를 하자는것이죠. 스프린트 기간은 대략 1~2주 단위로 잡습니다.
워터폴에서는 프로젝트 진행에서 데드라인을 제일 중요시 여기지만,
애자일에서는 애자일속도(프로젝트 진행 속도)를 제일 중요시 여깁니다.
애자일에서의 일의 단위
애자일은 하나의 일을 여러개의 단위로 쪼갭니다.
Theme > Epic > Story(기본단위) > Task(티켓 할당 단위)
각 작업의 단위를 이해하기 쉽게 예시를 들어보겠습니다. 온라인 쇼핑몰에서 고객의 주문을 처리하는 작업을 여러개의 단위로 쪼개보겠습니다.
- Theme: 종합 온라인 쇼핑몰 구축
- Epic: 고객은 스마트폰이나 데스크탑으로 주문을 할 수 있다.
- Story: 고객(누가)은 주문을 하기 위해서(왜) 배송 시간을 고를 수 있어야 한다.(행동)
- Task: 배송 시간을 선택할 수 있는 기능을 구현한다.
각 작업의 단위에서 가장 중요하고 기본이 되는 단위는 ‘Story’입니다. Story는 특이하게도 ‘누가 왜 그 행동을 하는가’를 말합니다. 우리가 구축하고자 하는 시스템에서의 고객의 행동을 Story로 만든것이죠.
고객의 행동 = 스토리입니다.
그런 고객의 스토리들이 모여서 하나의 에픽을 구성합니다. 주문을 하는 행위 는 배송시간을 고르는 행위를 포함하고 있습니다.
‘Task’는 고객이 그 행동을 할 수 있도록 실제로 개발 해야 하는 단위를 나타냅니다. 각 Task가 담당 개발자들에게 티켓으로 할당 되는 거죠. 이 Task를 좀 더 잘게 나눠서 Sub Task를 구성 할 수도 있습니다.
애자일 팀에서는 매일 아침 스탠드업 미팅을 합니다. 그 미팅에서 다루는 일의 단위는 Task나 Sub Task입니다.
애자일에서 스크럼(Scrum)이란?
Scrum이라는것은 럭비에서 나온 단어라고 합니다. 럭비 경기 중 반칙이 생기면 심판이 잠깐 경기를 멈추고 반칙장소에서 다시 경기를 재개합니다. 그때 양팀 선수들이 서로 공을 뺏으려고 저런 이상한 동작을 하는것이죠. 아마 저 가운데 공이 있겠죠?
왜 애자일에서 이런 럭비 단어를 사용할까요?
정해진 스프린트(전력질주) 기간동안 기능을 완성 시키기 위해서 협력하는 팀원의 모습이 럭비의 스크럼과 비슷하여 이런 이름이 지어졌습니다.
스프린트 기간 동안 팀원들은 이런 일들을 합니다.
애자일 보드에서 티켓을 골라서 본인에게 할당하고 In Progress로 옮깁니다. 작업을 마치면 Review탭으로 옮겨놓고 리뷰가 끝나면 Done으로 옮깁니다.
팀원들은 매일 아침 스탠드업 미팅에 참여합니다. 말그대로 일어서서 할 정도로 간단한 미팅이라는 뜻입니다. 아침에 가볍게 어제 한일, 오늘 할 일, 발생한 이슈나 어려움등을 공유합니다. 서로 업무 공유가 잘 된다는점에서 큰 장점이 있는 것 같습니다.
스프린트 기간(대략 1~2주)이 종료되면 이번 스프린트에서의 이슈들을 리뷰하고 더 좋은 코드, 작업방식을 개선하기 위한 스프린트 미팅이 있습니다.
애자일 팀이 하나의 스프린트를 마무리하면 고객에게 몇가지 스토리를 전달 할 수 있게 됩니다. 예를들어, 2주간의 스프린트 기간 동안 처리한 Task들이 모여서 “고객이 주문을 하기 위해서 배송시간을 선택한다.” 라는 스토리를 제공할 수 있게 된거죠.
스토리의 단위
스토리의 단위를 너무 크게 잡으면 스프린트 기간 동안 단 하나의 스토리도 완성하지 못할 수 도 있습니다. 어느정도의 규모로 스토리를 가져갈지는 경험에서 나올 수 밖에 없기 때문에 정하기 애매한 경우에는 팀원간의 합의를 통해서 정하곤 합니다.
스토리 포인트 플래닝 미팅
스크럼을 진지하게 사용하는 팀에서는 각 스토리에 스토리 포인트라는 점수를 부여해서 각 작업의 규모를 측정합니다. 만약 최근 2주간의 스프린트에서 50 스토리 포인트를 완성 시켰다고 해봅시다. 이 애자일 팀은 스프린트 기간 동안 보통 50 포인트 정도 얻을 수 있는 팀이라는 기준이 생겼습니다. 이것이 바로 애자일 속도입니다. 다음 스프린트때도 비슷하거나 더 많은 포인트를 얻기 위해서 노력하면 됩니다.
이번 스프린트에서 구현해야할 스토리들을 모아놓고 각 스토리들의 포인트(일정)를 부여 하는 미팅을 “스토리 포인트 플래닝 미팅”이라고 합니다.
스프린트 계획(Sprint Planning) 미팅
각 스토리들이 대략 얼마나 걸릴지 일정을 산정하는 스토리 포인트 플래닝 미팅을 마치고 나면 이제 실제로 이번 스프린트 기간 동안 처리해야할 스토리들을 선정해야 합니다.
저번 스프린트때 50정도 처리했으니.. 다음 스프린트때도 50정도 채우자. 애자일 보드에 있는것들 중에서 중요한것들 위주로 50을 채워보자.
스탠드업 미팅
위에서 잠깐 소개했지만, 애자일 팀이 한데 모여 15분정도 간단하게 자신이 처리하고 있는 태스크의 상황을 팀원들에게 공유하는 자리입니다. 예상치 못한 이슈때문에 개발이 더뎌질수있는데 이 스탠드업 미팅 자리에서 그런 어려움을 팀원들에게 얘기하고 도움을 받을 수 있습니다.
스탠드업 미팅은 보통,
- 아침에 합니다.
- 어제 한일, 오늘 할 일 중 어려움을 겪는 부분을 팀원들에게 공유하고 도움을 받습니다.
- 약 10~15분의 시간을 넘기지 않도록 주의합니다.
스프린트 리뷰 미팅
스프린트가 마무리 되면 리뷰를 해야 합니다. 팀원 각각이 완성한 태스크가 모여 스토리가 잘 만들어진 데모를 보면서 축하하기도 하고, 완성되지 못한 스토리가 있다면 원인을 분석하고 검토합니다. 팀의 애자일 속도도 리뷰 미팅에서 지속적으로 체크해서 빨라지고 있는지 느려지고 있는지도 체크하는것이 좋습니다. 그리고 미팅 내용을 문서화해서 히스토리를 쌓아두는것도 좋은 방법입니다.
칸반 보드
일본어 ‘칸반’은 우리말로 간판, 게시판 정도로 해석됩니다.
도요타에서 생산 효율을 높이기 위해서 처음 사용한 방법이라 이런 이름이 지어졌고, 이 칸반에 원재료가 제품이 될때까지 들인 리소스를 왼쪽에서 오른쪽으로 쭉 나열하여 체크 했다고 합니다.
칸반 방식에서는 스프린트를 나누지 않습니다. 단지 백로그(해야할일을 포스트잇으로 붙여놓은곳)에 새로운 일이 계속 쌓이고 작업자는 백로그에서 일을 꺼내서 하는 프로세스입니다.
도요타에서는 하루에 딱 만대의 자동차만 생산하는 원칙을 고수했다고 합니다. 왜냐면, 그 이상 생산하려고 했을때 일의 능률, 효율, 생산성이 오히려 떨어졌기 때문입니다. 그래서 칸반에 있는 백로그의 최대 개수를 지정해두고 그 이상은 절대 추가 하지 않습니다. 일의 상한선을 정해두는것이죠.
애자일팀에서도 동시에 진행중인 태스크의 숫자를 제한할 필요가 있습니다. 일을 동시에 너무 많이 처리하면 완료기간이 늘어나게되고 고객에게 빠르게 제품을 전달하는 애자일의 가치에 어긋나게 됩니다.
스프린트가 진행중일때 스크럼에서는 어떤 엔지니어가 본인의 태스크를 빠르게 끝냈다면 다른 엔지니어의 일을 대신 처리해주는등, 스프린트 기간동안 만들기로 약속한 스토리를 고객에게 전달하기 위해서 최선을 다합니다. 반면, 칸반에서는 일이 끝났을때 그저 백로그에서 다음 할일을 찾아서 PM과 상의할 뿐이죠.
소프트웨어 프로젝트 관리
칸반과 스크럼은 상황에 따라서 다르게 선택해야합니다.
스크럼 : 전문가 그룹인 경우
이미 충분한 경험이 있는 전문가들의 그룹인 경우 스크럼이 적합합니다. 왜냐면, 이미 언어와 라이브러리에 친숙한 상태에서 각 스토리의 포인트를 예측하는데 이견이 많지 않을 것 이기 때문입니다. 또한 스토리를 제공하고자 하는 고객이 뚜렷한 경우에 사용합니다.
칸반 : 기술 개발인 경우
고객에게 어떤 가치를 제공하는 서비스를 만드는게 아니라, 기술 자체를 개발하는 경우에는 오히려 칸반 방식이 더 적합할 수 있습니다. 왜냐면, 스프린트가 끝난다고 하더라도 유의미한 스토리가 잘 나오지도 않을 뿐더러(기술적 어려움 때문에), 팀 또는 조직 내에서 사용할 기술을 만드는 프로젝트에서는 “태스크를 세분화 하는것이 가장 중요하기 때문입니다.”
출처
