베스트 프랙티스: 반복적으로 개발위험을 완화하려면 반복적인 방법을 통해 단계적으로 개발하십시오. 각 반복으로 실행 가능한 릴리즈를 생성합니다. 주제반복 개발의 개념
반복 개발을 사용하는 프로젝트에는 여러 번의 반복으로 이루어진 라이프사이클이 있습니다. 반복은 비즈니스 모델링, 요구사항, 분석 및 설계, 구현, 테스트 및 전개의 연속 세트를 개발 주기에서 반복의 위치에 따라 다양한 비율로 통합합니다. 초기 및 구현화 단계의 반복은 관리, 요구사항 및 설계 활동에 중점을 두고 구축 단계의 반복은 설계, 구현 및 테스트에 중점을 두며 전이 단계의 반복은 테스트 및 전개에 중점을 둡니다. 반복은 시간 제한 방법으로 관리되어야 합니다. 다시 말해, 반복에 대한 스케줄이 고정되고 해당 스케줄에 맞추도록 반복의 컨텐츠 범위가 적극적으로 관리되어야 합니다. 반복적으로 개발해야 하는 이유
초기 설계는 주요 요구사항에 관하여 결함이 될 수 있습니다. 설계 결함을 늦게 발견하면 비용이 초과되고, 일부 경우에는 프로젝트가 취소되기도 합니다. 모든 프로젝트에는 연관된 위험 세트가 있습니다. 라이프사이클의 초기에 위험을 피했는지 확인할 수 있으면 계획을 더 정확하게 작성할 수 있습니다. 시스템을 통합하려고 할 때, 수 많은 위험이 발견됩니다. 개발 팀이 얼마나 많은 경험을 가지고 있느냐에 관계없이 절대로 모든 위험을 예측할 수는 없습니다. 워터폴 라이프사이클에서는 라이프사이클의 후반부까지 위험을 피했는지 여부를 확인할 수 없습니다.
반복적 라이프사이클에서 주요 위험 목록을 기반으로 하여 반복에 개발되는 증가량을 선택합니다. 반복을 통해 테스트된 실행 파일을 생성하므로 대상 위험을 완화했는지 여부를 확인할 수 있습니다. 반복 방법의 장점
반복 방법은 여러 가지 이유로 인해 선형 또는 워터폴 방법보다 일반적으로 우수합니다.
고객이 다음과 같이 말했습니다. "워터폴 방법을 사용하면 프로젝트 종료에 가까와질 때까지, 경우에 따라 통합 도중에 이르기까지 모든 것이 괜찮아 보입니다. 그런 다음, 모든 것이 붕괴됩니다. 반복적 방법을 사용하면 오랫동안 사실을 숨기는 것이 어렵습니다." 프로젝트 관리자는 종종 반복 방법을 끝없는 해킹으로 간주하여 이 방법을 반대합니다. Rational Unified Process에서 반복 방법은 상당히 제어됩니다. 반복은 숫자, 지속 기간 및 목표로 계획됩니다. 실행자의 타스크 및 책임이 정의됩니다. 객관적인 진행 측정이 캡처됩니다. 한 반복에서 다음 반복까지 일부 재작업이 발생하지만 이것 또한 철저하게 제어됩니다. 위험 완화
수 많은 위험이 통합 중에만 처리되고 발견되므로 반복 방법을 사용하면 위험을 더 빨리 완화할 수 있습니다. 초기 반복을 전개할 때 많은 프로젝트 측면(툴, 구매 가능한 소프트웨어, 인력 기술 등)을 사용하여 모든 규칙을 검토합니다. 인지된 위험이 위험이 아닌 것으로 판명될 수 있고 뜻밖의 새로운 위험이 나타납니다. 통합은 결국 하나의 "빅뱅(big bang)"이 아닙니다. 요소는 지속적으로 통합됩니다. 실제로 반복 방법은 거의 지속적인 통합입니다. 길고 불확실하고 어려운 시간(프로젝트 후반에 전체 노력의 최대 40%를 차지함)이었던 것과 정확하게 계획하기 어려웠던 것은 6개에서 아주 작은 수의 요소로 통합을 시작하는 9개의 더 작은 통합으로 나뉩니다. 변경 조정
요구사항이 보통 반복 방법에 따라 변경되므로 반복 방법은 요구사항 변경을 고려하게 합니다. 요구사항 및 요구사항 "크리프" 변경은 항상 전달 지연, 스케줄 초과, 고객 불만 및 개발자를 초조하게 하는 등 프로젝트에 대한 문제의 주된 원인이 되어 왔습니다. 25년 전에 Fred Brooks가 다음과 같이 썼습니다. "하나를 버리도록 계획하십시오. 어차피 그렇게 됩니다." 사용자는 도중에 마음을 바꿉니다. 이것은 인간의 본성입니다. 원래 가정한 대로 시스템을 승인하도록 사용자를 강요하는 것은 잘못된 일입니다. 컨텍스트가 변경되고 있으므로 사용자의 마음이 변경됩니다. 이들은 환경 및 기술에 대해 더 자세히 배우고 개발되고 있는 제품의 중간 시연을 보게 됩니다. 반복적 라이프사이클은 관리자에게 제품에 전술적인 변경을 작성하는 방법을 제공합니다. 예를 들어, 기존 제품과 경쟁하기 위해 경쟁사의 움직임에 더욱 빠르게 대응하도록 축소 기능의 제품을 릴리즈하기로 결정하거나 해당 기술을 수용하기 위해 다른 벤더를 채택할 수 있습니다. 또한 반복은 중간에 기술적 변경을 허용합니다. 일부 기술이 변경되거나 새 기술이 발표되어 표준이 될 때 프로젝트가 이를 이용할 수 있습니다. 이것은 특히 플랫폼 변경 및 하위 레벨 인프라스트럭처 변경에 대한 케이스입니다. 고품질 달성
여러 반복에 걸쳐 오류가 정정되므로 반복 방법은 더 견고한 구조를 생성합니다. 제품이 초기 반복 중에 완성되면 초기 문제점이 발견됩니다. 제품 출시 직전에 발견되는 것과는 대조적으로 성능 병목현상은 발견되고 감소될 수 있습니다. 프로젝트의 끝부분에서 테스트를 한 번 수행하는 것과는 대조적으로 반복적으로 개발하는 것은 보다 철저하게 테스트된 제품을 생성합니다. 중요한 기능은 여러 반복으로 테스트될 기회를 많이 가졌고 테스트 자체 및 테스트 소프트웨어가 완성될 시간이 있었습니다. 학습 및 개선
개발자는 전체 라이프사이클 중에 더욱 완전하게 사용되는 방법, 다양한 능력 및 전문성에 따라 학습할 수 있습니다. 단지 계획을 작성하고 기술을 숙련시키기 위해 오랜 시간을 기다리는 대신, 테스터는 테스트 작업을 빨리 시작하고 기술 문서 작성을 빨리 시작합니다. 추가 훈련 또는 외부 도움에 대한 요구는 초기 반복 평가 검토에서 발견될 수 있습니다. 프로세스가 개발됨에 따라 프로세스 자체적으로 개선되고 정제될 수 있습니다. 반복 종료시 평가는 제품 스케줄 Perspective에서 프로젝트의 상태를 보는 것만이 아니라 다음 반복에서 보다 잘 수행하기 위해 조직 및 프로세스에 변경되어야 하는 사항을 분석하기도 합니다. 재사용 증대
반복 라이프사이클은 재사용을 용이하게 합니다. 모든 공통성을 미리 식별해야한다는 사실을 비교할 때 부분적으로 설계되거나 구현되었기 때문에 공통 부분을 식별하는 것은 쉽습니다. 재사용 가능한 부분을 식별하고 개발하는 것은 어렵습니다. 초기 반복의 설계 검토를 통해 소프트웨어 아키텍트가 예상치 않은 잠재적 재사용을 식별할 수 있게 하며, 연속적인 반복으로 이 공통 코드를 한층 더욱 더 개발하고 완성시킬 수 있게 합니다. 반복 방법 사용은 상업상 구매 가능한 제품의 이용을 용이하게 합니다. 반복을 선택하고 통합하며, 구조에 맞는지 검증할 수 있는 여러 개의 반복이 있습니다. |
Rational Unified Process
|