애자일 개발 방법론 - 스크럼

이게 참...

내가 이 블로그를 쓰기 시작한 계기가 프로젝트 개발론을 정리 해볼까.. 하면서 였다. 

 

애자일 방법론의 대표 격인 도해

 

그런데 먹고 살기도 퍽퍽하고 시간이 부족한 만큼 블로그에 대한 관심도 옅어져서 상세 내용은 다음에... 라고 스스로 한 약속을 완전히 까먹고 있었다.

 

애자일 방법론의 종류

애자일 방법론의 종류

 

개발 방법론 - 애자일

개발 방법론 - 애자일

 

그 사이 진행한 프로젝트가 몇개인가... 흠흠..

 

아무튼 그리하야 애자일 방법론 중 유명한 것들을 좀 정리해보고자 한다.

---

 

스크럼

 

 

인터넷에서 스크럼 이미지를 검색하니... 좀 된 사진인데 아직도 이렇게 돌아다니니 이분 참 열심히 사시는게 맞는거 같다.

 

 

위 사진에서 보듯 스크럼은 럭비 경기에서 공격자들이 공을 둘러싸고 진영을 만드는 모양을 일컫는다.

스크럼 포지션 안내. 출처 : https://rugbyfix.com/

 

어느 새 위키사전에서 스크럼을 검색하니 ① 럭비 용어 ② 애자일 방법론 으로 소개해준다.

(이렇게 유명했다고?)

 

무려 1986년 일본의 노나카 이쿠지로라는 양반이 발표한 소프트웨어 게임 개발방법론이다.

New 를 두번이나 붙인 논문 제목이 상큼하다. 

 

원본을 보고 싶었는데... 언제 한 번 도서관을 뒤져봐야할거 같다.

 

 

스크럼은 특정 언어나 방법론에 의존하지 않는 상당히 포괄적 의미의 개발방법론으로 

(보통은 특정 언어의 아키를 벗어나기 힘들다) 다음과 같이 내용을 정리할 수 있다.

 

• 솔루션에 포함할 기능 및 개선점에 대한 우선 순위를 부여한다. 
• 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라. 
• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라. 
• 날마다 15분 정도 회의를 가져라. 
• 항상 팀 단위로 생각하라.
• 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.

 

현재 소프트웨어 개발 프로젝트 현장을 돌아보게 하는 문구들이다.

 

매일 어제까지의 성과를 가지고 깨진다. 15분? 1인당 15분이면 10명이면 ....

개발주기를 30일 단위로 하라고? 수십억짜리 프로젝트 총 개발기간이 6개월을 넘기지 않는 현실을 모르시는 분이다. ㅜㅜ

언제나 팀 단위로 시작한다. 하지만 팀 단위로 깨지다보면 어느새 각개전투에 특화된 이들을 보게 된다. 나름 포함해서...

원할한 의사소통은 언제나 알코올을 동반한다.

•  

아... 우리나라 SI 프로젝트가 이래서 죄다 망해 나가자빠지는구나.... 반성에 반성을 하게 만드는 주옥같은 문구들이 아닌가 말이다.

 

 

이 개발론은 "지식창조기업" 이라는 일본의 조직론에 그 근간을 두고 있다.

당시 저가의 제빵기나 복사기 같은 혁신적 아이디어 제품을 개발한 기업들을 소개한 조직론이다.

이후에도 이런 류의 조직론은 상당 기간 유행했었다. 

 

아무튼 스크럼 개발론에서 차용한 지식창조기업의 창조 프로세스는 다음과 같은 5가지로 요약된다.

 

• 조직의 의도 : 지식 창조의 목표나 팀을 지탱하는 축
• 자율성 : 팀의 멤버에게 자유로운 행동을 인정하는 열린 환경(시스템)
• 역동적이고 창조적인 카오스 : 조직 내 외부 간의 역동적인 상호작용을 통한 지식창조 환경
• 잉여성 : 의도적으로 조직에 넘쳐나는 여분의 정보
• 최소 유효 다양성 : 복잡하고 다양한 환경에 기민하게 대응하기 위해서는 조직 구성원이 가져야 하는 다양성

 

---

 

그러면 30일 주기로 어떤 식으로 개발하면 잘 개발하는 것일까.

 

글 내에서도 30일은 권장기간으로 형편에 따라 1주~4주 정도로 유연하게 대응하라고 한다.

현장에서도 WBS 작성 시 가급적이면 1~2주 단위로 끊어서 과업을 정리할 것을 요구 받는다.

경험상 이 정도가 품질을 놓치지 않는 선이라는 일종의 암묵적 약속이 있는 편이다.

반응형

Product Backlog

요즘 말로 요구사항 정의서다. 무엇을 개발해야 하는지 과업을 명확히 해야 한다는 것이다.

단계 별, 단위 별이 아니라 근본적 요구사항을 알아야 한다. 

한 마디로 우리가 뭘 만드려고 모였는지, 최종 개발 완성품의 모양을 대충이라도 알아야 한다.

 

Sprint (반복적 개발주기)

요구사항 받아서 첫 회의 ~ 개발 완료 후 고객 피드백 까지가 1텀(1스프린트)이다. 

이걸 짧게 끊어서 주고 받으며 피멍 들으라는 말이렸다...

아래의 요소들이 1 Sprint 안에서 실행된다. 

 

          Sprint Planning Meeting (스프린트 계획 회의)

 

          Sprint Backlog

 

          Daily Scrum Meeting

 

shippable product (현실성 있는 제품 개발)

 

피드백 받으면 다시 회의 ~ 개발 ~ 리뷰 ~~~ 이게 애자일의 진수다.

돈주는 이, 만드는 이, 쓰는 이 모두가 코피 쏟게 되는 대 환장 파티...

 

이 방법론에서 가이드 주는 개발 방법은 이렇다.

 

① 일단 제품에서 요구되는 기능과 우선순위를 정한다. 그리고 이것들을 정리해서 Backlog에 정의한다.

 

② 정의된 우선순위에 맞게 팀 별로 개발 범위를 정한다. 이 과정에서 팀 간의 조율도 필요하다. 조율을 거쳐 정리된 Backlog 가 이번 Sprint 의 개발 목표가 된다.

 

③ 팀 별로 Sprint 내에서 정의된 Backlog를 다시 정리한다. (Sprint Backlog. 여윽시 일본인은 정리가 짱이다. 끝도 없이 정리한다. 초년생 시절 일본 회사에서 일할 때 미치는 줄 알았지만... 배우기도 많이 배웠던 기억이... 주르륵)

 

④ 매일 정해진 시간에 정해진 장소에서 모든 팀원이 모여서 회의한다. 이를 일일 스크럼 회의(Daily Scrum Meeting) 이라고 한다. 

 

⑤ 1Sprint 가 종료되면, 스프린트 리뷰 미팅을 갖는다. (회의 하다 프로젝트 끝나겠는데?) 이때 모든 이들은 현재까지 개발된 제품을 학습하고 이해하는 시간을 갖는것이 목표다.

 

⑥ 리뷰 미팅을 통해 제품의 학습이 되었다면, 스프린트 회고를 통해 팀의 프로세스 개선 방향을 모색한다. (한 마디로 각 잡고 반성하라는 말씀)

 

⑦ 각 Sprint 가 종료되기 전에 다음 Sprint 를 준비한다. 이 때는 모든 팀원이 모이는 것은 아니고 제품 총괄담당자(PO, Product Owner)와 단위 프로젝트 관리자(SM, Scrum Master)간에 조율하고 정의한다.

728x90

Scrum Master는 단순히 프로젝트를 관리하는데 그치는것이 아니라. 팀원을 코칭하고 프로젝트 수행 중 만나는 문제를 해결하는 역할을 담당한다. PO는 비록 직책 상 SM의 상위의 개념이지만, 혼자 독단적으로 개발 목표 등을 정의해서는 안된다. 모든 목표의 정의는 고객, 관리자, 팀원이 모두 모여서 정의해야 한다.

 

실질적으로 개발자(팀원)가 단위 모듈 작업을 진행하는 시간은 4 ~ 16시간 정도로 쪼개서 배분한다. 하루 8시간 근무로 따지면 하루에 2개에서 이틀에 하나 개발하는 정도의 강도를 말한다.

 

보통 품질론에서는 한 명의 개발자가 주 3~4본 정도의 개발범위로 과업을 받을 때 어느 정도의 품질을 보장하는 것으로 말한다. 두 이론에서 요구하는 개발 강도가 대충 비슷한거 같다