agentic-qe 1.1.0 → 1.3.0

package/.claude/skills/xp-practices/SKILL.md

@@ -0,0 +1,671 @@
+---
+name: xp-practices
+description: Apply XP practices including pair programming, ensemble programming, continuous integration, and sustainable pace. Use when implementing agile development practices, improving team collaboration, or adopting technical excellence practices.
+version: 1.0.0
+category: development
+tags: [xp, pair-programming, ensemble-programming, continuous-integration, sustainable-pace, agile, teamwork]
+difficulty: intermediate
+estimated_time: 2-3 hours
+author: user
+---
+
+# Extreme Programming (XP) Practices
+
+## Core Philosophy
+
+XP emphasizes technical excellence, rapid feedback, and sustainable pace. It's about doing the simple thing that could possibly work, then iterating based on real feedback.
+
+## The Five Values
+
+1. **Communication** - Everyone knows what everyone else is doing
+2. **Simplicity** - Do the simplest thing that could possibly work
+3. **Feedback** - Get feedback early and often
+4. **Courage** - Tell the truth about progress and estimates, adapt when needed
+5. **Respect** - Everyone contributes value, treat team members well
+
+## Core XP Practices
+
+### 1. Pair Programming
+
+**Definition:** Two developers working together at one workstation. One writes code (driver), the other reviews each line as it's typed (navigator).
+
+#### Pairing Styles
+
+**Driver-Navigator (Classic)**
+- Driver: Writes code
+- Navigator: Reviews, suggests, thinks ahead
+- Rotate every 20-30 minutes
+
+**Ping-Pong Pairing (with TDD)**
+```
+Person A: Writes failing test
+Person B: Makes test pass
+Person B: Refactors
+Person B: Writes next failing test
+Person A: Makes test pass
+[Continue...]
+```
+
+**Strong-Style Pairing**
+- "For an idea to go from your head to the computer, it must go through someone else's hands"
+- Great for mentoring/knowledge transfer
+
+#### When to Pair
+
+**ALWAYS pair for:**
+- Complex or risky code
+- Learning new technology
+- Onboarding new team members
+- Critical bug fixes
+- Architectural decisions
+
+**CAN pair for:**
+- Regular feature development
+- Refactoring sessions
+- Code reviews (live pairing review)
+
+**DON'T pair for:**
+- Simple, well-understood tasks
+- Spikes/research (pair to discuss findings)
+- Personal learning time
+- Admin work
+
+#### Making Pairing Work
+
+**Do:**
+- ✅ Switch roles regularly (20-30 min)
+- ✅ Take breaks together
+- ✅ Speak your thoughts aloud
+- ✅ Ask questions
+- ✅ Challenge ideas respectfully
+- ✅ Keep sessions 2-4 hours max
+
+**Don't:**
+- ❌ Grab keyboard without asking
+- ❌ Check phone/email while pairing
+- ❌ Dominate the conversation
+- ❌ Pair all day every day (exhausting)
+- ❌ Pair with same person exclusively
+
+#### Remote Pairing Tools
+
+- **VS Code Live Share** - Shared editing, debugging
+- **Tuple** - Low-latency screen sharing for pairing
+- **Zoom/Meet** - Standard video with screen share
+- **tmux/screen** - Terminal sharing for CLI work
+
+### 2. Ensemble Programming (Mob Programming)
+
+**Definition:** 3+ developers working together on the same code at the same workstation.
+
+#### Ensemble Setup
+
+```
+[Projector/Large Screen]
+        ↓
+[Computer with Code]
+        ↓
+    [Driver]
+      ← ← ←
+[Navigator 1] [Navigator 2] [Navigator 3]
+```
+
+**Rotation:** Driver switches every 5-10 minutes
+
+#### Ensemble Patterns
+
+**Strong-Style Mob**
+- Navigators direct, driver types
+- Driver doesn't add own ideas while driving
+- Forces clear communication
+
+**Rotating Facilitator**
+- One person manages time/rotation
+- Keeps discussion focused
+- Rotates like driver position
+
+**Expert Learning**
+- Expert explains while driving
+- Others learn and ask questions
+- Useful for knowledge transfer
+
+#### When to Ensemble
+
+**Great for:**
+- Complex problem solving
+- Architectural decisions  
+- Learning new frameworks
+- Kickstarting difficult features
+- Resolving blockers
+
+**Not great for:**
+- Simple, well-understood tasks
+- When people need deep focus
+- Long-term (unsustainable)
+
+### 3. Continuous Integration
+
+**Definition:** Integrate code into shared repository frequently (multiple times per day), with automated build and tests.
+
+#### CI Workflow
+
+```
+Developer:
+1. Pull latest from main
+2. Make small change (<2 hours work)
+3. Run tests locally (all pass)
+4. Commit and push to main
+5. CI runs tests automatically
+6. If tests fail → fix immediately
+
+Pipeline:
+main ← commit
+  ↓
+[Run Tests]
+  ↓
+[Build]
+  ↓
+[Deploy to Staging]
+```
+
+#### CI Best Practices
+
+**Commit frequently:**
+- Small commits (< 2 hours of work)
+- Each commit should pass all tests
+- Commit to main/trunk (no long-lived branches)
+
+**Keep build fast:**
+- Full build + tests < 10 minutes
+- Faster feedback = more valuable
+- Parallelize slow tests
+
+**Fix broken builds immediately:**
+- Broken build = top priority
+- Don't commit more code until fixed
+- Revert commit if fix takes too long
+
+**Automate everything:**
+- Tests run automatically
+- Build happens automatically
+- Deploy to staging automatically
+
+### 4. Test-Driven Development (TDD)
+
+(See `tdd-london-chicago` skill for deep dive)
+
+**Red-Green-Refactor cycle:**
+1. Write failing test (Red)
+2. Write minimal code to pass (Green)
+3. Refactor while keeping tests green
+
+**XP emphasis:** Tests as executable specifications, safety net for refactoring.
+
+### 5. Simple Design
+
+**Four Rules of Simple Design** (Kent Beck):
+1. Passes all tests
+2. Reveals intention (clear, expressive)
+3. No duplication (DRY principle)
+4. Fewest elements (no speculative code)
+
+**Apply in order - tests first!**
+
+#### Examples
+
+**Not simple:**
+```javascript
+// Speculative generalization
+class PaymentProcessor {
+  process(payment, options = {}) {
+    // Supports 15 payment types we might need someday
+    // Has configuration for every possible scenario
+    // 500 lines of "just in case" code
+  }
+}
+```
+
+**Simple:**
+```javascript
+// Just what we need today
+class PaymentProcessor {
+  processCreditCard(cardInfo) {
+    // Does one thing well
+    // 30 lines of clear code
+  }
+}
+
+// Add complexity only when needed
+```
+
+### 6. Refactoring
+
+**Definition:** Improving code structure without changing behavior.
+
+#### When to Refactor
+
+**The Rule of Three:**
+1. First time: Just do it
+2. Second time: Wince and duplicate
+3. Third time: Refactor
+
+**Refactor when:**
+- Tests are green
+- You see duplication
+- Code is hard to understand
+- Adding feature reveals poor design
+- During green phase of TDD
+
+**Don't refactor when:**
+- Tests are failing
+- Under deadline pressure (address later)
+- Code works and rarely changes
+
+#### Safe Refactoring
+
+**Always:**
+1. Have tests that pass
+2. Refactor in small steps
+3. Run tests after each step
+4. Commit working code frequently
+
+**Common Refactorings:**
+- Extract method
+- Rename for clarity
+- Remove duplication
+- Introduce parameter object
+- Replace conditional with polymorphism
+
+### 7. Collective Code Ownership
+
+**Principle:** Anyone can improve any part of the codebase.
+
+**Benefits:**
+- No bottlenecks (no waiting for "that one person")
+- Knowledge spreads across team
+- Code quality improves (more eyes)
+- Bus factor > 1
+
+**Requirements:**
+- Comprehensive test suite (safety net)
+- Coding standards (consistency)
+- Continuous integration (catch issues fast)
+- Code reviews or pairing (maintain quality)
+
+**In practice:**
+```
+❌ "That's Alice's module, only she can change it"
+✅ "I see an issue in this module, I'll pair with Alice to fix it"
+✅ "I need to change this module, I'll write tests first"
+```
+
+### 8. Coding Standards
+
+**Purpose:** Consistency makes collaboration easier.
+
+**What to standardize:**
+- Formatting (use auto-formatter: Prettier, Black)
+- Naming conventions
+- File structure
+- Testing patterns
+- Documentation style
+
+**How to maintain:**
+- Automated linting (ESLint, Pylint)
+- Pre-commit hooks
+- CI enforcement
+- Pair/ensemble programming (natural alignment)
+
+**Don't:**
+- Have 50-page style guides no one reads
+- Enforce arbitrary preferences
+- Spend hours debating tabs vs spaces (use formatter)
+
+### 9. Sustainable Pace
+
+**Principle:** Team should work at a pace they can sustain indefinitely.
+
+**40-hour work week:**
+- No routine overtime
+- Regular hours = sustainable productivity
+- Tired developers write bugs
+
+**Warning signs of unsustainable pace:**
+- Regular late nights/weekends
+- Increasing bug rate
+- Declining code quality
+- Team burnout/turnover
+- Decreased morale
+
+**How to maintain:**
+- Realistic estimates
+- Buffer time in plans
+- Say no to unrealistic deadlines
+- Measure velocity, plan accordingly
+- Take vacations
+
+### 10. Small Releases
+
+**Principle:** Release working software frequently.
+
+**Benefits:**
+- Fast feedback from users
+- Reduced risk (small changes)
+- Easier to debug (what changed?)
+- Business value delivered sooner
+
+**How small?**
+- Deploy to production: daily or weekly
+- Internal release: multiple times per day
+- Feature flags for incomplete work
+
+**Continuous Deployment:**
+```
+Commit → CI Tests → Deploy Staging → Automated Tests → Deploy Production
+[All automated, happens multiple times per day]
+```
+
+### 11. On-Site Customer
+
+**Modern interpretation:** Product Owner embedded with team.
+
+**Customer responsibilities:**
+- Writes user stories
+- Prioritizes backlog
+- Answers questions immediately  
+- Accepts completed work
+- Makes scope decisions
+
+**Not realistic:** Customer physically present 40hrs/week
+
+**Practical compromise:**
+- Daily standup attendance
+- Available for questions (Slack/quick calls)
+- Sprint planning and review
+- Regular demo sessions
+
+### 12. Metaphor / Ubiquitous Language
+
+**Principle:** Shared vocabulary between technical and non-technical team members.
+
+**Example - E-commerce System:**
+```
+Shared language:
+- "Cart" (not "session shopping container")
+- "Checkout" (not "payment initialization workflow")
+- "Order" (not "purchase transaction record")
+
+Everyone uses same terms:
+- Product owner writes stories using these words
+- Developers name classes/methods using these words
+- Tests use these words
+- Documentation uses these words
+```
+
+**Benefits:**
+- Clearer communication
+- Code reflects business domain
+- Less translation needed
+- Easier onboarding
+
+## Combining XP Practices
+
+### Practice Synergies
+
+**TDD + Pair Programming**
+```
+Ping-pong pairing with TDD:
+Person A writes test → Person B makes it pass
+High quality code, fast feedback, knowledge sharing
+```
+
+**Collective Ownership + CI + Tests**
+```
+Anyone can change anything because:
+- Tests catch regressions immediately
+- CI runs tests on every commit  
+- Broken builds fixed immediately
+No fear of stepping on toes
+```
+
+**Simple Design + Refactoring**
+```
+Start with simplest design
+When requirements change → refactor
+Tests give confidence to refactor
+Never build more than needed
+```
+
+## Adapting XP for Your Context
+
+### Startup Context
+- **Keep:** TDD, CI, Simple Design, Small Releases
+- **Adapt:** Pair occasionally (not always), lighter standards
+- **Skip:** Might not need dedicated on-site customer
+
+### Enterprise Context
+- **Keep:** All practices, especially sustainable pace
+- **Adapt:** More formal standards, documentation requirements
+- **Add:** Architecture reviews, security scans
+
+### Remote Team
+- **Keep:** All core practices  
+- **Adapt:** Remote pairing tools, async communication
+- **Add:** Over-communicate, document decisions
+
+### Legacy Codebase
+- **Start with:** Tests for changes, CI, Refactoring
+- **Build towards:** TDD for new code, Collective ownership
+- **Be patient:** Can't adopt everything at once
+
+## Common Objections (and Responses)
+
+**"Pair programming is twice as slow"**
+→ Studies show 15% slower to write, 15% fewer bugs, better design. Net positive.
+
+**"We don't have time for TDD"**
+→ You don't have time NOT to. Debugging takes longer than writing tests.
+
+**"Continuous integration is too hard to set up"**
+→ Start simple: GitHub Actions with one test. Build from there.
+
+**"Collective ownership will create chaos"**
+→ Only with poor tests and no CI. Fix those first.
+
+**"40-hour weeks won't work for our deadlines"**
+→ Your deadlines are based on unsustainable pace. Adjust estimates.
+
+## XP in Quality Engineering
+
+### QE-Specific Applications
+
+**Ensemble Testing Sessions**
+- 3-5 people exploring together
+- Share testing heuristics in real-time
+- Rapid bug discovery and investigation
+
+**Test Code Pairing**
+- Pair on test automation
+- Share testing patterns
+- Improve test quality
+
+**Quality as Team Responsibility**
+- Developers write tests
+- QE does exploratory testing
+- Everyone owns quality
+
+**Continuous Testing**
+- Tests run on every commit
+- Fast feedback on quality
+- No separate QE phase
+
+## Measuring XP Success
+
+**Code Quality Metrics:**
+- Test coverage trend
+- Defect density
+- Code churn
+
+**Team Health Metrics:**
+- Velocity consistency
+- Team satisfaction surveys
+- Turnover rate
+
+**Delivery Metrics:**
+- Deployment frequency
+- Lead time for changes
+- Mean time to recovery
+
+**Don't measure:**
+- Lines of code written
+- Hours worked
+- Number of commits
+
+## Resources
+
+**Books:**
+- **Extreme Programming Explained** by Kent Beck
+- **Extreme Programming Installed** by Jeffries, Anderson, Hendrickson
+- **Pair Programming Illuminated** by Williams & Kessler
+
+**Modern Practices:**
+- Remote mob programming techniques
+- DevOps integration with XP
+- Continuous deployment patterns
+
+## Using with QE Agents
+
+### Agent-Human Pair Testing
+
+**qe-test-generator** + Human QE:
+```typescript
+// Ping-pong pattern with AI agent
+// Human writes test charter
+const charter = "Test payment processing edge cases";
+
+// Agent generates test code
+const test = await qe-test-generator.generate(charter);
+
+// Human reviews and refines
+const refinedTest = await human.review(test);
+
+// Agent implements refinements
+await qe-test-generator.implement(refinedTest);
+```
+
+### Ensemble Testing with Multiple Agents
+
+```typescript
+// Mob testing: Multiple agents + human coordinator
+const ensemble = await FleetManager.startEnsemble({
+  facilitator: 'human',
+  participants: [
+    'qe-test-generator',
+    'qe-coverage-analyzer',
+    'qe-security-scanner'
+  ],
+  rotation: '10min',
+  charter: 'Design test strategy for new payment API'
+});
+
+// Human directs, agents execute and suggest
+// Rotate which agent is "driving" every 10 minutes
+```
+
+### Continuous Integration with Agents
+
+```yaml
+# AI agents in CI pipeline
+name: XP CI with Agents
+
+on: [push]
+
+jobs:
+  test:
+    steps:
+      # Agent runs risk analysis
+      - name: Risk Analysis
+        run: aqe agent run qe-regression-risk-analyzer
+
+      # Agent generates tests for changes
+      - name: Generate Tests
+        run: aqe agent run qe-test-generator
+
+      # Agent executes all tests
+      - name: Execute Tests
+        run: aqe agent run qe-test-executor
+
+      # Agent analyzes coverage
+      - name: Coverage Check
+        run: aqe agent run qe-coverage-analyzer
+```
+
+### Collective Code & Test Ownership
+
+```typescript
+// Agents help maintain collective ownership
+// Any team member can improve any test
+// Agents ensure consistency
+
+await qe-quality-analyzer.enforceStandards({
+  scope: 'all-tests',
+  standards: ['naming-conventions', 'test-structure', 'assertions'],
+  autoFix: true  // Agent fixes simple violations
+});
+```
+
+### Sustainable Pace with Agent Assistance
+
+```typescript
+// Agents handle grunt work, humans focus on high-value tasks
+const workDistribution = {
+  agents: [
+    'Repetitive regression testing',
+    'Log analysis and pattern detection',
+    'Test data generation',
+    'Coverage gap analysis',
+    'Performance monitoring'
+  ],
+  humans: [
+    'Exploratory testing',
+    'Risk assessment',
+    'Test strategy decisions',
+    'Domain-specific edge cases',
+    'Stakeholder communication'
+  ]
+};
+
+// Result: 40-hour work week, sustainable, high productivity
+```
+
+---
+
+## Related Skills
+
+**Core Quality Practices:**
+- [agentic-quality-engineering](../agentic-quality-engineering/) - Agents as pair partners
+- [holistic-testing-pact](../holistic-testing-pact/) - Whole-team quality practices
+- [context-driven-testing](../context-driven-testing/) - Adapt XP to context
+
+**Development Practices:**
+- [tdd-london-chicago](../tdd-london-chicago/) - TDD within XP workflow
+- [refactoring-patterns](../refactoring-patterns/) - Safe refactoring techniques
+- [code-review-quality](../code-review-quality/) - Review as pairing alternative
+
+**Testing Specializations:**
+- [exploratory-testing-advanced](../exploratory-testing-advanced/) - Ensemble exploration
+- [test-automation-strategy](../test-automation-strategy/) - CI/CD integration
+
+---
+
+## Remember
+
+XP practices work together as a system. Don't cherry-pick randomly:
+- Start with practices that give immediate value
+- Build supporting practices gradually
+- Adapt to your context
+- Measure results
+
+**The goal:** Sustainable delivery of high-quality software through technical excellence and teamwork.
+
+**With Agents**: XP practices amplify agent effectiveness. Pair humans with agents for best results. Agents handle repetitive work, humans provide judgment and creativity.