목적
-
프로세스 엔지니어가 프로젝트 이해 당사자를 만납니다.
-
프로젝트 이해 당사자의 포괄적인 문제점 목록을 수집합니다.
-
워크샵에 참여한 이해 당사자에 따라 수집한 문제점의 우선순위를 결정합니다.
|
가이드라인:
|
평가 워크샵은 모든 이해 당사자가 한 자리에 모여 주제를 집중적으로 논의하는 모임입니다. 보통 평가 워크샵은 반나절 또는 하루 동안 운영됩니다.
프로세스 엔지니어는 프로세스를 구현할 때 사용할 접근 방식에 대한 프리젠테이션을 준비합니다. 이 프리젠테이션은 참석자의 배경에 따라 1 - 3시간이 걸립니다.
개발 조직의 대표에게 현재 개발 조직이 수행하는 작업에 대한 프리젠테이션을 준비하도록 요청하십시오. 프리젠테이션은 1시간 정도여야 하고 조직 구조, 인원 수, 인원의 역량 및 경험, 비즈니스 목적과 목표 및
일반적인 프로젝트에 대한 간략한 설명과 같은 영역을 다루어야 합니다. 또한 프리젠테이션에서는 조직에서 프로세스 및 도구를 변경한 결정 이면의 기본적인 이유(예: 문제점 비즈니스 환경 변화 등)를 논의해야 합니다.
참고: 평가 워크샵은 조직에 대한 정보를 수집하는 다양한 방법 중 하나일 뿐입니다. 정보 수집 시 다른 방법으로 보충해야 합니다.
참석해야 하는 사람
프로세스 엔지니어는 진행자(facilitator) 역할을 수행해야 합니다. 보통 진행자는 개발 조직에 속하지 않는 것이 좋습니다. 새로운 관점으로 기본적인 문제점을 도출하는 자극적인 질문을 하려면 외부인이어야 할
수 있습니다. 소프트웨어 개발 프로세스 변경은 종종 정치적인 부담을 가지므로 진행자는 모든 관계자에게 존중되며 정당하고 공정하다고 평가되어야 합니다.
참가자 수는 진행자를 포함하여 3 - 8명입니다. 평가 워크샵은 가능한 현재 상태를 정확히 보여줄 수 있도록 조직 내 여러 다른 영역의 대표자를 포함합니다. 다음과 같이 가능한 많은 영역을 다루도록 적절히 인원을
조합하여 초대하십시오.
-
프로젝트 관리자
-
소프트웨어 설계자
-
숙련된 분석가
-
숙련된 개발자
-
숙련된 테스터
-
개발 부서 관리자
소프트웨어 엔지니어링 프로세스가 변경되면 소프트웨어 개발 조직에 있는 많은 인원들이 영향을 받으므로 많은 인원이 개입할 수 있습니다. 이 경우 참가를 통해 지원을 받을 수도 있으므로 몇 가지 장점이 있습니다.
그러나 워크샵에 더 많은 인원을 포함시키려는 태도는 권장되지 않습니다. 인원 수가 늘어나면 워크샵 관리가 어려워지거나 불가능할 수도 있습니다. 대안으로 각 팀에서 워크샵에 참가할 대표자를 선출하는 방법을 고려하거나
각 팀에서 하나씩 여러 워크샵을 운영하십시오. 워크샵의 목적은 결정을 내리는 것이 아니라 정보를 모으는 것입니다. 참가자의 관심사항이 적절히 제시되면 프로세스에 협조하게 됩니다.
진행자는 참가해야 하는 인원에게 워크샵을 홍보해야 하며, 워크샵에 참가할 그룹을 설정해야 합니다. 도착하기 전에 검토할 준비 자료를 참가자에게 제공하십시오. 특히, 프로세스 엔지니어는 더 잘 준비해야 합니다. 준비
자료에는 각 참가자가 검토해야 하는 워크샵의 범위 및 목적을 커뮤니케이션하는 워크샵의 의사 일정이 있어야 합니다. 이렇게 하면 워크샵을 시작하기 전에 가능한 문제 또는 잘 모르는 의사 일정을 식별할 수 있습니다.
진행자 또는 프로세스 엔지니어는 기존 프로세스에 대한 설명 및 개발 조직에 대한 설명과 같은 자료를 볼 수 있어야 합니다.
진행자는 워크샵을 운영하면서 다음을 수행합니다.
-
모든 사람에게 발언권을 줍니다. 정당하고 공정한 워크샵이 되기 위한 핵심 사항입니다.
-
세션의 진행을 관리합니다. 워크샵 유형은 불평을 위한 세션으로 변하는 경우가 많습니다. 문제점을 식별하되, 너무 이에 집중하지는 마십시오. 하나의 문제점이 식별되면 다음으로 진행하십시오.
-
의견을 수집합니다.
-
결과를 수집합니다.
-
세션을 요약하고 결론을 이끌어냅니다.
평가 워크샵의 일반 의사 일정은 다음을 포함합니다.
-
선임 대표자 중 한 명이 개발 조직의 프리젠테이션을 수행합니다.
-
프로세스 엔지니어가 평가 접근 방식에 대한 프리젠테이션을 수행합니다.
-
문제점 영역을 식별합니다. 브레인스토밍 세션을 운영하여 개발 조직에서의 모든 문제점을 식별합니다. 브레인스토밍 세션 운영 방법은 가이드라인: 브레인스토밍 및 아이디어 정리를 참조하십시오. 개발 조직의 모든 파트를 다루어야 합니다.
-
문제점 영역의 등급을 정합니다. 문제점 영역 사이에서 등급의 순서를 지정합니다. 파레토
다이어그램 사용을 고려하십시오.
-
문제점의 근본 원인을 식별합니다. 피시본
다이어그램이 이 작업에 도움이 될 수 있습니다. 평가 워크샵의 기본 초점은 눈에 보이는 문제점을 밝히는 것이므로 근본 원인을 식별하는 데 너무 많은 시간을 소비하지 않도록 주의하십시오. 프로세스
엔지니어는 계속 정보를 수집하고 나중에 분석하는 작업을 통해 근본 원인을 밝히게 됩니다.
-
문제점을 요약합니다. 진행자가 회의 및 결과물을 요약합니다. 참가자에게 동의 여부를 묻거나 추가 또는 철회할 기회를 줍니다.
-
문제점을 더 조사할 수 있는 2, 3개의 프로젝트를 식별합니다.
-
평가 시 인터뷰할 인원을 식별합니다.
-
나머지 평가 타스크의 스케줄의 아웃라인을 정합니다. 가능한 경우 인터뷰 및 향후 워크샵 날짜를 정합니다.
커뮤니케이션 촉진
평가 워크샵은 인원들 사이의 커뮤니케이션을 다룹니다. 서로를 더 쉽게 이해하려면 소프트웨어 개발 프로세스에 대한 공통된 이해가 필요합니다. 개발 조직이 Rational Unified Process(RUP)에 대한
지식이 있는 경우 해당 원칙을 로드맵으로 사용하여 개발 프로세스의 다른 모든 영역을 다룰 수 있습니다. 그러나 이미 조직에서 다른 프로세스를 사용하고 있고 참가자가 RUP에 대한 충분한 지식이 없는 경우, 프로세스
엔지니어는 평가 워크샵 및 인터뷰 동안의 프레임워크로 고객의 개발 프로세스를 사용하는 것이 좋습니다. 그러면 참가자가 서로의 의견을 더 쉽게 표현할 수 있으며 워크샵 도중 참가자에게 RUP를 가르치는 데 시간을
소비하지 않아도 됩니다.
다른 개발 프로세스 모델에 대한 예로 ISO/IEC 12207 표준이 있습니다. 이 예는 활동으로 설명되며 다음 섹션과 같이 구성됩니다.
-
프로세스 구현
-
시스템 요구사항 분석
-
시스템 아키텍처 디자인
-
소프트웨어 요구사항 분석
-
소프트웨어 아키텍처 디자인
-
자세한 소프트웨어 디자인
-
소프트웨어 코드 및 테스트
-
소프트웨어 통합
-
소프트웨어 규정 테스트
-
시스템 통합
-
시스템 규정 테스트
-
소프트웨어 설치
-
소프트웨어 적합성 지원
평가 워크샵 이후, 진행자는 동료 프로세스 엔지니어와 함께 결과를 통합하고 정보를 프리젠테이션 가능한 형식으로 압축하는 시간을 가져야 합니다. 결론은 진행자가 아닌 워크샵 참가자가 내려야 합니다.
어떤 진전이 필요하든지 조직 입장에서 결론에 대해 소유권을 표시해야 합니다. 종합하면, 해결해야 하는 문제점에 대해 합의하고 개인적 판단을 배제한 방식으로 표현해야 합니다. 평가의 목적은 개선해야 하는 영역을
식별하는 것이지, 개인에 대한 비평이나 비난이 아닙니다.
|