가이드라인: 프로세스 조정 절차
주제
RUP에서 다수의 결과물, 활동 및 역할을 분류하면서 다음 질문으로 자문할 수 있습니다.
- 이 항목이 필요합니까?
- 어떻게 이러한 모든 항목을 분류하여 해당 프로젝트에 필요한 항목을 판별할 수 있습니까?
- RUP는 대형 프로젝트 전용이다라는 것이 분명하지 않습니까?
조정에 관한 주제에서 이러한 모든 질문을 해결주게 됩니다.
소프트웨어 프로젝트의 목적은 제품을 만들어 내는 것입니다. 적합한 프로세스를 사용하면
스테이크홀더의 요구를 충족시키는 제품을 예산 범위 내에서 적기에 만들어 낼 수 있습니다.
베스트 프랙티스 접근 방법에 따라
가능한 한 간단하게 프로세스를 조정하는 것이 핵심입니다.
프로세스 조정을 위해 여기에 포함된 가이드라인을 고려해야 합니다. 자세한 가이드라인은
개념: RUP 조정 및 활동:
프로젝트의 프로세스 조정에서 제공합니다.
다수의 프로젝트에서 공통적인 문제는 흔히 한 특정 영역의 세부사항까지 지나치게 집중하고 나서야 고급 제품 생산의 전체 프로세스 라이프사이클과 관련되는 "핵심" 요소를 확실히 이해하고 있다고 확신한다는 것입니다.
일반적으로 어느 한 특정 문제 영역에 지나치게 집중하기 전에 프로세스의 모든 핵심 요소를 가벼운 방식으로
처리하는 것이 좋습니다.
일단 고급 소프트웨어 프로세스의 프레임워크가 적절하면 프로젝트에서 해당 문제점에 대한 주요 원인으로 식별된
특정 영역에 집중하는 것이 효과적일 수 있습니다. 이러한 선택은 해당 프로젝트의 위험을 식별하고
우선순위를 지정하며 식별된 위험의 초기 완화 전략에 기반하여 이루어집니다.
명확하게 정당화할 수 없는 활동 및 결과물을 포함하지 않음
선의의 프로젝트 관리자 또는 프로세스 엔지니어는 적절한 메트릭, 제어, 보고서 등에 대한 다량의
희망 목록을 가지고 있을 수도 있습니다. 그러나 활동과 결과물에는 시간과 비용이 소요됩니다. 이러한 시간과 비용
소모 중 일부는 환경 툴 세트와 일상적인 상호 작용과 같이 가시화되거나 가시화되지 않을 수 있지만 표준 타스크에
대한 낮은 생산성으로 묻혀 버릴 수 있습니다.
중대한 프로세스 요구와 희망 목록을 구별하여 장점이 이 시간과 비용의 소모를 보충하고도 남는지 판별해야 합니다.
프로세스로부터 개발자 보호
설계, 구현 및 테스트에서 가치있는 기술을 갖춘 고도로 훈련된 인력(스탭)을 보유하고 있을
가능성이 있습니다. 이러한 인력이 양식 기입, 문서화 개선 또는 다루기 힘든 툴을 사용하려고 매주 여러 시간을
소모하지 않도록 하십시오. 이러한 활동이 필요한 경우 자격을 갖춘 지원 스탭이 해당 활동을 처리하는 것을
고려하십시오.
공식적 중간 결과물 최소화
최종 제품에 의도되지 않은 결과물인 중간 결과물의 형식은 이 결과물 생성에 필요한 활동과 생각만큼
중요하지는 않습니다. 만약 해당 목적에 맞게 사용되면 중간 결과물의 모양 또는 빌드에 사용하는 툴은
문제가 되지 않습니다. Dwight D. Eisenhower가 말한 대로 "계획보다는 계획 수립이 더 중요합니다."
빠지기 쉬운 함정으로 너무나 신속한 결과물의 공식화가 있습니다. 초기 버전의 결과물은 종종 신속히
전개하여 함축되는 내용이 탐색되면서 다양한 표현으로 한 동안 유동적인 상태를 유지합니다. 공식적인 문서화는
이 프로세스를 지체시키며 다량으로 소비가 가능한 결과물을 다듬는 데 많은 시간을
낭비할 수 있습니다. 수작업 다이어그램과 색인 카드에 있는 간단한 설명은 종종 결과물의 초기 단계에서
충분하지만 일부 프로젝트에서는 반드시 필요한 것일 수 있습니다.
결과물은 어떤 형식으로도 유지되도록 조정할 수 있습니다. 예를 들어, 비전 문서는 웹 페이지로,
프로젝트 계획은 Microsoft Project 파일로, 위험 목록은 Rational RequisitePro 요구사항 유형으로 캡처할 수 있습니다.
가능할 때 생성
일부 프로젝트는 정보를 직접 잘라내거나 붙여넣으면서 공식 문서의 템플리트를 이식시키는
데 많은 시간을 소모합니다. 그 대신에 Rational SoDA과 같은 툴을 사용하여 소스로부터 필요한
문서를 생성하도록 고려하거나 Rational Rose Publisher를 사용하여 웹 기반 설계 모델을 생성하는 것과
같이 간단한 방법으로 동일한 정보를 제공하는 것에 대해 협의하십시오.
다수의 경우 해당 환경에서 정보를 암시적으로 제공하기 때문에 결과물을 완전히 건너뛸 수 있습니다. 예를 들어,
요구사항 유형의 속성을 나열하는 요구사항 관리 계획의 섹션을 생성하는 대신, 적용할 수 있는 요구사항 유형과
추적성으로 조정된 Rational RequisitePro 프로젝트를 제공한 다음 관심이 있는 상대방과 함께 이 프로젝트를 다루도록
할 수만 있습니다. 또다른 예로 그래픽을 별도의 소프트웨어 개발 계획에 복제하는 대신 관심이
있는 상대방에게 읽기 전용 버전의 Microsoft Project 파일을 제공합니다.
웹 사용
유용한 결과물을 통해 가치있는 정보를 전달할 수 있습니다. 이러한 정보는
필요한 당사자가 쉽게 이용할 수 있어야 합니다. 웹 기술은 이러한 목적에 맞는 탁월한
메커니즘입니다. 웹에서 요구사항, 설계 및 구현을 사용할 수 있으면 빠르게 쇠퇴하고 있는
다량의 종이 문서 세트를 생성할 필요가 전혀 없습니다.
통합 툴 사용
프로세스에 적합한 툴을 선택하고 툴에 맞도록 프로세스를 조정하십시오. 원하는 결과는
사용하기 쉬운 프로세스와 툴 세트입니다. 일반적으로 통합 툴은 통합되지 않은 툴보다 많은 상황, 그리고 유익한 메트릭과 보고서를 제공합니다.
프로세스를 정기적으로 재방문하여 해당 복잡도를 개선하고 낮추십시오. 프로세스의 각 단계에서
일반 제품에 부가가치를 제공한다는 것을 스탭에게 확신시키지 못하는 경우 아마 해당 프로세스가 중단되어
있을 것입니다.
베스트 프랙티스를 보유하면서 조정
RUP는 조정 기능을 촉진시킵니다. 그러나 조정은 프로세스를 완전히 생략할 수 있는
라이센스가 아닙니다. RUP의 본질적 요소는 베스트 프랙티스에서 구현됩니다. 요구사항에 적합하도록
활동과 결과물을 조정할 경우 이러한 베스트 프랙티스의 진의에 따르십시오.
|