6장 개발팀과의 협업을 성과로 이끄는 애자일 전략

확실한 프로젝트 수행법, 스프린트 플래닝

스프린트 : 팀이 정기적으로 만나 프로젝트 기간 동안 무슨 일이 있었는지, 자신들이 일하는 방식은 어떠한지 돌아보고 무엇을 개선하면 좋을지 논의

 

-> 단거리 전력 질주!!

-> 2주 단위로 나누 집중 개발

before 스프린트

1. 이전 스프린트에 개발 완료한 것

ex)
안드로이드 서비스 UX 개편
- Ticket-100
- Owner :  000
- 배포 일자 : 04/15
- 7일간 테스트 후 100% 적용 완료

2. 이전 스프린트에서 개발 완료하지 못한 것

ios 서비스 UX 개편
- Ticket-101
- Owner :  000
- ETA : 04/15
- QA. 도중 발견한 버그 수정을 위해 앱스토어 등록 연기

3. 이전 스프린트에 발생한 기술적 이슈 또는 버그
-> 이미 서비스되고 있는 프로덕트나 새로운 기능이 문제 
--> 인시던트 리뷰 진행
-> 원인, 대응 방식, 개선책 논의


ios 사진 5장 이상 등록 불가
- INCIDENT-1000
- 발생일 :  000
- 고객 임팩트: 04/15 오전 8시 부터 20분가량 IOS 사용자 중 다수의 사진 등록을 시도한 00000명이 일시적으로 업로드 불가
- 04/16에 incident Review 진행 완료

완료일을 언제로 잡는 것이 시기 적절한가

 po는 일방적으로 강요하지도, 일방적으로 강요받지도 말아야 한다.

고객에게 선보여야 하는 일정, 사업적으로 달성해야 하는 목표, 개발 조직의 여건 --->> 최적의 완료 일정 협의!

 

적절하게 반문하며 왜 일정을 맞출 수 없는지, 충분히 파악

모든 질문에 대답할 수 있는 소통의 기술

단 한순간도 개발이 정체되는 것을 스스로 용납하지 않는다.
상황이 애매하거나, 고객의 요구사항이 부정확하거나, 개발 착수를 위해 필요한게 있다면 최대한 빨리 해결하려고 한다.
내가 병목이 되어서는 안 되고, 함꼐 일하는 팀원들이 불필요한 것에 대해 고민하지 않길 바라기 때문이다.

po는 늘 다른 팀원보다 조금 더 멀리 내다보고 있어야 한다.
개발자나 디자이너가 궁금해하기도 전에, 최대한 미리 정의를 다 해놓고 제공하는 것이 최적화된 협업 방식이라고 생각한다.

고객이 무엇을 원하는지.
협업하는 유관부서의 상황은 어떤지.
언제까지 필요한 요소들이 완성되는지.

속도 vs 확장성

확장성을 추구하되, 속도도 감안해야 한다.