일 잘하는 개발자 되기 (feat.카이젠저니)

2024-05-03

일 잘하는 개발자가 되려면 어떻게 해야 할까?

카이젠 저니라는 책을 읽고 나만의 정리를 해본다.

redirect

https://product.kyobobook.co.kr/detail/S000001916949

태스크를 도출해 가시화 하기

개발을 하다 처리할 문제가 생겨 태스크를 만들어야 한다. 이 때 고려해야 할 사항은 무엇일까?

  • 태스크의 양은 얼마나 되는가?
  • 각 태스크의 목표는 무엇인가?
  • 각 태스크의 목표를 달성하는 데 있어 주의해야 할 점은 무엇인가?
  • 현재 상황은 어떠한가?

태스크에 들어가야 할 내용

어떻게 되면 이 태스크가 끝나는 것일까? 어떻게 되면 이 일을 완수했다고 볼 수 있을까?

태크스 안에는 다음의 내용이 들어가 있으면 좋다.

  • 누가 의뢰한 것인가?
  • 다음에는 누구에게 전달하는가?
  • 기한은 언제까지인가?
  • 작업 시간이 얼마나 소요되는가?
  • 어떤 상태가 되면 이 태스크가 완료되는가?

큰 태스크를 그대로 취급하지 않는다.

가끔은 태스크가 1~2달 혹은 그 이상일 수도 있다. 같이 일하는 동료나 관리자에게 “일”이 얼마나 진행됐는지 어떻게 공유할 수 있을까?

  • 하루 이상 걸리는 태스크는 분할하는게 좋다.
  • 이와 달리 태스크이 크기를 3일로 추정한 경우에는 하루가 지났다고 해서 1/3 완료했다라고 말할 수 없으므로 진척도를 알 기 어렵다.
  • 분할하게 되면 일이 진행되고 있다는 느낌을 얻을 수 있다.

Jira 같은 경우 하위 태스크로 분할을 하면 좋다.

태스크 제목

  • 태스크를 기록할 때는 ‘OO 처리’ 보다 ‘OO처리를 프로그래밍한다’와 같이 명사+동사의 형태로 쓰는 것이 훨씬 알아보기 쉽다. 명사로 끝나면 무엇을 해야 하는지 알 수 없는 경우가 있기 때문이다.

파이브 핑거

파이브 핑거는 개인이 ‘실제로 어떻게 생각하고 있는지’를 다섯 손가락으로 표현하는 방법이다. 스프린트나 업무의 현재 상황을 어떻게 생각하는지 표시한다.

5개: 정말 잘되고 있다.

4개: 잘되고 있는 것 같다

3개: 잘되는 것도 그렇지 않는 것도 아니다

2개: 약간 불안하다

1개: 절망적이다

스크럼 시간에 팀원들을 모아놓고 파이브 핑거를 해보자.

Q. 이번 스프린트가 잘 진행되고 있나요?

플래닝 포커

시간이나 노력, 자금이 충분하다면 프로젝트의 최후까지 변경이 없는 정확한 계획을 세울 수 있을까? 프로젝트가 진행되면서 정보량이 늘어난다. 제품이 준비해야 할 높은 가치의 요구나 개발팀의 과거 경험을 얼마나 활용할 수 있는지 등 다양한 정보를 발견하게 된다.

프로젝트가 진행되면서 당초 계획의 윤곽과 달라지는 경우, 실행 불가능한 계획에 집착하는 것보다 새로운 학습에서 흭득한 지식을 계획에 적용해 가치 제공에 주력하자.

사용자 스토리의 규모를 나타내는 단위를 스토리 포인트라 부르며 규모를 추정할 때는 절대적인 공수나 시간이 아닌 상대적인 값을 사용한다. 절대적인 공수나 시간을 적용하는 것은 어려울 뿐 아니라 시간도 많이 걸린다. 하지만 크고 작음의 상대적인 관계나 2배 또는 몇 배 정도의 감각적인 파악은 대부분의 사람이 잘하는 영역이다.

우리 회사 같은 경우는 1 스토리포인트 = 1일 공수다.

플래닝 포커는 팀 전원한테 숫자가 쓰여진 카드를 나눠주고, 스토리포인트를 정하는 방법이다. 이 방법의 장점으로는 신규 입사자나, 경험이 적은 팀원이 걱정하는 점을 공유할 수 있으며, 잘하는 멤버의 경험담이나 우려되는 점을학습할 수 있다. 견해의 차이가 있는 것이 오히려 긍정적이다.

선택한 카드의 숫자가 서로 다르다면 설명을 해야 한다. 예를 들어, A라는 작업의 스토리 포인트가 각자 ‘2, 2, 2, 5’로 나온다면, 이 일을 할 때 걱정하는 사항이나 과거의 실패담을 공유할 수도 있다. 이때 팀 내의 작업 난이도나 스킬의 차이가 줄어들게 된다.

Sanity Test

제품 책임자는 각 제품 백로그 아이템마다 인수 조건을 정의해야 한다.

여기서 인수 조건이란, ‘해당 조건을 만족시키면 요구사항을 확실하게 구현했다고 판단할 수 있는 리스트’를 의미 한다.

계획한 기능 사양은 물론, 비기능 사양도 만족시켰는지를 인수 조건에 포함시킨다.

제품 책임자로서 납득하고 인수할 수 있는지의 여부와 그 만족 조건은 제품 백로그 아이템별로 존재해야 한다.