[PM교육] 제품 개발 방법론

[ 2일차. 제품 개발 방법론 ]

 

오늘은 제품 개발 방법론의 종류에 대해 알아보고 각 특징에 대해서 학습할 것 이다. 

각 제품 개발 방법론의 장단점에 대하여 학습하고 방법론의 선택 기준에 대해 얘기해볼 것 이다. 

 

제품 개발 방법론 Oerview

 

---

1. RAD(Rapid Application Development) 

RAD는 1980년대 후반에 나온 소프트웨어 개발 방식 중 하나로, 빠른 프로토타이밍과 피드백을 통해 소프트웨어를 신속하게 개발하는 방법론이다. 이 방식은 사용자의 요구 사항을 빠르게 반영하고 반복적인 개발을 통해 최종 제품의 품질을 높이는 것을 목표로 한다.

RAD가 출현하게 된 배경은 아래와 같다. 

1. 빠르게 변화하는 비즈니스 환경 대응 : 전통적인 개발 방법론이 대규모 프로젝트에서 느리고 유연성이 부족
2. 사용자의 요구 변화 : 사용자의 요구 사항이 변동되는 경우, 변경 사항에 대한 유연성이 떨어짐
3. 효율적인 개발 프로세스 필요성 : 반복적인 프로토타이핑과 즉각적인 피드백을 통한 효율적인 개발 필요 

출현 배경에서 예측할 수 있듯 RAD의 대표적인 특징은 프로토타이핑 중심, 짧은 개발 주기, 반복적 개발, 사용자 중심, 모듈화 등이 있다.

 

RAD는 단기간(2-3개월)내에 시스템 제작이 필요한 경우, 요구사항이 잘 알려진 경우, 기술적 위험이 적은 경우, 사용자가 라이프사이클 전반에 걸쳐 참여할 경우, 예산이 높게 측정된 경우 사용하기에 적합한 개발 방식이다. 

 

 

---

2. Waterfall

 

 1970년대 이전 소프트웨어 개발은 대규모 프로젝트가 많았다. 이런 소프트웨어 프로젝트는 일반적으로 요구사항이 명확하게 정의되어 있고 변경이 적은 경우가 많았는데 제조 및 건축/건설 프로젝트에서 단계적 개발 방식을 따라 소프트웨어 개발에도 적용할 수 있다는 생각을 이끌어 냈다. 

 

 Waterfall 모델은 제조 및 건축/건설업에서 영감을 받아  각 단계를 확실하게 마무리한 후에 다음 단계로 넘어가는 방식으로 진행된다. 그렇기때문에 체계적인 관리와 문서화를 통한 통제와 안정성을 제공할 수 있다. 

 

 Waterall 모델의 장단점은 아래와 같다. 

장점	단점
1. 명확한 구조로 각 단계가 분명히 정의되어있어서 프로젝트 진행 상황을 관리하고 추적하는데 용이함 2. 개발 도중 요구 사항이 변경되는 일이 적음 3. 단계별 명확한 목표 설정을 통해 관리자가 일정과 비용을 예측하고 조정하기에 용이함 4. 철저한 문서화로 인해 새로운 팀원이 투입되더라도 빠르게 이해 가능 / 향후 유지보수 도움	1. 각 단계를 완료한 후에는 수정이 어려움 2. 프로젝트 전체가 완료되기까지 시간이 걸릴 수 있으며 빠른 결과물을 필요로 할때는 부적합 3. 후반 테스트 단계에서 오류나 문제가 발생하는 경우가 많아 수정 비용 증가 확률 높음  4. 제품이 완성되기 전까지 사용자가 시스템을 경험하지 못하기 때문에 최종 제품이 사용자 기대와 다를 수 있음

 

이러한 장단점에 따라 Waterfall은 아래와 같은 시기에 사용하는 것이 적합하다. 

• 고객의 요구 사항이 잘 알려져 있고 고정되어 있는 경우
• 요구사항의 범위 변경은 기대하지 않고 고정된 가격 계약으로 작업하고 있는 경우
• 고객이 인지하고 있는 리스크와 우려하는 것을 정확하게 미리 알고있는 경우
• 규모가 크지 않고 프로젝트 개발 업무가 복잡하지 않으면서 간단하거나 여러 번 해본적이 있어 숙달 된 경우
• 질서 정연하고 예측 가능한 프로젝트로 작업하고 있는 경우 

 

---

3. Agile

3.1 Agile 방법론

 

 1990년대와 2000년대 초반, 소프트웨어 프로젝트가 점점 더 복잡해지면서 고객 요구사항이 자주 변하고 개발 주기 동안 시장의 변화에도 민첩하게 대응할 필요성이 커졌다. 기존의 waterfall 모델은 이러한 변화에 유연하게 대응하기 어려웠고 프로젝트의 실패율(%)이 높아지는 문제가 발생했다. 

 

 Waterfall 모델에서의 늦은 피드백과 긴 개발 주기가 문제로 지적되면서 반복적인 피드백을 통해 개선하는 방법론의 필요성이 대두되었고, 고객의 요구를 충족시키는 것의 중요성이 드러나며 고객과의 긴밀한 협력을 통한 개발 과정이 더욱 강조되었다. 

 

 이러한 배경 속에서 등장한 Agile은 waterfall과는 상반되는 특징들을 갖는다. 

• 반복적이고 점진적인 개발 : 프로젝트를 Sprint(여러개의 작은 단위)로 나누어 각 Sprint를 일정 기간동안(1-4주) 프로젝트 진행 
• 지속적인 피드백 : 각 개발 주기마다 사용자의 피드백을 받아 점진적으로 개선 
• 자율적이고 협력적인 팀
• 문서의 경량화
• 고객과의 긴밀한 협력

장점	단점
- 고객 요구 사항이 자주 변동되거나 불확실한 경우에도 신속하게 대응할 수 있는 유연성을 갖음 - 문제를 일찍 발견하고 빠르게 수정할 수 있어 프로젝트  실패 확률이 낮아짐(리스크 감소 효과) - 짧은 개발 주기(sprint)마다 실행가능한 sw를 제공하므로 결과를 빠르게 확인할 수 있고, 그만큼 빠른 피드백을 제공받을 수 있음 - 지속적인 사용자 피드백을 통해 최종 제품이 고객의 기대와 일치하는 경우가 많음	- 고객과의 지속적인 협력이 중요하지만, 고객이 원하는 것이 명확하지 않고나 요구사항이 빈번하게 바뀌면 혼란스러울 수 있음 - 요구사항의 점진적인 확장으로 인해 프로젝트의 범위와 예산의 예측 및 관리가 어려움 - 문서화가 경량화되어 이루어지기 때문에 인수 인계하거나 유지 보수를 위한 문서가 부족할 수 있음 - 팀의 자율성이 크기 때문에 경험이 적거나 역량이 낮은 팀의 경우에는 오히려 비효율적일 수 있음

 

 

3.2 Agile 조직 

이러한 Agile을 조직에 적용하기 위해서 Agile 조직이 등장하게 된다. Agile 조직이란 무엇일까?

 

 VUCA(변동성, 불확실성, 복잡성, 모호성) 시대에서 유연하게 적응할 수 있는 능력을 가진 조직을 의미한다. 애자일 원칙에 따라 작은 팀이 자율적으로 일하며, 고객 중심으로 가치를 창출하고, 지속적인 피드백을 통해 개선을 추구한다. Agile 조직은 디지털 혁명으로 인한 기술과 시장의 급격한 변화와 고객 요구가 더욱 다양하고 빠르게 변화함에 따라 증가한 복잡성에 기존의 수직적 의사결정 구조가 비효율적이기에 Agile 방법론의 등장과 함께 출현하게 된다. 

 

 스타트업이 먼저 Agile 조직을 도입했고, 이들의 성공 사례로 인해 다양한 규모의 기업들이 서로 뒤쳐지지 않고 경쟁에서 지지 않기 위해 앞다투어 Agile 조직을 형성시켰다. 

 

 하지만 기존의 Watefall 방식의 수직적 구조가 익숙했던 기업을은 Agile 도입 시 다양한 어려운 점들이 발생했다. 

조직에서 Agile을 도입할 때 어떤 점이 가장 어려웠을까? 도입에 실패했다면 그 이유는 무엇일까?

 

Agile 도입 시 어려운 점
상명하달의 기존 조직 문화와의 충돌	기존 리더의 역할 변화	명확한 목표와 KPI 부족	조직 내 역할 모호성	조직 전체에 걸친 일관성 부족

 

Agile 도입 실패 이유 (현실과의 거리)
부분적인 애자일 도입으로 인한 충돌	애자일 원칙의 오해  : 애자일은 단순한 프로세스 변화가 아닌 문화적 변화가 필요	리더십의 미비한 지원	기존의 성과 평가  체계 유지	애자일 코칭과 교육 부족

 

 

---

4. 12가지 원칙에서 바라본 Waterfall과 Agile 

원칙	Agile	Waterfall
#1. 고객 만족	고객 요구를 우선시하며, 프로젝트 진행 중에도 피드백을 수용	모든 요구 사항이 사전에 결정되고, 완료 후 결과물을 전달하므로 피드백 반영이 낮음
#2. 변화에 대한 수용	요구 사항 변경에 유연하게 대응 가능	초기에 고정된 요구 사항에 따르므로 변경 사항 반영이 어려움
#3. 짧은 주기의 가치 제공	짧은 개발 주기(Sprint)를 통해 작은 단위의 기능을 빠르게 제공하고, 이를 반복적으로 개선	단계별로 진행되며, 결과물은 마지막 단계에서 전체적으로 제공
#4. 협업 중심	고객과 팀 간의 지속적인 협업을 강조하며, 고객의 피드백을 주기적으로 반영	고객과의 상호작용은 주로 프로젝트의 초기와 완료 후에만 발생
#5. 동기부여된 팀 중심	팀원들에게 자율성 부여, 자기주도적으로 프로젝트를 이끌어감	상위 관리자가 결정을 내리고, 팀원들은 계획에 따라 작업을 수행
#6. 직접적인 대면 커뮤니케이션	대면 커뮤니케이션 선호, 팀 내 원활한 소통을 위한 환경 조성	문서화에 의존, 대면 커뮤니케이션보다는 문서 중심의 소통이 많음
#7. 작동하는 소프트웨어 중심	작동하는 소프트웨어를 진척의 주요 척도로 삼고 일정한 주기로 소프트웨어를 테스트하고 배포	단계별 산출물을 기준으로 진행을 측정하며 실제 소프트웨어는 마지막에만 완성
#8. 지속 가능한 개발	팀이 일정한 속도로 지속적으로 개발 할 수 있도록 설계하여 균형 잡힌 속도를 유지함	일정이 고정되어 있어 마감 기한에 따라 속도를 조절(마지막 단계에 과도한 업무량이 집중되기도 함)
#9. 기술적 우수성과 디자인 개선	지속적인 기술 개선과 설계를 통해 시스템의 유연성과 품질을 높임	기술적 요구사항은 초기에 모두 정의되고, 진행 중 수정이 어려움
#10. 단순성	필요 이상의 작업을 하지 않는 것이 중요하며 요구되는 기능만 개발	처음부터 모든 요구 사항을 충족하려하기 때문에 복잡성이 초기에 결정되며 필요 이상으로 많은 작업이 들어갈 수 있음
#11. 자기 조직화 된 팀	팀은 스스로 조직되고 의사결정 권한을 가지며 개발자들이 문제 해결 방법을 결정하는 갖음	상위 관리자가 팀을 조직하고 팀원들에게 구체적인 지침을 제공
#12. 정기적 성찰과 조정	sprint마다 팀이 정기적으로 성찰하고 개선점을 찾아 작업 방식을 조정	프로젝트가 끝날때까지 중간 평가나 조정 없이 한 번에 진행되며 피드백 반영이 늦음