Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
Tags
- 시저암호
- AWS
- 백준
- 웹모의해킹
- 컴퓨터 구조
- 정보보안
- 알고리즘
- 코테
- 데이터 분석
- 회귀분석
- 데이터3법
- 파이썬
- 개인정보보호법
- 도커
- 자료형
- 파이썬 문법
- AI
- vagrant
- 개인정보보호
- 클라우드
- 데이터분석
- XSS 취약점
- 프로그래머스
- docker
- 머신러닝
- 코딩테스트 연습
- 함수
- 마이데이터
- 코딩테스트
- 웹 모의해킹
Archives
- Today
- Total
찬란하게
[Product Owner] 프로덕트 오너 #5 제4장 효율적인 일정 관리의 비밀 본문
2022.05.15 - [IT 지식 채우기/book 리뷰] - [Product Owner] 프로덕트 오너 #4 제3장 데이터 속에서 진실을 찾는 법
[Product Owner] 프로덕트 오너 #4 제3장 데이터 속에서 진실을 찾는 법
2022.05.15 - [IT 지식 채우기/book 리뷰] - [Product Owner] 프로덕트 오너 #3 제2장 고객의 목소리를 어디까지 반영할 것인가 [Product Owner] 프로덕트 오너 #3 제2장 고객의 목소리를 어디까지 반영할 것인가..
s2cherryy.tistory.com
4장
스토리 티켓으로 누구에게 무엇을 알려야 하나
"지난주에 제가 공유한 문서로 리뷰는 끝냈으니, 별다른 질문은 없죠?
그럼 제가 에픽을 하나 만들고,
당장 해야 하는 것들을 스토리 티켓으로 연결시켜 놓을게요"
티케팅 단계에 도달하기 전, 새로운 기능을 만들어야 할 때는 별도의 문서 작성
2~3 page 한정
개발 착수 1~2 주 전에 문서 작성
1. 목적 : 2~3문장,
> 이 문서의 목적, 어떤 내용을 다룰 것인지.
2. 배경 정보 : 2~3문단,
> 왜 이 신규 기능이 필요한지. 진행 상황, 풀고자 하는 문제, 앞으로의 방향성
3. 고객을 위해 어떤 일을 하는가? : 목록 형태 : 3~5가지 항목
> 각 고객이 왜 해당 기능을 고용할지에 대해
ex) 1) 정확하게 어떤 음식을 주문할지 알고 들어온 고객은 실시간 배송 정보를 눈으로 확인하기 위해 이 새로운 지도 기능을 고용한다.
4. 원칙 : 6개 이내
> 이 기능을 개발하고 고객에게 선보이는 과정에서 결정을 내릴 때의 잣대
ex) 1) 고객은 음식 배달 현황을 파악하는 걸 가장 중요하게 생각한다. 2) 배달 현황을 파악하는 데 도움이 안 되는 지도 기능은 철저히 배제
5. 목표 : 2~3개 한정
> 어떤 목표를 달성 ? 수치화
6. 주요 지표 : 3~4개
7. 개발 계획
> 1단계 : 최소 기능 모델 ( MVP, Minimum Valiable Product)
> 2단계..3단계
-> ETA : 개발 완료 예정 시간 + 상태 표기
8. FAQ : 자주 묻는 질문
개발팀 회의 소집 ->
회의에서는 주요 내용만 구두로 설명 -> 질의 시간
에픽 >> 스토리 >> 태스크
1. 에픽 티켓 : 서사, 큰 목표를 잡아주는 역할
>> 에픽 티켓 아래에 스토리 티켓 다수 생성
> 미리 작성한 문서의 핵심 내용을 기입
목적, 개발 타당성, 목표, 주요 수치 포함
2. 스토리 : 에픽을 달성하기 위해 분류
>> 통상적으로 사용자가 어떤 것을 할 수 있는지
ex) 사용자가 지도상에서 현재 이동 중인 배달원의 위치를 확인할 수 있어야 한다.
or
지도상에 실시간 배달원 위치 표기
> 개발 타당성, 주요 수치 + 구체적인 개발 요구사항 **
> 어떤 기능이 만들어져야 하는지 명시
> + ux 문서나 디자인 시안...
> 개발자가 무엇을 구현해야 하는지 명확하게 이해할 수 있도록...
3. 태스크 : 하나의 스토리가 완료되기 위해 개발되어야 하는 것들을 더 잘게 나눈 형태
ex) 네이버 지도 API를 연동한다
주문자의 위치 좌표를 db에서 연동...
> 주로 개발팀에서 작성
!! 요구사항을 명확하게 전달 !!
po는 고객이 필요로 하는 것 + 회사가 추구하는 방향성을 최적으로 구현하기 위한 해결책을 마련하여
개발자에게 전달하는 것
po가 해서는 안 되는일
po는 개발자, 디자이너, 비지니스 애널리스트 등이 각자의 업무를 잘 이행할 수 있도록 요구사항을 명확하게 하고 방향성을 제시하는 데 집중!!!
간단한 ui 개발 + 버그 픽스 (Bug Fix). xxxx
R&R
스크럼 : 업무 사이클을 유지할 수 있도록 주기적으로, 짧게 가지는 회의
스프린트 : 개발 사이클 -> 보통 2주당 하나
스크럼 회의 때 해야할 일들
<< 새로운 프로젝트 시작 >>
1) 문서나 티켓 생성
2) 변경사항 발생 -> 최단시간 내의 문서나 티켓 수정
3) 개발 팀원 메신저 공유 or 알림 설정
4) 다음날 오전 스크럼 회의 때 변경사항 구두로 다시 전달 -> 질의 과정
<< 특정 운영팀 요청사항 해결 >>
1. 대시보드 접속 후 세 번째 탭 오픈
2. 요청자의 이름과 소속 조직, 요청 일자 기입
3. 대시보드 작성 후 메일로 간략하게 작성 여부 알려주세요.
4. 개발팀에서 검토 후 ETA 산정 후 기입
5. 상태가 파란색이면 진행 중, 초록색이면 완료
<< 나만의 백로그 관리 >>
- 기능 명칭 : 주로 티켓의 제목과 동일
- 기능 설명 : 세부적인 내용 요약하여 한줄로
- 상황 : 시작 전/개발 중/개발 완료/테스트 중/배포 완료
배포 완료 -> 숨김, 폰트 옅은회색
- 전체 백로그
- 현재 스프린트
- 지난 스프린트
요청일 요청자 요청사항 또는기능 명칭 간략한 설명 우선순위 티켓 링크 ETA 개발상황 기타/메모
우선순위
p0 : 최우선
p1 : 가급적 완료
p2 : 완료되면 도움이 되는 개발물
p3 : 완료되지 않아도 지장 없는 개밸물
'IT 지식 > book 리뷰' 카테고리의 다른 글
6장 개발팀과의 협업을 성과로 이끄는 애자일 전략 (0) | 2022.06.04 |
---|---|
[프로그래밍 씽킹] (0) | 2022.05.22 |
[Product Owner] 프로덕트 오너 #4 제3장 데이터 속에서 진실을 찾는 법 (0) | 2022.05.15 |
[Product Owner] 프로덕트 오너 #3 제2장 고객의 목소리를 어디까지 반영할 것인가 (0) | 2022.05.15 |
[Product Owner] 프로덕트 오너 #2 제1장 프로덕트 오너는 미니 ceo다 (0) | 2022.05.13 |