W8D1 : 워터폴, 애자일

본 게시글은 [코드스테이츠 PMB 16기]에서 제공한 자료를 학습 후

복습 용도로 정리한 개인적인 글임을 알립니다.  

 

 

강의 및 리뷰 / 추가 학습자료(읽기, 영상) / 동기들의 과제 /디스코드  채널 오픈 스퀘어에 올라온 내용 / Q&A 세션 질의응답 

 

 

아티클 읽으면 내용 추가하기! 

---

 

학습 목표와 주요 개념 

 

- 워터폴, 애자일 프로세스
- 각각 무엇이고, 어떻게 다르며, 왜 필요한지

 

---

 

프로덕트 개발 라이프 사이클 (제품 개발 생애주기) 

 

PM은 What to build (기획) 과, How to build (창출)을 통해

문제를 해결하고 반복 개선해 나가면서 점차 거시적인 관점에서 장기적인 전략 필요

 

좋은 제품을 제때 출시해 내는 건 중요하니까 pm은 기획 뿐 아니라 
제품 개발 생애주기를 잘 관리해야 한다.

1. 기회 포착 및 계획
2. 솔루션 디자인 : 기회를 바탕으로 문제를 정의하고, 그 문제에 대응하는 솔루션을 도출, 정의합니다.
3. 솔루션 구축 : 디자인팀과 개발팀과 협업하여 실제로 제작.
4. 솔루션 공유 : 팀 또는 고객과 공유하고 피드백을 받는 과정, 마케팅 요소 포함
5. 솔루션 평가 : 데이터 분석은 이 과정에서 많이 사용.

 

---

워터폴, 애자일

분류	워터폴	애자일
핵심 이해관계자	클라이언트	고객
기획 문서	모든 게 들어간 최종 문서	그때그때. 문서에 집착X
작업 흐름	탑-다운	수평-동시
단점	리스크 발생하면 수정이 힘듬	관리, 계획이 잘 안됨
결과물	클라이언트의 요구사항을 다 갖춘 최종템	mvp 만들고 고객 간 보고 반복

 

• 기획 문서
  • W. 문제, 인사이트 + 이해관계자의 모든 요구사항 + 솔루션
    = 최종 기획 문서  
  • A. 고객과 주요 이해관계자도 함께 프로젝트 개념화, 브레인스토밍, 정의, 우선순위 설정, 필요 자원, 예산 책정을 논의 가능.
•  작업 흐름
  • W. 탑-다운 방식: 클라이언트, 높으신 분 → 기획 → 개발, 디자인 
  • A. 기획-디자인-개발팀이 자주 소통해서 서로 작업에 관여하기에 리스크를 사전에 방지
• 과정 차이
  - 설계: (공통) ux 전문가가 고객 등을 참고해서 요소 결정할 수 있음
  - W. 디자인+개발 단계 / A. 스크럼 마스터 참여, 개발자 스프린트
  - 테스팅: W. 클라이언트 요구사항 / A. 고객 요구사항을 충족하는지 확인
  - 최종 결과물 전달: 클라이언트(고객)에게.
  - W. 유지보수: 클라이언트는 변경을 요청할 수 있다. 프로젝트 비용과 시간은 추가될 수 있다.
    A. 피드백: 팀이 전체 개발 프로세스를 회고하며 제품이나 팀의 성과를 개선하는 방법을 검토한다.

 

 

등장 배경

초기 소프트웨어 시장 1950~60년대의 고객은

주로 규모가 큰 조직인 군인, 관리자, 정부, 엔지니어 등 군사, 정부, 대형 기업들의 프로젝트였습니다.
목적이 명확했기 때문에 처음부터 완벽한 계획을 갖추고 이에 맞게 개발하는 절차가 중요했습니다

하지만 90년대를 지나면서 SW 분야가 넓어지고

개인용 컴퓨터(pc)가 보급되니까 일반 대중들이 고객이 되었습니다. 따라서 트렌드 따라잡기 위해 애자일 등장~ 

 

참고

워터폴(Waterfall) 개발 방법론은 소프트웨어 개발의 프로세스를 순차적으로 진행하는 모델입니다. 각 단계는 완료될 때까지 기다리며, 다음 단계로 넘어가기 전에 전체 결과물이 완전하게 검토되어야 합니다. 이 모델은 프로젝트의 전체 과정을 정확하게 예측하고, 규정적인 관리 프로세스와 높은 품질 표준을 요구하는 방법론 

장점: 간단하고 쉽게 이해하고 사용할 수 있으므로 개발 프로세스를 보다 쉽게 관리하고 제어할 수 있습니다.
요구사항이 명확하고 안정적인 프로젝트에 적합하며, 변경 빈도와 심각성이 적습니다.
명확하고 명확한 단계를 통해 진행 상황을 추적하고 개선할 수 있는 영역을 쉽게 식별할 수 있습니다.

단점: 유연성이 부족하고 개발 도중 요구사항을 변경할 수 없어 재작업 및 비용 증가로 이어질 수 있습니다.
요구사항이 자주 변경될 수 있는 일부 소프트웨어 개발 프로젝트의 예측 불가능한 특성을 수용하지 않습니다.
이전 단계의 피드백과 학습이 이후 단계에 영향을 미쳐 개선 기회를 놓치게 됩니다.
실제 프로젝트에서는 항상 가능하지 않은 ‘단계의 선형 진행’을 가정합니다. 

워터폴 모델은 다음과 같은 특성을 가진 프로젝트에 적합합니다.
명확하고 안정적인 요구사항: 개발 프로세스는 개발 프로세스 중에 요구사항이 알려져 있고 변경될 가능성이 없다고 가정하여 범위와 요구사항이 명확한 프로젝트에 적합하다.
예측 가능하고 반복 가능한 프로세스: 이전 버전에 대한 최소한의 변경으로 개발이 필요한 소프트웨어의 경우처럼 개발 과정을 쉽게 반복할 수 있는 프로젝트는 폭포수 모델에 적합하다.
목표가 명확한 소규모 프로젝트: 목표, 성과물 및 마감일이 명확하고 명확한 소규모 프로젝트는 폭포수 모델에 적합합니다.
규제가 엄격한 사업: 의료 소프트웨어 개발의 경우처럼 엄격한 규제와 가이드라인이 필요한 사업은 폭포수 모델에 적합하다. 일반적으로 워터폴 모델은 개발 프로세스가 예측 가능하고 쉽게 관리 및 제어할 수 있는 요구사항이 명확하고 안정적인 프로젝트에 적합한 선택이다. 

워터폴은 그러면 어디에 쓰일까요?

• 정부주도의 개발
• 장기전
• B2B
• 공공발주
• 요구사항이 미리 잘 정리 되어 있는 조직
  예) 대기업 신규 사업 런칭
• 고객 요구를 확실히 아는 경우
• 결과물에 대한 목표가 뚜렷한 경우
• 목표가 명확한 업무
• 회사 내부 프로그램
• si 회사

---

애자일 프로세스의 원리 

 

• Product Owner(PO) vs Product Manager(PM)
  
  PO는 애자일 팀 관리
  PM은 제품의 비전을 설정하고 고객의 문제를 해결하는 제품을 만드는 방향을 결정.
  
  제품 팀을 운영한다는 점은 같다. 초점이 다를 뿐.

 

• 이해관계자(Stake holder)
  
  이해 관계자란 
  - 제품과 관련되어 있으나
  - 책임은 없는 사람들
  - 같이 협력해야 하는 사람들
  - 다양한 요구를 최대한 충족시켜줘야 함
  
  종류
  - 투자자, 경영진 등 비즈니스 관계자
  - 충성 고객, 일반 고객, 잠재 고객 등 고객군
  - 제품 팀 외의 타 부서 업무 인력
  - 특정 이슈나 문제와 관계된 사람

 

• 애자일의 3가지 도구
  
  스크럼: 팀원들이 하나로 뭉쳐 목적을 달성하기 위해 우다다 달리는 방식
  
  유저 스토리: 고객의 문제를 '고객'의 입장에서 서술한 내용. 
  \ 누가, 어떤 행동을 통해, 어떤 보상을 받을지 답하면서 \ 제품 기능(제공하는 가치)을 \ 줄글로 작성.
  이해관계자에게 제품의 비전을 설명할 때 사용. 
  
  칸반: 일 진행 상황을 확인하는 도구 
  기본적인 프로세스 표시 방법은 To Do(해야 될 것) - In Progress(진행중인 것) - Done (끝난 것)
  
  

* WIP(Work In Progress) : 동시 진행 업무 제한 / WIP LIMITS

* Pull 시스템 : 자리가 남을 때만 왼쪽에 진행이 덜 된(또는 시작안한) 일을 할 수 있음 

 

• capacity (줄여서 capa 캐파) 
  
  스크럼 팀이 출시 주기마다 해결할 수 있는 유저스토리(요구사항)의 개수 = 개발 범위
  
  백로그는 계속 쌓이기 마련이기 때문에 PO가 팀의 capa를 정확히 파악하고 우선순위를 잘 정해줘야 팀이 안 지침. 
  PM이 개발과 디자인 영역을 이해하고 충분히 소통할줄 알아야 하는 이유ㅇㅇ 
  
  
• 백로그 관리하고 우선순위 정하기 
  
  백로그: 팀의 역량 및 리소스의 제한으로 미처 처리하지 못하고 쌓아 놓는 할 일 목록
  
  - 너무 쌓이면 힘듬. 기한을 1개월로 제한 두고 오래 지난 일은 쳐내자. 어차피 해도 (시장은 바뀌었으니) 소용없다. 
  - PM이 거절하면서 일 쳐내주는 것도 필요하다. 
  - 사업 가치, 업무의 크기(팀원의 의견), 유저 스토리, 기간을 고려 → 뭐가 가치가 큰지는 경험으로 알기 때문에 뉴비 PM은 소통 많이 하자. 

PM은 뭘 만들지를 정하는 사람보다 뭘 안 만들지 정하는 사람에 가깝다

 

 

참고

애자일 방법론은 협업, 고객 참여 및 변화에 대한 신속한 적응을 중시하는 소프트웨어 개발에 대한 유연하고 반복적인 접근 방식 스프린트 기간을 반복하는 겁니다.

장점
유연성 및 적응성: 민첩한 방법론은 요구사항의 변화를 수용하고 개발 프로세스에서 반복을 허용하여 범위와 요구사항이 불분명하거나 변경될 수 있는 프로젝트에 적합하다.
고객 참여: 신속한 변화를 위한 방법론은 고객의 의견을 중요시하고 고객의 요구사항을 우선시하여 최종 제품이 고객의 기대와 요구사항을 충족하도록 지원합니다.
향상된 커뮤니케이션 및 협업: 신속한 변화를 위한 방법론은 개발자, 고객 및 이해관계자 간의 정기적인 커뮤니케이션과 협업을 강조하므로 요구사항을 더 잘 이해하고 개발 프로세스를 더 효율적으로 수행할 수 있습니다.
신속한 제공: 신속한 변화를 위한 방법론은 가능한 한 빨리 작동하는 소프트웨어를 제공하는 데 중점을 두므로 조기 피드백이 가능하고 제품 출시에 소요되는 시간을 단축할 수 있습니다. 

단점

• 숙련된 전문가 필요: 민첩한 방법론은 높은 수준의 협업 및 커뮤니케이션 기술과 개발 프로세스에 대한 깊은 이해가 필요하며, 이는 전문가 팀에서 찾기 어려울 수 있다. 스크럼 마스터 애자일 코칭 (배민, 야놀자)
• 계획 및 관리가 어려울 수 있습니다: 민첩한 방법론은 예측할 수 없고 변경될 수 있는 반복 프로세스를 기반으로 하기 때문에 계획 및 관리가 어려울 수 있습니다.
• 일부 프로젝트에 적합하지 않을 수 있습니다: 신속한 변화를 위한 방법론은 엄격한 규정이 있는 프로젝트, 변경이 허용되지 않는 프로젝트, 또는 범위와 요구사항이 잘 정의되어 있고 변경될 가능성이 낮은 프로젝트에는 적합하지 않을 수 있습니다.

---

읽기자료의 자리~ 

 

 

 

 

 

 

---

Q&A 세션 질의응답 

 

애자일 관련 질문 

애자일 기획 문서는 워터폴 기획 산출물과 일반적으로 어떤 차이가 있나요?

[워터풀은 일정이 너무 바쁘지 않은 이상 제안서, 기능 정의서, 정책 정의서 등을 다 갖추면서 문제+솔루션까지 모두 정의되는 게 일반적인 반면 애자일 방식의 경우는 수정 사항이 회의록과 협업툴에 주로 기록된다] 이거 맞나요?

A님 답변: 애자일과 워터폴 기획 산출물의 종류에는 차이는 크게 없습니다. 또한, 기업마다 사용하는 산출물의 종류가 다를 수 있기 때문에 일반적인 차이에 대해 말씀 드리긴 쉽지 않을 것 같습니다.

두 프로세스 기획 산출물의 대표적인 차이가 있다면 문서의 '완성도'와 '수정 주기'로 생각 됩니다. 먼저, 워터폴 프로세스는 문서 수정이 어렵기 때문에 일반적으로 100% 완성도를 갖춘 기획 산출물이 제작되어야 하겠죠. (ex. 문제 정의, 요구사항 정의서 등) 반대로 애자일 프로세스의 경우스프린트가 진행됨에 따라 문서가 끊임 없이 수정되고 구체화될 수 있습니다. G하이호님께서 말씀하신 것처럼 회의록과 협업툴을 통해 커뮤니케이션을 거친 수정 사항은 기획 산출물에 반영될 수 있겠습니다.

B님 답변: 애자일은 사실 문서화를 최소화하기 위해 나온 방법론이에요

구글은 그런 목적으로 도입했어요굳이 문서화 안하고 협업툴이나 컴플루언스(위키툴)에나 적습니다 트래킹 하려고. 물론 기획서는 디테일하게 쓰셔야졍 ㅋㅋ

 

 

Align(목표)을 맞추기 위한 행동, 질문 등에 대한 예시가 궁금합니다

저는 커피타임부터 가져요 최대한 대화 마니해용

 

 

애자일 번아웃?

번아웃 느낄 시간 자체가 없어요 지겨워지면 거긴 널널한 곳이에요

 

— 회사에서 쪽잠 자는 경우 많나요? 개발자가 아니더라도

숙직실 수면실도 잇어요

퇴근을 안해서 출근조차 안한 게 되는 일이 많았어요 ㅋㅋ

 

애자일 이후에 대안으로 떠오르는 프로세스는 아직 안나왔나요? 혹은 나왔는데 사장된 건가요?

없는 거 가태영

안 들어본 거 보니…

 

애자일 방식 단점이 계획이나 관리가 잘 안되는 걸로 적어주셨는데 경영진들이나 비즈니스쪽 부서들 - 프로덕트 팀이 일정관리 문제로 충돌이 자주 생길 것 같은데...

도입한지 얼마 안되어서 잘 모르는 거임. 그래서 코칭이 필요한 것임. 애자일 코칭, 스크럼 마스터 없으면 pm이 해야 돼

 

그 외 질문 

 

신사업 빌딩시 방향성을 결정한 경험

voc 기반해서 기능 먼저 정의했어용 

 

카카오톡처럼 사용자를 우선 모은 후 비즈니스 가치를 창출하겠다는 식의 솔루션

어떻게 사람을 모을지, 모아서 비즈니스 가치를 어케 검증할지를 고민해보삼 

 

 

 

* 색깔 질문 내 질문

---

그 외: 더 알아볼 내용, 어느 분류에도 넣기 힘든 정보, 링크 등

 

https://mokeya.tistory.com/150

애자일 업무 방법론 칸반(Kanban)에 대한 쉬운 설명

 

B2B 프로덕트는 어드민 페이지에 포커스를 맞추고 있는 느낌인데, 이런 부분을 어떻게 학습해야할 지 

mvp를 선정할 때 팁

자주 쓰는 지라 플러그인, 기능

웹훅이란?