오너십
작업을 하는 사람이 무엇을 해야 하는지 가장 잘 이해한다
태스크 플래닝
시각적 계획, 가치있는 증분을 나누는 행위는 태스크 플래닝을 통해 구현된다. 태스크 플래닝은 케이던스(cadence), 태스크 생성, 시각적 추적으로 구성된다.
케이던스
케이던스는 태스크 플래닝의 빈도다. 이는 두 가지 방식이 있다.
- 스크럼(이터레이션) : 정해진 주기로 스토리를 계획하여 진행한다.
- 칸반(지속적인 흐름) : 하나의 스토리가 끝나면 새로운 스토리를 선택해서 진행한다.
스크럼
스크럼은 시간을 엄격하게 관리한다. 시간이 되면 스프린트는 끝난다. 스프린트 시작할 때 capacity를 예측하고, 그에 맞는 스토리를 선택한다. 스프린트가 종료될 때 완료되지 않은 스토리가 있다면, 무언가 잘못된 것을 의미한다. 이 때, 문제를 확인할 수 있고 해결할 수 있는 기회가 생긴다.
애자일을 처음 접하는 팀일 경우 스프린트를 짧게 가져가야 애자일에 대한 이해도를 높힐 수 있다.
칸반
팀이 매주 무엇을 할 수 있는지 예측하는 대신 진행 중인 작업의 제한을 두라. 제한 값에 이르면 어떤 스토리도 시작할 수 없다. 예를 들어, 지라 티켓은 최대 3개까지 WIP 목록에 있을 수 있다.
칸반은 작고 예측할 수 없는 많은 스토리를 다루는 팀, 다시 말해 많은 유지보수나 버그 수정 작업을 하는 팀에게 적합한다. 계획이 너무 자주 변경되 1주기의 스프린트도 길다면, 칸반을 사용하는게 좋다.
태스크 생성
스토리를 선택해 태스크 플래닝을 진행하라. 우선순위가 높은 스토리를 선택하라. 이상적인 시간은 30분 이내다. 만약 특정 스토리에 대해 '인증 라이브러리를 어떤 것을 사용할 지'와 같은 주제로 이야기가 길어질 것 같으면 해당 논의를 태스크로 생성하라.
시각적으로 추적하기
태스크의 진행 상태를 확인하기 위해 이를 시각화하라.
긴급 요청
스토리를 진행하던중 이해관계자가 나타나 불쑥 "이 작업을 해야 합니다."라고 말한다면 어떻게 할 것인가.
- 우선 긴급한지 팀에서 결정하라.
- 긴급한 업무로 진행되기로 결정했다면 스크럼의 경우 시작되지 않은 스토리를 제거하고 대체하라. 칸반을 사용하는 경우 긴급한 스토리 진행을 위한 WIP 제한을 만든다.
- 긴급 요청이 많거나 지속적인 지원이 필요하다면, 예비 개발자를 확보하고 이들은 스토리에 관한 작업에서 배제하라. 번아웃을 방지하기 위해 매일 또는 매주 새로운 인원에게 이 역할을 준다.
수용량
스프린트의 경우 이를 파악하는게 매우 중요하다. 한 스프린트 내에서 얼마나 달성할 수 있는지 신뢰할 수 있는 지표다.
어제의 날씨
이 수용량을 예측하기 보다는 측정하라. 지난 스프린트들에 대한 스토리 포인트를 확인하라.
수용량 및 이터레이션 타임박스
수용량은 엄격한 이터레이션 타임박스에 의존한다. 수용량이 제대로 동작하려면 이터레이션 종료 시점에 '완료'되지 않은 스토리의 수는 절대 세면 안된다. 이터레이션을 조금 늘려 모든 스토리를 완료하고 싶더라도 참아야 한다. 그렇지 않을 경우 피드백 루프는 엉망이 되고 팀이 실제로 완료할 수 있는 양을 초과하게 작업하게 될 것이다.
과도한 일정의 압박은 팀의 성과를 떨어뜨리고, 지름길을 선택하고, 실수를 저지른다. 이는 내부 코드 품질과 자동화, 인프라스트럭처 품질을 손상시키며 모든 것이 더 오래되게 만든다.
수용량을 개선하려면
1.내부 품질을 개선한다
결함이 있는 코드, 느리고 신뢰성 없는 테스트, 열악한 자동화는 팀 수용량에 매우 큰 영향을 준다.
2.고객 스킬을 개선한다
팀에 현장 고객이 없는 상황에서 대답자는 대답을 기다리거나 추측할 수 밖에 없다. 이는 수용량을 감소시킨다. 개잘자의 고객 스킬을 개선함으로써 현장 고객에 대한 의존도를 줄일 수 있다.
3.에너지 넘치는 작업을 지원한다
지치고 번아웃된 개발자는 많은 비용이 드는 실수를 한다. 압박을 받는 경우 초과 근무를 하지 않는 정책을 세워라.
4.의무를 덜어내라
작업을 수행하는 팀원들은(개발자) 다른 사람이 할 수 있는 모든 작업에서 손을 떼야 한다. 불필요한 회의에서 이들을 제외하고 인터럽트로부터 이들을 보호하라. 타임 시트나 경비 보고 등의 관료적인 절차를 대신 신경 써 줄 수 있는 사람을 찾아라.
슬랙
만약 워크스테이션의 케이블이 벽의 콘센트에 겨우 꽂을 만큼만 길다고 생각해보자. 아마 여러분들은 워크스테이션의 위치를 벽과 좀 더 가까운 위치로 옮겨 느슨하게 만들어 전원이 꺼지는 것을 방지할 것이다. 이터레이션 또한 이런 여유가 필요하다.
슬랙을 이용하는 방법
팀의 병목이 되는 유형에 대해서 이용하라. 슬랙을 가장 잘 활요앟는 방법은 전달하기 능력을 증가시키는 것이다. 이를 위한 방법으로 세 가지 좋은 선택지가 있다.
1.내부 품질 개선하기
내부 품질을 개선하는 것은 수용량을 증가시키는 확실한 방법 중 하나이다. 개선을 일괄적으로 처리하지 말고, 이터레이션하는 동안 매일 개선하라. 태스크 보드를 확인하고 계획된 작업보다 더 빨리 진행되고 있으면 개선을 진행하고, 느리다면 스토리에 집중하라.
2.고객 스킬을 개발하라
애자일은 cross-functional 팀이지만 많은 기업이 고객 스킬을 간과한다. 슬랙을 이용해 이들을 학습하라.
3.탐험과 실험을 위한 시간을 확보하라
개발자들은 호기심이 많으며 호기심을 충족할 시간이 주어지면 이들은 종종 팀에서 작업을 향상시키는 것을 배운다. 이 연구 시간 블록을 통해 주도적으로 학습을 수행하라. 새로운 기술을 연구하거나, 코드의 애매한 부분을 학습하거나, 새로운 프랙티스를 시도하라. 단, 어떤 스토리를 구현하거나 프로덕션 코드를 커밋하지 말라.
스탠드업 회의
스탠드업은 조정을 위한 회의이지 상태 공유를 위한 회의가 아니다. 상태 공유가 필요하다면 태스크 보드를 보라. 스탠드업 회의는 팀원들을 동기화 함으로써 ad-hoc 기반으로 하루 동안 조정을 계속할 수 있다.
고객 예시
일부 소프트웨어는 간단하다. 그저 다른 데이터베이스 위에 있는 또 다른 UI일 뿐이다. 그러나 가치 있는 소프트웨어는 종종 전문화된 지식을 포함하는 소프트웨어다. 이런 도메인 지식을 전달할 때는 고객 예시를 이용하라. 도메인 규칙을 설명하는 구체적인 예시를 만들어라. 이 과정은 설명, 시연, 개발의 프로세스를 따르라.
전문가: 스토리 중 하나는 인보이스 삭제입니다. 이것과 관련한 규칙은 다음과 같습니다. 일반적으로 고객에게 전송되지 않은 인보이스는 삭제되도 괜찮습니다. 그래야 사람들이 실수를 삭제할 수 있습니다. 단, 고객에게 발송된 인보이스는 관리자만 삭제 가능합니다. 그럼에도 불구하고 감사 목적으로 사본을 저장해야 합니다.
// 질의 진행완전 완료
완성된 스토리는 통합되어야 하며, 테스트 되어야한다. 그렇지 않으면 완성된 스토리가 아니다. 즉, 완성된 스토리는 출시 가능한 단위다. 'WIP 업무를 최소화하라'는 원칙처럼 부분 완료된 스토리는 진행 중 업무와 비용을 증가시킨다.
이런 완전 완료를 평가하기 위해 완료 정의를 만들라.
- 테스트 완료
- 코드 작성
- 디자인 완료
- 통합
- 빌드
- 배포
- 마이그레이션
- 현장에서 검토
- 수정
- 스토리 완료 동의
이 과정에서 중요한 것은 현장 고객을 참여시키는 것이다. UI 태스크에 관련된 작업을 하는 경우 이 진행 상황을 보여주라. 고객은 UI를 종종 수정하고 싶어한다. 마찬가지로 태스크를 완료하고 스토리의 다양한 부분을 통함할 때 코드를 실행해 모든 것이 함께 작동하는지 확인하라.