@cloudkinetix/bmad-enhanced

# Create Parallel Development Workflow Plan Task ## Purpose Guide users through parallel development workflow selection and create a detailed plan that emphasizes conflict detection, wave management, and efficient resource utilization using git worktrees. ## Task Instructions ### 1. Understand Parallel Development Needs [[LLM: Start with discovery about parallel work requirements]] Ask the user: 1. **Work Type & Scope**: - Feature development (multiple features)? - Story execution (sprint stories)? - Bug fixing (multiple bugs)? - Mixed work types? 2. **Team Context**: - Team size and availability? - Git expertise level? - Current branching strategy? - CI/CD maturity? 3. **Constraints**: - Timeline pressure? - Integration requirements? - Testing resources? - Deployment windows? ### 2. Recommend Parallel Workflow Based on answers, recommend: **Development Workflows:** - `parallel-feature-development` - Multiple features in parallel - `parallel-story-execution` - Sprint story parallelization - `parallel-bug-fixing` - Efficient bug fix coordination **Optimization Workflows:** - `parallel-testing` - Parallel test execution - `parallel-review` - Distributed code review ### 3. Create Parallel Development Workflow Plan [[LLM: Generate plan with parallel-specific elements]] ````markdown # Parallel Development Workflow Plan: {{Workflow Name}}  **Created Date**: {{current date}} **Parallel Scope**: {{number}} items **Team Size**: {{number}} developers **Conflict Management**: {{strategy}} ## Parallel Objectives {{Clear description of what will be developed in parallel}} ## Prerequisites Check - [ ] Git version 2.7+ (worktree support) - [ ] Clean working directory - [ ] Stable base branch - [ ] CI/CD pipeline ready - [ ] Team briefed on parallel approach ## Workflow Steps with Wave Management ### Phase 1: Analysis & Planning  - [ ] Step 1: Work Item Analysis  - **Analysis**: Component dependencies, file conflicts - **Output**: Conflict matrix and risk assessment - **Decision**: Wave assignment strategy  - [ ] Step 2: Wave Assignment  - **Grouping**: Conflict-free work groups - **Waves**: {{number}} planned waves - **Timeline**: Estimated completion per wave ### Phase 2: Parallel Setup  - [ ] Step 3: Environment Setup  - **Worktrees**: Create {{number}} isolated environments - **Naming**: {{naming-convention}} - **Branches**: Feature/bugfix branches created - [ ] Step 4: Coordination Setup  - **Tracking**: Progress dashboard configured - **Communication**: Sync channels established - **Automation**: CI/CD per worktree ### Phase 3: Parallel Execution  - [ ] Step 5: Wave 1 Execution  - **Items**: {{list of wave 1 items}} - **Developers**: {{assignments}} - **Expected Duration**: {{time}} - [ ] Step 6: Progress Monitoring  - **Metrics**: Completion rate, blockers, conflicts - **Sync Points**: Daily standups, async updates - **Escalation**: Conflict resolution process - [ ] Step 7: Continuous Testing  - **Strategy**: Test per worktree - **Automation**: CI runs on push - **Validation**: Quality gates enforced ### Phase 4: Integration  - [ ] Step 8: Merge Planning  - **Sequence**: Priority-based merge order - **Strategy**: {{rebase|merge|squash}} - **Validation**: Pre-merge testing - [ ] Step 9: Conflict Resolution  - **Detection**: Automated conflict alerts - **Resolution**: Developer pairs assigned - **Verification**: Post-merge validation ### Phase 5: Cleanup & Learning  - [ ] Step 10: Worktree Cleanup  - **Removal**: Clean worktree directories - **Branches**: Archive or delete - **Documentation**: Update guides - [ ] Step 11: Efficiency Analysis  - **Metrics**: Parallel efficiency calculation - **Learnings**: Process improvements - **Recommendations**: Future optimizations ## Conflict Management Strategy ### Wave Assignment Rules ```yaml wave_1: criteria: No file conflicts, independent components risk: Low duration: 2-3 days wave_2: criteria: Minor overlaps, manageable conflicts risk: Medium duration: 2-3 days dependencies: wave_1 completion wave_3: criteria: Core system changes, high conflict potential risk: High duration: 3-4 days dependencies: wave_1 and wave_2 merged ``` ```` ### Conflict Detection - Automated file conflict analysis before wave start - Real-time monitoring during development - Early warning system for emerging conflicts - Escalation procedures defined ## Parallel Execution Metrics ### Efficiency Tracking - [ ] Parallel Efficiency = (Parallel Time / Sequential Time) × 100% - [ ] Conflict Rate = Conflicts / Total Merges - [ ] Resource Utilization = Active Developers / Total Developers - [ ] Integration Success Rate = Successful Merges / Total Merges ### Target Metrics - Parallel Efficiency > 70% - Conflict Rate < 15% - Resource Utilization > 85% - Integration Success Rate > 95% ## Communication Plan ### Sync Points - Daily: 15-min parallel standup - On-demand: Conflict resolution sessions - Weekly: Integration planning - Post-wave: Retrospective ### Async Coordination - Progress dashboard updates - Automated status notifications - Conflict alerts via Slack/Teams - Merge readiness indicators ## Risk Mitigation ### Technical Risks - Merge conflicts → Wave-based isolation - Integration failures → Incremental integration - Performance regression → Parallel testing - Resource contention → Load balancing ### Process Risks - Communication gaps → Over-communicate - Coordination overhead → Automation - Quality degradation → Continuous testing - Timeline slippage → Buffer planning ## Decision Points 1. **Wave Assignment**  - Conflict-based grouping - Skills-based assignment - Priority-based ordering - Risk-based sequencing 2. **Integration Timing**  - Continuous integration - Wave-based integration - Big-bang integration - Feature-flag isolation 3. **Conflict Resolution**  - Developer pairs - Technical lead resolution - Architect arbitration - Team consensus ## Success Criteria - [ ] All work items completed - [ ] Integration successful - [ ] Quality standards met - [ ] Timeline achieved - [ ] Team satisfaction high - [ ] Process improvements identified ## Next Steps 1. Review conflict analysis with team 2. Confirm wave assignments 3. Set up worktree environments 4. Begin with: `/parallel-dev "{{work-description}}" {{worktree-name}}` --- _Parallel Development Active: Monitor progress dashboard for real-time updates_ ```` ### 4. Parallel Workflow Variations **For Small Teams** (2-3 developers): - Simplified wave management - Direct communication - Lightweight tracking **For Large Teams** (5+ developers): - Multiple wave coordination - Automated progress tracking - Formal sync procedures - Dedicated coordination role **For Complex Systems**: - Component-based waves - Architectural oversight - Extended integration phases - Risk-based sequencing ### 5. Provide Parallel-Specific Guidance ```text Your Parallel Development workflow plan is ready! Key Success Factors: - 🌊 Wave-based execution minimizes conflicts - 🔄 Continuous integration reduces risk - 📊 Real-time monitoring enables quick decisions - 🤝 Clear communication prevents confusion Before starting: 1. Ensure git worktree support: `git --version` 2. Clean working directory: `git status` 3. Brief team on parallel approach 4. Set up progress tracking Ready to parallelize? ```` ## Success Criteria The parallel workflow plan succeeds when: 1. Conflict analysis completed 2. Wave assignments clear 3. Communication plan defined 4. Metrics tracking ready 5. Risk mitigation addressed 6. Team aligned on approach ## Integration with Parallel Dev Command The parallel-dev command should: 1. Check for workflow plans before execution 2. Use wave assignments from plan 3. Update progress in real-time 4. Alert on plan deviations 5. Track efficiency metrics