개발 범위 파악이 어려워요
개발 일정 계획을 잘할 수 있는 방법에 대한 고민
<노션에 기록된 회고 포스트잇 내용>이번 스프린트 회고에서 출발한 이야기를 적어봅니다.
개발자 한분이 남긴 회고 내용을 보고 여러 가지 생각들이 떠오르기는 했지만, 일단은 간단하게 코멘트를 남겨두고 정리를 해보기로 했습니다.
<일단은 코멘트 먼저 남김. 급하게 썼더니 문장이 매끄럽지 못하다는;;>여러 가지를 메모하다 보니 범주가 꽤 커져서 몇 가지 내용으로 나눠서 정리를 해봅니다.
문제라고 느끼는 내용을 정의해보자
작업 이전에 업무 범위에 대해서 얼마나 잘 알 수 있을까
나를 얼마나 잘 알고 있나, 내가 얼마나 집중을 할 수 있나
그래서 뭘 해야 하지
먼저 언급을 해둘 것은 이번 문의를 한 주체가 '개발자'분이어서 '개발자' 관점에서 주로 설명을 하고자 합니다. 기획과 디자인 및 QA를 하는 경우에도 동일하게 스토리 포인트 또는 일정을 고려할 때 어려운 점들이 있기 마련이지만, 일부 영역들은 서로의 입장 차이로 느껴질 수 있는 부분도 있으므로 이번 글에서는 가능하면 해당 요소는 제외하고 생각을 정리하고자 합니다.
1. 문제라고 느끼는 내용을 정의해보자
질문자의 회고 내용은 "개발 규모 파악"으로 되어있고, 내용에도 "기획 공유 회의로(에서) 개발 규모를 판단하는데 실패"라고 설명을 하고 있습니다.
먼저 현재 저희 조직의 스프린트 프로세스를 살펴보면 (PM들이 선정한) 스프린트 후보 과제 공유를 공유하는 시간 이후 플래닝까지 1주일가량 시간이 있는데요, 해당 기간 동안에 기획을 보강하고 필요하다면 개발 이슈도 확인을 하는 작업을 하게 됩니다. 즉 플래닝 시점이 되면 대부분의 경우 담당자가 될 분들이 이미 정해지거나, 또는 누가 하더라도 크게 이슈가 되지 않을 내용들이 스프린트 내에 진행될 업무로 선정되는 구조를 가지게 됩니다. (참고로 해당 기간에 평소 하고자 했던 작업을 하거나, 이후 스프린트에서 진행이 확실한 업무를 선행해서 일부 진행하기도 합니다)
다만 실제 플래닝 시점에 리소스 이슈나 특정 업무의 우선순위 조정 등이 발생하게 되면, 상대적으로 잘 인지하지 못했던 업무를 담당하게 되는 인원이 생길 수는 있습니다. 그런 경우 추가로 플래닝 미팅 이후에 스토리 포인트를 산정하는 별도의 스토리가 일부 생기기도 합니다.
이렇게만 보면 프로세스 기준으로는 크게 문제 될 것이 없어 보이는데요, 실패라고 느끼게 된 문제는 어디에서 발생 문제일까요? 결과 현상만 보면 플래닝 미팅 중에 정한 스토리 포인트와 실제 작업 중에 사용한 스토리 포인트가 차이가 난 것일 텐데, 차근차근 생각을 해보도록 합시다.
2. 작업 이전에 업무 범위에 대해서 얼마나 잘 알 수 있을까
서비스의 각 과정에서 자주 얘기가 되는 것들이 있습니다.
A. 기획 및 디자인 요소를 검토하면서 발견되는 내용
정확하지 않은 설명
세부 사항이 비어있는 기획
구현이 가능할지 바로 알기 힘든 요구 사항
B. 개발 중에 발견되는 내용
생각과 달리 작업에 시간이 많이 소요되는 기능
개발 중에 발견된 과거 오류
다른 기능과의 연결성으로 인해 추가 작업 필요
현재 사용 중인 라이브러리에서 지원하지 않는 기능
성능상의 이슈로 대규모 작업이 별도로 필요
C. 개발 후에 발견되는 내용
잘못 이해하고 개발된 내용
개발자 컴퓨터에서는 발견되지 않는 오류
특정 환경에서만 발생하는 현상
각 항목들에 대해서도 정말 다양한 의견이 있는데요, 예를 들면 '세부 사항이 비어있는 기획'에 대해서는 여러 가지 논쟁들도 있습니다. 가능한 자세한 것이 좋은지, 혹은 참여자들이 개발 과정 중에 정비를 하는 것이 좋은지 등에 대한 것이죠. (링크: 향로님 글 - 엔지니어의 세심함 https://jojoldu.tistory.com/667)
기획/디자인/개발/QA 모두 좋은 결과물을 목표로 하지만 '완벽' 또는 '충분'하다고 자신 있게 얘기하는 것은 항상 어렵습니다. 반대로 생각해보면 최초의 고민이었던 '개발자 기준에서 범위 파악을 잘하지 못할 수 있는 부분' 역시 다양하다는 것이고, 특히나 각 개인의 실력과 경험에 따라 그 수준까지도 달라지기 때문에 도깨비방망이 같은 멋진 솔루션을 제시하는 것은 더욱 어렵습니다.
참고로 좋은 결과와 일정 준수 사이의 적절한 조화를 위해, 개발 기간 중에도 조정이 가능한 부분은 긴밀하게 협의하는 것이 합리적이라는 것은 당연한 이야기입니다.
<개발을 해보니 '생각과 달리 작업에 시간이 많이 소요되는 기능'에 대한 협의 예시>이렇게 하고 있음에도 불구하고 실패하는 계획이 나오는 이유는 무엇일까요.
3. 나를 얼마나 잘 알고 있나, 내가 얼마나 집중을 할 수 있나
책 '사용자 스토리'에는 이런 내용이 있습니다.
<사용자 스토리 : '20장 릴리즈 계획'의 '속도 추정하기' 내용 발췌 - 출판사 인사이트>여기서 얘기하고 싶은 것은 "집중력을 잘 발휘하는 나를 기준으로 업무 계획을 세우고 있지 않은가"에 대한 것입니다. 사실은 이렇게 기준을 잡고 계획을 세우는 것이 좋습니다. 그리고 동시에 업무 시간 동안 항상 집중력을 발휘하는 8시간을 사용할 수 없다는 것도 인정을 해야겠죠. 첨언을 하면 같은 기간에 진행하는 일상적인 업무에 대해서도 동일하게 "집중력을 잘 발휘하는" 기준으로 일정을 고려해서 계획을 잡는 것 역시 피해야 할 것입니다. 만약 기준을 동일하게 세운다면 일상적인 업무조차 약간의 추가 일정을 가정하는 것이 필요하다고 생각됩니다.
다시 현재 저희 조직의 얘기를 해보면 "할당 스토리 포인트는 가용 스토리 포인트의 80%를 넘을 수 없다"는 제약을 1차로 두고 있고, 추가적으로 다른 큰 업무가 있는 경우 사용할 가용 스토리 포인트를 더 줄이도록 하고 있습니다. 하지만 그럼에도 불구하고 경험상으로는 본인의 업무 시간의 집중도를 잘 알지 못하는 경우를 자주 보게 됩니다.
위의 예시에 나오는 두 명의 프로그래머가 이상적인 하루 동안의 작업을 수행하는데 2~3일이 걸릴 것으로 판단한 근거에 대한 설명은 없지만, 일반적인 상황들을 몇 가지 생각해 볼 수 있습니다.
이미 운영 중인 서비스에 대한 대응
정기적인 업무 회의 및 보고 시간
코드 리뷰와 같은 협업 업무 시간
일상적으로 일어나는 여러 인터럽트
어떤 사람에게는 이상적인 작업 수행 단위와 실제와의 차이가 크지 않을 수 있겠고, 어떤 사람의 경우에는 1주일에 1~2일 정도만 집중해서 일하는 결과를 만들어 내는 것으로 판단하는 것이 맞는 것이겠죠.
4. 그래서 뭘 해야 하지
먼저 필요한 것은 스스로의 시간 측정에 대한 연습이라고 생각됩니다. Jira 이슈를 기준으로 보면 Task 단위로 Time Estimation을 하고, 작업 단위로 Task Log로 Time Spent를 남겨두는 형태를 생각해 볼 수 있습니다.
이러한 작업을 통해 예측과 결과를 비교할 수 있는 자료가 확보되는 것이 1차적인 효과라고 한다면, 명시적으로 작업 기록을 남기는 행동을 통해 스스로 점검을 해보는 연습을 해볼 수 있는 것이죠.
여기까지 글을 쓰고 나서 어떻게 더 설명을 할까 고민을 하다가 연습을 해보면 좋겠다는 생각이 들었고, 그래서 책상 속에 잠들어 있던 플래닝 포커 카드를 꺼내서 오랜만에 찬찬히 살펴봤습니다.
<책상 속에서 오래 잠자고 있었던 플래닝 포커 카드>이런저런 이유로 실제 플래닝 시간을 대체하지는 못할 상황이어서 맨 처음 질문을 남겨주셨던 분을 포함해서 몇 분에게 플래닝 연습을 위한 미팅 초대를 드렸습니다. 그리고 하나의 작업에 대해 논의를 하면서 약식으로 플래닝 연습을 해봤습니다. (Task 기록도 간략하게만 손으로 쓰면서 간략하게...)
<약식으로 진행해 본 플래닝 연습 with dk, jy1, jy2>조만간 진행할 업무를 기준으로 진행을 했기 때문에 디자인 화면까지 보면서 꽤 구체적으로 스토리 포인트 산정을 해볼 수는 있었는데요, '왜' 그렇게 생각했는지에 대한 얘기를 꺼내는 것을 통해 실제적인 도움을 얻을 수 있는 시간이었습니다. (라는 의미로 참여하신 분들이 얘기를 해주셨습니다^^)
사실 책이나 세미나에서 언급되는 스포리포인트 카드를 실무에 활용을 할 기회가 거의 없었는데요, 카드를 꺼내놓고 곰곰이 생각을 해보니 플래닝 과정이 중요하다는 생각을 다시 한번 하게 되었습니다. 스토리 포인트 산정을 할 때 혼자 하는 것이 아닌 여러 명이 함께 하는 것이 주는 효용성에 대한 것인데요, 많은 일들이 그렇듯이 혼자 생각하는 경우 부족할 수 있는 부분에 대해 보완할 수 있었습니다. 또한 장기적으로 팀원들 간의 장단점을 좀 더 구체적으로 알게 되는 것과 서로에게 도움이 되는 정보를 자연스럽게 전달하는 과정으로도 사용될 수 있는 툴이라는 생각이 들었습니다. (물론 꼭 카드를 이용해야 할 필요는 없겠지만요)
매일 개발에 참여를 하고 있다고 하더라도 일정을 잡는 것은 쉽지 않고, 오차가 항상 있기 마련입니다. 중요한 것은 막연한 시도가 아닌 구체적인 계획과 개인적인 회고를 통한 학습일 것 같습니다. 아는 것뿐만 아니라 시간을 들여서 익히는 것이 필요한 것이겠죠.
이후에 어떤 형식으로 더 보완을 해나갈 것인지는 정해지지 않았지만, 좋은 경험에 대한 기억을 바탕으로 아쉬웠던 부분들이 조금씩이나마 개선이 될 것이라 기대를 해봅니다.
