12.0 폭포수 대 순환적 프로젝트 관리(5부) – 순환적 프로젝트 관리를 위한 조건

사용자/고객이 적극적으로 참여 #

주기적인 프로젝트 관리의 각 주기에는 요구 사항 개발, 설계, 실행 및 테스트가 포함됩니다. 이것은 주기 동안 많은 선택을 해야 함을 의미합니다. 프로그램이 고객의 욕구를 정확하게 나타내려면 고객은 프로젝트 팀의 적극적인 구성원이어야 합니다.

고객은 프로그래머와 설계자에게 가능한 한 명확하게 요구 사항을 전달해야 합니다. 이것은 종종 프로젝트 팀에 매주(또는 최소한 격주로) 참여해야 합니다.

프로젝트 내에서 소비자는 필요한 기능 및 주기 계획의 정의에 기여합니다. 그들은 승인 테스트에 협력하고 중간 결과를 승인하거나 거부하며 프로젝트의 전반적인 방향에 기여합니다. 또한 적극적인 고객 참여는 폭포수 방식을 사용할 때 개선된 결과를 가져옵니다.

팀은 선택권을 가지고 있습니다. #

주기 내에서 프로젝트 팀은 스스로 결정을 내릴 수 있는 권한을 부여받아야 합니다. 프로젝트 팀에 이 권한이 없으면 프로젝트 관리의 순환 모델이 작동하지 않습니다. 주기 전반에 걸쳐 상급자의 지속적인 승인이 필요한 경우 정체가 발생할 수 있습니다. 또한 외부인은 프로젝트 팀에 적극적으로 참여하지 않기 때문에 무슨 일이 일어나고 있는지 알지 못하는 경우가 많습니다. 이것은 그들이 합리적인 결정을 내리는 것을 어렵게 만듭니다.

프로젝트의 출력(소프트웨어)은 더 작은 구성 요소로 분해될 수 있습니다. #

순환 프로젝트 관리는 프로젝트의 일부가 일련의 주기로 완료되는 프로젝트를 관리하는 방법입니다. 이것은 개발 중인 소프트웨어가 다소 구별되는 여러 구성 요소로 분해될 수 있는 경우에만 가능합니다.

프로젝트 관리 소프트웨어 에 대한 경영진의 요구 사항은 주로 글로벌합니다. 경영진은 직접, 구체적 또는 특정 요구 사항을 부과하지 않습니다. 주기적인 프로젝트 관리의 장점 중 하나는 주기 동안 고객, 디자이너, 프로그래머 및 테스터 간의 긴밀한 협력입니다. 프로젝트 시작 시 구체적이고 구체적인 요구 사항이 설정되면 설계 선택 시 최선의 판단을 내릴 수 있는 프로젝트 팀의 능력이 제한됩니다. 프로젝트에 대한 수많은 요구 사항은 프로세스 중에 조정이 필요한 것으로 드러났으므로 처음부터 (너무) 확고하게 설정되어서는 안 됩니다.

고객은 활동을 이해합니다. #

고객이 이해하기 어려운 중요한 기술 작업이 주기 내에서 발생해야 하는 경우 고객이 팀에 효과적으로 기여할 수 없는 위험이 있습니다. 이러한 상황에서 고객은 반드시 내려야 하는 설계 결정에 대해 발언권이 거의 없습니다.

고객이 진행 상황을 알지 못하는 경우에도 유사한 위험이 존재합니다. 예를 들어, 사용자 인터페이스에는 거의 관심을 기울이지 않고 많은 작업을 코딩에 할애할 수 있습니다. 고객이 옆으로 밀려나는 것을 피하기 위해 주기의 내용과 진행 상황에 대한 충분한 통찰력을 갖는 것이 중요합니다.

자신의 발걸음을 되돌릴 수 있어야 합니다. #

주기적인 프로젝트 관리에서도 팀은 때때로 잘못된 경로를 추구합니다. 그러한 경우에는 한 발짝 뒤로 물러날 수 있어야 합니다. 주기 중에 생성된 새 모듈이 충분하지 않은 것으로 판명되면 이전 모듈로 작업을 재개할 수 있어야 합니다. 이것은 특히 프로젝트 자료의 보관 및 문서화에 대한 요구 사항을 부과합니다. CVS와 Subversion은 이러한 작업에 유용한 두 가지 도구입니다(도구의 전체 목록은 부록 3 참조).

프로그래밍 기술과 함께 프로그래머는 고객과 효과적으로 상호 작용할 수 있어야 하며 그 반대의 경우도 마찬가지입니다. 팀원은 지적 사고를 해야 합니다. 작업을 계속하려면 규율이 필요합니다.

프로젝트가 수행되는 조직도 이러한 운영 방식에 대해 충분한 지원을 제공해야 합니다. 프로젝트를 지원하려면 시간 추적, 보관 및 일정 관리 시스템이 필요합니다. 이러한 등록 시스템은 프로젝트와 기간에 걸쳐 자원을 공평하게 할당하는 데 필수적인 개방성을 제공합니다.

우선순위 #

프로젝트에는 적절한 중요성이 부여되어야 하며 팀 구성원이 프로젝트에 사용할 수 있어야 합니다. 팀원들에게 너무 많은 작업을 동시에 수행하도록 요구하는 것은 비효율적입니다. 조직이 프로젝트 기반 작업에 적절하게 적응하지 않으면 주기적 프로젝트 관리 유연성으로 인해 혼란이 발생할 수 있습니다. 또한 폭포수 기법은 프로젝트 관리에 대한 조직적인 접근 방식의 이점을 얻습니다(Wijnen, 2004, p. 111 참조).

관리자보다 선견지명이 있는 소프트웨어 개발 회사의 이사는 거의 매달 좋은 아이디어를 내놓았고 회사에서 끊임없이 새로운 이니셔티브를 시작했습니다. 그 결과 오래된 프로젝트는 한 번도 완료되지 않았고 작업자는 동시에 최대 5개의 프로젝트를 수행했습니다. 카리스마 넘치는 감독은 RAD(빠른 응용 프로그램 개발)에 대한 책을 막 읽었으며 특히 ‘빠른’ 요소에 대해 매우 흥분했습니다. 그는 RAD의 기본 아이디어를 복사기에 테이프로 붙인 다음 모든 사람이 이러한 개념으로 작업을 시작할 것이라고 예상했습니다. 결국, 그것은 훌륭한 기술이었습니다.

주기적 프로젝트 관리의 위험 #

주기적 프로젝트 관리 기술은 때때로 필요한 기능을 실행하기에 불충분한 시간을 남깁니다. 프로젝트 기간이 고정되어 있기 때문에 처음에 예상했던 것보다 더 적은 수의 기능이 추가될 것이 거의 확실합니다.

이는 정당한 문제이지만 폭포수 접근 방식 에도 내재되어 있습니다. 폭포수 접근 방식의 정의 단계에는 요구 사항에 대한 심층적인 조사가 수반됩니다. 이 분석을 통해 시간 관리가 개선될 수 있습니다. 위에서 언급한 이유로 인해 실제로는 그렇지 않은 경우가 많습니다.

또한 이 접근 방식에서는 기능을 개발할 자금이 부족하기 때문에 기능이 생략됩니다.

요구 사항은 사이클 접근 방식에서 실용적으로 처리됩니다. 예를 들어, 주기의 필요성은 MoSCoW 기준(Stapleton, 2003)을 사용하여 다음과 같이 분류할 수 있습니다.

  • 필수 사항: 시스템에 중요한 요구 사항
  • 해야 할 것: 사용자가 진정으로 원하는 중요한 요구 사항
  • 가질 수 있는 것: 쉽게 무시할 수 있는 바람직한 욕구
  • 갖고 싶은 것: 이번에 충족되지 않을 요구 사항: 나중에 기다릴 수 있는 요구 사항

특정 기능을 더 이상 사용할 수 없는지 여부에 관계없이 DANS 프로젝트 관리자는 주기적 작업이 폭포수 방식보다 고객 만족도가 더 높다고 믿습니다. 어떤 경우든 기대치는 정기적으로 더 효과적으로 통제되며 프로젝트는 초기에 계획한 것보다 덜 복잡하더라도 일상적으로 작동하는 결과를 생성합니다.

잠재적인 단점 이해 #

XP의 일반적으로 언급되는 단점 중 하나는 상당한 권한이 프로그래머에게 이전된다는 것입니다. 이 권한을 남용하면 고객의 기술 전문성 부족을 유리하게 이용할 수 있습니다. 이 시나리오를 피하려면 프로그래머와 고객의 이익을 모두 볼 수 있는 프로젝트 리더가 필요합니다. 이러한 프로젝트 리더는 고객이 주기를 선택 및 계획하고 선택의 기술적 토대를 이해하기 쉽게 만들고 관리 및 보고를 제공하는 데 도움을 줍니다.

마지막으로 XP의 또 다른 단점은 이 방법을 구현하려면 프로그래머, 관리자 및 소비자를 위한 높은 학습 곡선이 필요하다는 것입니다.