내부 또는 아웃소싱 소프트웨어 프로젝트인지 여부에 관계없이 프로젝트 계획 단계는 소프트웨어 프로젝트의 성공 여부를 결정하는 데 결정적입니다. 승나이자형 소프트웨어 프로젝트 계획은 소프트웨어 개발을 위해 선택한 프로세스 모델에 크게 의존합니다.
새로운 기사에서는 소프트웨어 개발을 계획할 때 고려해야 하는 가장 일반적인 프로세스 모델의 특수 기능과 선택한 모델이 프로젝트 계획에 어느 정도 영향을 미칠 수 있는지 보여줍니다.
선형 프로세스 모델을 사용한 계획:
폭포 모델
폭포수 모델에서 소프트웨어 프로젝트는 요구 사항 분석, 설계, 프로그래밍, 테스트, 제공 및 유지 관리와 같은 일련의 순차적 단계로 나뉩니다. 즉, 각 이전 단계의 결과가 후속 단계(캐스케이드 형식)의 기초 역할을 합니다. 각 단계의 결과는 포괄적으로 문서화됩니다. 개별 단계를 반복하는 것은 거의 불가능합니다. 계획 단계 이 캐스케이드의 첫 번째 단계는 소프트웨어 프로젝트의 성공에 중요한 역할을 합니다.
참가자: 프로젝트 소유자, 프로젝트 관리자, 비즈니스 분석가 및 테스트 관리자입니다.
특징: 프로젝트 계획의 기초는 소프트웨어 프로젝트의 시작 부분에서 정의되고 사양의 형태로 정확하게 설명되고 컴파일되는 요구 사항입니다. 요구 사항은 안정적으로 유지되어야 합니다. 이 모델은 또한 프로젝트 팀이 이러한 요구 사항을 충족해야 하는 방법을 지정해야 합니다.
프로세스: 요구 사항 분석 단계에서 비즈니스 분석가는 고객의 프로젝트 소유자와 통신하여 소프트웨어가 제공해야 하는 기능을 찾습니다. 수집된 정보를 기반으로 비즈니스 분석가는 기능 범위, 모든 프로젝트 활동의 흐름, 비용 및 기간 등을 계획합니다.
V 모델
의 프로젝트 관리 V 모델 폭포수 모델과 유사합니다. 개발 프로세스도 단계별로 구성됩니다. 그러나 주요 차이점은 V 모델의 테스트가 각 프로젝트 단계에 대해 계획되고 수행된다는 것입니다.
애자일 프로세스 모델을 사용한 계획:
스크럼
Scrum을 사용하면 소프트웨어 프로젝트는 스프린트 조직, 그만큼 1-4주 동안 지속되며 사용자 스토리의 요구 사항을 충족하는 기능 세트와 함께 작동하는 제품 증분을 제공하는 것을 목표로 합니다. 사용자 스토리는 일반적으로 특정 결과를 달성할 수 있도록 사용자 관점에서 원하는 기능을 설명합니다(예: 이미지, 비디오 트리밍, 데이터베이스에 데이터 삽입 등).
참가자: 프로젝트 소유자(스크럼에서는 제품 소유자라고 함), 프로젝트 관리자, 비즈니스 분석가, 테스트 관리자, 개발 및 테스트 팀입니다.
특수성: Scrum에서는 다가오는 스프린트에 대해서만 세부 계획이 생성됩니다.
프로세스: 각 스프린트 전에 프로젝트 소유자는 프로젝트 소유자의 비전을 기반으로 새 스프린트의 구체적인 목표가 결정되는 다음 프로젝트 단계를 계획하는 회의(소위 스프린트 계획 회의)를 구성합니다. 질문이있을 것입니다 “무엇” 그리고 “어떻게” 답변:
“무엇” – 그것은 어떤 요구 사항에 관한 것입니다. 제품 백로그 (우선 순위에 따라 변경될 수 있는 기록된 모든 소프트웨어 요구 사항 목록)은 다음 스프린트 중에 선택하고 구현해야 합니다. 스크럼 팀은 종종 요구 사항을 설명하기 위한 효과적인 도구로 사용자 스토리를 사용합니다.
“어떻게” – 선택한 요구 사항을 구현하는 방법에 관한 것입니다. 이를 위해 소위에서 우선 순위가 지정됩니다. 스프린트 백로그 개별 프로젝트 작업으로 입력 및 분할됩니다.
익스트림 프로그래밍(XP)
이 모델에는 반복으로 구성된 4단계(계획, 설계, 프로그래밍, 테스트)가 포함됩니다. 프로그래밍은 항상 초점입니다. 반복은 일반적으로 1~3주 동안 지속되며 이전 반복에서 얻은 교훈과 고객 피드백을 기반으로 계획됩니다. 각 단계는 각 반복이 끝날 때 작업 제품 증분을 더 빠르게 제공하기 위해 특정 사례(예: 쌍 프로그래밍, 원룸 협업, 사용자 스토리, 지속적인 테스트 및 통합, 테스트 기반 개발 등)를 사용합니다. 출시된 제품은 다음 반복에서 고객의 요구 사항에 맞게 조정되고 점진적으로 개선될 것입니다.
참가자: 프로젝트 소유자, 프로젝트 관리자, 비즈니스 분석가, 개발 및 테스트 팀.
특이 사항. 기획 소프트웨어 개발에 대한 이러한 접근 방식을 계획 게임이라고 하며 릴리스 계획 및 반복 계획의 두 단계로 구성됩니다.
프로세스: 시 릴리스 계획 다음 릴리스에서 어떤 기능을 구현해야 하는지는 대략적으로 정의되고 사용자 스토리에 문서화되어 있습니다. 예상 작업량은 릴리스 계획의 일부로도 만들어집니다. 생성된 계획은 검토, 업데이트(필요한 경우) 및 승인됩니다.
후속 반복 계획 개발자와 테스터를 위해 사용자 스토리를 상세한 기술 작업 단계로 변환하고 각 작업 완료 기간을 설정하는 것을 목표로 합니다. 변경 요청이 발생하면 다시 계획을 세울 수 있습니다.
칸반
Kanban은 소프트웨어 프로젝트의 모든 흐름과 프로세스를 더 작은 작업으로 세분화하고, 이러한 작업을 팀 구성원에게 할당하고, Kanban 보드에서 워크플로를 시각화하고, 개별 작업을 상태(할 일, 진행 중)에 따라 적절한 열로 이동할 수 있습니다. , 완료.
참가자: 프로젝트 소유자, 프로젝트 관리자, 비즈니스 분석가, 프로젝트에 참여하는 팀의 팀장(디자이너, 개발자, 테스터, 데이터 분석가 등).
특수성: Kanban에는 구분된 계획 단계가 없습니다. Kanban 프로젝트에는 많은 커뮤니케이션이 있습니다. 결과적으로 협업 중에 새로운 작업을 논의하고 Kanban 보드에 배치할 수 있습니다.
순서: 프로젝트 소유자의 요구 사항을 기반으로 프로젝트 관리자는 명확한 프로젝트 목표를 달성하기 위해 프로젝트 팀이 수행해야 하는 작업을 계획합니다. 어떤 경우에는 비즈니스 분석가가 계획 프로세스에 참여하여 요구 사항을 수집하기도 합니다. 이러한 작업을 완료하기 위해 팀 리더는 개별 단기 작업 단계로 세분화되고 팀 구성원에게 할당되고 우선 순위가 지정되는 세부 계획을 만듭니다. 이 단계는 종이 쪽지에 쓰여 있으며 Kanban 보드의 해당 열에 배치됩니다.
소프트웨어 프로젝트를 계획할 때 함정을 피하십시오
소프트웨어 프로젝트를 계획할 때 각 모델의 세부 사항을 고려하는 것만으로는 충분하지 않습니다. 또한 이를 효과적으로 관리하고 방지하기 위해 소프트웨어 개발 계획에서 잠재적인 함정을 미리 식별하는 것이 좋습니다. 서로 다른 프로세스 모델에는 서로 다른 함정이 숨겨져 있습니다.
선형 프로세스 모델:
- 선형 모델에는 문제가 있습니다. 변경 사항. 이러한 작업이 필요한 경우 계획된 모든 활동을 재작업해야 하며 일반적으로 더 긴 시간과 더 많은 투자가 필요합니다. 이를 방지하려면 프로젝트 소유자는 프로젝트 시작 시 모든 비즈니스 요구 사항을 가능한 한 정확하게 설명하고 이를 프로젝트 계획에 사용해야 합니다.
- 폭포수 모델에서는 얼마나 많은 노력을 기울여 계획하기가 어렵습니다. 버그 확인 및 수정 될 수 있습니다. 이러한 함정을 피하려면 프로젝트 전반에 걸쳐 품질 관리 활동을 계획하는 것이 좋습니다.
반복 프로세스 모델:
- 단기 계획에 초점을 맞추면 위험이 매우 커집니다. 느린 프로젝트 진행. 이러한 함정을 피하려면 특정 기준(예: 월별 목표 설정 및 달성 방법 확인)에 따라 프로젝트 진행 상황을 정기적으로 평가하고 모니터링하는 것이 좋습니다.
- 그것은 또한 어렵다 생산적인 반복 계획, 팀이 재건될 때. 각 팀원이 작업을 완료할 수 있는 속도는 아직 명확하지 않습니다. 결과적으로 스프린트가 원래 예상보다 오래 걸릴 수 있습니다. 마감일을 놓치지 않으려면 첫 번째 스프린트가 끝날 때 속도를 측정하고 다음 스프린트를 계획할 때 이 정보를 사용할 수 있습니다.
요약하자면
소프트웨어 개발을 계획할 때 선택한 프로세스 모델의 세부 사항을 고려하지 않고 소프트웨어 프로젝트를 성공적으로 계획하는 것은 거의 불가능합니다. 이 모델은 계획 프로세스에 참여할 사람, 계획에 포함되는 단계, 계획의 유연성을 결정합니다.