Clean Agile : Back to Basics
Robert C. Martin의 저서 Clean Agile : Back to Basics 을 읽고 정리한 글입니다.
프로덕트 매니저, 개발자라면 한번쯤은 들어보았을 단어이다.
그렇지만 애자일이 무엇인지 정확하게 답변할 수 있는 사람은 생각보다 많지 않다.
또 이미 알고있다고 하더라도 애자일을 실제 개발에 적용하는 데에 어려움을 겪는 사람들도 많을 것이다.
그러한 사람들에게 애자일 선언문 서명자들 중 한 명인, Robert C.Martin의 저서 Clean Agile : Back to Basics을 추천한다.
🍦 soft + ware : 바꾸기 쉬운
소프트웨어는 바꾸기 쉬운(soft) + 제품(ware)이라는 뜻의 합성어이다.
우리는 이러한 소프트웨어의 특성을 훼손하지 말아야 하며, 언제 발생할지 모르는 변경사항에 항상 대비하고 있어야 한다.
책에서는 이렇게 말한다.
“만약 바뀌는 요구사항 때문에 아키텍처가 망가진다면, 그건 아키텍처가 엉망인 잘못이다.”
💦 Waterfall : 폭포수 모델
‘폭포수 개발’은 1970년에 Winston Royce가 쓴 대규모 소프트웨어를 관리하는 방법에 대한 그의 아이디어를 설명하는 논문의 한 그림으로부터 시작되었다.
그러나 사실은 로이스가 위 그림을 처음으로 그려낸 것도 아니고, 심지어는 더 좋은 방법을 제시하기 위해 비교 대상으로 내세운 그림이었다고 한다(Robert C.Martin에 따르면, 논문을 대충 읽거나 그림책처럼 대하는 사람들에 의해 폭포수 개발이 생겨났다고 한다).
이러한 폭포수 모델은 과학적 관리법의 이론적인 후예로, 철저한 분석과 상세한 계획을 세우고 실행하여 완성하는, 단순하지만 명확한 방법이다.
주목해야 할 것은, 폭포수 모델은 위에서 얘기한 소프트웨어의 ‘바꾸기 쉬운’ 특성을 훼손시킨다는 점이다.
왜 폭포수 모델은 소프트웨어의 ‘바꾸기 쉬운’ 특성을 훼손시킬까?
그 이유는 사실 그림에 전부 나와있다고 해도 과언이 아니다.
폭포수 모델은 개발 프로세스를 일련의 선형적인 단계로 나누고 엄격하게 구분한다.
폭포수 모델을 따르는 개발자는 반드시 순차적으로 단계를 수행해야 하며, 이전 단계가 완료되어야만 다음 단계로 진행할 수 있다.
따라서 개발 도중에 요구사항이나 기능 등의 변경이 발생하면, 지금까지 했던 작업들을 모두 리셋하고 다시 처음으로 돌아가 작업을 시작해야 하는 상황에 빠지게 된다.
즉, 폭포수 모델은 요구사항이나 기능이 유동적이고 변동 사항이 많을수록, 소프트웨어의 변경이 더욱 어려워지고 개발 프로세스가 지연된다고 할 수 있다.
🅰️ Agile : 애자일
그렇다면 어떻게 해야 소프트웨어의 ‘바꾸기 쉬운’ 특성을 해치지 않을 수 있을까?
이를 위해 애자일에서는 아래와 같은 방법을 제시한다.
- 마감기한을 고려해 프로젝트를 일정한 크기( -> 반복주기 )로 더 작게 나눈다.
- 반복 주기에 걸쳐 요구 사항 분석, 아키텍처 수립, 설계, 구현 활동을 끊임없이 수행한다.
이렇게만 보면 ‘애자일이 단순히 짧은 폭포수 모델을 무한히 반복하는 방법이구나’라고 생각하는 사람이 분명 있겠지만, 이 책의 저자인 Uncle Bob은 그렇지 않다고 주장한다.
애자일은 폭포수 모델과는 달리, 고객과의 소통과 지속적인 개선을 중요하게 생각한다.
따라서 애자일은 언제든 필요에 따라서 현재 작업 중인 단계가 완료되지 않더라도 이전 단계로 돌아가서 작업을 진행할 수도 있어야 한다.
❕ 애자일의 4가지 핵심 가치
- 공정과 도구보다 개인과 상호작용
전체 팀, 메타포, 공동 소유, 짝 프로그래밍, 지속 가능한 속도
- 포괄적인 문서보다 작동하는 소프트웨어
인수 테스트, 테스트 주도 개발, 단순한 설계, 리팩토링, 지속적 통합
- 계약 협상보다 고객과의 협력
작은 릴리스, 계획 게임, 인수 테스트, 메타포
- 계획을 따르기보다 변화에 대응하기
작은 릴리스, 계획 게임, 지속 가능한 속도, 테스트 주도 개발, 리팩토링, 인수 테스트
위 4가지 사항은 선호 사항일 뿐임을 주의해야 한다.
애자일은 작은 소프트웨어 팀이 작은 프로젝트를 관리할 수 있게 도와주는 작은 규칙이다.
하지만 모든 큰 프로젝트는 작은 프로젝트가 많이 모여서 만들어진다는 점을 잊지 말아야 한다.
✝️ Iron Cross : 철십자
소프트웨어 프로젝트의 근본 물리 법칙이다.
모든 프로젝트는 좋음, 빠름, 저렴함, 완성의 4가지 중 3가지까지만 고를 수 있고 모두는 가질 수 없다는 일종의 트레이드오프를 벗어날 수 없다는 것에서 비롯되었다.
좋은 프로젝트 관리자가 되고 싶다면, 모든 속성이 100%가 되기를 요구하는 것이 아니라 각 속성의 가중치를 상황에 적합하게 관리해야 한다는 것을 이해해야 한다.
📦 애자일은 데이터를 제공한다.
프로젝트 관리자가 철십자의 4가지 축의 가중치를 얼마로 할지 결정해야 할 때, 프로젝트 구성원들은 결정에 필요한 데이터를 제공함으로써 관리자가 프로젝트를 최선의 결과로 이끌도록 해야 한다.
각 반복주기가 종료될 때마다 측정한 수치를 가지고 데이터를 계속 분석하고 갱신해가며 계획을 조정하여 오차 범위를 줄이는 것을 목표로 해야 한다.
⛔️ 애자일은 희망을 없앤다.
놀랍게도 희망을 없애는 것이 애자일의 주요 목표 중 하나이다.
물론 부정적인 의미는 아니고, 희망이 프로젝트를 죽이기 전에 조금이라도 빨리 현실을 깨닫고 최선의 결과로 이끌 수 있게 상황을 관리하는 것을 택한다는 말이다.
애자일은 데이터를 많이 만들고, 관리자는 이러한 데이터를 이용해 상황을 관리한다.
⛳️ 프로젝트 관리자는 프로젝트를 어떻게 최선의 결과로 이끌까?
철십자 관점에서 생각해보면, 관리자는 일의 범위나 일정, 사람, 품질을 변경하는 것을 선택할 수 있다.
- 범위 변경
계획한 기능 중에 마감 기한까지 정말로 꼭 완성하지 않아도 되는 것이 있는지 이해관계자에게 물어보고 확인해본다. 합리적인 조직이라면, 우리가 가진 데이터를 인정하고 계획을 다시 면밀히 살펴보면서 절대적으로 필요하지 않은 기능을 찾고 해당 기능은 연기시킬 것이다.
이것은 매우 곤란한 일이지만, 다른 선택의 여지가 없기 때문에 어쩔 수 없다.- 일정 변경
보통의 경우, 마감 기한을 변경할 수는 없다. 그러나 이른 시점에 이해관계자에게 말한다면, 일정을 변경할 가능성도 있다.
마감 기한을 늘릴 수 있다면, 그 무엇보다 가장 좋은 선택지일 것이다.- 인력 추가
흔히 인력을 추가하면 반드시 프로젝트의 진척 속도가 빨라질 것이라고 예상하지만, 마냥 그렇지만은 않다. 브룩스의 법칙에 따르면 지연된 프로젝트에 인력을 추가하면 더 늦어질 수도 있다. 그러나 만약 사람을 추가하는 경우가 프로젝트의 전반적인 관점에서 + 가 될 것이라고 생각한다면, 인력을 추가하는 도박을 해보는 것도 하나의 방법이다. 물론, 사람을 추가하면 비용이 그만큼 발생한다는 점도 고려해보아야 한다.
- 품질 하락
품질을 떨어뜨리는 것은 옳지 못한 선택이다. 쓰레기를 만든다고 더 빨리 갈 수는 없다는 것을 유념해야 한다.
👥 관리자, 사용자, 고객의 입장
👀 반복주기가 끝날 때마다 개발 진척 상황을 눈으로 볼 수 있고, 높은 품질의 시스템을 받으리라고 기대한다.
따라서 개발자는 항상 기술적 준비 상태를 유지해야 한다.
즉, 애자일 시스템에서는 각 반복주기가 끝날 때면 기술적으로 배포가 가능해야 한다.
💭 시간이 지나도 생산성이 일정할 것이라고 생각한다.
개발자도 위와 똑같이 생각해야 한다.
아키텍처, 설계, 코드를 가능한 한 계속해서 깨끗하게 관리하여 재설계의 함정에 빠지지 않도록 주의해야 한다.
💸 소프트웨어 시스템이 바꾸기 쉬울 것이라 기대하며, 변경하려는 비용도 변경 범위에 비례하리라 생각한다.
위에서 이미 언급했던 것처럼, 소프트웨어는 바꾸기 쉬워야 한다.
고객의 요구사항이나 기능의 변경이 발생해도, 언제든 유연하게 대처할 수 있도록 대비해야 한다.
🎖️ 애자일이 주는 권리
애자일은 고객에게 다음 권리를 준다.
- 전체적인 계획을 알 권리가 있다. 무엇을, 언제, 얼마의 비용으로 완성하는지 알 권리가 있다.
물론 애자일에 따르면, 개발 초기에는 확실하고 정밀한 전체적인 계획을 알려주기 어렵다. 따라서 개발자는 날짜 아니면 범위에 여유를 두고, 정해진 날짜까지 스토리를 처리할 확률을 추정하여 계획을 세워 고객에게 알린다.
- 반복 주기마다 가능한 한 많은 가치를 얻을 권리가 있다.
고객은 반복 주기마다 가치의 우선순위를 지정하며, 개발자가 반복 주기 내에 끝낼 수 있다고 추산한 스토리 중에서 투자 수익률이 가장 높은 스토리를 고를 수 있다.
- 일정이나 추정이 바뀐 경우 제떄 알림을 받고, 목표 일자에 맞추기 위하여 업무 범위를 어떻게 줄일지 결정할 권리가 있다. 언제든지 프로젝트를 취소할 수 있으며, 이 경우 해당 시점까지 지불한 비용이 반영된 유용한 시스템을 받을 수 있다.
고객에게는 일정에 맞출 것을 요구할 권리가 없음을 주지해야 한다. 고객의 권리는 업무 범위를 바꾸어 일정을 관리하는 것으로 한정된다. 대신 일정이 어긋나려고 할 때 알 수 있는 권리를 통해서 너무 늦지 않게 대처할 수 있다.
- 작동하는 시스템을 통해 진척도를 알 권리가 있다. 개발자는 고객이 제공한 테스트로 계속해서 시스템을 검사하여 동작을 증명해야 한다.
- 과도한 비용 추가 없이 기능이나 우선순위를 바꿀 권리가 있다.
애자일은 개발자에게 다음 권리를 준다.
- 명확하게 정의된 우선순위와 함께 무엇이 필요한지를 알 권리가 있다.
완벽하게 정확한 요구사항이 있을 수 없는 경우도 있기 때문에, 위 권리는 오직 반복 주기 범위 내에서만 적용된다. 반복 주기 범위 밖에서는 요구 사항과 우선순위가 바뀌지 않는다고 생각할 권리가 있다. 단, 개발자가 생각하기에 요청받은 변경 사항이 사소하면 위 권리를 제쳐둘 수도 있다.
- 언제나 높은 품질의 결과물을 만들 권리가 있다.
고객은 개발자에게 절차를 건너뛰거나 저품질로 작업하라고 할 권리가 없다. 다시 말해, 고객은 개발자가 자신의 경력에 오점을 남기거나 직업 윤리를 어기도록 강요할 권리가 없다.
- 동료나 관리자, 고객에게 도움을 요청하고 받을 권리가 있다.
프로그래머에게 의사소통할 권리를 준다. 그리고 도움을 청할 권리는 필요할 때 도와주어야 하는 책임과 함께 온다는 것을 잊지 말자.
- 담당 업무를 할당받는게 아니라 수락할 권리가 있다.
전문 개발자는 모든 일이나 과제에 대해 “아니요”라고 말할 권리가 있다. 수락할 권리에는 비용이 따르기 때문에 일단 수락했다며느 업무의 품질과 실행에 책임을 져야 한다는 것을 잊지 말자.
- 자신만의 추정치를 만들고 갱신할 권리가 있다.
Robert C. Martin의 저서 Clean Agile : Back to Basics 을 읽고 책 내용 중 일부분을 정리한 글입니다.
읽어주셔서 감사합니다.
