린 제조^{lean manufacturing}를 공부한 사람이라면 누구나 신고 시게오(新郷 重雄)의 제조 7대 낭비를 배웠을 것이다.[^10] 이 책보다 앞서 낸 책에서, 우리는 이러한 7대 낭비를 소프트웨어 개발 7대 낭비로 옮겼었다. 이 절에서 그 내용을 다시 한번 살펴보자. 표 4.1을 보면 앞의 책과 비교하여 7대 낭비의 이름이 조금 변경되었지만 내용은 동일하다. 낭비를 찾는다는 것은 그것이 어떤 분류에 넣을 것인가를 고민하는 것이 아니다. 분류는 단지 낭비를 보는 습관이 몸에 배도록 도와줄 뿐이다. 낭비를 발견하고 제거하는 진정한 목적은 비용을 줄이고 우리 제품을 더욱 가치있게 만드는 것이다.

표 4.1 7대 낭비

제조	소프트웨어 개발
재공 재고	미완성 작업
과잉 생산	가외 기능
과잉 가공	재학습
이동	이관
동작	작업 전환
대기	지연
결함	결함

[^10]: Shigeo Shingo, Study of “Toyoda” Production System from an Industrial Engineering Viewpoint, Productivity Press, 1981, 5장

미완성 작업^{Partially Done Work}

소프트웨어 개발의 재고는 미완성 작업이다. 우리의 목적은 시스템에 대한 작업을 시작한 후, 통합, 테스트, 문서화를 모두 마친 배포가능한 코드까지 하나의 빠른 흐름으로 진행하는 것이다. 이를 실현하기 위한 유일한 방법은 한 번에 처리하는 작업량batch을 작게 줄여서 반복적 개발을 하는 것이다.

미완성 작업의 예

1. 코드로 옮기지 않은 문서: 설계 및 요구사항 문서가 오래 방치될수록, 변경이 필요해질 가능성은 커진다. 개발 팀은 종종 요구사항 변경이 필요하다는 것에 골치 아파하지만, 고객관점에서 보면 요구사항이 너무 일찍 작성된다는 것이 오히려 문제다.
2. 동기화하지 않은 코드: 코드를 체크아웃하여 개인 작업공간으로 가져오거나, 병렬 개발을 위해 브랜치를 생성한 경우에, 이러한 개인 작업공간 및 브랜치의 코드는, 거의 대부분 나중에 다시 머지(merge)해야만 한다. 개인 작업공간이나 브랜치의 코드를 동기화하지 않고 따로 두는 기간이 길어질수록, 나중에 머지하기 어려워지기 때문에 가능한 자주 동기화해야 한다.
3. 테스트하지 않은 코드: 결함을 즉시 검출하는 방법 없이 코드를 작성하는 것은 미완성 작업의 재고를 축적하는 가장 빠른 길이다. 코드 작업량을 측정할 때, 부분 점수는 있을 수 없다. 각각의 코드는 통합되고, 테스트되어 승인되거나, 그렇지 않으면 점수에 반영해서는 안 된다.
4. 문서화되지 않은 코드: 문서화가 필요하다면, 그것은 코드가 작성될 때 같이 만들어져야 한다. 이상적으로는, 코드 자체가 문서 역할을 해야겠지만, 사용자 문서나, 도움말 화면 등은 별도 작성이 필요한 문서이다. 테스터가 개발 팀에 상주하는 것처럼, 테크니컬라이터들도 그렇게 해야 한다. 결국은, 이들도 고객이 업무를 완수하는 데 도움을 줄 사람들이다. 테크니컬라이터가 개발 팀의 다른 멤버들에게 "그 기능이 우리 고객의 업무 수행을 정확히 어떻게 도와줄 수 있나요?"라고 계속해서 묻는 것만으로도, 가외 기능이 작성되는 것을 많이 막을 수 있다.
5. 배포되지 않은 코드: 모든 환경에서 코드를 바라는 만큼 자주 배포할 수는 없다. 새로운 소프트웨어가 고객이 현재 수행중인 업무에 방해가 될 수도 있기 때문이다. 그러나 가능하면 코드를 일찍 배포하는 쪽으로 생각하라. 사실, 사용자는 조금씩 변경되는 것은 쉽게 수용한다. 교육도 덜 필요하고, 혼선도 최소화될 수 있기 때문이다.

 

우리는 문서가 많이 쌓여 있지만 이 상황을 바꿀 수는 없습니다.

왜냐하면 소프트웨어 요구사항명세서를 작성하고 코드 추적성을 확보하는 것이 정부 규정이기 때문입니다. 만약 소프트웨어 요구사항명세서를 작성하고 추적성을 확보해야 한다면, 명세서 내용 중에서 될수록 많은 부분을 실행가능한 테스트로 작성하는 방법을 고려하라. FIT(Framework for Integrated Tests: 테스트 통합 프레임웍)이나 유사한 인수 테스트 도구를 사용하여 예제에 의한 명세specifications-by-example를 작성하는 것을 검토하라.[^*1] 이러한 도구를 이용하면 테스트의 코드 추적성을 추가 노력없이 확보할 수 있다. 만약 매일 이러한 테스트를 수행하고 그 결과를 형상 관리 시스템에 저장한다면, 어떤 테스트가 통과되고 어떤 테스트는 통과되지 않았는지의 기록이 항상 남게 된다. 규정을 다루는 사람들도 이것을 매우 좋아할 것이다.

[^*1]: Rick Mugridge와 Ward Cunningham,『Fit for Developing Software: Framework for Integrated Tests』, Prentice Hall 출판, 2005년 참조. www.fitnesse.org. 7장 앞 부분에서 소개하는 사례에는 FIT와 Fitnesse가 설명되어 있다.

가외 기능^{Extra Features}

오노 다이이치(大野 耐一)는 과잉생산(지금 당장 필요하지 않은 재고를 만들어내는 것)이 제조의 7대 낭비 중 최악의 낭비라고 강조하였다. 마찬가지로, 소프트웨어 개발의 7대 낭비 중 최악의 낭비는 고객이 현재 작업을 수행하는데 필요하지 않는 기능을 추가하는 것이다. 만약 그 기능에 대해 현재 명확한 경제적 필요가 없다면, 그것은 개발되지 말아야 한다.

구현해야 한다고 알고 있는 것을 미리 구현하면 안된다는 말인가요?

우리가 종종 이런 질문을 받을 때는 주로 다음과 같은 지침을 제시합니다.

1. 상식을 활용하라. 이것들은 단지 지침이라는 것을 명심하라.
2. 고객 업무에 집중하라. 고객이 업무를 수행하기 위해 필요한 소프트웨어를 개발하는 데 여러 번의 이터레이션이 걸리고, 그 기능이 업무를 수행하는데 절대적으로 없어서는 안되는 기능이라면 그것은 부가 기능이 아니다.
3. 될수록 기능을 추가하지 않는 방향으로 생각하라. 만약 어떤 기능의 필요에 대해 조금이라도 의문이 있다면, 아직 시기상조다. 기다려라.
4. 기능을 일찍 추가하지 않고 나중에 추가할 수 있는 구조로 만들어라. 기업에서 재사용 가능한 서비스 프레임웍을 ‘추출’하는 것은 좋은 아이디어라고 여러 번 입증되었지만, 앞으로 일어날 일들을 예상하여 이것저것 뭐든지 할 수 있도록 설정 가능한 애플리케이션 프레임웍을 만들어 내는 시도는 실패만 거듭해 왔다. 그 차이를 이해하라.

재학습^Relearning

최근에 우리는 애자일 소프트웨어 개발이 고객에게 어떤 영향을 미치는지를 논의하는 공개 토론회에 참석했는데 거기서 어떤 사람이 이렇게 말했다. “이 방 안에 혹시 고객이 있나요? 우리는 진짜 고객의 견해를 들어야 합니다.” 한 사람이 외롭게 손을 들었다. 그는 이런 질문을 받았다. “애자일 개발이 어떤 면에서 당신에게 도전적인가요?”

자신이 고객이라고 밝힌 사람이 이렇게 대답했다.“제 생각에 가장 큰 문제는, 제가 어떤 결정을 내렸었고, 어떤 것들을 이미 시도했었는가를 잘 기억하지 못한다는 것입니다. 그래서 저는 그것들을 다시 시도하게 됩니다.”

우리가 알던 것을 잊어버린 후에 다시 생각해내는 것이야말로 개발에서의 ‘재작업’을 가장 잘 정의한 것이다. 우리는 배운 것을 기억하고 있어야 한다는 것을 안다. 그럼에도 불구하고, 지식을 획득하기 위한 우리의 방법은 너무나 장황하고, 필요한 것보다 훨씬 덜 엄격한 경우가 너무 많다. 지식을 창조하고 유지하는 것에 관한 복잡한 주제는 7장에서 자세히 다룰 것이다.

지식을 낭비하는 또 다른 경우는, 지식을 가진 사람들을 개발 과정에 끌어들이지 못하여, 그들이 작업공간에 제공할 수 있는 지식을 놓치는 것이다. 이것은 단지 우리가 만들어낸 지식의 궤적을 잃는 것 이상으로 심각한 일이다. 작업자들이 오랫 동안 쌓아 온 경험을 이끌어냄으로써 모두의 지식을 배가하는 것은 매우 중요하다.

우리는 설계에 대한 결정이 내려지면, 그것을 모두 문서화하려 했어요. 문제는 이 문서들을 절대 다시 보지 않는다는 것입니다.

이것은 일반적으로 발생하는 문제입니다. 그리고 많은 조직들이 설계 결정을 문서화하는 것을 중단한 이유이기도 합니다. 그들이 실패했던 경험에서 얻게 되는 지식은 문제를 해결하는데 매우 유용한 지식이지만, 그 지식을 나중에 참조하기 쉽게 만드는 것은 매우 도전적인 일입니다. 다음의 질문부터 시작해 보십시오. 지금 여러분이 하고 있는 일이 잘 되고 있습니까? 그렇지 않다면, 그 일을 계속 진행하지 마세요. 대신 여러분의 목표를 다시 살펴보고, 여러분의 팀과 협력하여 그 목표를 달성하는데 필요한 지식을 가장 효과적이고 효율적인 방법으로 보존하는 방법을 고안하세요. 7장에 몇 가지 아이디어가 제시되어 있습니다.

이관^Handoffs

어린 아이에게 자전거 타는 법을 가르치는 것은 매우 독특한 체험이다. 아이는 우선 움직이면서 균형을 잡는 법을 배워야 하기 때문에, 여러분은 그 아이의 자전거를 살짝 잡은 채로 아이가 그 방법을 터득할 때까지 옆에서 같이 달려야 한다. 아이가 처음 스스로 페달을 밟아 여러분의 도움없이 나아가는데 성공하면, 여러분은 그제서야 아이에게 멈추는 방법을 가르치지 않았다는 것을 깨닫게 된다. 몇 번 더 넘어지고 나서야 아이는 혼자 힘으로 자전거를 탈 수 있게 된다. 2시간 정도 후에 여러분은 아이가 길을 따라 돌진하여, 가볍게 출발하고 끽 소리를 내며 멈추는 것을 보고 놀라워 한다.

업무를 이관한다는 것은 자전거를 탈줄 모르는 사람에게 자전거를 건네주는 것과 같다. 당신은 그들에게 자전거 타는 방법에 관한 두꺼운 설명서를 줄 수도 있겠지만, 그것이 크게 도움이 되지는 않을 것이다. 그 보다는 같이 달리면서, 속도가 붙음에 따라 생기는 균형감을 직접 느끼게 하는 편이 훨씬 좋다. 그러고 나서는 그들이 출발, 정지, 회전, 내리막길 주행, 오르막길 주행을 연습할 때 적절한 조언을 해 주는 것이다. 오래지 않아 여러분의 동료는 자전거 타는 법을 알게 될 것이다. 비록 그것을 말로 설명하지는 못하더라도 말이다. 이러한 종류의 지식을 암묵지라고 하며, 암묵지를 문서를 통해 다른 사람에게 전수하기란 매우 어렵다.

업무가 동료에게 이관될 때는 상당히 많은 양의 암묵지가 전수되지 못하고 원래의 사람에게 남게 된다. 다음을 생각해 보라. 만약 한 번 이관할 때 지식이 50%씩 (매우 보수적인 추정이다) 전수되지 못하고 남게 된다고 했을 때,

• 2번 이관을 거치면 25%의 지식만 전수되고,
• 3번 이관을 거치면 12%의 지식만 전수되고,
• 4번 이관을 거치면 6%의 지식만 전수되고,
• 5번 이관을 거치면 3%의 지식만 전수된다.

암묵지는 전달하기가 매우 어렵기 때문에, 이를 이관할 때는 항상 정보가 손실된다. 진짜 문제는 어떻게 그러한 낭비를 최소화할 것인가이다.

이관의 낭비를 줄이는 몇 가지 방법

1. 이관하는 횟수를 줄여라.
2. 서로 가르칠 수 있도록 설계-개발 팀(모든 기능을 포함하는 완전한 교차기능 팀)을 활용하라.
3. 의사소통의 대역폭을 넓혀라. 문서는 사실상 암묵지를 전혀 전수하지 못한다. 문서 대신 면대면 토론, 직접 관찰, 모형mock-up, 프로토타입, 시뮬레이션을 통한 상호작용으로 대체하라.
4. 예비 코드나 부분 코드도, 가능한 일찍 그리고 실무적으로 가능한 자주 배포하여 검토와 피드백을 받아라.

작업 전환^{Task Switching}

현재의 복잡도를 파악하고 다음 퍼즐 조각을 정확히 맞추어야 하는 소프트웨어 개발은 고도의 집중과 깊은 사고를 많이 요구한다. 다른 작업으로 전환하는 것은 정신을 산란하게 할뿐만 아니라, 시간을 소모시키고 종종 두 작업 모두의 결과를 악화시킨다. 지식 근로자가 3,4개의 작업을 동시에 처리해야 하면 그들은 종종 새로운 작업을 수행하는데 쓰는 시간보다 작업을 전환하는데 더 많은 시간을 사용한다. 이러한 작업 전환 시간이 낭비이다.

그뿐만 아니라, 여러 작업을 동시에 수행하려 하는 것은 대부분 이치에 맞지 않는다. 당신에게 A, B, C 이렇게 세 개의 작업이 주어졌다고 해 보자. 논의를 위해 작업을 수행하는데 각각 1주가 소요된다고 가정한다. 작업들을 한 번에 하나씩 수행한다면, 첫주가 끝났을 때 A 작업이 완료되어 가치를 제공하기 시작한다. 2번째 주가 끝났을 때 B 작업이 가치를 제공하기 시작하고, 3번째 주가 지나면, 3개의 작업이 모두 완료되고 많은 가치가 이미 실현되어 있다.

이번에는 3개의 작업을 동시에 하는 것으로 가정해보자. 그림 4.2는 이 시나리오를 따를 때 얻을 수 있는 최선의 경우를 보여준다. 각각의 작업을 8개의 똑같은 조각으로 나누어, 작업 전환에는 최소한의 시간만 사용된다고 가정하자. 이런 이상적인 상황을 가정하더라도, 3주가 지날 때까지 한 개의 작업도 완료되지 않는다. 작업 전환을 하기 위해 낭비된 시간 외에도, 일찍 완료되었더라면 제공될 수 있었던 잠재적 가치 또한 얻지 못했다.

우리는 별도의 유지보수 팀을 원하지 않기 때문에 작업 전환을 할 수밖에 없어요.

어떤 코드라도 한번 배포하고 나면 유지보수를 필요로 합니다. 그래서 때로는 별도의 유지보수 팀을 구성하여 개발자들이 유지보수 때문에 작업 전환을 하는 일 없이 개발에만 전념할 수 있게 합니다. 그러나 우리는 일반적으로 이런 방식에 반대합니다. 왜냐하면, 팀은 그 제품의 수명주기 동안 제품과 함께하는 것이 최선이라고 믿기 때문입니다. 그렇게 하지 않으면 사람들은 소위 코드를 “완료할 수 있다”고 착각하게 됩니다. 그러나 이것은 대개 잘못된 통념일 뿐입니다. 코드는 항상 변화하는 (그리고 변해야만 하는) 살아있는 생명체입니다.

개발 팀이 자신들의 코드를 유지보수하게 한다는 것은 개발 팀이 유지보수까지 감당하느라 작업 전환을 해야 한다는 것을 의미합니다. 물론, 이것은 무결점 코드를 출시하게 하는 훌륭한 동기를 제공하여, 개발 팀이 새로운 개발에 집중할 수 있게 합니다.

그래도 여전히 개발자들의 정신을 산만하게 만드는 유지보수 요구가 있을 것입니다. 개발자가 ‘기능’이라고 생각하는 것을 별 이유 없이 ‘결함’이라고 생각하는 고객들이 있기 때문입니다. 여기에 코드를 유지보수하느라 발생되는 혼란을 최소화시키기 위한 몇 가지 방법을 소개합니다.

1. 매달 혹은 이터레이션마다 개발자 중에서 2명씩 교대로 그 기간 동안의 모든 유지보수 업무를 수행하게 하세요.
2. 지난 24시간 동안 발생한 모든 이슈사항을 팀 전체가 공동으로 처리할 수 있게 매일 아침 2시간 정도를 할애하세요. 그런 다음 일일 미팅을 하고 나머지 시간은 새로운 개발에 전념하게 하세요.
3. 유지보수 요청을 적극적으로 선별하여 급박한 요청만 즉시 처리하세요. 매주 격주로 일정 시간을 따로 떼어서 눈에 띄게 중요한 유지보수 이슈를 처리합니다. 만약 그 할애된 시간이 충분히 짧다면, 대부분의 요구는 대기상태가 될 것이고, 일부는 사라지는 것도 있을 겁니다. 이 방법은 유지보수 업무량을 평준화하는 방법입니다.
4. 모든 고객을 같은 코드베이스로 대응하고, 매주 새 버전을 릴리스하세요. 그리고 그 릴리스에 나타난 문제들을 모두 해결합니다. 이제 문제를 제기하는 고객이 있으면 현재 버전으로 업그레이드해 주기만 하면 됩니다.

지연^Delays

다른 일을 하고 있는 개발자가 가용한 상태가 될 때까지 기다리는 것은 지연에 의한 낭비를 야기하는 가장 큰 이유이다. 개발자들은 대략 15분마다 중요한 결정을 내린다. 그런데 이러한 결정을 내리는데 필요한 정보들을 기존 문서에서 다 찾을 수 있을 것으로 생각한다면 너무 순진한 생각이다. 만약 개발자가 코드 구조나 수행 기능을 잘 이해하고 있고, 그 외 나머지 질문들에 대해 대답해 줄 수 있는 사람이 같은 방 안에 있다면, 결정을 빨리 내릴 수 있을 것이다. 만약 그렇지 않다면, 개발자에게는 3가지 옵션이 있다. 하던 일을 멈추고 답을 구하거나, 다른 작업으로 전환하거나, 아니면 추측으로 결정을 내리고 일을 계속하는 것이다. 만약 개발자가 답을 구하기 어려운 상황이라면, 개발자는 2번째나 3번째 방침을 따를 것이다. 간혹 지연에 따른 불이익이 크지 않은 경우에는 개발자들이 답을 찾느라 상당한 시간을 쓰게 될 것이다. 이들 중 어떤 것도 좋은 방법이 아니다.

필요한 인원이 모두 한 공간에서 일하는 팀과 정기적인 피드백이 있는 짧은 이터레이션은 의사결정의 질을 높여주면서 지연을 극적으로 줄여줄 수 있다. 이것이 지연을 줄이기 위한 유일한 방법은 아니다. 팀 구성원들이 지리적으로 어디에 있건, 중요한 것은 지식을 필요한 시간과 장소에서 얻을 수 있는 방법을 확보하는 것이다. 너무 이르거나 너무 늦지 않도록 하라. 너무 이르면 변경되고, 너무 늦으면 무시된다.

소프트웨어는 왜 그렇게 오래 걸리나요?

고객 관점에서 보면, 개발자들이 질문에 대한 대답을 구하기 위해 대기하는 것보다 더 큰 지연이 있으며 이것들은 훨씬 더 심각한 문제입니다.

1. 내가 원하는 것이 무엇인지 내가 정확히 알 때까지 나의 문제를 풀지 않고 기다리기. 내가 그것을 어떻게 알 거라고 기대하나요?
2. 프로젝트 승인을 얻을 때가지 수개월간 기다리기.
3. 개발자가 배정될까지 하염없이 기다리기.
4. 배정된 개발자들이 가용한 상태가 될 때까지 기다리기.
5. 골치아픈 변경 승인 프로세스. 나를 몇 달간 기다리게 해놓고, 그동안 나의 상황이 변하지 않고 그대로 있을 것으로 생각합니까?
6. 전체 시스템이 완성될 때까지 기다리기. 지금 당장 나에게 필요한 핵심 기능들만 받아볼 수는 없을까요?
7. 코드가 테스트를 통과할 때까지 기다리기. 이것이 왜 그렇게 오래 걸리나요?
8. 새로운 소프트웨어가 기존 프로그램을 뒤죽박죽으로 만드는 것을 멈출 때까지 기다리기. 또는 그 반대일지 누가 아나요?

결함^Defects

모든 코드베이스는 단위 테스트 및 인수 테스트에 결함 유입을 걸러주는 실수 방지^{mistakeproofing} 테스트가 포함되어야 한다. 그러나, 이러한 테스트는 우리가 생각한 대로 코드가 실패하지 않고 동작하는지를 확인해 주는 것일 뿐이다 그러나, 소프트웨어는 어떻게든 정해진 길을 벗어나 실패하는 길을 찾아내기 때문에, 탐색적 테스트exploratory test에 능숙한 테스트 전문가는 예기치 않은 실패를 가능한 많이 찾아낼 수 있도록 코드를 일찍 그리고 자주 테스트한다. 결함이 발견되었을 때는, 그 결함을 검출하는 테스트를 만들어서 이것이 다시 발생하지 않도록 해야 한다. 또한, 보안의 취약점이나, 부하 대응력 등을 테스트하기 위한 도구가 필요할 수도 있다. 조합combinatorial 시험 도구도 매우 유용할 수 있다. 우리는 최종 검증에서 일상적인 결함이 발견되지 않도록, 최대한 빨리 모든 결함을 발견하려고 노력해야 한다. 만약 결함을 가진 채로 최종 검증에 들어가는 일이 일상적으로 발생한다면, 이는 프로세스에 결함이 있다는 의미이다.

훌륭한 애자일 팀은 극히 낮은 결함율을 자랑하는데, 이는 코드에 대한 실수 방지와 더불어 결함을 매우 드문 것으로 만드는데 최우선으로 집중하기 때문이다. 그 다음으로 집중하는 부분은 결함을 가능한 한 빨리 발견하는 것과 그런 결함이 다시 발생하지 않도록 하는 방법을 찾는 것이다.

그러나 개발을 시작할 때부터 테스팅을 해야 하는 진짜 이유는 실수 방지보다 더 심오하다. 인수 테스트는 제품 설계의 일부이며, 그 설계를 그 도메인의 구조에 맞추는 가장 적절한 수단이다. 단위 테스트는 코드 설계를 좋게 해준다. 왜냐하면, 코드를 작성하기 전에 단위 테스트를 작성하면 단순하고, 이해하기 쉽고, 테스트하기 좋은 코드를 작성하게 되기 때문이다. 이러한 테스트는 우리가 코드와 최종 제품이 어떻게 동작하는지를 정확하게 그리고 자세하게 말해준다. 그런 점에서 볼 때, 인수 테스트와 단위 테스트는 시스템에 대한 최고의 문서 역할을 한다. 거기다 그 문서들은 항상 최신 버젼이다. 왜냐하면, 그 테스트들은 항상 통과되어야하기 때문이다.

이런 광범위한 자동 테스트는 낭비 아닌가요?

신고 시게오는 "결함을 예방하기 위한 검사"는 어느 프로세스에서나 절대적으로 필요하지만, "결함을 찾아내기 위한 검사"는 낭비라고 말했습니다. 개발 팀은 결함이 아예 발생하지 않도록 예방하는 것과, 절대로 나쁜 코드 위에서 개발하지 않는 것이 결국에는 항상 더 빠르다라는 것을 발견했습니다. 더욱이, 테스트 하니스는 쉽고 안전하게 코드를 수정할 수 있게 해주며, 그 혜택을 배가시킵니다. 결국, 광범위한 요구사항 스펙을 작성해온 조직이라면, 실행할 수 있는 스펙으로서의 테스트를 작성하는 것이 기존에 스펙을 작성하고 이를 코드에서 추적하는 것보다 훨씬 시간이 적게 소요된다는 것을 발견하게 될 것입니다.

고객의 독특한 환경에서 테스트해 볼 수 없기 때문에, 설치할 때마다 결함이 발견돼요.

때로는 실제 고객 환경에서 최종 통합 테스트를 할 수가 없고, 그래서 설치 시에 결함이 발견되기도 합니다. 그러나 이러한 상황에서도 여러분은 가장 많이 발생하는 설치 결함을 목록으로 만들어서 각각에 대한 근본 원인을 분석하고, 우선순위가 높은 것부터 하나씩 공략하는 개선 프로그램을 시작해야 합니다. 이를 통해 고객 사이트에서 결함이 발생하는 것 자체가 매우 드문 일이 되도록 할 수 있습니다.

우리가 알고 있는 몇몇 회사들은 설치도 이터레이션의 일부로 포함시키고 있습니다. 소프트웨어가 고객 사이트에서 실제로 가동될 때까지는 그 이터레이션이 끝난 것이 아닙니다. 이러한 접근을 통해, 전체 개발 팀이 고객을 위한 설치 작업에 참여하게 되는 것입니다. 그리고 고객 요구사항에 대응하기 위해 별도의 시간을 할애하는데, 그 시간에는 고객이 요청하는 것은 무엇이든지 그것이 현실적이기만 하다면 처리됩니다. 고객의 요청을 받는 과정에서 기능 수정과 결함을 따로 구분하는 시도는 하지 않습니다.

• 이미지 출처: Stuart Caie / CC BY 2.0