기획을 한다는 사람이라면, 열심히 쓴 기획서를 개발자에게 보여줬을때 “이거 다 개발해야하나요?”라는 말을 들어본 적이 있을 것이다. 안 해준다고 탓하기 전에 개발자들이 어떤 개발을 지향하는지 이해하는 것이 필요하다.
오늘 소개할 ‘The nature of Software Development’는 개발자들이 지향하는 관점을 비개발자도 이해할 수 있게 쉽게 설명한 책이다. 매우 매우 쉬워서 동화책 같은 느낌이 든다.
피쳐 단위로 작게, 자주 배포한다
이 한마디가 책의 80%를 커버한다. 제품은 1~2주 걸리는 피쳐 단위로 작게 나누어 개발하고 배포해야한다. 이를 통해 제품팀은 고객에게 더 빨리 가치를 전달할 수 있고, 빨리 피드백을 받을 수 있고, 필요하다면 유연하게 방향을 수정할 수 있다. 이에 대한 원칙은 아래와 같다.
- 나누어진 피쳐는 가치가 높은 순서로 개발되어야한다.
- 매 배포마다 ‘동작하는’ 추가 기능을 볼 수 있어야한다.
짧은 스프린트로 업무를 하는 것은 이제 스타트업에서 낯선 풍경은 아닌 것 같다. 다만 처음 스프린트를 도입하면 긴 계획을 짧게 나누어서 스프린트를 도는게 아니라, 애초에 2주 수준의 기획을 하기도 한다(내가 그랬다)
전체 제품 계획을 세우고 스프린트 단위로 쪼개어 개발할 수 있어야한다. “계획을 길게 세워두는 것은 애자일하지 않다”고 할 수 있는데, 몸은 불편하지만 자주 계획을 변경하면서 진행하면 된다. 이에 대해 책에서는 아이젠하워 장군의 명언을 인용한다.
나는 전쟁을 준비하면서 항상 계획(plan)은 소용이 없다는 것을 발견했지만, 계획수립(planning)은 필수 불가결하다는 것을 알았다.
나누어진 피쳐의 우선순위는 어떻게 판단할까? ICE(Impact, Confidence, Ease)등 알려진 우선순위 판단 방법이 많으니 팀에 맞는 것을 사용하면 될 것 같다. 중요한 것은 제품매니저, 이해관계자, 그리고 개발팀이 모여서 피쳐가 고객에게 어떤 가치를 주는지 깊게 고민해보는 것이다. 그리고 릴리즈한 후에 고객의 의견을 반영하면 된다.
팀에 무리한 요구를 하지 않는다
“이거 16일까지 해주세요” , “이 기능은 꼭 포함해주세요” 라는 말은 하지 않는 것이 좋다. 무리한 추정과 개발에는 부작용이 따르기 쉽다. 오히려 여유가 있다면 아래 사항을 점검하는 것이 지속적으로 잘 할 수 있는 방법이다.
- 충분한 in-cell 테스트
- 리팩토링
일정이 빡빡하면 팀에서 제대로 된 테스트를 하지 않은채 QA팀에 넘기게 되는 경우가 많다. 하지만, 어떤 이슈가 나올지 모르는 테스트 결과를 기다리는 것보다는, 버퍼를 두고 in-cell 테스트를 하는 것이 당장은 느려보여도 지속적으로 팀이 정확한 일감 추정을 할 수 있는 방법이다. (피쳐를 작게 배포하는 것은 역시 이 과정을 수월하게 한다)
저자는 리팩토링을 강조한다. 그런데 스타트업의 본질은 달리는 마차에서 바퀴를 만드는 것이 아닌가? 책에 나오는 방법은 전체 개발을 중단하고 리팩토링을 진행하는 방법이 아닌, 아래와 같은 ‘야영지 규칙’을 따르며 발견했을 때보다 떠날 때 더 나은 곳을 만드는 것에 초점을 맞춘다.
- 피쳐를 추가할 때마다 잘 자리잡을 수 있을 정도로 주변 코드를 깔끔하게 정리하며 시작한다.
- 피쳐가 작동한 이후에는 늘 그렇듯 코드를 정리한다. 자주 할수록 좋다.
- 모든 것을 뒤엎고 새로 시작하지 말고, 매 번 야영지 규칙을 잘 따른다.
변치 않는 최선의 방법은 없다
얼마 전 스포티파이에서 애자일에 실패했다는 글을 재미있게 읽었다. 매트릭스 구조의 비효율을 이기지 못했다는 내용이었다. 그렇다면 애자일이 잘못된 것일까? (참고로 저자는 그 유명한 ‘애자일 선언문’의 공동 작성자다) 애자일이 문제가 아니라, 한가지 완벽한 일하는 방식이 있다고 믿은 경영진의 문제라고 생각한다.
어디에도 완벽한 방법은 없기 때문에, 잘 그리고 즐겁게 일하는 조직을 위해서는, 반드시 일하는 방식을 계속 점검하고 고민하고 소통하는 경영진이 고달파야한다. 가장 좋은 방법이 가장 편한 방법은 아니다.
도니님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
