1. 소프트웨어 개발 방법론
- 소프트웨어를 개발하기 위한 '구체적인 절차, 방법, 기술 등을 정리'한 것입니다. 이를 통해 개발자들이 프로젝트를 효율적으로 관리하고 소프트웨어를 더욱 품질 높게 개발할 수 있도록 도와줍니다.
- 소프트웨어 개발방법론으로는 대표적으로는 폭포수 모델 (Waterfall Model), 애자일 방법론 (Agile Methodologies), 린(Lean) 등이 있습니다.
1.1 개발 방법론 종류
| 개발 방법론 | 특징 |
|---|---|
| 폭포수 모델(Waterfall Model) | 순차적 개발 과정, 각 단계를 선행적으로 진행 |
| 애자일 방법론(Agile Methodologies) | 반복적이고 점진적인 개발 방법, 유연성과 빠른 적응력을 갖춤 |
| 린(Lean) | 낭비를 최소화하고 효율적인 생산 방식을 추구 |
| 스파이럴(Spiral) | 점진적이고 반복적인 개발 방법, 위험 분석과 평가를 강조 |
| 라디칼(RAD) | 짧은 시간 내에 빠른 개발을 목표로 함 |
| 프로토타이핑(Prototyping) | 초기 모델을 만들어 피드백을 받고 개선하는 과정으로 개발을 진행 |
1.2 폭포수 방법론
-
폭포수 방법론(Waterfall Methodology)은 소프트웨어 개발 방법론 중 하나로 개발 생명 주기를 폭포수가 내려오는 것처럼 순차적으로 ‘일련의 단계’로 나누어 개발하는 방법을 의미합니다.
-
각 단계는 이전 단계의 결과물을 입력으로 받아 다음 단계의 결과물을 출력하는 구조를 가지고 있습니다.
(방법론의 원칙적으로 완료된 단계(이전 단계)로 돌아갈 수는 없습니다.) -
계획 및 분석(Discover) - 설계(Design) - 개발(Develop) - 테스트 - 운영/유지보수 단계를 가집니다.
| 용어 | 설명 |
|---|---|
| 계획 및 분석(Discover) | 요구 분석, 문제 해결 방법 도출을 수행하는 단계 입니다. |
| 설계(Design) | 구조 설계, 디자인, 상세 설계를 수행하는 단계 입니다. |
| 개발(Develop) | 코딩, 모듈 테스트, 통합 테스트를 수행하는 단계 입니다. |
| 테스트 | 시스템 테스트, 사용자 테스트, 인수 테스트를 수행하는 단계 입니다. |
| 운영/유지보수 | 운영, 유지보수, 보완, 기능 추가를 수행하는 단계 입니다. |
1.3 애자일 방법론
-
애자일 방법론(Agile methodology)은 소프트웨어 개발 방법론 중 하나로 ‘반복적이고 점진적인 개발 방법’을 통해 개발을 진행하는 것을 특징으로 합니다.
-
개발 초기부터 고객의 요구 사항을 반영하여 빠르게 개발하고 그 과정에서 지속적으로 피드백을 받아 개발을 진행합니다.
-
각각의 단계는 계획 및 분석(Discover) - 설계(Design) - 개발(Develop) - 테스트단계를 '작은 단위의 사이클로 분리'하고 사이클이 종료가 되면 다음 사이클로 반복적으로 진행합니다.
-
애자일 방법론의 종류는 대표적으로 칸반(Kanban), 스크럼(Scrum), 익스트림 프로그래밍 (Extreme Programming, XP)이 존재합니다.
-
http://www.incodom.kr/%EC%95%A0%EC%9E%90%EC%9D%BC_%EB%B0%A9%EB%B2%95%EB%A1%A0
애자일 방법론의 주요 용어
| 용어 | 설명 |
|---|---|
| 스프린트(Sprint) | 애자일 방법론 중 스크럼(Scrum)에서 사용되는 용어로 고객 요구사항에 대한 개발을 정해진 기간 안에 완료하는 “작업 주기”를 의미합니다. |
| 백로그(Backlog) | 개발할 기능 또는 작업 목록입니다. 스프린트 전에 우선순위를 결정하고, 스프린트 동안 개발될 목록으로 사용됩니다. |
| 스탠드업 미팅(Stand-up Meeting) | 스크럼에서 사용되는 미팅으로, 매일 아침 팀원들이 모여 진행 상황과 문제를 공유하는 미팅입니다. |
| 이터레이션(Iteration) | 애자일 방법론에서 사용되는 용어로, 고객 요구사항을 단계적으로 수행하며, 반복적인 개발과 검증을 통해 소프트웨어를 개발하는 것을 의미합니다. |
| 인큐베이션(Incubation) | 애자일 방법론에서 사용되는 용어로, 새로운 아이디어나 기능을 개발하기 전에 실험적으로 검증하는 단계를 의미합니다. |
2. 애자일 방법론의 종류
2.1 칸반
-
칸반(Kanban)은 애자일 소프트웨어 개발 방법론 중 하나로 개발 과정에서 사용되는 “시각적인 작업 관리 도구”입니다.
-
개발 과정에서 발생하는 작업들이 '카드' 형태로 시각적으로 표시되어 있고 작업의 진행 상황을 실시간으로 파악할 수 있다는 특성이 있습니다.
-
각각의 작업이 어떤 상태인지(진행 중, 완료, 보류 등)를 파악하는 것이 쉽기 때문에, 개발 과정에서 일어나는 문제를 빠르게 파악하여 대처할 수 있습니다.
-
칸반은 칸반 보드로 물리적 보드(화이트보드 내의 구성), 디지털 보드(JIRA, Trello, Redmine, …)를 이용하여 운영합니다
2.2 스크럼
스크럼(Scrum)은 애자일 소프트웨어 개발 방법론 중 하나로 ‘프로젝트를 진행하는데 있어서 유연성과 적응성’을 강조하는 방법론입니다.
스크럼은 작은 팀으로 구성되어 각 팀원이 적극적으로 참여하여 프로젝트를 진행하는 방식을 취하며 개발 주기를 일정 기간으로 나누어 각 주기마다 일정한 목표를 설정하고 그 목표를 달성하도록 팀원들이 협력하여 일하는 방식을 취합니다. 이러한 방식으로 작업을 진행하면서 문제가 발생하면 팀원들끼리 빠르게 의사소통하여 문제를 해결하는 것이 스크럼의 핵심입니다.
스크럼(Scrum)의 수행과정
- 스크럼에서는 일정 기간 동안(보통 1~4주) 프로젝트를 진행하는 스프린트(Sprint)라는 주기를 사용합니다.
- 각 스프린트마다 목표를 설정하고 해당 목표를 달성하기 위해 필요한 작업을 백로그(Backlog)에서 우선순위에 따라 선정하여 진행합니다. 스프린트 중에는 매일 스탠드업 미팅(Stand-up Meeting)을 진행하여 진행 상황과 문제를 공유합니다.
- 스프린트가 끝나면 해당 스프린트에서 개발한 제품의 작동 여부를 검증합니다. 이러한 과정을 반복하여 제품을 완성해 나갑니다.
스크럼(Scrum)의 주요 용어
| 용어 | 설명 |
|---|---|
| 스프린트(Sprint) | 스크럼에서 사용되는 일정 기간(보통 1~4주) |
| 스프린트 백로그(Sprint Backlog) | 해당 스프린트에서 완료해야 할 작업을 우선순위에 따라 정리한 목록 |
| 제품 백로그(Product Backlog) | 제품의 모든 요구사항을 우선순위에 따라 정리한 목록 |
| 스크럼 마스터(Scrum Master) | 스크럼 프로세스를 관리하고 팀이 스크럼의 원칙을 따르도록 지원하는 역할 |
| 프로덕트 오너(Product Owner) | 제품 개발 프로젝트에서 고객 또는 사용자와의 의사소통을 중개하고 제품의 우선순위를 결정하는 역할 |
| 개발팀(Development Team) | 제품을 개발하는 역할을 하는 팀 |
| 스프린트 계획 회의(Sprint Planning Meeting) | 스프린트를 진행하기 전, 해당 스프린트에서 완료해야 할 작업을 선정하는 회의 |
| 데일리 스크럼 회의(Daily Scrum Meeting) | 매일 진행되는 짧은 회의로, 진행 상황과 문제를 공유함 |
| 스프린트 리뷰 미팅(Sprint Review Meeting) | 해당 스프린트에서 개발한 제품의 작동 여부를 검증하는 회의 |
| 스프린트 회고 미팅(Sprint Retrospective Meeting) | 해당 스프린트에서 진행한 프로세스와 문제점을 검토하고 개선점을 도출하는 회의 |
| 스크럼 이벤트(Scrum events) | 스크럼 프로세스에서 일어나는 이벤트로서 스프린트 계획 회의, 데일리 스크럼 회의, 스프린트 리뷰 미팅, 스프린트 회고 미팅 등이 있다. |
2.3 익스트림 프로그래밍
익스트림 프로그래밍(Extreme Programming, XP)은 애자일 소프트웨어 개발 방법론 중 하나로 ‘개발자 중심의 방법론’을 의미합니다.
고객과 개발자가 함께 일하며 고객이 원하는 기능을 우선순위에 따라 작은 단위로 나누어 개발을 합니다. 이를 통해 고객의 요구 사항을 빠르게 반영하고 문제가 발생했을 때 빠르게 대처할 수 있습니다.
기존의 전통적인 소프트웨어 개발 방법론과 다르게 빠르고 유연한 반복 개발 방식을 중심으로 합니다.익스트림 프로그램은 페어 프로그래밍, 테스트 주도 개발, 지속적인 통합, 단순한 설계, 적극적인 리펙토링등을 통해서 높은 소프트웨어 품질을 만듭니다.
| 실천 방법 | 설명 |
|---|---|
| Pair Programming | 두 명의 프로그래머가 함께 작업하여 코드를 작성하는 방법입니다. 한 명이 코드를 작성하고, 다른 한 명이 코드를 검토하고 지속적인 피드백을 제공하며 협업합니다. |
| Unit Test + TDD | 소프트웨어의 작은 부분인 유닛에 대한 테스트를 수행합니다. 유닛 테스트는 개별 함수 또는 모듈이 예상대로 작동하는지 확인하는 데 사용됩니다. |
| Pair Negotiation | 두 명의 사람이 함께 협상하여 문제를 해결하고, 결정을 내리는 과정입니다. 각각의 의견을 고려하며 협업하여 최선의 결론을 도출합니다. |
| Stand-up Meeting | 팀 구성원들이 매일 짧은 시간 동안 서로의 진행 상황과 장애물을 공유하는 미팅입니다. 팀의 커뮤니케이션과 협업을 도울 수 있는 기회가 제공됩니다. |
| Acceptance Test | 소프트웨어가 요구사항을 만족하는지 확인하는 테스트입니다. 사용자의 관점에서 시스템을 검증하며 사용자 승인을 받을 수 있는지 확인합니다. |
| Iteration Plan | 작은 주기로 소프트웨어를 개발하는 방법입니다. 각 이터레이션은 목표와 일정을 설정하고, 해당 이터레이션 동안 필요한 작업을 계획합니다. |
| Release Plan | 소프트웨어 제품을 출시하기 위한 계획입니다. 기능 및 버그 수정 등의 작업을 포함하여 출시 일정과 전략을 계획합니다. |
3. 스크럼 원칙과 가치, 사용목적
스크럼만 자세히 정리하는 이유는 칸반(Kanban)과 가장 많이 채택되는 애자일 방법론이기 때문입니다. 실무에서 스크럼을 채택한 이유와 스크럼만의 어떠한 강점이 있는지 학습을 목표로 정리합니다.
3.1 스크럼의 추구하는 '원칙'
- 스크럼 팀은 최적의 결과를 내기 위해서는 스스로를 조직하고, 지속적으로 개선할 수 있어야 합니다.
- 스크럼 팀은 개발 중인 제품의 품질과 효과적인 개발을 위해서는 실시간 검사, 적극적인 피드백, 지속적인 개선 등을 추구해야 합니다.
- 스크럼 팀은 제품의 원활한 진행을 위해 제품 백로그를 효과적으로 관리하고, 스프린트 백로그를 신속하게 조정할 수 있어야 합니다.
- 스크럼 팀은 개발자와 고객, 사용자, 스크럼 마스터 등 개발 과정에 참여하는 모든 이해관계자 간의 원활한 의사소통을 지원해야 합니다.
3.2 스크럼의 추구하는 '가치'
- 모든 이해관계자들과의 협력과 팀워크
- 작동하는 제품에 대한 집중
- 작업을 위한 열린 마음과 전문성
- 변화에 대한 적극적인 대처와 적응
3.3 스크럼을 사용해야 하는 이유
| 사용 이유 | 내용 |
|---|---|
| 투명성 | 모든 팀원이 작업 진행 상황과 이슈에 대해 인식할 수 있습니다. |
| 적응성 | 팀은 계속해서 변화하는 상황에 대응할 수 있습니다. |
| 생산성 | 스크럼은 팀의 생산성을 높이는 데 도움이 됩니다. |
| 고객 만족도 | 스크럼은 고객 요구사항을 반영하며, 고객 만족도를 높이는 데 도움이 됩니다. |
| 자기 조직성 | 스크럼은 팀원들이 스스로 문제를 해결할 수 있도록 자기 조직성을 높이는 데 도움이 됩니다. |
| 지속적인 개선 | 스크럼은 지속적인 개선을 통해 프로젝트의 품질을 높이는 데 도움이 됩니다. |
4. 스크럼의 계획과 역할
4.1 스크럼 이벤트
스크럼 방법론을 수행하는 데 있어서 계획을 세우고 진행을 하기 위한 용어들입니다.
| 주요 용어 | 설명 |
|---|---|
| 스프린트(Sprint) | 스크럼에서 사용되는 일정 기간(보통 1~4주)을 의미합니다. |
| 스프린트 백로그(Sprint Backlog) | 해당 스프린트에서 완료해야 할 작업을 우선순위에 따라 정리한 목록을 의미합니다. |
| 제품 백로그(Product Backlog) | 제품의 모든 요구사항을 우선순위에 따라 정리한 목록을 의미합니다. |
| 스크럼 이벤트(Scrum events) | 스크럼 프로세스에서 일어나는 이벤트로서 스프린트 계획 회의, 데일리 스크럼 회의, 스프린트 리뷰 미팅, 스프린트 회고 미팅 등이 있습니다. |
| 스프린트 계획 회의(Sprint Planning Meeting) | 스프린트를 진행하기 전, 해당 스프린트에서 완료해야 할 작업을 선정하는 회의를 의미합니다. |
| 데일리 스크럼 회의(Daily Scrum Meeting) | 매일 진행되는 짧은 회의로, 진행 상황과 문제를 공유하는 회의를 의미합니다. |
| 스프린트 리뷰 미팅(Sprint Review Meeting) | 해당 스프린트에서 개발한 제품의 작동 여부를 검증하는 회의를 의미합니다. |
| 스프린트 회고 미팅(Sprint Retrospective Meeting) | 해당 스프린트에서 진행한 프로세스와 문제점을 검토하고 개선점을 도출하는 회의를 의미합니다. |
4.2 스크럼 팀의 역할
스크럼 방법론에서의 각각의 역할을 의미하는 용어들입니다.
| 주요 용어 | 설명 |
|---|---|
| 제품 책임자(PO: Product Owner) | 제품 개발 프로젝트에서 고객 또는 사용자와의 의사소통을 중개하고 제품의 우선순위를 결정하는 역할을 수행합니다. |
| 스크럼 마스터(SM: Scrum Master) | 스크럼 프로세스를 이해하고, 팀이 스크럼을 잘 수행하도록 도와주는 역할을 수행합니다. |
| 개발팀(Development Team) | 제품 개발을 위해 스스로 조직되는 팀이며, 제품 책임자와 스크럼 마스터의 지도를 받는 역할을 수행합니다. |
4.3 스크럼(Scrum)의 수행과정
- 스크럼의 시작은 ‘스프린트 계획 회의(Sprint Planning Meeting)’를 통해서 스프린트 (보통 2~4주) 기간을 정합니다. : Sprint Planning
- 회의에서는 제품 개발을 위해서 개발을 해야 하는 ‘목표’를 지정하며 목표를 달성하기 위해 스크럼 마스터는 개발팀과 협의를 통해 ‘백로그’를 작성합니다. : Spring Backlog
- 도출된 백로그를 기반으로 개발팀 내에서 각각 백로그에 대한 역할을 지정합니다. : Daily Scrum
- 스프린트를 진행하면서 매일 스탠딩업 미팅(Stand-up Meeting)을 통해 간략한 미팅을 진행합니다. : Sprint Execution
- n차의 스프린트 기간이 종료가 되면 스프린트 리뷰 미팅(Sprint Review Meeting)을 통해 리뷰를 진행합니다.
(리뷰 기간에는 제품의 작동여부를 검증하며 제품의 책임자와 사용자가 검토하고 승인합니다) : Sprint Review - 제품 개발이 종료될 때까지 스프린트는 진행이 됩니다. 이러한 과정을 반복하면 제품을 완성해 나아갑니다. : Sprint Retrospective
스탠딩업 미팅(Stand-up Meeting)을 하는 이유가 무엇일까?
스탠딩업 미팅은 매일 진행되는 짧은 회의로 팀원들 간의 진행상황과 문제를 공유하여 문제를 빠르게 해결하고 팀원들이 서로의 일에 대해 파악을 하기 위한 목적으로 수행하며 스탠딩업 미팅을 함으로써 짧은 시간 내의 미팅을 종료하여 길어지는 회의에 대해서 스탠딩업을 함으로써 최소한으로 시간을 줄이기 위한 목적을 가지고 있습니다.
4.4 스프린트의 주기
스프린트의 주기는 2~4주 기간이 적절합니다. 그러나, 모두 이 기간을 사용하는 것은 아니고 팀의 크기나 업무의 복잡도 및 일정에 따라서 적절한 스프린트 주기를 찾는 ‘여러 번의 시도’가 필요합니다.
스프린트의 주기를 '1주'로 선택할 수도 있습니다. '개발 초기에 적절한 시기를 찾지 못한 경우' 빠른 피드백을 통해서 결과물을 얻은 뒤에 스프린트 기간을 조정합니다.
5. [참고] 스크럼과 칸반의 차이점
애자일 방법론 중에서 자주 사용이 되는 칸반(Kanban)과 비교하였을 때 어떤 차이를 가지는지 확인해 봅니다.
| 구분 | 스크럼(Scrum) | 칸반(Kanban) |
|---|---|---|
| 개발 주기 | 일정한 주기마다 스프린트를 진행하는 방식 | 지속적으로 작업을 진행하는 방식 |
| 역할 | 제품 책임자, 스크럼 마스터, 개발팀 | 없음 |
| 업무 처리 | 작업 목록을 스프린트 백로그로 관리하고, 스프린트 계획 회의, 스프린트 데일리 스크럼, 스프린트 회고 등의 이벤트를 거쳐 스프린트를 진행 | 작업 목록을 표현한 칸반 보드를 통해 작업을 관리하며, 작업 진행 상황을 체크리스트를 통해 확인 |
| 변경 | 스프린트 중에는 변경할 수 없음 | 언제든지 변경 가능 |
| 팀 규모 | 작은 팀에 적합 | 대형 프로젝트에 적합 |
6. 요약 : 폭포수 방법론, 애자일 방법론 비교
폭포수 방법론과 애자일 방법론을 비교하여서 각각에 대해 이해하고 비교합니다.
폭포수 방법론과 애자일 방법론 비교
| 분류 | 폭포수 방법론(Waterfall Methodology) | 애자일 방법론(Agile Methodology) |
|---|---|---|
| 개요 | 계획 중심, 선형적인 개발 방법 | 반복적이고 점진적인 개발 방법 |
| 프로세스 | 단계별로 엄격하게 분리된 개발 단계 | 반복적인 개발 단계 |
| 요구사항 | 초기에 명확하게 정의하고 변경 어려움 | 유연하게 대처 가능 |
| 테스트 | 개발 완료 후 테스트 | 개발 초기부터 테스트 |
| 방향성 | 예측 가능한 방향성 | 변경 가능한 방향성 |
| 비용 | 변경 및 오류 수정 비용이 높음 | 초기 비용이 낮으나 유지보수 비용 높음 |
| 적용 분야 | 큰 규모의 프로젝트 | 중간, 작은 규모의 프로젝트 |
| 장점 | 명확한 계획과 예측 가능성, 문서화 용이성 | 요구사항 변경 대처 용이, 고객 요구사항 반영 |
| 단점 | 변경 어려움, 유연성 부족, 반응성 떨어짐 | 계획 변경 어려움, 초기 비용 낮지 않음 |
결론적으로 서로간의 가장 큰 차이점은 '수행 단계의 반복 여부'입니다.
'폭포수 방법론' 같은 경우는 수행 과정에서 하나의 단계를 완료하게 되면 완료된 단계(이전 단계)로 돌아갈 수 없습니다. 그러나 '애자일 방법론'의 경우는 하나의 단계가 되는 과정을 쪼개서 단계를 수행하고 이전 단계로 돌아가서 수정을 하게 되는 시점이 된다면 돌아가서 수행을 할 수 있습니다.
7. 린 방법론
린 방법론(Lean Methodology)은 소프트웨어 개발 방법론 중 하나로 이전 제조 산업에서 비롯된 개발 방법론으로 ‘낭비를 최소화하고 가치를 최대화하는 것’을 목적으로 합니다.
- 린 방법론은 제품을 개발하는 전 과정에서 고객의 피드백을 수시로 반영하며, 불필요한 작업을 최소화하여 생산성을 높이는 것을 목표로 합니다.
- 린은 제조 산업에서 사용하는 방법을 소프트웨어 개발방법론과 결합하여 사용합니다. 린 방법론의 종류는 린 소프트웨어 개발 (LSD), 린 UX, 린 스타트업, 린 애자일, 린 시스템스 엔지니어링이 있습니다
| 주요 용어 | 설명 |
|---|---|
| MVVP(Minimum Viable Product) | 가능한 최소한의 기능으로 구성된 제품 또는 서비스 |
| A/B 테스트(A/B Test) | 두 가지 버전의 제품 또는 서비스를 비교하여 어느 것이 더 효과적인지를 테스트하는 방법 |
| 피벗(Pivot) | 실패한 가설이나 전략을 버리고 새로운 가설이나 전략을 시도하는 것 |
| 캔버스(Business Model Canvas) | 비즈니스 모델을 구성하는 주요 요소들을 시각적으로 정리한 도구 |
| 린 캔버스(Lean Canvas) | 캔버스를 린 방법론에 맞게 수정한 것으로, 제품 개발에 필요한 핵심 요소들을 시각적으로 정리한 도구입니다. |
7.1 린 스타트업(Lean Startup)
-
스타트업에서 사용되는 린 방법론 중 하나로 ‘작은 단위로 빠르게 실험하고 검증하는 것’을 중요시합니다.
-
특히 린 스트업의 핵심은 “적극적인 실험”입니다. 제품이나 서비스를 빠르게 출시한 후 시장의 피드백을 수집하고 그에 따라 제품이나 서비스를 조정합니다.
-
적극적인 고객 피드백 수집과 실험적인 개발 방법을 채용하여 제품 개발에 대한 초기 비용을 줄이고, 빠르게 실패하며 성공할 수 있는 방법을 모색합니다.
린 스타트업의 과정
- 아이디어 도출(IDEAS) → 가설 설정과 실험 설계(BUILD & PRODUCT) → 실험 실행과 피드백 수집(MEASURE) → 결과 분석 및 개선(DATA & LEANRN)
- 아이디어 도출 단계에서는 문제 발견과 고객 니즈 파악을 위한 시장 조사를 수행합니다.
- 가설 설정과 실험 설계 단계에서는 목표를 설정하고 가설을 설정하고 가설을 테스트할 수 있는 실험을 설계합니다.
- 실험 실행과 피드백 수집 단계에서는 설계한 실험을 실행하고 고객의 피드백을 수집합니다.
- 결과 분석과 개선 단계에서는 수집한 데이터를 분석하여 가설을 검증하고 제품이나 서비스를 개선합니다.
