잘 알려진 IT 프로젝트 방법론으로
워터폴/에자일방법이 있습니다.
워터폴 방식 : 프로세스에 따라 단계적으로 구현하는 방식
에자일 방식 : 최소단위 제품(MVP)을 빠르게 출시해서 고객 피드백을 바탕으로 제품을 개선하는 방식
프로젝트 성격에 따라서 워터폴이 적합한경우/ 애자일이 적합한경우가 있습니다
금융 플랫폼, 운영체제와 같이 한번에 완제품을 출시해야 하는 경우- 워터폴 방식 적합
고객을 사로잡아야 사업의 성패가 결정되는 프로덕트의 경우 - 애자일방식 적합
EX) Backlog
1. 경영진과 커뮤니케이션에서 나오는 Roadmap
2. 개발하다 나오는 내부이슈, 기술부채
3. 고객 요구사항
-> 전체적인 일정관리
cf) 많은 회사들이 Atlassian JIRA 로 Task 를 관리하고 Confluence를 wiki로 이용하지만
다르게 Notion과 Asana를 사용할수 있습니다.
- 빠르게 출시하다보면 -> 기술부채가 존재할수있습니다.
Asana에서
이 단계에서 발생하는 모든 task들은 Inbox에 정리하고
검토필요한것 -> Pending에 올려서 정리(정리,분류,그룹화)
product 관련한 모든 요구사항은 backlog에서 관리하게됨
요구사항을 작업을 할수있는 형태로 변이시키는것이 pending단계 (정리, 분류, 그룹화)
- Inbox에 모든 요구사항들을 담고있음
=> 새로운 스프린트로 만들기
- Ready단계에 정리된 task 모아둠
-Asana의 weekly라는 공간에 진행중인 업무들을 정리함
=> 무슨일 하고있는지 한눈에 파악하기 쉽다
- 모든 우선순위는 목표에 의해서 결정함
PM이 되면 어려운점 중하나 -> 여기저기서 요구사항 발생 / 우선순위 정하기가 어려움
백로그 요구사항 -> 목표에 대입 -> TASK를 만들어서 관리
- 기간이 있는 TASk를 sprint로 보고있음 (평균2주, 1주~1달경우도 있음 ), 기간을 유연하게 관리
- sprint 만들때 옆에 왜하는지 같이 명시
- 추천 로직 ( 빠르게 생성-> 코드 불안, 확장성 떨어짐) => 기술부채 해결, 유연성 확대
=> 확장성 고려
- 급하게 진행된느거 (operation section = ops)에 작성관리 (20%)
=> 미룰수도 있음 ( 항목으로 sprint를 만들어서 작성가능)
- sprint에 가급적이면 업무비중 80% 유지
회고(피드백을 주고받는 문화)
sprint가 끝나고나면 sprint에 참여했던 멤버들이
1) 각자 잘한점/개선할점 각자정리 ( 이때 상대눈치보단 무조건 1개라도 개선점 적는게 중요)
2) 회고 미팅( 내용 한번더 정리)
3) 최종 정리(최종적으로 회고미팅에서 나왔던 이야기들을 다 정리해가지고 전사적으로 공유함
참고>유투브 기획자 데이먼
