XP, Lean 및 DevOps: 기술 관행 및 Agile 문화
스크럼과 칸반 외에도 개발의 기본이 되는 다른 방법론과 문화가 있습니다. 최신 소프트웨어: 익스트림 프로그래밍(XP) 극단적인 기술적 관행을 바탕으로 기대다 폐기물 제거에 중점을 두고, e 데브옵스 그것이 무너진다 개발과 운영 사이의 사일로.
🎯 무엇을 배울 것인가
- XP: 12가지 기본 사례(TDD, 쌍 프로그래밍, CI, 리팩토링)
- 린(Lean): 7가지 낭비, 가치 흐름 매핑, 풀 시스템
- DevOps: 문화, CALMS 프레임워크, CI/CD 파이프라인
- XP를 스크럼과 통합하는 방법(기술적 관행 + 프레임워크)
- 지속적인 통합, 제공 및 배포에 대한 자세한 내용
- 코드형 인프라 및 구성 관리
- 모니터링, 관찰 가능성 및 피드백 루프
익스트림 프로그래밍(XP)
역사와 철학
익스트림 프로그래밍 90년대 말에 탄생한 켄트 벡 크라이슬러 C3 프로젝트 중. 이름은 다음과 같은 사실에서 유래되었습니다. "극단적인" 수준까지 좋은 개발 관행을 취합니다.
🔥 코드리뷰가 좋으면... 저희는 항상 합니다(페어 프로그래밍)!
🔥 테스트가 중요하다면... 코드(TDD) 이전에 테스트를 작성하자!
🔥 통합이 중요하다면... 우리는 지속적으로 통합(CI)합니다!
🔥 단순함이 미덕이라면... 필요할 때 다시 디자인하세요(리팩토링)!
XP의 5가지 가치
XP 핵심 가치
1️⃣ COMMUNICATION (Comunicazione)
└─ Costante, faccia a faccia, onesta
2️⃣ SIMPLICITY (Semplicità)
└─ Fare la cosa più semplice che funziona (YAGNI)
3️⃣ FEEDBACK
└─ Rapido e continuo (da test, cliente, team)
4️⃣ COURAGE (Coraggio)
└─ Coraggio di refactorare, dire la verità, cambiare
5️⃣ RESPECT (Rispetto)
└─ Rispetto reciproco tra membri del teamXP의 12가지 실천사항
1. 테스트 주도 개발(TDD)
TDD XP의 기본 관행: 테스트 작성 전에 생산 코드의.
TDD 빨간색-녹색-리팩터링 주기
🔴 RED: Write a failing test
├─ Scrivi test per funzionalità che non esiste ancora
├─ Test deve fallire (altrimenti non stai testando nulla!)
└─ Focus su "what" non "how"
🟢 GREEN: Make the test pass
├─ Scrivi codice minimo per far passare il test
├─ Non importa se il codice è "brutto"
└─ Obiettivo: green bar il più velocemente possibile
🔵 REFACTOR: Improve the code
├─ Migliora design mantenendo test verdi
├─ Elimina duplicazione
├─ Rendi codice più leggibile
└─ Test ti proteggono da regressioni
♻️ REPEAT per ogni piccola funzionalità (cicli di 2-10 min)
TDD 예: isPalindrome 함수
// 🔴 RED: Scrivi test che fallisce
describe('isPalindrome', () => {{ '{' }}
it('should return true for "racecar"', () => {{ '{' }}
expect(isPalindrome('racecar')).toBe(true);
{{ '}' }});
{{ '}' }});
// Test fallisce perché isPalindrome non esiste!
// 🟢 GREEN: Implementa funzione minima
function isPalindrome(str: string): boolean {{ '{' }}
return str === str.split('').reverse().join('');
{{ '}' }}
// Test passa! ✅
// 🔵 REFACTOR: Migliora
function isPalindrome(str: string): boolean {{ '{' }}
const normalized = str.toLowerCase().replace(/[^a-z0-9]/g, '');
return normalized === normalized.split('').reverse().join('');
{{ '}' }}
// Aggiungi più test (edge cases)
it('should return true for "A man, a plan, a canal: Panama"', () => {{ '{' }}
expect(isPalindrome('A man, a plan, a canal: Panama')).toBe(true);
{{ '}' }});
it('should return false for "hello"', () => {{ '{' }}
expect(isPalindrome('hello')).toBe(false);
{{ '}' }});🎯 TDD의 이점
- 더 나은 디자인: 테스트 가능한 코드가 잘 설계되었습니다(낮은 결합도, 높은 응집도).
- 버그 감소: 바로 잡아낸 문제
- 안전한 리팩토링: 테스트는 당신을 보호합니다
- 실시간 문서: 테스트에서는 코드 사용 방법을 보여줍니다.
- 신뢰: 안심하고 배포하세요
2. 페어 프로그래밍
두 명의 개발자가 함께 작업합니다. 같은 컴퓨터 같은 코드에서.
🖥️ 드라이버
- 코드 작성
- 전술적 세부 사항에 집중
- "구현 방법"을 생각하세요
- 키보드 및 마우스 제어
🧭 네비게이터
- 실시간으로 코드 검토
- 전략에 집중
- "일반 관리"를 생각하십시오
- 개선을 제안합니다
♻️ 연속 회전
역할을 전환할 때마다 15~30분 (토마토 타이머). 쌍도 변경 하루/주 동안 지식 공유.
✅ 프로
- 지속적인 코드 검토
- 버그 감소(4눈 > 2)
- 신속한 지식 공유
- 멘토링의 실천
- 더 나은 문제 해결
- 집중(산만함 감소)
⚠️ 도전과제
- 피곤하다 (강렬하다)
- 명백한 이중 비용
- 성격 갈등
- 큰 기술 격차(불안함)
- 필요한 물리적 공간
- 원격이 더 어렵다
3. 지속적 통합(CI)
공유 저장소에 코드 통합 자주 (하루에 여러 번), 자동 빌드 및 테스트를 사용합니다.
CI 파이프라인 일반
📝 DEVELOPER COMMIT (multiple times per day)
↓
🔔 CI SERVER TRIGGERED (webhook da Git)
↓
📦 BUILD
├─ Checkout latest code
├─ Install dependencies (npm install)
├─ Compile (tsc, webpack)
└─ Package artifacts
↓
🧪 TEST
├─ Unit tests (Jest, Mocha)
├─ Integration tests
├─ Lint & code style (ESLint)
└─ Security scan (npm audit)
↓
✅ SUCCESS: Notifica team (Slack, email)
└─ Artifact pronto per deploy
❌ FAILURE: Notifica team immediatamente
└─ Fix diventa priorità #1 (stop the line!)🚨 황금률 CI
절대로 빌드를 망가진 채로 두지 마세요! 커밋이 CI를 위반하는 경우:
- 즉시 수정(최우선순위)
- 수정하는 데 10분 이상이 소요되는 경우: 돌아가는 것 커밋
- 로컬에서 수정한 후 다시 커밋
몇 시간/일 동안 빌드가 중단됨 → 지속적인 통합이 지속적인 혼돈이 됩니다!
4. 지속적인 리팩토링
리팩토링: 수정 없이 코드의 내부 구조를 변경합니다. 외부 행동. "시간이 있을 때"가 아니라 지속적으로 수행됩니다.
🔧 보이스카우트 규칙
"찾은 것보다 조금 더 나은 코드를 남겨주세요"
파일을 탭할 때마다 작은 개선(변수 이름 바꾸기, 추출 방법 등)
5.심플한 디자인
모든 테스트를 통과한 가장 심플한 디자인. 우선순위에 따른 4가지 규칙:
심플한 디자인의 4가지 규칙
1️⃣ Passes all tests
└─ Funzionalità corretta è priorità #1
2️⃣ Reveals intention
└─ Codice esprime chiaramente cosa fa
3️⃣ No duplication (DRY)
└─ Elimina codice duplicato
4️⃣ Fewest elements
└─ Minimo numero di classi/metodi necessari6. 단체코드 소유권
팀 전체 소유하다 모든 코드. 누구나 어떤 부분이든 편집할 수 있습니다.
✅ 장점
- 사일로 없음
- 단일 장애 지점 없음
- 공유된 지식
- 더 빠른 속도
🛡️ 보호
- 필수 코드 검토
- CI/CD 자동화 테스트
- 코딩 표준
- 페어 프로그래밍
기타 XP 관행
XP 실습 7-12
7️⃣ SMALL RELEASES
└─ Rilasci frequenti (settimane, non mesi)
8️⃣ 40-HOUR WEEK
└─ Sostenibilità, no overtime
9️⃣ ON-SITE CUSTOMER
└─ Cliente disponibile quotidianamente
🔟 CODING STANDARDS
└─ Team segue stesse convenzioni
1️⃣1️⃣ SYSTEM METAPHOR
└─ Metafora condivisa per architettura
1️⃣2️⃣ SUSTAINABLE PACE
└─ Marathon, not sprint린 소프트웨어 개발
유래: 도요타 생산 시스템
기대다 에서 유래 도요타 생산 시스템(TPS) 개발됨 1950년대 오노 다이이치. Mary Poppendieck과 Tom Poppendieck(2003)이 소프트웨어에 적용했습니다.
🏭 기본 린 개념
낭비를 제거하여 고객가치 극대화
7가지 린 원칙
1. 폐기물 제거
I 폐기물 7개 (Muda) 소프트웨어 개발 분야:
소프트웨어 개발의 7가지 낭비
1️⃣ PARTIALLY DONE WORK (Lavoro parzialmente completato)
├─ Es: Codice non integrato, feature 90% completa
└─ Soluzione: Definition of Done rigorosa, CI/CD
2️⃣ EXTRA FEATURES (Funzionalità extra)
├─ Es: Gold plating, "nice to have" mai usati
└─ Soluzione: YAGNI, MVP approach
3️⃣ RELEARNING (Riapprendimento)
├─ Es: Conoscenza persa, documentation assente
└─ Soluzione: Knowledge sharing, pair programming
4️⃣ HANDOFFS (Passaggi di consegna)
├─ Es: Dev → QA → Ops (silos)
└─ Soluzione: Cross-functional teams, DevOps
5️⃣ DELAYS (Ritardi)
├─ Es: Waiting for approvals, dependencies
└─ Soluzione: Rimuovere impedimenti, autonomia team
6️⃣ TASK SWITCHING (Multitasking)
├─ Es: Developer su 5 progetti contemporaneamente
└─ Soluzione: WIP limits, focus
7️⃣ DEFECTS (Difetti)
├─ Es: Bug in produzione, rework
└─ Soluzione: TDD, code review, automated testing2. 품질 향상(통합 품질)
"나중에 품질을 추가합니다"(테스트 단계)가 아니라 우리는 내부에 품질을 구축합니다 첫 순간부터.
🛠️ 품질 실천
- TDD: 테스트 드라이브 설계
- 자동화된 테스트: 단위, 통합, E2E
- 코드 검토: 모든 커밋을 검토했습니다.
- CI/CD: 빠른 피드백
- 정적 분석: 린팅, 유형 검사
3. 지식 창출(학습 확대)
소프트웨어 개발은 지식 창조, 반복 생산이 아닙니다.
📚 연습
- 회고전
- 사후부검
- 브라운백 세션
- 내부 기술 회담
- 문서(위키)
🔬 실험
- 스파이크 솔루션
- 개념 증명
- A/B 테스트
- 기능 플래그
- 빨리 실패하고 빨리 배우세요
4. 약속 연기(가능한 한 늦게 결정)
되돌릴 수 없는 결정을 연기할 때까지마지막 책임의 순간. 정보가 많을수록 더 나은 결정을 내릴 수 있습니다.
5. 빠른 배송
짧은 개발 주기 → 빠른 피드백 → 학습 가속화.
6. 사람을 존중하라
사람이 가장 중요한 자원입니다. 권한 부여와 신뢰.
7. 전체를 최적화하라
최적화 가치 흐름 로컬 하위 최적화가 아닌 엔드투엔드.
가치 흐름 매핑
VALUE STREAM: Dalla richiesta del cliente al valore consegnato
[Customer Request] → [Backlog] → [Dev] → [Test] → [Deploy] → [Customer Value]
⏱️ 1 day ⏱️ 3 days ⏱️ 5 days ⏱️ 2 days ⏱️ 1 day
📊 LEAD TIME: 12 giorni totali
📊 VALUE-ADD TIME: 8 giorni (effettivo lavoro)
📊 WASTE: 4 giorni (attese, handoff)
🎯 OTTIMIZZAZIONE:
- Ridurre tempo in backlog (WIP limits)
- Automatizzare testing (da 2 giorni a 2 ore)
- CI/CD per deploy (da 1 giorno a 10 min)
RISULTATO: Lead time 7 giorni → 2x più veloce!DevOps: 개발 + 운영
DevOps란 무엇입니까?
데브옵스 하나야 문화 사일로를 무너뜨리는 일련의 관행 개발과 운영 사이에서 지속적인 전달 가치가 있습니다.
❌ 사전 DevOps(사일로)
DEV: "Il nostro obiettivo è rilasciare features velocemente"
OPS: "Il nostro obiettivo è stabilità, no cambiamenti!"
RISULTATO: Conflitto, deploy ogni 3 mesi, outages frequenti✅ DevOps 사용(협업)
DevOps Team: "Obiettivo condiviso: consegnare valore continuamente E in sicurezza"
RISULTATO: Deploy multipli al giorno, high reliabilityCAMS 프레임워크
DevOps의 5가지 핵심 요소:
CALMS DevOps 원칙
🔵 C - CULTURE (Cultura)
├─ Collaborazione Dev-Ops
├─ Shared responsibility
├─ Blameless post-mortems
└─ Continuous learning
🔵 A - AUTOMATION (Automazione)
├─ CI/CD pipelines
├─ Infrastructure as Code
├─ Automated testing
└─ Self-service deployment
🔵 L - LEAN
├─ Elimina sprechi
├─ Small batch sizes
├─ Value stream focus
└─ Continuous improvement
🔵 M - MEASUREMENT (Misurazione)
├─ Metriche chiave (DORA metrics)
├─ Monitoring & Observability
├─ Data-driven decisions
└─ Feedback loops
🔵 S - SHARING (Condivisione)
├─ Knowledge sharing
├─ Open communication
├─ Cross-team collaboration
└─ Communities of practiceCI/CD 세부정보
지속적 통합(CI)
이미 XP가 포함되어 있습니다. 개발자는 자동 빌드 및 테스트를 통해 코드를 자주(매일) 통합합니다.
지속적 전달(CD)
CI를 통과하는 모든 커밋은 잠재적으로 배포 가능 생산 중. 배포에는 수동 승인이 필요합니다.
지속적인 배포
CI를 통과하는 모든 커밋은 자동으로 배포 생산 중. 수동 개입이 없습니다.
| 나는 기다린다 | CI | 지속적인 전달 | 지속적인 배포 |
|---|---|---|---|
| 빈도 | 모든 커밋 | 모든 커밋 | 모든 커밋 |
| 자동 빌드/테스트 | ✅ 예 | ✅ 예 | ✅ 예 |
| 자동 스테이징 배포 | ❌ 아니요 | ✅ 예 | ✅ 예 |
| 프로덕션 자동 배포 | ❌ 아니요 | ❌ 매뉴얼 | ✅ 자동 |
| 승인 필요 | No | 예(프로덕션용) | No |
| 생산할 시간 | Settimane | 시간/일 | Minuti |
CD 파이프라인 예
🔵 COMMIT & PUSH
↓
📦 CI: BUILD & TEST (2-5 min)
├─ Compile
├─ Unit tests
├─ Lint
└─ Security scan
↓
🟢 DEPLOY TO STAGING (auto) (1 min)
├─ Blue/Green deployment
├─ Smoke tests
└─ Integration tests (5 min)
↓
🟡 MANUAL APPROVAL (Continuous Delivery)
├─ Product Owner reviews staging
├─ Click "Deploy to Prod" button
└─ OR: Automatic (Continuous Deployment)
↓
🔴 DEPLOY TO PRODUCTION (1 min)
├─ Canary release (5% traffic)
├─ Monitor metrics
├─ Gradual rollout 100%
└─ Success! 🎉 (or auto-rollback if errors)코드형 인프라(IaC)
인프라 관리 암호 수동 구성 대신 버전이 지정됩니다.
예: 테라폼
// Define infrastructure as code
resource "aws_instance" "web_server" {{ '{' }}
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {{ '{' }}
Name = "ProductionWebServer"
{{ '}' }}
{{ '}' }}
resource "aws_s3_bucket" "assets" {{ '{' }}
bucket = "my-app-assets"
acl = "public-read"
{{ '}' }}
// terraform apply → Infra creata automaticamente!
// terraform destroy → Infra eliminata
// Version control → Git per infra changes🎯 IaC 혜택
- 재생할 수 있는: 개발/스테이징/프로덕션의 동일한 인프라
- 버전 지정: 인프라 변경에 대한 Git 이력
- 테스트 가능: CI의 인프라 검증
- 선적 서류 비치: 코드는 문서입니다
- 재해 복구: 몇 분 안에 아래를 다시 생성하세요.
DORA 지표
DevOps 연구 및 평가 4가지 주요 지표를 확인했습니다. DevOps 성능 측정:
4 DORA 지표
1️⃣ DEPLOYMENT FREQUENCY
└─ Quanto spesso deployiamo in prod?
Elite: Multiple per day
High: Weekly to monthly
Low: Monthly to every 6 months
2️⃣ LEAD TIME FOR CHANGES
└─ Tempo da commit a produzione?
Elite: < 1 hour
High: 1 day to 1 week
Low: 1 month to 6 months
3️⃣ TIME TO RESTORE SERVICE
└─ Quanto per ripristinare dopo incident?
Elite: < 1 hour
High: < 1 day
Low: 1 week to 1 month
4️⃣ CHANGE FAILURE RATE
└─ % deploy che causano failure?
Elite: 0-15%
High: 16-30%
Low: 31-45%XP, Lean 및 DevOps를 Scrum과 통합
🔧 최고의 조합: 스크럼 + XP + DevOps
- 스크럼: 프로젝트 관리를 위한 프레임워크(스프린트, 역할, 행사)
- XP: 기술 사례(TDD, 쌍 프로그래밍, 리팩토링)
- 데브옵스: 자동화 및 문화(CI/CD, IaC, 모니터링)
- 기대다: 폐기물 제거 및 흐름 최적화에 대한 사고방식
통합적 접근
📅 SPRINT PLANNING (Scrum)
└─ Team seleziona User Stories (Lean: pull system)
💻 DEVELOPMENT (XP Practices)
├─ Pair Programming
├─ TDD (Red-Green-Refactor)
├─ Continuous Refactoring
└─ Simple Design
🔄 EVERY COMMIT (DevOps)
├─ CI pipeline runs
├─ Automated tests
├─ Deploy to staging
└─ Ready for production
📊 DAILY STANDUP (Scrum)
└─ Walk the board, identify impediments
🎬 SPRINT REVIEW (Scrum)
└─ Demo features deployed to staging
🔁 RETROSPECTIVE (Scrum + Lean)
├─ Inspect & Adapt
├─ Identify waste
└─ Kaizen experiments
🚀 DEPLOY TO PRODUCTION (DevOps)
└─ Continuous Delivery: quando PO approva결론
XP, 린 및 DevOps는 보완적인 완벽하게 통합됩니다. Scrum과 같은 민첩한 프레임워크. 이들은 함께 소프트웨어 개발에 대한 포괄적인 접근 방식을 형성합니다. 현대: 빠르고 고품질의 지속적인 전달.
💡 핵심 포인트
- XP는 TDD, 쌍 프로그래밍, CI, 리팩토링과 같은 극단적인 기술 사례를 제공합니다.
- 린(Lean)은 낭비를 제거하고 엔드투엔드 가치 흐름을 최적화합니다.
- DevOps는 문화와 자동화(CI/CD, IaC)를 통해 Dev-Ops 사일로를 무너뜨립니다.
- TDD는 디자인을 개선하고 버그를 극적으로 줄입니다.
- 지속적인 배포를 통해 하루에 여러 릴리스를 허용합니다.
- DORA 지표는 DevOps 성능(배포 빈도, 리드 타임, MTTR, CFR)을 측정합니다.
- 최선의 접근 방식: 스크럼(프레임워크) + XP(실행) + DevOps(자동화)
📚 전체 시리즈
소프트웨어 개발 방법론에 관한 시리즈를 완료하셨습니다! 다음을 탐색해 보셨나요?
- 방법론 소개
- 폭포수 모델(고전적 접근 방식)
- 민첩한 방법론(가치 및 원칙)
- 스크럼 프레임워크(역할, 이벤트, 아티팩트)
- 칸반 방법(연속 흐름, WIP 제한)
- XP, Lean 및 DevOps(기술 관행 및 문화)
이제 소프트웨어 구축을 위한 최신 방법론을 완전히 이해하게 되었습니다. 효과적이고 지속 가능한 방식으로 품질을 유지하세요! 🚀