agile 방법론과 스크럼 계획 세우기

Agile 프로세스 모델이란

 

agile 방법론은 소프트웨어 하나를 만드는데 너무 시간이 오래 걸린다고 해서 나온 모델이다. 확실히 옛날엔 요구사항같은 문서작업이 많았다고 한다.(waterfall 모델이 기억나는가)

이렇게 쭉 우직한 방식의 방법론들을 쓰다가 2000년대에 스마트폰 나오고~ 뭔가 자꾸자꾸 나오니까 더 유연하고 민첩하게 대응할 수 있는 방법론으로 문제 발생 시 바로 대응할 수 있었으면 좋겠다~~ 해서 개발한 방법론이라고 한다.

이전엔 문서 중심이었다면, agile 개발 모토는 프로세스보다 사람들간의 상호 소통을 중시하겠다, 프로세스가 정해지면 무조건 따르기보다 대화로 적절히 변경하면서 소통하겠다는 마인드를 갖고 있다.

 

 

 

그래서 agile 방법론이란,

• 소프트웨어를 고객에게 빠르고 지속적으로 전달해서 만족시키자.
• 비록 개발의 후반부라도 고객 요구사항 변경을 환영하자.(남용금지)
• 비즈니스 사람들과 개발자들은 함께 일해야 한다.
• 작동하는 소프트웨어가 진척의 척도이다. 등등.. 이 있다.

 

결국 반복적인 개발로 잦은 출시를 목표한다.

그런데, 조금씩 자주 만든다고 이걸 잘못 이해할 수 있다.

일부기능이 러프하게나마 동작하는 소프트웨어 개발이다. 러프하게 그려놓고 점차 완성하는 것이다.

이런 퍼즐맞추기 개발로 착각할 수 있는데, 이런 방식이 아니라

 

 

이렇게 조금씩 완성도를 높여나가는 것이다.

 

 

 

agile 과 waterfall 모델을 비교해보자.

 

기존의 폭포수 모델은 한단계 거칠때마다 많은 양의 일을 하므로 추가요구사항이 있으면 수용하기 어려운 구조였다.
하지만 agile 방법론은 추가요구사항을 수용할 수 있다.

릴리스시점도 서로 다르다.

시작단계부터 밀도높게 완성하여 최종단계에서 릴리스하는 폭포수 모델과 달리, 애자일은 비록 시작은 미흡하지만 완성도가 점점높아지는 방식을 통해 수시로 릴리스한다.

또한 폭포수는 고객과의 의사소통을 처음에 많이 하고, 애자일은 수시로 계속 소통한다.

 

이렇게 진행사항을 개발초기부터 점검하여 고객과 공유하는 애자일이 있고, 산출물에 대한 결과로 개발의 진척사항을 점검하는 폭포수 모델이 다르다.

이렇게 많은걸 알아야 하는데, 많은 사람들이 애자일 방법론을 사용한 개발에 대해 오해를 한다.
'문서중심 아니니까 문서 작성은 됐고 프로젝트나 하자~' 로 착각할 수 있다. 

그 오해들은 여러가지가 있다.

 

 

애자일을 사용하면 개발이 쉽다고 오해하지만, 애자일방법론 자체가 고도의 소프트웨어공학 지식을 기반으로 하기 때문에 반복형 개발의 요소들을 완전히 마스터 해야만 한다. 프로세스 자체는 간단해 보여도, 모든 과정에서 엄청난 지식이 요구된다.

그리고 애자일을 사용하면 일의 양이 적어지는 줄 오해하는데, 폭포수처럼 한번에 많이 하는 것은 아니지만 반복형 이다보니 계속 요구사항이 변해서 의외로 폭포수보다 일이 더 많다.

또한 애자일은 프로젝트 성공률 올린다기 보다, 다른 모델들은 결과를 마지막 한번만 확인하고 애자일은 계속 프로토타입으로 점검하기 때문에 산으로 갈 확률을 줄이는 것이지 성공확률을 높이는 것은 아니다.

마지막으로 애자일은 계획이 필요 없다고 간혹 오해하는 사람이 있다. 계획이 디테일하지 않고 빠르게 여러번 하는 것이지 설계, 계획은 필수다. 의미없는문서를 만들지말고 개발에 필요한 문서만 만들라는 말이다.

 

 

 

 

agile - scrum

agile 방법론 중에서도 여러가지 방식이 있다.

그 중 스크럼은 소프트웨어 개발보단, 팀의 개선과 프로젝트 관리를 위한 애자일 방법론이다.
주로 개발팀을 운영하는 효율적인 운영방식이 중점이다.
이를 기반으로 하여, 개발 프로세스 자체에 빠지기보다 팀원간의 커뮤니케이션과 효율적인 운영에 집중된 프로세스 방법론이다.

결론을 먼저 간단하게 말하자면 스크럼은 하나의 텀이다. 하나의 기간 동안 빠르게 이런거 만들자! 하고 단기적인 계획을 세운 후 매일 짧은 회의를 마치고 개발을 시작한다. 보통 하나의 스크럼은 1주일~ 한달? 단위라고 한다.

빠르게 결과를 도출하려다 보니 결과물이 디테일하진 않은데 부족한 부분은 이걸 여러번 반복하여 보충한다.

 

 

 

 

이어서 스크럼에 대해 더 자세하게 알아보자면

우선, 일정 기간(예를 들어 한달)동안 할 일의 목록을 확정한다. 이후 매일매일 팀원 전체가 모여서 회의하는 것으로 그 누구도 농땡이를 필 수 없는 시스템을 만든다. 이 기간 동안에는 무려 사장조차도 팀을 방해할 순 없다.

그래도 이런 철학 덕분에 프로젝트가 산으로 가는 것을 미연에 방지할 수 있다.

위 그림처럼

플젝에 관련된 사람들이 다 모이면 제품 기능 목록을 작성한다. 그것으로 구현 목록을 만들고 빠르게 스프린트를 수행한다.(스프린트는 단거리 경주. 스크럼 동안 수행하는 것을 말함)

 

수행하는 동안 매일매일 스크럼 회의해서 오늘 할일 체크하고, 어느정도 스프린트가 완료되면? 완료된 프로토타입이 만족할 때 까지 무한 반복한다.

 

 

 

 

PM ( product manager ) - 제품 기능 목록

 

여기서 중요한 사람이 하나 있는데 PM. project manager가 아니라 product manager. 제품 관리자가 나온다.

제품 관리 과정 일체를 총괄하는데, 그 과정에는
제품에 대한 외부의 요구를 취합하고, 제품에 대한 정의나 팀이 나아갈 방향을 설정하여 취합한 것을 바탕으로 내부 팀원에게 일을 분배한다.

그 중 스크럼에서 말했던 제품 기능 목록을 여기서 만든다.

그래서 제품 기능 목록이 어떤거냐면 사용자가 만들어달라는 기능의 우선순위를 메긴다거나, 제품에 포함되야할 기능, 특성, 기술목록 등 제품과 관련된 모든 이야기를 글로 적은 것이다.

 

그럼 제품 기능이나 특성은 PM 혼자 다 정의할까?

>> 아니다. 이 기능들을 글로 적는 것이 PM이다.

 

그렇다면 제품에 필요한 기능은 누가 제안하는 거지?

>> 누구든 제품에 관심이 있는 사람이면 제안자라고 한다. 오해하면 안되는게 목록 작성자는 아니다. 그냥 제안만 한다.
이 제안자는 고객이나 기획자, PM, 팀원 등이 있을 수 있다.

이렇게 고객 요구사항이나 PM 기획의도, 마케팅, 영업팀, 기술팀, 고객지원팀, 팀원... 쓸데없이 많은데 아무튼 등등 이런걸 전부 제품 백로그에 기록한다.

 

 

 

 

PO (Product Owner) - 백로그 관리

 

제품 백로그의 항목은 다음과 같이 만들어진다.

일단, 앞서 기록된 백로그 항목들을 봐서 우선순위를 정하고 각 항목을 달성하기 위해 얼마나 시간이 걸릴지 추정한다.

프로젝트가 한창 진행중일 때, 각 항목은 훨씬 더 구체적인 조건을 갖는다. 그 과정에서 우선순위가 바뀌고 더 정확한 추정치를 측정한다.

 

 

그렇다면 이런 백로그는 대체 누가 관리하지? Product Owner 통칭 PO가 한다.

이 사람은 백로그에 대한 모든 권한을 갖는다. 예를들어 백로그에 새로운 항목을 추가한다던가 항목을 수정한다던가, 각 항목의 우선순위를 결정한다. 이렇게 백로그에 손을 댈 수 있는건  오로지 제품책임자(po)만이 관리 가능하다.

 

 

그럼 여기서 PM이랑 PO가 뭐가 다른지 조금 헷갈린다.

PM은 제품의 관리자로 제품이 잘 개발될 수 있도록 비전을 제시하는 사람이다. 팀의 인사권이나 외부 자원 조달 등의 권한이 있다. 그냥 자원조달이지 어떻게 개발해라~ 등 기능에 어떻게 하는 권한은 없다.

PO는 제품의 책임자로 제품이 잘 개발될 수 있도록 구체화시키는 사람이다. PM과 달리 실권은 없다. 오직 백로그만 담당한다... 그래도 백로그에 한해서는 무소불위의 권한을 갖지만, 항목을 추가할 때는 모두가 이해할 수 있도록 구체화시켜서 우선순위를 비교해준다.
그래도 백로그가 즉각적으로 업데이트 되진 않는다. 그저 가이드라인을 제시해서 구체화할 뿐. 이걸 또 바로 구현할 필요도 없다. 그래서 만약 PO가 백로그를 시시때때로 갱신해도, 개발 팀은 이전에 자신에게 주어진 스프린트를 토대로 기능을 구현하기 때문에 영향을 주지는 않는다.

 

다시 말하자면, 팀은 스프린트 백로그를 근거로 작업을 진행한다.

 

 

 

 

용어 정리

 

어...뭐.. 뭔프린트 백로그?

이쯤 되면 스크럼에서 사용하는 용어들이 조금씩 헷갈리기 시작한다. 그냥 전체적으로 한번 쭉 정리하고 넘어가겠다.

사용자 스토리 user story
메모지 한 장에 우리가 구현할 기능을 사용자 관점에서 작성한 사용자 요구사항이다.
그냥 사용자에게 가치를 평가 받을 수 있도록 기능을 표현한 것이다.

 

스토리 포인트 sp
사용자 스토리를 수행하는데 걸리는 상대적인 개발 기간(시간)

 

스프린트
그대로 번역하면 단거리 전력질주, 작업량이 많지 않아서 개발 기간을 짧게 해서 단기간 내에 전력으로 개발한다는 뜻이다.
스크럼에서 말하는 반복 주기의 단위로도 사용한다.

 

스프린트 백로그
아까 말했던 스프린트에서의 구현 목록이다. 각각의 스프린트 주기에서 개발할 작업 목록에 이번 스프린트까지 꼭 해결하기로 결정된 목록들과 세부 작업 항목과 작업자, 예상 작업 시간등에 대한 정보가 있다. 이것으로 팀의 현재 상태를 실시간으로 반영할 수 있다. (갱신은 팀 내부의 PO가)
>> 여기서 PO가 제품 백로그를 시시때때로 갱신하긴 하는데, 스프린트 기간동안 팀원들은 스프린트 백로그만 들여다본다. 스프린트 백로그에 없다? 신경조차 안씀. (미리 회의한 스프린트 백로그와, 중간에 임의로 갱신하는 백로그 차이)

 

그런데 도저히 이번 스프린트 내에 모든 백로그 항목을 달성할 수 없을 때가 있다. 이럴 땐 팀에서 덜 중요하다고 생각하는, 아직 시작되지 않은 백로그 항목을 없애버린다.
만약 모든 백로그 항목이 진행중이면 어떡하지? >> 걱정할 것 없다. 완료할 수 있는 수준까지 백로그 항목을 쪼갤 수 있다.

 

이 외에 작업 도중 예상시간이 엄청 길어질것 같다면 바로 주저하지 않고 스프린트 백로그에 해당 사항이 반영되어야 한다.

마지막으로 용어정리 계속 하자면

 

소멸차트 burndown chart
시간이 지남에 따라 소멸되고 남은 것을 표현한 것이다. 계획 대비 작업이 어떻게 진행되고 있는지를 날짜별로 남은 작업량을 통해 표현한다.

 

스프린트 계획 회의 (스프린트 목표 설정)
제품 책임자의 의도를 파악하고 가장 높은 순위의 항목에 관심을 두면서 그 배경과 목표에 대해 팀원들과 토의한다.
세부적으로는, 작업 수행 소요 시간을 추정하고 우선순위가 높은 항목의 구현 방법에 대해 구체적인 작업 계획을 세운다.

이런 회의는 매일, 서서, 짧게(15분 정도) 진행 상황만 점검한다. (스프린트 작업 목록 잘 개발하고있는지 확인)
간략하게 모든 팀원이 참석해서 한 사람씩 어제 한 일과 오늘 할 일을 얘기하는 것이다.
마지막으로, 오늘 할 일중 문제점이나 어려운 점 정도 얘기하고 완료된 세부 작업 항목을 스프린트 현황판에 업데이트한다.

아래는 스프린트 현황판이다.

 

이렇게 하나의 스프린트가 끝났다. 그럼 수행 활동과 잘 개발했는지, 문제점이나 개선점은 없는지 회고하고 반성한다.

아래는 배포 목록이다.

 

 

 

 

PM과 PO 말고도 스크럼을 주재하는 사람인 스크럼 마스터가 있다.

이 사람은 일일 스크럼 회의를 소집하고 진행하는 사람이다. 또한 스프린트 기간 내내 스프린트 백로그를 잘 따를 수 있도록 팀내 의견을 조율한다.

그래서 스크럼 마스터는 보통 팀을 잘 이끄는 프로그래머가 한다.

 

스크럼 마스터가 주로 하는 업무는 우선

계획 회의
팀원들의 능력에 알맞은 양의 스프린트 백로그가 작성될 수 있도록 노력

일일 스크럼 미팅
팀원들이 스프린트 백로그를 달성할 수 있도록 팀원들의 동향을 살피고 조율함

스프린트 기간 중 외압으로부터 팀을 보호!
(사장님이 자꾸 귀찮게 해요, 서버가 너무 느려요 >> 일개 사원인 스크럼 마스터가 사장님 닦달해서 해결!
르세라핌 음악 없이는 현기증나서 일을 못하겠어요 >> 앨범사오기ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ )

 

 

 

---

 

 

 

이렇게 agile 방법론 중 하나인 스크럼을 알아봤다. 이렇게 하면 그래서 뭐가 좋은거지?

사용자와 충분한 의견 조율이 가능해지고, 일일 회의를 통해 팀원들 간에 신속한 협조와 조율도 가능하다.

이 방법론은 다른 개발 방법론들에 비해 단순하고 실천 지향적이다. 프로젝트 진행 현황을 통해 신속하게 목표와 결과를 추정할 수 있다. 필요하다면 수정할 수도 있다. (agile이니 수정 가능)