사용자/고객이 적극적으로 참여#
주기적 프로젝트 관리의 각 주기에는 요구 사항 개발, 설계, 실행 및 테스트가 포함됩니다. 이는 주기가 진행되는 동안 많은 선택이 이루어져야 함을 의미합니다. 프로그램이 고객의 요구를 정확하게 표현하려면 고객이 프로젝트 팀의 적극적인 구성원이어야 합니다.
고객은 가능한 한 명확하게 자신의 요구 사항을 프로그래머와 디자이너에게 전달해야 합니다. 이는 종종 프로젝트 팀에 매주(또는 최소한 격주) 참여하는 것을 수반합니다.
프로젝트 내에서 소비자는 필수 기능 정의 및 주기 계획에 기여합니다. 그들은 승인 테스트에 협력하고, 중간 결과를 승인하거나 거부하며, 프로젝트의 전반적인 방향에 기여합니다. 또한 폭포수 방법을 사용할 때 적극적인 고객 참여로 인해 결과가 향상됩니다.
팀에는 선택을 할 수 있는 권한이 부여됩니다.#
주기 내에서 프로젝트 팀은 스스로 결정을 내릴 수 있는 권한을 부여받아야 합니다. 프로젝트 팀에 이러한 권한이 없으면 프로젝트 관리의 순환 모델이 작동하지 않게 됩니다. 주기 내내 상사의 지속적인 승인이 필요한 경우 정체가 발생할 수 있습니다. 또한 외부인은 프로젝트 팀에 적극적으로 참여하지 않기 때문에 무슨 일이 일어나고 있는지 알지 못하는 경우가 많습니다. 이로 인해 합리적인 결정을 내리기가 어렵습니다.
프로젝트의 출력(소프트웨어)은 더 작은 구성 요소로 분해될 수 있습니다.#
순환 프로젝트 관리는 프로젝트의 일부가 일련의 주기로 완료되는 프로젝트를 관리하는 방법입니다. 이는 개발 중인 소프트웨어가 다소 별개의 구성 요소로 분해될 수 있는 경우에만 가능합니다.
경영진의 요구사항프로젝트 관리 소프트웨어주로 글로벌합니다. 경영진은 직접적, 구체적 또는 특정 요구 사항을 부과하지 않습니다. 주기적 프로젝트 관리의 장점 중 하나는 주기 동안 고객, 설계자, 프로그래머 및 모든 테스터 간의 긴밀한 협업입니다. 프로젝트 시작 시 구체적이고 구체적인 요구 사항이 설정되면 이로 인해 프로젝트 팀이 설계를 선택할 때 최선의 판단을 내릴 수 있는 능력이 제한됩니다. 프로젝트에 대한 수많은 요구 사항은 프로세스 중에 조정이 필요한 것으로 나타나므로 시작 시 (너무) 확고하게 설정되어서는 안 됩니다.
고객은 활동을 이해합니다.#
고객이 이해하기 어려운 중요한 기술 작업이 한 주기 내에 발생해야 하는 경우 고객이 팀에 효과적으로 기여하지 못할 위험이 있습니다. 그러한 상황에서 고객은 내려져야 하는 설계 결정에 대해 거의 발언권을 갖지 못합니다.
고객이 진행 상황을 알지 못하는 경우에도 유사한 위험이 존재합니다. 예를 들어, 대부분의 작업은 코딩에 집중되고 사용자 인터페이스에는 거의 관심을 기울이지 않을 수 있습니다. 고객이 부업으로 밀려나는 것을 방지하려면 주기의 내용과 진행 과정에 대한 충분한 통찰력을 갖는 것이 중요합니다.
자신의 발걸음을 되돌리는 것이 가능해야 합니다.#
순환적인 프로젝트 관리에서도 팀은 때때로 잘못된 경로를 추구합니다. 그러한 경우에는 한 발 뒤로 물러나는 것이 가능해야 합니다. 주기 중에 생성된 새 모듈이 부족한 것으로 확인되면 이전 모듈로 작업을 재개할 수 있어야 합니다. 이는 특히 프로젝트 자료의 보관 및 문서화에 대한 요구 사항을 부과합니다. CVS와 Subversion은 이러한 작업에 유용한 두 가지 도구입니다(전체 도구 목록은 부록 3 참조).
프로그래밍 기술과 함께 프로그래머는 고객과 효과적으로 상호 작용할 수 있어야 하며 그 반대의 경우도 마찬가지입니다. 팀원은 지적인 사상가여야 합니다. 일을 계속하려면 규율이 필요합니다.
프로젝트가 수행되는 조직도 이러한 운영 모드에 대해 충분한 지원을 제공해야 합니다. 프로젝트를 지원하려면 시간 추적, 보관 및 일정 관리 시스템이 필요합니다. 이러한 등록 시스템은 프로젝트와 기간 전반에 걸쳐 자원의 공평한 할당을 보장하는 필수적인 개방성을 제공합니다.
우선순위#
프로젝트에는 적절한 중요성이 부여되어야 하며 팀 구성원이 이를 위해 활용 가능해야 합니다. 팀 구성원에게 너무 많은 작업을 동시에 수행하도록 요구하는 것은 효과적이지 않습니다. 조직이 프로젝트 기반 작업에 적절하게 적응하지 못하면 주기적인 프로젝트 관리 유연성으로 인해 혼란이 발생할 수 있습니다. 추가적으로, 폭포수 기술은 프로젝트 관리에 대한 조직적인 접근 방식으로부터 이점을 얻습니다(Wijnen, 2004, p. 111 참조).
관리자보다 더 비전이 있는 소프트웨어 개발 회사의 이사는 거의 매달 좋은 아이디어를 가지고 있었고 회사에서 끊임없이 새로운 계획을 시작했습니다. 결과적으로 오래된 프로젝트는 완료되지 않았으며 작업자는 최대 5개의 프로젝트를 동시에 작업했습니다. 카리스마 넘치는 감독은 RAD(Rapid Application Development)에 관한 책을 막 읽었고 그 책, 특히 '빠른' 요소에 대해 매우 흥미를 느꼈습니다. 그는 RAD의 기본 아이디어를 복사기에 녹화한 다음 모든 사람이 이러한 개념으로 작업을 시작할 것이라고 기대했습니다. 결국 그것은 훌륭한 기술이었습니다.
순환적인 프로젝트 관리의 위험#
순환적인 프로젝트 관리 기술로 인해 필요한 기능을 실행하는 데 시간이 부족한 경우가 있습니다. 프로젝트 기간이 정해져 있기 때문에 처음 예상했던 것보다 더 적은 수의 기능이 추가될 것이 거의 확실합니다.
이는 타당한 우려이기는 하지만,폭포 접근 방식. 폭포수 접근 방식의 정의 단계에는 요구 사항에 대한 심층적인 조사가 수반됩니다. 이 분석을 통해 시간 관리가 개선될 가능성이 높습니다. 위에서 언급한 이유로 인해 실제로는 그렇지 않은 경우가 많습니다.
또한 이 접근 방식에서는 기능을 개발할 자금이 부족하기 때문에 기능이 생략되었습니다.
요구 사항은 주기적인 접근 방식으로 실용적으로 처리됩니다. 예를 들어, 주기에 따른 욕구는 다음과 같이 MoSCoW 기준(Stapleton, 2003)을 사용하여 분류될 수 있습니다.
- 필수 사항: 시스템에 중요한 요구 사항
- 가져야 할 것: 사용자가 진정으로 원하는 중요한 요구 사항
- 가질 수 있음: 쉽게 무시할 수 있는 바람직한 욕구
- 갖고 싶은 것: 이번에는 충족되지 않는 요구 사항: 나중에 충족할 수 있는 요구 사항
특정 기능을 더 이상 사용할 수 없는지 여부에 관계없이 DANS 프로젝트 관리자는 순환 작업이 폭포수 접근 방식보다 고객 만족도가 더 높다고 믿습니다. 어떤 경우든 기대치는 정기적으로 더욱 효과적으로 통제되며, 프로젝트는 처음에 예상했던 것보다 덜 복잡하더라도 정기적으로 효과적인 결과를 생성합니다.
잠재적인 단점 이해#
일반적으로 언급되는 XP의 단점 중 하나는 상당한 권한이 프로그래머에게 전달된다는 것입니다. 이 권한을 남용하는 경우 고객의 기술적 전문성 부족을 유리하게 이용할 수 있습니다. 이 시나리오를 피하려면 프로그래머와 고객의 이익을 모두 살펴볼 수 있는 프로젝트 리더가 필요합니다. 이러한 프로젝트 리더는 고객이 주기를 선택 및 계획하고, 선택 항목의 기술적 기반을 이해하기 쉽게 만들고, 관리 및 보고를 제공하는 데 도움을 줍니다.
마지막으로 XP의 또 다른 단점은 이 방법을 구현하려면 프로그래머, 관리자 및 소비자를 위한 높은 학습 곡선이 필요하다는 것입니다.
