이슈 오너쉽에 대해서 많이 궁금해 하시는데요 Kanban의 이슈 오너쉽을 예시로 들어보겠습니다.
예)
팀은 비즈니스팀, 개발팀, 운영팀이 있습니다.
할일-기획-개발-테스트-배포신청-배포완료 Workflow 입니다.
비즈니스팀에서는 할일, 기획 상태를 소유하고
개발팀에서는 개발-테스트 상태를 소유하고
운영팀에서는 배포신청-배포완료 상태를 소요할 수 있습니다.
각 상태의 중요도 설정은 오너쉽이 있는 팀에서 합니다.
비즈니스팀은 기획 이슈의 중요도를 자유롭게 정할 수 있습니다.
비즈니스팀의 상태의 이슈를 개발팀에서 선택하여 개발로 옮긴 후부터 개발팀의 소유가 됩니다.
Jira Wrap up
Jira ServiceDesk, Jira Software 로 요구사항을 요청할 수 있습니다.
대외 서비스를 하거나 고객이 많다면 Jira ServiceDesk로 고객을 관리할 수 있습니다.
고객에 내부에 있거나 Jira Software를 같이 사용한다면 Jira Software로 충분합니다.
이슈(티켓, 일감)를 만드는 이유는 이슈 진행 상황을 공유하고 협업과 사일로 현상을 방지할 수 있습니다.
이슈는 시작과 끝이 있습니다. 그래서 설명에 산출물, 많은 정보는 Confluence에 남겨야 합니다.
설명에 포함된 단어는 검색이 어렵고 이슈가 해결 됐을 때 찾기 어렵기 때문입니다.
Jira Service Desk Case Study
Kakao
Jira Service Desk로 프로젝트 생성 요청을 받습니다.
프로젝트 타입, 사용 스킴정보로 프로젝트를 생성합니다.
프로젝트 생성은 자동화 기능을 직접 개발하셨습니다.
내부 사용자들의 다양한 불편 사항을 서비스 데스크로 접수를 받습니다.
평균 응답 시간은 30분이고 SLA 100%를 준수하고 있습니다.
Confluence Page를 연결하여 문제 해결을 빠르게 하고 있습니다.
팀 협업 – 지식 베이스 구축
좋은 생각, 아이디어는 어디에 있을까요? 우리 머릿속에 있습니다. 그 좋은 것들을 정리한 파일은 어디에 있을까요? 내 컴퓨터 또는 파일 서버에 있습니다. 이러한 문제점을 해결하기 위해서 쉐어포인트, 구글닥스 등 문서 협업 도구를 사용하지만 이슈(work)와 연결하기는 쉽지 않습니다. Confluence는 Jira와 강력한 통합을 지원하면서 언제 어디서나 팀과 협업할 수 있습니다.
<그림. Confluence 구조>
Page 생성
모든 사용자는 Page를 만들고 공유할 수 있습니다.
(방법1) 최초의 요청사항을 Confluence로 시작해서 Jira로 시작할 수 있습니다.
(방법2) 최초의 요청사항을 Jira로 시작해서 Confluence에 작성할 수 있습니다.
둘 중 더 좋은 방법은 무엇일까요? 정답은 실무자가 알고 있습니다.
프로세스가 흘러가는데 편하고 어색하지 않는 방법을 추천 드립니다. (감이 안오시면 다 해보는 걸로..)
<그림. 저도 Confluence에서 글을 작성하고 있어요>
Create 버튼으로 Blank Page를 생성하거나
Atlassian에서 제공하는 Template으로 Page를 생성할 수 있어요.
<그림. Atlassian에서 제공하는 Template>
Template도 만들어서 정형화된 문서를 찍어낼 수 있어요.
양식을 고민하지 말고 GO
Jira Issue 연결
Confluence Page에서 Jira 이슈를 연결할 수 있습니다.
반대로 Jira issue에서 Confluence Page를 연결할 수 있습니다.
Issue(work)은 일정, 진행 상태, 이해관계자 알림 등이 목적입니다.
Page는 일이 진행되면 필요한 지식이 쌓이는 곳입니다.
목적에 맞게 일, 지식이 저장되고 사일로 현상을 방지하며 필요할 때 또 꺼내서 보기 쉽습니다.
Jira Issue Chart
Confluence에서는 Jira이슈 검색으로 차트로 표시할 수 있습니다.
Notification
Confluence Notification은 신문 구독과 같습니다.
보고싶은 내용을 개인 설정으로 받을 수 있어요.
쉬운 정보 공유와 협업을 촉진 시키는데 이메일 알람이 큰 역할을 합니다.
그 중 일간 업데이트 구독은 24시간 동안 변경 사항을 간단하게 정리해서 메일로 보내줍니다.
물론 공간, 페이지 권한이 있는 사용자들만 볼 수 있습니다.
Confluence Wrap up
Jira Issue(work)과 산출물을 연결하세요.
Confluence는 최신 정보를 팀과 실시간으로 공유하고 발전 시킵니다.
Jira Comment, Description에는 지식을 남기 마세요. 이슈가 릴리즈 되거나 완료되면 이슈 Comment 찾기 힘들어요.
Confluence ↔ Jira Service Desk 연결로 문제 해결을 최전방에서 해결할 수 있습니다.
내 머릿속, 내 컴퓨터에 지식을 가두지 말고 Confluence에 남기세요.
Bitbucket – 프로페셔널 팀을 위한 Git 솔루션
Jira Issue – Branch 연결
Jira Software와 Bitbucket의 통합으로 Branch 생성을 Jira에서 할 수 있습니다.
Pull Request 승인 절차
Pull Request는 Master Branch에 Merge를 하기위한 절차입니다.
코드 리뷰를 통해서 품질을 향상 시키고 협업을 촉진 시킬 수 있어요
Jira Software는 Branch History와 이슈를 연결하여 보는 최고의 툴입니다.
Jira에서 분기점을 만들어 보세요.
Bitbucket 과 Application연결이 됐을 때 가능합니다. Master Branch에서 Issue key + summray로 생성되네요 생성 후 Jira에서 Tracking 할 수 있습니다.
Jira에서 Git 상태를 확인하는게 중요합니다.
프로덕트 오너, 리더 등 매니저 그룹은 개발자보다 이슈에 더 포커싱이 되어 있습니다.
Jira에서 이슈를 확인하고 코드를 확인하는 절차를 갖을 수 있습니다.
다른 동료 개발자들도 이슈와 코드를 Jira에서 이슈 상태와 함께 공유할 수 있기 때문에 협업 문화를 잘 구축할 수 있습니다.
개발이 끝나고 Pull Request를 생성하고 Reviewer를 지정하여 승인 절차를 받을 수 있습니다.
PR(Pull Request)는 협업 문화, 코드 품질 향상 등 장점이 많습니다.
Wrap up
Jira에서 생성된
Bamboo
Bamboo Server는 프로페셔널 팀 이 지속적 통합, 배포를 위해 선택하는 제품입니다.
아틀라시안 제품과 강력하게 통합하여 자동화 빌드/배포 환경을 구축할 수 있습니다.
자동화의 목적은 빠른 빌드/배포를 자주하는 것 입니다.
개발팀과 운영팀은 더 이상 배포는 두려움의 대상이 아닙니다.
Project
Plans의 모음입니다. 논리적으로 관련된 계획을 쉽게 그룹화하고 식별 할 수 있습니다.
프로젝트 단위로 접근 권한을 설정하여 액세스를 쉽게 제어 할 수 있습니다.
n개의 계획을 포함합니다.
프로젝트는 Reports를 제공합니다.
Plan에 포함 된 권한을 설정할 수 있습니다.
<project settings>
Project details
Project permissions
Plan permissions inheritance
Bamboo Specs repositories
Application links
Bamboo Project Admin을 설정하여 Admin이 Bamboo Plan, Repositories 접근 권한을 설정할 수 있습니다.
Application 개발자에게 한정적인 빌드, 배포 권한을 부여함으로써 Ops팀과 Dev팀의 차이를 줄일 수 있습니다.
Plan
지속통합, 빌드 프로세스를 정의합니다.
기본적으로 하나의 stage로 구성되어 있지만, 여러개의 jobs을 여러 stage로 구성할 수 있습니다.
하나의 Repository를 사용하여 순차적으로 실행되는 하나 이상의 stage를 처리합니다.
기본 Repository를 지정합니다.
빌드가 트리거되는 방법과 프로젝트의 계획과 다른 계획 간의 트리거 종속성을 지정합니다.
빌드 결과에 대한 알림을 지정합니다.
메일 또는 메신저
Plan, jobs 설정 및 보기 권한을 설정할 수 있습니다.
Plan variables를 설정할 수 있습니다.
<Create stage>
stage를 추가할 수 있습니다.
Stage
하나의 Plan에는 각 단계에 대한 stage를 정의할 수 있습니다.
예를들어, 컴파일 단계와 몇가지 테스트 단계, 배포 단계로 구성된 전반적인 Plan 빌드프로세스가 있을 수 있습니다.
기본적으로는 Default job이 있지만 여러 작업을 그룹화 하는데 사용할 수 있습니다.
여러 Agent에서 병렬처리 할 수 있습니다.
다음 Stage를 처리하기 위해서는 모든 작업을 성공적으로 완료해야 합니다.
Job
Plan 내의 단일 빌드 단위입니다.
하나 이상의 작업을 Bamboo Agent로 순차 또는 병렬 처리할 수 있습니다.
작업이 수행되는 순서를 제어합니다.
job에 각 tast가 필요한 값으로 agent를 선택적으로 실행할 수 있습니다.
artifacts를 생성하여 stage가 실행될 때 사용할 수 있습니다.
Deployment projects
배포 프로젝트의 계획을 쉽게 만들 수 있습니다.
<빌드 배포 전략 예시>
배포는 다음을 포함하는 컨테이너 입니다.
Development, Staging, Production과 같은 물리적 환경을 나타냅니다.
배포 중인 실제 소프트웨어 artifacts를 나타내는 릴리즈 – 릴리즈를 구성하는 이슈, 및 커밋 내역을 포함하고 있습니다.
Plan의 통합 빌드, 배포를 workflow로 정의할 수 있습니다.
마무리
요즘 DevOps 의 기술적인 부분인 CI/CD는 많은 관심을 받고 있습니다.
많은 자본과 인력을 가진 회사가 항상 좋은 소프트웨어를 누구보다 더 빠르게 만들 수 있을까요?
요즘 많은 스타트업들이 적은 자본과 인력으로 많은 서비스를 내놓고 있습니다.
우리는 비용 절감을 이야기하지 않습니다. 덩치가 커진 회사는 민첩함을 잃고 부서의 성과에 집중하게 됩니다.
DevOps, CI/CD, Agile 등은 팀에게 민첩함을 부여하고 공통된 성과에 집중하도록 합니다.
고객께서는 Jira Service Desk 또는 Jira Software로 요구사항을 요청할 수 있습니다.
Product Owner또는 Project Leader는 서비스 데스크에 접수된 이슈를 확인합니다.
