모든 것을 예측하고 대비할 수 없을때, 모르는게 더 많은 복잡한 문제를 풀때 애자일, 스크럼, 스프린트를 적용해보자!
스프린트 기간이 1달일때는 플래닝은 8시간 리뷰는 4시간 회고는 3시간이 적정하다.

이론편

소프트웨어 개발은 만드는 행위가 목적이 되어선 안 되고 성과를 내기 위한 수단이 되어야 합니다.

결국 애자일 개발이란 어느 특정한 개발 방법론을 칭하는게 아니라, 다양한 개발 기법 사이의 공통된 가치관과 행동 원칙에 이름을 붙인 겁니다.(스크럼, 익스트림 프로그래밍, 칸반 등)

이들을 관통하는 공통된 생각은 모든 것을 예측하고 대비할 수 없다는 걸 일찌감치 인정하는 겁니다.

스크럼은 아는 것보다 모르는 게 더 많은 복잡한 문제를 풀때 유용합니다.

프로덕트 백로그

• 요구사항을 목록으로 정렬한다.

프로덕트 오너

• 제품의 명세를 책임지는 자
• 프로덕트 백로그를 관리하는 사람
• 개발자와 상의하되 간섭하지 않는다.
• 백로그를 검토하고 납기나 구현 순서를 상의한다.

디벨로퍼

• 동작하는 제품을 만드는자.
• 개발팀은 제품 개발에 필요한 모든 역량을 갖고 있어야 합니다. 예를 들면 요구 분석부터 설계, 구현, 테스트는 물론 인프라 구축과 문서화까지 모든 작업을 개발팀 안에서 해내야 합니다.

스프린트

• 작업기간을 짧은 간격으로 나눈다.
• 스프린트 마지막 날에는 할일이 남았어도 스프린트를 종료하고 기간연장하지 않습니다.

스프린트 플래닝

• 스프린트에 할일을 계획한다.
• 스프린트 백로그를 만드는 단계에서 일감에 작업자를 배정하지 않습니다. 작업자 할당은 스프린트가 시작된 후 실제로 작업할 시점에 결정되고, 팀원 스스로가 자기 할일을 가져가는 방식으로 배정됩니다.
• 스프린트 기간이 1달일때 플래닝은 8시간 정도가 적정
• 일감을 구체화하는 과정을 백로그 리파인먼트라고 합니다.

인크리먼트

• 스프린트마다 동작하는 제품을 만든다.
• 이전 스프린트의 결과물에 이번 스프린트의 결과물이 더해진다.
• 결과물은 릴리스 여부와 상관없이 동작하고 점검받을 수 있어야 한다.
• 프로덕트 오너와 개발팀은 어떤 상태를 완료로 볼 것인지 조건을 정해야 합니다. 이것을 완료조건이라 하죠.

데일리 스크럼

• 진행 상황을 매일 점검한다.
• 매일 하되 15분의 타임박스를 지킨다.
• 이야기가 길어지면 회의를 따로 잡는다.
• 데일리 스크럼은 문제를 해결하기 위한 모임이 아니므로 상황 공유가 끝났다면 데일리 스크럼을 마쳐야 합니다.

스프린트 리뷰

• 스프린트가 끝나면 프로덕트 오너가 주관하여 스프린트 결과를 점검합니다. 제품의 이해관계자인 스테이크홀더가 초대됩니다.
• 스프린트 기간이 1달일 때 리뷰는 4시간 정도가 적정

스프린트 회고

• 했던 일을 돌아보고 더 좋게 보완한다.
• 버그를 고치기보다 버그를 유발하는 작업 방식에 집중한다.
• 스프린트 기간이 1달 일때 리뷰는 3시간 정도가 적정

스크럼 마스터

• 일이 되게 만드는 숨은 조력자
• 일하는데 방해되는 요소를 제거한다.
• 업무 할당이나 진척 관리를 하지 않는다.
• 스크럼 마스터는 일하는 과정에서 문제가 될만한 걸 목록으로 정리하고, 우선순위와 해결방법을 검토한 다음, 그것을 해결할 수 있는 사람에게 협조를 구하기도 합니다.