도서 소개

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

  출판사 리뷰

1장 애자일 개발을 지원하는 프랙티스
애자일 개발의 목표와 프랙티스의 관계, 프랙티스를 이해하는 데 도움이 되는 개념을 소개합니다.

2장 '프로그래밍'에서 활용할 수 있는 프랙티스
프로그래밍 방침, 브랜치 전략, 코드 리뷰, 테스트 등의 공정에서 필요한 규칙을 만드는 것과 팀원들 간의 긴밀한 커뮤니케이션을 위한 기술 프랙티스를 소개합니다.

3장 'CI/CD'에서 활용할 수 있는 프랙티스
개발 프로세스 전반에 걸쳐 제품의 품질을 유지 또는 개선하기 위해 필요한 지속적인 전체 통합과 자동화 방법을 소개합니다.

4장 '운용'에서 활용할 수 있는 프랙티스
시스템을 안정적으로 운영하고 애자일 개발을 지속하기 위해 필요한 운용 관련 기술 프랙티스를 소개합니다.

5장 '인식 일치'에서 활용할 수 있는 프랙티스
개발 안팎의 인식을 일치시키기 위한 프랙티스와 개발을 진행하면서 계획을 재검토할 수 있는 프랙티스를 소개합니다.

6장 '팀 협업'에서 활용할 수 있는 프랙티스
고객 가치 제공에 적합한 팀 구성 방법, 팀 간 소통을 원활하게 하는 프랙티스, 이해관계자를 참여시켜 인식을 일치시키는 프랙티스를 소개합니다.

[이런 분들에게 추천합니다]
- 조직 내에서 애자일 개발을 추진하는 담당자
- 팀 개발 경험이 적은 주니어 엔지니어
- 개발 현장과 팀을 책임지는 기술 책임자 시니어 엔지니어

  작가 소개

지은이 : 츠네마츠 유이치
Retty 주식회사 제품 부문 집행임원 VPoE엔지니어링 조직의 관리-제품 개발 프로세스의 애자일 혁신을 통해 '팀이 하나로 협력해 고객에게 가치 있는 제품을 단기간에 출시할 수 있는 개발 체제의 모습'을 모색하고 있다.

  목차

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

[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년간의 애자일 실천

  회원리뷰