TMI 프로폴리스가 떨어져서 며칠 먹지 않았더니 면역력이 저하되었다. 요 며칠 약속이 계속 있어 쉬지 못했는데, 목이 아예 나가버렸다. 주말에 유튜브, 글쓰기를 하려고 했는데 유튜브는 다음 주로 미뤘다.
목적
- 칸반(Kanban), 스크럼(Scrum) 에 대하여 알아보고 고찰하기
- Atlassian Jira 이용하기
프로젝트 방법론
사람의 생각은 다 똑같은 것 같다. 분야를 불문하고 효율성과 생산성을 개선하기 위한 노력을 한다. 그래서 어떤 분야에서 고안한 방법론이 성공적이면 다른 분야로 전파되어 나가는 것처럼 보인다. 린 스타트업(Lean Startup), 애자일 프로세스(Agile Process) 등 지난 1.5년 간 스타트업에 관심을 가지고 활동했을 때 들었던 용어들, 품질 관리 수업을 들으며 조사하여 발표했던 도요타의 품질 철학인 린 시스템(Lean System), 리콜 사태 이후 도입한 JIT(Just In Time) 생산 방식, 칸반(Kanban) 방법론과 같은 용어들, 이러한 용어들을 소프트웨어 개발을 하면서도 듣고 있다는 점이 전파의 증거인 것 같다.
다른 분야에서 성공을 거둔 방법론은 역사가 비교적 짧은 학문인 소프트웨어 공학에도 역시 전파가 된 것처럼 보인다. 최근 많이 들었던 소프트웨어 개발 프로세스는 총 세가지이다.
- Waterfall Model (폭포수 모델)
- 프로세스가 폭포수 같다고 하여 붙여진 이름이다.
- 요구사항 분석으로 시작하여, 소프트웨어 설계, 구현, 테스트, 통합, 유지보수 단계로 이루어진다.
- Agile Model (애자일 모델, Agile Process)
- Agile의 사전적 의미는 민첩한, 날렵한 이다.
- 소프트웨어의 생명 주기 동안 반복적으로 빠르게 개발하고 빠르게 배포하고 빠른 피드백을 얻어 민첩하게 변화에 대응할 수 있다.
- 개발의 과정에 고객과의 협력이 포함된다.
- 이 프로세스의 방법론 중 하나가 스크럼이다. XP(Extreme Programming이라고 하는 것도 하나의 방법론이다.)
- Lean Proecss (린 프로세스)
- 시장에 대한 가정을 최대한 빨리, 반복적으로 검증하면서 낭비를 최소화하는 프로세스이다.
- MVP(Minimal Viable Product, 최소 기능 제품)를 지속적으로 생산한다.
- 크게 3단계 (Build, Measure, Learn)의 과정을 거친다. 이 세 과정을 통해 가설, 테스트, 검증을 한다.
- 리소스가 한정된 스타트업에서 효율성 극대화하기 위해 많이 채택하고 있다.
현업에서 경험해 본 것은 아니지만 내가 경험해 본 프로세스는 애자일 모델과 린 프로세스이다. (팀의 실정에 맞게 적용하여 경험하였다.) 애자일 모델은 칸반 보드를 이용해 테코브러리의 팀 리딩을 하면서 적용한 경험이 있고, 린 프로세스는 신촌 연합 IT 창업 동아리 CEOS(
홈페이지 리뉴얼해야 하는데...
)에서 프로젝트를 진행했을 때, 동아리를 운영하면서 경험하고 있다.
칸반(Kanban)과 스크럼(Scrum)
애자일 모델에는 여러 방법론이 있다. 위에서 언급했던 것처럼 XP 나 스크럼, 그리고 칸반이 있다. 이 글은 칸반과 스크럼을 다루기 위해 작성하는 글이니 칸반과 스크럼에 대해서 조금 더 알아보고자 한다.
- 칸반(Kanban)
- 소프트웨어에서의 칸반은 도요타의 TOC(Theory Of Constraints, 제약 이론)과 당김 방식(Pull Process)에서 착안하여 데이비드 앤더슨(David J.Anderson)이 주장한 방법론이다.
- 각 파이프 라인(Column, 열)은 WIP(Work In Process)를 가지고 있다. 어떤 파이프 라인의 최대 수용량은 WIP로 결정된다.
- 작업의 중요성을 추정하는 대신 동시에 처리할 수 있는 이슈의 수(WIP)를 제한함으로써 제어할 수 있다.
- 모든 작업의 할당은 당김 방식으로 진행한다.
- 칸반의 핵심 특성 중 하나는 조직적 피드백의 시행(원문 : Implement Organizational Feedback)이다.
- IT 개발 조직에서 굳이 역할을 나누자면, TODO 파이프 라인을 기획자 혹은 PM 이 관리하고, 그 이후의 파이프 라인은 개발자가 관리한다.
- 데드라인이 존재하지 않는다.
- 스크럼(Scrum)
- 각 이슈는 우선순위가 존재한다. (Story Point, Backlog, Icebox 등이 있다.)
- 스프린트를 통해 실행 주기를 조절한다. 실행 주기는 1주 ~ 4주로 다양하다. (각 팀의 실정에 맞춰 진행한다.)
- 매일 스크럼 회의를 진행한다. 서로의 작업을 파악하고, 어떤 작업을 언제 진행할지 파악하기 위함이다.
- 모든 작업의 할당은 당김 방식으로 진행한다.
- 스크럼 마스터를 둔다. 하지만 독단적인 역할을 수행하는 것이 아닌 구성원의 의견을 종합하는 역할과 목표 수립을 조절하는 역할을 한다.
각 방법론은 하나에 들어맞게 도입하는 것이 아니라 조직의 규모나 성격에 맞게 유연하게 적용하는 것이 핵심이라고 생각한다. 또한 위의 두 가지 방법론은 하나의 틀(Frame)이지 정답이 아니기 때문에 더 좋은(효율성, 생산성을 극대화할 수 있는) 방법론이 존재한다면 수용하여 프로세스를 갖추는 것이 좋다고 생각한다.
칸반과 스크럼을 위한 도구
소프트웨어 버전 관리 서비스를 제공하는 다양한 회사들은 버전 관리 기능과 동시에 칸반과 스크럼을 위한 도구도 제공하는 경우가 많다. Github의 경우 버전 관리 도구와 프로젝트 관리 도구를 하나의 레포지토리로 통합하여 제공한다. 레포지토리에 기본 내장되어 있는 Projects,
2019년 하반기 Github에 인수된
프로젝트 관리 도구인 Zenhub 플러그인(첫 번째 이미지에 첨부)을 이용할 수 있다.
한편, IT 서비스 회사에서 협업 도구로 많이 사용하는 Jira 가 있다. Jira는 Atlassian 이 제공하는 서비스 중 하나인데, Atlassian 은 Github과 다르게 각 기능들은 분리하여 서비스를 제공한다. 버전 관리는 Bitbucket라는 이름 서비스로, 프로젝트 관리는 Jira Software(줄여서 Jira라고 한다.)라는 이름의 서비스(
Trello 도 Atlassian 꺼라니 오늘 알았다.
)로, 위키는 Confluence라는 이름의 서비스로 제공한다.
Github과 Atlassian 은 서비스 제공 타깃이 달라 보인다. Github 은 무료 서비스가 주이기 때문에 개인을 대상으로 하는 것 같아 보인다. 반면에 Atlassian 은 첫 페이지부터 Pricing, Get started for free (관대하게도 7일간 무료 서비스를 제공한다.
나는 이메일 계정이 10개가 넘기 때문에 70일가량 사용할 수 있다.
) 등의 메뉴가 많이 등장하는 것을 보면 유료 서비스가 주인 것으로 추정되고 B2B로 서비스를 제공하는 것 같다. (
그래서인지 UI/UX 면에서 Atlassian의 압승
)
Jira 첫인상 및 스크럼 보드로 시작하기
상당히 깔끔하다. 역시 돈을 받고 하는 서비스라서 그런지 확실히 돈 냄새가 나는 UI/UX 로 잘 구성되어 있다.
로그인을 한 뒤, 무료 체험(클라우드에서 체험하기)을 통해 프로필의 My Cloud Product > Jira Software를 클릭하면 이런 화면을 볼 수 있다.
1. 프로젝트를 생성하기 위해 오른쪽 상단의 프로젝트 만들기 버튼을 클릭하면 다음과 같은 화면이 나온다.
차세대 프로젝트의 설명에 "추가 기능이 곧 제공될 예정입니다."라고 쓰여있는 것을 보니 클래식을 선택하는 것이 좋을 것 같다. (완벽하지 않다는 뜻이라고 생각한다.)
2. 클래식을 선택하면 "프로젝트 만들기" 화면이 등장한다.
여기서는 프로젝트 이름과 키(이슈 접두어, Atlassian의 서비스들이 분리되어 있어 커밋 메시지에 기입하기 위하여 식별자를 두는 것으로 추정된다. 그리고 키는 중복이 불가능하다. Zenhub의 경우 Commit 메시지에 issue 넘버를 기입하면 자동으로 이슈 Tracking 이 된다.)를 설정할 수 있다.
- 템플릿은 총 세 가지를 선택할 수 있다. 칸반, 스크럼, 버그 추적. (너무 상세하고 잘 설명되어 있어서 위에서 칸반과 스크럼을 괜히 알아봤다는 생각이 든다.)
이 글에서는 스크럼 보드를 통해 Jira를 톺아볼 것이기 때문에 스크럼을 선택하였다.
3. 이름과 키를 설정하고 생성하면 생성된 프로젝트의 메인화면이 뜬다.
왼쪽 Drawer 메뉴를 살펴보면, 백로그, 활성 스프린트, 보고서, 릴리즈, 이슈 및 필터, 페이지, 구성요소 등의 메뉴가 있다. 회색 구분선으로 상단과 하단이 나누어져 있는데, 대략적인 직감(은 페이크고 사실 둘 다 만들어봄)으로 구분선의 상단부가 스크럼 보드의 주가 되는 기능이라고 파악할 수 있을 것 같다.
그전에 이슈 관리에 대한 몇 가지 용어를 언급하고 Jira로 돌아가야겠다.
이슈 관리 용어 (Jira 기준, 이미지 참고)
훑어보니 커스터마이징도 가능하고, 이슈 관리에 대하여 다양한 기능을 제공하는 것 같다.
4. 다시 Jira 로 돌아와서 먼저 백로그에 새로운 이슈들을 등록해보고자 한다.
한글이 지원되기 때문에 매우 편리하다. (
역시 돈이 최고인가!
)
5. 먼저 에픽을 하나 만들어 본다.
드로어의 우측에 에픽 만들기 버튼을 만들고, 에픽을 생성하면 위와 같이 에픽이 하나 추가된다. 에픽은 여러 이슈의 묶음이기 때문에 사실상 에픽만 생성하면 이슈를 생성하지 않은 것과 같다고 할 수 있다. (
마치 단팥빵에 팥이 빠진 느낌이랄까.
)
6. 이슈를 하나 만들어 본다.
이슈를 생성하고 생성된 이슈를 클릭하면 우측에 해당 이슈에 대한 상세 정보가 나온다. Story Point (이슈의 무게?를 측정하는 수치, 너무 높으면 이슈 생성을 쪼개어 다시 하는 편이 좋다.), 담당자, 우선순위, 시간 추적, EPIC LINK, 댓글 등 이슈를 관리하기 위해 많은 기능들을 제공한다.
7. 이 이슈의 EPIC LINK를 처음에 생성한 에픽인 지라 연습하기에 할당한다.
EPIC LINK에 설정할 수 있는 에픽은 단 하나의 에픽으로 한정되어 있으며, 서로 다른 프로젝트에 속해있는 에픽을 설정할 수도 있다. 에픽이 설정되면 백로그의 이슈 목록에도 어떤 에픽에 속해있는 이슈인지 알아볼 수 있도록 배지가 하나 생긴다.
8. 세 가지 유형의 이슈를 모두 생성해 보았다.
Jira 가 제공하는 기본 이슈 유형은 스토리, 버그, 작업 총 세 가지이다. 이 세 가지 이슈 유형은 차이점이 몇 가지 있다.
- 스토리 이슈만 스토리 포인트 부여가 가능하다. (그래서 스토리 포인트인가 보다.)
- 버그 이슈는 영향을 받는 버전을 설정할 수 있다.
- 작업 이슈는
솔직히 뭔지 잘 모르겠다. (댓글에 달아주시면 수정하겠습니다.)
9. 이 이슈들을 기반으로 스프린트를 생성할 수 있다.
스프린트에 해당 반복 주기 동안 실행할 이슈들을 끌어다 두고 스프린트 시작하기를 클릭하면 다음과 같이 스프린트를 설정할 수 있는 모달이 뜬다.
10. 스프린트 생성화면, 활성 스프린트는 단 하나! 여러 개의 활성 스프린트도 가능합니다.
- 활성 스프린트는 단 하나인 줄 알았는데 사용하다보니 여러 개의 활성 스프린트를 설정할 수 있고, 드롭다운 목록으로 전체, 특정 스프린트만 칸반보드에 노출되도록 할 수 있습니다. - 2020.03.27 수정
여기까지 Jira로 스크럼 보드를 생성하고 기본적인 내용들을 파악해 보았다.
상당히 깔끔하고 스크럼 보드 관리를 쉽게 하여 이 서비스를 사용하는 조직이 스크럼 보드 관리에 불필요한 낭비를 하지 않게 도와줄 수 있을 것 같아 보인다. 파일럿 프로젝트를 진행하면서 Jira를 통해 이슈 관리를 하고 다음 블로그 포스팅을 작성해보도록 해야겠다.
출처
- 위키백과 폭포수 모델
- 위키백과 애자일 소프트웨어 개발
- InfoQ.com Kanban Pioneer: Interview with David J. Anderson
- 불곰님의 블로그 칸반
- 한규주님의 린 스타트업 pdf -린 스타트업.pdf9.0 MB
댓글