Agile SCRUM 프로젝트 관리를 위해 Jira를 바꾸면 어떨까?

1. SDLC, 애자일(Agile), 스크럼(SCRUM)

20세기로 들어오면서 기계를 중심으로 하는 공장이 늘어나면서 공장에서 일하는 사람들의 생산성을 높이기 위해 테일러/포드 관리와 같은 과학적 관리 방법이 생겨났다는 것을 배운 적이 있다. 컨베이어 벨트를 만들어 분업화시키고 일하는 동선을 고려해 작업환경을 만들고 생산라인을 체계적으로 관리하기 위해 조직을 만들고 단순화된 업무에 대한 피로를 해소하기 위해 목적과 동기를 부여해서 하나의 효율적인 기계처럼 생산할 수 있도록 관리방법은 발전해 왔다.

 

3차 산업혁명과 진행 중인 4차 산업혁명의 중심에는 정보통신 기술이 있다. 정보통신 산업에서 중요한 것 중의 하나가 소프트웨어 개발 생산성이다. 개발자의 개인으로 보면 생산성을 높이는 것은 효과적인 디자인패턴을 적용하거나 Github Pilot을 적용하는 것이지만, 회사 전체로 볼 때 소프트웨어의 개발은 개인 능력향상만으로 개선되기 쉽지 않은 부분이 많다. 그래서 사람들은 오래전부터 SDLC (Software Development Life Cycle)을 정의하고 관리하는 프로세스를 연구해 왔다.

a. SDLC (Software Development Life Cycle)

SDLC는 기본적으로 분석, 설계, 개발, 테스트, 운영의 5가지 단계가 필요하다. 내가 처음 회사 생활을 시작했을 때에는 이 모든 것은 당연히 물 흐르듯이 순서대로 진행되는 Waterfall 관리 방식을 따랐다. 비즈니스 이끄는 관리자들이 모여서 무엇이 필요한지에 대해 결정하면, 프로젝트 팀이 구성되고 PM과 경험 많은 시니어 개발자가 관리자들의 요구사항을 분석해서 시스템을 설계하면, PM이 WBS (Work Breakdown Structure)와 연결된 일정계획을 가지고 차질 없이 진행되도록 관리하면서 개발하고, 개발이 완료되고 테스트를 진행해서 문제가 없으면 실제 업무에 적용하고 운영하는 방식으로 진행되었다.

b. 워터폴 (Waterfall) 관리 방법

Waterfall 방식은 아직도 많이 사용하는 방법이다. 특히 예측과 정밀한 계획이 가능해서 일반적인 프로젝트에서 많이 사용하는 방법이고, 소프트웨어 개발에서는 회사의 오프라인 업무를 온라인으로 전환하는 프로젝트에 워터폴 (Waterfall) 방식을 많이 적용한다. 이전에 진행한 P회사 물류창고 자동화는, 설비, 엔지니어링, 하드웨어, 소프트웨어 자회사들이 모여 1년 후 오픈할 자동화된 창고를 위해 필요한 장비를 개발하고, 설치에 필요한 시설을 만들고, 장비를 운영할 하드웨어를 도입히고, 이 모든 것을 통제할 수 있는 소프트웨어를 개발하는 장기 프로젝트였는데, 이런 규모의 프로젝트는 여전히 워터폴 (Waterfall) 방식을 적용하고 있다.

c. 애자일 (Agile) 관리 방법

만일, 업무가 이미 온라인으로 전환되었고, 시장에 대한 회사의 빠른 대응이 필요하다면 워터폴 (Waterfall) 방식의 대응이 느릴 수 있기 때문에, TF조직처럼 필요할 때마다 작은 규모로 빠르게 요구 사항에 대응할 수 있는 애자일 (Agile) 방법론이 나왔다. 애자일 (Agile) 방법은 분석, 설계, 개발, 테스트의 전체 주기를 짧게 가져가고 이 주기를 반복하면서 시장의 반응에 유연하게 대처하면서 개발하는 방법이다. 하지만, 장기적인 목표를 관리하지 않으면 너무 단기적 대응으로 일관해서 실패하는 경우도 적지 않기 때문에, 앞에서와 같은 온라인 전환이나 차세대 개발과 같이 요구사항이 좀 더 명확하다면 Waterfall방식이 더 효율적이다.

d. 스크럼 (SCRUM)

애자일 (Agile) 방법 중 현재 많이 사용하고 있는 방법이 스크럼 (SCRUM) 이다. SCRUM은 MVP (Minimum Viable Product)에서 Full Featured Service까지 유연하고 시장요구에 반응하면서 개발하고 싶은 IT스타트업들이 도입해서 성공한 사례가 생기면서 대중적인 인기를 얻고 있다. 제품 담당자와 개발자의 협의를 통해 기능 개발이나 개선 항목을 10개 정도의 소규모 기능에 대한 백로그 (Backlog)를 협의를 통해 만들고, 개발자가 자율적으로 개발하고 최종 리뷰를 거쳐 확정된 부분을 운영으로 전환하는 주기, 스프린트 (Sprint)를 반복하면서 제품을 만들어 가는 방법이다. 시장에 시 제품 (Prototype) 을 빨리 출시할 수 있고, 시장 반응에 따라 빠르게 대응할 수 있어 스타트업에서 선호하고 있지만,  스타트업만큼 실패 가능성이 높은 방법이다.

2. 지라 (Jira)

Jira | Issue & Project Tracking Software | Atlassian

 

스크럼 (SCRUM) 으로 소프트웨어 프로젝트를 관리하는 것은 워터폴 (Waterfall) 로 관리하는 것보다 어렵다. 스프린트 (Sprint) 주기마다 백로그를 협의해야 하고 백로그에서 개발을 위한 작업을 WBS로 만들면 개발자의 자율에 맡겨 관리하다 보니, 치밀하게 WBS를 만들고 일정을 관리하는 Waterfall방식보다 더 세밀한 모니터링과 리포팅 도구가 필요해졌고, 현재 가장 많이 사용하고 있는 소프트웨어 중의 하나가 Jira이다.

 

아틀라시안(Atlassian)에서 개발한 Jira는 원래 Issue Tracking (문제 추적)의 용도로 개발되었다. 프로그램의 버그와 같은 문제를 추적하는 것에서 출발해서 SCM (Source Code Management) 도구들과 결합하고, 모니터링 또는 리포팅에 필요한 도구와 결합하고 항목에 대한 커스터마이징 기능이 추가되면서 발전해 왔다. 하지만, 처음 설계한 개념을 유지하고 있다 보니 Jira에 등록하는 모든 항목은 이슈의 한 종류로 만들어져 있고, 이 구조를 사용자들이 쉽게 사용할 수 있도록 도와주는 여러 가지 템플릿으로 만들어 제공하고 있다.

a. 스크럼 템플릿

Jira는 SCRUM을 관리하기 위한 템플릿을 "소프트웨어 개발" 카테고리에서 제공하고 있고 이 템플릿을 사용하면 가장 기본이 되는 "에픽" 이슈 이외에 "스토리", "버그", "작업", "하위작업"의 4종류의 이슈를 만들어 준다. 아틀라시안은 

• 스토리를 사용자의 한 작업에 대한 정의, 예를 들어 "사용자는 앱에 아이디, 패스워드를 사용해서 로그인할 수 있다"
• 에픽을 여러 개의 스토리를 합쳐 하나의 의미를 정의, 예를 들어 "2분기 사용자 App의 보안기능 강화"
• 작업을 회사의 구성원이 스토리 목표로 진행하는 작업, 예를 들어 "사용자 DB에 아이디, 패스워드를 추가"
• 하위작업은 작업을 좀 더 세분화할 때 사용

하는 것으로 제안하고 있는데 대부분의 경우 이 규칙을 그대로 적용하고 있다. 또한, 상위 의사결정자들이 사용하는 회사 단위의 계획을 위해 "최상위 계획" 템플릿으로 프로젝트를 만들게 되면 이니셔티브라는 보다 큰 이슈 항목도 만들어진다.

b. 이슈 유형 계층 구조 변경

하지만, 회사마다 구성원이 다르고 프로젝트를 진행하는 방식이 다르기 때문에 지라 (Jira) 의 이슈 구조가 회사와 맞지 않는 경우가 발생할 수 있다. 예를 들어, 제품팀이 정의하는 스토리 기준으로 개발팀이 서비스를 개발해야 하는 경우, 에픽이 아니라 스토리가 제품팀과 개발팀에 공유되어야 할 수도 있고, 디자인팀에서 만드는 화면 기준으로 개발팀이 개발을 한다면 화면이 개발팀과 공유되어야 할 수가 있다. 하지만, 지라 (Jira) 는 에픽 이슈가 공유되기 때문에 프로젝트의 유형을 "회사에서 관리"하도록 설정하여도, 다른 유형의 이슈를 기준으로 해서 하위 이슈로 확장해 나가는 것은 어렵다. 대신 동일한 이슈를 작성하고 링크로 연결할 다음 하위 이슈를 작성해야 한다.

 

이때 사용할 수 있는 방법이 이슈 유형과 계층 구조를 바꾸는 방법이다. 예를 들어

 

• 에픽의 명칭을 회사에서 팀간 공유하는 기준으로 바꾸고
• 회사 업무 특성에 맞게 이슈 유형을 만들고
• 이슈 유형에 대한 계층 구조를 다시 정의

하면 회사에서 원하는 구조로 이슈를 운영할 수 있게 된다.

 

예를 들어, 회사가 스토리 기준으로 업무를 진행한다고 하고, 스토리를 기준으로 제품팀과 개발팀의 이슈를 다음과 만들 수 있을 것이다.

 

하지만, 이런 방법은 현재 지라 (Jira) 를 사용하고 있는 프로젝트가 있는 경우 모든 프로젝트에 영향을 주게되기 때문에 지라 (Jira) 를 처음 사용할 때 정의하지 않으면 기존 프로젝트의 내용을 옮겨야 하기 때문에 현실적으로 어려운 단점도 있다.

 

하지만, 지라 (Jira) 에서 정의한 방식으로 프로젝트를 관리하는 것보다 회사에 맞게 변경해서 사용하는 것도 좋지 않을까 생각한다.