@cloudkinetix/bmad-enhanced/expansion-packs/ck-parallel-dev/data/parallel-patterns.md

Cloud-Kinetix enhanced fork of BMAD-METHOD - Breakthrough Method of Agile AI-driven Development with robust versioning and unified validation.

# Common Parallel Development Patterns

## Overview

This document catalogs proven patterns for successful parallel development, helping teams maximize efficiency while minimizing conflicts.

## Pattern Categories

### 1. Feature Isolation Pattern

**When to Use**: Independent features with minimal shared code
**Success Rate**: ★★★★★ (5/5)

```
Wave 1: Authentication, User Profile, Settings
Wave 2: Dashboard (depends on auth), Reports, Analytics
```

**Key Success Factors**:

- Clear API contracts defined upfront
- Separate database tables/schemas
- Independent test suites
- Well-defined integration points

### 2. Microservice Pattern

**When to Use**: Service-oriented architecture with clear boundaries
**Success Rate**: ★★★★☆ (4/5)

```
Parallel Streams:
- Service A: Payment processing
- Service B: Inventory management
- Service C: Order fulfillment
- Service D: Customer notifications
```

**Key Success Factors**:

- Service contracts versioned
- Mock services for testing
- Async communication patterns
- Circuit breakers for resilience

### 3. UI Component Pattern

**When to Use**: Frontend development with component libraries
**Success Rate**: ★★★★☆ (4/5)

```
Component Development:
- Header/Navigation (Team 1)
- Data Tables (Team 2)
- Forms/Inputs (Team 3)
- Charts/Visualizations (Team 4)
```

**Key Success Factors**:

- Storybook or similar for isolation
- Shared design system
- Props/API consistency
- Visual regression testing

### 4. Database Migration Pattern

**When to Use**: Schema changes with data migrations
**Success Rate**: ★★★☆☆ (3/5) - Requires careful coordination

```
Migration Waves:
Wave 1: Add new columns (backward compatible)
Wave 2: Migrate data to new structure
Wave 3: Update application code
Wave 4: Remove old columns
```

**Key Success Factors**:

- Backward compatible changes
- Feature flags for gradual rollout
- Comprehensive rollback scripts
- Data integrity validation

### 5. API Evolution Pattern

**When to Use**: API updates while maintaining compatibility
**Success Rate**: ★★★★☆ (4/5)

```
Version Strategy:
- v1: Existing API (maintained)
- v2: New endpoints (parallel development)
- Migration: Gradual client updates
- Deprecation: Planned v1 sunset
```

**Key Success Factors**:

- Clear versioning strategy
- Parallel endpoint support
- Client migration plan
- Deprecation notices

## Anti-Patterns to Avoid

### 1. The Big Bang Anti-Pattern

**Description**: Trying to parallelize everything at once
**Why It Fails**: Too many dependencies, coordination overhead
**Alternative**: Start with 2-3 independent items, scale gradually

### 2. The Shared State Anti-Pattern

**Description**: Multiple teams modifying global state
**Why It Fails**: Race conditions, merge conflicts
**Alternative**: State isolation, event-driven updates

### 3. The Documentation Lag Anti-Pattern

**Description**: Code changes without updating docs
**Why It Fails**: Integration confusion, duplicated work
**Alternative**: Docs-as-code, automated API docs

## Pattern Selection Guide

Use this decision tree to select the right pattern:

```
1. Are the features completely independent?
   YES → Feature Isolation Pattern
   NO → Continue to 2

2. Do you have service boundaries?
   YES → Microservice Pattern
   NO → Continue to 3

3. Is it primarily UI work?
   YES → UI Component Pattern
   NO → Continue to 4

4. Does it involve database changes?
   YES → Database Migration Pattern
   NO → Continue to 5

5. Is it API development?
   YES → API Evolution Pattern
   NO → Consider sequential development
```

## Success Metrics

Track these metrics to measure pattern effectiveness:

1. **Merge Conflict Rate**: Target < 5%
2. **Integration Time**: Target < 2 hours per wave
3. **Rollback Frequency**: Target < 1%
4. **Team Velocity Increase**: Target > 30%
5. **Quality Metrics**: No decrease in coverage/standards

## Pattern Evolution

Patterns should evolve based on team experience:

1. **Beginner**: Start with Feature Isolation
2. **Intermediate**: Add Microservice and UI patterns
3. **Advanced**: Include Database and API patterns
4. **Expert**: Custom hybrid patterns for your domain

Remember: The best pattern is the one your team can execute successfully!