XP、リーン、DevOps: 技術的実践とアジャイル文化
スクラムとカンバンに加えて、開発の基礎となる他の方法論や文化もあります 最新のソフトウェア: エクストリーム プログラミング (XP) 極端な技術的実践により、 傾く 無駄の排除に重点を置き、 DevOps それは壊れる 開発と運用の間のサイロ化。
🎯 何を学ぶか
- XP: 12 の基本的な実践 (TDD、ペア プログラミング、CI、リファクタリング)
- リーン: 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. ペアプログラミング
2 人の開発者が協力して開発に取り組んでいます 同じコンピュータ 同じコード上で。
🖥️ ドライバー
- コードを書く
- 戦術的な詳細に焦点を当てる
- 「どう実現するか」を考える
- キーボードとマウスを制御する
🧭ナビゲーター
- リアルタイムでコードをレビューする
- 戦略に集中する
- 「総合管理」を考える
- 改善を提案します
♻️ 連続回転
役割を切り替える間隔 15～30分 （トマトタイマー）。ペアも変える 日中/週中 知識の共有.
✅ プロ
- 継続的なコードレビュー
- バグの減少 (4 つの目 > 2)
- 迅速な知識の共有
- メンターシップの実践
- より良い問題解決
- 集中力（気を散らすものを減らす）
⚠️ 課題
- 疲れる（激しい）
- 明らかに二重コスト
- 性格の不一致
- スキルギャップが大きい（イライラする）
- 必要な物理的スペース
- リモートのほうが難しい
3. 継続的インテグレーション (CI)
コードを共有リポジトリに統合する 頻繁に (1日に数回)、 自動ビルドとテストを使用します。
典型的な 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: 素早いフィードバック
- 静的解析: lint、型チェック
3. 知識の創造（学習の増幅）
ソフトウェア開発というのは、 知識の創造、反復生産ではありません。
📚 実践
- 回顧展
- 事後分析
- ブラウンバッグセッション
- 社内の技術的な話
- ドキュメント (wiki)
🔬 実験
- スパイクソリューション
- 概念実証
- 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 それは1つです 文化 サイロを打破する一連の実践方法 開発と運用の間で、 継続的デリバリー 価値のあるもの。
❌ 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 reliabilityCALMSフレームワーク
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 | 継続的デリバリー | 継続的な展開 |
|---|---|---|---|
| 頻度 | すべてのコミット | すべてのコミット | すべてのコミット |
| 自動ビルド/テスト | ✅ はい | ✅ はい | ✅ はい |
| 自動ステージングのデプロイ | ❌ いいえ | ✅ はい | ✅ はい |
| Prod Auto のデプロイ | ❌ いいえ | ❌ マニュアル | ✅ 自動 |
| 承認が必要です | No | はい (製品の場合) | No |
| 本番までの時間 | 週間 | 時間/日 | 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 の利点
- 再現可能: dev/staging/prod で同じインフラストラクチャ
- バージョン管理: インフラ変更の 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 をスクラムと統合
🔧 最適な組み合わせ: スクラム + XP + DevOps
- スクラム： プロジェクト管理のフレームワーク (スプリント、役割、儀式)
- XP: 技術的な実践 (TDD、ペアプログラミング、リファクタリング)
- DevOps: 自動化と文化 (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 は 補完的な と完全に統合します スクラムのようなアジャイルフレームワーク。これらは共に、ソフトウェア開発への包括的なアプローチを形成します。 現代: 迅速、高品質、継続的な配信.
💡 キーポイント
- XP は、TDD、ペア プログラミング、CI、リファクタリングなどの極端な技術的実践をもたらします。
- リーンにより無駄が排除され、バリュー ストリームがエンドツーエンドで最適化されます。
- DevOps は、文化と自動化 (CI/CD、IaC) によって Dev-Ops のサイロを打破します。
- TDD は設計を改善し、バグを劇的に削減します
- 継続的デプロイメントにより、1 日に複数のリリースが可能
- DORA メトリクスは DevOps パフォーマンスを測定します (デプロイ頻度、リードタイム、MTTR、CFR)
- 最良のアプローチ: スクラム (フレームワーク) + XP (プラクティス) + DevOps (自動化)
📚 完全なシリーズ
ソフトウェア開発方法論に関するシリーズはこれで完了です。次のことを調べましたか?
- 方法論の紹介
- ウォーターフォール モデル (古典的なアプローチ)
- アジャイル手法（価値観と原則）
- スクラム フレームワーク (ロール、イベント、成果物)
- カンバン方式（連続フロー、WIP制限）
- XP、Lean、DevOps (技術慣行と文化)
これで、ソフトウェアを構築するための最新の方法論を完全に理解できました。 効果的かつ持続可能な方法で品質を向上させます。 🚀