14 Feature-Set Control #1570
Description
개발자, 관리자, 영업부, 최종 사용자가 이미 기능이 과다한 제품에 더 많은 기능을 넣는 관례 때문에,
어떤 소프트웨어 노장이 좀더 간결한 소프트웨어 제품을 공개적으로 간청했다(Wirth 1995).
사실 자료
기능 집합 관리에서 가장 심각한 문제는 요구사항 변형, 즉 프로젝트 후반에 발생하는 요구사항 추가다.
- 요구사항 변형을 통제하지 못하는 프로젝트는 과도한 일정 압력에 시달릴 가능성이 크다(Jones 1994).
- 여러 연구에서 요구사항 변형이 비용과 일정 초과를 일으키는 흔한 원인 중 하나라고 밝혀졌다(Vosburgh et al. 1984, Lederer and Prasad 1992, Jones 1991, 1994, Standish Group 1994).
요구사항 변형은 프로젝트 취소를 일으키는 주요 원인이다.
- 요구사항 변형은 프로젝트 완료가 불가능할 정도로 제품을 발안정하게 할 수 있다(Jones 1994).
요구사항 변형을 통제해야 한다고 말하지만 더 제대로 알아야 할 입장에 처한 사람들이 오히려 그 필요성을 심각하게 받아들이지 않고 있다.
- '소프트웨어 프로젝트 재난'을 기술한 글에서 덴버 공항 수하물 처리 소프트웨어 예로, 2천만불을 주면서 요구사항을 추가한 탓에 한 달에 하루 110만불씩 손해를 봤다고 했다.
- 소프트웨어 프로젝트 지연 보고서에는 요구사항 변형이 소프트웨어를 다시 구현하게 만든 장본인이라는 단순한 원인을 모른다고 했다.
온 로케이션 개발에 월 스트리트 저널 보고서(Carroll 1990)는 다음과 같이 표현했다.
소프트웨어는 일정과 예산을 크게 초과했다. 사실상 출시는 거의 불가능하다. 게다가 원래 계획과는 완전히 동떨어졌다. 소프트웨어 개발 계획 수립은 대부분 엉망이다.
이 보고서에는 계획과 동떨어진 것과 일정과 예산을 크게 초과했다는 표현을 동시에 사용했다.
이 두 가지를 별도 문제로 취급해 엉망인 부분은 '계획 수립'이라고 결론을 내렸다.
이 기사를 쓴 저자와 기사에서 묘사한 개발팀 중 누구도 기능 변경과 소프트웨어 지연 사이의 연관성을 깨닫지 못하고 있다.
기능집합 관리는 개발 속력의 네 차원인 사람, 공정, 제품, 기술 중 제품 부분에 해당한다.
제품 부분에서 얼마나 개발 속력을 높일 수 있는지는 기능 집합 관리에 달려 있다.
일반적으로 기능 집합 관리는 세 종류로 나눈다.
- 프로젝트 초반 관리 - 프로젝트 일정과 예산 목표에 맞는 기능 집합 정의
- 프로젝트 중반 관리 - 요구사항 변형 통제
- 프로젝트 후반 관리 - 일정이나 비용 목표에 맞추기 위한 기능 삭제
이 세 가지 전부를 활용할 줄 아는 프로젝트가 성공한다.
보잉777 프로젝트는 일정에 맞게 끝냈고 성공한 이유는 하나는 수석 개발자가 후반의 긴급 변경을 제어할 필요성을 확실히 알고 있었기 때문이다(Wiener 1993).
그는 책상에 다음과 같은 문구를 붙였다.
14.1 프로젝트 초반: 기능 집합 축소
불필요한 기능을 처음부터 넣지 않는 데 초점을 맞춘다.
Inside RAD에서 커어와 헌터는 쾌속 개발 제 1 계명으로 '범위 축소' 라고 얘기한다 (Kerr and Hunter 1994).
이를 위한 기본적인 방법 세 가지는 아래와 같다.
- Minimal specification
- Requirements scrubbing
- Versioned development
최소 명세서
보통 자세히 작성하는게 좋다고 한다.
요구사항 명세서를 상세하게 작성하려고 하면 그렇지 않을 경우보다 요구사항을 더 많이 파악할 수 있다.
그러면 프로젝트 후반에 요구사항 추가로 생기는 비용과 시간 문제를 미리 피할 수 있다.
상세한 요구사항 명세서는 프로젝트 계획 수립과 감독에 근거로 사용할 수 있으며, 개발자가 설계와 구현을 잘 할 수 있는 든든한 기초가 된다.
전통적인 명세서의 단점
노력 낭비
시스템 특성을 사용자가 신경쓰지도 않을 부분까지 너무 상세하게 정의하느라 시간을 보낼 수 있다.
진부화
프로젝트 도중에 변경이 생기면 요구사항 문서는 금방 구식이 되어 버린다.
요구사항 문서 관리는 프로젝트 진행에 도움을 주기보다 의무적이거나 관료적인 업무로 변해 버린다.
효과 부족
시스템을 대단히 상세하게 정의한다고 해서 성공을 보장하지는 않는다.
과도한 설계 제약
지나친 명세서는 설계와 구현에서 시간을 낭비하게 만든다.
그림 14-1과 같은 3D 그룹 박스를 사용할 것을 지정한다.
Figure 14-1.A dialog box with the ideal group box
구현 시점에서 그림 14-2와 같은 3D 그룹 박스를 상용으로 판매해 구현하기 쉽다는 사실을 발견한다.
Figure 14-2.A dialog box with the quick-to-implement group box. Relaxingrequirements by a small amount can make a large difference in implementationtime if the change allows for better tool support.
두 그림의 유일한 차이점은 테두리 너비와 박스 내부 색깔이다.
이런 세부 사항을 개발자 재량에 맡겨도 된다면 그렇게 하는 편이 낫다.
최종 사용자가 처음 그룹 박스가 낫다는 의견을 얘기할 수도 있지만 비용이 동일하다는 가정하에 내린 선택일 가능성이 크다.
개발하는데 1주일이 더 걸린다는 사실을 알면 처음 그룹 박스를 선택할 사용자는 거의 없다.
전통적인 명세서를 작성하는 이유 중 일부는 실용성 때문에고, 일부는 후반 활동에서 비용 소모를 피할 목적이며, 일부는 초반부터 프로젝트 전부를 통제하겠다는 다소 비합리적인 욕심 때문이다.
최소 명세서 작성
- 짧은 논문 명세서 - 10페이지 이하
- 출발점 명세서 - 1회용. 비전 공유를 위한 용도
- 사용자 매뉴얼 - 소프트웨어를 매뉴얼에 맞게 개발. 어차피 매뉴얼을 작성해야 하므로 초반에 작성해 명세서 까지 만드는 중복 업무를 피한다.
- 사용자 인터페이스 프로토타입 - 그림 하나가 더 나은 효과를 줄 수도 있다.
- 문서형 스토리보드 - 고객이나 사용자가 소프트웨어를 머릿속에 그릴 능력이 있다면 이 방법이 쉽다.
- 비전 선언문 - 제품에 넣을 기능과 제외할 기능을 설명. 주요 목적인 제외할 기능을 명시하는 데 있다.
- 제품 주제 - 주제는 비전과 관련 있으며 기능 통제에 효과적인 수단이 된다.
최소 명세서로 성공하려면 요구사항에 상당한 융통성이 있어야만 한다.
보잉 777처럼 정확성이 필요한 프로젝트는 최소 명세서 사용이 적합하지 않다.
최소 명세서를 작성할 대는 고객이 기대할 바를 확인시킬 목적으로 이해각서나 그와 비슷한 내용을 작성할 수 있다.
최소 명세서의 장점
- 사기 향상과 동기 유발: 개발자들은 명세화 작업에 적극적으로 뛰어드는데 자신들이 정의하는 제품이 되기도 하고 성공에 필요한 일이면 뭐든 하기 때문이다
- 효율성: 가장 신속한 방법을 선택해 소프트웨어를 설계하고 구현할 자유가 생긴다.
- 노력 낭비 감소: 고객이 별로 신경쓰지 않는 내용까지 의견을 구하려는 낭비를 줄인다.
- 요구사항 정의 기간 단축
최소 명세서의 위험
핵심 요구사항 누락
고객에게 필요한 내용까지 제외할 위험이 있다.
애매하거나 불가능한 목표
애매한 목표에 대해 개발자들이 기준을 제시한다.
사용자 편의성, 최대 효과, 최소 개발 기간 중 기준을 명확하지 않으면 전통적인 명세서를 이용해 원하는 바를 상세히 기술하는 게 낫다.
기능 치장
개발자들은 최대한 우수한 제품을 만들고 싶어하기 때문에 제품 품질에 대한 욕구가 프로젝트 개발 속력 목표보다 앞설 수 있다.
새 분야에 대한 도전과 탐험은 쾌속 개발 프로젝트에는 적합하지 않다.
마이크로소프트 프로젝트 사후 분석에 따르면 팀원들이 새 기능을 추가하고 싶은 욕구를 자제하지 못할 때 심각한 일정 문제가 발생한다고 지적한다(Cusumano and Selby 1995).
기술 수석은 제품의 가시적인 측면을 엄격히 통제해야 한다.
상세한 사용자 인터페이스를 작성한 후 개발자들에게 프로토타입을 맞추는 한도 내에서 설계 자유를 준다.
개발자가 임의로 프로토타입에 없는 주요 기능을 추가하게 해서는 안 된다.
개발자 치장을 막는 두 번째 방법은 정기적인 설계 검토다.
이 작업을 통해 효율이 높은 최소 설계에 초점을 맞춘다.
팀에 최소 출시 기간이라는 목표를 공유하면 기능 치장하는 개발자들에게 압력을 줄 수 있다.
병렬 활동 지원 부족
전통적인 명세서는 사용자 문서와 테스트 케이스 작성을 동시에 할 수 있다.
최소 명세서는 가시적인 변화가 없는 시점을 중간 목표로 잡고 문서 작성과 테스트 케이스 작성을 해야 한다.
이 시점을 시각적인 동결이라고 부르며 문서 작성과 테스트 작성에 전체 일정을 지연하지 않도록 넉넉하게 잡아야 한다.
특정 기능에 대한 개발자 집착
최소 명세서 기법은 동기 유발 효과를 얻기도 하지만 개발자가 담당한 기능을 변경하는 데 어려움을 겪을 수 있다.
제품 변경 영향이 제품 자체에만 그치지 않는다는 걸 명심해야 한다.
잘못된 목적으로 최소 명세서 사용
요구사항 명세 활동 자체에 드는 시간을 줄일 목적으로 최소 명세서를 사용하면 안 된다.
그러면 엄청난 재작업에 시달리게 될 것이며 설계와 구현을 다시 해야 한다.
자신과 고객을 충분히 파악해야 한다.
고객이 개발자에게 어느 정도 방향만 제시하고 그 결과를 받아들일 자세가 되어 있는지를 판단하라.
통제권을 개발자에게 넘기기 불편하다면, 전통적인 명세서 기법이나 단계적인 출시 전략을 쓰는 편이 낫다.
최소 명세서 기법으로 성공하는 방법
요구사항에 융통성이 있는 경우에만 사용하라
어떤 쾌속 개발법이든지 성공으로 가는 열쇠는 융통성있는 초기 요구사항이라고 여러 사람들이 지적했다(Millington and Stapleton 1995).
명세서를 최소한으로 유지하라
세부사항 최소화가 목표이다.
구체적인 사항은 개발자의 몫으로 남겨야 한다.
사용자가 신경쓰는 기능인지 확실하지 않다면 제외하라!
중요한 요구사항을 잡아 내라
필요한 기능을 모두 찾아내도록 주의를 기울여야 한다.
우수한 최소 명세서를 작성하려면 사용자가 정말로 원하는 바를 민감하게 감지할 수 있어야 한다.
융통성있는 개발법을 사용하라
실수를 해도 정정할 수 있는 개발법을 사용하라.
융통성 있는 개발법은 낭비하는 시간보다 절약하는 시간이 더 크다는 가정에서 사용하는 것이다.
핵심 사용자들을 참여시켜라
비즈니스 요구와 조직 내 필요성을 이해하는 사람들을 찾아라.
그들을 제품 명세와 개발에 참여시켜 요구사항 누락과 같은 문제를 피한다.
그래픽 위주로 문서를 작성하라
도표, 출력 예제, 프로토타입과 같은 그래픽은 문서 명세서보다 작성하기 쉽고, 사용자에게 의미를 전달하는 데 더욱 효과적이다.
요구사항 가지치기
이 방법은 소프트웨어 일정을 단축하는 가장 확실한 방법이다.
기능 삭제는 요구사항 명세, 설계, 테스트, 문서화 등 그 기능과 관련있는 모든 활동을 함께 제거하기 때문이다.
요구사항 가지치기는 최소 명세서 기법보다 위험이 적다.
제품 크기와 복잡성을 줄이기 때문에 제품의 전반적인 위험 수준이 줄어든다.
Figure 14-3.Smaller projects take less time to build.
방법은 제품 명세서를 작성한 후, 다음 목적을 염두해 두고 명세서를 면밀하게 검토한다.
- 반드시 필요하지 않으면 제거한다.
- 필요 이상으로 복잡하면 단순화한다.
- 더 쉬운 방안이 있으면 대치한다.
최소 명세서와 마찬가지로 이 기법 역시 성공은 실행에 달려있다.
가지치기 했다가 나중에 복구하면 프로젝트 비용은 처음부터 하려고 했던 경우보다 훨씬 더 커진다.
개발 버전화
완벽하고 이상적인 프로젝트 요구사항 집합을 면밀히 계획한 다음에, 프로젝트를 여러 단계로 나누어서 구현한다.
다음 버전에서 개발할 준비는 하되 기능 자체를 구현하지는 않다.
발전적인 출시와 단계적인 출시와 같은 개발법이 도움이 된다.
14.2 프로젝트 중반: 기능 변형 통제
일반적으로 프로젝트는 개발 기간 동안 약 25% 정도 요구사항 변화를 겪는다(Boehm 1981, Jones 1994).
변경 원인
최종 사용자는 추가 기능이나 다른 기능을 바라기 때문에 또는 시스템을 만들어 가면서 이해도가 높아졌기 때문에 변경을 원한다.
영업부는 기능 위주로 시장을 보기 때문에 변경을 원한다. 새로운 기능을 포함한 신제품이 나오면 경쟁 제품에 필적하기를 원하므로 새 기능 추가를 요구한다.
개발자는 시스템 상세 부분까지 열정과 능력을 쏟았기 때문에 변경을 바란다. 수정이 필요하지 않은 경우에도 마찬가지다. 자신의 특별한 관심사에 맞는 업무라면 무엇이든 하려고 한다.
때로 사용자는 요구사항 검토 과정을 우회해서 개발자를 구슬려 원하는 기능을 넣기도 한다.
영업부는 나중에야 마케팅 사례를 만들어 원하는 기능을 추가하자고 우긴다.
개발자는 따로 시간을 내거나 상사가 신경쓰지 않을 때를 이용해 요구사항에 없는 기능을 구현한다.
프로젝트는 매달 1% 정도 요구사항이 변한다.
평균적으로, 프로젝트 기간이 길수록 변경은 많아 진다(Jones 1994).
킬러앱 증후군
출시 몇 주전 다른 회사 제품이 시장에 출시하게 되고 생각지도 못한 기능 몇 가지를 포함 다른 기능도 우월한 경우가 생긴다.
그래서 개발 그룹은 재설계를 통해 앞서 출시한 다른 회사 제품을 앞지르기 위해 일정을 몇 달 늦추기로 결정한다.
그러다가 또 다른 회사의 제품이 시장에 출시되고 기능 일부가 더 우월하면 다시 출시를 연기하게 된다.
애매하거나 불가능한 목표
"최소 비용으로 최단 시간 내에 세계적인 제품을 개발하고 싶습니다."
목표 전부를 달성하기가 불가능하고 목표 자체가 아매하기 때문에 어느 목표도 달성하지 못할 가능성이 높다.
개발자가 사소해보이는 사항을 어떻게 해석하는지에 따라 구현 시간의 차이를 만든다.
어떤 명세서도 사소한 세부사항까지 하나도 빠드리지 않았다고 장담할 수는 없다.
개발자가 구현시 고려할 수 있는 유연성 정도에는 대단한 차이가 있다.
일부 연구에서는 같은 명세서를 바탕으로 작성한 프로그램이 그 크기에서 10대 1까지 차이가 난다고 밝혔다(DeMorco and Lister 1989).
명세서에서 애매함에 부딪혔을 때 최고 개발 속력을 얻을 목적이라면, 빠르게 구현하는 선택지를 팀에게 분명히 말해야 한다.
다른 목표를 덧붙여 개발자들을 헷갈리게 해서는 안된다.
변경이 미치는 영향
- 설계, 구현, 테스트, 문서, 고객 지원, 교육, 환경 관리, 개인 업무 할당, 관리층과 직원 의사소통, 계획과 감독은 물론이거니와 일정, 예산, 제품 품질에 이르는 파급 효과를 과소평가하는 경향이 있다(Boehm 1989).
- 일반적으로 요구사항 수집 단계에서 드는 변경 비용은 구현이나 유지보수 단계보다 50배에서 200배가 적다(Boehm and Papaccio 1988).
- 명세서를 다시 작성해야 할 만큼 변경이 심했던 프로젝트는 그렇지 않은 프로젝트보다 생산성이 상당히 낮았다(Vosburghet al. 1984).
Figure 14-5.Findings for “Changes Require Specification to Be Rewritten” factor(Vosburgh et al. 1984). Controlling changes can produce dramatic improvementsin productivity, but that control does not by itself guarantee success.14.2 Mid-Project: Feature-Creep Control
그림 14-5에서 변경을 통제하는 경우, 평균 생산성과 최고 생산성은 높아졌다.
이 연구 결과는 변경을 통제하지 않고 높은 생산성을 이루기가 어렵다는 사실을 암시한다.
하지만 변경을 통제헤도 낮은 생산성을 보이는 프로젝트도 있기에 변경 통제만으로 높은 생산성을 보장할 수는 없다.
분별있는 변경 통제
융통성이 필요한데도 변경이 불가능하거나 바람직하지 않다고 밀어붙이게 되면, 프로젝트는 통제력을 잃게 된다.
변경을 무조건 막으려는 시도가 현명하지 못한 상황을 몇 가지 소개한다.
고객이 스스로 원하는 바를 알지 못할 때
소프트웨어 개발자는 업무 일부로 고객이 스스로 원하는 바를 깨닫도록 도와야 한다.
고객은 돌아가는 소프트웨어를 보고 나서야 원하는 바를 깨닫게 되므로 이런 상황에 대처하기 위해 여러 가지 발전적인 개발법을 사용할 수 있다.
고객 요청에 적절히 응하고 싶을 때
요구사항 동결 이후 제품은 제시간에 출시할수는 있어도 고객 요구를 무시한다는 인상을 줄 수 있다.
이는 출시 지연만큼 바람직하지 못하다.
개발자 경쟁력 유지를 위해서라도 융통성을 발휘할 필요가 있다.
특히 사내 개발 조직은 사용자 요구를 무시하기 쉽다.
독점 계약을 맺은 셈이므로, 사용자를 진짜 고객으로 여기지 않는다.
시간이 지나면서 마찰이 생기고, 개발자들은 사용자의 추가 요구를 막기 위해 요구사항 명세서를 무기처럼 휘두른다.
이런 행동을 보이는 개발자들은 결국 계약이 생각만큼 독점적이지 않다는 사실을 깨닫게 된다(Yourdon 1992).
시장이 급속하게 변할 때
오늘날 가장 성공적인 소프트웨어는 대개 개발 마지막 단계에서 가장 많은 변경을 소화해낸 제품이다.
오늘날 소프트웨어 개발자의 임무는 요구사항 변경을 없애려는 기계적인 노력이 아니라, 혼돈과 경직성 사이에서 중용을 택하려는 노력이다.
우선순위가 낮은 변경은 거부하고, 시장 변화에 신중히 반응하는 변경은 받아들일 수 있어야 한다.
개발자에게 자유를 주고 싶을 때
제품 개념 일부를 개발자 재량에 맡길 생각이라면 요구사항 명세서 완성과 동시에 제품 개념을 동결해서는 안된다.
적어도 개발자가 해석할 여지는 남겨 놓아야 한다.
안정적인 요구사항
쾌속 개발 관점에서 보면, 불안정한 요구사항을 안정적이라고 간주하는 실수가 가장 위험하다.
불안정한 요구사항을 보완하기 위해 조취를 취해야 한다.
변경 통제 방법
어떤 변경 관리 계획을 세우든지 간에 다음을 목표로 삼아야 한다.
- 가능한 시간 안에 최고 제품을 만드는 데 도움을 주는 변경만을 허용하라. 기타 변경은 금지하라.
- 변경으로 영향을 받는 관련자 전부와 일정, 자원, 제품에 미치는 영향을 진단하라.
- 프로젝트 관리자에게 변경 내용, 파급 효과, 승인 여부를 통보하라.
- 제품을 변경하는 결정에 대해 감사 기록을 제공하라.
이런 목적을 달성하기 위한 몇 가지 방안을 제시한다.