2019.05.29

How To : 지라를 쉽게 사용하는 방법

Isaac Sacolick | InfoWorld
애자일 프로젝트를 관리하기 위해 아틀라시안 지라 소프트웨어(Atlassian Jira Software)를 갓 사용하기 시작한 개발자나 테스터와 이야기를 해보면 이들의 흥분을 느낄 수 있다. 지라는 스크럼(scrum), 칸반(Kanban) 또는 기타 프로젝트 관리 프로세스에서 애자일 팀을 지원하며 비교적 사용하기 쉬운 툴이기 때문이다.



지라는 고급 단계의 애자일 팀과 초기 단계의 애자일 팀을 위한 기능을 모두 갖추고 있다. 백로그를 스프린트(sprint) 관리와 별도의 활동으로 관리하도록 지원한다. 대시보드에서 팀과 개인에 따라 가장 중요한 정보를 맞춤 설정할 수 있다. 기본 보고 기능도 속도와 사이클 시간을 관리하고 릴리스와 에픽을 추적하기 시작한 대부분의 팀에 충분할 만큼 좋다. 컨플루언스(Confluence), 깃(Git) 등 개발자들이 사용하는 다양한 다른 툴과의 통합도 견고하다. 필요한 기능이 없다면 마켓플레이스에서 부가적인 기능과 통합을 찾아보면 된다.


지라에서 마음에 들지 않는 부분 

그런데 몇 년 동안 지라를 사용해 온 스크럼 마스터, 개발자, 엔지니어, 테스터와 이야기를 해보면 열정이 식었음을 종종 느낄 수 있다. 이들에게 지라(그리고 애자일 개발 프로세스의 어떤 측면)는 관리 복잡성 증가의 요인이다. 애자일 분야에서 오랜 경험을 쌓은 이들과 고급 지라 사용자는 애자일 방법과 지라 사용 방법을 깨끗이 정리하고 싶어한다.

문제가 무엇인지 살펴보자. 우선 팀에서 사용하는 기능과 구성이 늘어남에 따라 툴을 구성하고 사용하는 과정이 불친절하고 복잡해진다. 지라는 필드와 워크플로우, 스크린, 이슈 유형, 이슈 레이아웃을 프로젝트 수준에서 맞춤구성한 다음, 체계를 통해 이러한 구성을 여러 팀에 공유할 수 있게 해준다. 그러나 과잉 엔지니어링과 구성에 빠지기 쉽고, 결국 한때 사용하기 쉬웠던 툴이 어느 시점이 되면 무엇을 하더라도 너무 많은 데이터 입력과 클릭이 필요하거나 백로그를 정리하기 위해 너무 많은 작업이 필요한 노동으로 변질된다.

고급 사용자는 단축 키와 바로가기를 익혀서 문제를 보완할 수 있다. 필자는 새 지라 이슈를 만드는 "c", 이슈를 팀원에게 할당하는 "a", 레이블을 지정하는 "I", 단축키 찾기 도움말인 "?" 등을 자주 사용한다. 여러 개의 새 지라 이슈를 만들 때는 백로그 화면에서 릴리스와 에픽을 미리 선택해서 새 이슈가 자동으로 할당되도록 한다. 많은 변경을 해야 하는 경우 이슈를 검색하고 강력한 벌크 편집 기능을 사용한다.

그러나 새로운 지라 사용자가 많은 시간을 투자해 이런 여러 방법을 익히지는 않는다. 이들은 스토리의 세부적인 부분을 무시한 채 필요에 따라 지라를 업데이트하는 데 너무 많은 시간을 소비한다. 스크럼 마스터는 팀 동료들이 뒤떨어질 때 지라 이슈를 업데이트해야 한다는 생각만으로도 진저리를 친다.

요약하자면, 지라를 사용하는 일부 애자일 조직과 팀은 지나치게 복잡해진 프로세스와 팀 구성 탓에 길을 잃었다. 그러나 이런 함정을 피하고 구성을 조정하면 리더와 관리자, 사용자는 지라 툴의 유용함을 되찾을 수 있다. 


지라의 회계 시스템화 방지

지라는 팀 협업을 실현하고 스토리 요구 사항, 팀 속도, 릴리스와 에픽, 스프린트의 상태와 같은 중요한 정보를 포착하는 데 사용되어야 한다.

팀에 따라서는 사용자 스토리 및 작업과 같은 이슈를 하위 작업으로 세분화하는 것이 더 좋다. 특히 세분화는 기술적 성숙도가 낮거나 지리적으로 분산되거나 스토리를 이행하기 위해 많은 종류의 기술적 스킬이 필요한 팀에 유용하다. 스토리를 하위 작업으로 세분화하면 이러한 팀에서 누가 무엇을 하고 어떤 순서로 하는지에 관한 커뮤니케이션에 유용하다.

그러나 제품과 기술 아키텍처, 팀 동료들에 대해 잘 아는 팀에는 필요 이상으로 복잡한 과정이다. 이들은 스탠드업 미팅에서 구현 접근 방법을 전파하거나, 지라 이슈에 주석 달기, 슬랙, 힙챗, 구글 행아웃 미팅 등 협업 툴을 사용할 수 있다. 작업 세분화를 묻거나 요구하는 것은 고급 개발자의 짜증을 유발할 뿐이다.

한 걸음 더 나아가서 지라에서 시간 추적까지 요구하면 개발자와 테스터의 짜증은 더욱 커진다. 다른 더 나은 방법으로 이슈의 복잡성과 작업을 포착할 수 있다. 애자일 팀 동료에게 시간을 기록하라고 요구하면 상황이 악화될 뿐이다. 애자일 팀은 시간에 대한 자세한 척도를 확인하는 것보다는 애자일 문화와 마음가짐을 개선하는 데 집중해야 한다.

마지막으로, 지라 이슈 워크플로우를 구성하는 데 매몰되기가 쉽다. 지라는 활성 스프린트 보드와 같은 수영 레인으로 간단한 할 일(To Do), 하는 중(Doing), 완료(Done) 워크플로우를 설정한다. 일부 팀은 작성된 요구 사항, 추가된 설계, 완료된 계산, 해결된 데브옵스 기능과 같은 상태와 전환을 더 많이 캡처하기 위해 상태를 또 추가한다. 더 나아가 특정 전환을 제한하고 역할 기반 규칙을 워크플로우에 추가하거나, 지라 이슈 유형별로 다른 워크플로우를 만들기도 한다.

이런 모든 복잡성은 애자일 프로세스를 관리하는 사람에게는 정상적이고 필요한 요소로 보이지만 애자일을 실천하는 사람들에게는 강압적으로 느껴질 수 있다. 또한 수영 레인과 필요한 상태 전환의 정렬이 어긋나는 경우 기능 장애로 이어질 수도 있다.

핵심은 구성과 워크플로우의 복잡성이 지나치게 높아지면 사용자의 불만도 함께 높이진다는 것이다.


과도한 복잡성 없이 지라 기능 확장하기

간혹 지라를 포함해 어느 툴이든 해당 툴로 너무 많은 일을 하려는 사람들이 있다. 이 경우 실제 사용자의 일상적인 업무가 필요 이상으로 어려워진다. 아예 하지 않는 편이 더 나을 때도 있고 그 외의 경우에는 다른 툴과 통합하기 위한 옵션이나 간단한 대처 방법을 찾을 수 있다.

지라에서 필자의 불만 가운데 하나는 에픽, 스토리, 하위 작업을 3계층만 지원한다는 점이다. 많은 그룹은 스토리의 레벨을 추가해 상위 요소, 에픽의 하위 요소와 같은 기능을 지원하기를 원한다. 이렇게 하면 장시간 실행되는 향상을 에픽으로 나타내고, 하나의 릴리스 또는 소수의 여러 릴리스에 구현된 하나 이상의 스토리를 기능에서 캡처할 수 있다.

필자가 선호하는 방법은 팀에 이슈 요약을 입력할 때 접두어를 붙이도록 요청하는 것이다. 기능이 "로그인"이고 스토리가 "비밀번호 분실 기능 활성화"라면 이슈 요약은 "로그인: 비밀번호 분실 기능 활성화"가 될 수 있다. 또 다른 방법은 기능 이름을 나타내는 맞춤 필드를 만드는 것이다.

완벽한 해결책은 아니고 사용자가 기능 이름을 모를 경우 데이터 품질 문제로 이어질 수 있다. 그러나 기능 개발은 소수의 스프린트에서 수행되는 작업에 묶이므로 이 기능이 없는 지라에서는 쓸 만한 대처 방법이다.

이와 관련된 문제는 지라를 제품 및 프로젝트 포트폴리오 관리자를 위한 완벽한 시스템으로 만들려고 하는 것이다. 팀 동료들은 전략, 이니셔티브, 로드맵, 목표, 주요 성과 지표 및 기타 스토리를 이야기하고 비즈니스 수준의 상태를 커뮤니케이션하는 비즈니스 아티팩트를 캡처하고 관리해야 한다. 지라는 이런 용도의 툴이 아니다. 대신 포트폴리오 포 지라(Portfolio for Jira), 아하!(Aha!) 및 기타 제품 관리 툴을 사용하면 된다. 제품 소유자와 관리자가 지라를 용도에 맞게 사용하기 어렵다면 지라 소프트웨어에서 제공하는, 데이터를 통합하는 이러한 툴 중 하나를 사용하는 방법이 있다.

지라의 보고 툴이 더 이상 충분하지 않다면 다른 데이터베이스와 보고 툴로 지라의 메트릭스를 옮기는 방법도 있다. 예를 들어 태블로(Tableau)를 사용해 더 세부적인 속도와 번다운 차트를 볼 수 있다.

마지막으로, 수준이 높은 팀이라면 반복적인 특정 지라 작업과 스토리를 표준화하기를 원할 수 있다. 정해진 일정에 따라 백로그에 나타내야 하는 반복 작업의 경우 마켓플레이스에 있는 리커링 태스크 포 지라 클라우드(Recurring Tasks for Jira Cloud) 애플리케이션을 사용할 수 있다. 

템플릿화된 작업 그룹을 특정 작업의 백로그에 추가해야 하는 운영 팀을 위한 툴도 있다. 필자의 경우 퀵베이스(Quickbase)를 사용해 템플릿화된 스토리를 저장하고, 퀵베이스 및 지라 재피어(Jira Zapier) 통합을 사용해 지라로 전송했다.

지라는 많은 애자일 팀에 사용되는 다재다능한 툴이지만 데이터 입력과 워크플로우를 과잉 엔지니어링해서 팀 협업을 저해하는 요소가 되기 쉽다. 다른 모든 소프트웨어 툴과 마찬가지로, 전문가와 초급자, 프로그램 관리자가 함께 필요한 거버넌스와 협업을 제공하는 구현 방법을 찾는 것이 최선이다. editor@itworld.co.kr 


2019.05.29

How To : 지라를 쉽게 사용하는 방법

Isaac Sacolick | InfoWorld
애자일 프로젝트를 관리하기 위해 아틀라시안 지라 소프트웨어(Atlassian Jira Software)를 갓 사용하기 시작한 개발자나 테스터와 이야기를 해보면 이들의 흥분을 느낄 수 있다. 지라는 스크럼(scrum), 칸반(Kanban) 또는 기타 프로젝트 관리 프로세스에서 애자일 팀을 지원하며 비교적 사용하기 쉬운 툴이기 때문이다.



지라는 고급 단계의 애자일 팀과 초기 단계의 애자일 팀을 위한 기능을 모두 갖추고 있다. 백로그를 스프린트(sprint) 관리와 별도의 활동으로 관리하도록 지원한다. 대시보드에서 팀과 개인에 따라 가장 중요한 정보를 맞춤 설정할 수 있다. 기본 보고 기능도 속도와 사이클 시간을 관리하고 릴리스와 에픽을 추적하기 시작한 대부분의 팀에 충분할 만큼 좋다. 컨플루언스(Confluence), 깃(Git) 등 개발자들이 사용하는 다양한 다른 툴과의 통합도 견고하다. 필요한 기능이 없다면 마켓플레이스에서 부가적인 기능과 통합을 찾아보면 된다.


지라에서 마음에 들지 않는 부분 

그런데 몇 년 동안 지라를 사용해 온 스크럼 마스터, 개발자, 엔지니어, 테스터와 이야기를 해보면 열정이 식었음을 종종 느낄 수 있다. 이들에게 지라(그리고 애자일 개발 프로세스의 어떤 측면)는 관리 복잡성 증가의 요인이다. 애자일 분야에서 오랜 경험을 쌓은 이들과 고급 지라 사용자는 애자일 방법과 지라 사용 방법을 깨끗이 정리하고 싶어한다.

문제가 무엇인지 살펴보자. 우선 팀에서 사용하는 기능과 구성이 늘어남에 따라 툴을 구성하고 사용하는 과정이 불친절하고 복잡해진다. 지라는 필드와 워크플로우, 스크린, 이슈 유형, 이슈 레이아웃을 프로젝트 수준에서 맞춤구성한 다음, 체계를 통해 이러한 구성을 여러 팀에 공유할 수 있게 해준다. 그러나 과잉 엔지니어링과 구성에 빠지기 쉽고, 결국 한때 사용하기 쉬웠던 툴이 어느 시점이 되면 무엇을 하더라도 너무 많은 데이터 입력과 클릭이 필요하거나 백로그를 정리하기 위해 너무 많은 작업이 필요한 노동으로 변질된다.

고급 사용자는 단축 키와 바로가기를 익혀서 문제를 보완할 수 있다. 필자는 새 지라 이슈를 만드는 "c", 이슈를 팀원에게 할당하는 "a", 레이블을 지정하는 "I", 단축키 찾기 도움말인 "?" 등을 자주 사용한다. 여러 개의 새 지라 이슈를 만들 때는 백로그 화면에서 릴리스와 에픽을 미리 선택해서 새 이슈가 자동으로 할당되도록 한다. 많은 변경을 해야 하는 경우 이슈를 검색하고 강력한 벌크 편집 기능을 사용한다.

그러나 새로운 지라 사용자가 많은 시간을 투자해 이런 여러 방법을 익히지는 않는다. 이들은 스토리의 세부적인 부분을 무시한 채 필요에 따라 지라를 업데이트하는 데 너무 많은 시간을 소비한다. 스크럼 마스터는 팀 동료들이 뒤떨어질 때 지라 이슈를 업데이트해야 한다는 생각만으로도 진저리를 친다.

요약하자면, 지라를 사용하는 일부 애자일 조직과 팀은 지나치게 복잡해진 프로세스와 팀 구성 탓에 길을 잃었다. 그러나 이런 함정을 피하고 구성을 조정하면 리더와 관리자, 사용자는 지라 툴의 유용함을 되찾을 수 있다. 


지라의 회계 시스템화 방지

지라는 팀 협업을 실현하고 스토리 요구 사항, 팀 속도, 릴리스와 에픽, 스프린트의 상태와 같은 중요한 정보를 포착하는 데 사용되어야 한다.

팀에 따라서는 사용자 스토리 및 작업과 같은 이슈를 하위 작업으로 세분화하는 것이 더 좋다. 특히 세분화는 기술적 성숙도가 낮거나 지리적으로 분산되거나 스토리를 이행하기 위해 많은 종류의 기술적 스킬이 필요한 팀에 유용하다. 스토리를 하위 작업으로 세분화하면 이러한 팀에서 누가 무엇을 하고 어떤 순서로 하는지에 관한 커뮤니케이션에 유용하다.

그러나 제품과 기술 아키텍처, 팀 동료들에 대해 잘 아는 팀에는 필요 이상으로 복잡한 과정이다. 이들은 스탠드업 미팅에서 구현 접근 방법을 전파하거나, 지라 이슈에 주석 달기, 슬랙, 힙챗, 구글 행아웃 미팅 등 협업 툴을 사용할 수 있다. 작업 세분화를 묻거나 요구하는 것은 고급 개발자의 짜증을 유발할 뿐이다.

한 걸음 더 나아가서 지라에서 시간 추적까지 요구하면 개발자와 테스터의 짜증은 더욱 커진다. 다른 더 나은 방법으로 이슈의 복잡성과 작업을 포착할 수 있다. 애자일 팀 동료에게 시간을 기록하라고 요구하면 상황이 악화될 뿐이다. 애자일 팀은 시간에 대한 자세한 척도를 확인하는 것보다는 애자일 문화와 마음가짐을 개선하는 데 집중해야 한다.

마지막으로, 지라 이슈 워크플로우를 구성하는 데 매몰되기가 쉽다. 지라는 활성 스프린트 보드와 같은 수영 레인으로 간단한 할 일(To Do), 하는 중(Doing), 완료(Done) 워크플로우를 설정한다. 일부 팀은 작성된 요구 사항, 추가된 설계, 완료된 계산, 해결된 데브옵스 기능과 같은 상태와 전환을 더 많이 캡처하기 위해 상태를 또 추가한다. 더 나아가 특정 전환을 제한하고 역할 기반 규칙을 워크플로우에 추가하거나, 지라 이슈 유형별로 다른 워크플로우를 만들기도 한다.

이런 모든 복잡성은 애자일 프로세스를 관리하는 사람에게는 정상적이고 필요한 요소로 보이지만 애자일을 실천하는 사람들에게는 강압적으로 느껴질 수 있다. 또한 수영 레인과 필요한 상태 전환의 정렬이 어긋나는 경우 기능 장애로 이어질 수도 있다.

핵심은 구성과 워크플로우의 복잡성이 지나치게 높아지면 사용자의 불만도 함께 높이진다는 것이다.


과도한 복잡성 없이 지라 기능 확장하기

간혹 지라를 포함해 어느 툴이든 해당 툴로 너무 많은 일을 하려는 사람들이 있다. 이 경우 실제 사용자의 일상적인 업무가 필요 이상으로 어려워진다. 아예 하지 않는 편이 더 나을 때도 있고 그 외의 경우에는 다른 툴과 통합하기 위한 옵션이나 간단한 대처 방법을 찾을 수 있다.

지라에서 필자의 불만 가운데 하나는 에픽, 스토리, 하위 작업을 3계층만 지원한다는 점이다. 많은 그룹은 스토리의 레벨을 추가해 상위 요소, 에픽의 하위 요소와 같은 기능을 지원하기를 원한다. 이렇게 하면 장시간 실행되는 향상을 에픽으로 나타내고, 하나의 릴리스 또는 소수의 여러 릴리스에 구현된 하나 이상의 스토리를 기능에서 캡처할 수 있다.

필자가 선호하는 방법은 팀에 이슈 요약을 입력할 때 접두어를 붙이도록 요청하는 것이다. 기능이 "로그인"이고 스토리가 "비밀번호 분실 기능 활성화"라면 이슈 요약은 "로그인: 비밀번호 분실 기능 활성화"가 될 수 있다. 또 다른 방법은 기능 이름을 나타내는 맞춤 필드를 만드는 것이다.

완벽한 해결책은 아니고 사용자가 기능 이름을 모를 경우 데이터 품질 문제로 이어질 수 있다. 그러나 기능 개발은 소수의 스프린트에서 수행되는 작업에 묶이므로 이 기능이 없는 지라에서는 쓸 만한 대처 방법이다.

이와 관련된 문제는 지라를 제품 및 프로젝트 포트폴리오 관리자를 위한 완벽한 시스템으로 만들려고 하는 것이다. 팀 동료들은 전략, 이니셔티브, 로드맵, 목표, 주요 성과 지표 및 기타 스토리를 이야기하고 비즈니스 수준의 상태를 커뮤니케이션하는 비즈니스 아티팩트를 캡처하고 관리해야 한다. 지라는 이런 용도의 툴이 아니다. 대신 포트폴리오 포 지라(Portfolio for Jira), 아하!(Aha!) 및 기타 제품 관리 툴을 사용하면 된다. 제품 소유자와 관리자가 지라를 용도에 맞게 사용하기 어렵다면 지라 소프트웨어에서 제공하는, 데이터를 통합하는 이러한 툴 중 하나를 사용하는 방법이 있다.

지라의 보고 툴이 더 이상 충분하지 않다면 다른 데이터베이스와 보고 툴로 지라의 메트릭스를 옮기는 방법도 있다. 예를 들어 태블로(Tableau)를 사용해 더 세부적인 속도와 번다운 차트를 볼 수 있다.

마지막으로, 수준이 높은 팀이라면 반복적인 특정 지라 작업과 스토리를 표준화하기를 원할 수 있다. 정해진 일정에 따라 백로그에 나타내야 하는 반복 작업의 경우 마켓플레이스에 있는 리커링 태스크 포 지라 클라우드(Recurring Tasks for Jira Cloud) 애플리케이션을 사용할 수 있다. 

템플릿화된 작업 그룹을 특정 작업의 백로그에 추가해야 하는 운영 팀을 위한 툴도 있다. 필자의 경우 퀵베이스(Quickbase)를 사용해 템플릿화된 스토리를 저장하고, 퀵베이스 및 지라 재피어(Jira Zapier) 통합을 사용해 지라로 전송했다.

지라는 많은 애자일 팀에 사용되는 다재다능한 툴이지만 데이터 입력과 워크플로우를 과잉 엔지니어링해서 팀 협업을 저해하는 요소가 되기 쉽다. 다른 모든 소프트웨어 툴과 마찬가지로, 전문가와 초급자, 프로그램 관리자가 함께 필요한 거버넌스와 협업을 제공하는 구현 방법을 찾는 것이 최선이다. editor@itworld.co.kr 


X