협업 루틴
협업 루틴의 목적은 문제를 빨리 드러내는 것임.
- 팀을 통제하기 위한 장치가 아님.
- 서로의 상황을 빨리 알고, 문제가 커지기 전에 드러내기 위한 장치임.
최소 루틴
| 루틴 | 주기 | 남겨야 할 것 |
|---|---|---|
| 주간 계획 | 주 1회 | 이번 주 목표, 담당자, 데모 가능한 결과 |
| 짧은 동기화 | 주 2~3회 | 막힌 일, 결정 필요한 일, 도움 필요한 일 |
| 멘토링 준비 | 멘토링 전 | 질문 목록, 현재 선택지, 팀의 임시 판단 |
| 회고 | 1~2주 1회 | 유지할 것, 바꿀 것, 다음 실험 |
| 리스크 점검 | 상시 | 일정 지연, 데이터, 팀 컨디션, 발표 리스크 |
회의를 결정으로 바꾸기
- 회의는 많아도 결정이 남지 않으면 프로젝트는 앞으로 가지 않음.
- 회의를 위한 회의를 줄이려면 주제, 목적, 제한 시간이 먼저 정해져야 함.
- 오늘 결정할 것
- 공유만 하면 되는 것
- 담당자를 정해야 하는 것
- 멘토에게 가져갈 질문
- 모든 토론을 무제한으로 열어두면 팀의 체력이 빠르게 소모됨.
- 다만 무제한 토론이 필요한 순간도 있음.
- 초기 아이디어 회의
- 피봇팅 회의
- 타깃 사용자나 핵심 기능처럼 중요한 결정이 걸린 회의
- Amazon의 1 Way Door / 2 Way Door 관점으로 나누어보면 도움이 됨.
- 1 Way Door
- 되돌리기 어려운 결정임.
- 피봇팅, 핵심 타깃 변경, 주요 기술 선택처럼 충분한 논의가 필요함.
- 회의 시간과 판단 근거를 넉넉히 잡는 편이 좋음.
- 2 Way Door
- 되돌리기 쉬운 결정임.
- 버튼 위치, 작은 문구, 단기 실험 방식처럼 빠르게 정하고 써보면 됨.
- 오래 토론하기보다 담당자와 기한을 정하고 실행해보는 편이 좋음.
- 1 Way Door
- 회의 시간이 길어지는 이유가 2 Way Door 결정을 1 Way Door처럼 다루기 때문인지 점검해야 함.
개발 루틴
- 개발 루틴은 팀이 실제로 지킬 수 있는 최소 규칙부터 시작하는 편이 좋음.
- 초기에 맞추면 좋은 것은 아래 정도임.
- 브랜치 전략
- 커밋 규칙
- 코드 리뷰 방식
- 배포 방식
- 장애나 버그를 공유하는 방식
- Agent Coding을 할 경우에는 Harness를 먼저 알아보는 것이 좋음.
- Harness는 에이전트가 만든 결과를 검증하는 최소 장치임.
- 예: 테스트 코드, smoke test, fixture, sample input/output, lint, 타입 체크, 배포 전 확인 스크립트
- 검증 장치가 없으면 에이전트가 코드를 많이 만들어도 맞게 만든 것인지 판단하기 어려움.
- 자동화와 테스트는 스트레스를 줄이기 위한 장치임.
- 보여주기 위한 장식이 아님.
- 문제가 생길 때 하나씩 보강하는 편이 현실적임.