[개발 일정관리] #3 플래닝 원칙 적용
지난 글
이 글은 ‘개발 일정관리’라는 주제로 연재하는 3번째 글입니다.
플래닝 원칙 적용
지난 글에서 효과적으로 일하기 위한 플래닝 3가지의 원칙을 다음과 같이 제시하였다.
1. 중요하지만 급하지 않은 일을 계획한다.
2. 계획의 최소단위를 일 단위(daily)가 아닌 주 단위(weekly)로 한다.
3. 결과(output)를 수치화한다.
이제 이 3가지의 원칙을 실제 개발 일정관리에 적용해보고자 한다.
중요하지만 급하지 않은 일을 계획한다.
‘중요하지만 급하지 않은 일’은 플래닝의 개념에서 매우 중요하다. 우리가 가장 쉽게 반응하는 일은 그 중요도에 따라 결정되지 않고, 그 일이 급하냐/급하지 않냐에 의해 결정된다. 그래서 급한일을 수행하는 것은 굳이 플래닝의 영역까지 가지 않아도 된다. 그저 To do list를 체크하는 정도면 충분하다. 반면에 중요하지만 급하지 않은 일은 플래닝 없이는 수행하기 매우 어렵다. 그리고 이 중요하지만 급하지 않은 일이 바로 실상 가장 효과적인 일이며, 플래닝의 핵심이다.
정리: 가장 효과적인 일은 중요하지만 급하지 않은 일을 하는 것인데, 이것은 플래닝 없이는 달성하기 매우 어렵다.
개발에서 중요하지만 급하지 않은 일이 무엇인가?
- 리팩토링
- 코드 질 향상
- 테스트 코드 작성
- 문서 작성
- 예외처리
- 자동화
- 테스트
- 코딩 원칙 적용: DRY, KISS & YAGNI
- 최적화
- …
개발자가 A라는 기능을 구현한다고 했을 때, 자명하다고 생각하는 a, b, c 정도의 input이 잘 동작하면 A를 완성했다고 생각한다. 그러나 실 서비스 단계에서 A라는 기능의 동작을 잘 보장하려면, d, e, f 등 생각하기 어려운 input도 고려해야 하며, input이 아예 없거나 input을 받지 못하거나, input을 받다가 중단되거나 하는 등의 여러가지 케이스를 다 고려해야 한다. 그런데 과연 우리는 코딩할 때 충분한 완성도(‘완벽한’이 아니다)로 항상 개발을 하고 있는가? 아니, 이렇게 개발을 할 수 있는 환경에 있는가?
이렇게 충분한 완성도를 가지지 못한 코드가 하나 둘 쌓여가게 되면, 어느 순간은 반드시 그 대가를 치룰 때가 오기 마련이다. 일정의 막바지에 버그가 쌓여 일정이 딜레이 될 수도 있고, 실제 서비스를 돌리다 생긴 문제를 해결하기에 급급해 다른 일정에 지장을 줄 수도 있다. 사용하지 않는 코드가 계속 쌓이고, 중복된 코드가 늘어나고, 유지보수에 투입되는 리소스는 증가하는데 근본적인 문제는 해결이 안 된다.
<실용주의 프로그래머>에서는 이렇게 말한다.
훌륭한 잔디밭은 매일 조금씩 손질해 주어야 한다. 훌륭한 프로그래머도 마찬가지다.
또 깨진 창문 이론을 언급하며 이렇게 강조한다.
깨진 창문을 고치지 않은 채로 내버려 두지 마라. 발견하자마자 고쳐라… 더 이상의 손상을 예방하기 위해 어떤 조치든 취하고 현 상황을 잘 관리하고 있다는 것을 보여줘라.
이처럼 중요하지만 급하지 않은 문제를 개발 일정에 추가하여 일정을 산정하는 것은 매우 중요하다. 그러나 이러한 점은 각 개발자가 속한 개발팀, 나아가 조직의 패러다임과 문화가 이런 부분을 인지하고 지향하지 않는다면, 개인의 노력만으로는 해결되기 어려운 부분이라는 것이다.
계획의 최소단위를 일 단위(daily)가 아닌 주 단위(weekly)로 한다
이 두 번째 원칙은 매우 간단하고 이해하기도 쉽지만 개발자에게는 다른 어떤 것보다 큰 영향을 주는 원칙이다. 비개발자가 개발이라는 행위를 이해하려고 할 때, 그나마 비슷한 것은 아마 ‘화가의 그림 그리기'가 아닐까 한다. “3일 뒤면 완성됩니다.”라고 말하기가 매우 어렵다는 것이다.
개발자는 특정 기능을 대략 2주일이면 개발할 수 있을 것 같다고 짐작하지만, 그것이 11일이 될지, 13일이 될지 예측하는 것은 매우 어렵다. 어떤 변수가 생길지 모르기 때문이다. 또한, 제대로 된 개발 일정이라 함은 단순히 급한 일(기능 구현)만이 아닌, 중요하지만 급하지 않은 일(예외처리, 테스트 코드 작성, 테스트 등)까지 포함해야 하는 것인데, ‘일 단위'의 계획은 이런 부분을 배제하게 되기 쉽기에 결코 추천하지 않는 방식이다.
결과(output)를 수치화한다
이 원칙은 역시 ‘효과적으로 일한다'는 패러다임의 연장선에 있는 원칙이다. ‘효과적’이라 함은, 이전 글에서 언급한 바와 같이 결과를 기준으로 성과를 파악해야 하는 것이다. input은 측정하기 쉽지만, input만으로 개발자를 평가하기 시작하면 개발자는 책임을 회피하기 매우 쉬우며, 오히려 비효율적으로 일하기 쉽다.
“40시간 일을 했으니까 내 책임을 다 했다"라고 말하며 책임을 지지 않기는 얼마나 쉬운가? 개발자가 뛰어난 퍼포먼스를 발휘하여 일정일 일찍 마무리했는데, 그에 대한 성과 측정은 없고 그저 input만 평가한다면, 미리 해놓고도 ‘하고 있다'고 말하기도 한다.
그리고 ‘수치화'해야 한다고 함은, 피터 드러커의
“측정하지 않으면 관리할 수 없고, 관리하지 않으면 개선할 수 없다”
는 원칙에 따름이다.
특정 단위의 모듈 A의 기획-개발-테스트하는데 어느 정도의 싸이클이 걸렸는지를 꾸준히 측정하는 것은 일정관리에서 매우 중요한 요소이다. 이 측정을 바탕으로 한 개발자의 생산성을 점점 더 정확히 파악할 수 있게되며, 이는 정확한 일정 산정의 선순환으로 이어지기 때문이다.
이상 3가지 플래닝 원칙의 적용에 대해 간략하게 적어보았다. 이 3가지 원칙은 몇 번이나 강조한 바 있듯, “효과적으로 일하기"라는 패러다임의 연장선에서 만들어진 원칙들이다.
중요하지만 급하지 않은 일들을 포함하여 계획을 하고 — 그것을 주 단위로 수행하며 — 그 결과를 수치화하는 것이다.
또한 이 3가지 원칙은 각각 독립적이지 않고, 매우 긴밀하게 연결되어 있다. 코드를 다듬고 더 나은 형태로 구현하고자 하려 해도, 일 단위의 빡빡한 계획에서는 일정 맞추기에 급급해 그렇게 시간을 쓰기가 어렵다. 또한 그렇게 한다고 한들, input으로만 평가가 되어 나의 그런 노력이 성과 인정이 되지 않는다면 점점 좋은 코드를 작성하지 않으려 할 것이다. 아무리 좋은 씨앗도, 그 씨앗이 자라는 밭이 좋지 않으면 잘 자랄 수 없다. 마찬가지로 아무리 실력 있는 개발자라도, 개발팀의 문화가 그것을 발휘할 수 없는 곳이라면 퍼포먼스를 발휘하기 어려운 것이다.
다음 글에서는 이제 실제 예시를 바탕으로 이 원칙들을 개발 일정관리에 적용해보도록 하겠다.
