폭포수
1. 설립 전 - Build & Fix 방식
정의
- 요구사항에 대해 일단 코드로 만든 후 계속 수정해 나가며 프로그램을 완성하는 방식
2. 설립 후 - 폭포수 방식
구조
- Build & Fix 와는 달리 좀 더 구체화되고 순차적으로 진행
- 분석 : 고객의 요구조건, 시스템 환경 등 타당성 검토 후 요구사항에 대한 명세를 작성
- 설계 : 요구사항의 명세를 바탕으로 SW의 전체 구조간의 관계, 상세 알고리즘 등을 세부적으로 설계
- 개발 / 구현 : 요구사항 명세를 준수하는 설계에 따라 직접 코딩하여 SW를 개발하는 단계
- 테스트 : 완성된 프로그램을 테스트하는 단계
- 유지보수 : 변화에 대비하는 과정
특징
- 절차적 : 순차적으로 진행
- 단계검증 : 각 단계별로 검증이 완료 후 다음 단계로 이동
- 하향식 접근 : 전 단계의 작업이 모두 완료 되어야 다음 진행이 가능한 방식
- 피드백 : 결함 발견시 전 단계로 돌아가는 피드백 단계 존재
장/단점
- 장점
- 전체 과정이 SW 생명주기와 일치하여 이해하기 쉬움
- 각 진행 단계 별 산출물(문서)이 확실하여, 진행중 및 진행 이후에도 관리가 용이
- 단점
- 각 단계가 종결 되어야 다음 단계 진행 가능
- 고객의 요구사항을 반영하기 어렵다
- 테스트 단계에서 발견된 중요 결함은 치명적인 문제가 될 수 있음
에자일 - 폭포수 문제점 해결!
정의
- 문서를 통한 개발 방법 보다 일정 주기를 가지고 실질적인 코딩을 통해 개발을 진행하여 그때 그때 필요한 고객의 요구사항을 더하고 수정하며 진행하는 방법론
장/단점
- 장점
- 제품에 대한 피드백을 많이 받아 제품의 질을 향상시키고, 고객 요구사항의 지속적인 변화에 맞춤
- 지속적인 테스트를 하기 때문에 버그들을 고치기 쉽다
- 단점
- 고객의 요구사항을 추가하고, 수정하는 작업이 반복되기 때문에 데드라인을 맞추기가 쉽지않음
- 만약 뒤늦게 제품을 다시 수정해야 하는 상황이 생긴다면 수정하고 시험하기를 다시 번복해야 함 ==> 많은 비용이 들어감
애자일 선언문
- 프로세스 도구 < 사람과 상호작용
- 광범위한 문서 < 실제 작동하는 제품
- 계약 협상 < 고객 협력
- 계획 따름 < 변화 대응
스크럼 방식
- [스크럼 용어 탄생] 럭비에서 나온 용어 ==> 사소한 반칙이 일어나면 그 주변으로 7~8명이 뭉쳐서 서로간의 힘겨루기를 하는 모양새를 보이는 모습이 방법론과 닮아있어서 이름을 붙임
출처 : https://needjarvis.tistory.com/317
- 주요 개념
- 5-9명으로 구성되는 소규모의 다기능팀이 제품 개발을 완성하기 위해 스프린트라고 불리우는 업무 주기를 반복
- 해야 할 일들의 목록에서 스프린트 동안 해야 하는 일들을 스스로 결정하고 완수하여 매 스프린트마다 결과물을 산출해냄
- 팀이 성과를 낼 수 있도록 조력하는 역할 => 스크럼 마스터
- 스크럼 마스터는 팀이 과제를 완수할 수 있도록 필요한 자원을 지원하거나 장애 요소를 제거하여 프로세스 인도
- 스프린트
- 과제가 진행되는 주기를 지칭하는 것
- 보통 1~4주로 구성
- 하나의 스프린트가 끝나면 곧바로 다음 스프린트가 시작됨
- 스크럼 실행 방식
- 팀, 제품 책임자, 스크럼 마스터가 참여하는 계획 회의로 부터 출발
- 1파트 : 무엇을 하는지 => 2파트 : 결정된 무엇을 어떻게 할지 다룸
- 매일 15분~30분 동안 스크럼 회의 진행
- 스프린트 회고를 통해 무엇이 효과가 있고, 무엇이 문제인지 자유롭게 논의하여 프로세스와 환경을 점검하고 조정
- 1~4주 주기로 반복되며 피드백과 학습을 통해 고객 요구 및 환경 변화에 대응 가능 ==> 고객 만족도 개선하고 , 더 빨리 제품 또는 기능을 출시 할 수 있게 만듬
참조 : https://hrbulletin.net/organizational-culture/%EC%95%A0%EC%9E%90%EC%9D%BC-%EB%B0%A9%EB%B2%95%EB%A1%A0%E2%91%A0-%EC%8A%A4%ED%81%AC%EB%9F%BCscrum/
데비옵스
- 애자일은 고객과의 상호작용 => 데브옵스는 개발팀과 운영팀간의 긴밀한 협력 관계 구축에 집중
- 개발자 + 운영자 역할을 합쳐지면서 => 더욱 민첩한 개발 및 배포 사이클을 가질 수 있음
참조 : https://engineering-skcc.github.io/devops/DevOps1-%EC%95%A0%EC%9E%90%EC%9D%BC%EA%B3%BC%EB%8D%B0%EB%B8%8C%EC%98%B5%EC%8A%A4/
폭포수(위) vs 에자일(아래) 비교 사진
(출처 : https://www.safaribooksonline.com/library/view/user-story-mapping/9781491904893/ch04.html)