📖 폭포수 모델
💬 개념
- 전통적인 개발 프로세스
- {요구 분석 => 기획 => 디자인 => 개발 => 테스트 => 출시} 순서로 진행
💬 문제점
- 요구 사항 분석을 정확히 하지못하거나 기획이 변경될 때 개발자는
수정을 해야 되는 이슈가 발생하며 1~4단계까지를 반복하게 됨
- 반복이 될수록 코드의 품질은 떨어지고 요구사항은 모두 충족되지 않는 상태의 결과물이 나옴
📖 애자일 방법론
💬 개념
- Agile : 민첩함, 기민함, 날렵함
- 요구사항이 변화하는 것을 당연한 전제로 두고, 변화하는 요구사항에
민첩하게, 기민하게 날렵하게 대응하며 소프트웨어를 개발하기위한 방법에 대한 이론
💬 폭포수 모델과 다른점
- 요구 분석, 기획 등 전체 프로젝트에 대한 모든 문서를 만들고 해당 작업들이 모드 끝난 이후
개발에 들어가던 워터폴 방식과는 달리 애자일은 기능 단위의 프로토타입을 기반 작업
- 쉽게 말해 좀 더 작은 단위로 개발을 해서 해당 부분을 직접 고객에게 선보이고 피드백을
빠르게 전달받아 수정이나 이슈 처리에 대한 기민한 대응을 하자는 것
- 주의할 점은 좀 더 작은 단위의 개발을 한다고 해서 퍼즐 처럼 조각 조각 내서 개발 후
하나로 합치는 것이 아닌 완벽하지는 않지만 고객의 요구사항을 증명 할 수 있는 개발을 하여
피드백을 받고 요구사항을 반영하는 것
💬 종류
📖 스크럼(Scrum)
💬 개념
- 5~9명으로 구성되는 소규모의 다기능 팀이 제품 개발을 완성하기 위해 스프린트(sprint)라고 불리우는 업무 주기를 반복
💬 주요 용어
- 백 로그(Backlog) : 프로젝트 수행에 필요한 사항에 대한 목록
- 스프린트(Sprint) : 반복적인 개발주기, 이터레이션(iteration)이라고도 함
보통 1주 ~ 4주의 기간을 상황과 조직에 맞게 선정한다.
- 스프린트 백로그(Sprint Backlog) : 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
- 제품 백로그(Product Backlog) : 전체 기간동안 개발할 백로그, 개발할 제품에 대한 요구 사항 목록
- Product Owner(PO) :
제품 책임자, 제품에 대한 요구사항, 백로그를 작성하는 주체.
보통 소프트웨어 개발자보다는 제품을 사용할 고객이나 비즈니스 요구사항을 정의할 수 있는 사람이 좋다.
- Scrum Master(SM) : 프로젝트 관리자, 스크럼이 잘 수행될 수 있도록 도와주는 역할
최대한 객관적인 시각에서 스크럼의 원칙들이 잘 적용될 수 있도록 이끌어주고 문제를 해결하는 역할
팀마다 성향이나 일하는 방식이 다르므로 해당 팀에 따라 팀원들의 목소리에 귀를 귀울이고 PO 및 외부 관계자들과 타협을 맡기도 함
💬 스크럼 프로세스
- PO가 제품 백로그를 작성한다.
- 스크럼 팀원 전체가 스프린트 계획 미팅을 진행한다. (스프린트 목표 설정, 백로그 작성)
- 스프린트 주기(약 1 ~ 4주)동안 프로젝트를 진행한다.
- 매일 스크럼 미팅(Daily Scrum Meeting)을 통해 각자의 이슈를 공유한다.
- 스프린트 종료 시 모든 이해관계자가 모인 자리에서 회의(Sprint Review)를 진행한다. 중요한 소스 6. 코드 리뷰 등 팀원들의 산출물을 함께 살펴본다.
- 스프린트 회고(Sprint Retrospective).
- 스프린트 기간 중 잘한 것, 다음 스프린트 시 개선할 점 등을 도출하며 한 단계 발전된 팀으로
다음 스프린트를 수행할 준비를 한다.
- 다시 1번으로 돌아가 반복한다.
📖 칸반(Canvan)
💬 개념
- 연속적 흐름 처리 방식
- 이슈는 큐에 입력되고 개발 프로세스에 따라 당겨짐
- 칸반 보드로 시각화되고 각 단계를 열로 표시
- 가장 핵심은 "Work-In-Process(WIP)를 제한하자" 임
- 쉽게말하면 멀티 태스킹 그만하자..
💬 방법
- 수영 레인(SwimLane)이라는 행으로 나누고 우선순위가 낮은 이슈들을 아래에 배치
- TO-TO의 행에서 우선 순위에 따라 이슈를 처리
- 한번 이슈에 처리를 시작하면 해당 이슈를 처리한 후 다음 이슈 확인하고 업무 진행
📖 어떨 때 어느 기반으로 애자일 방법론을 사용할까?
- 프로젝트 같은 종료 일이 정해져야 하는 업무가 많이 발생하는 경우는 스크럼
- 지속적인 업무를 다루며 프로젝트 개발 및 ops까지 함께 다뤄야 하는 상대적으로
작은 단위의 팀에서는 칸반을 사용하는 것이 효율적
💬 Hotfix 라는 이슈를 다루는 관점에 대한 스크럼과 칸반의 차이
- HotFix란 말 그대로 예측되지 않았던 요청
- 스크럼 에서는 Hotfix는 해당 스프린트에 절대 넣지 않는다
1. 스프린트 진행 중 발생하는 모든 Hotfix는 무조건 다음 스프린트의 백 로그로 쌓이게 되고
다음의 업무가 됨
- 칸반 에서는 Hotfix 또한 바로 프로젝트 backlog 넣는다
1. 우선순위가 높다면 바로바로 처리됨
👀 마무리
- 정리하면서 마무리를 처음 남겨보는데 이건 정말 팀프로젝트하기전에 알고 가야할 지식인거같다
- 거의 Github사용방법과 맞먹는 수준이다
💡 답변
스프린트, 칸반에 대해 익숙? 아는가
익숙하진 않지만 알고있습니다. 애자일 방법론의 도구?들로 스프린트는 스크럼이라는 방법론의
개발 주기입니다. 스크림의 핵심은 목표를 설정해두고 단거리 달리기하듯이 집중적으로 진행하는
방법이고 중간에 hotfix같은 것이 발생하면 일단 백로그에는 넣어두는데 스프린트에 포함하지는
않습니다.
칸반의 핵심은 work in process를 제한하는 것입니다. 간단하게 멀티 태스킹 그만하고
칸반 보드에 우선순위 바탕으로 시각화된 이슈를 하나씩 처리하자는 겁니다.
면접 준비하면서 자세히 알게되었는데 프로젝트할 때 적용을 못해봐서 아쉽습니다.
