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

1장 애자일 개발을 지원하는 프랙티스 애자일 개발의 목표와 프랙티스의 관계, 프랙티스를 이해하는 데 도움이 되는 개념을 소개합니다. 2장 ‘프로그래밍’에서 활용할 수 있는 프랙티스 프로그래밍 방침, 브랜치 전략, 코드 리뷰, 테스트 등의 공정에서 필요한 규칙을 만드는 것과 팀원들 간의 긴밀한 커뮤니케이션을 위한 기술 프랙티스를 소개합니다. 3장 ‘CI/CD’에서 활용할 수 있는 프랙티스 개발 프로세스 전반에 걸쳐 제품의 품질을 유지 또는 개선하기 위해 필요한 지속적인 전체 통합과 자동화 방법을 소개합니다. 4장 ‘운용’에서 활용할 수 있는 프랙티스 시스템을 안정적으로 운영하고 애자일 개발을 지속하기 위해 필요한 운용 관련 기술 프랙티스를 소개합니다. 5장 ‘인식 일치’에서 활용할 수 있는 프랙티스 개발 안팎의 인식을 일치시키기 위한 프랙티스와 개발을 진행하면서 계획을 재검토할 수 있는 프랙티스를 소개합니다. 6장 ‘팀 협업’에서 활용할 수 있는 프랙티스 고객 가치 제공에 적합한 팀 구성 방법, 팀 간 소통을 원활하게 하는 프랙티스, 이해관계자를 참여시켜 인식을 일치시키는 프랙티스를 소개합니다. [이런 분들에게 추천합니다] - 조직 내에서 애자일 개발을 추진하는 담당자 - 팀 개발 경험이 적은 주니어 엔지니어 - 개발 현장과 팀을 책임지는 기술 책임자 시니어 엔지니어