플래닝
애자일은 예측하는 것이 아니라 적응하는 것이다.
스토리
스토리는 요구사항이 아니며, 사용 사례도 아니다. 스토리는 계획을 위한 것이다. '미래의 대화를 위한 약속 어음'이라고 할 수 있다. 스토리는 대화를 하도록 상기시키기 위한 것뿐이므로 자세한 설명은 필요 없다.
스토리 만들기
팀이 수행할 모든 작업에는 스토리가 필요하다. 그래야 일의 우선 순위를 정할 수 있다.
eg.
- 창고 재고 보고서
- 로그인 화면의 커스터마이즈 가능한 브랜딩
"(역할)의 입장에서 나는 (결과)를 얻기 위해 (무엇)을 원한다"는 템플릿으로 작성될 수 있지만 필수는 아니다. 사용자에게 서비스를 제공하는 방법을 상기시키는데 도움을 주기 위한 실험용으로 만들어진 것이다.
스토리는 짧지만 여전히 두 가지 중요한 특징을 지닌다.
- 고객의 가치를 나타내며 고객의 언어로 기술된다. 구현 세부 사항이 아니라 고객이 인식하고 가치 있게 여기는 작업을 설명한다.
- 명확한 완료 기준을 갖는다.
Bad eg.
- 통합 구축 자동화
- 방화벽 외부의 스테이징 서버에 배포
고객 가치
스토리는 고객 중심이어야 한다. 고객에게 이익이 되는 내용을 제공하는지 확인해야 한다.
개발자들은 종종 고객 중심 스토리를 작성하는 데 어려움을 겪기 때문에 계속 연습해야 한다.
스토리 분할 및 결합하기
스토리는 우선순위를 개별적이고 순서에 관계없이 우선순위를 지정할 수 있는 것이 최고의 분할이다. 연습이 필요하며, 항상 가능한 것도 아니므로 해당 문제를 경험하더라도 걱정하지 말라. 스토리는 나눌수록 고객 중심의 관점을 유지하기 어려워질 수 있지만 포기하지 말라.
적응적 계획하기
가치 있는 증분
가치 잇는 증분으로부터 계획을 세우라. 가치 있는 증분은 다음과 같은 세 가지 특성이 있다.
- 출시 가능하다
- 가치 있다
- 점진적이다
가치 있는 증분은 다음과 같이 세 범주로 나눌 수 있다
- 직접 가치: 가치가 있는 것을 만들거나 변경하거나 수정한다.
- 학습 가치: 가치를 높이는 방법에 대한 통찰력을 제공하는 실험을 수행한다.
- 선택 가치: 미래의 소중한 기회를 활용할 수 있도록 결정을 연기 또는 변경할 수 있는 역량을 만든다.
증분을 작게 나누라
증분을 세밀하게 분할할수록 팀 작업에서 더 많은 가치를 추출할 수 있다. 증분이 작을 수록 계획을 더 자주 조정할 수 있으며, 더 애자일해질 수 있다.
WIP 업무를 최소화하라. WIP는 변경 비용을 증가시킨다. 계획을 변경하는 경우 완료되지 않은 작업은 별도로 보관해야 한다.
일찍 자주 릴리즈하라
종종 팀은 여러 증분을 묶어 출시하는데, 기술적인 제약으로 인해 빈번한 출시에 비용이 너무 많이 들기 때문이다. 반드시 필요하다면 그렇게 해도 좋지만, 그 이유에 대해선 솔직해야 한다.
일부 팀은 릴리스 트레인을 통해 일정을 조율한다. 릴리즈 트레인은 매주 같은 시간 출발한다. 다른 증분은 다음 열차에 탑승한다. 증분이 얼마나 열차에 가까이 있는지는 중요하지 않다.
책임감 잇는 마지막 순간
애자일 팀은 책임감있는 마지막 순간까지 결정을 미룬다. 이를 통해 비용을 절감하고 민첩성을 향상시킨다.
일찍 결정 내릴수록 중요한 결정을 놓칠 가능성이 커진다. 그렇게 하면 작업을 다시 시작하거나 잘못된 결정을 견뎌야 한다. 그것은 낭비다.
시각적 계획하기
말하기보다 선택 사항을 시각화하고 진행하면서 조정할 수 있는 계획을 만드는 것이다.
플래닝 게임
플래닝 게임은 계획 프로세스 중 일부일 뿐이며, 가치 있고 릴리즈 가능한 증분을 더 작은 스토리로 나누는 방법이다. 이를 마치면 개발에 '딱 맞는' 일련의 스토리를 갖게 도니다.
두 가지 방법으로 토스트가 언제 완료되는지 결정할 수 있다. 카메라를 이용하면 정확하게 빵이 구워지지만 좀 더 많은 스토리가 필요하고, 타이머를 이용하면 추가 작업은 없지만 빵을 덜 굽거나 너무 많이 굽게 될 수도 있다. 어떤 것을 선호하는가?
실질적인 고객 참여
팀의 작업의 가치는 현장 고객에 달려있다. 그리고 그 관점을 넓히려면 실제 고객과 사용자들을 참여시켜야 한다.
애자일은 피드백을 강조하며, 이는 성공의 큰 이유 중 하나다. 소프트웨어가 어떻게 받아들여질지 예측하기는 매우 어렵다.
점진적 요구사항
세부 요구사항은 필요하기 직전에 결정한다. 전통적인 프로세스는 하나의 요구사항 문서를 만든다. 이론적으로 이 문서는 소프트웨어가 어떻게 동작해야 하는지를 정확하게 설명한다. 이 문서는 사전 요구사항 수집 단계에서 비즈니스 분석가들이 만든다.
애자일 팀에서는 이런 단계가 필요치 않으며, 스토리 카드는 요구사항 문서의 미니어처가 아니다. 애자일 팀은 대면 커뮤니케이션을 선호한다. 구매자, 현장 고객은 살아있는 요구사항 문서처럼 활동한다.
문서화
애자일 팀에서도 일부 문서는 여전히 가치를 지닌다.
- 제품 설명서: 고객에게 전달된다.
- 운영 문서: 런북으로 불리며 상황에 따란 표준 프랙티스와 절차를 기술한다.
- 거버넌스 문서: 조직에서 거버넌스나 감사를 목적으로 요구할 수 있는데 이는 최소한으로 유지하라
- 준공 문서: 아키텍처, 디자인, 주요 피처에 대한 중요한 개념을 개괄적으로 설명하며, 코드와 테스트는 세부 사항을 전달한다.