애자일 프랙티스 - 팀으로 성과를 내기 위한 개발 기술의 실천 지식

116가지 기술 프랙티스와 현장 사례로 배우는 애자일 개발

이 책은 소프트웨어 개발 현장에서 애자일 개발을 실천해 온 저자가 자신의 실무 경험을 바탕으로 정리한 실무 가이드북입니다. 애자일 개발 실천을 위한 개발 지식과 116가지 기술 프랙티스를 체계적으로 정리하고, 가상의 개발 현장을 그린 만화를 통해 현장 상황에 맞는 프랙티스를 선택하고 활용하는 방법을 안내합니다.

[목 차]
  

들어가며

이 책의 소개

이 책의 대상 독자

이 책을 읽는 방법

이 책에서 다루는 프랙티스

감수자 서문

안녕하세요!

한편 그 무렵……

 

[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)

 

 

[칼럼]

팀에서 하나씩 하나씩 끝내자

페어 프로그래밍의 효과와 영향

테스트 주도 개발에서는 TODO 리스트가 테스트보다 먼저

기술적 부채 - 문제 발견까지의 시간과 리스크를 경영 부문에 설명한다

인프라 구축을 자동화하자

Logging as API contract

AI 친화적인 문서 작성하기

개발과 운영을 함께 생각하기

개발 항목을 간결하게 유지하려면 깨끗한 코드

팀에 활력을 불어넣는 목표 설정

그라데이션으로 생각하는 12년간의 애자일 실천