도구와 함께 Rational Unified Process를 구성하는 새 개발 환경 구현에 사용되는 일부 주요 사례는 다음과 같습니다.
프로젝트 및 조직 평가
프로젝트와 조직의 현재 상태를 평가하여 개선해야 하는 환경 부분을 제대로 이해할 수 있도록 합니다. 환경 구현 방법도 제대로 이해하게 됩니다.
다음 페이지는 프로젝트와 프로젝트 조직의 상태를 평가하는 방법을 설명합니다.
점진적으로 프로세스 및 도구 구현
환경, 프로세스 및 도구를 점진적으로 구현하므로 프로젝트의 인원이 많은 새 요인들을 모두 한 번에 감당하지 않아도 됩니다. 환경을 점진적으로 구현하면 성공 가능성을 높이는 환경 서브세트에 초점을 맞출 수
있습니다.
한 번에 하나씩 환경을 도입하십시오. 개발 조직 평가 결과는 도입을 시작해야 하는 도구와 프로세스의 부분을 결정하는 데 도움이 됩니다. 보통 개발 조직이 가장 큰 문제점을 가지고 있는 영역에 초점을 맞추십시오.
환경을 점진적으로 구현한다는 것은 첫 번째 또는 도입/인식(Inception), 반복에서 요구사항 도구와 함께 요구사항 원칙을 도입하는 데 초점을 맞춘다는 것을 의미할 수 있습니다. 두 번째 반복에서는 초점이
모델링 도구와 함께 분석 및 디자인 원칙을 도입하는 데 있습니다. 후속 반복에서는 한층 많은 환경 부분이 도입됩니다.
세부사항은 개념: 프로젝트에서 프로세스 구현을 참조하십시오.
관리 및 계획
소프트웨어 개발 프로젝트의 다른 모든 타스크에서와 같이 환경 타스크를 관리하고 계획합니다.
프로젝트에서 새 프로세스와 새 도구를 구현하는 것은 복잡한 타스크입니다. 인원이 작업하는 방식을 변경하면 프로젝트 성공에 해가 될 수 있습니다. 경험상 개발 타스크와 비교해 볼 때 환경 타스크는 간혹 프로젝트
관리자가 대출 훑어봅니다.
환경 타스크는 소프트웨어 개발 프로젝트의 다른 모든 타스크와 같이 관리 및 계획해야 합니다. 따라서 프로젝트 관리자는 새 프로세스와 도구를 제대로 이해해야 합니다. 간혹 프로젝트 관리자가 필요한 시간을 할당하여 새
프로세스와 몇몇 새 도구에 대해 학습하는 것이 어렵습니다. 이와 같은 경우, 프로젝트 관리자는 환경을 구현하는 방법과 이전에 환경 구현에 참여했던 인원을 아는 누군가의 지원을 받아야 합니다. 프로젝트 관리자가
올바른 스킬과 경험을 가지고 있어도 "환경 구현 전문가"를 포함시킬 것을 권장합니다. 프로젝트가 성공될 기회가 점점 증가하기 때문입니다.
환경 타스크를 포함하여 소프트웨어 개발 프로젝트를 관리하는 계획하는 방법에 대한 세부사항은 프로젝트 관리 원칙을 참조하십시오. 개념: 프로젝트에서 프로세스 구현도 참조하십시오.
프로젝트에 새 프로세스를 도입하려면 조언자를 사용하십시오. 경험상 새 프로세스 구현에 성공하려면 조언자 사용이 중요합니다. 조언자가 없을 경우 프로젝트의 인원이 예전의 습관에 빠지게 될 가능성이 높습니다.
조언자는 변경 추진자 역할을 합니다.
프로젝트에는 프로젝트에 관한 조언을 위한 자원 및 예산이 필요합니다. 워크샵 리드와 같은 일부 조언 활동의 발생을 계획해야 합니다. 프로세스 조언자는 변경 추진자 역할의 중요성을 이해하고 작업 진행상태를 확인해야
합니다. 또한 조언자는 없어도 되는 존재가 되어 역할이 끝나야 합니다. 따라서 조언자는 지식과 책임 모두를 프로젝트 구성원에게 전달해야 합니다. 조언자의 개념과 조언자 역할에 대한 세부사항은 개념: 조언을 참조하십시오.
프로세스 소유권 분배
프로젝트의 인원 사이에 프로세스의 소유 권한을 분배하십시오. 인원들은 새 프로세스를 더 빠르게 채택하고 학습해야 하기 때문입니다. 결과로 생성되는 개발 사례는 프로젝트의 인원인 "실제 전문가" 스스로 개발할 경우에
더 낫습니다. 프로세스의 소유권을 분배하면 프로젝트가 외부 컨설턴트에게 너무 의존할 가능성도 줄어듭니다.
가능하면 바로 각각의 핵심 프로세스 원칙의 책임을 맡을 프로젝트 인원을 지명하십시오. 이 인원은 프로세스의 부분과 개발 사례의 해당 부분을 구성하는 1차 책임을 가지고 있습니다. 예를 들어, 요구사항과 같은 핵심
프로세스 원칙에 대한 책임을 맡는 것은 개발 사례의 해당 부분에 대한 책임을 맡는 것입니다. 각 인원은 하나 또는 몇 가지의 핵심 프로세스 원칙에 대한 책임을 맡아야 하며 영역이 제대로 되어 있는지 알고 다른
개발자에게 조언할 수 있는 사람입니다.
프로세스 엔지니어는 프로세스의 다른 부분을 소유하는 프로젝트 인원에 대해 조언자 역할을 하고 프로세스를 구성할 때 그 인원을 보조합니다.
'투자 수익률' 고려
프로세스를 구성할 때 '투자 수익률'을 고려하십시오. 투자보다 많은 금액이 회수될 대상에 초점을 맞추도록 하십시오.
경험상 일부 프로젝트는 광범위한 가이드라인, 광범위한 개발 사례 및 추가 프로세스 관련 자료를 개발하는 데 너무 많은 시간과 자원을 소모하는 경향이 있습니다. 여기에는 다음과 세 가지의 주요 문제점이 있습니다.
-
인원들은 포괄적인 설명을 읽지 않습니다.
-
처음부터 모든 내용을 바로 수행하는 것은 어렵습니다. 어떤 내용은 부분적으로 테스트한 후 조정하는 것이 좋습니다.
-
조언에 집중하지 못합니다. 프로세스 지식이 있는 인원에게는 포괄적인 설명 작성 대신 조언을 1차 타스크로 지정해야 합니다.
가이드라인을 개발할 때 투자 수익률을 염두해야 합니다. 기존 가이드라인을 다시 사용하십시오. 예를 들어, 완전한 유스 케이스 모델링 가이드라인을 개발하기 위한 비용상 효율적인 대안은 기존 유스 케이스 설명의 좋은
예를 유스 케이스 모델링 가이드라인으로 제공하는 것입니다.
사실상, 투자 및 회수 금액을 측정하고 비교할 수 없습니다. 프로세스 엔지니어로서, 항상 염두해야 할 가장 중요한 것은 무엇을 수행하든지 개발자에게 많은 금액을 회수해야 한다는 것입니다.
인원에게 정보 제공 및 참여 유지 유지
새 프로세스와 도구에 대한 정보를 제공하는 인원을 유지하고 작업에 참여하도록 해야 합니다. 변경 시 조직에서 가장 문제가 되는 것은 변경에 대한 인원들의 태도입니다. 조직에 새 프로세스와 도구를 도입하는 것은
인원들이 작업하는 방법을 변경해야 함을 의미합니다. 인원들은 변경에 대한 자연적인 저항을 가지고 있습니다. 항상 악순환에 빠질 위험성이 있습니다. 즉, 인원들의 부정적인 태도는 나쁜 결과를 가져오며 이는 다시 더
부정적인 태도를 가져옵니다.
다음은 조직의 인원들 사이에 부정적인 태도가 형성되지 않도록 하는 데 도움이 될 수 있는 조치를 나열한 것입니다.
-
실제적 예외를 설정합니다. 새 프로세스와 새 도구를 실제보다 높게 평가하지 마십시오.
-
주요 인원을 변경 작업에 투입합니다. 그 인원이 파일럿 프로젝트의 일부가 되도록 하고 프로세스 파트의 책임을 부여하십시오. 프로세스 소유권 분배를 참조하십시오.
-
변경을 수행해야 하는 이유를 설명합니다. 조직에 해결해야 할 어떤 문제점이 있는지, 기술에서 어떤 변경으로 새 프로세스와 새 도구가 필요한지, 새 도구와 프로세스를 사용할 경우 어떤 이점을 얻는지
설명합니다.
-
조직의 모든 인원에게 발생할 사항에 대해 알립니다. 예를 들어, 모든 부서에 진행 사항에 대해 알립니다. 이 정보는 아주 세부적일 필요는 없습니다. 중요한 것은 어떤 정보를 받는다는
것입니다.
-
고객 또는 후원자와 같은 이해 당사자(stakeholder)를 기억하십시오. 예를 들어, 폭포수형과 유사한 개발 접근 방식에서 반복적 개발 접근 방식으로 변경할 경우, 이해 당사자는 반복 개발 프로젝트의
관리 방법과 진행상태 측정 방법을 이해해야 합니다. 예를 들어, 반복적 개발 프로젝트에서는 초기 이정표에서 완전히 고정된 디자인을 기대할 수 없습니다. 이해 당사자는 또한 프로젝트에서 요구사항을 캡처하는
방식이 변경될 때 영향을 받습니다.
새 프로세스와 새 도구에 대해 인원들을 교육합니다. 인원들은 새 프로세스와 새 도구의 사용 방법을 알아야 하기 때문입니다.
지금까지 사용했던 다음과 같은 방법을 포함하여 몇 가지 방법으로 인원을 교육합니다.
-
표준 훈련 과정
-
1 - 5주간 집중적으로 실제 훈련을 하는 "훈련 캠프". 많은 조직에서 훈련 캠프를 실시할 수 있는 것은 아니지만 프로젝트의 인원들에 대해 새로운 요소가 많을 경우에는 효율적입니다.
-
조언은 결과를 검토하고 워크샵을 이끌며 질문에 응답하는 조언자가 있을 경우에 가능합니다. 잘만 하면 조언을 제공하는 것이 지식을 이전할 수 있는 아주 효율적인 방법이 될 수 있습니다.
-
"시작(kick-start)" 워크샵은 환경의 새 파트가 도입될 때 하루만에 인원들에게 예비 지식을 줄 수 있는 효율적인 방법입니다. 이 유형의 워크샵에서는 인원이 실제 프로젝트 자료를 사용하며 새
템플리트, 가이드라인 및 도구를 사용하여 새 개발 사례 파트를 따라 학습합니다. 일반적으로, 프로세스 엔지니어와 도구 전문가가 이 워크샵의 책임을 맡습니다. 시작(kick-start) 워크샵을 위한 훈련
자료 개발에 많은 시간을 소비하지 않도록 하십시오. 기본 목적은 템플리트, 가이드라인 및 도구와 함께 개발 사례의 새 구역을 사용해 보는 실제 경험을 제공하는 것입니다. 시작(kick-start) 워크샵은
또한 개발 사례, 템플리트, 가이드라인 및 도구를 확인하는 방법이기도 합니다.
|