들어가며
이 책의 소개
이 책의 대상 독자
이 책을 읽는 방법
이 책에서 다루는 프랙티스
감수자 서문
안녕하세요!
한편 그 무렵……

[1장. 애자일 개발을 지원하는 프랙티스]

1-1 프랙티스의 실천
애자일의 ‘오른쪽 날개’와 ‘왼쪽 날개’
기술 프랙티스 실천을 통해 문화를 정착시키자

1-2 돌다리도 두드려 보고 빠르게 건너라
빨리 알아채기
작은 단위로 완성한다
지속적인 수정

1-3 잘 알려진 애자일 개발기법과 프랙티스
스크럼
익스트림 프로그래밍
칸반

1-4 프랙티스 이해에 도움이 되는 개념
동시에 진행하는 작업을 줄여라
__WIP 제한
__리소스 효율과 플로우 효율
작은 단위로 완성하면서 전체 밸런스도 신경을 쓴다
__점진적(Incremental)
__반복적(Iterative)
동작하는 상태에서 변화해 나간다

[2장. ‘프로그래밍’에서 활용할 수 있는 프랙티스]

2-1 프로그래밍 방침
프로그래밍 전에 방침을 논의해 재작업을 방지한다
__프로그래밍 전에 방침을 논의한다
사용자 스토리를 작업 단위로 분해한다
__작업 분할
__칸반
완료 기준을 명확히 한다
__준비 완료의 정의(Definition of Ready)
__완료의 정의(Definition of Done)
__인수 기준(Acceptance Criteria)
__미완료 정의(Undone Work)
코멘트로 프로그래밍 가이드라인을 마련한다
__의사코드 프로그래밍

2-2 브랜치 전략
동시에 수정을 진행하기 위한 운용규칙
__브랜치 전략
세밀하고 빈번하게 직접 커밋을 반복해 개발을 진행한다
__트렁크 기반 개발
동작하는 상태를 유지한 채 조금씩 병합해 나가는 방법
__피처 플래그
장기간 브랜치가 필요한 경우
__장기간 브랜치에 정기 병합

2-3 커밋
표준적인 커밋 메시지를 작성한다
__읽는 사람을 배려한 커밋 메시지
다른 목적의 수정을 하나의 커밋에 섞지 않는다
__커밋을 목적별로 나눈다
__커밋 메시지에 프리픽스를 부여한다
커밋 이력을 다시 쓰는 방법
__커밋 이력을 다시 쓴다
읽는 사람이 알기 쉬운 흐름으로 커밋을 배열한다
__이야기처럼 커밋을 배열한다

2-4 코드 리뷰
코드 리뷰의 목적
__소스 코드의 공동 소유
코드 리뷰의 실시 방법
__코드 리뷰에도 적극적으로 참가한다
__소스 코드 전체를 보며 코드 리뷰를 한다
__리뷰어는 그룹에 배정
__코드 소유주의 설정
도구에서 할 수 있는 지적은 도구에 맡긴다
__linter, formatter의 활용
__도구의 출력 결과를 풀 리퀘스트에 코멘트한다
작업을 확인할 수 있는 자리를 조기에 마련한다
__프로그래밍의 시작과 동시에 풀 리퀘스트를 만든다
__부모 브랜치를 사용한 코드 리뷰와 병합
건설적인 커뮤니케이션을 위한 마음가짐
__리뷰어 혹은 리뷰이를 이해시키려는 노력
__풀 리퀘스트 템플릿
__협업 작업으로 소스 코드 개선
__코드 리뷰 방식 재검토
__코멘트에 피드백의 뉘앙스 포함하기
코드 리뷰 코멘트가 생각나지 않는 상태를 극복하는 방법
__질문을 통해 배우는 자세를 가져라

2-5 공동작업
하나의 사용자 스토리에 많은 관계자를 끌어들인다
__스워밍(Swarming)
두 명이 협력하여 개발을 진행한다
__페어 프로그래밍
__실시간 공동 편집 기능이 있는 개발 환경을 사용한다
여러 사람이 협업하여 개발을 진행한다
__몹 프로그래밍, 몹 워크

2-6 테스트
검증(Verification)과 확인(Validation)의 관점
__검증(Verification)과 확인(Validation)
__확인(Validation)은 이해관계자와 함께 진행한다
테스트 자동화 관련 기술 프랙티스의 차이
__자동 테스트
__테스트 우선
__테스트 주도 개발
테스트 코드를 오래 운영하기 위해 할 수 있는 일
__읽기 쉬운 테스트 코드를 작성
__테이블 주도 테스트
테스트 코드의 분량을 적절하게 유지
__필요한 만큼의 테스트 코드 준비하기
__돌연변이 테스트

2-7 장기적인 개발/운용이 가능한 소스 코드
평소 개발부터 소스 코드 품질에 신경을 쓴다
__장기적인 개발/운용이 가능한 소스 코드
소스 코드를 장기적으로 개발/운용할 수 있도록 한다
__리팩터링
__리아키텍처
원본 소스 코드보다 더 깔끔하게 만들기
__보이스카우트 규칙
__기능 삭제하는 방법 익히기
소프트웨어 의존관계를 검토한다
__의존관계의 자동 갱신

[3장. ‘CI/CD’에서 활용할 수 있는 프랙티스]

3-1 지속적 통합
반복적인 빌드와 테스트를 통해 문제를 조기에 발견한다
__지속적 통합
로컬 환경에서 자주 실행한다
__훅 스크립트
문서의 지속적 갱신
__도구에 의한 문서 자동 생성

3-2 지속적 배포
시스템을 항상 배포 가능한 상태로 유지
__지속적 배포
CI/CD 파이프라인 구축
__CI/CD 파이프라인
이용 환경을 브랜치 전략과 연계하여 자동 갱신한다
__브랜치 전략과 이용 환경과의 연계
브랜치 보호를 설정하고 릴리스 가능 상태 유지
__브랜치 보호

3-3 지속적 테스트
자동 테스트의 바람직한 테스트 분량
__테스트 피라미드
사용자 환경에 가까운 시스템 전체 테스트
__E2E 테스트 자동화
개발과 관련된 모든 공정에서 테스트를 시행한다
__지속적 테스트

[4장. ‘운용’에서 활용할 수 있는 프랙티스]

4-1 배포 / 릴리스
배포 전략 선택
__롤링 업데이트
__블루/그린 배포(Blue/Green Deployment)
__카나리아 릴리스
데이터베이스 스키마 관리 및 마이그레이션
__데이터베이스 스키마 정의 및 관리
누구나 쉽게 배포/릴리스할 수 있도록 정비한다
__배포 도구
__ChatOps
정기 릴리스를 지키는 릴리스 트레인
__릴리스 트레인(Release Train)

[5장. ‘인식 일치’에서 활용할 수 있는 프랙티스]

5-1 관계자와의 인식 일치
관계자를 모아 목표와 범위를 맞춘다
__적절한 관계자 모으기/목표 맞추기/범위 맞추기
__유비쿼터스 언어
__실제 예에 의한 사양
__화제가 줄어들 때까지 매일 이야기하기
진행 방식에 대한 인식 일치
__불확실성이 높은 것부터 시작하자
__통제할 수 있는 사항은 빨리 결정한다
__통제할 수 없는 사안에 대한 결정은 최대한 미룬다
진행 상황에 대한 인식 일치
__관계자의 기대치를 듣고 인식을 일치시킨다
__보고 형식 맞추기
__기술 관행 적용을 위한 여력 확보하기

5-2 개발 안에서의 인식 맞추기
설계를 사전에 협의한다
__사전 설계 상담
리스크가 있는 사용자 스토리는 ‘스파이크 조사’
__스파이크 조사
큰 규모의 개발은 Design Doc으로 눈높이를 맞춘다
__Design Doc
5-3 계획의 지속적인 수정
사용자 스토리를 작게 나누기
__사용자 스토리 분할
__INVEST
사용자 스토리를 정리하여 전망성을 높인다
__사용자 스토리의 정기적인 점검

[6장. ‘팀 협업’에서 활용할 수 있는 프랙티스]`

6-1 팀의 기본 단위
팀으로 일하기
__피처 팀
피처 팀이 자주 받는 질문과 오해들
__컴포넌트 멘토 임명하기
__회사 조직과 팀 체제를 맞추는 방법

6-2 속인화의 해소
위험의 징조 '트럭 번호 = 1'을 피하자
__트럭 번호
기술 지도를 작성하고 속인화된 기술을 파악한다
__기술 지도

6-3 성과의 측정
메트릭을 극대화하는 작용을 피하자
__상관관계가 있는 여러 메트릭 조합 보기
‘Four Keys Metrics’로 팀 성과 측정하기
__Four Keys Metrics

6-4 원활한 커뮤니케이션을 위한 아이디어
필요할 때 직접 소통하기
__그냥 말하기
여행자가 팀을 떠돈다
__여행자
소리 내어 일하기
__Working Out Loud
원격근무를 전제로 한 체계
__동기 커뮤니케이션을 유연하게 도입
__Working Agreement
__현장을 원격과 동일한 조건으로 만들기
__협업 도구 활용

6-5 인식을 일치시키기 위한 워크숍
사용자 관점에서 우선순위를 확인한다
__사용자 스토리 매핑
단시간에 견적, 실적에 기반한 진행 상황을 보여준다
__사일런트 그룹핑
__번업 차트
아이디어의 탄생부터 납품까지를 단축한다
__가치 흐름 매핑

마치며
컬럼 필자 소개
저자 · 감수자 소개

색인(Index)