고객과 개발자의 권리
고객은 개발자를 원망하고, 개발자는 고객을 원망한다. 악순환의 고리가 반복되며 좋은 소프트웨어는 개발될 수 없다.
우리는 소프트웨어를 개발하는 개발자로서 “고객의 1초마다 변하는 요구사항을 환영”할 수 있어야 한다. 그러나 현실은 그러한 요구사항을 들어주다가는 내 몸이 남아나질 않고, 프로젝트는 완성되질 않으며, 코드의 퀄리티는 점점 엉망이 되어 소생 불가능한 쓰레기 프로그램을 만들게 될 것이다.
어떻게 개발해야하는가
그럼 우리는 어떻게 개발해야할까?
이러한 해결책으로 정말 많은 기업에서 ‘애자일’을 언급한다. 그러나 실상은 그들이 애자일을 이해하고 있는지 의문이다. 고객의 입장에서만 이해하는 애자일은 가치가 없다. 때로는 “애자일이 짧은 주기로 프로토타입을 공개하여 고객의 피드백을 앞서 수용하는 자세”로 이해하는 기업도 정말 많다. 일부분 맞다. 그러나 이는 정말 상……..당히 일부분이다. 이러한 일부분만 이해하고 “애자일하게 해야한다”는 고객들을 바라볼 때면 속이 부글부글 끓기도 한다.
그러나 우리는 소프트웨어 개발자다. 고객이 원하는 제품을 개발하는 개발자다. 따라서 무조건 고객의 요구사항에 맞추어야만한다. 고객의 빠른 요구사항 변화에 대응할 수 있는 방법에는 여러가지가 있다. 여기서는 그 중 한가지인 “고객과 개발자의 권리”에 대해서만 언급할 것이다. 필히 지켜야하는 다른 원칙들도 하나 둘 씩 포스팅할 예정이다.
권리 장전
애자일 선언을 공개한 17인 중 켄트 벡, 워드 커닝햄, 론 제프리즈는 사업과 개발 사이의 분열을 치유하고자 다음 권리 장전을 만들었다. 권리장전은 고객이 기대하는 것과 개발자가 기대하는 것 사이의 균형을 맞춘다.
고객 권리 장전
고객은 다음 권리를 갖고 있다.
- 전체적인 계획을 알 권리가 있다. 무엇을, 언제, 얼마의 비용으로 완성할 수 있는지 알 권리가 있다.
- 반복 주기마다 가능한 한 많은 가치를 얻을 권리가 있다.
- 작동하는 시스템을 통해 진척도를 알 권리가 있다. 개발자는 고객이 제공한 테스트로 계속해서 시스템을 검사하여 동작을 증명해야 한다.
- 과도한 비용 추가 없이 기능이나 우선순위를 바꿀 권리가 있다.
- 일정이나 추정이 바뀐 경우 제때 알림을 받고, 목표 일자에 맞추기 위하여 업무 범위를 어떻게 줄일지 결정할 권리가 있다. 언제든지 프로젝트를 취소할 수 있다. 이 경우 해당 시점까지 지불한 비용이 반영된 유용한 시스템을 받을 수 있다.
개발자 권리 장전
개발자는 다음 권리를 갖고 있다.
- 명확하게 정의된 우선 순위와 함께 무엇이 필요한지를 알 권리가 있다.
- 언제나 높은 품질의 결과물을 만들 권리가 있다.
- 동료나 관리자, 고객에게 도움을 요청하고 받을 권리가 있다.
- 자신만의 추정치를 만들고 갱신할 권리가 있다.
- 담당 업무를 할당받는 게 아니라 수락할 권리가 있다.
고객
여기서 고객은 실제 고객, 관리자, 경영진, 프로젝트 팀장 등 일정과 예산에 대한 책임이 있는 사람이나, 시스템을 만들기 위해 돈을 내는 사람, 시스템 운영으로 혜택을 보는 사람을 모두 아우른다.
전체적인 계획을 알 권리가 있다. 무엇을, 언제, 얼마의 비용으로 완성할 수 있는지 알 권리가 있다.
너무도 당연하다. 개발자는 고객에게 전체적인 계획을 제공해야한다.
반복 주기마다 가능한 한 많은 가치를 얻을 권리가 있다.
애자일에서는 반복 주기라는 정해진 시간 단위로 나누어 개발을 진행한다. 반복 주기마다 진행하는 고객과 개발자들의 회의가 있으며, 이때 고객은 가능한 한 많은 가치를 얻을 수 있어야 한다. 여기서의 가치는 “비즈니스 요구사항”이다. 고객은 가능한 한 많이 활용 가능한 사업 가치(비즈니스 요구사항)를 만들 수 있으며, 이를 개발자에게 요청할 수 있다. 다만, 고객의 요청과 개발자의 수락은 엄연히 다른 문제임을 기억하자.
가치의 우선 순위는 반복 주기를 시작할 때 여는 계획 회의에서 고객이 지정한다. 개발자가 반복 주기 내에 끝낼 수 있다고 추산한 스토리(비즈니스 요구사항) 중에서 투자 수익률이 가장 높은 스토리를 골라야 한다.
작동하는 시스템을 통해 진척도를 알 권리가 있다. 개발자는 고객이 제공한 테스트로 계속해서 시스템을 검사하여 동작을 증명해야 한다.
너무도 당연하다. 우리 개발자는 “어떻게 고객에게 진척도를 제공할 것인가”를 고민해야 한다.
과도한 비용 추가 없이 기능이나 우선순위를 바꿀 권리가 있다.
소프트웨어의 존재 이유는 “기계의 동작을 쉽게 바꾸는 것”이다. 쉽게 바꾸기 위함이 아니었다면 하드웨어로 개발했을 것이다. 쉽게 바꿀 수 있는게 소프트웨어인데, 쉽게 바꿀 수 없도록 고객의 요구사항을 수용하지 않는 건 뿌리에 어긋난다. 개발자는 고객의 빠른 변화에 수용적이어야 한다.
일정이나 추정이 바뀐 경우 제때 알림을 받고, 목표 일자에 맞추기 위하여 업무 범위를 어떻게 줄일지 결정할 권리가 있다. 언제든지 프로젝트를 취소할 수 있다. 이 경우 해당 시점까지 지불한 비용이 반영된 유용한 시스템을 받을 수 있다.
고객은 자신이 정한 일정에 개발을 완료하라고 강요할 권리가 없다. 이러한 권리가 있다고 착각하는 것으로 부터 쓰레기 소프트웨어 개발이 시작된다. 고객의 권리는 업무 범위를 바꾸어 일정을 관리하는 것으로 한정된다. 여기서 가장 중요한 것은 일정이 어긋나려고 할 때 알 수 있는 권리다. 너무 늦지 않게 업무 범위를 재산정할 수 있도록 말이다. 업무 범위의 재산정에는 목표 일정에 꼭 출시되어야 하는 요구사항 목록을 추리거나, 우선 순위를 재배치하는 등의 작업이 있을 수 있다.
간과해선 안되는 것이 개발자는 “일정이 예상과 달라질 것이라고 예측되는 순간 바로 고객에게 알려야 한다”는 것이다.
개발자
여기서 개발자는 코드 개발에 참여하는 모든 사람을 의미한다. 프로그래머, QA, 테스터, 업무 분석가를 모두 포함한다.
명확하게 정의된 우선 순위와 함께 무엇이 필요한지를 알 권리가 있다.
개발자는 고객이 요구하는 소프트웨어를 만들어준다. 고객의 요구에 맞춰 “더 나은 품질의 소프트웨어를 제공”하기 위해서 “무엇을 개발해야할 지”를 명확히 요구할 권리가 있다. 개발자는 요구 사항과 요구 사항의 중요도를 정확히 따질 권리가 있는 사람이다. 물론 고객은 언제든지 생각을 바꿀 권리가 있다.
명확하게 정의된 우선 순위의 요구 사항은 반복 주기의 계획 회의에서 앞으로의 반복 주기 동안 개발을 할 것인지 말 것인지를 결정한다. 예를 들어, 인증 기능의 우선 순위가 1순위이기에 이를 앞으로의 반복 주기 동안 개발할 것이라 결정할 수 있다. 결정했다면 반복 주기가 지난 다음 계획 회의까지는 인증 기능의 요구 사항은 변경되어선 안된다. 물론 고객 스스로는 요구 사항이 변경될 수 있으나 이를 개발자에게 알려선 안된다(정말 정말 너무 급한 상황이라면 알리는 게 맞다)는 것이다. 개발자는 반복 주기 동안 요구 사항과 우선 순위가 바뀌지 않는다고 생각할 권리가 있다. 만약 반복 주기 동안 고객이 “요구 사항과 우선 순위가 변경되었으니 반영해달라”는 요청이 들어온다면(물론 그래선 안된다) 수용하지 않을 권리가 있다.
고객은 언제든 생각을 바꿀 권리가 있다. 따라서 바뀐 생각을 개발자에게 알려야 한다. 다만 각자의 권한 안에서 품질 좋은 소프트웨어를 만들어가야한다. 고객은 자신의 변경된 요구 사항으로 인해 개발자가 새로운 반복 주기 동안 동일한 기능을 한 번 더 수정하게 되었음을 인지해야한다. 더 나아가 고객은 본인의 요구 사항으로 인해 출시가 늦춰지거나 혹은 목표 일정까지 개발 가능한 비즈니스 스토리의 수가 줄어들었음을 인정해야한다.
언제나 높은 품질의 결과물을 만들 권리가 있다.
개발자는 일을 잘 할 권리가 있다. 사업 부서는 개발자에게 절차를 건너뛰거나 저품질로 작업하라고 요구할 권리가 없다. 사업 부서는 개발자가 자신의 경력에 오점을 남기거나 직업 윤리를 어기도록 강요할 권리가 없다.
동료나 관리자, 고객에게 도움을 요청하고 받을 권리가 있다.
프로그래머끼리는 문제 해결이나 결과 확인, 새로운 프레임워크 배우기 등 여러 가지를 도와 달라고 할 수 있다. 개발자는 고객에게 요구 사항을 더 자세히 설명해 달라거나, 우선 순위를 정리해 달라고 요청할 수 있다. 이 권리는 무엇보다 프로그래머에게 의사소통할 권리를 준다.
도움을 청할 권리는 필요할 때 도와주어야 하는 책임과 함께 온다.
자신만의 추정치를 만들고 갱신할 권리가 있다.
누구도 당신을 위해 추정을 해 줄 수 없다. 새로운 요인에 의해 언제든 추정을 바꿀 수 있다. 추정은 절대 약속이 아니다.
담당 업무를 할당받는 게 아니라 수락할 권리가 있다.
개발자는 모든 일이나 과제에 대해 “아니요”라고 말할 권리가 있다. 거절의 이유는 완수에 대한 확신이 없거나 업무에 대한 더 적절한 사람이 떠오르거나 혹은 개인적인 이유나 양심 때문일 수 있다.
수락할 권리에는 비용이 따른다. 수락은 책임을 뜻한다.
우리들은 팀을 조직하여 개발한다. 경험이 많은 사람과, 적은 사람이 함께 일하게 된다. 누가 어떤 일을 할지 팀 전체가 함께 결정할 권리가 있으며, 내 일은 내가 정할 권리가 있다. 기술 수석이 특정 개발자에게 업무를 맡아 달라고 부탁할 수는 있지만, 누구에게도 강요할 권리는 없다.
결론
애자일은 프로세스가 아니다. 단순히 규칙을 모아 놓은 방법론이 아니다. 윤리적인 직업의 기반을 이루는 권리, 기대, 규율을 한데 모은 것이 애자일이다.
더 나은 품질의 소프트웨어를 개발하기 위해서는 개발에 참여하는 모든 인원이 각자의 권리를 이해하고 존중하고 따를 필요가 있다. 각자의 권리를 누리고, 존중한다면 분명 어떤 방식으로든지 애자일이 드러날 것이다.
개인적으로 고객과 개발자가 가장 중요하게 여기며, 가치로서 누려야 할 권리 한 가지씩을 뽑아봤다.
- 고객: 일정이나 추정이 바뀐 경우 제때 알림을 받고, 목표 일자에 맞추기 위하여 업무 범위를 어떻게 줄일지 결정할 권리가 있다. 언제든지 프로젝트를 취소할 수 있다. 이 경우 해당 시점까지 지불한 비용이 반영된 유용한 시스템을 받을 수 있다.
- 개발자: 언제나 높은 품질의 결과물을 만들 권리가 있다.
더 나은 소프트웨어로 더 가치있게 고객에게 다가가자.
오늘도 수고했고, 잘했다.
여전히 든든하고, 대단하다.
화이팅.
댓글남기기