범위는 프로젝트의 크기를 언급합니다.

얼마나 많은 시간, 노력, 자원들이 필요한가?. 어떤 수준의 품질에서 어떤 기능성을 가지는지? 얼마나 많은 위험이 있는지? 어떠한 제약이 존재하는지? 이에 대한 대답들이 프로젝트의 범위를 정의합니다.

소프트웨어 아키텍트들은 크고, 복잡한 프로젝트에 도전하는 것을 사랑합니다. 잠재적인 보상은 사람들이 인위적으로 프로젝트 외관상의 중요성을 증가시키기 위해 프로젝트의 범위를 인위적으로 확장하게 유혹할 수 있습니다.

범위를 확장하는 것은 성공의 적입니다, 왜냐하면 실패할 가능성이 예상했던 것보다 더 빨리 증가하기 때문입니다.

프로젝트의 범위를 2배로 증가시키는 것은 종종 실패의 가능성을 10배로 높입니다. 왜 이렇게 실패 가능성이 높아질까요? 몇 가지 예 들을 살펴봅시다.

직감은 일을 두 배로 일을 하기 위해 우리의 시간이나 자원을 두 배로 늘리라고 말합니다.

역사[1]는 ,직관이 제안했던 것처럼,  미치는 영향이 선형적으로 증가(두배로 일하기 위해 미치는 영향이 단시 시간과 자원을 두배로늘리는 것)하지 않는다고 말합니다. 예를 들어나 네 명의 팀은 두 명의 팀이 커뮤니케이션 하는 것보다 2배 이상의  커뮤니케이션 비용이 들것입니다.

추정은 정확한 과학과는 거리가 멉니다. 예상했던 것보다 구현하기에 훨씬 어려운 기능(features)들을 겪어 보지 않은 사람이 있나요? 물론 (이미 도메인이나 요구사항에서) 내장하고 있는 크기와 복잡성을 다루어야만, 가치가 있는 몇몇 프로젝트가 있습니다. 텍스트를 입력할 기능도 없는 텍스트 에디터는 쉽게 만들수 있지만, 이건 텍스트 에디터라고 할수 없습니다.

그럼, 어떤 전략들이 실세계의 프로젝트 범위를 감소시키고 관리할수도록 도와 줄 수 있을까요?

(고객이) 실제 요구하는 것을 알아내십시오. 프로젝트가 반드시 제공해야 하는 기능들은 요구사항의 묶음입니다. 요구사항은 기능과 기능의 품질을 정의합니다.

고객에게 평가할 수 있는 가치의 측면에서 설명되지 않는, 모든 요구사항들에 대해서 질문을 해 보십시오. 만약 회사의 수익에 어떠한 영향도 미치지 않는 다면, 왜 이것이 요구사항이 될어야 할까요?

분할후 정복하십시오. 업무를 더 작고 개별적인 덩어리로 나눌 수 있는 기회를 찾아보십시오.

몇몇의 작은 개별적인 프로젝트가, 서로 엮여있는 하나의 큰 프로젝트보다 관리하기 쉽습니다.

우선 순위를 두십시오. 비즈니스세계는 빠르게 변화합니다. 큰 프로젝트의 요구 사항들은 프로젝트가 완성되기 전까지 여러 번 바뀝니다.

중요한 요구사항은 비즈니스가 변화하여도 존재하는 경우가 많지만, 중요하지 않는 요구사항들은 변하거나 심지어 사라져 버리기도 합니다. 우선사항을 결정하는 것은 당신이 가장 중요한 요구사항들을 먼저 수행하게 만듭니다.

가능한 결과가 나오자마자 전달하십시오. 거의 모든 사람들이 어떤 것을 가지기 전에 그들이 무엇을 원하는지 알지 못합니다. 유명한 카툰에서는 고객이 무슨 말을 하는지 그리고 프로젝트에서 어떤 다양한 역할이 이해되는지에 기반하여 어린이 그네를 만든 프로젝트의 진보를 보여줍니다. 그 복잡한 결과는 오직 그네와 어렴풋이 닮아있습니다. “무엇이 작동되었는지- what would have worked”로 타이틀이 붙여진 마지막 패널이, 낡은 타이어를 이용한 간단한 그네를 보여줍니다.

고객이 무언가를 시도할 때, 해결책은 예상했던 것보다 쉬울수 있습니다. 가장 중요한 것을 먼저 만드는 것은, (당신이 이것에 대한 피드백이 가장 필요할때 보다), 가장 중요한 피드백을 미리 받는 것을 의미합니다.

Agile 옹호자[2]들은 우리가 할 수 있는 가능한 가장 간략한 건축물을 세우라고(build) 간곡히 부탁한다. 복잡한 아키텍쳐는 간단한 아키텍쳐보다 훨씬 자주 실패 합니다. 프로젝트의 범위를 줄이는 것은 더 간단한 건축물을 짓게 합니다. 그리고 이것은 아키텍트가 성공의 가능성을 증진시키는데 적용할 수 있는 가장 효과적인 전략 중 하나입니다.

Written By Dave Quick.

이 자료는 Creative Commons Attribution 3 라이센스를 준수하며, Wiki 원본과 책 원본의 내용이 상이할 수 있습니다.

1차 번역 : 김 현종

2차 번역:  손 영수

---

[1] 맨 먼스 미신(The Mythical Man-Month)을 보아라 : 소프트웨어 공학에 대한 에세이, 저자  Frederick Brooks (원서 – Addison-Wesley Professional, 번역서 – 케이앤피북스 )

[2] Kent Beck이 쓴 (Addison-Wesley Professional, 번역서 – 인사이트). 익스트림 프로그래밍 : 변화를 포용해라 (eXtreme Programming eXplained: Embrace Change)를 보십시오.