Atlassian playbook - 5 whys

Atlassain playbook 번역해보기 #2

오래전에 DACI 번역하고 이제 두번째로 번역, 정리해보는 프레임워크네요. 5 Whys 프레임워크입니다.

원글: https://www.atlassian.com/ko/team-playbook/plays/5-whys

5 Whys Analysis framework

5 Whys 프레임워크는 문제의 근본 원인을 찾아냅니다.
컨플루언스 템플릿이나 다른 템플릿들은 원글에서 확인하실 수 있습니다.

플레이북 진행

1. 준비 Prep

문제 설명을 준비하세요. 팀이 현재 직면하고 있는 문제일 수도 있고 해결해야 할 과거에 발생한 문제일 수도 있습니다.
원격 팀의 경우 협업 문서(위의 선택적 템플릿 참조)를 만들고 팀과 미리 공유하세요.

대면 팀의 경우 다음 열로 화이트보드에 레이블을 지정합니다.

  • 문제 설명 1
  • 문제 설명 2
  • 문제 설명 3
  • 문제 설명 4
  • 문제 설명 5
  • 어떻게 해결할 수 있는지?

2. 무대 설정

회의 시작 시 팀에 다음 사항을 알리세요.

  • 우리는 문제의 근원을 찾기 위해 깊이 파고들 것입니다.
  • 우리는 비난하기 위해 여기 있는 것이 아니라 조사하기 위해 왔습니다.

팁: 5 Whys Analysis Play는 호기심과 실수로부터 배우는 것을 장려하는 문화에서 가장 잘 작동합니다. 이런 종류의 환경은 비난 게임으로 변하는 것을 방지합니다.

3. 브레인스토밍

초기 문제 설명의 경우 팀에 “왜 이런 일이 발생했습니까?”라고 질문하세요.
타이머를 5분으로 설정합니다. 팀이 공동 작업 문서 또는 화이트보드에 자신의 답변을 추가하도록 합니다.

팁: 다른 방법으로 물어보세요

  • 문제의 원인은 무엇입니까?
  • 무엇이 문제로 이어졌습니까?
  • 문제가 발생한 조건은 무엇입니까?
  • 문제에 기여한 것은 무엇입니까?

4. 선택

팀으로서 다음 문제 설명으로 자세히 설명할 답변 중 하나를 선택하세요.
초기 문제 설명을 이것으로 바꿉니다.

팁: 투표하기
앞으로 나아갈 문제 진술에 투표하세요.
Trello Voting Power-Up을 시도하거나 팀이 선택한 진술에 +1을 추가하도록 합니다.

5. 반복

총 5번을 “왜?”라고 물을 때까지 3단계와 4단계를 반복합니다.

팁: WHYS
팀에서 의미 있는 수준의 근본 원인에 도달했다고 동의할 때까지 “왜”를 계속 물어보세요.

6. 솔루션 제안

근본 원인의 지점에 도달하면 팀 구성원이 최종 문제 설명에 대한 솔루션을 제안하게 합니다.
진행할 솔루션을 한두 개만 선택하고 각 솔루션에 담당자를 지정하고 팀이 담당자로부터 응답을 받을 수 있는 시점을 결정합니다.

팔로업 Follow ups

  • 모든 메모 캡처
    • 전체 팀이 볼 수 있는 장소에 세션의 메모를 게시합니다.
  • 작업 추적
    • Jira 또는 Trello와 같은 팀의 작업 보드에 문제 설명을 작업 항목으로 추가합니다.
  • 체크인
    • 합의된 시간에 제안된 솔루션의 진행 상황을 확인하고 있는지 확인하세요.

변형 Variations

브레이크아웃 / Breakout
첫 번째 브레인스토밍 단계 후, 하나의 문제 진술에 투표하는 대신 그룹이 각 문제 진술에 대해 하나씩 팀으로 나뉩니다.
그런 다음 나머지 팀 플레이를 따라 각 팀이 끝나는 근본 원인을 확인하세요.

Playbook - 5 Whys 활동 문서 번역을 마치며

이번 플레이북 5 Whys는 내용이 어렵지 않기도 하고 본문이 길지도 않아서 금방 번역을 마쳤네요.
실제 업무에서도 5 Whys 처럼 단계를 모두 따라서 문제를 정의하는 경우가 있긴하겠지만 대부분 2-3번째 쯤에 문제가 정의되는 것 같긴합니다.
정의하기 어려운 문제는 5번 이상 원인에 대해 파악해봐야겠지만요. 😇

이 프레임워크에 대해 알게된 건 박물관 이야기였던 것 같네요.

제퍼슨 기념관(Jefferson memorial) - 대리석 지붕이 빨리 부식되는 원인을 찾자

  • 왜 대리석이 빨리 부식되는가?
    • 세제로 자주 씻고 있음
  • 왜 세제로 자주 씻는가?
    • 비둘기 배설물이 많아 자주 씻음
  • 왜 비둘기가 많은가?
    • 비둘기의 먹이인 거미가 많음
  • 왜 거미가 많은가?
    • 거미의 먹이인 나방이 많음
  • 왜 나방이 많은가?
    • 직원들이 일찍 퇴근하면서 해지기 전 전등을 켜서 나방이 몰려듬

-> 기념관 직원들의 업무시간을 조정하여 해가 진 후 전등을 켬

이 외에 많은 예시가 있겠지만 여러 단계에 걸쳐서 문제 원인을 찾고 해결해나가는 기법입니다.
대부분 머리속에서 정리되는 경우가 있지만 큰 문제나 다같이 문제를 풀어야하는 경우에는 이 기법을 사용해보면 좋지 않을까 싶네요.

참고하면 좋을만한 글

Product Plan vs Release Plan 글을 보고

원문

https://www.aha.io/blog/the-product-plan-vs-the-release-plan

Product Plan vs Release Plan?

제목을 번역해보면 “제품 계획 vs 출시 계획”으로 볼 수 있겠네요
처음에 이 글을 봤을 때, 두 계획이 다른 것은 이미 알고 있는데 어떻게 다른가에 대해 깊게 고민한적은 없었던 것 같습니다.

위 글에서 두 계획에 대해 정의한 것이 인상깊어 공부 겸 글 내용을 정리해보았습니다.

제품 계획은 제품의 전략적 방향을 정의하는 반면 출시 계획은 비전을 달성하는 데 필요한 작업을 정의합니다.”

두 계획 모두 중요하지만 다른 것을 정의하고 있습니다.
제품 계획은 왜(Why) 이것을 만들고 있는지, 우리는 무엇(What) 을 성취하려고 하는지 답을 줍니다.
출시 계획은 정확히 무엇(What) 을 빌드해야하는지, 언제(When) 만들 것인지, 제품 경험을 어떻게(How) 제공할 것인지를 정의합니다.

6하 원칙으로 정리하는게 깔끔하긴 하네요.
제품 계획에는 왜 라는 프로덕트 목표 설정이 중요한 것 같고
출시 계획에는 언제 어떻게 무엇을 전달 또는 배포할 수 있을지 정의하는 것이 중요하겠네요.
Who, Where은 때에 따라 제품 계획에 들어갈 수 있을 것 같습니다. 😁

목표(Goal) 관점

제품 계획 목표: 제품의 방향성을 전달하는 것. 전략 및 비즈니스 목표를 기반으로 제품이 비즈니스 가치를 제공하는 방법을 보여줍니다.

출시 계획 목표: 제품 팀이 수행할 작업에 대해 책임을 지도록 하는 것. 작업의 세부 사항을 분명히 하고 완료해야하는 작업 단계를 강조합니다.

목표 관점에서 각 계획이 가지는 목표는 성격이 다른 것은 누구나 알 수 있겠지만 저는 상위 방향성 vs 상위 방향성이 동작하게 하는 워크플로우, 프로세스 등의 집합체 정도로 이해했습니다.
여기서 제 PM 업무를 떠올려보면 2가지 계획에 모두 기여를 해야하지만 출시 계획을 잡고 개발팀과 헉헉하느라 제품 계획에는 신경쓰지 못하는 것 같습니다. 😥

끝이 없네 끝이 없어..

매 주기마다 개발부서들과 개발한 콘텐츠 업데이트와 라이브 이슈 대응의 연속..

이니셔티브(initiative) 관점

제품 계획: 향후 6개월에서 1년 동안 주요 테마, 초점 영역 및 기능을 나타내는 이니셔티브를 제시합니다.

출시 계획 : 전략적 이니셔티브가 존재한다고 가정하고 팀에 집중하는데 중점을 둡니다.
출시 계획은 일상적인 성공을 위한 명확한 경로를 제시합니다. 출시 계획의 이니셔티브는 동기 부여, 책임에 관한 것입니다.

이 글에서 말하는 이니셔티브 개념은 목표를 달성하기 위한 액션 아이템 또는 액션 아이템들을 묶을 수 있는 계획이라고도 볼 수 있을 것 같습니다.
액션 아이템과 목표를 잘 버무린 계획의 느낌이네요.
OKR에서는 이니셔티브를 Key Result를 달성하기 위한 액션아이템, 어떻게 달성할지에 대한 것으로 정의하고 사용하는 케이스를 볼 수 있었습니다.

사실 사회에서 말하는 “이니셔티브”는 번역으로는 주도권, 주장이 되는 위치에서 이끌거나 지도할 수 있는 권리로 이야기하니 “권한”의 성격을 띄고 있습니다.
기업에서 특정 이니셔티브 그룹에 가입하면서 이야기하는 “이니셔티브”는 계획에 더 가깝습니다. 특정 문제를 해결하기 위한 그룹 정도로 이해할 수 있을 것 같네요.

청중(Audience) 관점

제품 계획: 외부 또는 내부 전략 로드맵으로 시각화할 수 있습니다. 고객을 위해 기대할 수 있는 새로운 기능 또는 개선 사항의 주요 영역을 제시합니다.

츨시 계획: 내부 제품 팀 및 기타 교차 기능 기여자를 위한 것. 향후 작업을 계획하고 해당 작업의 세부 정보를 추적하는 데 도움이 됩니다.

여기서 청중은 이 계획을 듣는 사람들을 의미하는 것 같습니다.
제품 계획은 외부에 공유하는 러프한 로드맵 이런 것으로 바꿔서 사용할 수 있는 것,
출시 계획은 내부 프로덕션 프로세스 문서, 업무 가이드가 될 것 같네요.

타임라인(Timeline) 관점

제품 계획: 장기간에 걸친 전략적 목표와 이니셔티브를 제시합니다. 소프트웨어 회사의 경우 1년이 일반적입니다.
출시 계획: 기능 배포 또는 주요 출시로 이어지는 특정 작업 단계를 추적합니다. 30, 60, 90일 단위인 경우가 많습니다.

제품 계획은 타임라인으로 보면 1년 계획 + 더 큰 차원의 계획도 있을 수 있겠다 싶습니다.
예를 들면, 게임의 핵심 재미를 정의하고 어떻게 그 재미를 더 키울 수 있을까를 계획하거나 다른 맛을 곁들이거나 하는 등의 방향 설정이 있을 것 같아요.

출시 계획은 단순히 생각하면 업데이트 주기를 말할 수 있겠습니다. 그 주기에 맞춰 필요한 일들의 타임라인을 정리하고 프로세스화 한 것을 출시 계획으로 볼 수 있겠죠.

마무리

글 마지막에는 “How do you use product plans and release plans in your work?” 라고 질문을 해주었는데 글을 읽다보니 저는 제품 계획이 잘 이뤄질 수 있도록 출시 계획을 관리하고 있었구나 싶었습니다.

Being responsible for a product plan and a release plan challenges product managers to think about every element of delivering a Complete Product Experience. It is a good way to encourage both big and small thinking.

이런 말을 글 마지막에 크게 달아뒀는데 각 계획을 정의하고 그 정의에 맞춰 일을 정리해나가는 것이 좋은 경험이 되는 것 같습니다.
어떤 게임 개발사는 패키지 형태로 한번에 빡 출시하고, 어떤 개발사는 얼리억세스부터 지속적인 업데이트를 통해 출시하고 여러 방법이 있으니 각자의 계획이 다 다르겠죠

너는 다 계획이 있구나! - 기생충

어쨌든 각자의 계획이 다 있는 것 아니겠습니까 😁

우리는 어떤 계획을 가지고 살고 있는지, 2개의 계획을 분리해서 보자면 어떻게 정의하고 있는지 생각해볼 수 있는 시간이었어서 재미있는 글이었습니다.
다른 재미있는 글들도 있으니 나중에 보고 또 공부 겸 포스트해보겠습니다.

NDC22 프로덕션 발표 리뷰 - 피파 온라인4 라이브 서비스

NDC22 발표 리뷰

6월에 여러 컨퍼런스가 있었는데 게임 업계 프로덕션 직군에서 일하는 사람이니 NDC 프로덕션 내용들은 잘 챙겨서 봐야겠다 싶어서 보면서 슬쩍 정리해보았습니다.

리뷰라고 말하긴했지만 배울 것과 우리 조직, 프로덕션 상황을 같이 보면서 되돌아볼 수 있는 것들이 있어 흥미롭게 발표를 보았어요. ㅎㅎ

https://www.youtube.com/watch?v=rK83XrOU5Bg

리뷰

처음에는 피파 온라인 서비스를 오래 운영한 팀의 이야기가 궁금해서 들어보았는데 외부에 공유할 수 있는 만큼 잘 정제(?)해서 공유해주셨구나 싶었습니다.

조직 구조, 업무 방식을 외부에 공유한다는게 긍정적인 것 보다 우려가 많을 수 있는데 적당히 추상화해서 공유해서 가능했던 걸까 싶었네요.

  • 서비스 기간
    • 피파 온라인4는 2018년 부터 서비스한 게임이지만 피파 온라인 시리즈는 발표에서 말하길 16년차된 서비스로 소개해주셨습니다.
    • 히스토리를 좀 확인해보았더니 피파 온라인1은 2006년에 런칭했었네요. 1부터 보면 16년차 맞습니다. ㅎㅎ
    • 게임을 개발하고 서비스하면서 어떤 어려움들이 있었을까, 어떤 그림자들이 있었을까 궁금하기도 했네요.
  • 조직 구조 - 약 150명 정도
    • 조직 구조는 기능 조직으로 구성하고 모든 기능 조직들을 묶는 Line 조직에 PD를 두는 것으로 보이네요.
    • PD 중심으로 기능적으로 조직을 구성하고 조직에 시니어들은 매니저 부담을 덜고 개인과 주니어의 커리어와 제작의 퀄리티를 담당하게 한 것에 대해 매니저(DD)와 시니어를 분리해서 평가 체계를 가져간 것이 신기했습니다
  • 2개의 개발팀(Meta/Core) 로테이션
    • 라이브팀 운영을 해보려했지만 개발자들은 콘텐츠를 만들고 싶어하는 경향과 라이브팀 운영 특성상 노령화가 될 수 밖에 없고 해보았으나 조직 운영에 어려움이 있었던 것 같았습니다.
    • 3, 6개월 단위의 업데이트도 시도해보았지만 라이브 대응이 어려웠다고 합니다.
      (이슈 대응과 업데이트는 다른 카테고리의 이슈인데 왜 그 단위만큼 늘어지는 구조를 사용했었을까하는 의문이 있었네요. 🤔)
  • 의사결정
    • 앞에서 조직 구조 이야기하면서 PD 중심의 조직이 있고 그 조직에는 모든 직군팀이 있다고 했었습니다. 이에 따라 기능 조직을 모았지만 목적 조직 아래에 기능 조직이 모인 형태로 이해했어요.
    • 이런 목적 조직 구조의 특성상 의사결정 속도는 빠르게 이뤄질 수 있겠다 싶었습니다.
  • 프로덕션 프로세스
    • 각 프로세스 단계의 정의와 결과물의 정의를 깔끔하게 했다는 인상을 받았습니다. 라이브 서비스를 오래했던 만큼 프로세스가 잘 닦여있다는 인상을 받았어요.
    • 각 프로세스에서 진행되는 일에 대해 다이어그램으로 표현한 것을 보면서 우리도 저런게 잘 정리되면 좋겠다 싶었습니다.
    • Hardening 이라는 표현은 생소했는데 피파 온라인팀에서는 퍼블리셔와 함께 빌드가 단단한지 확인하고 문제가 있다면 수정하는 단계 정도로 정의한게 신기했습니다. (우리는 릴리스 준비 정도로 간략히 정리해볼 수 있겠다 싶었네요)
  • 라이브 이슈 대응 우선순위
    • 가이드 문서에서 기억에 남는 것은 이슈 우선순위에 따라 대응을 며칠 전까지 해야하는가에 대해 정의되어있었다는 점이네요. 추가로 연락 방법도! (전화, 메일, Jira 이런식으로 나눠짐)
    • 라이브 이슈 대응 우선순위 가이드라인 내용이 우리도 필요하겠다 싶었습니다
  • 라이브 서비스 플랜
    • 롱텀 플랜을 만들고 명확한 기준으로 개발, 출시하고 있는데 피파 온라인 게임 콘텐츠 특성상 현실세계 시즈널 이벤트들이 있고 그에 맞춰 계획, 개발하고 있다고 합니다.
    • 개인적인 생각으로는 코로나 영향으로 축구 경기도 연기되고 하느라 이벤트 대응에 이슈가 있었지 않았을까 싶긴했네요. 😂

발표 내용 노트

개발팀 구조

  • 22년 조직 변경 방향성: 직능적 구조(직군 모임)로 바꾸고 매니저 역할(목표 관리), 시니어 역할(업무 관리, 퀄리티 관리) 나눠서 결정을 빠르게하고 대응함
  • Core, Meta, Codev 등 직군별로 팀을 나누고 PD 중심 기능적으로 조직을 변경
  • 2개의 프로덕션팀 - Core, Meta
    • Core: Fun, Competitive Gaming, Core Ex 등 UI/UX 개발
    • Meta: 프로그레션, 라이브 서비스, 유료화, 개인화 경험 개발
    • 2개의 프로덕션팀은 2개월 로테이션으로 콘텐츠 개발, 라이브 서비스를 돌아가면서 대응함
    • 버그 대응: 본인의 팀에서 개발한 콘텐츠 버그는 콘텐츠 개발팀에서 수정한다
  • 스페셜팀(DET): 개발환경 개선, 인프라 개선 등 긴 호흡으로 스페셜한 영역의 일을 함
  • Art, CODEV 등 팀이 있음
  • 우리와 비슷한 이슈
    • 버그 수정하더라도 1-2달 뒤에나 수정한 것을 배포할 수 있었음

Work Process

  • High-level Roadmap
    • 로드맵을 만들 때 PD는 어떤 것을 개발할지 결정
    • GD는 콘텐츠 목표, 방향성을 정의
  • Pre-Planning
    • 피쳐에 대한 상세 정의
    • 결과물: IDD, PDD, FDD 등 디자인 문서
  • Planning
    • Pre Planning 하면서 이미 유관부서는 컨텍스트를 알고 있기에 안정적인 계획을 할 수 있음
    • 결과물: FDD 기준으로 만들어진 TDB(기술 문서), 로그 설계 문서, 테스트 설계 문서
  • Development
    • 진짜 개발, 프로덕션 시작
    • 개발하면서 사전 테스트 프로세스를 진행하여 안정성을 올림
  • Debugging
    • 테스트 문서를 기반으로 디버깅 진행
    • QA팀은 빌드 내에서 전체 기능 테스트 진행. 목표는 퍼블리셔 스테이징 환경에서 진행할 QA를 위해 빌드를 준비하는 것
  • Hardening
    • 퍼블리셔 시스템, 모바일 플랫폼 확인 등 빌드 유효성 검증 테스트
    • 결과물: 최종 빌드, 빌드 노트, 점검 노트
  • Release / Live Support
    • 릴리스 모니터링 및 피쳐 분석
    • 버그 모니터링 후 핫픽스, 다음 패치 목표를 결정하기도 함
    • 결과물: 피쳐 분석 리포트, 유저 피드백들

피파온라인은 16년 동안 서비스한 게임으로 지금의 조직 구조가 탄탄하다고 평가하고 있음
2022년 목표로 피파온라인을 완성해보려하고 있음

마무리

NDC에서 소중한 프로덕션 사례를 발표해주신 EA Korea, 피파 온라인팀에 감사한 마음으로 보았습니다.
사실 프로덕션, 내부 조직 구조 내용은 발표나 자료들을 찾아보기 쉽지 않은데요.
이렇게라도 다른 개발 조직은 어떻게 살아가고 있는지 알 수 있어서 좋았습니다. 👍
이 포스트 이후에 팀 내부에 우리 조직과의 차이점, 배울점을 고민해보면 좋을 것 같다는 생각이 들었네요.
이만 포스트를 마치겠습니다. 🙏

이슈 트래커(Issue Tracker Jira)에 잘 접근하는 방법 고민 #1

방법 연구 목적

Jira에 접근해서 자신이 해야하는 일이 무엇인지 확인하기 어려워하는 분들이나 더 편하게 접근할 수 있는 방법이 있을까 하는 생각이 들었습니다. (갑자기?)
궁극적인 목적은 작업자들이 자신이 해야하는 일을 잘, 빠르고 편리하게 확인하고 일할 수 있는 것이죠.
나에게 할당된 일을 바로 알 수 있는 방법이 있다면 제일 좋을 것 같아 각 작업자의 작업 흐름, 작업 프로그램 등을 확인해봅니다.

(TMI) 이 글을 정리하게된 계기

https://youtu.be/xlV82Q-ZmAA

2021년에 OKKYCON에서 김영재님이 발표해주셨던 프로덕트 조직의 생산성 높이기 내용에 감명을 받아서 정리하게되었습니다.
(작년에 본 영상인데 왜 이제야? 라는 생각도 들지만 최근에 동료분들이 내가 어떤 일을 해야하는지에 대해 편하게 접근할 수 있다면 Jira와 친해지고 더 잘 쓸 수 있게되지 않을까했습니다. 😁)

영상에서는 “개발자가 이슈 트래커를 잘 쓴다는 기준”에 대해 다뤄주셨는데요.

  • 이슈 트래커 웹에서 적게 열어볼 수록 잘쓰는 것
  • 절대 상태를 손으로 바꾸지 않는 것 → (핵심) 커밋 메세지로 상태 변화가 가능한 것

작업

게임 개발(PUBG 기준)에 있어서 작업자 카테고리 및 작업 프로그램을 분류해보겠습니다.
일단 PUBG 개발은 Unreal Engine Editor, Perforce/Git 으로 작업하고 소스를 관리하고 있습니다.

엔지니어 Engineer

(코딩 + 블루프린트 작업) Visual Studio (Visual Studio Code), Unreal Engine Editor

  • 코딩 후 Git 히스토리 정리를 위해 SourceTree, Fork, GitKraken 등 Git GUI를 사용하는 경우도 있음
  • PUBG는 소스 컨트롤 시스템을 Perforce와 Gitlab(Git)을 쓰고 있음

아티스트 Artist

(애셋 작업) Maya, 3D Max …, Unreal Engine Editor

  • 컨셉 아티스트…의 경우 어도비 포토샵 또는 일러스트레이터?
  • 어쨌든 실제 게임에 적용되는 애셋들은 언리얼 에디터 통해서 반영되어야하니 커밋 내용을 작성하고 푸시하는 곳은 언리얼 에디터? Perforce?
  • (어디가 편할지는 인터뷰와 고민이 필요합니다.)

기획자 Designer

(데이터 작업 + 블루프린트 작업 등) Excel, Unreal Engine Editor

  • 데이터 작업을 엑셀로만 하지는 않고 언리얼 에디터에서 그래프를 수정하는 등 여러 작업이 있음
  • 블루프린트에 입력해야하는 데이터, 코드에서 가져다 쓰는 데이터 등 에디터와 에디터 밖에서 작업 가능함

작업 프로그램과 Jira 연결

각 작업자분들이 작업을 하는 프로그램에서 Jira 이슈를 볼 수 있는 방법이 있는지부터 확인을 해봐야겠죠?
작업 프로그램 하나하나 관련 플러그인이 있는지 확인해보겠습니다.

작업 프로그램Jira 연결 프로그램특징/코멘트
Visual StudioVSJira⚠️ VSJira
- VS 2019에서 동작하지 않는다는 평가가 많네요. (동작하는지 확인 필요)
Visual StudioCodeStream-vs✅ CodeStream-vs
- New Relic에서 만든 플러그인으로 VS 2019 버전에서 동작 가능하고 지금도 유지보수가 이뤄지고 있는 플러그인
- 내 이슈를 확인하고 이슈를 바로 만들 수도 있습니다.
- Jira 외에도 다른 서비스 연결이 강력하네요. (슬랙, 팀즈, 트렐로 등)
Visual Studio CodeJira and Bitbucket✅ Jira and Bitbucket
- 아틀라시안에서 만든 플러그인으로 유지보수 및 여러가지 Jira 기능이 보장되어있습니다.
- 플러그인의 형태로 VS Code에 설치 후 서버 설정 및 계정 설정
- VS Code에서 바로 이슈 내용을 바로 볼 수 있습니다
- VS Code 내에서 필터를 구성해서 내가 보려는 이슈만 골라서 볼 수도 있고요
Unreal Engine EditorBug-reporter
❌ Bug tracker
❓ 언리얼 엔진 플러그인으로 있는 것을 찾기 어렵네요
- ❌ Bug-reporter 플러그인은 있는데 $30로 비용이…
- ❌ Bug Tracker 플러그인은 ₩73590… 꽤 비싸네요. 다만 Trello만 지원해서 패스.
없어서 플러그인 만들어서 써야하는 것 같습니다. (다른 회사들도 그냥 만들어쓰는걸까요..?)
Perforce(P4V)❌ / ⚠️ jira-perforce 연결
- P4V에서 바로 Jira 연결하는 플러그인은 따로 없고 커스텀 툴을 개발해서 넣어야합니다.
- HTML Tool 또는 Custom Tool을 따로 만들어서 적용해야합니다.
- 다른 서비스들에 연결은 할 수 있는데 추가로 구매하고 설정해야하는게 큰일이네요.

고민 1차 정리

일단 각 작업 프로그램별로 Jira 연결 프로그램을 확인해보았는데요.
Visual Studio쪽은 있는데 언리얼 에디터, 퍼포스 쪽은 제대로된 플러그인을 확인할 수 없었네요.

공교롭게도 게임 개발 관련 프로그램에는 Jira 연결 플러그인을 찾기 어려웠… (게임 개발과 이슈 트래커 툴은 친하지 않은 관계일까 싶기도했지만 아니겠죠..?)
물론 언리얼 에디터 쪽에 관련 플러그인이 있지만 Jira를 딱 잘 쓸 수 있게 만들어진 것은 아니어서 애매하다고 생각했습니다.

내부 동료 개발자분들은 어떻게 Jira를 사용하고 있는지, 어떤 방법으로 커밋(submit)할때 jira 이슈를 찾아서 보고 있는지 인터뷰해보고 개선 각을 봐야겠습니다.
개선 방식은 #2 포스트로 찾아올게요 😃

12 Jira Features from 2021

2021에 업데이트된 12가지 Jira Feature

https://community.atlassian.com/t5/Jira-articles/December-to-Remember-12-Jira-features-from-2021/ba-p/1873465

Jira 커뮤니티에 올라온 Jira 기능 업데이트 소개글이 있어 가져와봤습니다.
Jira Cloud에 업데이트된 기능들의 소개글이니 참고해서 봐주세요.

1. “Done(완료)” 상태 추가 기능

그동안 Done(완료) 상태 밖에 없었는데 원하는 상태명으로 완료 카테고리 상태를 추가할 수 있게되었습니다.

Learn more

2. 리스트 뷰 - 이슈 네비게이터에서 이슈 상태 업데이트 가능!

이슈를 열어서 상태 변경하지 않고 리스트뷰 상에서 상태 업데이트가 가능하도록 업데이트되었습니다.

Learn more

3. 드래그 & 드랍으로 이슈를 로드맵에서 관리

로드맵 기능에서 태스크를 생성하고 드래그 & 드랍으로 태스크 순서를 조정하는 등 태스크를 관리할 수 있습니다.

Learn more

4. 다른 프로젝트로 이슈 레이아웃 복사

프로젝트를 복사하거나 동일하게 이슈 레이아웃을 만들기 위해 이슈 레이아웃 복사 기능이 추가되었네요.

Learn more

5. Reopen closed sprints 끝난 스프린트 다시 열기

완료된 스프린트를 다시 열 수 있도록 기능이 추가되었네요.
실수로 완료되었거나 일정이 연장되는 등 이슈가 있는 스프린트을 다시 열 수 있도록 추가된 것 같습니다.

Learn more

6. Estimation 기능을 통한 진행도 확인

스토리 포인트, 시간 등 기존에 태스크 관리하던 데이터를 통해 작업의 진행도를 확인할 수 있는 estimation이 추가되었습니다.

Learn more

7. 이슈 타입별 워크플로우 추가

21년 중순까지는 이슈 타입별로 워크플로우 추가할 수 있는 기능이 없었는데 4분기쯤에 업데이트가 이뤄졌나보네요. 이슈 타입별로 워크플로우 설정하는 것은 서버버전에는 기본적으로 있었는데 클라우드 버전에 추가되었다니 다행이네요.

이슈 타입별 워크플로우

Learn more

8. 컨텍스트 뷰 업데이트

필요한 정보를 오른쪽 뷰에서 볼지 중간 뷰에서 볼지 설정할 수 있도록 업데이트가 되었습니다.
자세한 설정은 프로젝트 설정 > 이슈 레이아웃에서 해볼 수 있습니다.

컨텍스트 뷰 업데이트

Learn more

9. Your Work(내 작업)에 “Assigned to me(나에게 할당됨)” 추가

나에게 할당된 작업들을 바로 볼 수 있는 기능이 추가되었습니다.

기존에 대시보드를 통해 내 작업을 보던 사용자는 이게 유용한 기능일지 모르겠네요. 😈

10. JQL 에디터 업데이트

JQL을 이용한 이슈 검색에 유용한 에디터 업데이트가 이뤄졌습니다.

하이라이트 기능이나 자동완성 등이 깔끔하게 반영되었네요. 서버 버전에도 반영해주면 좋겠..

Learn more

11. 공지 배너

공지 배너에 대한 기능이 추가되었습니다. 닫을 수 있는 배너로 설정할 수도 있게 추가되었네요. 🤩

Learn more

12. 사이드바 네비게이션 개선

사이드바에서 보이는 메뉴의 우선순위 등을 조정한 것 같네요.

차세대 프로젝트에서는 볼 수 없고 기존 프로젝트에서 보드에 연결된 메뉴들을 따로 보거나할 수 있는 것 같습니다.

Learn more

마무리

21년 말에 작성된 글인데 이제 슬쩍보고 정리해볼 수 있었네요.
내용 대부분은 차세대 프로젝트에서 설정할 수 있는 내용이기보다 기존 프로젝트에서 사용할 수 있는 기능들이었던 것 같습니다.

서버 버전 업데이트는 없지만 클라우드 Jira도 슬슬 쓸만한 상황인건가 싶기도한데 개인 프로젝트나 일 정리할 때 써보면서 업무에 적용할 수 있을지 한번 조금씩 봐야겠습니다. 😁