프로젝트 범위 정의에 대해 알아봅시다.
프로젝트 범위 정의 이해
프로젝트를 수행할 때 프로젝트의 범위를 정의하는 것은 매우 중요합니다. 구체적인 목표를 가지고 프로젝트를 체계적으로 진행할 수 있도록 프로젝트 범위를 정의해야 하기 때문이다. 프로젝트 범위는 프로젝트 요구사항에 따라 정의됩니다. 프로젝트 범위는 프로젝트에서 제공할 시스템과 프로세스 결과를 기반으로 한 일련의 제품 및 서비스입니다. 그러나 프로젝트 범위가 정의되었다고 해서 끝이 아닙니다. 프로젝트 범위가 정의된 후에도 보다 자세한 요구 사항을 식별해야 할 수 있습니다. 프로젝트 범위와 관련된 산출물에는 세 가지 주요 유형이 있습니다. 프로젝트 범위와 관련된 세 가지 출력은 범위 설명입니다. 작업분류체계(WBS)WBS 사전이 있습니다. 프로젝트 팀은 범위 기술서에서 공식 업무의 범위를 설명합니다. 범위 설명에는 범위 설명, 주요 결과물, 허용 기준 및 허용 기준 제외 사항이 포함됩니다. 프로젝트 범위는 작업분류체계(WBS)를 통해 하위 수준으로 세분화하여 세분화할 수 있습니다.
프로젝트 범위 정의와 관련된 문서
프로젝트 범위는 프로젝트를 통해 시스템 기반의 제품, 서비스 및 프로세스를 개발하는 데 필요한 작업입니다. 또한 제품 범위는 제품이 제공하려는 기능 및 특징입니다. 예측 접근 방식을 사용하는 폭포수 프로젝트에서는 프로젝트 시작 시 매우 상세한 작업 분류 시스템(WBS, Work Breakdown)을 구축하여 프로젝트 범위를 정의합니다. 구조)가 정의되고 작성됩니다. 적응적 접근법 애자일 프로젝트WBS(Work Breakdown Structure)라는 개념을 사용하지 않는 경우가 많습니다. 적응형 접근 방식 민첩한 프로젝트개발 범위는 로드맵으로 정의되며, 백로그Epic, Feature, User Story로 활용되기 때문입니다. WBS(Work Breakdown Structure)는 “무엇(What)”과 “어떻게(How)”에 해당하는 요구사항 정의에 해당합니다. 생애주기(Life Cycle) 관점에서 나누어 정의하고 있습니다. 프로젝트 범위를 정의하는 세 가지 주요 결과가 있습니다. 프로젝트 범위를 정의하는 세 가지 출력은 범위 기술서, 작업분류체계(WBS) 및 WBS 사전입니다.[프로젝트 범위 관련 산출물]
1. 범위 설명 이해
범위 기술서는 프로젝트 범위를 설명하고, 프로젝트 범위를 통해 구현될 주요 결과물을 정의하며, 프로젝트 범위 완료를 확인하기 위한 승인 기준과 같은 프로젝트 팀의 공식적인 작업 범위를 정의하고 설명합니다. 범위 설명에는 “제외 사항”도 나열되어 있습니다. 제외는 프로젝트 범위 밖의 콘텐츠를 설명합니다. 범위설명에 프로젝트 제외사항을 기재하는 이유는 해당 프로젝트에서 시행할 범위에 포함되지 않는다는 점을 사전에 논의하고 상황에 따라 추후 진행하기 위함이다. 이는 추가 요구 사항이 적용될 수 있기 때문입니다. 따라서, 프로젝트 범위를 벗어난 내용을 공식 문서에 기술함으로써, 추후 관리가 불가능한 무분별한 범위 추가(범위 크리프)를 방지할 수 있습니다. 범위 설명이 생성되면 범위 설명을 기반으로 작업분류체계(WBS)가 생성됩니다.
2. WBS 이해
작업분류체계(WBS)는 특정 활동 단위의 범위와 분류를 구현하는 데 필요한 작업을 설명하는 문서입니다. 작업분류체계(WBS)는 프로젝트 팀이 목표를 달성하고 필요한 결과물을 계산하는 데 도움이 됩니다. 전체 업무 범위를 계층적으로 레이어별로 나누어서 수행해야 할 업무 전체를 정리한 문서입니다. 여기서 작업은 활동 자체가 아니라 활동의 결과로 생성된 결과 또는 결과물입니다. 업무활동을 통해 창출된 결과물이 WBS에서의 업무입니다. WBS(Work Breakdown Structure)에서 작업을 분할해야 하는 수준은 계산의 정확성과 추정 비용 간의 균형을 고려하여 분할되어야 합니다. WBS의 작업이 상세할수록 비용과 일정을 더 정확하게 추정할 수 있습니다. 그러나 작업이 세밀해질수록 분할에 소요되는 시간과 비용이 늘어나므로 적절한 라인을 유지하는 것이 필요하다. WBS 계층 구조의 하위 수준에는 산출물과 이를 생성하는 데 필요한 작업에 대한 자세한 수준 정보가 표시됩니다. WBS는 프로젝트 계획 및 프로젝트 제어의 핵심입니다. WBS는 프로젝트 기획 및 통제의 핵심이기 때문에 경영 관점에서 가장 중요한 문서입니다. WBS(Work Breakdown Structure)는 프로젝트 견적의 정확성을 높일 수 있습니다. . WBS는 작업을 작은 덩어리로 나누어 비용, 일정, 자원 등 다양한 계산의 정확성을 높일 수 있습니다. 또한 WBS는 책임과 역할을 명확히 할 수 있습니다. WBS가 없으면 책임과 역할이 모호해지고 업무가 진행되지 않을 수 있다. WBS는 책임과 역할을 계층적으로 분류하고 담당자를 나열하여 계층적으로 정의합니다. 그리고 WBS를 사용하면 자동차 운전과 제어가 더 쉬워집니다. 프로젝트의 분할된 작업 단위에서 진행 상황을 모니터링하여 진행 상황을 쉽게 파악하고 부진한 작업에 대한 조치를 취할 수 있습니다. WBS(Work Breakdown Structure)와 관련된 작업 단위 패키지가 있습니다. 작업 패키지는 작업 단위로 나눌 때 작업의 가장 작은 단위입니다. 작업 패키지는 일정과 비용을 추정하는 데 사용됩니다. 프로젝트 관리자참조로 사용할 수 있습니다. 작업 패키지는 WBS의 가장 낮은 수준에 있는 작업을 의미합니다. 작업분류체계가 제대로 분할되었는지 판단하는 기준은 작업패키지를 통해 확인할 수 있다. 각 작업 패키지에 대해 각 작업 패키지가 완료되었는지 여부를 확인할 수 있어야 하며 각 작업 패키지에 대한 산출물을 정의해야 합니다. 각 작업 패키지에 대해 비용, 일정 및 리소스를 안정적으로 추정해야 합니다. 그리고 업무 패키지의 기간은 회사와 조직이 정한 상한선을 초과할 수 없습니다. WBS와 관련하여 롤링플래닝(Rolling Planning), WBS ID, 컨트롤 유닛(Control Unit) 등의 개념도 존재합니다. 롤링 웨이브 계획은 미래에 수행해야 할 작업을 계획하는 것을 의미합니다. 정보가 부족하여 비용이나 기간을 계산할 수 있는 수준으로 나누기가 어렵다면, 프로젝트가 진행되면서 세부적으로 나누는 것을 의미한다. WBS ID(Code of Account)는 WBS의 각 구성 요소 수준에 할당된 ID입니다. WBS ID를 부여하면 WBS 각 레벨의 구성요소를 체계적으로 관리할 수 있습니다. 그리고 WBS ID를 통해 WBS의 세부 수준과 WBS 내 각 항목이 속한 그룹을 쉽게 이해할 수 있습니다. 통제단위(Control Account)는 범위, 일정, 예산 등을 통합하여 계획을 수립하고 성과를 통제하는 역할을 합니다. 이는 WBS 수준을 의미합니다. 통제단위는 획득가치를 분석하는 단위이기도 하다. 제어 단위는 WBS의 최고 수준과 최저 수준 사이의 중간 수준 단위입니다. 제어 장치는 단일 부서나 조직의 책임인 경우가 많습니다. 제어 단위는 두 개 이상의 작업 패키지로 구성되며, 하나의 작업 패키지는 하나의 제어 단위에만 종속되어야 합니다.
3. WBS 사전의 이해
WBS 사전은 각 작업 패키지에 대한 자세한 정보를 설명하는 문서입니다. WBS 사전은 WBS 항목에 대한 자세한 정보를 설명하며 작업 설명, 작업 수행 기간, 투입 자원, 비용 견적, 계약 정보 등을 포함합니다. WBS 사전은 작업 패키지에 대한 자세한 정보를 제공합니다. 적어보세요. WBS 사전에는 작업에 대한 설명, 작업을 수행할 사람, 비용은 얼마, 계약 정보가 어떻게 연결되는지 등 작업분류체계(WBS)와 관련된 자세한 정보가 기록되어 있습니다. Document.WBS Dictionary는 WBS의 각 구성 요소와 관련된 자세한 정보를 제공합니다. WBS 사전에는 WBS 코드 ID, 작업 설명, 가정 및 제약 조건, 책임 조직, 일정 마일스톤, 필수 자원, 비용 추정, 품질 요구 사항 및 승인 기준과 같은 정보가 포함되어 있습니다.
프로젝트 범위 정의 설명
프로젝트 범위를 정의하는 문서인 범위 기술서, 작업분류체계(WBS), WBS 사전이 범위 기준선을 구성합니다. 프로젝트 범위 정의 이 세 가지 문서를 총칭하여 “범위 기준선”이라고 합니다. 범위 기준은 실제 결과와의 비교를 위한 표준으로 사용될 수 있습니다. 범위 기준선은 공식적인 변경 제어 프로세스를 통해서만 변경할 수 있습니다. 프로젝트 범위와 관련하여 사용되는 세 가지 문서는 주로 폭포수 프로젝트에서 사용됩니다. 워터폴 프로젝트는 철저하고 체계적인 계획과 통제가 중요하기 때문에 범위기술서, WBS, WBS 사전 등의 결과물이 매우 중요합니다. 특히 워터폴 프로젝트에서는 WBS가 매우 중요합니다. 워터폴 프로젝트에서 기획과 통제의 핵심인 WBS는 프로젝트 초기에 생성되는 가장 중요하고 핵심적인 결과물이다. 그러나 WBS 문서는 Agile 프로젝트에서 사용되지 않습니다. Agile 프로젝트에서는 다른 유형의 문서가 사용됩니다. 출력을 사용하십시오. Agile에서는 Agile Charter와 범위 구분 로드맵을 기반으로 전략적 주제를 식별합니다. 테마를 달성하기 위해 대규모 사용자 스토리를 포함한 서사시를 개발합니다. 에픽은 시스템의 특정 동작을 나타내는 기능으로 분할됩니다. 기능은 사용자 관점에서 작성된 요구사항인 사용자 스토리로 구성됩니다. 프로젝트 범위 정의와 관련하여 사용하는 프로젝트 접근 방식에 따라 인도물 구현 완료 및 프로젝트 완료를 설명하는 방식이 달라집니다. 즉, 예측적 접근 방식인 워터폴 프로젝트와 접근 방식인 애자일 프로젝트에서는 모든 결과물이 구현되었는지, 프로젝트가 성공적으로 완료되었는지를 판단하는 기준인 ‘수용 기준’을 살펴본다. 다르게 완성되었습니다. 승인 기준은 인도물이 승인되고 프로젝트가 완료된 것으로 간주되기 위해 충족되어야 하는 조건을 나타냅니다. 기술적 성과 측정은 완료를 결정하는 데 사용되는 다양한 기준을 지정하는 WBS 사전의 자세한 정보입니다. 예측적 접근 방식인 폭포수 프로젝트에서는 주문에 따라 승인 기준과 완료 기준이 결정됩니다. 회사(클라이언트 회사)가 결과물을 승인하거나 프로젝트가 완료된 것으로 간주하려면 사전 설정된 기준을 충족해야 완료된 것으로 간주됩니다. 이는 범위 설명에 문서화되어 있습니다. 예측적 접근 방식인 폭포수 프로젝트에서는 기술 성능 측정이 제품의 기술 사양에 대한 별도의 문서 또는 WBS 사전 형식으로 문서화됩니다. 적응형 접근 방식에서는 Agile 프로젝트의 완료 표준을 DoD(Definition of Done)라고 합니다. DoD(Agile Definition of Done)는 적응형 접근 방식 개발 프로젝트에서 주로 사용되는 개념으로, 고객이 사용할 수 있는 수준으로 완성된 결과물을 의미합니다. 완료된 것으로 간주되기 위해 충족해야 하는 모든 기준을 지정하는 체크리스트입니다. Agile에서 DoD(Definition of Done)를 정의할 때 품질 기준 충족 여부를 완료 기준으로 정의할 수 있습니다. 애자일의 품질 기준은 수행의 의미의 일부로 간주됩니다. 당신은 할 수 있습니다. Agile에서 가장 중요한 것은 DoD가 작동하는 제품이어야 한다는 것입니다. Agile 프로젝트를 통해 생성된 결과물은 모든 품질 기준을 충족하고, 기능적이어야 하며, 결함이 없어야 하며, 결과는 제품 소유자의 검증 및 승인을 받아야 합니다. Agile 프로젝트에서 완료 기준은 제품 소유자의 승인을 통해 결정될 수 있습니다. 기술적 관점에서는 코드 리팩토링 및 검증, 마스터 브랜치 통합 및 포함 여부, 추후 작업을 위해 스테이징 환경으로 배포(프로덕션) 환경에 배포할 준비가 되었는지 여부로도 판단할 수 있습니다. 적응형 접근 방식인 Agile 프로젝트에서 준비 상태에 대한 정의를 DoR(Definition of Ready)이라고 합니다. Agile에서 준비 상태(DoR)의 정의는 Agile 프로젝트 팀이 스프린트 계획 회의를 열 때 제품 소유자(PO)와 개발팀이 논의하는 것입니다. 이는 개발팀이 상담 과정에서 사용자 스토리를 충분히 이해했는지 판단하는 기준입니다. 제품 소유자(PO 입장에서는 개발팀 구성원이 모드를 제대로 이해하고 설명하는 사용자 스토리를 기술적으로 구현할 준비가 되어 있는지 확인하는 것이 필요합니다. 준비가 되었는지 판단할 때 DoR은 다음과 같은 작업을 수행하는 데 사용됩니다. 이는 제품 소유자와 개발팀 간의 충분한 대화를 통해 사용자 스토리에 대해 기술적으로 구현하는 방법에 대한 충분한 합의가 이루어졌음을 의미합니다. Agile, 준비된 UserStory는 비즈니스 가치와 충분하고 명확하게 일치해야 합니다. Agile 프로젝트에서는 우선순위가 고객 가치를 기반으로 하므로 기본적인 준비는 고객 가치를 기반으로 한 스토리를 구현하는 것이 옳다고 인식될 때만 이루어집니다. 우선 사용자 스토리(UserStory)는 단일 스프린트로 구현될 수 있을 만큼 분할되어야 합니다. 그래야만 짧은 반복이 완료되면 결과를 볼 수 있습니다. 다듬어지지 않았다면 Agile 프로젝트 작업을 시작할 준비가 되지 않았다는 의미입니다. 이것이 바로 Agile 프로젝트에서 준비 상태 정의(DoR)가 중요한 이유입니다.