타스크: 개발 프로세스 시작
이 타스크는 개발 프로세스를 프로젝트 팀으로 롤아웃하는 방법을 설명합니다.
원칙: 환경
목적

이 타스크의 목적은 다음과 같습니다.

  • 프로젝트 구성원이 제대로 프로세스에 참여하도록 합니다.
  • 프로세스의 모든 피드백을 얻고 필요한 대로 프로세스를 정제합니다.
관계
역할기본 수행자: 추가 수행자:
입력필수: 선택사항:
출력
프로세스 사용법
기본 설명

개발 프로세스는 변경에 집중하여 프로젝트 라이프사이클 중에 개발 프로세스의 모든 중요한 갱신사항에 대해 다시 실행되어야 합니다.

이 타스크는 개발 프로세스의 롤아웃 뿐만 아니라 프로세스를 수행할 때 모든 기존 도구를 사용하는 방법에 대해 프로젝트 팀을 교육합니다.

단계
변경 공개

모든 프로젝트 구성원에게 사용자 조정된 개발 프로세스에 대한 모든 중요한 갱신사항에 대해 알리십시오. 프로젝트에 프로젝트 웹 사이트가 있는 경우 프로젝트 구성원에게 알리는 외에 해당 사이트에 변경을 게시해야 합니다. 

구성된 프로세스의 프로세스 웹 사이트는 일반적으로 모든 프로젝트 구성원이 액세스할 수 있는 웹 서버의 위치에 공개됩니다. 또는 웹 사이트를 프로젝트 구성원의 로컬 하드 드라이브에 복사할 수 있습니다.

프로젝트 구성원 교육

변경이 사소한 경우가 아니면 모든 가이드라인, 템플리트 및/또는 도구를 포함하여 새 개발 프로세스에 대해 프로젝트 구성원을 교육시켜야 합니다. 이는 프로젝트의 크기 및 비슷한 개발 프로세스에 대한 프로젝트 구성원의 숙지 정도에 따라서 비공식적인 2시간짜리 프리젠테이션이 될 수도 있고 보다 정규 훈련이 될 수도 있습니다.

다음은 프로젝트 구성원을 교육하기 위해 공통적으로 사용되는 방법입니다.

  • 세미나.
    변경이 작거나 이해하기 쉬운 경우 프로세스 엔지니어가 세미나에서 새로운 내용을 제시하는 경우 허용 가능합니다. 이 유형의 세미나는 대개 1 - 3시간이 걸립니다. 이것이 보통 반복을 위해 프로세스를 다시 실행할 때 최종 실행의 변경이 사소할 때 선호되는 선택사항입니다.
  • "시작(kick-start)" 워크샵.
    모든 프로젝트 구성원에 대해 하루의 워크샵을 준비하십시오. 여기에서 새 개발 프로세스를 따르고 도구를 사용합니다. 그런 워크샵을 준비하는 방법에 대한 세부사항은 지원 자료: 개발 프로세스 워크샵을 참조하십시오. "시작(kick-start)" 워크샵은 참가자가 관련 표준 훈련 과정을 이수했다고 가정함을 유의하십시오. 항상 워크샵 비용을 프로젝트에 대한 예상 가치에 대해 고려하십시오.
  • 사용자 정의된 훈련 과정.
    프로젝트 구성원이 프로세스 및 도구의 표준 훈련 과정에 참가하지 않은 경우 대안은 표준 훈련 과정을 사용자 정의하여 가이드라인, 템플리트 및 도구를 포함한 프로젝트의 개발 프로세스를 포함하는 것입니다. 그러나 훈련 과정을 사용자 정의하는 비용이 클 수 있습니다. Rational Unified Process™에 대한 소개 과정 같은 일반 프로세스 훈련이 프로젝트 시작 전이나 프로젝트의 초기에 수행되어야 합니다. 기법, 방법 또는 기술에 있어서 보다 특수한 훈련은 보통 "적시에"에 수행됩니다. 이는 새로운 지식을 바로 사용할 수 있도록, 방법이나 기법이 프로젝트에 적용되기 직전에 훈련이 제공됨을 의미합니다.
  • "훈련 캠프".
    1 - 5주의 집중된 실제 훈련입니다. 많은 조직이 이런 종류의 훈련 캠프를 제공할 수 있는 것은 아니지만, 프로젝트의 인원에 대해 많은 새로운 요소가 있는 경우에 효율적인 것으로 증명되었습니다. 훈련 캠프는 일반적으로 세미나, 훈련 과정 및 프로세스 및 도구를 갖는 실제 작업의 혼합입니다.
피드백 수집

새로운 자료를 제시하고 프로젝트 구성원을 교육하는 동안 피드백을 받아 개발자 프로세스 및/또는 도구에서 결함을 발견할 수 있습니다. 적합한 경우 변경 요청을 생성하십시오. 일부 변경은 프로젝트 범위 밖에서, 예를 들어 조직 전반의 개발 프로세스에 책임이 있는 프로세스 그룹에 의해 다루어져야 할 수 있습니다. 프로젝트가 프로세스를 사용자 조정하기 위해 선택한 방법에 대해 다른 문제가 발생할 수 있으며 프로세스의 다음 내부 릴리스를 위해 문제점에 대한 해결책이 고려되어야 합니다.

종종 프로젝트 구성원이 "진의를 파악"할 수 있도록 프로세스 실행을 따르는 것이 유용합니다. 많은 사람들은 프리젠테이션 중에, 특히 내부 및 외부의 많은 사람이 존재할 때 해명을 요청하는 것을 어렵다고 인식합니다. 많은 프로젝트에서 프로세스 엔지니어의 책임에는 프로젝트 구성원이 프로세스에서 설명하는 기법을 적용하는 데 도움이 되도록 프로세스에 대한 조언을 수행하는 것도 포함됩니다. 이 작업의 결과는 종종 일반적으로는 실행 중에 캡처하지 않는 피드백입니다. 자세한 정보는 개념: 조언 을 참조하십시오.

핵심 고려사항

프로세스 엔지니어는 프로젝트 관리자와 함께 작업하여 프로젝트에 특정한 개발 프로세스를 공용으로 만들고 프로젝트 구성원을 교육시키는 방법을 결정해야 합니다.

자세한 정보
개념