며칠 전 사람들을 만났더 지인께서 이런 말씀을 하십니다.
애자일을 적용하니 관리자와 고객이 너무 좋아한다. 하지만 2주마다 릴리즈를 해야 해서 개발 강도가 생각했던 것보다 높다. 개발자들이 힘들어 하는 것 같지만 고객과 관리자가 좋아하니 지금처럼 계속 해야 할것 같다.
애자일 개발 방식은 자주 릴리즈를 하고 지속적으로 고객을 만나 피드백을 받습니다. 이를 통해서 만들어야할 제품의 정보를 업데이트하고 중간 제품에 대한 피드백을 통해 시장과 고객에게 가치를 전달할 수 있는 제품을 전달할 수 있습니다.
이로 인해 개발자들은 높은 긴장 상태를 지속적으로 유지하게 됩니다. 애자일 개발 방법에서는 정보를 투명하게 공개하기에 관리자가 현재의 개발 상황을 비교적 명확하게 파악할 수 있습니다. 높은 긴장 상태의 개발자는 관리자의 눈을 피할 수도 없습니다. 개발자의 안정감이 중요한 이유입니다.
하지만 어떤 관리자는 경영진이나 스스로 원하는 목표를 달성하기 위해 마이크로매니징을 시도 하기도합니다. 업무는 늘어나고 동기부여는 떨어집니다. 이렇게 되면 개발자는 곧 번아웃 상태에 빠지게 됩니다.
XP는 이와 관련한 프랙티스를 제안하고 있습니다. 바로 지속 가능한 속도로 일하기(Sustainable Pace)입니다.
"Sustainable Pace" 무엇인가?
Sustainable Pace는 Extreme Programming과 Agile Manifesto에서 기본적인 Practice입니다. 테스트주도개발(TDD, Test Driven Development) 또는 지속적인 통합(CI,Continuous Integration)과 같은 실천법과 달리 Sustainable Pace는 많이 알려지지 않았으며 공식적으로 수행하는 조직이 많지 않습니다.
기원
"Sustainable Pace"의 개념은 2011년 애자일 선언문을 통해 알려졌습니다. Extreme Programming의 전문가인 켄트 벡은 "Extreme Programming Explained" 초판에서 이 개념에 대해서 이야기를 하고 있으며 "일주일에 40시간 이상, 그리고 두 주 연속으로 초과근무를 하지 말라"고 이야기 합니다. 하지만 이 표현이 일정시간만 일해야 한다는 오해를 만들어 낼수 있다고 느낀 론 제프리스는 "일주일에 40시간 일하기"라는 표현 대신 "Sustainable Pace"라는 용어를 사용하였습니다.
이후 켄트 벡도 팀을 최고의 상태로 유지한 상태로 일하자는 의미로 2004년 “Energized Work”라는 표현으로 대체했습니다.
아래의 애자일 선언문의 원칙 중 하나는 Sustainable Pace를 가장 잘 표현하고 있는 문장입니다.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
"Sustainable Pace"는 유효한 개념인가?
1920년대에 헨리 포드(Henry Ford)는 생산성이 작업 시간에 의해 증가하지 않는다는 것을 증명했으며, 주당 48시간을 초과하지 않는다는 EU의 근무시간 지시(EU Work Directive)도 사회적 책임이 아니 생산성 측면에서 정의된 것입니다. 하지만 현재 많은 사람들이 일정 시간 이상 근무를 하거나 야근, 주말 근무를 수행하고 있습니다.
소프트웨어 개발시 초과 근무를 하면 어떤 일이 발생할까요? 몇 몇 연구는 초과 근무 첫 주에는 생산성 향상을 보여주지만 이후에 생산성이 급속히 감소하고 궁극적으로 40시간 일하는 것보다 낮은 생산성 수준으로 떨어진다는 것을 보여줬습니다.. 초과 근무로 인해 사람들의 인지 능력이 떨어지는 것을 알지 못하고 이는 결국 품질 저하로 이어집니다.
초과 근무는 기술적 부채를 해결하지 못하게 하는 원인이 됩니다.
마틴 파울러는 비즈니스 기회를 잡기 위해 이자를 감수하고 돈을 빌리는 것을 빗대어 소프트웨어 개발에서 주요 일정을 맞추기 위해 무리하게 일하며 좋지 않는 코드를 만들어 내는 것을 “기술적 부채”라는 표현을 사용하여 설명했습니다.
Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.
비즈니스가 시장 기회를 잡기 위해 빚을 지면서까지 시장 선점을 하는 것과 마찬가지로 개발자는 기술적인 부채로 인해 중요한 마감 기한을 맞추기도 합니다.
결국 이렇게 발생한 부채는 시간을 투자하여 해결하지 않으면 지속적으로 이자를 만들어내게 되어 프로젝트에 부담이 됩니다. 워드 커닝햄은 1992년에 부채라는 표현을 처음사용하여 아래와 같이 표현했습니다.
Every minute spent on not-quite-right code counts as interest on that debt
"좋지 않은 코드를 만들면 지속적으로 부채에 대한 이자가 만들어집니다."
기술적 부채와 그에 따른 이자를 System Theory 또는 System Thinking 방식을 빌리면 아래과 같은 모형으로 표현될수 있습니다.
초과 근무는 개발자의 집중력을 떨어뜨리고 이는 기술적 부채를 증가시키며 품질을 떨어 뜨립니다. 품질 유지를 위해 점점 많은 시간을 투자하게 되며 일정시간동안 개발할수 있는 요구사항의 양이 줄어들도록 만듭니다. 이는 또 다시 초과 근무를 증가시킵니다. 결국 악순환의 고리를 만들어 내며 상황은 점점 심각해집니다.
"Sustainable Pace"의 이익들
애자일 사고 방식에서 바라볼때 예외적인 경우를 제외하고는 초과 근무를 하는 것은, 생산성을 높이기 보다는 생산성을 저해하게 됩니다. 초과 근무는 일정 관리 실패 또는 품질 저하를 드러나지 않게 만들기 때문에 문제를 드러내지 못해 근본적인 원인을 해결하는 방식으로 업무를 이끌어가지 못합니다.
초과 근무는 문제를 드러내게 만들어 근본적인 문제를 해결하는 방향으로 나아가는 애자일 방식의 의도와 맞지 않습니다.
Sustainable Pace를 원칙으로 업무을 진행하게 되면 개발팀은 개발과 운영에 있어 예측성을 높이며 이를 통해 앞으로의 계획을 수월하게 만듭니다. Sustainable Pace라는 원칙으로 일하지 않으면 업무량이 일정하게 유지되지 않으므로 과거의 데이터를 통해 미래를 예측하거나 계획을 위한 자료로 과거의 사례를 활용하는 것을 힘들게 만듭니다.
또한 Sustainable Pace라는 원칙은 업무를 단순히 수행하는 것이 아닌 무엇이 중요한 업무인지 먼저 수행해야 하는 것은 무엇인지와 같은 중요한 물음을 개발팀에 던져주며 수면으로 들어나지 않았던 많은 비효율적인 업무들을 드러내도록 만듭니다.
생산성과 관련된 8가지 실험들
http://lunar.lostgarden.com/Rules%20of%20Productivity.pdf
'Agile' 카테고리의 다른 글
| 재택근무를 시작하는 분들을 위한 수줍은 안내서 (0) | 2020.04.27 |
|---|---|
| 시스템 씽킹과 애자일 코치 (0) | 2020.04.17 |
| 업무의 우선순위 정하기 (0) | 2020.04.01 |
| "스포티파이가 제품을 만드는 방법(How Spotify Builds Products)" 살펴보기 (0) | 2020.03.12 |
| 스크럼(Scrum)을 그리고 소개해보았다. (0) | 2020.01.09 |
