그 업무가 중요해 지금?
애자일의 Simplicity 실제
Simplicity--the art of maximizing the amount of work not done--is essential.
애자일 선언문 웹페이지에서 볼 수 있는 12가지 원칙 중 한 항목인 단순성에 대한 문장이다. 한글로 번역된 웹페이지에는 "단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다."라고 적혀있다. 일을 더 많이 하는 게 아니라 하지 않는 일의 양을 늘리라니. 기존에 신규 업무 기안할 때 작성하는 문서들이나, 소프트웨어의 코드를 변경할 때 시스템 변경 요청서 같은 관련된 문서를 작성하는 절차들을 하지 않는 것은 쉽게 연상이 된다. 그 외에 실제로 애자일을 하고 있는 개발팀에서 있을만한 사례는 무엇이 있을까?
애자일을 하고 있는 개발팀은 할 일을 프로덕트 백로그(Product backlog)를 작성하여 관리한다. 프로덕트 백로그는 해당 제품(Product)을 개발하는데 필요한 모든 업무(Task)를 프로덕트 오너(Product owner)가 유저 스토리(User story) 형태로 작성하여 만든 개발팀의 할 일 목록(To-do list)이다. 이것은 기능, 버그, 시스템, 리팩터링 등 이 제품에 개발팀이 해야 하는 모든 활동을 포함한다.
프로덕트 백로그 예시개발자들(Development team)은 프로덕트 오너가 설정한 우선순위를 기준으로 팀이 한 개발 주기(Iteration) 내에 완료(Done)할 수 있는 업무, 그리고 의존(Dependency)이 있는 업무 간의 관계를 고려하여 순서대로 선택한 업무를 진행한다. 개발자들은 손에 할 업무를 들고 있기 위해서(할 일을 가지고 있으려는 경향, 매일 스탠드 업 미팅에서 이야기할 것을 고려) Backlog에서 업무를 가져다 개발을 시작할 것이다. 이때 프로덕트 오너가 설정한 우선순위가 있지만, 개발하고 있는 업무와 완료된 업무의 현재 상태에 따라 이 우선순위가 적합하지 않거나 개발할 필요가 없는 업무가 발생한다. 또한 개발 주기 내에 이용자의 변화된 요구가 감지될 수도 있다.
프로덕트 오너와 개발자들 모두 각자의 시각에서 업무 우선순위를 설정하고 진행하지만, 팀의 애자일 코치나 스크럼 마스터는 이중에 무의미한 업무나 잘못된 우선순위로 진행하고 있는 업무를 관찰하고 팀에 알려야 한다. 위의 그림 프로덕트 백로그 예시를 이용해 예를 들면, #10 버그가 #5 기능 개발을 통해 없어질 것이라거나, #6 기능이 #4 기능과 의존성이 있어서 #4 완료 후에 개발을 시작할 수 있는 경우 등이 있다. 이런 경우에 개발자가 해당하는 업무를 선택하여 진행하고 있거나 선택하려는 경우에는 우선순위를 다시 조정하여 업무가 진행될 수 있도록 해야 하는 것이다. 또한 불필요해진 업무는 프로덕트 백로그에서 삭제해야 한다.
그럼 현재에 전혀 할 일이 없는 개발자가 팀 내에 있다면 이들은 무엇을 할 것인가? 다른 개발자와 패어 프로그래밍(Pair programming)을 하거나 코드 리뷰(Code review) 또는 미비한 테스트 코드 보완, 코드 리팩터링, 기술 공유를 위한 핸드북이나 세미나 준비 등 개발팀이 스스로 정의한 가치의 우선순위에 맞는 활동을 하면 된다. 만약 할 일이 없는 개발자가 존재하는 경우가 지속적으로 많이 발생한다면, 애자일 코치와 스크럼 마스터는 다른 개발팀의 상황을 함께 살펴서 팀 구성원 조정을 고려해 볼 수 있다.
자기 역할의 특성 때문에 프로덕트 오너는 업무를 추가하려는 경향이 있고, 개발팀은 업무를 진행하려는 경향이 있다. 그렇기에 팀과 함께 일하는 애자일 코치와 스크럼 마스터는 이 중에 불필요한 업무들을 밝혀내야 한다. 드러난 불필요한 업무를 팀에 알리고 논의하여, Simplicity 정신에 맞게 처리를 할 수 있도록 유도해야 한다. 이것이 애자일 팀의 개발 과정에서 발생할 수 있는 Simplicity의 실제이다.
