1. Jira 도입기와 개인 프로젝트
# 이 글에서는 지금까지 2달간 사내 스터디 그룹을 위해 jira를 운영해오면서 있었던 일들을 정리해 올리고자 합니다.
# jira 사용법보다는 일기에 훨씬 가까운 형태가 될 것 같습니다.
# jira는 협업 툴이고 결국에는 그 조직에 대해서 설명하지 않으면 지라를 쓰고 있는 상황을 표현 할 수가 없다고
생각합니다. 이에 따라 지라 사용법이 아니라 내가 속한 organization과 jira를 묶어서 이야기 하고자 합니다.
# 1. 대학원 생활과 jira
제가 jira를 처음 접한 것은 대학원 시절 연구실에서 였습니다
교수님께서 연구에 애자일 메솔로지를 적용 하고 싶어 하셨고
지라를 도입하고 일주일 단위였던 연구 주기를 매일 매일 단위로 바꿨습니다
문제는 템포가 제 연구에는 맞지 않았다는 것입니다.
지나치게 빠른 템포로 인해 매일매일 다음날 보고할 연구 성과가 있어야 했고
매일 매일 생산물이 나오는 개발과 달리 결과물이 나오지 않거나 수행한 시도가
실패 도달했을 경우 충분한 생각을 할 시간 없이 어떻게 보고 할까 만을 매일 매일 생각해야 했습니다
그리고 지나치게 잦은 주기로 소통이 가능해지자 낮이고 밤이고 상관없이 작업물이 공유 된다는 점이 굉장히 큰 스트레스가 되었습니다. 저는 퇴근 후 집에서 쉬고 있는데 다른 학생들이 연구 내용을 올릴 때 이제부터 재택근무 나도 해야 되나 생각이 들었습니다
그래서 당시에는 지라에 대한 의문이 있었습니다
# 2. 취업 후 스터디 운영과 jira
나는 취업 후에 출근 세 번째 날에회사 임원들 앞에서 스터디를 열 테니 비용 지원을 해 줄 수 있느냐란 말을 했습니다.
허가를 받았고 이제 사람만 모으면 되는구나나는 생각에 사람을 모은 적이 있습니다.
회사에서 스터디를 열려고 했던 건 회사 업무의 질이 생각보다 마음에 들지 않았고
직원들을 모아서 직원들 전체의 기술 스택의 수준이 상승하면 회사에 들어오는 일의 종류가 달라질 거라고 생각했기 때문입니다.
마침 그때 직원들 중 누군가는 쿠버네티스를 다루는 일을 하고 싶다 했고 또 누군가는 데이터 엔지니어가 되고 싶다 란 말을 했습니다.
그래서 사람을 모으는 일이 어렵지 않을 것이다라고 생각을 했습니다.
이렇게 사람들을 모은다면 스터디를 공식 활동으로 인정받고 대학원 때 세미나를 운영했던 것처럼 일주일에 한 번 정도 업무 시간 내 스터디 시간을 보장 받을수 있다고 생각했기 때문입니다
예상치못한 일이 발생했습니다.
직원들은 모두 퇴근 이후에 각자의 삶이 있었고, 그 시간을 공부에 할애하고 싶지 않다는 의견을 조심스럽게 내비쳤습니다.
그렇게 저를 제외한 지원 4명 중 세 명이 참석하지 않게 되었습니다.
남은 한 명이 같이 한번 해보자고 말을 했습니다.
그렇게 두 명이서 스터디를 시작하나 했습니다.
근데 또 예상치 못한 문제가 발생했습니다.
1달 반 가량을 하염없이 기다리기만 한 결과,
같이 한번 해보자고 말했던 직원도 참여 할 수 없는 상황이 됐습니다.
지금 운영하고 있는 지라는 사실 이 친구 와 협업을 하기 위해 도입한 협업툴입니다.
그래서 혼자 남은 지금 솔직히 말하면 방향성을 조금 잃은 것도 사실입니다.
# 3. 스터디 참여자를 기다리며 만든 jira와 채워넣은 내용, 결국은 혼자가 된 나.
그렇게 지라를 도입하게 되었습니다
같이 하기로 한 친구가 1달정도 뒤에 온다고 하니까 협업하기 좋게 협업툴을 미리 셋팅해 두자. 라는 생각으로 jira도 설치하고, slack도 연동하기 시작했습니다.
처음에는 구글링을 통해서 지라를 쓰는 사람들이 보드를 만들고 이 주 단위로 스플린트를 운영한다는 사실을 알게 되었습니다.
이 처럼 스플린트를 도입하려 했으나 업무가 끝난 뒤에 운영하는 스터디 기 때문에 야근 등을 한다면 2주라는 기간을 늘 지킬 수는 없구나 라는 걸 깨닫게 되었고
(실제로 한번 야근으로 기한내 수행량을 못맞춰서 미룬 적이 있습니다.)
일단 에픽을 2주 단위로 끊어서 스플린트처럼 운영하다가 필요한 경우 조금씩 조금씩 기한은 늘리는 방향으로 운영을 했습니다
제일 먼저 했던 것은 뭘 해야 하는가를 아는 것이었습니다. 목표는 DevOps가 되는 것으로 잡았지만 무슨 공부를 어떻게 시작해야 될지 알지 못했고 처음에 생각한 것은 채용공고를 닥치는 대로 읽는 것이었습니다.
여러 채용 공고를 읽으면서 서로 겹치는 기술스택을 찾는 것을 시작했습니다.
이 중에서 뭘 해야 하는가에 대해서 브레인스토밍 하는 것처럼 스킵하지 않고 필요하다 생각하는 것을 모두 적었습니다.
그리고 이들의 우선 순위를 메겼습니다.
양이 상당히 많았어요.
이걸 전부 구글링으로 알 수는 없다.
그래서 유료 강의를 하나 듣자.
결제를 하고 보니까 강의를 다 듣는데 총 270 시간이 걸리더라구요.
=> 틀어 놓는 시간만 그런거고, 못알아들어서 다시 듣거나, 따라하려고 멈추는 것까지 포함하면,
적어도 400시간 이상 걸립니다.
여기에 강의로 부족한 내용을 책으로 메우려니까 10권 이상은 읽어야 겠다는 계산이 나왔습니다.
이걸 다 듣고 수행 하는 건, agile 하지 못하다 는 생각에 최소 필요 단위에 따라 쪼개서 나눠 수행하기로 했습니다.
그래서 이걸 공부하면 만들 수 있게 될 것을 리스트로 정리해 만들었습니다
정리하면 인프라 생성 쿠버네티스로 미들웨어 배포 젠킨스로 코드 배포 이 과정 안에서 여러가지 서비스(web, andriod, ai, data engineering)
=> 이에 대해서는 agile methology와 devops라는 내용을 따로 쓸 생각입니다.
그러면 첫 프로젝트는 인프라 생성을 하고
두 번째 프로젝트는 쿠버네티스를 그 위에 올리고
세 번째 프로젝트는 거기에 젠킨스로 코드를 배포하는 것
이것을 주요 순서로 정했습니다
이에 따라 지금 첫 번째 프로젝트인
테라폼으로 인프라를 생성하고 매주 업무인 모니터링 시스템을 띄우는 것을 진행 중입니다
# 4. 보드의 구성이 이렇게 된 이유.
위에 이유들로 인해 현재 지라 보드는 1)브레인스토밍 2)퇴근 3)진행 중 4)완료로 나누게 되었습니다
그리고 어플리케이션 이메일등이 알람을 받지 말자 규칙을 만들었습니다
현재 혼자 진행하고 있어서 방향성을 좀 잃었는데 의외의 이점이 생겼습니다.
위에 만들어 놓은 보드들이 지라의 보고서를 봤을 때 조직의 특성을 보여줬기 때문입니다.
누적 플로우 다이어그램을 보면 전체 중 제일 넓은 부분이 브레인 스토밍이며 완료 부분의 넓이가 상당히 작음을 알 수 있습니다
이는 조직이 꿈은 크나 현실은 미흡함을 나타낸다고 볼 수 있습니다
다행히도 완료 부분이 계단식으로 늘어나고 있는 것을 볼 때 그 꿈이 조금씩 매워지고 있구나 라는 점을 긍정적으로 볼 수 있습니다.
파란색 부분은 그 주에 얼마나 열심히 했는가를 나타내며 앞부분은 적고 뒷부분은 뾰족한 모양인 것은 평일엔 일을 하느라 시간이 없고 주말에 가서야 하루 종일 공부를 했기 때문입니다
현재 지라를 도입한지 두 달이 지났습니다
완료 와 퇴근 부분에 넓이를 비교해 봤을 때 지금 목표로 하고 있는 양은 지금까지 지나간 시간만큼 지나면 끝나겠구나 하고 추정이 될 수 있습니다
또한 현재 브레인스토밍에 적은 내용들은 칸의 넓이로 비교해 봤을 때 현재의 5배 정도의 시간 즉 10개월 뒤면 완료 될 수 있음을 알 수 있습니다
그리고 이건 차트와는 상관 없지만 현재 속도를 봤을 때 지금까지 짜놓은 목표인 테라폼에서 젠킨스까지는 6개월 정도 시간이 걸릴 것으로 추측하고 있습니다
(테라폼, 쿠버네티스, 젠킨스 각각 2개월씩)
지금 첫 번째 프로젝트로 만들고 있는 테라폼 코드를 깃허브에 올려 놨습니다 그리고 이에 따라 깃허브를 연동 하였으나 현재 확인할 수 있는 건 커밋 내역과 브랜치와 이슈를 연결하는 것으로 배포, 빌드, 오토메이션, 릴리즈를 다루기 전까지는 큰 의미는 없을 거 같습니다.
첫 번째 프로젝트가 현재 99.99% 완료 되었기 때문에 현황은 마무리하겠습니다.
프로젝트와 같이 jira도 계속 발전 시킬 수 있도록 노력할 것입니다.
+ 추가 : jira 운영 지침
1) 2주간 진행할 목표를 만들어 epic으로 둔다.
2) 해야 할 일을 issue로 만든다.
3) 완료 한 것을 짤막하게 댓글로 남긴다.
4) 인상 깊었던 부분, 대화하고 싶었던 것들을 길게 issue의 본문에 채워 넣는다.
5) 공유할만큼 중요하지 않거나, 너무 많거나, 공부한 것, 필기한 것들은 notion에 적고 그 페이지를 jira에 연결한다.