목차
문제 해결 방법론
탑다운(Top-down)
탑다운 방법론은 문제 해결 과정에서 큰 그림을 먼저 파악하고 이를 기반으로 작은 문제들을 해결해 나가는 방법이다.
- 장점: 일반적으로 계획적이며 구체적인 목표를 가지고 접근할 수 있다.
- 단점: 전체적인 구조나 목표가 분명하지 않은 경우 문제 해결에 어려움이 있을 수 있다.
바텀업(Bottom-up)
바텀업 방법론은 문제 해결 과정에서 작은 문제들을 먼저 해결하고 이를 결합하여 큰 문제를 해결해 나가는 방법이다.
- 특징: 일반적으로 실험적이며 융통성이 있어, 문제 해결 과정에서 예상치 못한 결과가 나올 가능성이 있다.
- 유의점: 전체적인 구조나 목표를 설정하기 어려울 수 있다.
피벗(Pivot)
피벗 방법론은 문제 해결 과정에서 중요한 요소를 발견하고, 이를 중심으로 해결 방법을 바꾸는 방법이다. 이 방법론은 일반적으로 융통성이 있어 문제 해결 과정에서 예상치 못한 결과가 나올 가능성이 있지만, 이전 방법들이 실패한 경우 유용한 방법이 될 수 있다.
개발 방법론
애자일(Agile)
애자일 방법론(Agile Methodology)은 소프트웨어 개발 및 프로젝트 관리 분야에서 널리 사용되는 개발 방법론이다. 애자일 방법론은 프로젝트의 초기 계획 수립에 대한 엄격한 접근 방식에서 벗어나, 사용자 요구 사항을 충족하고 프로젝트 일정을 준수하는 것에 초점을 맞춘다.
애자일 방법론은 소규모 개발 팀에서 시작되어 대형 프로젝트에서도 적용된다. 이 방법론은 프로젝트를 작은 주기(스프린트)로 나누고, 각 주기마다 기능을 개발하고 테스트하며 고객의 피드백을 받는 방식으로 작업을 진행한다. 이러한 방식은 빠르게 변화하는 환경에서 더욱 민첩하고 유연하게 대응할 수 있도록 한다.
애자일 방법론은 대표적으로 스크럼(Scrum), 익스트림 프로그래밍(Extreme Programming, XP), 칸반(Kanban) 등이 있다.
스크럼(Scrum)
스크럼은 프로젝트를 진행하는 과정에서 변화를 수용하고 대처할 수 있는 프로세스다. 스크럼은 전체 프로젝트를 여러 개의 작은 단위로 쪼개서 작은 단위로 업무를 나누어 일정 주기마다 완료된 결과물을 보여주는 것이 특징이다.
이러한 단위를 스프린트(Sprint)라고 하며, 스프린트 기간 동안 개발자들은 무엇을 해야 하는지, 어떤 목표를 달성해야 하는지를 명확하게 정의한다. 스프린트의 기간은 보통 2주부터 1개월 정도로 설정되며, 각 스프린트가 끝나면 개발자들은 스프린트에서 완성된 결과물을 검토하고 피드백을 주고받는다.
스크럼에서는 각각의 개발자가 자율적으로 일을 수행하며, 일정 기간 동안 작업이 완료되지 않은 경우 다음 스프린트에 이어서 작업을 진행한다. 또한, 매일 정해진 시간에 스크럼 미팅을 진행하여 해당 스프린트에서 진행되는 작업 상황을 공유하고 문제를 해결할 수 있도록 지원한다.
- 강점: 프로젝트의 진행 상황을 실시간으로 확인할 수 있어 변화에 빠르게 대처할 수 있다. 개발자들 간의 협력과 커뮤니케이션을 촉진하여 프로젝트의 진행 속도와 품질을 높일 수 있다.
- 유의점: 각 스프린트마다 목표를 정확하게 설정하고 일정에 맞춰 완료해야 하기 때문에, 초기 계획 수립이 중요하다. 또한, 스프린트 기간 동안 개발자들이 목표를 달성할 수 있도록 적절한 지원과 환경이 제공되어야 한다.
익스트림 프로그래밍(XP)
익스트림 프로그래밍(Extreme Programming, XP)은 소프트웨어 개발 프로세스에서 사용되는 방법론 중 하나로, 소규모 프로젝트에서 많이 사용된다. 빠르게 변화하는 요구 사항에 대응하기 위해 탄생한 방법론이다.
이 방법론에서는 짧은 주기로 릴리즈를 하고, 이를 통해 사용자의 요구 사항을 빠르게 확인하고 개발을 진행한다. 또한, 테스트 주도 개발(Test-Driven Development, TDD)과 같은 실천 방법을 사용하여 높은 코드 품질을 유지하며, 자동화된 테스트를 수행한다. 개발 실천 방법들을 정리하면 다음과 같다.
- 페어 프로그래밍(Pair Programming) : 두 명의 개발자가 하나의 컴퓨터에서 함께 작업하는 것. 이를 통해 코드 품질을 향상시키고 지식 공유를 촉진한다.
- 단순성(Simplicity) : 가능한 단순한 설계를 만든다. 이를 통해 코드 유지보수성과 확장성을 높인다.
- 테스트 주도 개발(Test-Driven Development, TDD) : 먼저 테스트를 작성하고, 그에 맞는 코드를 작성한다. 이를 통해 코드 품질을 높이고 결함을 줄인다.
- 지속적인 통합(Continuous Integration) : 코드 변경 시 자동으로 빌드하고 테스트를 수행한다. 이를 통해 개발자들은 자신의 코드 변경이 전체 시스템에 어떤 영향을 미치는지 빠르게 확인할 수 있다.
- 짧은 주기의 릴리즈(Short Releases) : 가능한 짧은 주기로 제품을 출시한다. 이를 통해 빠르게 사용자의 요구 사항을 확인하고 반영할 수 있다.
- 고객 참여(Customer Involvement) : 고객과 끊임없이 소통하며, 요구 사항을 파악하고 변경에 대응한다.
칸반(Kanban)
칸반(Kanban)은 소프트웨어 개발 프로세스에서 사용되는 애자일 방법론 중 하나이다. 원래 일본에서 생산 방법으로 사용되다가 소프트웨어 개발 분야로 확장되었다.
칸반은 기존의 소프트웨어 개발 방법론과는 달리, 작업의 흐름을 시각화하고, 작업의 흐름을 최적화하면서 지속적인 개선을 이루어내는 방법이다. 이를 위해, 작업의 흐름을 보드 형태로 시각화하고, 작업의 상태를 컬럼 형태로 분류한다. 이러한 보드를 칸반보드라 한다.
칸반 보드는 일반적으로 To Do, In Progress, Done과 같은 세 개 이상의 컬럼으로 구성된다. 각각의 칸반 카드는 특정 작업을 나타내며, 이 카드는 각 컬럼을 이동하면서 작업이 진행되는 과정을 표현한다. 노션과 트렐로 등의 협업 툴에서는 칸반 보드를 꼭 제공한다.
작업자들은 각각의 칸반 카드를 이동하면서 작업을 수행하고, 이를 통해 전체 작업의 흐름을 파악하고 개선한다. 칸반은 작업의 우선순위를 지정하거나, 릴리즈 계획을 세우는 것보다는 작업의 흐름에 중점을 둔다. 이를 통해, 작업의 우선순위나 릴리즈 계획을 변경하지 않으면서도 더 나은 작업 흐름을 구축할 수 있다. 또한, 작업의 흐름을 지속적으로 개선하면서 진행하므로, 칸반은 지속적인 개선과 함께 진행되는 애자일 방법론으로 평가받는다.
폭포수(Waterfall) 방법론
폭포수 모델(Waterfall Model)은 개발 프로세스가 순차적인 과정을 따라 진행되는 방법론이다.
각 단계가 선행되어야 하며, 한 단계가 완료되면 다음 단계로 진행 초기에 정해진 요구사항이나 계획을 바탕으로 진행되므로 변경에 대한 대처가 어렵다.
프로젝트의 초기 단계에서만 요구사항을 수집하고, 이후에는 변경할 수 없다는 가정에 기반하기 때문에, 요구사항이 변경되는 경우에는 전체적인 프로젝트 일정에 큰 영향을 미칠 수 있다. 또 이전 단계의 결과물이 다음 단계에서의 입력물이 되는 특성 때문에 전체적인 프로세스의 흐름을 파악하기 어렵다는 단점이 있다.
