그림 출처: https://media.dandypeople.com/2022/01/Agile-poster-2017-ver16-dandy_Korean.pdf
개발 단계에서의 문제 발생 유형 : 소프트웨어 개발 업계에서는 프로젝트가 초기 계획대로 수행되지 않는 과정도 종종 발생한다. 1) 계약 이행 실패 , 2) 개발사가 수주하면서 받은 금액이 부족한 경우 , 3) 계약대로 이행하기 위해 프로젝트에 투입된 사람들이 힘들게 일하는 경우, 4) 프로젝트 기간 동안에 발생한 시장 또는 고객의 요구 변화에 대응하지 못한 결과물 완성, 5) 마지막 단계에 몰아서 결과물 검증하면서 발생가능한 많은 수의 결함과 같은 고통 반복
워터풀은 : 모든 어려운 결정사항들이 초기에 이루어진다. 한 번에 빅뱅에 한다. 테스트와 계획 변경 없이 분석과 계획 수립하고, 보통 마지막에 가서 큰 이슈가 발생되고, 결국 비즈니스 목표, 유저의 니즈도 충족하지 못한 채 전달한다.
애자일은 : 지속적으로 결정사항은 유효한 범위내에서 이루어진다. 보통 계획한 것보다 이른 시기에 목표를 달성한다. 점진적 개발은 무엇이 요구되는지 파악될 때마다 반복적으로 개선을 통해 가치를 전달한다. 1) 대상을 아는 상태, 2)아직 모르는 걸 아는 상태, 3) 무엇이 있는지 지금은 모르는 상태로 구분된다고 할 때. 학습하면서 만들어 가기 위해 필요한 방식이다.
빠른 속도에 대응하기 위해 크고 지속적인 민첩한 변화가 필요하다. 기존의 긴 개발주기를 가진 방식은 이런 환경과 프로덕트 개발에 적합하지 않다. 목표를 달성하기 위해 개발기간과 할 일을 작은 단위로 나누어 아는 만큼 반복 점진적으로 개발하는 애자일 기반의 개발방식이 더 효과적인 프로덕트를 만드는 데 적합하다.
일 하는 방식 : 50%의 지식이 전달 과정에서 사라진다. 이른 성공을 위한 빠른 실패를 한다. t자형 인재, 교체 가능팀은 효과적으로 함께 문제를 해결한다.
모던 애자일 : 사람을 최우선, 빠르게 실험&학습, 심리적 안정감, 지속적 가치전달
스크럼 (scrum) : 경험주의 기반의 프로덕트 개발 협업 프레임워크. (계획-실행-적응 단계) / 스프린트 : 스크럼에서 짧은 주기의 반복적인 개발 주기 / 스프린트를 반복할 때 진행하는 스크럼 이벤트 4가지 (스프린트 계획, 스프린트 리뷰, 스프린트 회고)가 있음.
스크럼팀 : 3~9명 정도의 규모로 작은 목적 지향 팀. 위대한 교차기능 팀, 함께 모여서, 비즈니스 & 유저가치와 기술적 해결책에 대한 결정 권한을 가지고 일한다.
스프린트 : 데일리 스크럼 15분, 가치를 찾기 위한 백로그 정제, 스프린트 계획, 스프린트 목표, 리뷰, 회고
애자일이 지향하는 유연하게 여러 사람이 협업하면서 효과적인 목표를 품질 높은 개발 결과물로 만들어 내기 위해서는 문화와 사람이 중요하다는 것을 알게 된다.
애자일 되기 : 도구와 프로세스 > 실천법 > 원칙 > 가치 > 사고방식
교차기능 (cross-functional): 역할자를 한 팀으로 묶기. 각자의 역할만 하는 개인의 집단이 아닌, 각자의 전문 역량을 중심으로 서로 협업을 통해 가치 있는 프로덕트를 완성하는 데 필요한 모든 일을 함께 하는 팀
자율경영 (self-management) : 자율적인 프로덕트 진화, 일하는 방식과 일의 진척도 팀원 모두 스스로 결정 & 관리
린 생산방식 (lean production) : 리드 타임을 줄이려는 노력. 소프트웨어 개발에도 적용하여 낭비 요소를 최소화하고 리드타임을 짧게 함.
린 스타트업 : 가설을 제품으로 만들고 검증하여 학습한 것을 적용 반복하는 것. 스타트업 특성상 인력과 자원이 풍부하지 않고, 새로운 제품이나 시장을 개척하는 만큼 아이디어를 빠르게 실현시키고 지속적 개선으로 프로덕트의 생존과 성공 가능성을 높이는 방안 ( MVP기법 : minimum viable product)
칸반 kanban : 할일, 진행 중, 완료 세 가지 상태로 일의 진척도를 구분. WIP Limit 이라는 진행 중 열에 두는 최대할 일의 개수에 제한을 둬서 진행하는 업무를 우선적으로 빠르게 진행하는 것에 집중.
* 프로덕트 백로그 Product Backlog : 스크럼팀의 할 일 목록/ 할 일의 단위 = product backlog item (PBI)
* 스프린트 백로그 Sprint Backlog : 스크럼팀이 한 스프린트 동안에 완료한 것을 목표로 한 할 일의 목록.
* 프로덕트 개발 증가분 Increment : 릴리즈 목표일에 최종 사용자에게 전달 delivery 하는 릴리즈 release 실행.
[ 스크럼 5가지 이벤트 ]
* 스프린트 sprint : 1주 ~ 4주 정도의 길이 내에서 주단위로 결정하는, 반복적으로 수행하는 일정한 길이의 고정된 프로덕트 개발 주기.
* 스프린트 계획 sprint planning : 스크럼이 하나의 스프린트를 시작할 때 1일 차에 실행하는 이벤트. 이번 프린트 동안 어떤 목표를 달성하고, 그 목표달성을 위한 PBI(할 일목록)이 무엇인지 파악, 스프린트 백로그로 가져오는 결정함. 보통 4시간 ~ 최대 8시간 내에 완료함. PO와 스크럼 마스터가 backlog refinement 작업을 하는 것이 도움이 됨.
* 데일리 스크럼 daily scrum : 목표를 달성하는 과정에서 24시간의 진척과 다음 24시간의 진척 계획을 서로 확인하는 이벤트. 방해요소, 도움 필요한 일 언급, 개발자들 또는 스크럼 마스터와 협력함. 데일리 스크럼은 15분 동안 진행함.
* 스프린트 리뷰 sprint review : 목표 달성을 위해 필요한 일을 백로그 아이템 단위로 완료함. 스프린트 동안 얻은 의견을 정리해 백로그 정제 또는 시연을 하고 의견을 들음. 스프린트 리뷰는 최대 4시간 진행함. -> 모든 이해관계자가 참여하기 어려움. 축적된 마일스톤이 완료된 경우에는 반드시 참여하도록 안내하는 것이 좋음.
* 스프린트 회고 sprint retrospective : 팀원 개인 또는 팀의 문제점을 다루기 위한 것. 회고동안 나누는 대화로 정서적 공감, 이해가 깊어지는 분위기 조성이 중요함.
애자일 프로덕트 매니저의 역할과 기술 (실전 - 어려움)
OKR = 기업이 목표하는 방향과 하위 부서들의 기대치를 함께 맞추기 위해 사용하는 목표와 기대성과 전략.
프로덕트 매니저는 - 개별 단위로 기여하는 목표를 명시, 업무를 하는 팀 (스크럼팀, 스쿼드)이 어떤 목표를 가지고 프로덕트를 성장시켜 나갈 것인지 목표를 설정함.
Being Agile '애자일이 되기' 위해서는 '우리는 정답을 모른다.' 전제로 하면 쉽다. -> '프로덕트를 만드는 것은 혼자 할 수 없다'를 받아들인다. -> 정답을 모르기에 아는 만큼 구체화하고 계획하고 실행한다. -> 목표 지점까지 도달하기 위해 여정을 짧은 단위로 나눈다. 전체 개발 기간을 짧게 나누고, 전체 개발 할 일을 작게 분할한다. -> PM은 '혼자 해결책 구상, 정리, 기획서를 작성해 개발팀에 전달해 결과물을 만든다'라고 생각하면 개발자들을 더 수동적으로 일하게 하는 악순환이다. -> PM은 목표와 가설, 이를 해결할 대략적인 계획을 가지고 팀에 공유하고 > 디자이너, 개발자, QA 등 모든 역할자가 함께 구체화해 작은 단위로 할 일을 프로덕트로 완성해 나가는 걸 반복한다.
PM이 프로덕트 목표 달성을 위한 개발 계획 수립 방법 1) User story mapping : PM이 개발자에게 일정 기간 전체 할 일을 보여주는 방법 - 유저 입장의 공감포인트, 정보, 문제 페인포인트를 바탕으로 개발하려는 프로덕트의 할 일을 큰 단위로 작성함. - MoSCoW 정리 : 반드시 필요한 일 Must / 해야 하는 일 Should have/ 하면 좋은 일 Could Have / (현재는) 하지 않을 일 Won't Have로 구분하는 것.
2) 대략적으로 팀이 가진 개발주기 (스프린트, 이터레이션)만큼 어느 정도 할 일을 완료할 수 있을지 수평선을 그어봄. release planning이 됨. 프로덕트를 어떻게 개발해 나갈 것인지 일정과 함께 완료하는 일의 일정을 갖는 것.
3) 전체할 일을 이슈 관리 프로덕트(ex. 지라)에 등록 > PM이 앞으로 다른 팀원과 목표/진척을 확인할 시각화된 view가 생김 > 실시간으로 할 일의 순서, 할 일의 관계, 일정 표시 업데이트
할 일을 작은 단위로 나누기 story splitting * 스토리를 최소한의 크기로 분할하는 방법 1) 스토리를 독립적으로 존재하고 개발 2) 스토리가 구체화된 내용이 아니어서, 팀내부 또는 이해관계자들이 함께 해결 방안을 논의할 여지가 있는 것. 3) 완료 시 얻는 혜택, 영향력이 실질적인 가치를 담고 있어야 한다. 4) 할 일을 이해, 할 일의 규모를 측정함. 5) 개발팀이 가진 규모의 충분히 완료할 작은 크기 6) 테스트할 방법을 담을 충분한 내용이 담겨 있어야 함.
업무 시각화 work visualization : 포스트잇 표시, 미로 Miro, 피그잼 FigJam
할 일 우선순위 조정 work prioritization : 시장 상황, 이해 관계자 의견, 유저의 요청사항, 개발 기술 환경, 가설과 목표 지표 등 고려.
반복/ 점진적인 개발 수행 iterative/incremental development * 반복적 개발 : A라는 기능이 동작하는 가장 간단한 방식과 수준으로 개발함. -> 실질적으로 A기능이 효과가 있는지 판단함. * 점진적 개발 : B라는 경험을 유저에게 프로덕트를 제공하기 위해 필요한 여러 가지가 있음. 이 기능들 간의 경험 수준이 다른 경우가 있다. 예를 들어, 경제라는 경험을 유저에게 전달하는 경우, 1) 처음에는 신용카드 결제만 가능하게 완료해 한 가지 기능을 통해 경험을 전달한다. 2)다음에는 소셜플랫폼 연동 간편 결제 기능을 개발 완료해 같은 결제를 다른 기능으로 할 수 있게 제공한다. 이후, 추가적으로 결제 관련해 자체 페이먼트 개발, 자사 포인트 결제 등 여러가지 경험 루트를 제공할 수 있다.
