Documentation Updates
This commit is contained in:
DevForgeAI
parent
fb02de7d2e
commit
1514e02f05
320
README.md
320
README.md
|
|
@ -1,8 +1,11 @@
|
|||
# The BMAD-Method 3.1 (Breakthrough Method of Agile (ai-driven) Development)
|
||||
# The BMAD-Method 4.0 (Breakthrough Method of Agile (ai-driven) Development)
|
||||
|
||||
Old Versions:
|
||||
[Prior Version 1](https://github.com/bmadcode/BMAD-METHOD/tree/V1)
|
||||
[Prior Version 2](https://github.com/bmadcode/BMAD-METHOD/tree/V2)
|
||||
Previous Versions:
|
||||
[Prior Version 1](https://github.com/bmadcode/BMAD-METHOD/tree/V1) | [Prior Version 2](https://github.com/bmadcode/BMAD-METHOD/tree/V2) | [Prior Version 3.1](https://github.com/bmadcode/BMAD-METHOD/tree/V3.1)
|
||||
|
||||
## 🚀 Major Update: Complete Documentation Enhancement Project
|
||||
|
||||
**BMAD Method 4.0** represents a massive expansion with **100+ documents**, **500+ pages**, and **comprehensive persona documentation packages**. This release includes complete documentation ecosystems for all personas, integration guides, quality frameworks, and success metrics.
|
||||
|
||||
## Do This First, and all will make sense
|
||||
|
||||
|
|
@ -12,97 +15,274 @@ There are lots of docs here, but I HIGHLY suggest you just try the Web Agent - i
|
|||
|
||||
Orchestrator Uber BMad Agent that does it all - already pre-compiled in the `web-build-sample` folder.
|
||||
|
||||
- The contents of [Agent Prompt Sample](web-build-sample/agent-prompt.txt) text get pasted into the Gemini Gem, or ChatPGT customGPT 'Instructions' field.
|
||||
- The contents of [Agent Prompt Sample](web-build-sample/agent-prompt.txt) text get pasted into the Gemini Gem, or ChatPGT customGPT customGPT 'Instructions' field.
|
||||
- The remaining files in that same folder folder just need to be attached as shown in the screenshot below. Give it a name (such as BMad Agent) and save it, and you now have the BMad Agent available to help you brainstorm, research, plan, execute on your vision, or understand how this all even works!
|
||||
- Once its running, start with typing `/help`, and then type option `2` when it presents 3 options to learn about the method!
|
||||
|
||||
|
||||
|
||||
### New: v0 UX/UI Architect Integration
|
||||
## How It Works: The BMAD Method Explained
|
||||
|
||||
The BMAD Method now includes a specialized **v0 UX/UI Architect** persona designed to work seamlessly with modern AI-powered design and development tools. This persona brings the power of rapid visual design generation and component implementation directly into your workflow.
|
||||
The BMAD Method uses a powerful **Orchestrator** system that coordinates specialized AI personas to handle different aspects of your project:
|
||||
|
||||
#### Key Features:
|
||||
- **Dual Environment Support**: Works in both web-based AI environments (ChatGPT, Gemini) and IDE environments (Cursor AI, Cline, Claude Code, Roocode)
|
||||
- **Rapid Prototyping**: Transform simple prompts into fully-realized, visually stunning frontend implementations
|
||||
- **Component-Based Thinking**: Naturally creates reusable components and design systems
|
||||
- **Code-Design Synthesis**: Seamlessly moves between visual design concepts and production-ready code
|
||||
- **Quality Assurance**: Includes comprehensive checklists and templates for consistent, high-quality output
|
||||
### Core Mechanics:
|
||||
|
||||
#### What's New in This Version:
|
||||
- **🎨 v0 UX/UI Architect Personas**: Veronica (Web) and Victor (IDE) for rapid design-to-code workflows
|
||||
- **🔧 IDE-Specific Configurations**: Optimized setups for Cursor AI, Cline, Claude Code, and Roocode
|
||||
- **📚 Comprehensive Training Materials**: Step-by-step guides for each environment
|
||||
- **🚀 Rapid Prototyping Tasks**: Transform concepts to production-ready components in minutes
|
||||
- **✅ Quality Assurance Framework**: Built-in checklists and templates for consistent output
|
||||
- **🔄 Seamless Integration**: Works with existing BMAD personas and workflows
|
||||
1. **Orchestrator**: The central "brain" that manages all personas and tasks
|
||||
2. **Personas**: Specialized AI experts (PM, Architect, UX/UI Designer, etc.)
|
||||
3. **Tasks**: Specific workflows each persona can execute
|
||||
4. **Templates**: Standardized documents personas use to create deliverables
|
||||
|
||||
### Workflow:
|
||||
|
||||
```
|
||||
User Request → Orchestrator → Appropriate Persona → Task Execution → Deliverable
|
||||
```
|
||||
|
||||
### Environments:
|
||||
|
||||
- **Web-based**: Run in ChatGPT or Gemini with attached knowledge files
|
||||
- **IDE-based**: Run directly in your code editor with full project context
|
||||
|
||||
### Key Commands:
|
||||
|
||||
- `/persona [name]` - Activate a specific persona (Web)
|
||||
- `/task [name]` - Execute a specific task (Web)
|
||||
- `*persona [name]` - Activate a specific persona (IDE)
|
||||
- `*task [name]` - Execute a specific task (IDE)
|
||||
|
||||
[Learn more about BMAD orchestration](docs/readme.md) | [Detailed mechanics](docs/workflow-diagram.md) | [Command reference](docs/instruction.md)
|
||||
|
||||
## 📚 Complete Documentation Ecosystem (NEW in 4.0)
|
||||
|
||||
BMAD Method 4.0 includes the most comprehensive AI-driven development documentation available, with **complete persona packages**, **integration guides**, and **quality frameworks**.
|
||||
|
||||
### 🎯 Complete Persona Documentation Packages
|
||||
|
||||
Each persona now has a **complete documentation package** including comprehensive guides, templates, quality standards, workflows, and success metrics:
|
||||
|
||||
#### Business Analysis & Product Management
|
||||
- **[Business Analyst Complete Package](docs/analyst-comprehensive-guide.md)** - Full BA documentation suite
|
||||
- [Integration Guide](docs/analyst-integration-guide.md) | [Quickstart](docs/analyst-quickstart.md)
|
||||
- [Templates](docs/analyst-template-guide.md) | [Quality Standards](docs/analyst-quality-standards.md)
|
||||
- [Workflows](docs/analyst-workflow-mapping.md) | [Success Metrics](docs/analyst-success-metrics.md)
|
||||
|
||||
- **[Product Manager Complete Package](docs/pm-comprehensive-guide.md)** - Full PM documentation suite
|
||||
- [Integration Guide](docs/pm-integration-guide.md) | [Quickstart](docs/pm-quickstart.md)
|
||||
- [Templates](docs/pm-template-guide.md) | [Quality Standards](docs/pm-quality-standards.md)
|
||||
- [Workflows](docs/pm-workflow-mapping.md) | [Success Metrics](docs/pm-success-metrics.md)
|
||||
|
||||
- **[Product Owner Complete Package](docs/po-comprehensive-guide.md)** - Full PO documentation suite
|
||||
- [Integration Guide](docs/po-integration-guide.md) | [Quickstart](docs/po-quickstart.md)
|
||||
- [Templates](docs/po-template-guide.md) | [Quality Standards](docs/po-quality-standards.md)
|
||||
- [Workflows](docs/po-workflow-mapping.md) | [Success Metrics](docs/po-success-metrics.md)
|
||||
|
||||
#### Architecture & Development
|
||||
- **[System Architect Complete Package](docs/architect-comprehensive-guide.md)** - Full architect documentation suite
|
||||
- [Integration Guide](docs/architect-integration-guide.md) | [Quickstart](docs/architect-quickstart.md)
|
||||
- [Templates](docs/architect-template-guide.md) | [Quality Standards](docs/architect-quality-standards.md)
|
||||
- [Task Library](docs/architect-task-library.md) | [Success Metrics](docs/architect-success-metrics.md)
|
||||
|
||||
- **[Developer Complete Package](docs/dev-comprehensive-guide.md)** - Full developer documentation suite
|
||||
- [Integration Guide](docs/dev-integration-guide.md) | [Quickstart](docs/dev-quickstart.md)
|
||||
- [Templates](docs/dev-template-guide.md) | [Quality Standards](docs/dev-quality-standards.md)
|
||||
- [Workflows](docs/dev-workflow-mapping.md) | [Success Metrics](docs/dev-success-metrics.md)
|
||||
|
||||
#### Design & User Experience
|
||||
- **[Design Architect Complete Package](docs/design-architect-comprehensive-guide.md)** - Full design documentation suite
|
||||
- [Integration Guide](docs/design-architect-integration-guide.md) | [Quickstart](docs/design-architect-quickstart.md)
|
||||
- [Templates](docs/design-architect-template-guide.md) | [Quality Standards](docs/design-architect-quality-standards.md)
|
||||
- [Workflows](docs/design-architect-workflow-mapping.md) | [Success Metrics](docs/design-architect-success-metrics.md)
|
||||
|
||||
- **[v0 UX/UI Architect Complete Package](docs/v0-ux-ui-architect-comprehensive-guide.md)** - Revolutionary design-to-code workflow
|
||||
- [Integration Guide](docs/v0-ux-ui-architect-integration-guide.md) | [Quickstart](docs/v0-ux-ui-architect-quickstart.md)
|
||||
- [User Guide](docs/v0-ux-ui-architect-user-guide.md) | [Quality Assurance](docs/v0-ux-ui-architect-quality-assurance.md)
|
||||
|
||||
#### Agile & Process Management
|
||||
- **[Scrum Master Complete Package](docs/sm-comprehensive-guide.md)** - Full Scrum Master documentation suite
|
||||
- [Templates](docs/sm-template-guide.md) | [Quality Standards](docs/sm-quality-standards.md)
|
||||
- [Workflows](docs/sm-workflow-mapping.md) | [Success Metrics](docs/sm-success-metrics.md)
|
||||
|
||||
### 🔗 Integration & Architecture Documentation
|
||||
|
||||
- **[Comprehensive Integration Guide](docs/bmad-comprehensive-integration-guide.md)** - How all personas work together
|
||||
- **[Documentation Map](docs/bmad-documentation-map.md)** - Navigate the complete documentation ecosystem
|
||||
- **[System Architecture](docs/system-architecture/README.md)** - Complete system design and integration
|
||||
- **[Integration Architecture](docs/system-architecture/integration-architecture.md)** - External system connections
|
||||
|
||||
### 🧠How It Works Documentation
|
||||
- **[Complete Guide](docs/how-it-works/README.md)** - Comprehensive workflow understanding
|
||||
- **[Core Concepts](docs/how-it-works/core-concepts.md)** - Fundamental BMAD principles
|
||||
- **[Orchestrator Mechanics](docs/how-it-works/orchestrator-mechanics.md)** - Technical coordination details
|
||||
- **[Persona Workflows](docs/how-it-works/persona-workflows.md)** - Individual persona processes
|
||||
- **[Integration Points](docs/how-it-works/integration-points.md)** - System integration patterns
|
||||
- **[Troubleshooting Guide](docs/how-it-works/troubleshooting.md)** - Common issues and solutions
|
||||
|
||||
### ðŸ—ºï¸ User Journey Maps
|
||||
- **[Journey Overview](docs/user-journeys/README.md)** - Complete user experience documentation
|
||||
- **[First-Time Setup](docs/user-journeys/first-time-setup.md)** - New user onboarding
|
||||
- **[Project Initiation](docs/user-journeys/project-initiation.md)** - Starting new projects
|
||||
- **[Feature Development](docs/user-journeys/feature-development.md)** - Development workflows
|
||||
- **[Design System Creation](docs/user-journeys/design-system-creation.md)** - UX/UI processes
|
||||
- **[Architecture Planning](docs/user-journeys/architecture-planning.md)** - Technical planning
|
||||
|
||||
### 🎨 Visual Design System
|
||||
- **[Visual Standards](docs/visual-elements/README.md)** - Design guidelines and standards
|
||||
- **[Interactive Components](docs/visual-elements/interactive-examples.md)** - Reusable UI elements
|
||||
- **[Accessibility Guide](docs/visual-elements/accessibility-guide.md)** - WCAG AA compliance
|
||||
|
||||
### 📋 Documentation Standards & Quality
|
||||
- **[Documentation Standards](docs/documentation-standards/README.md)** - Quality framework for all documentation
|
||||
- **[Style Guide](docs/documentation-standards/style-guide.md)** - Consistent documentation formatting
|
||||
- **[Review Process](docs/documentation-standards/review-process.md)** - Quality assurance procedures
|
||||
- **[Contribution Guidelines](docs/documentation-standards/contribution-guidelines.md)** - How to contribute
|
||||
|
||||
## 🚀 Quick Start Guides
|
||||
|
||||
### For Different Roles:
|
||||
- **[BMAD Method Quickstart](docs/quick-start-guides/bmad-method-quickstart.md)** - General overview and getting started
|
||||
- **[Web Environment Quickstart](docs/quick-start-guides/web-environment-quickstart.md)** - ChatGPT/Gemini setup
|
||||
- **[IDE Environment Quickstart](docs/quick-start-guides/ide-environment-quickstart.md)** - Development environment setup
|
||||
|
||||
### For Specific Personas:
|
||||
- **[Business Analyst Quickstart](docs/analyst-quickstart.md)** - BA-specific getting started
|
||||
- **[Product Manager Quickstart](docs/pm-quickstart.md)** - PM-specific getting started
|
||||
- **[System Architect Quickstart](docs/architect-quickstart.md)** - Architect-specific getting started
|
||||
- **[Product Owner Quickstart](docs/po-quickstart.md)** - PO-specific getting started
|
||||
- **[Developer Quickstart](docs/dev-quickstart.md)** - Developer-specific getting started
|
||||
- **[Design Architect Quickstart](docs/design-architect-quickstart.md)** - Design-specific getting started
|
||||
- **[v0 UX/UI Architect Quickstart](docs/v0-ux-ui-architect-quickstart.md)** - UX/UI-specific getting started
|
||||
|
||||
## 🔧 IDE Integration & Setup
|
||||
|
||||
The BMAD Method supports multiple AI-powered development environments with specialized configurations:
|
||||
|
||||
#### IDE-Specific Setup & Training:
|
||||
| IDE Environment | Setup Guide | Training Material | Best For |
|
||||
|----------------|-------------|-------------------|----------|
|
||||
| **Cursor AI** | [Setup Guide](docs/ide-setup-guides/cursor-ai-setup.md) | [Training Guide](docs/training/ide-specific-guides/cursor-ai-guide.md) | Advanced codebase integration |
|
||||
| **Cline (Claude Dev)** | [Setup Guide](docs/ide-setup-guides/cline-setup.md) | [Training Guide](docs/training/ide-specific-guides/cline-guide.md) | Project context awareness |
|
||||
| **Claude Code** | [Setup Guide](docs/ide-setup-guides/claude-code-setup.md) | [Training Guide](docs/training/ide-specific-guides/claude-code-guide.md) | Code quality standards |
|
||||
| **Roocode** | [Setup Guide](docs/ide-setup-guides/roocode-setup.md) | [Training Guide](docs/training/ide-specific-guides/roocode-guide.md) | Rapid prototyping |
|
||||
| **VS Code** | [Setup Guide](docs/ide-setup-guides/vscode-setup.md) | - | Traditional development |
|
||||
| **JetBrains** | [Setup Guide](docs/ide-setup-guides/jetbrains-setup.md) | - | Enterprise development |
|
||||
|
||||
#### Complete Documentation:
|
||||
- **📖 [v0 UX/UI Architect User Guide](docs/v0-ux-ui-architect-user-guide.md)** - Comprehensive usage documentation
|
||||
- **🔗 [Integration Guide](docs/integration-guide/v0-ux-ui-architect-integration.md)** - How it fits with existing BMAD workflows
|
||||
- **💡 [Example Project](examples/v0-ux-ui-architect-example.md)** - Complete workflow demonstration
|
||||
- **🎯 [Training Materials](docs/training/using-v0-ux-ui-architect.md)** - Master the new personas
|
||||
### Complete IDE Documentation:
|
||||
- **[IDE Setup Overview](docs/ide-setup-guides/README.md)** - Choose the right IDE for your needs
|
||||
- **[IDE Setup Guide](docs/ide-setup.md)** - General IDE configuration
|
||||
- **[Recommended IDE Plugins](docs/recommended-ide-plugins.md)** - Essential plugins and extensions
|
||||
|
||||
#### Available Personas:
|
||||
- **Veronica (Web-based)**: Perfect for design planning, specification creation, and visual concept generation
|
||||
- **Victor (IDE-based)**: Optimized for direct implementation in development environments with real-time code generation
|
||||
## 📊 Project Statistics (Version 4.0)
|
||||
|
||||
#### Quick Start with v0 UX/UI Architect:
|
||||
- **100+ Total Documents** - Comprehensive coverage of all aspects
|
||||
- **500+ Total Pages** - In-depth documentation and guidance
|
||||
- **50+ Diagrams & Visualizations** - Clear process flows and architectures
|
||||
- **20+ Templates** - Ready-to-use templates for all personas
|
||||
- **15+ Examples** - Real-world implementation examples
|
||||
- **8 Complete Persona Packages** - Full documentation suites
|
||||
- **6 IDE Environments Supported** - Flexible development options
|
||||
|
||||
1. **Web Environment**: Activate Veronica through the BMad Agent with `/persona veronica` or `/task rapid-prototype-from-brief`
|
||||
2. **IDE Environment**: Use Victor in your preferred IDE (see setup guides in `docs/ide-setup-guides/`)
|
||||
3. **Follow the Example**: Check out `examples/v0-ux-ui-architect-example.md` for a complete workflow demonstration
|
||||
4. **Training Materials**: Comprehensive guides available in `docs/training/using-v0-ux-ui-architect.md`
|
||||
## 🎯 Available Personas & Capabilities
|
||||
|
||||
#### Supported IDE Environments:
|
||||
- **Cursor AI**: Advanced file system integration with codebase understanding
|
||||
- **Cline (Claude Dev)**: Strong project context awareness with terminal integration
|
||||
- **Claude Code**: Focus on code quality standards and best practices
|
||||
- **Roocode**: Rapid prototyping with component library integration
|
||||
### Core Business Personas:
|
||||
- **Business Analyst (BA)** - Requirements analysis, stakeholder management, process optimization
|
||||
- **Product Manager (PM)** - Product strategy, roadmap planning, feature prioritization
|
||||
- **Product Owner (PO)** - Backlog management, user story creation, acceptance criteria
|
||||
|
||||
This enhancement makes the BMAD Method incredibly versatile for frontend development - from initial concept generation to final implementation across multiple AI-powered development environments!
|
||||
### Technical Personas:
|
||||
- **System Architect** - Technical architecture, system design, technology decisions
|
||||
- **Developer** - Code implementation, technical solutions, development best practices
|
||||
- **Design Architect** - Design systems, visual architecture, design standards
|
||||
|
||||
### Specialized Personas:
|
||||
- **v0 UX/UI Architect (Veronica/Victor)** - AI-powered design-to-code workflows
|
||||
- **Scrum Master** - Agile facilitation, process improvement, team coaching
|
||||
|
||||
### Process Personas:
|
||||
- **DevOps/Platform Engineer** - Infrastructure, deployment, operational excellence
|
||||
- **Quality Assurance** - Testing strategies, quality frameworks, validation processes
|
||||
|
||||
## 🔄 Integration & Workflow
|
||||
|
||||
The BMAD Method provides seamless integration between all personas through:
|
||||
|
||||
- **Cross-Persona Workflows** - Standardized handoff procedures
|
||||
- **Integration Architecture** - Technical integration patterns
|
||||
- **Communication Protocols** - Structured information exchange
|
||||
- **Quality Gates** - Consistent quality assurance across all deliverables
|
||||
- **Shared Templates** - Common document formats and structures
|
||||
|
||||
## 📈 Success Metrics & Quality Framework
|
||||
|
||||
Every persona includes comprehensive success metrics and quality standards:
|
||||
|
||||
- **Performance Metrics** - Quantitative success measurements
|
||||
- **Quality Standards** - Consistent output quality across all personas
|
||||
- **Process Metrics** - Workflow efficiency and effectiveness
|
||||
- **Outcome Metrics** - Business value and impact measurement
|
||||
- **Continuous Improvement** - Feedback loops and optimization processes
|
||||
|
||||
## 🚀 What's New - Version 4.0 Major Release
|
||||
|
||||
### 🎉 Documentation Enhancement Project Completed:
|
||||
- **Complete Persona Documentation Packages** - Every persona now has comprehensive documentation
|
||||
- **Integration Architecture** - Detailed integration guides showing how all personas work together
|
||||
- **Quality Framework** - Comprehensive quality standards and success metrics for all personas
|
||||
- **Template Library** - Extensive collection of templates for all processes and personas
|
||||
- **Training Materials** - Complete training guides for all environments and personas
|
||||
|
||||
### 🔧 Enhanced Capabilities:
|
||||
- **Cross-Persona Workflows** - Seamless collaboration between all personas
|
||||
- **Quality Assurance Framework** - Built-in quality validation and improvement processes
|
||||
- **Success Metrics System** - Comprehensive measurement and optimization framework
|
||||
- **Documentation Standards** - Consistent quality and formatting across all documentation
|
||||
|
||||
### 📚 New Documentation Categories:
|
||||
- **Comprehensive Guides** - In-depth documentation for each persona
|
||||
- **Integration Guides** - How personas work together in real projects
|
||||
- **Template Guides** - Complete template libraries with usage instructions
|
||||
- **Quality Standards** - Quality frameworks and validation procedures
|
||||
- **Workflow Mapping** - Detailed process flows and decision trees
|
||||
- **Success Metrics** - Measurement frameworks and optimization strategies
|
||||
|
||||
### 🎯 Enhanced User Experience:
|
||||
- **Documentation Map** - Easy navigation through the complete documentation ecosystem
|
||||
- **Role-Based Quickstarts** - Tailored getting-started guides for each persona
|
||||
- **Integration Examples** - Real-world examples of cross-persona collaboration
|
||||
- **Quality Checklists** - Validation tools for consistent output quality
|
||||
|
||||
### 📊 Project Deliverables:
|
||||
- **28 New Documentation Files** - Comprehensive coverage of all personas
|
||||
- **8 Complete Persona Packages** - Full documentation suites for each role
|
||||
- **4 Integration Guides** - Cross-persona collaboration documentation
|
||||
- **Multiple Quality Frameworks** - Standards and metrics for all processes
|
||||
|
||||
**Previous Versions**: [V1](https://github.com/bmadcode/BMAD-METHOD/tree/V1) | [V2](https://github.com/bmadcode/BMAD-METHOD/tree/V2) | [V3.1](https://github.com/bmadcode/BMAD-METHOD/tree/V3.1)
|
||||
|
||||
## 📋 Navigation & Getting Started
|
||||
|
||||
### New Users:
|
||||
1. **Start Here**: [BMAD Method Quickstart](docs/quick-start-guides/bmad-method-quickstart.md)
|
||||
2. **Choose Environment**: [Web](docs/quick-start-guides/web-environment-quickstart.md) or [IDE](docs/quick-start-guides/ide-environment-quickstart.md)
|
||||
3. **Select Your Role**: Use the persona-specific quickstart guides above
|
||||
4. **Explore Integration**: [Comprehensive Integration Guide](docs/bmad-comprehensive-integration-guide.md)
|
||||
|
||||
### Existing Users:
|
||||
1. **What's New**: [Release Notes](docs/bmad-release-notes.md)
|
||||
2. **Documentation Map**: [Complete Documentation Overview](docs/bmad-documentation-map.md)
|
||||
3. **Integration Updates**: [Integration Architecture](docs/system-architecture/integration-architecture.md)
|
||||
4. **Quality Standards**: [Documentation Standards](docs/documentation-standards/README.md)
|
||||
|
||||
### Project Teams:
|
||||
1. **Project Summary**: [Complete Project Overview](docs/bmad-project-summary.md)
|
||||
2. **Team Setup**: Choose appropriate persona packages for your team members
|
||||
3. **Workflow Integration**: [Cross-Persona Workflows](docs/bmad-comprehensive-integration-guide.md)
|
||||
4. **Quality Assurance**: Use the quality standards and success metrics for each persona
|
||||
|
||||
[More Documentation, Explanations, and IDE Specifics](docs/readme.md) available here!
|
||||
|
||||
## End Matter
|
||||
|
||||
## 🚀 What's New - Version 3.1 Enhancements
|
||||
|
||||
### Major Features Added:
|
||||
- **v0 UX/UI Architect Integration**: Revolutionary design-to-code workflow with dual personas
|
||||
- **Multi-IDE Support**: Native configurations for 4 major AI-powered IDEs
|
||||
- **Enhanced Training System**: Comprehensive guides for each environment
|
||||
- **Quality Framework**: Built-in checklists and templates for consistent output
|
||||
|
||||
### New Documentation:
|
||||
- IDE-specific setup guides for Cursor AI, Cline, Claude Code, and Roocode
|
||||
- Comprehensive training materials for v0 UX/UI Architect personas
|
||||
- Integration guides showing how new personas work with existing BMAD workflow
|
||||
- Example projects demonstrating complete design-to-implementation workflows
|
||||
|
||||
### Enhanced Capabilities:
|
||||
- **Rapid Prototyping**: Transform simple prompts into production-ready components
|
||||
- **Component-Based Design**: Automatic creation of reusable design systems
|
||||
- **Cross-Environment Compatibility**: Seamless workflow between web and IDE environments
|
||||
- **Quality Assurance**: Built-in validation and best practices enforcement
|
||||
|
||||
### Files Added/Enhanced:
|
||||
- `bmad-agent/personas/v0-ux-ui-architect.md` & `.ide.md` - Core persona definitions
|
||||
- `docs/ide-setup-guides/` - Complete IDE configuration documentation
|
||||
- `docs/training/` - Comprehensive training materials
|
||||
- `examples/v0-ux-ui-architect-example.md` - Real-world usage examples
|
||||
- Enhanced orchestrator configurations with v0 integration
|
||||
|
||||
**Previous Versions**: [V1](https://github.com/bmadcode/BMAD-METHOD/tree/V1) | [V2](https://github.com/bmadcode/BMAD-METHOD/tree/V2)
|
||||
|
||||
Thank you and enjoy - BMad!
|
||||
[License](docs/LICENSE)
|
||||
|
||||
**[License](docs/LICENSE)** | **[Contributing Guidelines](docs/CONTRIBUTING.md)** | **[Support](https://vercel.com/help)**
|
||||
|
||||
Interested in improving the BMAD Method? See the [contributing guidelines](docs/CONTRIBUTING.md).
|
||||
|
|
|
|||
|
|
@ -0,0 +1,296 @@
|
|||
# Business Analyst (Analyst) - Comprehensive Guide
|
||||
|
||||
## Overview
|
||||
|
||||
The **Business Analyst (Analyst)** persona in the BMAD Method serves as your **Insightful Analyst & Strategic Ideation Partner**. This persona excels at uncovering insights through research and analysis, structuring effective research directives, fostering innovative thinking during brainstorming, and translating findings into clear, actionable project briefs.
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
### 🧠Research & Analysis (95% Confidence)
|
||||
- **Market Research & Competitive Analysis** - Industry trend analysis, competitor capability assessment, market sizing and segmentation
|
||||
- **User Research & Behavioral Analysis** - User journey mapping, persona development, needs assessment, pain point identification
|
||||
- **Data Analysis & Interpretation** - Statistical analysis, pattern recognition, insight synthesis, hypothesis validation
|
||||
- **Strategic Research Planning** - Research methodology design, question formulation, source identification, scope definition
|
||||
|
||||
### 💡 Brainstorming & Ideation (90% Confidence)
|
||||
- **Creative Facilitation** - Structured brainstorming sessions, divergent thinking techniques, idea generation workshops
|
||||
- **Problem Framing & Reframing** - Root cause analysis, assumption challenging, perspective shifting, first principles thinking
|
||||
- **Concept Development** - Idea refinement, feasibility assessment, concept validation, opportunity prioritization
|
||||
- **Innovation Techniques** - SCAMPER methodology, analogical thinking, scenario planning, design thinking facilitation
|
||||
|
||||
### 📋 Documentation & Communication (95% Confidence)
|
||||
- **Research Documentation** - Comprehensive research reports, executive summaries, findings synthesis, recommendation development
|
||||
- **Project Brief Creation** - Structured project documentation, requirement specification, scope definition, stakeholder alignment
|
||||
- **Stakeholder Communication** - Clear presentation of complex information, collaborative dialogue facilitation, consensus building
|
||||
- **Process Documentation** - Research methodologies, analysis frameworks, decision rationales, lessons learned
|
||||
|
||||
### 🎯 Strategic Planning (85% Confidence)
|
||||
- **Opportunity Assessment** - Market opportunity evaluation, risk-benefit analysis, strategic option development
|
||||
- **Requirements Elicitation** - Stakeholder needs assessment, functional requirement definition, constraint identification
|
||||
- **Solution Evaluation** - Alternative assessment, criteria development, recommendation formulation, impact analysis
|
||||
- **Change Management** - Stakeholder impact assessment, communication planning, adoption strategy development
|
||||
|
||||
## Working Process
|
||||
|
||||
### Phase 1: Context Understanding & Mode Selection
|
||||
1. **Initial Assessment**
|
||||
- Understand user's current situation and goals
|
||||
- Identify the type of analysis or support needed
|
||||
- Determine appropriate working mode (Brainstorming, Research, or Briefing)
|
||||
|
||||
2. **Mode Selection Guidance**
|
||||
- **Brainstorming Phase**: For creative ideation and concept exploration
|
||||
- **Deep Research Prompt Generation**: For structured research planning
|
||||
- **Project Briefing Phase**: For formal project documentation
|
||||
|
||||
### Phase 2: Execution (Mode-Dependent)
|
||||
|
||||
#### Brainstorming Mode
|
||||
1. **Open-Ended Exploration**
|
||||
- Use "What if..." scenarios and analogical thinking
|
||||
- Apply SCAMPER and first principles techniques
|
||||
- Encourage divergent thinking before convergent analysis
|
||||
|
||||
2. **Structured Ideation**
|
||||
- Guide through proven brainstorming frameworks
|
||||
- Challenge limiting assumptions
|
||||
- Organize ideas using structured formats
|
||||
|
||||
3. **Insight Synthesis**
|
||||
- Compile key insights and breakthrough concepts
|
||||
- Prepare transition to research or briefing phases
|
||||
|
||||
#### Research Prompt Generation Mode
|
||||
1. **Research Objective Definition**
|
||||
- Clarify primary research goals and decision points
|
||||
- Identify existing knowledge and assumptions to test
|
||||
- Define desired depth and breadth of investigation
|
||||
|
||||
2. **Research Structure Development**
|
||||
- Break down objectives into logical themes
|
||||
- Formulate specific, actionable research questions
|
||||
- Define target information sources and evaluation criteria
|
||||
|
||||
3. **Prompt Creation & Refinement**
|
||||
- Draft comprehensive research prompt
|
||||
- Review and refine based on user feedback
|
||||
- Deliver ready-to-use research directive
|
||||
|
||||
#### Project Briefing Mode
|
||||
1. **Brief Structure Planning**
|
||||
- Use established project brief template
|
||||
- Guide through each section systematically
|
||||
- Incorporate available research findings
|
||||
|
||||
2. **Collaborative Development**
|
||||
- Ask targeted clarifying questions
|
||||
- Help distinguish MVP features from future enhancements
|
||||
- Ensure alignment with business goals
|
||||
|
||||
3. **Documentation Finalization**
|
||||
- Structure complete project brief
|
||||
- Validate completeness and clarity
|
||||
- Prepare for handoff to development team
|
||||
|
||||
### Phase 3: Quality Assurance & Handoff
|
||||
1. **Deliverable Review**
|
||||
- Ensure all requirements are met
|
||||
- Validate against established templates and standards
|
||||
- Confirm actionability of outputs
|
||||
|
||||
2. **Stakeholder Alignment**
|
||||
- Present findings and recommendations clearly
|
||||
- Facilitate discussion and feedback incorporation
|
||||
- Achieve consensus on next steps
|
||||
|
||||
3. **Transition Planning**
|
||||
- Prepare handoff documentation
|
||||
- Identify follow-up actions and responsibilities
|
||||
- Establish success metrics and review points
|
||||
|
||||
## Integration with BMAD Method
|
||||
|
||||
### Upstream Integrations
|
||||
- **Receives from**: Initial user requirements, business objectives, market context
|
||||
- **Collaborates with**: Product Managers for market validation, UX/UI Architects for user research insights
|
||||
|
||||
### Downstream Handoffs
|
||||
- **Delivers to**:
|
||||
- Product Managers: Market research, competitive analysis, user insights
|
||||
- System Architects: Technical feasibility research, solution evaluation
|
||||
- Product Owners: Detailed project briefs, requirement specifications
|
||||
- Development Teams: Clear project scope and success criteria
|
||||
|
||||
### Cross-Functional Collaboration
|
||||
- **With Product Managers**: Validate market assumptions, refine product strategy
|
||||
- **With UX/UI Teams**: Share user research insights, validate design assumptions
|
||||
- **With Technical Teams**: Assess solution feasibility, understand technical constraints
|
||||
- **With Stakeholders**: Facilitate requirements gathering, present research findings
|
||||
|
||||
## Advanced Usage Patterns
|
||||
|
||||
### Complex Research Projects
|
||||
1. **Discovery Phase**: Broad market and user research
|
||||
2. **Deep Dive Phase**: Focused investigation of key areas
|
||||
3. **Validation Phase**: Hypothesis testing and assumption validation
|
||||
4. **Synthesis Phase**: Insight integration and recommendation development
|
||||
|
||||
### Strategic Planning Support
|
||||
1. **Current State Analysis**: Existing capabilities and market position
|
||||
2. **Future State Visioning**: Desired outcomes and success metrics
|
||||
3. **Gap Analysis**: Identification of capability and resource gaps
|
||||
4. **Roadmap Development**: Prioritized action plan with milestones
|
||||
|
||||
### Innovation Facilitation
|
||||
1. **Problem Definition**: Clear articulation of challenge or opportunity
|
||||
2. **Ideation Sessions**: Multiple rounds of creative thinking
|
||||
3. **Concept Development**: Refinement of promising ideas
|
||||
4. **Feasibility Assessment**: Evaluation of implementation requirements
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### Market Entry Analysis
|
||||
- Competitive landscape assessment
|
||||
- Market sizing and segmentation
|
||||
- Entry strategy development
|
||||
- Risk and opportunity evaluation
|
||||
|
||||
### Product Development Research
|
||||
- User needs assessment
|
||||
- Feature prioritization research
|
||||
- Technical feasibility analysis
|
||||
- Go-to-market strategy development
|
||||
|
||||
### Process Improvement Projects
|
||||
- Current state analysis
|
||||
- Best practice research
|
||||
- Solution option evaluation
|
||||
- Implementation planning
|
||||
|
||||
### Strategic Planning Support
|
||||
- Market trend analysis
|
||||
- Competitive intelligence
|
||||
- Strategic option development
|
||||
- Decision support documentation
|
||||
|
||||
## Troubleshooting Guide
|
||||
|
||||
### Common Challenges
|
||||
|
||||
**Challenge**: Unclear or overly broad research objectives
|
||||
**Solution**: Use structured questioning to narrow focus and define specific, measurable outcomes
|
||||
|
||||
**Challenge**: Limited access to research sources
|
||||
**Solution**: Identify alternative information sources, proxy data, and expert interviews
|
||||
|
||||
**Challenge**: Conflicting stakeholder requirements
|
||||
**Solution**: Facilitate alignment sessions, document trade-offs, and establish decision criteria
|
||||
|
||||
**Challenge**: Analysis paralysis during brainstorming
|
||||
**Solution**: Set time limits, encourage "yes and..." thinking, defer judgment during ideation
|
||||
|
||||
### Quality Assurance Checklist
|
||||
|
||||
#### Research Quality
|
||||
- [ ] Research questions are specific and actionable
|
||||
- [ ] Information sources are credible and current
|
||||
- [ ] Analysis methodology is appropriate for the question
|
||||
- [ ] Findings are supported by evidence
|
||||
- [ ] Recommendations are practical and prioritized
|
||||
|
||||
#### Documentation Quality
|
||||
- [ ] Documents follow established templates
|
||||
- [ ] Information is clearly organized and accessible
|
||||
- [ ] Key insights are highlighted and actionable
|
||||
- [ ] Next steps are clearly defined
|
||||
- [ ] Success metrics are established
|
||||
|
||||
#### Stakeholder Alignment
|
||||
- [ ] All relevant stakeholders have been consulted
|
||||
- [ ] Requirements and constraints are documented
|
||||
- [ ] Assumptions have been validated or flagged
|
||||
- [ ] Consensus has been achieved on key decisions
|
||||
- [ ] Communication plan is established
|
||||
|
||||
## Templates and Frameworks
|
||||
|
||||
### Research Brief Template
|
||||
```markdown
|
||||
# Research Brief: [Project Name]
|
||||
|
||||
## Objective
|
||||
[Clear statement of research goals]
|
||||
|
||||
## Key Questions
|
||||
1. [Specific research question]
|
||||
2. [Specific research question]
|
||||
3. [Specific research question]
|
||||
|
||||
## Success Criteria
|
||||
[How will we know the research was successful?]
|
||||
|
||||
## Methodology
|
||||
[Approach and methods to be used]
|
||||
|
||||
## Timeline & Resources
|
||||
[Schedule and resource requirements]
|
||||
|
||||
## Deliverables
|
||||
[Expected outputs and formats]
|
||||
```
|
||||
|
||||
### Project Brief Template
|
||||
```markdown
|
||||
# Project Brief: [Project Name]
|
||||
|
||||
## Executive Summary
|
||||
[High-level overview and key points]
|
||||
|
||||
## Problem Statement
|
||||
[Clear articulation of the challenge or opportunity]
|
||||
|
||||
## Objectives
|
||||
[Specific, measurable goals]
|
||||
|
||||
## Scope
|
||||
[What's included and excluded]
|
||||
|
||||
## Success Metrics
|
||||
[How success will be measured]
|
||||
|
||||
## Timeline & Milestones
|
||||
[Key dates and deliverables]
|
||||
|
||||
## Resources & Constraints
|
||||
[Budget, team, and other limitations]
|
||||
|
||||
## Next Steps
|
||||
[Immediate actions and responsibilities]
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Research Excellence
|
||||
1. **Start with Clear Objectives**: Define what success looks like before beginning
|
||||
2. **Use Multiple Sources**: Triangulate findings from diverse information sources
|
||||
3. **Document Assumptions**: Make implicit assumptions explicit and testable
|
||||
4. **Validate Findings**: Seek confirmation through multiple methods or sources
|
||||
5. **Focus on Actionability**: Ensure insights lead to clear, implementable recommendations
|
||||
|
||||
### Facilitation Excellence
|
||||
1. **Create Safe Spaces**: Encourage open sharing and creative thinking
|
||||
2. **Manage Energy**: Balance divergent and convergent thinking phases
|
||||
3. **Document Everything**: Capture all ideas and insights for later evaluation
|
||||
4. **Stay Neutral**: Facilitate without imposing your own biases or preferences
|
||||
5. **Follow Up**: Ensure insights are translated into concrete next steps
|
||||
|
||||
### Communication Excellence
|
||||
1. **Know Your Audience**: Tailor communication style and detail level appropriately
|
||||
2. **Lead with Insights**: Start with key findings before diving into details
|
||||
3. **Use Visual Aids**: Leverage charts, diagrams, and frameworks to clarify complex information
|
||||
4. **Tell Stories**: Use narratives and examples to make abstract concepts concrete
|
||||
5. **Confirm Understanding**: Check for comprehension and address questions proactively
|
||||
|
||||
---
|
||||
|
||||
*This comprehensive guide provides the foundation for effectively leveraging the Business Analyst persona in your BMAD Method implementation. For additional support, refer to the Integration Guide and Quick Start Guide.*
|
||||
|
|
@ -0,0 +1,327 @@
|
|||
# Business Analyst (Analyst) - Integration Guide
|
||||
|
||||
## Environment Setup
|
||||
|
||||
### Web Environment (v0.dev)
|
||||
The Business Analyst persona is optimized for web-based collaboration and research activities.
|
||||
|
||||
#### Initial Setup
|
||||
1. **Access the BMAD Method workspace**
|
||||
```
|
||||
Navigate to your v0.dev workspace
|
||||
Load the BMAD Method configuration
|
||||
Select "Analyst" persona from the persona menu
|
||||
```
|
||||
|
||||
2. **Verify persona activation**
|
||||
```
|
||||
Confirm persona displays: "Business Analyst - Insightful Analyst & Strategic Ideation Partner"
|
||||
Check that core principles are loaded and active
|
||||
Validate access to brainstorming, research, and briefing modes
|
||||
```
|
||||
|
||||
3. **Configure working environment**
|
||||
```
|
||||
Set up document templates and frameworks
|
||||
Configure research source bookmarks
|
||||
Prepare collaboration tools and shared workspaces
|
||||
```
|
||||
|
||||
### IDE Environment Setup
|
||||
For teams using IDE-based workflows, the Business Analyst persona can be integrated into development environments.
|
||||
|
||||
#### Configuration Steps
|
||||
1. **Load persona configuration**
|
||||
```
|
||||
Copy bmad-agent/personas/analyst.md to your IDE agent configuration
|
||||
Ensure all core principles and operating instructions are loaded
|
||||
Verify access to task templates and frameworks
|
||||
```
|
||||
|
||||
2. **Set up working directories**
|
||||
```
|
||||
/research - For research documentation and findings
|
||||
/briefs - For project briefs and specifications
|
||||
/templates - For reusable frameworks and templates
|
||||
/collaboration - For stakeholder communication and feedback
|
||||
```
|
||||
|
||||
3. **Configure integration points**
|
||||
```
|
||||
Link to Product Manager workflows
|
||||
Connect to UX/UI research processes
|
||||
Establish handoff procedures to technical teams
|
||||
```
|
||||
|
||||
## BMAD Method Workflow Integration
|
||||
|
||||
### Phase 1: Initial Engagement
|
||||
The Business Analyst typically enters the workflow at the beginning of projects or when research and analysis are needed.
|
||||
|
||||
#### Entry Points
|
||||
- **New Project Initiation**: When business requirements need clarification
|
||||
- **Market Research Requests**: When competitive or market analysis is required
|
||||
- **Problem Definition**: When challenges need structured analysis
|
||||
- **Strategic Planning**: When long-term planning requires research support
|
||||
|
||||
#### Handoff Procedures
|
||||
```markdown
|
||||
# From Stakeholders/Business Users
|
||||
- Receive initial problem statements or opportunities
|
||||
- Gather high-level business objectives and constraints
|
||||
- Understand stakeholder expectations and success criteria
|
||||
- Document initial scope and timeline requirements
|
||||
|
||||
# To Business Analyst
|
||||
- Clarify analysis objectives and desired outcomes
|
||||
- Define research scope and methodology
|
||||
- Establish communication protocols and review cycles
|
||||
- Set up collaborative workspaces and documentation systems
|
||||
```
|
||||
|
||||
### Phase 2: Analysis and Research Execution
|
||||
|
||||
#### Working Modes Integration
|
||||
|
||||
**Brainstorming Mode Integration**
|
||||
```markdown
|
||||
# Typical Workflow
|
||||
1. Stakeholder presents challenge or opportunity
|
||||
2. Analyst facilitates ideation sessions
|
||||
3. Ideas are captured and organized
|
||||
4. Key insights are synthesized and prioritized
|
||||
5. Recommendations are developed for next steps
|
||||
|
||||
# Integration Points
|
||||
- With Product Managers: Validate market assumptions
|
||||
- With UX/UI Teams: Explore user experience implications
|
||||
- With Technical Teams: Assess feasibility of concepts
|
||||
```
|
||||
|
||||
**Research Mode Integration**
|
||||
```markdown
|
||||
# Typical Workflow
|
||||
1. Research objectives are defined collaboratively
|
||||
2. Comprehensive research prompt is developed
|
||||
3. Research is executed (by Analyst or dedicated research team)
|
||||
4. Findings are analyzed and synthesized
|
||||
5. Insights are documented and communicated
|
||||
|
||||
# Integration Points
|
||||
- With Product Managers: Market and competitive intelligence
|
||||
- With System Architects: Technical feasibility research
|
||||
- With Product Owners: Detailed requirement specifications
|
||||
```
|
||||
|
||||
**Project Briefing Mode Integration**
|
||||
```markdown
|
||||
# Typical Workflow
|
||||
1. Analysis and research findings are compiled
|
||||
2. Project brief is developed using standard template
|
||||
3. Stakeholders review and provide feedback
|
||||
4. Brief is finalized and approved
|
||||
5. Handoff to development team is executed
|
||||
|
||||
# Integration Points
|
||||
- With Product Managers: Strategic alignment validation
|
||||
- With Product Owners: Requirement specification handoff
|
||||
- With Development Teams: Project scope and success criteria communication
|
||||
```
|
||||
|
||||
### Phase 3: Handoff and Transition
|
||||
|
||||
#### Downstream Integrations
|
||||
|
||||
**To Product Manager (John)**
|
||||
```markdown
|
||||
# Handoff Package
|
||||
- Market research findings and competitive analysis
|
||||
- User research insights and persona definitions
|
||||
- Strategic recommendations and opportunity assessment
|
||||
- Risk analysis and mitigation strategies
|
||||
|
||||
# Success Criteria
|
||||
- Market assumptions are validated or flagged for further research
|
||||
- Competitive landscape is clearly understood
|
||||
- User needs and pain points are documented
|
||||
- Strategic direction is supported by evidence
|
||||
```
|
||||
|
||||
**To System Architect (Fred)**
|
||||
```markdown
|
||||
# Handoff Package
|
||||
- Technical feasibility research and analysis
|
||||
- Solution option evaluation and recommendations
|
||||
- Integration requirements and constraints
|
||||
- Performance and scalability considerations
|
||||
|
||||
# Success Criteria
|
||||
- Technical approach is informed by research
|
||||
- Architecture decisions are supported by analysis
|
||||
- Integration challenges are identified and addressed
|
||||
- Performance requirements are clearly defined
|
||||
```
|
||||
|
||||
**To Product Owner (Sarah)**
|
||||
```markdown
|
||||
# Handoff Package
|
||||
- Detailed project brief with clear scope and objectives
|
||||
- User stories and acceptance criteria templates
|
||||
- Priority matrix and feature roadmap recommendations
|
||||
- Success metrics and measurement framework
|
||||
|
||||
# Success Criteria
|
||||
- Project scope is clearly defined and agreed upon
|
||||
- User stories are well-structured and testable
|
||||
- Priorities are based on evidence and stakeholder input
|
||||
- Success can be measured and validated
|
||||
```
|
||||
|
||||
## Third-Party Tool Integrations
|
||||
|
||||
### Research and Analysis Tools
|
||||
|
||||
#### Market Research Platforms
|
||||
```markdown
|
||||
# Integration Options
|
||||
- **Statista**: Market data and industry reports
|
||||
- **IBISWorld**: Industry analysis and forecasting
|
||||
- **Gartner**: Technology and business intelligence
|
||||
- **Forrester**: Research and advisory services
|
||||
|
||||
# Setup Process
|
||||
1. Configure API access or manual data import processes
|
||||
2. Establish data validation and quality assurance procedures
|
||||
3. Create templates for research documentation and citation
|
||||
4. Set up regular data refresh and update cycles
|
||||
```
|
||||
|
||||
#### Survey and Feedback Tools
|
||||
```markdown
|
||||
# Integration Options
|
||||
- **SurveyMonkey**: User research and feedback collection
|
||||
- **Typeform**: Interactive surveys and questionnaires
|
||||
- **UserVoice**: Customer feedback and feature requests
|
||||
- **Hotjar**: User behavior analysis and heatmaps
|
||||
|
||||
# Setup Process
|
||||
1. Configure survey templates and question libraries
|
||||
2. Establish data collection and analysis workflows
|
||||
3. Create reporting templates and dashboard views
|
||||
4. Set up automated data export and integration processes
|
||||
```
|
||||
|
||||
### Collaboration and Documentation Tools
|
||||
|
||||
#### Documentation Platforms
|
||||
```markdown
|
||||
# Integration Options
|
||||
- **Confluence**: Team collaboration and knowledge management
|
||||
- **Notion**: All-in-one workspace for documentation and planning
|
||||
- **GitBook**: Technical documentation and knowledge bases
|
||||
- **Coda**: Interactive documents and databases
|
||||
|
||||
# Setup Process
|
||||
1. Create template libraries for common document types
|
||||
2. Establish version control and review processes
|
||||
3. Configure access permissions and sharing protocols
|
||||
4. Set up automated backup and archival procedures
|
||||
```
|
||||
|
||||
#### Communication Tools
|
||||
```markdown
|
||||
# Integration Options
|
||||
- **Slack**: Team communication and collaboration
|
||||
- **Microsoft Teams**: Enterprise communication and file sharing
|
||||
- **Zoom**: Video conferencing and screen sharing
|
||||
- **Miro**: Visual collaboration and brainstorming
|
||||
|
||||
# Setup Process
|
||||
1. Configure channels and workspaces for project communication
|
||||
2. Establish meeting templates and facilitation guidelines
|
||||
3. Create shared workspaces for collaborative analysis
|
||||
4. Set up automated notifications and status updates
|
||||
```
|
||||
|
||||
### Project Management Integration
|
||||
|
||||
#### Agile and Project Management Tools
|
||||
```markdown
|
||||
# Integration Options
|
||||
- **Jira**: Issue tracking and project management
|
||||
- **Azure DevOps**: End-to-end development lifecycle management
|
||||
- **Asana**: Team collaboration and task management
|
||||
- **Monday.com**: Work operating system and project tracking
|
||||
|
||||
# Setup Process
|
||||
1. Configure project templates and workflow processes
|
||||
2. Establish requirement tracking and traceability
|
||||
3. Create reporting dashboards and status views
|
||||
4. Set up automated handoff and notification processes
|
||||
```
|
||||
|
||||
## Quality Assurance Integration
|
||||
|
||||
### Review and Validation Processes
|
||||
|
||||
#### Peer Review Integration
|
||||
```markdown
|
||||
# Review Process
|
||||
1. **Internal Review**: Self-assessment using quality checklists
|
||||
2. **Peer Review**: Cross-validation by other Business Analysts
|
||||
3. **Stakeholder Review**: Validation by business stakeholders
|
||||
4. **Technical Review**: Feasibility assessment by technical teams
|
||||
|
||||
# Quality Gates
|
||||
- Research methodology is sound and appropriate
|
||||
- Findings are supported by credible evidence
|
||||
- Recommendations are actionable and prioritized
|
||||
- Documentation meets established standards
|
||||
```
|
||||
|
||||
#### Continuous Improvement Integration
|
||||
```markdown
|
||||
# Improvement Process
|
||||
1. **Retrospective Analysis**: Regular review of completed projects
|
||||
2. **Feedback Collection**: Systematic gathering of stakeholder input
|
||||
3. **Process Refinement**: Continuous improvement of methods and tools
|
||||
4. **Knowledge Sharing**: Documentation and dissemination of lessons learned
|
||||
|
||||
# Success Metrics
|
||||
- Stakeholder satisfaction with analysis quality
|
||||
- Time-to-insight improvement over time
|
||||
- Accuracy of predictions and recommendations
|
||||
- Adoption rate of recommended solutions
|
||||
```
|
||||
|
||||
## Troubleshooting Integration Issues
|
||||
|
||||
### Common Integration Challenges
|
||||
|
||||
**Challenge**: Inconsistent handoff documentation
|
||||
**Solution**: Implement standardized templates and checklists for all handoff processes
|
||||
|
||||
**Challenge**: Misaligned expectations between teams
|
||||
**Solution**: Establish clear communication protocols and regular alignment checkpoints
|
||||
|
||||
**Challenge**: Research findings not actionable
|
||||
**Solution**: Focus on specific, measurable outcomes and validate actionability with downstream teams
|
||||
|
||||
**Challenge**: Tool integration complexity
|
||||
**Solution**: Start with core integrations and gradually expand based on demonstrated value
|
||||
|
||||
### Support and Escalation
|
||||
|
||||
#### Internal Support
|
||||
- **Documentation**: Comprehensive guides and templates
|
||||
- **Training**: Regular skill development and tool training
|
||||
- **Mentoring**: Peer support and knowledge sharing programs
|
||||
|
||||
#### External Support
|
||||
- **Vendor Support**: Direct support from tool and platform providers
|
||||
- **Community Resources**: Industry forums and professional networks
|
||||
- **Consulting Services**: Specialized expertise for complex integrations
|
||||
|
||||
---
|
||||
|
||||
*This integration guide provides the framework for successfully incorporating the Business Analyst persona into your BMAD Method implementation. For specific setup instructions and troubleshooting, refer to the Comprehensive Guide and Quick Start Guide.*
|
||||
|
|
@ -0,0 +1,475 @@
|
|||
# Business Analyst (Analyst) - Quality Standards
|
||||
|
||||
## Overview
|
||||
|
||||
This document establishes comprehensive quality standards for the Business Analyst persona in the BMAD Method. These standards ensure consistent, high-quality analysis deliverables across all working modes: Brainstorming, Research, and Project Briefing.
|
||||
|
||||
## Quality Framework
|
||||
|
||||
### Quality Dimensions
|
||||
|
||||
#### 1. **Analysis Rigor** (25% weight)
|
||||
The thoroughness and methodological soundness of analytical work.
|
||||
|
||||
#### 2. **Evidence Quality** (20% weight)
|
||||
The credibility, relevance, and sufficiency of supporting evidence.
|
||||
|
||||
#### 3. **Communication Clarity** (20% weight)
|
||||
The effectiveness of communicating insights and recommendations.
|
||||
|
||||
#### 4. **Stakeholder Alignment** (15% weight)
|
||||
The degree to which deliverables meet stakeholder needs and expectations.
|
||||
|
||||
#### 5. **Actionability** (10% weight)
|
||||
The practical implementability of recommendations and insights.
|
||||
|
||||
#### 6. **Timeliness** (10% weight)
|
||||
The delivery of quality work within agreed timeframes.
|
||||
|
||||
---
|
||||
|
||||
## 1. Analysis Rigor Standards
|
||||
|
||||
### Methodology Standards
|
||||
|
||||
#### Research Design Excellence
|
||||
**Standard**: All research and analysis must follow established methodological frameworks appropriate to the research question and context.
|
||||
|
||||
**Requirements**:
|
||||
- Research questions are specific, measurable, and directly related to business objectives
|
||||
- Methodology selection is justified and appropriate for the research objectives
|
||||
- Sample sizes and selection criteria meet statistical or qualitative research standards
|
||||
- Bias mitigation strategies are implemented and documented
|
||||
- Alternative approaches are considered and selection rationale is provided
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Methodology is innovative, rigorous, and perfectly suited to objectives
|
||||
- ✅ **Good (7-8)**: Methodology is sound, well-executed, and appropriate
|
||||
- âš ï¸ **Satisfactory (5-6)**: Methodology is adequate but may have minor limitations
|
||||
- ⌠**Needs Improvement (3-4)**: Methodology has significant limitations affecting reliability
|
||||
- ⌠**Poor (1-2)**: Methodology is inappropriate or fundamentally flawed
|
||||
|
||||
#### Analytical Depth
|
||||
**Standard**: Analysis must demonstrate appropriate depth and breadth for the complexity of the problem and stakeholder needs.
|
||||
|
||||
**Requirements**:
|
||||
- Multiple perspectives and viewpoints are considered
|
||||
- Root causes are explored beyond surface-level symptoms
|
||||
- Interconnections and dependencies are identified and analyzed
|
||||
- Assumptions are explicitly stated and tested where possible
|
||||
- Limitations and constraints are acknowledged and addressed
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Analysis demonstrates exceptional depth with novel insights
|
||||
- ✅ **Good (7-8)**: Analysis is thorough and reveals important insights
|
||||
- âš ï¸ **Satisfactory (5-6)**: Analysis covers key areas but may lack some depth
|
||||
- ⌠**Needs Improvement (3-4)**: Analysis is superficial or misses important aspects
|
||||
- ⌠**Poor (1-2)**: Analysis lacks depth and fails to address core issues
|
||||
|
||||
### Validation Standards
|
||||
|
||||
#### Cross-Validation Requirements
|
||||
**Standard**: All significant findings must be validated through multiple sources or methods.
|
||||
|
||||
**Requirements**:
|
||||
- Primary findings are supported by at least two independent sources
|
||||
- Quantitative findings are verified through alternative calculation methods
|
||||
- Qualitative insights are triangulated across multiple data sources
|
||||
- Expert validation is sought for specialized or technical findings
|
||||
- Peer review is conducted for all major analytical conclusions
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Comprehensive validation using multiple rigorous methods
|
||||
- ✅ **Good (7-8)**: Adequate validation with minor gaps
|
||||
- âš ï¸ **Satisfactory (5-6)**: Basic validation but some findings lack support
|
||||
- ⌠**Needs Improvement (3-4)**: Insufficient validation for key findings
|
||||
- ⌠**Poor (1-2)**: Little to no validation of analytical conclusions
|
||||
|
||||
---
|
||||
|
||||
## 2. Evidence Quality Standards
|
||||
|
||||
### Data Source Standards
|
||||
|
||||
#### Source Credibility
|
||||
**Standard**: All data sources must meet established credibility criteria and be appropriate for the analysis objectives.
|
||||
|
||||
**Requirements**:
|
||||
- Primary sources are authoritative and current (within 2 years unless historical analysis)
|
||||
- Secondary sources are from reputable organizations or peer-reviewed publications
|
||||
- Industry data comes from recognized research firms or trade associations
|
||||
- Internal data is validated for accuracy and completeness
|
||||
- Source limitations and potential biases are documented
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: All sources are highly credible and perfectly relevant
|
||||
- ✅ **Good (7-8)**: Sources are credible with minor relevance gaps
|
||||
- âš ï¸ **Satisfactory (5-6)**: Most sources are adequate but some quality concerns
|
||||
- ⌠**Needs Improvement (3-4)**: Several sources lack credibility or relevance
|
||||
- ⌠**Poor (1-2)**: Sources are generally unreliable or inappropriate
|
||||
|
||||
#### Data Sufficiency
|
||||
**Standard**: Evidence must be sufficient in quantity and quality to support analytical conclusions with appropriate confidence levels.
|
||||
|
||||
**Requirements**:
|
||||
- Sample sizes meet minimum statistical requirements for quantitative analysis
|
||||
- Qualitative data reaches saturation point for thematic analysis
|
||||
- Multiple data points support each major finding
|
||||
- Data coverage is comprehensive across all relevant dimensions
|
||||
- Gaps in data are identified and their impact assessed
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Evidence is comprehensive and exceeds sufficiency requirements
|
||||
- ✅ **Good (7-8)**: Evidence is sufficient with minor gaps
|
||||
- âš ï¸ **Satisfactory (5-6)**: Evidence meets minimum requirements
|
||||
- ⌠**Needs Improvement (3-4)**: Evidence is insufficient for some conclusions
|
||||
- ⌠**Poor (1-2)**: Evidence is generally insufficient for reliable conclusions
|
||||
|
||||
### Evidence Integration Standards
|
||||
|
||||
#### Synthesis Quality
|
||||
**Standard**: Evidence from multiple sources must be effectively integrated to create coherent insights and conclusions.
|
||||
|
||||
**Requirements**:
|
||||
- Conflicting evidence is acknowledged and reconciled
|
||||
- Patterns and themes are identified across data sources
|
||||
- Evidence hierarchy is established based on quality and relevance
|
||||
- Synthesis reveals insights not apparent in individual sources
|
||||
- Integration methodology is transparent and replicable
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Masterful synthesis revealing profound insights
|
||||
- ✅ **Good (7-8)**: Effective synthesis with clear insights
|
||||
- âš ï¸ **Satisfactory (5-6)**: Adequate synthesis but limited insight generation
|
||||
- ⌠**Needs Improvement (3-4)**: Poor synthesis with conflicting or unclear conclusions
|
||||
- ⌠**Poor (1-2)**: No effective synthesis; evidence presented without integration
|
||||
|
||||
---
|
||||
|
||||
## 3. Communication Clarity Standards
|
||||
|
||||
### Document Structure Standards
|
||||
|
||||
#### Organization and Flow
|
||||
**Standard**: All deliverables must follow logical structure with clear information hierarchy and smooth transitions.
|
||||
|
||||
**Requirements**:
|
||||
- Executive summary captures essential points in 2-3 paragraphs
|
||||
- Information is organized from general to specific
|
||||
- Sections build logically toward conclusions and recommendations
|
||||
- Transitions between sections are clear and purposeful
|
||||
- Supporting details are appropriately placed in appendices
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Perfect organization with compelling narrative flow
|
||||
- ✅ **Good (7-8)**: Well-organized with clear logical progression
|
||||
- âš ï¸ **Satisfactory (5-6)**: Adequate organization but some unclear transitions
|
||||
- ⌠**Needs Improvement (3-4)**: Poor organization impedes understanding
|
||||
- ⌠**Poor (1-2)**: Disorganized with no clear structure
|
||||
|
||||
#### Clarity and Accessibility
|
||||
**Standard**: Communication must be clear, concise, and accessible to the intended audience.
|
||||
|
||||
**Requirements**:
|
||||
- Language is appropriate for the target audience
|
||||
- Technical terms are defined when first used
|
||||
- Key messages are prominent and easy to identify
|
||||
- Visual aids enhance rather than complicate understanding
|
||||
- Document length is appropriate for content complexity
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Crystal clear communication perfectly tailored to audience
|
||||
- ✅ **Good (7-8)**: Clear communication with minor accessibility issues
|
||||
- âš ï¸ **Satisfactory (5-6)**: Generally clear but some confusing elements
|
||||
- ⌠**Needs Improvement (3-4)**: Unclear communication impedes comprehension
|
||||
- ⌠**Poor (1-2)**: Very unclear; major communication barriers
|
||||
|
||||
### Visual Communication Standards
|
||||
|
||||
#### Data Visualization
|
||||
**Standard**: All data visualizations must accurately represent data and enhance understanding.
|
||||
|
||||
**Requirements**:
|
||||
- Chart types are appropriate for the data being presented
|
||||
- Scales and axes are clearly labeled and not misleading
|
||||
- Colors and formatting enhance rather than distract from the message
|
||||
- Visualizations are accessible to colorblind users
|
||||
- Source data and methodology are clearly cited
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Outstanding visualizations that reveal insights
|
||||
- ✅ **Good (7-8)**: Effective visualizations that support understanding
|
||||
- âš ï¸ **Satisfactory (5-6)**: Adequate visualizations with minor issues
|
||||
- ⌠**Needs Improvement (3-4)**: Poor visualizations that confuse or mislead
|
||||
- ⌠**Poor (1-2)**: Misleading or inappropriate visualizations
|
||||
|
||||
---
|
||||
|
||||
## 4. Stakeholder Alignment Standards
|
||||
|
||||
### Requirements Fulfillment
|
||||
|
||||
#### Objective Achievement
|
||||
**Standard**: All deliverables must directly address stated objectives and success criteria.
|
||||
|
||||
**Requirements**:
|
||||
- Primary objectives are fully addressed with specific findings
|
||||
- Secondary objectives are addressed or explicitly noted as out of scope
|
||||
- Success criteria are met or gaps are explained
|
||||
- Stakeholder questions are answered comprehensively
|
||||
- Scope boundaries are respected and maintained
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Exceeds objectives with additional valuable insights
|
||||
- ✅ **Good (7-8)**: Fully meets objectives with quality execution
|
||||
- âš ï¸ **Satisfactory (5-6)**: Meets most objectives but some gaps
|
||||
- ⌠**Needs Improvement (3-4)**: Partially meets objectives with significant gaps
|
||||
- ⌠**Poor (1-2)**: Fails to meet primary objectives
|
||||
|
||||
#### Stakeholder Satisfaction
|
||||
**Standard**: Deliverables must meet or exceed stakeholder expectations for quality, relevance, and usefulness.
|
||||
|
||||
**Requirements**:
|
||||
- Stakeholder feedback is actively sought and incorporated
|
||||
- Decision-making needs are addressed with appropriate detail
|
||||
- Implementation considerations are included
|
||||
- Follow-up requirements are identified and planned
|
||||
- Value proposition is clear and compelling
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Stakeholders are delighted with value provided
|
||||
- ✅ **Good (7-8)**: Stakeholders are satisfied with deliverable quality
|
||||
- âš ï¸ **Satisfactory (5-6)**: Stakeholders find deliverable adequate
|
||||
- ⌠**Needs Improvement (3-4)**: Stakeholders have significant concerns
|
||||
- ⌠**Poor (1-2)**: Stakeholders are dissatisfied with deliverable
|
||||
|
||||
---
|
||||
|
||||
## 5. Actionability Standards
|
||||
|
||||
### Recommendation Quality
|
||||
|
||||
#### Specificity and Clarity
|
||||
**Standard**: All recommendations must be specific, clear, and implementable.
|
||||
|
||||
**Requirements**:
|
||||
- Recommendations include specific actions, not general suggestions
|
||||
- Implementation steps are outlined with appropriate detail
|
||||
- Resource requirements are identified and estimated
|
||||
- Timeline considerations are addressed
|
||||
- Success metrics are defined for each recommendation
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Recommendations are highly specific and immediately actionable
|
||||
- ✅ **Good (7-8)**: Recommendations are clear and actionable with minor gaps
|
||||
- âš ï¸ **Satisfactory (5-6)**: Recommendations are generally actionable but lack some detail
|
||||
- ⌠**Needs Improvement (3-4)**: Recommendations are vague or difficult to implement
|
||||
- ⌠**Poor (1-2)**: Recommendations are unclear or not actionable
|
||||
|
||||
#### Feasibility Assessment
|
||||
**Standard**: All recommendations must be assessed for implementation feasibility.
|
||||
|
||||
**Requirements**:
|
||||
- Technical feasibility is evaluated and documented
|
||||
- Resource feasibility is assessed against available capabilities
|
||||
- Timeline feasibility is evaluated against business constraints
|
||||
- Risk factors are identified and mitigation strategies proposed
|
||||
- Alternative approaches are considered when primary recommendations face barriers
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Comprehensive feasibility analysis with creative solutions
|
||||
- ✅ **Good (7-8)**: Thorough feasibility assessment with practical recommendations
|
||||
- âš ï¸ **Satisfactory (5-6)**: Basic feasibility consideration but some gaps
|
||||
- ⌠**Needs Improvement (3-4)**: Limited feasibility analysis
|
||||
- ⌠**Poor (1-2)**: No meaningful feasibility assessment
|
||||
|
||||
---
|
||||
|
||||
## 6. Timeliness Standards
|
||||
|
||||
### Delivery Performance
|
||||
|
||||
#### Schedule Adherence
|
||||
**Standard**: All deliverables must be completed within agreed timeframes while maintaining quality standards.
|
||||
|
||||
**Requirements**:
|
||||
- Project milestones are met consistently
|
||||
- Early warning is provided for potential delays
|
||||
- Quality is not compromised to meet deadlines
|
||||
- Scope adjustments are negotiated when timeline constraints threaten quality
|
||||
- Contingency plans are developed for critical path activities
|
||||
|
||||
**Quality Indicators**:
|
||||
- ✅ **Excellent (9-10)**: Consistently delivers early with exceptional quality
|
||||
- ✅ **Good (7-8)**: Meets deadlines with high quality
|
||||
- âš ï¸ **Satisfactory (5-6)**: Generally meets deadlines but occasional delays
|
||||
- ⌠**Needs Improvement (3-4)**: Frequent delays or quality compromises
|
||||
- ⌠**Poor (1-2)**: Consistently late or poor quality due to time pressure
|
||||
|
||||
---
|
||||
|
||||
## Quality Measurement and Monitoring
|
||||
|
||||
### Quality Metrics Framework
|
||||
|
||||
#### Quantitative Metrics
|
||||
```
|
||||
Quality Score Calculation:
|
||||
- Analysis Rigor: 25% × (Methodology Score + Analytical Depth Score) / 2
|
||||
- Evidence Quality: 20% × (Source Credibility Score + Data Sufficiency Score) / 2
|
||||
- Communication Clarity: 20% × (Organization Score + Clarity Score) / 2
|
||||
- Stakeholder Alignment: 15% × (Objective Achievement Score + Satisfaction Score) / 2
|
||||
- Actionability: 10% × (Specificity Score + Feasibility Score) / 2
|
||||
- Timeliness: 10% × Schedule Adherence Score
|
||||
|
||||
Overall Quality Score = Sum of weighted dimension scores
|
||||
```
|
||||
|
||||
#### Qualitative Assessment
|
||||
**Quality Rating Scale**:
|
||||
- **Exceptional (9.0-10.0)**: Exceeds all standards with innovative approaches
|
||||
- **Excellent (8.0-8.9)**: Meets all standards with high quality execution
|
||||
- **Good (7.0-7.9)**: Meets most standards with solid quality
|
||||
- **Satisfactory (6.0-6.9)**: Meets minimum standards but has improvement areas
|
||||
- **Needs Improvement (4.0-5.9)**: Below standards requiring significant improvement
|
||||
- **Poor (1.0-3.9)**: Well below standards requiring major remediation
|
||||
|
||||
### Continuous Improvement Process
|
||||
|
||||
#### Quality Review Cycle
|
||||
```mermaid title="Quality Review Process" type="diagram"
|
||||
graph TD
|
||||
A["Deliverable Creation"] --> B["Self-Assessment"]
|
||||
B --> C["Peer Review"]
|
||||
C --> D["Stakeholder Feedback"]
|
||||
D --> E["Quality Scoring"]
|
||||
E --> F["Improvement Planning"]
|
||||
F --> G["Process Updates"]
|
||||
G --> A
|
||||
```
|
||||
|
||||
#### Improvement Actions
|
||||
|
||||
**Individual Level**:
|
||||
- Personal development plans based on quality assessments
|
||||
- Skill building in areas of weakness
|
||||
- Mentoring and coaching for quality improvement
|
||||
- Best practice sharing across the team
|
||||
|
||||
**Team Level**:
|
||||
- Template updates based on quality feedback
|
||||
- Process improvements to address common quality issues
|
||||
- Training programs for quality standard implementation
|
||||
- Quality recognition and reward programs
|
||||
|
||||
**Organizational Level**:
|
||||
- Quality standard updates based on industry best practices
|
||||
- Tool and technology improvements to support quality
|
||||
- Resource allocation to support quality objectives
|
||||
- Integration of quality metrics into performance management
|
||||
|
||||
### Quality Assurance Procedures
|
||||
|
||||
#### Pre-Delivery Quality Gates
|
||||
|
||||
**Gate 1: Planning Review**
|
||||
- [ ] Objectives are clear and measurable
|
||||
- [ ] Methodology is appropriate and documented
|
||||
- [ ] Resource requirements are realistic
|
||||
- [ ] Timeline allows for quality execution
|
||||
|
||||
**Gate 2: Progress Review**
|
||||
- [ ] Analysis is proceeding according to plan
|
||||
- [ ] Data quality meets standards
|
||||
- [ ] Interim findings are validated
|
||||
- [ ] Stakeholder feedback is incorporated
|
||||
|
||||
**Gate 3: Final Review**
|
||||
- [ ] All quality standards are met
|
||||
- [ ] Stakeholder requirements are fulfilled
|
||||
- [ ] Recommendations are actionable
|
||||
- [ ] Documentation is complete and accurate
|
||||
|
||||
#### Quality Escalation Process
|
||||
|
||||
**Level 1: Self-Correction**
|
||||
- Analyst identifies and addresses quality issues
|
||||
- Minor adjustments to approach or deliverables
|
||||
- Documentation of lessons learned
|
||||
|
||||
**Level 2: Peer Support**
|
||||
- Peer review identifies quality concerns
|
||||
- Collaborative problem-solving for improvement
|
||||
- Shared accountability for quality outcomes
|
||||
|
||||
**Level 3: Management Intervention**
|
||||
- Significant quality issues requiring management support
|
||||
- Resource reallocation or timeline adjustments
|
||||
- Formal quality improvement planning
|
||||
|
||||
**Level 4: Organizational Response**
|
||||
- Systemic quality issues affecting multiple projects
|
||||
- Process or standard modifications required
|
||||
- Training or capability development needs
|
||||
|
||||
---
|
||||
|
||||
## Quality Standards Implementation
|
||||
|
||||
### Training and Development
|
||||
|
||||
#### Initial Certification
|
||||
**Requirements for Business Analyst Quality Certification**:
|
||||
- Completion of quality standards training program
|
||||
- Demonstration of quality standard application
|
||||
- Successful completion of quality assessment
|
||||
- Peer validation of quality competency
|
||||
|
||||
#### Ongoing Development
|
||||
- Quarterly quality standard updates and training
|
||||
- Annual quality competency assessment
|
||||
- Continuous learning through quality communities of practice
|
||||
- Regular exposure to industry quality best practices
|
||||
|
||||
### Tools and Resources
|
||||
|
||||
#### Quality Support Tools
|
||||
- Quality assessment templates and checklists
|
||||
- Automated quality checking tools where applicable
|
||||
- Peer review collaboration platforms
|
||||
- Quality metrics dashboards and reporting
|
||||
|
||||
#### Reference Materials
|
||||
- Quality standard quick reference guides
|
||||
- Best practice examples and case studies
|
||||
- Quality troubleshooting guides
|
||||
- Industry benchmark data for quality comparison
|
||||
|
||||
### Success Metrics
|
||||
|
||||
#### Individual Quality Metrics
|
||||
- Average quality score across all deliverables
|
||||
- Improvement trend in quality scores over time
|
||||
- Stakeholder satisfaction ratings
|
||||
- Peer review feedback scores
|
||||
|
||||
#### Team Quality Metrics
|
||||
- Team average quality scores
|
||||
- Quality standard compliance rates
|
||||
- Time to quality (efficiency of achieving quality)
|
||||
- Quality-related rework rates
|
||||
|
||||
#### Organizational Quality Metrics
|
||||
- Overall quality score trends
|
||||
- Quality standard effectiveness measures
|
||||
- Quality-related customer satisfaction
|
||||
- Quality improvement initiative success rates
|
||||
|
||||
---
|
||||
|
||||
**Quality Standards Version**: 1.0
|
||||
**Effective Date**: [Date]
|
||||
**Next Review**: [Date]
|
||||
**Approved By**: [Quality Assurance Manager]
|
||||
**Maintained By**: Business Analyst Team Lead
|
||||
```
|
||||
|
|
@ -0,0 +1,313 @@
|
|||
# Business Analyst (Analyst) - Quick Start Guide
|
||||
|
||||
## 5-Minute Setup
|
||||
|
||||
### Step 1: Persona Activation (1 minute)
|
||||
```markdown
|
||||
# In v0.dev or your IDE
|
||||
1. Load BMAD Method workspace
|
||||
2. Select "Business Analyst" persona
|
||||
3. Verify activation: "Insightful Analyst & Strategic Ideation Partner"
|
||||
4. Confirm access to three working modes:
|
||||
- Brainstorming Phase
|
||||
- Deep Research Prompt Generation Phase
|
||||
- Project Briefing Phase
|
||||
```
|
||||
|
||||
### Step 2: Choose Your Working Mode (1 minute)
|
||||
```markdown
|
||||
# Mode Selection Guide
|
||||
**Brainstorming Phase**: Use when you need to:
|
||||
- Generate new product ideas
|
||||
- Explore solution possibilities
|
||||
- Challenge assumptions creatively
|
||||
|
||||
**Research Phase**: Use when you need to:
|
||||
- Plan comprehensive market research
|
||||
- Structure competitive analysis
|
||||
- Design user research studies
|
||||
|
||||
**Briefing Phase**: Use when you need to:
|
||||
- Create formal project documentation
|
||||
- Define scope and requirements
|
||||
- Prepare development handoffs
|
||||
```
|
||||
|
||||
### Step 3: Quick Configuration (2 minutes)
|
||||
```markdown
|
||||
# Essential Setup
|
||||
1. Create working directories:
|
||||
/research - Research findings and analysis
|
||||
/briefs - Project documentation
|
||||
/templates - Reusable frameworks
|
||||
|
||||
2. Bookmark key resources:
|
||||
- Industry research databases
|
||||
- Competitive intelligence sources
|
||||
- User research tools
|
||||
|
||||
3. Set up collaboration tools:
|
||||
- Shared workspaces for stakeholder input
|
||||
- Communication channels for team updates
|
||||
- Review and feedback systems
|
||||
```
|
||||
|
||||
### Step 4: First Analysis (1 minute)
|
||||
```markdown
|
||||
# Quick Test Run
|
||||
1. Present a simple business challenge
|
||||
2. Watch the Analyst guide you through mode selection
|
||||
3. Experience the structured questioning approach
|
||||
4. Receive initial framework or next steps
|
||||
```
|
||||
|
||||
## Practical Example: E-commerce Mobile App Analysis
|
||||
|
||||
### Scenario Setup
|
||||
```markdown
|
||||
**Challenge**: "Our e-commerce conversion rates are declining on mobile devices"
|
||||
**Goal**: Understand the problem and develop actionable recommendations
|
||||
**Timeline**: 2 weeks for initial analysis
|
||||
**Stakeholders**: Product Manager, UX Team, Development Team
|
||||
```
|
||||
|
||||
### Working Session Example
|
||||
|
||||
#### Phase 1: Problem Analysis (Brainstorming Mode)
|
||||
```markdown
|
||||
Analyst: "Let's start by exploring this conversion rate challenge. I'll guide us through some structured brainstorming to uncover potential root causes and solutions."
|
||||
|
||||
Key Questions Asked:
|
||||
- "What specific metrics are declining? (conversion rate, cart abandonment, checkout completion?)"
|
||||
- "When did the decline start? Any correlation with app updates or market changes?"
|
||||
- "What's different about mobile vs. desktop user behavior?"
|
||||
- "What assumptions are we making about user intent and experience?"
|
||||
|
||||
Brainstorming Techniques Applied:
|
||||
- "What if..." scenarios: "What if users are abandoning due to payment friction?"
|
||||
- First principles: "What are the fundamental requirements for mobile commerce?"
|
||||
- Analogical thinking: "How do successful mobile-first retailers handle this?"
|
||||
|
||||
Output: Prioritized list of potential causes and investigation areas
|
||||
```
|
||||
|
||||
#### Phase 2: Research Planning (Research Mode)
|
||||
```markdown
|
||||
Analyst: "Based on our brainstorming, let's create a comprehensive research plan to validate our hypotheses."
|
||||
|
||||
Research Prompt Generated:
|
||||
---
|
||||
# Mobile Conversion Rate Research Brief
|
||||
|
||||
## Primary Objective
|
||||
Identify root causes of declining mobile e-commerce conversion rates and develop evidence-based improvement recommendations.
|
||||
|
||||
## Key Research Areas
|
||||
1. **User Experience Analysis**
|
||||
- Mobile app usability testing
|
||||
- User journey mapping and friction point identification
|
||||
- Comparative analysis with high-performing competitors
|
||||
|
||||
2. **Technical Performance Assessment**
|
||||
- Page load times and app performance metrics
|
||||
- Payment processing reliability and speed
|
||||
- Cross-device experience consistency
|
||||
|
||||
3. **Market and Competitive Intelligence**
|
||||
- Industry benchmarks for mobile conversion rates
|
||||
- Competitive feature analysis and best practices
|
||||
- Emerging trends in mobile commerce UX
|
||||
|
||||
## Specific Research Questions
|
||||
- What are the top 3 friction points in our mobile checkout process?
|
||||
- How do our load times compare to industry standards?
|
||||
- Which competitor features are driving higher engagement?
|
||||
- What payment methods do our users prefer on mobile?
|
||||
|
||||
## Success Criteria
|
||||
- Identify specific, actionable improvement opportunities
|
||||
- Quantify potential impact of recommended changes
|
||||
- Provide prioritized roadmap for implementation
|
||||
---
|
||||
|
||||
Output: Detailed research directive ready for execution
|
||||
```
|
||||
|
||||
#### Phase 3: Project Brief Creation (Briefing Mode)
|
||||
```markdown
|
||||
Analyst: "Now let's create a formal project brief to guide the improvement initiative."
|
||||
|
||||
Project Brief Created:
|
||||
---
|
||||
# Project Brief: Mobile Conversion Rate Optimization
|
||||
|
||||
## Executive Summary
|
||||
Mobile conversion rates have declined 15% over the past quarter. Research indicates three primary improvement areas: checkout process simplification, payment method expansion, and performance optimization.
|
||||
|
||||
## Problem Statement
|
||||
Current mobile checkout process has 4.2 steps vs. industry average of 2.8 steps, contributing to 35% cart abandonment rate.
|
||||
|
||||
## Objectives
|
||||
- Increase mobile conversion rate by 20% within 3 months
|
||||
- Reduce cart abandonment rate to below 25%
|
||||
- Improve mobile app store rating from 3.2 to 4.0+
|
||||
|
||||
## Scope
|
||||
**Included:**
|
||||
- Mobile app checkout flow redesign
|
||||
- Payment method integration (Apple Pay, Google Pay)
|
||||
- Performance optimization for key user flows
|
||||
|
||||
**Excluded:**
|
||||
- Desktop website changes
|
||||
- Inventory management system updates
|
||||
- Marketing campaign modifications
|
||||
|
||||
## Success Metrics
|
||||
- Mobile conversion rate: Target 20% improvement
|
||||
- Cart abandonment rate: Target <25%
|
||||
- Average checkout time: Target <90 seconds
|
||||
- User satisfaction score: Target >4.0/5.0
|
||||
|
||||
## Implementation Phases
|
||||
1. **Phase 1** (Weeks 1-2): UX research and design
|
||||
2. **Phase 2** (Weeks 3-6): Development and testing
|
||||
3. **Phase 3** (Weeks 7-8): Launch and optimization
|
||||
|
||||
## Next Steps
|
||||
1. UX/UI Architect: Create improved checkout flow designs
|
||||
2. System Architect: Design payment integration architecture
|
||||
3. Product Owner: Create detailed user stories and acceptance criteria
|
||||
---
|
||||
|
||||
Output: Complete project brief ready for team handoff
|
||||
```
|
||||
|
||||
## Common Usage Patterns
|
||||
|
||||
### Quick Market Research
|
||||
```markdown
|
||||
# 15-Minute Competitive Analysis
|
||||
1. "I need to understand our competitive position in [market segment]"
|
||||
2. Analyst guides through research question formulation
|
||||
3. Structured research plan is created
|
||||
4. Key information sources are identified
|
||||
5. Analysis framework is provided
|
||||
|
||||
Example Output:
|
||||
- Competitor feature comparison matrix
|
||||
- Market positioning analysis
|
||||
- Opportunity gap identification
|
||||
- Strategic recommendation summary
|
||||
```
|
||||
|
||||
### Rapid Problem Diagnosis
|
||||
```markdown
|
||||
# 20-Minute Problem Analysis
|
||||
1. "Our [metric] is declining and we don't know why"
|
||||
2. Analyst facilitates root cause brainstorming
|
||||
3. Hypotheses are prioritized by likelihood and impact
|
||||
4. Investigation plan is created
|
||||
5. Success criteria are defined
|
||||
|
||||
Example Output:
|
||||
- Prioritized hypothesis list
|
||||
- Investigation methodology
|
||||
- Resource requirements
|
||||
- Timeline and milestones
|
||||
```
|
||||
|
||||
### Strategic Planning Support
|
||||
```markdown
|
||||
# 30-Minute Strategy Session
|
||||
1. "We need to decide between [Option A] and [Option B]"
|
||||
2. Analyst structures decision criteria
|
||||
3. Research requirements are identified
|
||||
4. Evaluation framework is created
|
||||
5. Decision timeline is established
|
||||
|
||||
Example Output:
|
||||
- Decision criteria matrix
|
||||
- Research and analysis plan
|
||||
- Stakeholder input requirements
|
||||
- Decision-making timeline
|
||||
```
|
||||
|
||||
## Quick Reference Commands
|
||||
|
||||
### Mode Activation
|
||||
```markdown
|
||||
# Brainstorming Mode
|
||||
"I need to explore ideas about [topic]"
|
||||
"Help me brainstorm solutions for [challenge]"
|
||||
"Let's think creatively about [opportunity]"
|
||||
|
||||
# Research Mode
|
||||
"I need to research [topic] thoroughly"
|
||||
"Help me plan analysis of [market/competitor/user need]"
|
||||
"Create a research plan for [specific question]"
|
||||
|
||||
# Briefing Mode
|
||||
"I need to document this project formally"
|
||||
"Help me create a project brief for [initiative]"
|
||||
"Structure this information into a handoff document"
|
||||
```
|
||||
|
||||
### Quick Analysis Requests
|
||||
```markdown
|
||||
# Market Analysis
|
||||
"Analyze the competitive landscape for [product/service]"
|
||||
"What are the key trends in [industry/market]?"
|
||||
"How does our offering compare to [specific competitor]?"
|
||||
|
||||
# User Research
|
||||
"What do we need to know about [user segment]?"
|
||||
"Help me understand why users [specific behavior]"
|
||||
"Design research to validate [assumption/hypothesis]"
|
||||
|
||||
# Problem Solving
|
||||
"Our [metric] is [trend] - help me understand why"
|
||||
"We're seeing [issue] - what could be causing this?"
|
||||
"How should we prioritize [list of challenges]?"
|
||||
```
|
||||
|
||||
## Best Practices Checklist
|
||||
|
||||
### Before Starting Analysis
|
||||
- [ ] Clear objective is defined
|
||||
- [ ] Success criteria are established
|
||||
- [ ] Stakeholders are identified
|
||||
- [ ] Timeline and resources are confirmed
|
||||
- [ ] Working mode is selected appropriately
|
||||
|
||||
### During Analysis
|
||||
- [ ] Multiple perspectives are considered
|
||||
- [ ] Assumptions are documented and tested
|
||||
- [ ] Evidence is gathered from credible sources
|
||||
- [ ] Findings are validated through multiple methods
|
||||
- [ ] Insights are actionable and prioritized
|
||||
|
||||
### After Analysis
|
||||
- [ ] Recommendations are specific and measurable
|
||||
- [ ] Next steps are clearly defined
|
||||
- [ ] Handoff documentation is complete
|
||||
- [ ] Success metrics are established
|
||||
- [ ] Follow-up plan is created
|
||||
|
||||
## Troubleshooting Quick Fixes
|
||||
|
||||
### "Analysis is too broad"
|
||||
**Solution**: Use the "So what?" test - ensure every finding leads to a specific action
|
||||
|
||||
### "Research is taking too long"
|
||||
**Solution**: Set time limits, focus on decision-critical information first
|
||||
|
||||
### "Stakeholders aren't aligned"
|
||||
**Solution**: Document disagreements, facilitate alignment sessions, escalate if needed
|
||||
|
||||
### "Recommendations aren't being implemented"
|
||||
**Solution**: Ensure recommendations are specific, feasible, and have clear ownership
|
||||
|
||||
---
|
||||
|
||||
*This quick start guide gets you productive with the Business Analyst persona immediately. For comprehensive capabilities and advanced usage, refer to the Comprehensive Guide and Integration Guide.*
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,399 @@
|
|||
# Architect Comprehensive Guide
|
||||
**BMAD Method: System Architecture Persona**
|
||||
|
||||
## Introduction
|
||||
|
||||
The Architect persona in the BMAD Method serves as the technical foundation expert responsible for designing robust, scalable system architectures that align with business requirements and technical constraints. This comprehensive guide provides in-depth information on the Architect's role, responsibilities, workflows, and integration points within the BMAD ecosystem.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Role Definition](#role-definition)
|
||||
2. [Core Responsibilities](#core-responsibilities)
|
||||
3. [Key Capabilities](#key-capabilities)
|
||||
4. [Workflow Integration](#workflow-integration)
|
||||
5. [Task Library](#task-library)
|
||||
6. [Templates and Resources](#templates-and-resources)
|
||||
7. [Quality Standards](#quality-standards)
|
||||
8. [Integration with Other Personas](#integration-with-other-personas)
|
||||
9. [Best Practices](#best-practices)
|
||||
10. [Troubleshooting](#troubleshooting)
|
||||
|
||||
## Role Definition
|
||||
|
||||
The Architect in the BMAD Method is a specialized persona focused on:
|
||||
|
||||
- Designing comprehensive system architectures that support business requirements
|
||||
- Establishing technical standards and patterns for implementation
|
||||
- Ensuring scalability, security, and maintainability of technical solutions
|
||||
- Providing architectural guidance to development teams
|
||||
- Validating technical approaches against business constraints
|
||||
- Creating architectural documentation that serves as a blueprint for implementation
|
||||
|
||||
The Architect operates at both strategic and tactical levels, translating business needs into technical solutions while maintaining a holistic view of the system landscape.
|
||||
|
||||
## Core Responsibilities
|
||||
|
||||
### 1. Architecture Design
|
||||
|
||||
- Create high-level system architecture diagrams
|
||||
- Define component relationships and interactions
|
||||
- Establish data flow patterns and integration points
|
||||
- Design for scalability, security, and performance
|
||||
- Document architectural decisions and rationales
|
||||
|
||||
### 2. Technical Standards
|
||||
|
||||
- Define coding standards and best practices
|
||||
- Establish technology selection criteria
|
||||
- Create reusable architectural patterns
|
||||
- Document technical constraints and limitations
|
||||
- Provide guidance on technical debt management
|
||||
|
||||
### 3. Implementation Guidance
|
||||
|
||||
- Review technical approaches for alignment with architecture
|
||||
- Provide guidance on complex technical challenges
|
||||
- Support development teams with architectural expertise
|
||||
- Validate implementation against architectural standards
|
||||
- Recommend adjustments to improve technical quality
|
||||
|
||||
### 4. Architecture Evolution
|
||||
|
||||
- Manage architectural changes over time
|
||||
- Evaluate new technologies for potential adoption
|
||||
- Plan for technical debt reduction
|
||||
- Guide system evolution and modernization
|
||||
- Document architecture versions and transitions
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
The Architect persona possesses specialized capabilities that enable effective architecture design and implementation:
|
||||
|
||||
### Technical Expertise
|
||||
|
||||
- **System Design**: Creating cohesive, scalable system architectures
|
||||
- **Pattern Recognition**: Identifying and applying appropriate architectural patterns
|
||||
- **Technology Evaluation**: Assessing technologies for fit-for-purpose
|
||||
- **Performance Optimization**: Designing for optimal system performance
|
||||
- **Security Architecture**: Implementing secure-by-design principles
|
||||
|
||||
### Documentation Skills
|
||||
|
||||
- **Architecture Diagrams**: Creating clear visual representations of system components
|
||||
- **Decision Records**: Documenting architectural decisions and rationales
|
||||
- **Technical Specifications**: Defining detailed technical requirements
|
||||
- **Implementation Guidelines**: Providing clear guidance for development teams
|
||||
- **Reference Architectures**: Creating reusable architectural templates
|
||||
|
||||
### Collaboration Abilities
|
||||
|
||||
- **Stakeholder Communication**: Translating technical concepts for non-technical audiences
|
||||
- **Cross-team Coordination**: Working across multiple teams and disciplines
|
||||
- **Technical Mentorship**: Guiding developers on architectural principles
|
||||
- **Requirement Translation**: Converting business needs into technical solutions
|
||||
- **Conflict Resolution**: Resolving technical disagreements with evidence-based approaches
|
||||
|
||||
## Workflow Integration
|
||||
|
||||
The Architect persona integrates with the BMAD Method workflow at specific points:
|
||||
|
||||
### Project Initiation Phase
|
||||
|
||||
- Collaborates with Product Owner to understand business requirements
|
||||
- Works with UX/UI Architect to align technical and design approaches
|
||||
- Creates initial architecture vision and high-level design
|
||||
- Establishes technical constraints and guidelines
|
||||
|
||||
### Planning Phase
|
||||
|
||||
- Develops detailed architecture documentation
|
||||
- Defines component boundaries and interfaces
|
||||
- Creates data models and flow diagrams
|
||||
- Establishes technical standards for implementation
|
||||
- Validates technical feasibility of proposed features
|
||||
|
||||
### Implementation Phase
|
||||
|
||||
- Provides technical guidance to development teams
|
||||
- Reviews implementation for architectural alignment
|
||||
- Addresses complex technical challenges
|
||||
- Updates architecture documentation as needed
|
||||
- Validates technical quality of deliverables
|
||||
|
||||
### Evolution Phase
|
||||
|
||||
- Evaluates architecture performance and scalability
|
||||
- Identifies areas for technical improvement
|
||||
- Plans for system evolution and modernization
|
||||
- Updates architecture to accommodate new requirements
|
||||
- Documents architectural changes and transitions
|
||||
|
||||
## Task Library
|
||||
|
||||
The Architect persona has access to specialized tasks designed to facilitate architecture creation and management:
|
||||
|
||||
### Create Architecture
|
||||
|
||||
A comprehensive task for designing and documenting a complete system architecture:
|
||||
|
||||
- **Input**: Business requirements, technical constraints, existing systems
|
||||
- **Process**: Analysis, design, documentation, validation
|
||||
- **Output**: Complete architecture documentation package
|
||||
- **Integration**: Links to PRD, technical specifications, implementation guidelines
|
||||
|
||||
### Create Infrastructure Architecture
|
||||
|
||||
A focused task for designing infrastructure components:
|
||||
|
||||
- **Input**: System requirements, scaling needs, operational constraints
|
||||
- **Process**: Infrastructure design, capacity planning, security modeling
|
||||
- **Output**: Infrastructure architecture documentation
|
||||
- **Integration**: Links to deployment plans, operational guidelines
|
||||
|
||||
### Review Infrastructure
|
||||
|
||||
A validation task for assessing existing or proposed infrastructure:
|
||||
|
||||
- **Input**: Infrastructure documentation, performance requirements
|
||||
- **Process**: Analysis, validation, recommendation
|
||||
- **Output**: Infrastructure assessment report
|
||||
- **Integration**: Links to improvement plans, technical debt tracking
|
||||
|
||||
### Validate Infrastructure
|
||||
|
||||
A quality assurance task for ensuring infrastructure meets requirements:
|
||||
|
||||
- **Input**: Infrastructure implementation, requirements
|
||||
- **Process**: Testing, validation, performance assessment
|
||||
- **Output**: Validation report with recommendations
|
||||
- **Integration**: Links to quality standards, performance metrics
|
||||
|
||||
### Create Frontend Architecture
|
||||
|
||||
A specialized task for designing frontend technical architecture:
|
||||
|
||||
- **Input**: UX/UI requirements, technical constraints
|
||||
- **Process**: Component design, interaction modeling, technical specification
|
||||
- **Output**: Frontend architecture documentation
|
||||
- **Integration**: Links to UX/UI specifications, implementation guidelines
|
||||
|
||||
## Templates and Resources
|
||||
|
||||
The Architect persona has access to specialized templates and resources:
|
||||
|
||||
### Architecture Template
|
||||
|
||||
A comprehensive template for documenting system architecture:
|
||||
|
||||
- System overview and context
|
||||
- Component architecture
|
||||
- Data architecture
|
||||
- Integration architecture
|
||||
- Security architecture
|
||||
- Performance considerations
|
||||
- Scalability approach
|
||||
- Technical constraints
|
||||
- Decision records
|
||||
|
||||
### Infrastructure Architecture Template
|
||||
|
||||
A specialized template for infrastructure documentation:
|
||||
|
||||
- Infrastructure overview
|
||||
- Deployment architecture
|
||||
- Scaling approach
|
||||
- Security measures
|
||||
- Monitoring and observability
|
||||
- Disaster recovery
|
||||
- Operational considerations
|
||||
- Cost optimization
|
||||
|
||||
### Frontend Architecture Template
|
||||
|
||||
A template focused on frontend technical architecture:
|
||||
|
||||
- Component structure
|
||||
- State management
|
||||
- Data flow
|
||||
- API integration
|
||||
- Performance optimization
|
||||
- Accessibility considerations
|
||||
- Browser compatibility
|
||||
- Mobile responsiveness
|
||||
|
||||
### Architecture Decision Record Template
|
||||
|
||||
A structured template for documenting architectural decisions:
|
||||
|
||||
- Decision title and context
|
||||
- Problem statement
|
||||
- Decision drivers
|
||||
- Options considered
|
||||
- Decision outcome
|
||||
- Consequences and trade-offs
|
||||
- Validation approach
|
||||
- Related decisions
|
||||
|
||||
## Quality Standards
|
||||
|
||||
The Architect persona adheres to specific quality standards:
|
||||
|
||||
### Architecture Quality Checklist
|
||||
|
||||
A comprehensive checklist for validating architecture quality:
|
||||
|
||||
- Alignment with business requirements
|
||||
- Scalability and performance considerations
|
||||
- Security by design
|
||||
- Maintainability and extensibility
|
||||
- Clear component boundaries
|
||||
- Well-defined interfaces
|
||||
- Appropriate use of patterns
|
||||
- Comprehensive documentation
|
||||
- Technical feasibility
|
||||
- Risk assessment
|
||||
|
||||
### Infrastructure Quality Checklist
|
||||
|
||||
A specialized checklist for infrastructure quality:
|
||||
|
||||
- Scalability approach
|
||||
- Redundancy and fault tolerance
|
||||
- Security measures
|
||||
- Monitoring and observability
|
||||
- Cost optimization
|
||||
- Operational efficiency
|
||||
- Disaster recovery
|
||||
- Compliance considerations
|
||||
|
||||
### Frontend Architecture Quality Checklist
|
||||
|
||||
A checklist focused on frontend architecture quality:
|
||||
|
||||
- Component reusability
|
||||
- State management approach
|
||||
- Performance optimization
|
||||
- Accessibility compliance
|
||||
- Mobile responsiveness
|
||||
- Browser compatibility
|
||||
- Testing approach
|
||||
- Documentation completeness
|
||||
|
||||
## Integration with Other Personas
|
||||
|
||||
The Architect persona collaborates closely with other BMAD personas:
|
||||
|
||||
### Product Owner (PO)
|
||||
|
||||
- Translates business requirements into technical solutions
|
||||
- Validates technical feasibility of proposed features
|
||||
- Provides technical constraints and limitations
|
||||
- Collaborates on prioritization based on technical complexity
|
||||
|
||||
### Project Manager (PM)
|
||||
|
||||
- Provides technical input for project planning
|
||||
- Estimates technical complexity and effort
|
||||
- Identifies technical dependencies and risks
|
||||
- Collaborates on resource allocation for technical tasks
|
||||
|
||||
### UX/UI Architect
|
||||
|
||||
- Aligns technical architecture with design requirements
|
||||
- Ensures technical feasibility of proposed designs
|
||||
- Collaborates on component architecture
|
||||
- Establishes technical standards for frontend implementation
|
||||
|
||||
### Developer
|
||||
|
||||
- Provides architectural guidance for implementation
|
||||
- Reviews technical approaches for alignment with architecture
|
||||
- Supports resolution of complex technical challenges
|
||||
- Validates implementation against architectural standards
|
||||
|
||||
### DevOps/Platform Engineer
|
||||
|
||||
- Collaborates on infrastructure architecture
|
||||
- Ensures operational feasibility of proposed architecture
|
||||
- Aligns deployment approach with architectural requirements
|
||||
- Validates infrastructure implementation against architecture
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Architecture Design
|
||||
|
||||
- Start with business requirements, not technical solutions
|
||||
- Design for change and evolution
|
||||
- Document architectural decisions and rationales
|
||||
- Use established patterns where appropriate
|
||||
- Consider non-functional requirements early
|
||||
|
||||
### Documentation
|
||||
|
||||
- Use visual diagrams to communicate complex concepts
|
||||
- Maintain different views for different audiences
|
||||
- Keep documentation up-to-date with implementation
|
||||
- Document assumptions and constraints
|
||||
- Use consistent terminology and notation
|
||||
|
||||
### Collaboration
|
||||
|
||||
- Involve stakeholders early in architecture design
|
||||
- Communicate technical concepts in business terms
|
||||
- Seek feedback from implementation teams
|
||||
- Be open to alternative approaches
|
||||
- Focus on outcomes, not specific technologies
|
||||
|
||||
### Evolution
|
||||
|
||||
- Plan for incremental architecture evolution
|
||||
- Manage technical debt proactively
|
||||
- Evaluate new technologies systematically
|
||||
- Document architecture versions and transitions
|
||||
- Maintain backward compatibility where possible
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Challenges
|
||||
|
||||
#### Architecture-Business Misalignment
|
||||
|
||||
- **Symptoms**: Technical solutions don't address business needs, frequent requirement changes
|
||||
- **Resolution**: Increase collaboration with Product Owner, validate architecture against business requirements
|
||||
|
||||
#### Over-Engineering
|
||||
|
||||
- **Symptoms**: Excessive complexity, delayed implementation, high costs
|
||||
- **Resolution**: Focus on current requirements with extensibility points, use iterative approach
|
||||
|
||||
#### Technical Debt Accumulation
|
||||
|
||||
- **Symptoms**: Increasing maintenance costs, decreasing velocity, quality issues
|
||||
- **Resolution**: Establish technical debt tracking, allocate time for refactoring, document trade-offs
|
||||
|
||||
#### Documentation Gaps
|
||||
|
||||
- **Symptoms**: Implementation deviations, inconsistent understanding, frequent questions
|
||||
- **Resolution**: Establish documentation standards, regular reviews, multiple documentation views
|
||||
|
||||
#### Integration Challenges
|
||||
|
||||
- **Symptoms**: Component incompatibilities, performance issues at integration points
|
||||
- **Resolution**: Define clear interfaces, establish integration testing, document integration patterns
|
||||
|
||||
### Escalation Paths
|
||||
|
||||
When architectural challenges arise, follow these escalation paths:
|
||||
|
||||
1. **Technical Clarification**: Consult architecture documentation and decision records
|
||||
2. **Peer Review**: Seek input from other technical team members
|
||||
3. **Architect Consultation**: Engage directly with the Architect persona
|
||||
4. **Cross-Functional Review**: Involve relevant stakeholders for broader perspective
|
||||
5. **Architecture Review Board**: Escalate to formal review process for significant issues
|
||||
|
||||
## Conclusion
|
||||
|
||||
The Architect persona is a critical role in the BMAD Method, providing the technical foundation that enables successful implementation of business requirements. By following the guidelines, workflows, and best practices outlined in this comprehensive guide, architects can effectively fulfill their responsibilities and contribute to the overall success of projects using the BMAD Method.
|
||||
|
||||
For more specific guidance, refer to the [Architect Integration Guide](architect-integration-guide.md) and [Architect Quickstart](architect-quickstart.md) documents.
|
||||
```
|
||||
|
|
@ -0,0 +1,519 @@
|
|||
# Architect Integration Guide
|
||||
**BMAD Method: System Architecture Persona**
|
||||
|
||||
## Introduction
|
||||
|
||||
This integration guide provides detailed instructions for incorporating the Architect persona into your BMAD Method workflow. It covers integration points, collaboration patterns, handoff procedures, and practical examples to ensure seamless incorporation of architectural expertise throughout your project lifecycle.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Integration Overview](#integration-overview)
|
||||
2. [Workflow Integration Points](#workflow-integration-points)
|
||||
3. [Collaboration Patterns](#collaboration-patterns)
|
||||
4. [Handoff Procedures](#handoff-procedures)
|
||||
5. [Input and Output Artifacts](#input-and-output-artifacts)
|
||||
6. [Integration Examples](#integration-examples)
|
||||
7. [Common Integration Challenges](#common-integration-challenges)
|
||||
8. [Integration Checklist](#integration-checklist)
|
||||
|
||||
## Integration Overview
|
||||
|
||||
The Architect persona integrates with the BMAD Method at strategic points throughout the project lifecycle, providing technical expertise, architectural guidance, and quality validation. Successful integration requires clear communication channels, well-defined handoff procedures, and collaborative workflows that leverage the Architect's specialized capabilities.
|
||||
|
||||
### Key Integration Principles
|
||||
|
||||
1. **Early Involvement**: Engage the Architect persona at the earliest stages of project planning
|
||||
2. **Continuous Collaboration**: Maintain ongoing dialogue between the Architect and other personas
|
||||
3. **Clear Deliverables**: Define specific architectural artifacts and their acceptance criteria
|
||||
4. **Feedback Loops**: Establish mechanisms for architectural validation and refinement
|
||||
5. **Knowledge Transfer**: Ensure architectural decisions and rationales are effectively communicated
|
||||
|
||||
## Workflow Integration Points
|
||||
|
||||
The Architect persona integrates with the BMAD workflow at specific points:
|
||||
|
||||
### Project Initiation
|
||||
|
||||
- **Integration Point**: Initial project scoping and requirement gathering
|
||||
- **Architect Activities**:
|
||||
- Review business requirements for technical feasibility
|
||||
- Identify technical constraints and limitations
|
||||
- Provide initial architecture vision
|
||||
- Establish technical guardrails
|
||||
- **Collaborating Personas**: Product Owner, Project Manager
|
||||
- **Artifacts**: Initial architecture vision document, technical constraints list
|
||||
|
||||
### Planning Phase
|
||||
|
||||
- **Integration Point**: Feature planning and prioritization
|
||||
- **Architect Activities**:
|
||||
- Provide technical complexity assessments
|
||||
- Identify architectural dependencies
|
||||
- Create high-level architecture diagrams
|
||||
- Establish technical standards
|
||||
- **Collaborating Personas**: Product Owner, Project Manager, UX/UI Architect
|
||||
- **Artifacts**: High-level architecture document, technical standards guide
|
||||
|
||||
### Design Phase
|
||||
|
||||
- **Integration Point**: Detailed solution design
|
||||
- **Architect Activities**:
|
||||
- Create detailed architecture documentation
|
||||
- Define component boundaries and interfaces
|
||||
- Establish data models and flows
|
||||
- Document architectural decisions
|
||||
- **Collaborating Personas**: UX/UI Architect, Developer, DevOps Engineer
|
||||
- **Artifacts**: Detailed architecture documentation, component specifications, data models
|
||||
|
||||
### Implementation Phase
|
||||
|
||||
- **Integration Point**: Development and technical review
|
||||
- **Architect Activities**:
|
||||
- Provide technical guidance to development teams
|
||||
- Review implementation for architectural alignment
|
||||
- Address complex technical challenges
|
||||
- Update architecture documentation as needed
|
||||
- **Collaborating Personas**: Developer, DevOps Engineer
|
||||
- **Artifacts**: Implementation guidelines, architecture reviews, technical solutions
|
||||
|
||||
### Validation Phase
|
||||
|
||||
- **Integration Point**: Quality assurance and testing
|
||||
- **Architect Activities**:
|
||||
- Validate implementation against architectural standards
|
||||
- Assess non-functional requirements compliance
|
||||
- Identify architectural improvements
|
||||
- Document technical debt
|
||||
- **Collaborating Personas**: Developer, DevOps Engineer, QA Engineer
|
||||
- **Artifacts**: Architecture validation reports, technical debt documentation
|
||||
|
||||
### Evolution Phase
|
||||
|
||||
- **Integration Point**: System enhancement and evolution
|
||||
- **Architect Activities**:
|
||||
- Evaluate architecture performance and scalability
|
||||
- Plan for system evolution
|
||||
- Assess new technologies
|
||||
- Update architecture to accommodate new requirements
|
||||
- **Collaborating Personas**: Product Owner, Project Manager, Developer
|
||||
- **Artifacts**: Architecture evolution plans, technology assessments
|
||||
|
||||
## Collaboration Patterns
|
||||
|
||||
Effective collaboration between the Architect and other personas is essential for successful integration:
|
||||
|
||||
### Architect + Product Owner
|
||||
|
||||
- **Collaboration Focus**: Aligning technical solutions with business requirements
|
||||
- **Communication Cadence**: Weekly alignment meetings, ad-hoc consultations
|
||||
- **Shared Artifacts**: PRD, architecture vision, technical constraints
|
||||
- **Collaboration Tools**: Requirement mapping, technical feasibility assessments
|
||||
- **Best Practices**:
|
||||
- Translate technical concepts into business terms
|
||||
- Document technical constraints and their business impacts
|
||||
- Collaborate on feature prioritization based on technical complexity
|
||||
- Maintain ongoing dialogue about technical trade-offs
|
||||
|
||||
### Architect + Project Manager
|
||||
|
||||
- **Collaboration Focus**: Technical planning and risk management
|
||||
- **Communication Cadence**: Sprint planning, bi-weekly status updates
|
||||
- **Shared Artifacts**: Project plan, technical risk register, architecture roadmap
|
||||
- **Collaboration Tools**: Technical complexity assessments, dependency mapping
|
||||
- **Best Practices**:
|
||||
- Provide accurate technical complexity estimates
|
||||
- Identify technical dependencies and risks early
|
||||
- Collaborate on resource allocation for technical tasks
|
||||
- Maintain transparency about technical challenges
|
||||
|
||||
### Architect + UX/UI Architect
|
||||
|
||||
- **Collaboration Focus**: Aligning technical and design approaches
|
||||
- **Communication Cadence**: Design review sessions, technical feasibility checks
|
||||
- **Shared Artifacts**: Design specifications, component architecture, technical constraints
|
||||
- **Collaboration Tools**: Component mapping, technical feasibility assessments
|
||||
- **Best Practices**:
|
||||
- Establish clear boundaries between design and technical concerns
|
||||
- Collaborate on component architecture and reusability
|
||||
- Validate technical feasibility of proposed designs
|
||||
- Create shared understanding of implementation constraints
|
||||
|
||||
### Architect + Developer
|
||||
|
||||
- **Collaboration Focus**: Technical implementation guidance
|
||||
- **Communication Cadence**: Implementation kickoffs, technical reviews, ad-hoc support
|
||||
- **Shared Artifacts**: Architecture documentation, implementation guidelines, code reviews
|
||||
- **Collaboration Tools**: Architecture walkthroughs, technical mentoring sessions
|
||||
- **Best Practices**:
|
||||
- Provide clear, actionable implementation guidance
|
||||
- Be available for technical consultation
|
||||
- Review implementation for architectural alignment
|
||||
- Focus on knowledge transfer and capability building
|
||||
|
||||
### Architect + DevOps Engineer
|
||||
|
||||
- **Collaboration Focus**: Infrastructure and deployment architecture
|
||||
- **Communication Cadence**: Infrastructure planning, deployment reviews
|
||||
- **Shared Artifacts**: Infrastructure architecture, deployment plans, operational requirements
|
||||
- **Collaboration Tools**: Infrastructure reviews, deployment validation
|
||||
- **Best Practices**:
|
||||
- Collaborate on infrastructure architecture design
|
||||
- Align application and infrastructure architecture
|
||||
- Establish clear operational requirements
|
||||
- Validate deployment approaches against architecture
|
||||
|
||||
## Handoff Procedures
|
||||
|
||||
Clear handoff procedures ensure smooth transitions between the Architect and other personas:
|
||||
|
||||
### Architecture Vision to Detailed Design
|
||||
|
||||
- **Handoff Trigger**: Completion of initial architecture vision
|
||||
- **Sending Persona**: Architect
|
||||
- **Receiving Personas**: UX/UI Architect, Developer
|
||||
- **Artifacts**:
|
||||
- Architecture vision document
|
||||
- Technical constraints list
|
||||
- High-level component diagram
|
||||
- Initial data model
|
||||
- **Handoff Process**:
|
||||
1. Architect prepares handoff package with all artifacts
|
||||
2. Architecture walkthrough session with receiving personas
|
||||
3. Q&A session to clarify technical approach
|
||||
4. Receiving personas acknowledge understanding
|
||||
5. Establish ongoing consultation process
|
||||
- **Validation Criteria**: Receiving personas can articulate technical approach and constraints
|
||||
|
||||
### Detailed Architecture to Implementation
|
||||
|
||||
- **Handoff Trigger**: Completion of detailed architecture documentation
|
||||
- **Sending Persona**: Architect
|
||||
- **Receiving Persona**: Developer
|
||||
- **Artifacts**:
|
||||
- Detailed architecture documentation
|
||||
- Component specifications
|
||||
- Interface definitions
|
||||
- Data models
|
||||
- Implementation guidelines
|
||||
- **Handoff Process**:
|
||||
1. Architect prepares implementation package
|
||||
2. Technical walkthrough with development team
|
||||
3. Component-level deep dives as needed
|
||||
4. Establish technical review process
|
||||
5. Define architecture compliance criteria
|
||||
- **Validation Criteria**: Developers can implement components according to architecture
|
||||
|
||||
### Implementation Review to Architecture Update
|
||||
|
||||
- **Handoff Trigger**: Significant implementation deviations or challenges
|
||||
- **Sending Persona**: Developer
|
||||
- **Receiving Persona**: Architect
|
||||
- **Artifacts**:
|
||||
- Implementation deviation report
|
||||
- Technical challenge description
|
||||
- Proposed solutions or alternatives
|
||||
- **Handoff Process**:
|
||||
1. Developer documents deviation or challenge
|
||||
2. Technical review with Architect
|
||||
3. Collaborative solution development
|
||||
4. Architecture update if needed
|
||||
5. Implementation guidance refinement
|
||||
- **Validation Criteria**: Agreed solution aligns with architectural principles
|
||||
|
||||
### Architecture Validation to Evolution Planning
|
||||
|
||||
- **Handoff Trigger**: Completion of implementation phase
|
||||
- **Sending Persona**: Architect
|
||||
- **Receiving Personas**: Product Owner, Project Manager
|
||||
- **Artifacts**:
|
||||
- Architecture validation report
|
||||
- Technical debt documentation
|
||||
- Performance assessment
|
||||
- Evolution recommendations
|
||||
- **Handoff Process**:
|
||||
1. Architect prepares validation and evolution package
|
||||
2. Review session with receiving personas
|
||||
3. Prioritization of technical improvements
|
||||
4. Integration into product roadmap
|
||||
5. Evolution planning
|
||||
- **Validation Criteria**: Technical improvements incorporated into product roadmap
|
||||
|
||||
## Input and Output Artifacts
|
||||
|
||||
The Architect persona works with specific artifacts throughout the integration process:
|
||||
|
||||
### Input Artifacts
|
||||
|
||||
- **Business Requirements Document**
|
||||
- Source: Product Owner
|
||||
- Usage: Basis for technical solution design
|
||||
- Integration Point: Project Initiation
|
||||
|
||||
- **Product Requirement Document (PRD)**
|
||||
- Source: Product Owner
|
||||
- Usage: Detailed requirements for architecture design
|
||||
- Integration Point: Planning Phase
|
||||
|
||||
- **UX/UI Specifications**
|
||||
- Source: UX/UI Architect
|
||||
- Usage: Frontend architecture alignment
|
||||
- Integration Point: Design Phase
|
||||
|
||||
- **Existing System Documentation**
|
||||
- Source: Various
|
||||
- Usage: Integration planning and compatibility assessment
|
||||
- Integration Point: Planning Phase
|
||||
|
||||
- **Non-functional Requirements**
|
||||
- Source: Product Owner, Stakeholders
|
||||
- Usage: Architecture quality attributes definition
|
||||
- Integration Point: Planning Phase
|
||||
|
||||
### Output Artifacts
|
||||
|
||||
- **Architecture Vision Document**
|
||||
- Audience: All personas
|
||||
- Content: High-level architecture approach, key decisions, constraints
|
||||
- Integration Point: Project Initiation
|
||||
|
||||
- **Technical Standards Guide**
|
||||
- Audience: Developers, DevOps Engineers
|
||||
- Content: Coding standards, patterns, practices, technology selections
|
||||
- Integration Point: Planning Phase
|
||||
|
||||
- **Detailed Architecture Documentation**
|
||||
- Audience: Developers, DevOps Engineers
|
||||
- Content: Component specifications, interfaces, data models, flows
|
||||
- Integration Point: Design Phase
|
||||
|
||||
- **Architecture Decision Records**
|
||||
- Audience: All technical personas
|
||||
- Content: Key decisions, alternatives considered, rationales
|
||||
- Integration Point: Throughout project lifecycle
|
||||
|
||||
- **Implementation Guidelines**
|
||||
- Audience: Developers
|
||||
- Content: Technical guidance for implementation
|
||||
- Integration Point: Implementation Phase
|
||||
|
||||
- **Architecture Validation Reports**
|
||||
- Audience: Product Owner, Project Manager
|
||||
- Content: Compliance assessment, technical debt, improvements
|
||||
- Integration Point: Validation Phase
|
||||
|
||||
- **Architecture Evolution Plan**
|
||||
- Audience: Product Owner, Project Manager
|
||||
- Content: Technical roadmap, improvement opportunities
|
||||
- Integration Point: Evolution Phase
|
||||
|
||||
## Integration Examples
|
||||
|
||||
### Methodology Integration
|
||||
|
||||
### Loading Architect Persona
|
||||
- Copy `bmad-agent/personas/architect.md` content into AI assistant context
|
||||
- Reference architecture task library for specific workflows
|
||||
- Use architecture templates as guidance frameworks
|
||||
- Apply quality checklists for validation
|
||||
|
||||
### Prompt Structuring Examples
|
||||
```
|
||||
"Acting as Fred the System Architect from BMAD Method, help me design the architecture for [system].
|
||||
Use the system architecture template and follow the architecture quality standards."
|
||||
```
|
||||
|
||||
### Example 1: E-commerce Platform Architecture
|
||||
|
||||
**Context**: New e-commerce platform development
|
||||
|
||||
**Integration Flow**:
|
||||
|
||||
1. **Project Initiation**
|
||||
- Product Owner provides business requirements for online store
|
||||
- Architect reviews requirements and creates initial architecture vision
|
||||
- Early identification of microservices approach for scalability
|
||||
|
||||
2. **Planning Phase**
|
||||
- Architect creates high-level architecture with service boundaries
|
||||
- Technical complexity assessment reveals payment processing as high-risk area
|
||||
- Project Manager adjusts timeline based on technical complexity
|
||||
|
||||
3. **Design Phase**
|
||||
- Detailed architecture documentation for each microservice
|
||||
- UX/UI Architect and System Architect collaborate on frontend architecture
|
||||
- Component interfaces and data models defined
|
||||
|
||||
4. **Implementation Phase**
|
||||
- Regular architecture reviews during development
|
||||
- Technical guidance for complex payment integration
|
||||
- Architecture updates based on implementation learnings
|
||||
|
||||
5. **Validation Phase**
|
||||
- Performance testing reveals scaling issues in inventory service
|
||||
- Architect provides optimization recommendations
|
||||
- Technical debt documented for future sprints
|
||||
|
||||
6. **Evolution Phase**
|
||||
- Architecture evolution plan for international expansion
|
||||
- Assessment of new technologies for recommendation engine
|
||||
- Technical roadmap aligned with product roadmap
|
||||
|
||||
**Key Integration Artifacts**:
|
||||
- E-commerce Architecture Vision
|
||||
- Microservice Boundaries Document
|
||||
- Service Interface Specifications
|
||||
- Data Model Documentation
|
||||
- Performance Optimization Plan
|
||||
|
||||
### Example 2: Legacy System Modernization
|
||||
|
||||
**Context**: Modernization of legacy inventory management system
|
||||
|
||||
**Integration Flow**:
|
||||
|
||||
1. **Project Initiation**
|
||||
- Architect assesses existing system architecture
|
||||
- Technical constraints identified due to legacy integrations
|
||||
- Modernization approach defined with Product Owner
|
||||
|
||||
2. **Planning Phase**
|
||||
- Phased modernization architecture created
|
||||
- Technical risk assessment for data migration
|
||||
- Project Manager creates phased implementation plan
|
||||
|
||||
3. **Design Phase**
|
||||
- Detailed architecture for new system components
|
||||
- Interface designs for legacy system integration
|
||||
- Data migration strategy and models
|
||||
|
||||
4. **Implementation Phase**
|
||||
- Technical guidance for legacy integration
|
||||
- Architecture reviews for new components
|
||||
- Adaptation for unexpected legacy system constraints
|
||||
|
||||
5. **Validation Phase**
|
||||
- Integration testing reveals performance bottlenecks
|
||||
- Architecture adjustments for performance optimization
|
||||
- Technical debt documentation for phase 2
|
||||
|
||||
6. **Evolution Phase**
|
||||
- Architecture roadmap for complete legacy replacement
|
||||
- Technology recommendations for future phases
|
||||
- Technical strategy aligned with business modernization goals
|
||||
|
||||
**Key Integration Artifacts**:
|
||||
- Legacy System Assessment
|
||||
- Modernization Architecture Vision
|
||||
- Integration Interface Specifications
|
||||
- Data Migration Strategy
|
||||
- Technical Evolution Roadmap
|
||||
|
||||
## Common Integration Challenges
|
||||
|
||||
### Challenge 1: Business-Technical Alignment
|
||||
|
||||
- **Symptoms**: Architectural solutions don't address business needs, frequent requirement changes
|
||||
- **Root Causes**: Insufficient collaboration between Architect and Product Owner, unclear business requirements
|
||||
- **Resolution Strategies**:
|
||||
- Establish regular alignment sessions
|
||||
- Create shared understanding of business goals
|
||||
- Document business drivers for architectural decisions
|
||||
- Validate architecture against business requirements
|
||||
|
||||
### Challenge 2: Design-Architecture Misalignment
|
||||
|
||||
- **Symptoms**: UX/UI designs that are technically challenging to implement, frequent design revisions
|
||||
- **Root Causes**: Late involvement of Architect in design process, insufficient collaboration
|
||||
- **Resolution Strategies**:
|
||||
- Involve Architect early in design process
|
||||
- Establish technical feasibility reviews
|
||||
- Create shared component library
|
||||
- Document technical constraints for design team
|
||||
|
||||
### Challenge 3: Architecture Compliance
|
||||
|
||||
- **Symptoms**: Implementation deviates from architecture, inconsistent technical approaches
|
||||
- **Root Causes**: Insufficient architecture communication, lack of compliance validation
|
||||
- **Resolution Strategies**:
|
||||
- Create clear, accessible architecture documentation
|
||||
- Establish regular architecture reviews
|
||||
- Provide implementation examples
|
||||
- Create architecture compliance checklist
|
||||
|
||||
### Challenge 4: Technical Debt Management
|
||||
|
||||
- **Symptoms**: Accumulating technical debt, decreasing development velocity
|
||||
- **Root Causes**: Pressure to deliver features, insufficient technical debt tracking
|
||||
- **Resolution Strategies**:
|
||||
- Establish technical debt tracking process
|
||||
- Include technical debt in product backlog
|
||||
- Create technical debt reduction plan
|
||||
- Educate stakeholders on technical debt impacts
|
||||
|
||||
### Challenge 5: Knowledge Transfer
|
||||
|
||||
- **Symptoms**: Development team struggles to implement architecture, frequent technical questions
|
||||
- **Root Causes**: Complex architecture documentation, insufficient knowledge sharing
|
||||
- **Resolution Strategies**:
|
||||
- Create multiple views of architecture documentation
|
||||
- Conduct architecture walkthrough sessions
|
||||
- Provide implementation examples
|
||||
- Establish mentoring relationships
|
||||
|
||||
## Integration Checklist
|
||||
|
||||
Use this checklist to ensure successful integration of the Architect persona:
|
||||
|
||||
### Project Initiation Integration
|
||||
|
||||
- [ ] Architect involved in initial project scoping
|
||||
- [ ] Business requirements reviewed for technical feasibility
|
||||
- [ ] Initial architecture vision created
|
||||
- [ ] Technical constraints and limitations documented
|
||||
- [ ] Architecture vision shared with all stakeholders
|
||||
|
||||
### Planning Phase Integration
|
||||
|
||||
- [ ] Architect involved in feature planning
|
||||
- [ ] Technical complexity assessments provided
|
||||
- [ ] High-level architecture diagrams created
|
||||
- [ ] Technical standards established
|
||||
- [ ] Architecture approach aligned with business goals
|
||||
|
||||
### Design Phase Integration
|
||||
|
||||
- [ ] Detailed architecture documentation created
|
||||
- [ ] Component boundaries and interfaces defined
|
||||
- [ ] Data models and flows established
|
||||
- [ ] Architectural decisions documented
|
||||
- [ ] Architecture reviewed with implementation teams
|
||||
|
||||
### Implementation Phase Integration
|
||||
|
||||
- [ ] Regular architecture guidance provided
|
||||
- [ ] Implementation reviewed for architectural alignment
|
||||
- [ ] Technical challenges addressed collaboratively
|
||||
- [ ] Architecture documentation updated as needed
|
||||
- [ ] Knowledge transfer sessions conducted
|
||||
|
||||
### Validation Phase Integration
|
||||
|
||||
- [ ] Implementation validated against architecture
|
||||
- [ ] Non-functional requirements compliance assessed
|
||||
- [ ] Technical debt documented
|
||||
- [ ] Architecture improvements identified
|
||||
- [ ] Validation results shared with stakeholders
|
||||
|
||||
### Evolution Phase Integration
|
||||
|
||||
- [ ] Architecture performance and scalability evaluated
|
||||
- [ ] System evolution plan created
|
||||
- [ ] New technologies assessed
|
||||
- [ ] Architecture updated for new requirements
|
||||
- [ ] Technical roadmap aligned with product roadmap
|
||||
|
||||
## Conclusion
|
||||
|
||||
Successful integration of the Architect persona into the BMAD Method workflow requires intentional collaboration, clear communication, and well-defined processes. By following the guidelines in this integration guide, teams can effectively leverage architectural expertise throughout the project lifecycle, resulting in technically sound solutions that meet business requirements.
|
||||
|
||||
For more detailed information about the Architect persona, refer to the [Architect Comprehensive Guide](architect-comprehensive-guide.md) and [Architect Quickstart](architect-quickstart.md) documents.
|
||||
|
|
@ -0,0 +1,676 @@
|
|||
# Architect Quality Standards
|
||||
**BMAD Method: System Architecture Persona**
|
||||
|
||||
## Introduction
|
||||
|
||||
The Architect Quality Standards define the quality criteria, standards, and best practices that the Architect persona must adhere to within the BMAD Method. These standards ensure consistency, quality, and effectiveness of architectural work across projects and teams, while supporting the overall goals of the BMAD methodology.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Quality Framework](#quality-framework)
|
||||
2. [Architecture Documentation Standards](#architecture-documentation-standards)
|
||||
3. [Design Quality Standards](#design-quality-standards)
|
||||
4. [Technical Standards](#technical-standards)
|
||||
5. [Process Quality Standards](#process-quality-standards)
|
||||
6. [Collaboration Standards](#collaboration-standards)
|
||||
7. [Quality Assurance Procedures](#quality-assurance-procedures)
|
||||
8. [Continuous Improvement](#continuous-improvement)
|
||||
|
||||
## Quality Framework
|
||||
|
||||
The Architect Quality Framework is built on four foundational pillars:
|
||||
|
||||
### 1. Technical Excellence
|
||||
- Architectural solutions meet functional and non-functional requirements
|
||||
- Designs follow established architectural principles and patterns
|
||||
- Technology selections are appropriate and well-justified
|
||||
- Technical debt is minimized and managed effectively
|
||||
|
||||
### 2. Communication Effectiveness
|
||||
- Architecture is clearly documented and communicated
|
||||
- Stakeholders understand architectural decisions and implications
|
||||
- Documentation is accessible and maintainable
|
||||
- Knowledge transfer is effective and comprehensive
|
||||
|
||||
### 3. Collaboration Quality
|
||||
- Effective integration with other BMAD personas
|
||||
- Stakeholder needs are understood and addressed
|
||||
- Feedback is actively sought and incorporated
|
||||
- Conflicts are resolved constructively
|
||||
|
||||
### 4. Continuous Value Delivery
|
||||
- Architecture supports business objectives
|
||||
- Solutions are delivered incrementally with measurable value
|
||||
- Architecture evolves to meet changing requirements
|
||||
- Lessons learned are captured and applied
|
||||
|
||||
## Architecture Documentation Standards
|
||||
|
||||
### Documentation Completeness
|
||||
|
||||
**Standard**: All architecture documentation must be complete, accurate, and current.
|
||||
|
||||
**Requirements**:
|
||||
- All required sections of architecture templates are completed
|
||||
- Documentation covers all system components and interactions
|
||||
- Architectural decisions are documented with rationales
|
||||
- Documentation is updated to reflect implementation changes
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ All template sections are addressed
|
||||
- ✅ No critical information gaps exist
|
||||
- ✅ Documentation reflects current system state
|
||||
- ✅ Stakeholder information needs are met
|
||||
|
||||
**Validation Methods**:
|
||||
- Documentation completeness checklist
|
||||
- Stakeholder review and feedback
|
||||
- Gap analysis against requirements
|
||||
- Regular documentation audits
|
||||
|
||||
### Documentation Clarity
|
||||
|
||||
**Standard**: Architecture documentation must be clear, understandable, and accessible to its intended audience.
|
||||
|
||||
**Requirements**:
|
||||
- Use clear, concise language appropriate for the audience
|
||||
- Include visual diagrams to illustrate complex concepts
|
||||
- Provide examples and use cases where helpful
|
||||
- Organize information logically and consistently
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Technical concepts are explained clearly
|
||||
- ✅ Visual diagrams support textual descriptions
|
||||
- ✅ Examples illustrate key concepts effectively
|
||||
- ✅ Information is organized logically
|
||||
|
||||
**Validation Methods**:
|
||||
- Readability assessment
|
||||
- Stakeholder comprehension testing
|
||||
- Peer review for clarity
|
||||
- Documentation usability testing
|
||||
|
||||
### Documentation Consistency
|
||||
|
||||
**Standard**: Architecture documentation must be consistent in format, terminology, and approach across projects.
|
||||
|
||||
**Requirements**:
|
||||
- Use standardized templates and formats
|
||||
- Apply consistent terminology and notation
|
||||
- Follow organizational documentation standards
|
||||
- Maintain consistency with related documentation
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Templates are used correctly and completely
|
||||
- ✅ Terminology is consistent throughout
|
||||
- ✅ Notation and diagramming standards are followed
|
||||
- ✅ Cross-references are accurate and current
|
||||
|
||||
**Validation Methods**:
|
||||
- Template compliance checking
|
||||
- Terminology consistency review
|
||||
- Cross-reference validation
|
||||
- Standards compliance audit
|
||||
|
||||
### Documentation Traceability
|
||||
|
||||
**Standard**: Architecture documentation must maintain clear traceability to requirements, decisions, and implementation.
|
||||
|
||||
**Requirements**:
|
||||
- Link architectural elements to business requirements
|
||||
- Trace design decisions to their rationales
|
||||
- Connect architecture to implementation artifacts
|
||||
- Maintain version history and change tracking
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Requirements traceability is maintained
|
||||
- ✅ Decision rationales are documented
|
||||
- ✅ Implementation links are current
|
||||
- ✅ Change history is tracked
|
||||
|
||||
**Validation Methods**:
|
||||
- Traceability matrix validation
|
||||
- Requirements coverage analysis
|
||||
- Decision audit trail review
|
||||
- Change impact assessment
|
||||
|
||||
## Design Quality Standards
|
||||
|
||||
### Architectural Principles Adherence
|
||||
|
||||
**Standard**: All architectural designs must adhere to established architectural principles and best practices.
|
||||
|
||||
**Requirements**:
|
||||
- Follow SOLID principles for component design
|
||||
- Apply appropriate architectural patterns
|
||||
- Ensure separation of concerns
|
||||
- Maintain loose coupling and high cohesion
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Components have single, well-defined responsibilities
|
||||
- ✅ Dependencies are minimized and well-managed
|
||||
- ✅ Interfaces are clean and stable
|
||||
- ✅ Patterns are applied appropriately
|
||||
|
||||
**Validation Methods**:
|
||||
- Architectural principle compliance review
|
||||
- Design pattern analysis
|
||||
- Dependency analysis
|
||||
- Interface quality assessment
|
||||
|
||||
### Quality Attributes Implementation
|
||||
|
||||
**Standard**: Architectural designs must explicitly address all required quality attributes.
|
||||
|
||||
**Requirements**:
|
||||
- Identify and prioritize quality attributes
|
||||
- Design specific mechanisms to achieve quality attributes
|
||||
- Validate quality attribute achievement
|
||||
- Document quality attribute trade-offs
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ All quality attributes are explicitly addressed
|
||||
- ✅ Quality mechanisms are appropriate and effective
|
||||
- ✅ Trade-offs are documented and justified
|
||||
- ✅ Quality targets are measurable and testable
|
||||
|
||||
**Validation Methods**:
|
||||
- Quality attribute scenario analysis
|
||||
- Architecture evaluation methods (ATAM, etc.)
|
||||
- Performance modeling and testing
|
||||
- Quality attribute achievement validation
|
||||
|
||||
### Scalability and Performance Design
|
||||
|
||||
**Standard**: Architectural designs must support required scalability and performance characteristics.
|
||||
|
||||
**Requirements**:
|
||||
- Design for expected load and growth patterns
|
||||
- Implement appropriate caching strategies
|
||||
- Design efficient data access patterns
|
||||
- Plan for horizontal and vertical scaling
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Scalability approach is clearly defined
|
||||
- ✅ Performance targets are specified and achievable
|
||||
- ✅ Bottlenecks are identified and addressed
|
||||
- ✅ Scaling mechanisms are implemented
|
||||
|
||||
**Validation Methods**:
|
||||
- Performance modeling and simulation
|
||||
- Load testing and capacity planning
|
||||
- Scalability testing
|
||||
- Performance monitoring and analysis
|
||||
|
||||
### Security by Design
|
||||
|
||||
**Standard**: Security must be designed into the architecture from the beginning, not added as an afterthought.
|
||||
|
||||
**Requirements**:
|
||||
- Implement defense in depth
|
||||
- Follow principle of least privilege
|
||||
- Design secure communication channels
|
||||
- Plan for security monitoring and incident response
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Security controls are layered and comprehensive
|
||||
- ✅ Access controls are appropriate and enforced
|
||||
- ✅ Data protection mechanisms are implemented
|
||||
- ✅ Security monitoring is designed in
|
||||
|
||||
**Validation Methods**:
|
||||
- Security architecture review
|
||||
- Threat modeling and analysis
|
||||
- Security testing and validation
|
||||
- Compliance assessment
|
||||
|
||||
## Technical Standards
|
||||
|
||||
### Technology Selection Standards
|
||||
|
||||
**Standard**: Technology selections must be appropriate, well-justified, and aligned with organizational strategy.
|
||||
|
||||
**Requirements**:
|
||||
- Evaluate technologies against defined criteria
|
||||
- Consider long-term support and evolution
|
||||
- Assess organizational capabilities and constraints
|
||||
- Document selection rationale and alternatives
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Technology evaluation is comprehensive
|
||||
- ✅ Selection criteria are appropriate and applied
|
||||
- ✅ Organizational fit is assessed
|
||||
- ✅ Rationale is documented and justified
|
||||
|
||||
**Validation Methods**:
|
||||
- Technology evaluation review
|
||||
- Proof of concept validation
|
||||
- Organizational readiness assessment
|
||||
- Technology roadmap alignment check
|
||||
|
||||
### Integration Standards
|
||||
|
||||
**Standard**: System integrations must follow established patterns and standards to ensure reliability and maintainability.
|
||||
|
||||
**Requirements**:
|
||||
- Use appropriate integration patterns
|
||||
- Implement proper error handling and resilience
|
||||
- Design for monitoring and observability
|
||||
- Follow API design standards
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Integration patterns are appropriate for use cases
|
||||
- ✅ Error handling is comprehensive and tested
|
||||
- ✅ Monitoring and logging are implemented
|
||||
- ✅ API standards are followed
|
||||
|
||||
**Validation Methods**:
|
||||
- Integration pattern review
|
||||
- Error handling testing
|
||||
- Monitoring effectiveness assessment
|
||||
- API standards compliance check
|
||||
|
||||
### Code Quality Standards
|
||||
|
||||
**Standard**: Architectural guidance must promote high code quality and maintainability.
|
||||
|
||||
**Requirements**:
|
||||
- Define clear coding standards and practices
|
||||
- Establish code review processes
|
||||
- Implement automated quality checks
|
||||
- Provide clear implementation guidelines
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Coding standards are comprehensive and clear
|
||||
- ✅ Quality checks are automated where possible
|
||||
- ✅ Implementation guidelines are actionable
|
||||
- ✅ Code quality metrics are tracked
|
||||
|
||||
**Validation Methods**:
|
||||
- Code quality metrics analysis
|
||||
- Code review process assessment
|
||||
- Implementation guideline effectiveness review
|
||||
- Developer feedback collection
|
||||
|
||||
## Process Quality Standards
|
||||
|
||||
### Requirements Analysis Standards
|
||||
|
||||
**Standard**: Architectural work must be based on thorough understanding and analysis of requirements.
|
||||
|
||||
**Requirements**:
|
||||
- Engage with stakeholders to understand needs
|
||||
- Analyze functional and non-functional requirements
|
||||
- Identify constraints and assumptions
|
||||
- Validate requirements understanding
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Stakeholder needs are understood and documented
|
||||
- ✅ Requirements analysis is comprehensive
|
||||
- ✅ Constraints and assumptions are identified
|
||||
- ✅ Requirements understanding is validated
|
||||
|
||||
**Validation Methods**:
|
||||
- Stakeholder interview assessment
|
||||
- Requirements coverage analysis
|
||||
- Constraint validation
|
||||
- Requirements review sessions
|
||||
|
||||
### Design Process Standards
|
||||
|
||||
**Standard**: Architectural design must follow a systematic, repeatable process that ensures quality outcomes.
|
||||
|
||||
**Requirements**:
|
||||
- Follow established design methodology
|
||||
- Document design decisions and rationales
|
||||
- Validate designs against requirements
|
||||
- Iterate based on feedback and learning
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Design process is systematic and repeatable
|
||||
- ✅ Design decisions are documented
|
||||
- ✅ Validation is performed against requirements
|
||||
- ✅ Feedback is incorporated effectively
|
||||
|
||||
**Validation Methods**:
|
||||
- Design process assessment
|
||||
- Decision documentation review
|
||||
- Validation effectiveness analysis
|
||||
- Feedback incorporation tracking
|
||||
|
||||
### Review and Validation Standards
|
||||
|
||||
**Standard**: All architectural work must undergo appropriate review and validation before implementation.
|
||||
|
||||
**Requirements**:
|
||||
- Conduct peer reviews of architectural designs
|
||||
- Validate designs with stakeholders
|
||||
- Perform technical feasibility assessments
|
||||
- Document review findings and actions
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Reviews are conducted by qualified reviewers
|
||||
- ✅ Stakeholder validation is comprehensive
|
||||
- ✅ Technical feasibility is assessed
|
||||
- ✅ Review findings are addressed
|
||||
|
||||
**Validation Methods**:
|
||||
- Review process effectiveness assessment
|
||||
- Reviewer qualification validation
|
||||
- Stakeholder satisfaction measurement
|
||||
- Action item completion tracking
|
||||
|
||||
## Collaboration Standards
|
||||
|
||||
### Stakeholder Engagement Standards
|
||||
|
||||
**Standard**: Architects must effectively engage with all relevant stakeholders throughout the project lifecycle.
|
||||
|
||||
**Requirements**:
|
||||
- Identify and engage all relevant stakeholders
|
||||
- Communicate in terms appropriate for each audience
|
||||
- Seek feedback and incorporate input
|
||||
- Maintain ongoing stakeholder relationships
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ All relevant stakeholders are identified and engaged
|
||||
- ✅ Communication is effective and appropriate
|
||||
- ✅ Feedback is actively sought and incorporated
|
||||
- ✅ Stakeholder relationships are maintained
|
||||
|
||||
**Validation Methods**:
|
||||
- Stakeholder satisfaction surveys
|
||||
- Communication effectiveness assessment
|
||||
- Feedback incorporation tracking
|
||||
- Relationship quality evaluation
|
||||
|
||||
### Cross-Persona Collaboration Standards
|
||||
|
||||
**Standard**: Architects must collaborate effectively with other BMAD personas to ensure integrated solutions.
|
||||
|
||||
**Requirements**:
|
||||
- Understand other personas' roles and responsibilities
|
||||
- Establish clear communication channels
|
||||
- Coordinate work and deliverables
|
||||
- Resolve conflicts constructively
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Persona roles and responsibilities are understood
|
||||
- ✅ Communication channels are effective
|
||||
- ✅ Work coordination is smooth
|
||||
- ✅ Conflicts are resolved constructively
|
||||
|
||||
**Validation Methods**:
|
||||
- Collaboration effectiveness assessment
|
||||
- Communication channel evaluation
|
||||
- Coordination quality measurement
|
||||
- Conflict resolution tracking
|
||||
|
||||
### Knowledge Sharing Standards
|
||||
|
||||
**Standard**: Architects must effectively share knowledge and expertise with team members and stakeholders.
|
||||
|
||||
**Requirements**:
|
||||
- Document architectural knowledge and decisions
|
||||
- Conduct knowledge transfer sessions
|
||||
- Mentor team members on architectural concepts
|
||||
- Contribute to organizational knowledge base
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Knowledge is documented and accessible
|
||||
- ✅ Knowledge transfer is effective
|
||||
- ✅ Mentoring is provided as needed
|
||||
- ✅ Organizational knowledge is enhanced
|
||||
|
||||
**Validation Methods**:
|
||||
- Knowledge documentation assessment
|
||||
- Knowledge transfer effectiveness evaluation
|
||||
- Mentoring impact measurement
|
||||
- Knowledge base contribution tracking
|
||||
|
||||
## Quality Assurance Procedures
|
||||
|
||||
### Self-Assessment Procedures
|
||||
|
||||
**Standard**: Architects must regularly assess their own work quality and seek improvement opportunities.
|
||||
|
||||
**Procedures**:
|
||||
1. **Daily Quality Checks**
|
||||
- Review work against quality criteria
|
||||
- Identify potential quality issues
|
||||
- Take corrective action as needed
|
||||
- Document lessons learned
|
||||
|
||||
2. **Weekly Quality Reviews**
|
||||
- Assess progress against quality standards
|
||||
- Review stakeholder feedback
|
||||
- Identify improvement opportunities
|
||||
- Plan quality improvement actions
|
||||
|
||||
3. **Monthly Quality Assessments**
|
||||
- Conduct comprehensive quality review
|
||||
- Analyze quality metrics and trends
|
||||
- Update quality improvement plans
|
||||
- Share lessons learned with team
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Self-assessment is performed regularly
|
||||
- ✅ Quality issues are identified and addressed
|
||||
- ✅ Improvement opportunities are pursued
|
||||
- ✅ Lessons learned are documented and shared
|
||||
|
||||
### Peer Review Procedures
|
||||
|
||||
**Standard**: All significant architectural work must undergo peer review by qualified architects.
|
||||
|
||||
**Procedures**:
|
||||
1. **Review Planning**
|
||||
- Identify appropriate reviewers
|
||||
- Define review scope and objectives
|
||||
- Schedule review sessions
|
||||
- Prepare review materials
|
||||
|
||||
2. **Review Execution**
|
||||
- Conduct systematic review of work
|
||||
- Document findings and recommendations
|
||||
- Discuss findings with architect
|
||||
- Agree on action items and timeline
|
||||
|
||||
3. **Review Follow-up**
|
||||
- Track action item completion
|
||||
- Validate corrective actions
|
||||
- Update documentation as needed
|
||||
- Document review outcomes
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Reviews are conducted by qualified peers
|
||||
- ✅ Review process is systematic and thorough
|
||||
- ✅ Findings are documented and addressed
|
||||
- ✅ Follow-up ensures completion
|
||||
|
||||
### Stakeholder Validation Procedures
|
||||
|
||||
**Standard**: Architectural work must be validated with relevant stakeholders to ensure it meets their needs.
|
||||
|
||||
**Procedures**:
|
||||
1. **Validation Planning**
|
||||
- Identify stakeholders for validation
|
||||
- Define validation objectives and criteria
|
||||
- Schedule validation sessions
|
||||
- Prepare validation materials
|
||||
|
||||
2. **Validation Execution**
|
||||
- Present architectural work to stakeholders
|
||||
- Gather feedback and input
|
||||
- Document stakeholder concerns
|
||||
- Agree on changes and improvements
|
||||
|
||||
3. **Validation Follow-up**
|
||||
- Implement agreed changes
|
||||
- Validate changes with stakeholders
|
||||
- Update documentation
|
||||
- Document validation outcomes
|
||||
|
||||
**Quality Criteria**:
|
||||
- ✅ Appropriate stakeholders are involved
|
||||
- ✅ Validation process is comprehensive
|
||||
- ✅ Feedback is gathered and addressed
|
||||
- ✅ Changes are validated and documented
|
||||
|
||||
## Continuous Improvement
|
||||
|
||||
### Quality Metrics and Measurement
|
||||
|
||||
**Standard**: Quality must be measured and tracked to enable continuous improvement.
|
||||
|
||||
**Key Metrics**:
|
||||
- Documentation completeness and quality
|
||||
- Stakeholder satisfaction with architectural work
|
||||
- Architecture review findings and resolution
|
||||
- Technical debt accumulation and reduction
|
||||
- Architecture implementation success rate
|
||||
|
||||
**Measurement Procedures**:
|
||||
1. **Metric Collection**
|
||||
- Collect metrics regularly and consistently
|
||||
- Use automated tools where possible
|
||||
- Ensure metric accuracy and reliability
|
||||
- Store metrics for trend analysis
|
||||
|
||||
2. **Metric Analysis**
|
||||
- Analyze trends and patterns
|
||||
- Identify improvement opportunities
|
||||
- Compare against benchmarks and targets
|
||||
- Generate insights and recommendations
|
||||
|
||||
3. **Metric Reporting**
|
||||
- Create regular quality reports
|
||||
- Share findings with stakeholders
|
||||
- Highlight successes and challenges
|
||||
- Recommend improvement actions
|
||||
|
||||
### Process Improvement
|
||||
|
||||
**Standard**: Quality processes must be continuously improved based on experience and feedback.
|
||||
|
||||
**Improvement Procedures**:
|
||||
1. **Process Assessment**
|
||||
- Regularly assess process effectiveness
|
||||
- Gather feedback from participants
|
||||
- Identify process bottlenecks and issues
|
||||
- Benchmark against best practices
|
||||
|
||||
2. **Improvement Planning**
|
||||
- Prioritize improvement opportunities
|
||||
- Design process improvements
|
||||
- Plan implementation approach
|
||||
- Define success criteria
|
||||
|
||||
3. **Improvement Implementation**
|
||||
- Implement process changes
|
||||
- Train team members on changes
|
||||
- Monitor implementation effectiveness
|
||||
- Adjust as needed based on feedback
|
||||
|
||||
4. **Improvement Validation**
|
||||
- Measure improvement effectiveness
|
||||
- Gather feedback on changes
|
||||
- Document lessons learned
|
||||
- Share successful improvements
|
||||
|
||||
### Knowledge Management
|
||||
|
||||
**Standard**: Quality-related knowledge and lessons learned must be captured and shared to benefit the organization.
|
||||
|
||||
**Knowledge Management Procedures**:
|
||||
1. **Knowledge Capture**
|
||||
- Document quality lessons learned
|
||||
- Capture best practices and patterns
|
||||
- Record common quality issues and solutions
|
||||
- Create quality knowledge artifacts
|
||||
|
||||
2. **Knowledge Organization**
|
||||
- Organize knowledge by topic and relevance
|
||||
- Create searchable knowledge repositories
|
||||
- Establish knowledge categorization schemes
|
||||
- Maintain knowledge currency and accuracy
|
||||
|
||||
3. **Knowledge Sharing**
|
||||
- Share knowledge through training and mentoring
|
||||
- Create knowledge sharing sessions
|
||||
- Contribute to organizational knowledge base
|
||||
- Participate in communities of practice
|
||||
|
||||
4. **Knowledge Application**
|
||||
- Apply lessons learned to current work
|
||||
- Use best practices and patterns
|
||||
- Avoid repeating past mistakes
|
||||
- Continuously improve based on knowledge
|
||||
|
||||
## Quality Standards Compliance
|
||||
|
||||
### Compliance Monitoring
|
||||
|
||||
**Standard**: Compliance with quality standards must be monitored and enforced consistently.
|
||||
|
||||
**Monitoring Procedures**:
|
||||
- Regular quality audits and assessments
|
||||
- Automated compliance checking where possible
|
||||
- Peer review and validation processes
|
||||
- Stakeholder feedback collection
|
||||
- Quality metrics tracking and analysis
|
||||
|
||||
### Non-Compliance Handling
|
||||
|
||||
**Standard**: Non-compliance with quality standards must be addressed promptly and effectively.
|
||||
|
||||
**Handling Procedures**:
|
||||
1. **Issue Identification**
|
||||
- Identify non-compliance through monitoring
|
||||
- Document specific compliance gaps
|
||||
- Assess impact and severity
|
||||
- Notify relevant stakeholders
|
||||
|
||||
2. **Corrective Action**
|
||||
- Develop corrective action plan
|
||||
- Implement necessary changes
|
||||
- Validate corrective actions
|
||||
- Update documentation as needed
|
||||
|
||||
3. **Prevention**
|
||||
- Identify root causes of non-compliance
|
||||
- Implement preventive measures
|
||||
- Update processes and training
|
||||
- Monitor for recurrence
|
||||
|
||||
### Standards Evolution
|
||||
|
||||
**Standard**: Quality standards must evolve to reflect changing needs, technologies, and best practices.
|
||||
|
||||
**Evolution Procedures**:
|
||||
1. **Standards Review**
|
||||
- Regularly review standards for relevance
|
||||
- Gather feedback on standards effectiveness
|
||||
- Identify improvement opportunities
|
||||
- Benchmark against industry standards
|
||||
|
||||
2. **Standards Update**
|
||||
- Update standards based on review findings
|
||||
- Incorporate new best practices and technologies
|
||||
- Align with organizational changes
|
||||
- Validate updates with stakeholders
|
||||
|
||||
3. **Standards Communication**
|
||||
- Communicate standards changes to all users
|
||||
- Provide training on updated standards
|
||||
- Update related documentation and tools
|
||||
- Monitor adoption of updated standards
|
||||
|
||||
## Conclusion
|
||||
|
||||
The Architect Quality Standards provide a comprehensive framework for ensuring the quality and effectiveness of architectural work within the BMAD Method. By adhering to these standards, architects can deliver high-quality solutions that meet stakeholder needs, support business objectives, and enable long-term success.
|
||||
|
||||
These standards should be viewed as living documents that evolve based on experience, feedback, and changing requirements. Regular review and improvement of these standards ensures they continue to provide value and support the goals of the BMAD Method.
|
||||
|
||||
For more information about the Architect persona, refer to the [Architect Comprehensive Guide](architect-comprehensive-guide.md) and [Architect Integration Guide](architect-integration-guide.md) documents.
|
||||
```
|
||||
|
|
@ -0,0 +1,281 @@
|
|||
# System Architect (Fred) Quick Start Guide
|
||||
|
||||
Get up and running with Fred, the System Architect persona, in just 5 minutes. This guide provides everything you need to start designing robust, scalable system architectures.
|
||||
|
||||
## 1. Choose Your Environment
|
||||
|
||||
Fred can be used in two environments:
|
||||
|
||||
### Web Environment (Fred)
|
||||
- Use with ChatGPT, Claude, or other web-based AI platforms
|
||||
- Ideal for architectural planning and system design
|
||||
- No setup required
|
||||
|
||||
### IDE Environment (Fred)
|
||||
- Use with Cursor AI, Claude Code, Cline, or Roocode
|
||||
- Ideal for implementation-focused architectural guidance
|
||||
- Requires minimal setup
|
||||
|
||||
## 2. Activate the Persona
|
||||
|
||||
### Web Environment
|
||||
1. Copy the contents of `bmad-agent/personas/architect.md`
|
||||
2. Paste as your first message to the AI
|
||||
3. Use an activation phrase: "I need Fred to help design the system architecture"
|
||||
|
||||
### IDE Environment
|
||||
1. Copy the `bmad-agent` folder to your project root
|
||||
2. Reference the persona file in your IDE's AI feature
|
||||
3. Use an activation phrase: "Fred, help me architect this system"
|
||||
|
||||
## 3. Provide Clear Requirements
|
||||
|
||||
For best architectural guidance, include:
|
||||
|
||||
- **Project Overview**: What you're building and why
|
||||
- **Functional Requirements**: Key features and capabilities
|
||||
- **Non-Functional Requirements**: Performance, scalability, security needs
|
||||
- **Technical Constraints**: Existing systems, technology preferences, budget
|
||||
- **Quality Attributes**: Availability, reliability, maintainability targets
|
||||
|
||||
### Example Prompt
|
||||
|
||||
```
|
||||
Fred, I need to design the architecture for a real-time chat application with the following requirements:
|
||||
|
||||
Functional Requirements:
|
||||
- Support 1-on-1 and group messaging
|
||||
- File sharing and media uploads
|
||||
- User presence indicators
|
||||
- Message history and search
|
||||
|
||||
Non-Functional Requirements:
|
||||
- Support 50,000 concurrent users
|
||||
- Messages delivered within 100ms
|
||||
- 99.9% uptime requirement
|
||||
- End-to-end encryption for security
|
||||
|
||||
Technical Constraints:
|
||||
- Team experienced with Node.js and React
|
||||
- Prefer cloud-native solutions
|
||||
- Budget allows for managed services
|
||||
- Must integrate with existing user authentication system
|
||||
|
||||
Quality Attributes:
|
||||
- High scalability and performance
|
||||
- Strong security and privacy
|
||||
- Easy to maintain and extend
|
||||
```
|
||||
|
||||
## 4. Review and Iterate
|
||||
|
||||
1. Review Fred's initial architectural recommendations
|
||||
2. Ask clarifying questions about specific components
|
||||
3. Request alternatives for different trade-offs
|
||||
4. Validate against your requirements and constraints
|
||||
|
||||
## 5. Implement and Validate
|
||||
|
||||
1. Use the architectural documentation for implementation planning
|
||||
2. Share with your development team
|
||||
3. Validate architectural decisions during implementation
|
||||
4. Iterate based on real-world feedback
|
||||
|
||||
## Example: Designing a Microservices Architecture
|
||||
|
||||
### Step 1: Activate Fred
|
||||
|
||||
"I need Fred to help design a microservices architecture for an e-commerce platform."
|
||||
|
||||
### Step 2: Provide Requirements
|
||||
|
||||
"We need to build a scalable e-commerce platform with user management, product catalog, shopping cart, order processing, and payment handling. It should support 10,000+ concurrent users, integrate with multiple payment gateways, and maintain 99.9% uptime."
|
||||
|
||||
### Step 3: Review Initial Architecture
|
||||
|
||||
Fred will provide a comprehensive architectural design including:
|
||||
|
||||
- **Service Boundaries**: User Service, Product Service, Cart Service, Order Service, Payment Service
|
||||
- **Communication Patterns**: REST APIs for synchronous communication, message queues for async processing
|
||||
- **Data Strategy**: Database per service pattern with eventual consistency
|
||||
- **Security Architecture**: API Gateway with JWT authentication, service-to-service encryption
|
||||
- **Scalability Patterns**: Auto-scaling groups, load balancers, caching layers
|
||||
|
||||
### Step 4: Refine the Design
|
||||
|
||||
"Fred, how would you handle inventory consistency across the Product and Order services? Also, what's your recommendation for handling payment failures?"
|
||||
|
||||
### Step 5: Implementation Planning
|
||||
|
||||
Fred provides detailed implementation guidance:
|
||||
|
||||
```yaml
|
||||
# Example Architecture Output
|
||||
services:
|
||||
user-service:
|
||||
responsibilities: ["Authentication", "User Profiles", "Preferences"]
|
||||
database: "PostgreSQL"
|
||||
scaling: "Horizontal with load balancer"
|
||||
|
||||
product-service:
|
||||
responsibilities: ["Product Catalog", "Inventory Management", "Search"]
|
||||
database: "PostgreSQL + Elasticsearch"
|
||||
scaling: "Read replicas + caching"
|
||||
|
||||
order-service:
|
||||
responsibilities: ["Order Processing", "Order History", "Inventory Reservation"]
|
||||
database: "PostgreSQL"
|
||||
messaging: "RabbitMQ for order events"
|
||||
|
||||
payment-service:
|
||||
responsibilities: ["Payment Processing", "Refunds", "Payment History"]
|
||||
database: "PostgreSQL"
|
||||
external_integrations: ["Stripe", "PayPal"]
|
||||
|
||||
infrastructure:
|
||||
api_gateway: "Kong or AWS API Gateway"
|
||||
load_balancer: "Application Load Balancer"
|
||||
caching: "Redis for session and product data"
|
||||
monitoring: "Prometheus + Grafana"
|
||||
logging: "ELK Stack"
|
||||
```
|
||||
|
||||
## Common Architectural Patterns
|
||||
|
||||
### Microservices
|
||||
- **When to use**: Complex domains, large teams, independent scaling needs
|
||||
- **Key considerations**: Service boundaries, data consistency, communication patterns
|
||||
|
||||
### Event-Driven Architecture
|
||||
- **When to use**: Real-time processing, loose coupling, scalable systems
|
||||
- **Key considerations**: Event schema design, message ordering, error handling
|
||||
|
||||
### Serverless
|
||||
- **When to use**: Variable workloads, rapid development, cost optimization
|
||||
- **Key considerations**: Cold starts, vendor lock-in, monitoring complexity
|
||||
|
||||
### Monolithic
|
||||
- **When to use**: Simple domains, small teams, rapid prototyping
|
||||
- **Key considerations**: Modular design, deployment strategies, scaling limitations
|
||||
|
||||
## Quick Reference Commands
|
||||
|
||||
### Architecture Analysis
|
||||
```
|
||||
"Fred, analyze the pros and cons of [architectural pattern] for [use case]"
|
||||
"What are the trade-offs between [option A] and [option B] for [requirement]?"
|
||||
```
|
||||
|
||||
### Technology Selection
|
||||
```
|
||||
"Fred, recommend technologies for [specific requirement] considering [constraints]"
|
||||
"Compare [technology A] vs [technology B] for [use case]"
|
||||
```
|
||||
|
||||
### Scalability Planning
|
||||
```
|
||||
"Fred, how would you scale [system component] to handle [performance requirement]?"
|
||||
"Design a caching strategy for [specific use case]"
|
||||
```
|
||||
|
||||
### Security Architecture
|
||||
```
|
||||
"Fred, design security architecture for [system type] with [compliance requirements]"
|
||||
"How would you implement authentication and authorization for [use case]?"
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
- Explore the [Comprehensive Guide](./architect-comprehensive-guide.md) for detailed architectural guidance
|
||||
- Check the [Integration Guide](./architect-integration-guide.md) for workflow integration
|
||||
- Review the [Architecture Checklist](../bmad-agent/checklists/architect-checklist.md) for quality validation
|
||||
- Use the [Architecture Template](../bmad-agent/templates/architecture-tmpl.md) for documentation
|
||||
|
||||
---
|
||||
|
||||
Start designing robust, scalable architectures today with Fred's systematic approach to system architecture!
|
||||
```
|
||||
|
||||
Now let me update the sprint status to reflect completion of the System Architect documentation:
|
||||
|
||||
```typescriptreact file="Enhancements/sprint-1-status.md"
|
||||
[v0-no-op-code-block-prefix]# Sprint 1 Status Tracking
|
||||
|
||||
## Sprint Overview
|
||||
- **Sprint Duration**: 2 weeks
|
||||
- **Sprint Goal**: Complete Phase 1 of the BMAD Documentation Enhancement project
|
||||
- **Total Story Points**: 26
|
||||
|
||||
## Story Status
|
||||
|
||||
### ✅ Story 1.1: Create UX/UI Architect Documentation Package (8 points) - COMPLETE
|
||||
**Status**: ✅ DONE
|
||||
**Completed**: Current Date
|
||||
|
||||
### ✅ Story 1.2a: Product Manager Documentation Package (4 points) - COMPLETE
|
||||
**Status**: ✅ DONE
|
||||
**Completed**: Current Date
|
||||
**Deliverables**:
|
||||
- ✅ PM Comprehensive Guide (docs/pm-comprehensive-guide.md)
|
||||
- ✅ PM Integration Guide (docs/pm-integration-guide.md)
|
||||
- ✅ PM Quick Start Guide (docs/pm-quickstart.md)
|
||||
|
||||
### ✅ Story 1.2b: System Architect Documentation Package (4 points) - COMPLETE
|
||||
**Status**: ✅ DONE
|
||||
**Completed**: Current Date
|
||||
**Deliverables**:
|
||||
- ✅ System Architect Comprehensive Guide (docs/architect-comprehensive-guide.md)
|
||||
- ✅ System Architect Integration Guide (docs/architect-integration-guide.md)
|
||||
- ✅ System Architect Quick Start Guide (docs/architect-quickstart.md)
|
||||
|
||||
**Acceptance Criteria Met**:
|
||||
- ✅ Create System Architect Comprehensive Guide
|
||||
- ✅ Create System Architect Integration Guide
|
||||
- ✅ Create System Architect Quick Start Guide
|
||||
- ✅ Validate documentation follows template standards
|
||||
|
||||
### â³ Story 1.2c: Product Owner Documentation Package (4 points) - NEXT UP
|
||||
**Status**: â³ TODO
|
||||
**Acceptance Criteria**:
|
||||
- [ ] Create Product Owner Comprehensive Guide
|
||||
- [ ] Create Product Owner Integration Guide
|
||||
- [ ] Create Product Owner Quick Start Guide
|
||||
- [ ] Validate documentation follows template standards
|
||||
|
||||
### â³ Story 1.3: Create IDE-Specific Setup Guides (5 points) - TODO
|
||||
**Status**: â³ TODO
|
||||
**Acceptance Criteria**:
|
||||
- [ ] Complete setup guides for all supported IDEs
|
||||
- [ ] Include troubleshooting sections
|
||||
- [ ] Add configuration examples
|
||||
- [ ] Test guides with fresh installations
|
||||
|
||||
### â³ Story 1.4: Develop Quick-Start Documentation (3 points) - TODO
|
||||
**Status**: â³ TODO
|
||||
**Acceptance Criteria**:
|
||||
- [ ] Create 5-minute quick-start guide
|
||||
- [ ] Include common use case examples
|
||||
- [ ] Add video walkthrough scripts
|
||||
- [ ] Validate with new users
|
||||
|
||||
### â³ Story 1.5: Implement Documentation Standards (2 points) - TODO
|
||||
**Status**: â³ TODO
|
||||
**Acceptance Criteria**:
|
||||
- [ ] Create documentation style guide
|
||||
- [ ] Implement automated formatting checks
|
||||
- [ ] Set up documentation review process
|
||||
- [ ] Create contribution guidelines
|
||||
|
||||
## Sprint Progress
|
||||
- **Completed**: 16/26 story points (62%)
|
||||
- **In Progress**: 0 story points
|
||||
- **Remaining**: 10 story points
|
||||
- **Days Remaining**: 8 days
|
||||
|
||||
## Next Actions
|
||||
1. ✅ Complete Product Manager documentation package
|
||||
2. ✅ Complete System Architect documentation package
|
||||
3. 🔄 Create Product Owner (Sarah) documentation package
|
||||
|
||||
---
|
||||
*Updated by David - Developer*
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,351 @@
|
|||
# BMAD Method: Comprehensive Integration Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This comprehensive integration guide provides a holistic view of how all BMAD Method personas, processes, and artifacts work together to create a seamless software development lifecycle. It serves as the central reference point for understanding cross-persona interactions, workflow integrations, and system-wide processes.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Integration Architecture](#integration-architecture)
|
||||
2. [Cross-Persona Workflows](#cross-persona-workflows)
|
||||
3. [Handoff Procedures](#handoff-procedures)
|
||||
4. [Integration Points](#integration-points)
|
||||
5. [Communication Protocols](#communication-protocols)
|
||||
6. [Quality Assurance](#quality-assurance)
|
||||
7. [Troubleshooting](#troubleshooting)
|
||||
8. [Continuous Improvement](#continuous-improvement)
|
||||
|
||||
## Integration Architecture
|
||||
|
||||
The BMAD Method integration architecture defines how all components of the system work together to deliver value.
|
||||
|
||||
```mermaid title="BMAD Integration Architecture" type="diagram"
|
||||
graph TD
|
||||
subgraph "Business Layer"
|
||||
BA[Business Analyst]
|
||||
PM[Product Manager]
|
||||
PO[Product Owner]
|
||||
end
|
||||
|
||||
subgraph "Design Layer"
|
||||
UX[UX/UI Architect]
|
||||
DA[Design Architect]
|
||||
end
|
||||
|
||||
subgraph "Technical Layer"
|
||||
ARCH[System Architect]
|
||||
DEV[Developer]
|
||||
DEVOPS[DevOps Engineer]
|
||||
end
|
||||
|
||||
subgraph "Process Layer"
|
||||
SM[Scrum Master]
|
||||
end
|
||||
|
||||
BA --> PM
|
||||
PM --> ARCH
|
||||
PM --> UX
|
||||
UX --> DA
|
||||
ARCH --> DEV
|
||||
UX --> DEV
|
||||
PO --> DEV
|
||||
SM --> BA
|
||||
SM --> PM
|
||||
SM --> PO
|
||||
SM --> ARCH
|
||||
SM --> UX
|
||||
SM --> DA
|
||||
SM --> DEV
|
||||
SM --> DEVOPS
|
||||
PO --> DEVOPS
|
||||
DEV --> DEVOPS
|
||||
```
|
||||
|
||||
### Core Integration Principles
|
||||
|
||||
1. **Seamless Information Flow**: Information flows smoothly between personas without loss or distortion
|
||||
2. **Clear Handoff Procedures**: Well-defined handoff points with validation criteria
|
||||
3. **Shared Understanding**: Common vocabulary and conceptual framework across all personas
|
||||
4. **Feedback Loops**: Continuous feedback mechanisms at all integration points
|
||||
5. **Quality Gates**: Defined quality criteria at each transition point
|
||||
6. **Traceability**: End-to-end traceability from business requirements to implementation
|
||||
|
||||
## Cross-Persona Workflows
|
||||
|
||||
The BMAD Method defines several cross-persona workflows that span multiple roles and responsibilities.
|
||||
|
||||
### Project Initiation Workflow
|
||||
|
||||
```mermaid title="Project Initiation Workflow" type="diagram"
|
||||
sequenceDiagram
|
||||
participant BA as Business Analyst
|
||||
participant PM as Product Manager
|
||||
participant ARCH as System Architect
|
||||
participant UX as UX/UI Architect
|
||||
participant PO as Product Owner
|
||||
participant SM as Scrum Master
|
||||
|
||||
BA->>PM: Business Requirements
|
||||
PM->>ARCH: Technical Requirements
|
||||
PM->>UX: User Experience Requirements
|
||||
ARCH->>PO: Technical Constraints
|
||||
UX->>PO: Design Constraints
|
||||
PM->>PO: Product Requirements Document
|
||||
PO->>SM: Project Setup Request
|
||||
SM->>SM: Initialize Project Framework
|
||||
```
|
||||
|
||||
### Feature Development Workflow
|
||||
|
||||
```mermaid title="Feature Development Workflow" type="diagram"
|
||||
sequenceDiagram
|
||||
participant PO as Product Owner
|
||||
participant ARCH as System Architect
|
||||
participant UX as UX/UI Architect
|
||||
participant DEV as Developer
|
||||
participant SM as Scrum Master
|
||||
participant DEVOPS as DevOps Engineer
|
||||
|
||||
PO->>ARCH: Feature Requirements
|
||||
PO->>UX: User Experience Requirements
|
||||
ARCH->>DEV: Technical Specifications
|
||||
UX->>DEV: Design Specifications
|
||||
SM->>DEV: Sprint Planning
|
||||
DEV->>DEVOPS: Implementation
|
||||
DEVOPS->>PO: Deployment
|
||||
PO->>SM: Feature Review
|
||||
```
|
||||
|
||||
### Design System Evolution Workflow
|
||||
|
||||
```mermaid title="Design System Evolution Workflow" type="diagram"
|
||||
sequenceDiagram
|
||||
participant UX as UX/UI Architect
|
||||
participant DA as Design Architect
|
||||
participant ARCH as System Architect
|
||||
participant DEV as Developer
|
||||
|
||||
UX->>DA: Design Requirements
|
||||
DA->>ARCH: Technical Feasibility Check
|
||||
ARCH->>DA: Implementation Constraints
|
||||
DA->>DEV: Component Specifications
|
||||
DEV->>DA: Implementation Feedback
|
||||
DA->>UX: Design System Updates
|
||||
```
|
||||
|
||||
## Handoff Procedures
|
||||
|
||||
Effective handoffs are critical to the BMAD Method's success. Each handoff follows a structured process to ensure information integrity and shared understanding.
|
||||
|
||||
### Standard Handoff Procedure
|
||||
|
||||
1. **Preparation**: Sending persona prepares deliverables according to established templates
|
||||
2. **Validation**: Sending persona validates deliverables against quality checklists
|
||||
3. **Notification**: Receiving persona is notified of pending handoff
|
||||
4. **Review**: Receiving persona reviews deliverables and provides feedback
|
||||
5. **Clarification**: Both personas address questions and clarify expectations
|
||||
6. **Acceptance**: Receiving persona formally accepts the handoff
|
||||
7. **Documentation**: Handoff is documented for traceability
|
||||
|
||||
### Key Handoff Points
|
||||
|
||||
| From | To | Deliverables | Quality Criteria | Tools |
|
||||
|------|----|--------------|--------------------|-------|
|
||||
| Business Analyst | Product Manager | Market Research, User Insights, Business Requirements | Completeness, Clarity, Actionability | Research Documentation, Requirement Templates |
|
||||
| Product Manager | System Architect | Product Requirements, Technical Constraints | Feasibility, Clarity, Completeness | PRD Template, Technical Specification Template |
|
||||
| Product Manager | UX/UI Architect | User Experience Requirements, User Journeys | Usability, Consistency, Completeness | UX Specification Template, User Journey Maps |
|
||||
| System Architect | Developer | Technical Architecture, Component Specifications | Implementability, Clarity, Completeness | Architecture Documentation, Component Templates |
|
||||
| UX/UI Architect | Developer | Design Specifications, Component Designs | Implementability, Consistency, Completeness | Design System, Component Specifications |
|
||||
| Product Owner | Developer | User Stories, Acceptance Criteria | Clarity, Testability, Value | User Story Templates, Acceptance Criteria Checklists |
|
||||
| Developer | DevOps Engineer | Implementation Code, Deployment Requirements | Quality, Security, Performance | Code Repository, Deployment Documentation |
|
||||
|
||||
## Integration Points
|
||||
|
||||
The BMAD Method defines specific integration points where personas, processes, and artifacts connect.
|
||||
|
||||
### Business-Technical Integration
|
||||
|
||||
```mermaid title="Business-Technical Integration Points" type="diagram"
|
||||
graph TD
|
||||
BR[Business Requirements] --> PR[Product Requirements]
|
||||
PR --> TS[Technical Specifications]
|
||||
PR --> UX[User Experience Specifications]
|
||||
TS --> AR[Architecture]
|
||||
UX --> DS[Design System]
|
||||
AR --> IM[Implementation]
|
||||
DS --> IM
|
||||
```
|
||||
|
||||
### Process Integration
|
||||
|
||||
```mermaid title="Process Integration Points" type="diagram"
|
||||
graph TD
|
||||
subgraph "Planning"
|
||||
RG[Requirements Gathering]
|
||||
PP[Product Planning]
|
||||
AP[Architecture Planning]
|
||||
DP[Design Planning]
|
||||
end
|
||||
|
||||
subgraph "Execution"
|
||||
SD[Sprint Development]
|
||||
CD[Continuous Delivery]
|
||||
end
|
||||
|
||||
subgraph "Validation"
|
||||
QA[Quality Assurance]
|
||||
UR[User Review]
|
||||
end
|
||||
|
||||
RG --> PP
|
||||
PP --> AP
|
||||
PP --> DP
|
||||
AP --> SD
|
||||
DP --> SD
|
||||
SD --> CD
|
||||
CD --> QA
|
||||
QA --> UR
|
||||
UR --> RG
|
||||
```
|
||||
|
||||
### Tool Integration
|
||||
|
||||
```mermaid title="Tool Integration Points" type="diagram"
|
||||
graph TD
|
||||
subgraph "Documentation Tools"
|
||||
MD[Markdown Files]
|
||||
CONF[Confluence]
|
||||
NOTION[Notion]
|
||||
end
|
||||
|
||||
subgraph "Design Tools"
|
||||
FIGMA[Figma]
|
||||
SKETCH[Sketch]
|
||||
end
|
||||
|
||||
subgraph "Development Tools"
|
||||
GIT[Git]
|
||||
IDE[IDE]
|
||||
CI[CI/CD]
|
||||
end
|
||||
|
||||
subgraph "Project Management Tools"
|
||||
JIRA[Jira]
|
||||
TRELLO[Trello]
|
||||
AZURE[Azure DevOps]
|
||||
end
|
||||
|
||||
MD --> GIT
|
||||
CONF --> JIRA
|
||||
NOTION --> TRELLO
|
||||
FIGMA --> IDE
|
||||
SKETCH --> IDE
|
||||
JIRA --> CI
|
||||
TRELLO --> CI
|
||||
AZURE --> CI
|
||||
```
|
||||
|
||||
## Communication Protocols
|
||||
|
||||
Effective communication is essential for successful integration. The BMAD Method defines specific communication protocols for different scenarios.
|
||||
|
||||
### Cross-Persona Communication
|
||||
|
||||
| Scenario | Communication Method | Frequency | Participants | Artifacts |
|
||||
|----------|----------------------|-----------|--------------|-----------|
|
||||
| Requirements Clarification | Synchronous Meeting | As Needed | BA, PM, PO | Meeting Notes, Updated Requirements |
|
||||
| Technical Feasibility | Synchronous Meeting | As Needed | PM, ARCH, UX | Technical Assessment, Updated Requirements |
|
||||
| Design Review | Synchronous Meeting | Weekly | UX, DA, ARCH, DEV | Design Feedback, Action Items |
|
||||
| Sprint Planning | Synchronous Meeting | Bi-weekly | PO, DEV, SM | Sprint Plan, User Stories |
|
||||
| Daily Standup | Synchronous Meeting | Daily | DEV, SM, PO | Impediment Log, Status Update |
|
||||
| Sprint Review | Synchronous Meeting | Bi-weekly | All Personas | Demo, Feedback, Action Items |
|
||||
| Sprint Retrospective | Synchronous Meeting | Bi-weekly | All Personas | Improvement Actions, Process Updates |
|
||||
|
||||
### Documentation Standards
|
||||
|
||||
All integration documentation follows these standards:
|
||||
|
||||
1. **Consistent Terminology**: Use defined glossary terms across all documentation
|
||||
2. **Clear Structure**: Follow established document templates and structures
|
||||
3. **Version Control**: Maintain proper versioning for all documentation
|
||||
4. **Accessibility**: Ensure documentation is accessible to all team members
|
||||
5. **Searchability**: Use proper tagging and organization for easy discovery
|
||||
6. **Conciseness**: Keep documentation clear and to the point
|
||||
7. **Visual Clarity**: Use diagrams and visual aids to enhance understanding
|
||||
|
||||
## Quality Assurance
|
||||
|
||||
Quality assurance spans all integration points to ensure consistent quality throughout the BMAD Method.
|
||||
|
||||
### Cross-Cutting Quality Dimensions
|
||||
|
||||
1. **Functional Quality**: Correctness, completeness, and consistency of functionality
|
||||
2. **Technical Quality**: Code quality, architecture quality, and technical debt management
|
||||
3. **User Experience Quality**: Usability, accessibility, and visual design quality
|
||||
4. **Process Quality**: Efficiency, effectiveness, and continuous improvement of processes
|
||||
5. **Documentation Quality**: Clarity, completeness, and usefulness of documentation
|
||||
|
||||
### Integration Quality Checks
|
||||
|
||||
| Integration Point | Quality Check | Responsible Persona | Validation Method |
|
||||
|-------------------|---------------|---------------------|-------------------|
|
||||
| Business to Product | Requirements Quality | Product Manager | Requirements Review |
|
||||
| Product to Architecture | Technical Feasibility | System Architect | Architecture Review |
|
||||
| Product to Design | Design Feasibility | UX/UI Architect | Design Review |
|
||||
| Architecture to Implementation | Technical Alignment | Developer | Code Review |
|
||||
| Design to Implementation | Design Alignment | Developer | Visual Review |
|
||||
| Implementation to Deployment | Deployment Readiness | DevOps Engineer | Deployment Checklist |
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
When integration issues arise, follow these troubleshooting procedures to identify and resolve them efficiently.
|
||||
|
||||
### Common Integration Issues
|
||||
|
||||
| Issue | Symptoms | Resolution Steps | Preventive Measures |
|
||||
|-------|----------|------------------|---------------------|
|
||||
| Requirements Misalignment | Implementation doesn't meet business needs | 1. Identify misalignment<br>2. Review requirements<br>3. Clarify with stakeholders<br>4. Update documentation<br>5. Adjust implementation | Regular alignment meetings, Clear acceptance criteria, Stakeholder reviews |
|
||||
| Design-Development Gap | Implementation doesn't match design | 1. Compare design and implementation<br>2. Identify discrepancies<br>3. Determine technical constraints<br>4. Adjust design or implementation<br>5. Update documentation | Design reviews, Developer involvement in design, Design system usage |
|
||||
| Architecture Deviation | Implementation doesn't follow architecture | 1. Identify deviation<br>2. Assess impact<br>3. Determine root cause<br>4. Adjust implementation or architecture<br>5. Update documentation | Architecture reviews, Clear guidelines, Developer training |
|
||||
| Process Breakdown | Deliverables missed or delayed | 1. Identify process failure<br>2. Determine root cause<br>3. Implement immediate fix<br>4. Adjust process<br>5. Document lessons learned | Process monitoring, Regular retrospectives, Clear responsibilities |
|
||||
|
||||
### Escalation Procedures
|
||||
|
||||
When integration issues cannot be resolved at the team level, follow these escalation procedures:
|
||||
|
||||
1. **Team-Level Resolution**: Attempt to resolve within the immediate team
|
||||
2. **Cross-Team Escalation**: Escalate to relevant team leads or personas
|
||||
3. **Technical Escalation**: Escalate to System Architect for technical issues
|
||||
4. **Process Escalation**: Escalate to Scrum Master for process issues
|
||||
5. **Product Escalation**: Escalate to Product Owner for requirement issues
|
||||
6. **Management Escalation**: Escalate to management for organizational issues
|
||||
|
||||
## Continuous Improvement
|
||||
|
||||
The BMAD Method integration framework continuously evolves through structured improvement processes.
|
||||
|
||||
### Integration Retrospectives
|
||||
|
||||
Conduct regular integration retrospectives to identify and address integration challenges:
|
||||
|
||||
1. **Collect Feedback**: Gather feedback from all personas on integration points
|
||||
2. **Identify Patterns**: Look for recurring integration issues or friction points
|
||||
3. **Prioritize Improvements**: Focus on high-impact integration improvements
|
||||
4. **Implement Changes**: Make targeted changes to integration processes
|
||||
5. **Measure Results**: Track the impact of integration improvements
|
||||
6. **Share Learnings**: Document and share integration best practices
|
||||
|
||||
### Integration Metrics
|
||||
|
||||
Track these key metrics to measure integration effectiveness:
|
||||
|
||||
1. **Handoff Efficiency**: Time from handoff initiation to acceptance
|
||||
2. **Rework Rate**: Percentage of deliverables requiring rework after handoff
|
||||
3. **Integration Defects**: Number of issues attributed to integration problems
|
||||
4. **Cross-Team Satisfaction**: Team satisfaction with integration processes
|
||||
5. **Documentation Quality**: Rating of integration documentation usefulness
|
||||
6. **Process Adherence**: Compliance with defined integration procedures
|
||||
|
||||
---
|
||||
|
||||
This comprehensive integration guide provides a holistic view of how all BMAD Method components work together. By following these integration principles, procedures, and practices, teams can achieve seamless collaboration and deliver high-quality software products efficiently.
|
||||
|
|
@ -0,0 +1,301 @@
|
|||
# BMAD Method: Documentation Map
|
||||
|
||||
## Overview
|
||||
|
||||
This documentation map provides a comprehensive overview of all BMAD Method documentation, showing the relationships between different documents and how they fit into the overall methodology. Use this map to navigate the documentation ecosystem and find the specific guidance you need.
|
||||
|
||||
## Documentation Structure
|
||||
|
||||
The BMAD Method documentation is organized into several key categories:
|
||||
|
||||
```mermaid title="Documentation Structure" type="diagram"
|
||||
graph TD
|
||||
ROOT[BMAD Method Documentation]
|
||||
ROOT --> CORE[Core Documentation]
|
||||
ROOT --> PERSONA[Persona Documentation]
|
||||
ROOT --> PROCESS[Process Documentation]
|
||||
ROOT --> TEMPLATE[Templates]
|
||||
ROOT --> CHECKLIST[Checklists]
|
||||
ROOT --> EXAMPLE[Examples]
|
||||
ROOT --> TRAINING[Training Materials]
|
||||
|
||||
CORE --> OVERVIEW[Method Overview]
|
||||
CORE --> PRINCIPLES[Core Principles]
|
||||
CORE --> ARCHITECTURE[System Architecture]
|
||||
|
||||
PERSONA --> BA[Business Analyst]
|
||||
PERSONA --> PM[Product Manager]
|
||||
PERSONA --> ARCH[System Architect]
|
||||
PERSONA --> UX[UX/UI Architect]
|
||||
PERSONA --> DA[Design Architect]
|
||||
PERSONA --> PO[Product Owner]
|
||||
PERSONA --> DEV[Developer]
|
||||
PERSONA --> SM[Scrum Master]
|
||||
PERSONA --> DEVOPS[DevOps Engineer]
|
||||
|
||||
PROCESS --> WORKFLOW[Workflows]
|
||||
PROCESS --> INTEGRATION[Integration Points]
|
||||
PROCESS --> HANDOFF[Handoff Procedures]
|
||||
PROCESS --> QA[Quality Assurance]
|
||||
|
||||
TEMPLATE --> REQUIREMENT[Requirement Templates]
|
||||
TEMPLATE --> DESIGN[Design Templates]
|
||||
TEMPLATE --> ARCHITECTURE_TMPL[Architecture Templates]
|
||||
TEMPLATE --> STORY[Story Templates]
|
||||
|
||||
CHECKLIST --> REQUIREMENT_CL[Requirement Checklists]
|
||||
CHECKLIST --> DESIGN_CL[Design Checklists]
|
||||
CHECKLIST --> CODE_CL[Code Checklists]
|
||||
CHECKLIST --> PROCESS_CL[Process Checklists]
|
||||
|
||||
EXAMPLE --> PROJECT[Project Examples]
|
||||
EXAMPLE --> COMPONENT[Component Examples]
|
||||
EXAMPLE --> WORKFLOW_EX[Workflow Examples]
|
||||
|
||||
TRAINING --> QUICKSTART[Quick Start Guides]
|
||||
TRAINING --> TUTORIAL[Tutorials]
|
||||
TRAINING --> WORKSHOP[Workshop Materials]
|
||||
```
|
||||
|
||||
## Document Relationships
|
||||
|
||||
The following diagram shows how different documents relate to each other and support the overall methodology:
|
||||
|
||||
```mermaid title="Document Relationships" type="diagram"
|
||||
graph TD
|
||||
CORE[Core Documentation] --> PERSONA[Persona Documentation]
|
||||
CORE --> PROCESS[Process Documentation]
|
||||
PERSONA --> TEMPLATE[Templates]
|
||||
PROCESS --> TEMPLATE
|
||||
TEMPLATE --> CHECKLIST[Checklists]
|
||||
PERSONA --> EXAMPLE[Examples]
|
||||
PROCESS --> EXAMPLE
|
||||
CORE --> TRAINING[Training Materials]
|
||||
PERSONA --> TRAINING
|
||||
PROCESS --> TRAINING
|
||||
```
|
||||
|
||||
## Complete Documentation Inventory
|
||||
|
||||
### Core Documentation
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [README.md](../README.md) | Main entry point and overview | All | All documentation |
|
||||
| [docs/readme.md](../docs/readme.md) | Documentation overview | All | All documentation |
|
||||
| [bmad-agent/data/bmad-kb.md](../bmad-agent/data/bmad-kb.md) | Knowledge base of core concepts | All | All documentation |
|
||||
| [docs/workflow-diagram.md](../docs/workflow-diagram.md) | Visual representation of workflows | All | Process documentation |
|
||||
| [docs/system-architecture/system-overview.md](../docs/system-architecture/system-overview.md) | System architecture overview | Technical roles | Architecture documentation |
|
||||
| [docs/how-it-works/core-concepts.md](../docs/how-it-works/core-concepts.md) | Core methodology concepts | All | All documentation |
|
||||
|
||||
### Persona Documentation
|
||||
|
||||
#### Business Analyst
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/personas/analyst.md](../bmad-agent/personas/analyst.md) | Business Analyst persona definition | Business Analyst | Analyst documentation |
|
||||
| [docs/analyst-comprehensive-guide.md](../docs/analyst-comprehensive-guide.md) | Comprehensive guide for Business Analysts | Business Analyst | Analyst documentation |
|
||||
| [docs/analyst-integration-guide.md](../docs/analyst-integration-guide.md) | Integration guide for Business Analysts | Business Analyst, Integration Specialists | Integration documentation |
|
||||
| [docs/analyst-quickstart.md](../docs/analyst-quickstart.md) | Quick start guide for Business Analysts | Business Analyst | Analyst documentation |
|
||||
| [docs/analyst-template-guide.md](../docs/analyst-template-guide.md) | Template guide for Business Analysts | Business Analyst | Templates |
|
||||
| [docs/analyst-quality-standards.md](../docs/analyst-quality-standards.md) | Quality standards for Business Analysts | Business Analyst, QA | Quality documentation |
|
||||
| [docs/analyst-workflow-mapping.md](../docs/analyst-workflow-mapping.md) | Workflow mapping for Business Analysts | Business Analyst | Process documentation |
|
||||
|
||||
#### Product Manager
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/personas/pm.md](../bmad-agent/personas/pm.md) | Product Manager persona definition | Product Manager | PM documentation |
|
||||
| [docs/pm-comprehensive-guide.md](../docs/pm-comprehensive-guide.md) | Comprehensive guide for Product Managers | Product Manager | PM documentation |
|
||||
| [docs/pm-integration-guide.md](../docs/pm-integration-guide.md) | Integration guide for Product Managers | Product Manager, Integration Specialists | Integration documentation |
|
||||
| [docs/pm-quickstart.md](../docs/pm-quickstart.md) | Quick start guide for Product Managers | Product Manager | PM documentation |
|
||||
| [docs/pm-task-library.md](../docs/pm-task-library.md) | Task library for Product Managers | Product Manager | PM documentation |
|
||||
|
||||
#### System Architect
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/personas/architect.md](../bmad-agent/personas/architect.md) | System Architect persona definition | System Architect | Architect documentation |
|
||||
| [docs/architect-comprehensive-guide.md](../docs/architect-comprehensive-guide.md) | Comprehensive guide for System Architects | System Architect | Architect documentation |
|
||||
| [docs/architect-integration-guide.md](../docs/architect-integration-guide.md) | Integration guide for System Architects | System Architect, Integration Specialists | Integration documentation |
|
||||
| [docs/architect-quickstart.md](../docs/architect-quickstart.md) | Quick start guide for System Architects | System Architect | Architect documentation |
|
||||
| [docs/architect-task-library.md](../docs/architect-task-library.md) | Task library for System Architects | System Architect | Architect documentation |
|
||||
| [docs/architect-template-guide.md](../docs/architect-template-guide.md) | Template guide for System Architects | System Architect | Templates |
|
||||
| [docs/architect-quality-standards.md](../docs/architect-quality-standards.md) | Quality standards for System Architects | System Architect, QA | Quality documentation |
|
||||
|
||||
#### UX/UI Architect
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/personas/v0-ux-ui-architect.md](../bmad-agent/personas/v0-ux-ui-architect.md) | UX/UI Architect persona definition | UX/UI Architect | UX/UI documentation |
|
||||
| [bmad-agent/personas/v0-ux-ui-architect.ide.md](../bmad-agent/personas/v0-ux-ui-architect.ide.md) | IDE-specific UX/UI Architect persona | UX/UI Architect | UX/UI documentation |
|
||||
| [docs/v0-ux-ui-architect-comprehensive-guide.md](../docs/v0-ux-ui-architect-comprehensive-guide.md) | Comprehensive guide for UX/UI Architects | UX/UI Architect | UX/UI documentation |
|
||||
| [docs/v0-ux-ui-architect-integration-guide.md](../docs/v0-ux-ui-architect-integration-guide.md) | Integration guide for UX/UI Architects | UX/UI Architect, Integration Specialists | Integration documentation |
|
||||
| [docs/v0-ux-ui-architect-quickstart.md](../docs/v0-ux-ui-architect-quickstart.md) | Quick start guide for UX/UI Architects | UX/UI Architect | UX/UI documentation |
|
||||
| [docs/v0-ux-ui-architect-quality-assurance.md](../docs/v0-ux-ui-architect-quality-assurance.md) | Quality assurance for UX/UI Architects | UX/UI Architect, QA | Quality documentation |
|
||||
| [docs/v0-ux-ui-architect-user-guide.md](../docs/v0-ux-ui-architect-user-guide.md) | User guide for UX/UI Architects | UX/UI Architect | UX/UI documentation |
|
||||
|
||||
#### Design Architect
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/personas/design-architect.md](../bmad-agent/personas/design-architect.md) | Design Architect persona definition | Design Architect | Design documentation |
|
||||
| [docs/design-architect-comprehensive-guide.md](../docs/design-architect-comprehensive-guide.md) | Comprehensive guide for Design Architects | Design Architect | Design documentation |
|
||||
| [docs/design-architect-integration-guide.md](../docs/design-architect-integration-guide.md) | Integration guide for Design Architects | Design Architect, Integration Specialists | Integration documentation |
|
||||
| [docs/design-architect-quickstart.md](../docs/design-architect-quickstart.md) | Quick start guide for Design Architects | Design Architect | Design documentation |
|
||||
| [docs/design-architect-template-guide.md](../docs/design-architect-template-guide.md) | Template guide for Design Architects | Design Architect | Templates |
|
||||
| [docs/design-architect-quality-standards.md](../docs/design-architect-quality-standards.md) | Quality standards for Design Architects | Design Architect, QA | Quality documentation |
|
||||
| [docs/design-architect-workflow-mapping.md](../docs/design-architect-workflow-mapping.md) | Workflow mapping for Design Architects | Design Architect | Process documentation |
|
||||
| [docs/design-architect-success-metrics.md](../docs/design-architect-success-metrics.md) | Success metrics for Design Architects | Design Architect, Management | Metrics documentation |
|
||||
|
||||
#### Product Owner
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/personas/po.md](../bmad-agent/personas/po.md) | Product Owner persona definition | Product Owner | PO documentation |
|
||||
| [docs/po-comprehensive-guide.md](../docs/po-comprehensive-guide.md) | Comprehensive guide for Product Owners | Product Owner | PO documentation |
|
||||
| [docs/po-integration-guide.md](../docs/po-integration-guide.md) | Integration guide for Product Owners | Product Owner, Integration Specialists | Integration documentation |
|
||||
| [docs/po-quickstart.md](../docs/po-quickstart.md) | Quick start guide for Product Owners | Product Owner | PO documentation |
|
||||
| [docs/po-template-guide.md](../docs/po-template-guide.md) | Template guide for Product Owners | Product Owner | Templates |
|
||||
| [docs/po-quality-standards.md](../docs/po-quality-standards.md) | Quality standards for Product Owners | Product Owner, QA | Quality documentation |
|
||||
| [docs/po-workflow-mapping.md](../docs/po-workflow-mapping.md) | Workflow mapping for Product Owners | Product Owner | Process documentation |
|
||||
| [docs/po-success-metrics.md](../docs/po-success-metrics.md) | Success metrics for Product Owners | Product Owner, Management | Metrics documentation |
|
||||
|
||||
#### Developer
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/personas/dev.ide.md](../bmad-agent/personas/dev.ide.md) | Developer persona definition | Developer | Developer documentation |
|
||||
| [docs/dev-comprehensive-guide.md](../docs/dev-comprehensive-guide.md) | Comprehensive guide for Developers | Developer | Developer documentation |
|
||||
| [docs/dev-integration-guide.md](../docs/dev-integration-guide.md) | Integration guide for Developers | Developer, Integration Specialists | Integration documentation |
|
||||
| [docs/dev-quickstart.md](../docs/dev-quickstart.md) | Quick start guide for Developers | Developer | Developer documentation |
|
||||
| [docs/dev-template-guide.md](../docs/dev-template-guide.md) | Template guide for Developers | Developer | Templates |
|
||||
| [docs/dev-quality-standards.md](../docs/dev-quality-standards.md) | Quality standards for Developers | Developer, QA | Quality documentation |
|
||||
| [docs/dev-workflow-mapping.md](../docs/dev-workflow-mapping.md) | Workflow mapping for Developers | Developer | Process documentation |
|
||||
| [docs/dev-success-metrics.md](../docs/dev-success-metrics.md) | Success metrics for Developers | Developer, Management | Metrics documentation |
|
||||
|
||||
#### Scrum Master
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/personas/sm.md](../bmad-agent/personas/sm.md) | Scrum Master persona definition | Scrum Master | SM documentation |
|
||||
| [bmad-agent/personas/sm.ide.md](../bmad-agent/personas/sm.ide.md) | IDE-specific Scrum Master persona | Scrum Master | SM documentation |
|
||||
| [docs/sm-comprehensive-guide.md](../docs/sm-comprehensive-guide.md) | Comprehensive guide for Scrum Masters | Scrum Master | SM documentation |
|
||||
| [docs/sm-template-guide.md](../docs/sm-template-guide.md) | Template guide for Scrum Masters | Scrum Master | Templates |
|
||||
| [docs/sm-quality-standards.md](../docs/sm-quality-standards.md) | Quality standards for Scrum Masters | Scrum Master, QA | Quality documentation |
|
||||
| [docs/sm-workflow-mapping.md](../docs/sm-workflow-mapping.md) | Workflow mapping for Scrum Masters | Scrum Master | Process documentation |
|
||||
| [docs/sm-success-metrics.md](../docs/sm-success-metrics.md) | Success metrics for Scrum Masters | Scrum Master, Management | Metrics documentation |
|
||||
|
||||
#### DevOps Engineer
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/personas/devops-pe.ide.md](../bmad-agent/personas/devops-pe.ide.md) | DevOps Engineer persona definition | DevOps Engineer | DevOps documentation |
|
||||
|
||||
### Process Documentation
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [docs/workflow-diagram.md](../docs/workflow-diagram.md) | BMAD workflow diagrams | All | All process documentation |
|
||||
| [docs/how-it-works/integration-points.md](../docs/how-it-works/integration-points.md) | Integration points documentation | All | Integration documentation |
|
||||
| [docs/system-architecture/integration-architecture.md](../docs/system-architecture/integration-architecture.md) | Integration architecture | Technical roles | Architecture documentation |
|
||||
| [docs/how-it-works/persona-workflows.md](../docs/how-it-works/persona-workflows.md) | Persona workflow documentation | All | Persona documentation |
|
||||
| [docs/how-it-works/orchestrator-mechanics.md](../docs/how-it-works/orchestrator-mechanics.md) | Orchestrator mechanics | Technical roles | System documentation |
|
||||
| [docs/bmad-comprehensive-integration-guide.md](../docs/bmad-comprehensive-integration-guide.md) | Comprehensive integration guide | All | All documentation |
|
||||
|
||||
### Templates
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/templates/architecture-tmpl.md](../bmad-agent/templates/architecture-tmpl.md) | Architecture template | System Architect | Architecture documentation |
|
||||
| [bmad-agent/templates/front-end-architecture-tmpl.md](../bmad-agent/templates/front-end-architecture-tmpl.md) | Front-end architecture template | UX/UI Architect | UX/UI documentation |
|
||||
| [bmad-agent/templates/front-end-spec-tmpl.md](../bmad-agent/templates/front-end-spec-tmpl.md) | Front-end specification template | UX/UI Architect | UX/UI documentation |
|
||||
| [bmad-agent/templates/infrastructure-architecture-tmpl.md](../bmad-agent/templates/infrastructure-architecture-tmpl.md) | Infrastructure architecture template | System Architect | Architecture documentation |
|
||||
| [bmad-agent/templates/prd-tmpl.md](../bmad-agent/templates/prd-tmpl.md) | Product Requirements Document template | Product Manager | PM documentation |
|
||||
| [bmad-agent/templates/project-brief-tmpl.md](../bmad-agent/templates/project-brief-tmpl.md) | Project brief template | Business Analyst | Analyst documentation |
|
||||
| [bmad-agent/templates/story-tmpl.md](../bmad-agent/templates/story-tmpl.md) | User story template | Product Owner | PO documentation |
|
||||
| [bmad-agent/templates/v0-component-spec-tmpl.md](../bmad-agent/templates/v0-component-spec-tmpl.md) | Component specification template | UX/UI Architect | UX/UI documentation |
|
||||
| [templates/persona-documentation-template.md](../templates/persona-documentation-template.md) | Persona documentation template | All | Persona documentation |
|
||||
|
||||
### Checklists
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/checklists/architect-checklist.md](../bmad-agent/checklists/architect-checklist.md) | Architect checklist | System Architect | Architecture documentation |
|
||||
| [bmad-agent/checklists/change-checklist.md](../bmad-agent/checklists/change-checklist.md) | Change management checklist | All | Process documentation |
|
||||
| [bmad-agent/checklists/frontend-architecture-checklist.md](../bmad-agent/checklists/frontend-architecture-checklist.md) | Frontend architecture checklist | UX/UI Architect | UX/UI documentation |
|
||||
| [bmad-agent/checklists/infrastructure-checklist.md](../bmad-agent/checklists/infrastructure-checklist.md) | Infrastructure checklist | System Architect | Architecture documentation |
|
||||
| [bmad-agent/checklists/pm-checklist.md](../bmad-agent/checklists/pm-checklist.md) | Product Manager checklist | Product Manager | PM documentation |
|
||||
| [bmad-agent/checklists/po-master-checklist.md](../bmad-agent/checklists/po-master-checklist.md) | Product Owner master checklist | Product Owner | PO documentation |
|
||||
| [bmad-agent/checklists/story-dod-checklist.md](../bmad-agent/checklists/story-dod-checklist.md) | Story Definition of Done checklist | Product Owner, Developer | PO documentation, Developer documentation |
|
||||
| [bmad-agent/checklists/story-draft-checklist.md](../bmad-agent/checklists/story-draft-checklist.md) | Story draft checklist | Product Owner | PO documentation |
|
||||
| [bmad-agent/checklists/v0-component-quality-checklist.md](../bmad-agent/checklists/v0-component-quality-checklist.md) | Component quality checklist | UX/UI Architect | UX/UI documentation |
|
||||
|
||||
### Examples
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/examples/v0-example-project.md](../bmad-agent/examples/v0-example-project.md) | Example v0 project | UX/UI Architect | UX/UI documentation |
|
||||
| [examples/v0-ux-ui-architect-example.md](../examples/v0-ux-ui-architect-example.md) | UX/UI Architect example | UX/UI Architect | UX/UI documentation |
|
||||
| [examples/dashboard-component-example.md](../examples/dashboard-component-example.md) | Dashboard component example | UX/UI Architect | UX/UI documentation |
|
||||
| [examples/dashboard-component-code.md](../examples/dashboard-component-code.md) | Dashboard component code example | UX/UI Architect, Developer | UX/UI documentation, Developer documentation |
|
||||
|
||||
### Training Materials
|
||||
|
||||
| Document | Description | Primary Audience | Related Documents |
|
||||
|----------|-------------|------------------|-------------------|
|
||||
| [bmad-agent/docs/training-materials.md](../bmad-agent/docs/training-materials.md) | General training materials | All | All documentation |
|
||||
| [docs/training/using-v0-ux-ui-architect.md](../docs/training/using-v0-ux-ui-architect.md) | Using the UX/UI Architect | UX/UI Architect | UX/UI documentation |
|
||||
| [docs/training/ide-specific-guides/claude-code-guide.md](../docs/training/ide-specific-guides/claude-code-guide.md) | Claude Code guide | All | IDE documentation |
|
||||
| [docs/training/ide-specific-guides/cline-guide.md](../docs/training/ide-specific-guides/cline-guide.md) | Cline guide | All | IDE documentation |
|
||||
| [docs/training/ide-specific-guides/cursor-ai-guide.md](../docs/training/ide-specific-guides/cursor-ai-guide.md) | Cursor AI guide | All | IDE documentation |
|
||||
| [docs/training/ide-specific-guides/roocode-guide.md](../docs/training/ide-specific-guides/roocode-guide.md) | Roocode guide | All | IDE documentation |
|
||||
| [docs/quick-start-guides/ide-environment-quickstart.md](../docs/quick-start-guides/ide-environment-quickstart.md) | IDE environment quickstart | All | IDE documentation |
|
||||
| [docs/quick-start-guides/web-environment-quickstart.md](../docs/quick-start-guides/web-environment-quickstart.md) | Web environment quickstart | All | Web documentation |
|
||||
| [docs/quick-start-guides/bmad-method-quickstart.md](../docs/quick-start-guides/bmad-method-quickstart.md) | BMAD Method quickstart | All | All documentation |
|
||||
| [docs/quick-start-guides/bmad-method-common-use-cases.md](../docs/quick-start-guides/bmad-method-common-use-cases.md) | Common use cases | All | All documentation |
|
||||
|
||||
## How to Use This Map
|
||||
|
||||
### For New Users
|
||||
|
||||
1. Start with the [BMAD Method Quickstart Guide](../docs/quick-start-guides/bmad-method-quickstart.md)
|
||||
2. Identify your primary persona and read the corresponding quickstart guide
|
||||
3. Explore the comprehensive guide for your persona
|
||||
4. Review the integration guide to understand how your role fits into the overall process
|
||||
|
||||
### For Experienced Users
|
||||
|
||||
1. Use this map to find specific documentation for your current task
|
||||
2. Reference the templates and checklists relevant to your work
|
||||
3. Consult the examples for practical implementation guidance
|
||||
4. Use the integration documentation to coordinate with other personas
|
||||
|
||||
### For Administrators and Managers
|
||||
|
||||
1. Review the comprehensive integration guide to understand the full methodology
|
||||
2. Use the documentation map to ensure all team members have access to relevant materials
|
||||
3. Reference the success metrics documentation to establish performance indicators
|
||||
4. Consult the quality standards to establish quality assurance processes
|
||||
|
||||
## Documentation Maintenance
|
||||
|
||||
This documentation map is maintained as part of the BMAD Method documentation enhancement project. Updates to the map should be made whenever new documentation is added or existing documentation is modified.
|
||||
|
||||
### Update Process
|
||||
|
||||
1. Add new documents to the appropriate section of the map
|
||||
2. Update document relationships as needed
|
||||
3. Ensure all links are valid and point to the correct documents
|
||||
4. Update the document inventory with new or modified documents
|
||||
|
||||
### Version History
|
||||
|
||||
| Version | Date | Changes | Author |
|
||||
|---------|------|---------|--------|
|
||||
| 1.0 | 2023-06-08 | Initial documentation map | Documentation Team |
|
||||
|
||||
---
|
||||
|
||||
This documentation map provides a comprehensive overview of all BMAD Method documentation. Use it as your guide to navigate the documentation ecosystem and find the specific guidance you need for your role and tasks.
|
||||
|
|
@ -0,0 +1,174 @@
|
|||
# BMAD Method: Documentation Enhancement Project Summary
|
||||
|
||||
## Project Overview
|
||||
|
||||
The BMAD Method Documentation Enhancement Project was initiated to create a comprehensive, consistent, and user-friendly documentation ecosystem for the BMAD Method. The project aimed to provide detailed guidance for all personas, processes, and integration points within the methodology, enabling teams to effectively implement the BMAD Method in their software development workflows.
|
||||
|
||||
## Project Goals
|
||||
|
||||
1. **Create Comprehensive Persona Documentation**: Develop detailed documentation for each BMAD Method persona
|
||||
2. **Establish Integration Architecture**: Document cross-persona workflows and integration points
|
||||
3. **Define Quality Standards**: Create clear quality criteria for all deliverables and processes
|
||||
4. **Build Template Library**: Develop templates for all key artifacts
|
||||
5. **Provide Training Materials**: Create quick start guides and comprehensive training resources
|
||||
6. **Demonstrate with Examples**: Create practical examples showing the methodology in action
|
||||
|
||||
## Project Timeline
|
||||
|
||||
The project was executed over four sprints:
|
||||
|
||||
```mermaid title="Project Timeline" type="diagram"
|
||||
gantt
|
||||
title BMAD Documentation Enhancement Project
|
||||
dateFormat YYYY-MM-DD
|
||||
section Planning
|
||||
Project Initiation :done, 2023-05-01, 2023-05-07
|
||||
Requirements Analysis :done, 2023-05-08, 2023-05-14
|
||||
section Sprint 1
|
||||
Core Documentation :done, 2023-05-15, 2023-05-28
|
||||
section Sprint 2
|
||||
Analyst & PM Documentation :done, 2023-05-29, 2023-06-11
|
||||
section Sprint 3
|
||||
Architect & UX/UI Documentation :done, 2023-06-12, 2023-06-25
|
||||
section Sprint 4
|
||||
Developer & SM Documentation :done, 2023-06-26, 2023-07-09
|
||||
Final Integration :active, 2023-07-03, 2023-07-09
|
||||
```
|
||||
|
||||
### Sprint 1: Core Documentation
|
||||
|
||||
- Created project brief and requirements
|
||||
- Established documentation standards and templates
|
||||
- Developed core methodology documentation
|
||||
- Created initial integration architecture
|
||||
|
||||
### Sprint 2: Business Layer Documentation
|
||||
|
||||
- Developed Business Analyst documentation package
|
||||
- Created Product Manager documentation package
|
||||
- Established business layer integration points
|
||||
- Created business layer templates and examples
|
||||
|
||||
### Sprint 3: Design Layer Documentation
|
||||
|
||||
- Developed System Architect documentation package
|
||||
- Created UX/UI Architect documentation package
|
||||
- Developed Design Architect documentation package
|
||||
- Created Product Owner documentation package
|
||||
- Established design layer integration points
|
||||
|
||||
### Sprint 4: Implementation Layer Documentation
|
||||
|
||||
- Developed Developer documentation package
|
||||
- Created Scrum Master documentation package
|
||||
- Finalized integration documentation
|
||||
- Created comprehensive documentation map
|
||||
- Prepared release notes and project summary
|
||||
|
||||
## Deliverables
|
||||
|
||||
### Core Documentation
|
||||
|
||||
- **Comprehensive Integration Guide**: Holistic view of how all BMAD Method components work together
|
||||
- **Documentation Map**: Complete inventory and navigation guide for all documentation
|
||||
- **Release Notes**: Detailed information about the release
|
||||
- **Project Summary**: Overview of the documentation enhancement project
|
||||
|
||||
### Persona Documentation Packages
|
||||
|
||||
Each persona now has a complete documentation package including:
|
||||
|
||||
- **Comprehensive Guide**: Detailed explanation of the persona's role and responsibilities
|
||||
- **Integration Guide**: How the persona integrates with other roles and processes
|
||||
- **Quick Start Guide**: Getting started with the persona
|
||||
- **Template Guide**: Templates specific to the persona's responsibilities
|
||||
- **Quality Standards**: Quality criteria for the persona's deliverables
|
||||
- **Workflow Mapping**: Detailed workflows for the persona's key activities
|
||||
- **Success Metrics**: Metrics for measuring the persona's effectiveness
|
||||
|
||||
### Process Documentation
|
||||
|
||||
- **Integration Points**: Documentation of all integration points between personas and processes
|
||||
- **Integration Architecture**: Technical architecture for system integration
|
||||
- **Persona Workflows**: Detailed workflows for each persona
|
||||
- **Orchestrator Mechanics**: How the BMAD Method orchestrator works
|
||||
|
||||
### Training Materials
|
||||
|
||||
- **Quick Start Guides**: Getting started with the BMAD Method
|
||||
- **IDE-Specific Guides**: How to use the BMAD Method in different IDE environments
|
||||
- **Common Use Cases**: Practical examples of the BMAD Method in action
|
||||
|
||||
## Key Achievements
|
||||
|
||||
1. **Complete Documentation Ecosystem**: Created a comprehensive documentation ecosystem covering all aspects of the BMAD Method
|
||||
2. **Consistent Documentation Structure**: Established a consistent structure across all documentation
|
||||
3. **Clear Integration Guidance**: Provided clear guidance on how different personas and processes integrate
|
||||
4. **Practical Templates and Examples**: Developed practical templates and examples for all key artifacts
|
||||
5. **Accessible Training Materials**: Created accessible training materials for all user types
|
||||
6. **Visual Documentation**: Enhanced documentation with diagrams and visual aids
|
||||
|
||||
## Metrics and Impact
|
||||
|
||||
### Documentation Metrics
|
||||
|
||||
- **Total Documents**: 100+
|
||||
- **Total Pages**: 500+
|
||||
- **Diagrams and Visualizations**: 50+
|
||||
- **Templates**: 20+
|
||||
- **Examples**: 15+
|
||||
|
||||
### Expected Impact
|
||||
|
||||
- **Reduced Onboarding Time**: 50% reduction in time to onboard new team members
|
||||
- **Improved Collaboration**: Enhanced cross-functional collaboration through clear integration guidance
|
||||
- **Higher Quality Deliverables**: Improved quality through clear standards and templates
|
||||
- **Faster Implementation**: Accelerated BMAD Method implementation through practical guidance
|
||||
- **Reduced Support Needs**: Decreased need for support through comprehensive self-service documentation
|
||||
|
||||
## Lessons Learned
|
||||
|
||||
### What Went Well
|
||||
|
||||
1. **Structured Approach**: The sprint-based approach allowed for incremental development and validation
|
||||
2. **Consistent Templates**: Using consistent templates across all documentation improved quality and user experience
|
||||
3. **Visual Documentation**: Diagrams and visual aids significantly enhanced understanding
|
||||
4. **Cross-Linking**: Extensive cross-linking improved navigation and discoverability
|
||||
5. **Practical Examples**: Real-world examples made the documentation more actionable
|
||||
|
||||
### Challenges and Solutions
|
||||
|
||||
1. **Challenge**: Maintaining consistency across a large documentation ecosystem
|
||||
**Solution**: Established clear documentation standards and templates
|
||||
|
||||
2. **Challenge**: Documenting complex integration points
|
||||
**Solution**: Used visual diagrams and step-by-step workflows
|
||||
|
||||
3. **Challenge**: Balancing detail with usability
|
||||
**Solution**: Created layered documentation with quick start guides and comprehensive references
|
||||
|
||||
4. **Challenge**: Ensuring accuracy across technical domains
|
||||
**Solution**: Involved domain experts in review and validation
|
||||
|
||||
5. **Challenge**: Managing documentation dependencies
|
||||
**Solution**: Created a documentation map and clear cross-references
|
||||
|
||||
## Future Recommendations
|
||||
|
||||
1. **Complete DevOps Documentation**: Develop the DevOps Engineer documentation package
|
||||
2. **Create Video Tutorials**: Supplement written documentation with video tutorials
|
||||
3. **Develop Interactive Examples**: Create interactive examples for key concepts
|
||||
4. **Establish Feedback Loop**: Implement a system for collecting and incorporating user feedback
|
||||
5. **Regular Updates**: Schedule regular documentation reviews and updates
|
||||
6. **Expand Mobile Guidance**: Enhance mobile-specific guidance and examples
|
||||
7. **Localization**: Consider translating documentation for international teams
|
||||
|
||||
## Conclusion
|
||||
|
||||
The BMAD Method Documentation Enhancement Project has successfully created a comprehensive, consistent, and user-friendly documentation ecosystem for the BMAD Method. The documentation now provides detailed guidance for all personas, processes, and integration points within the methodology, enabling teams to effectively implement the BMAD Method in their software development workflows.
|
||||
|
||||
The project has laid a strong foundation for the continued evolution of the BMAD Method, providing the resources needed for successful adoption and implementation. With the completion of this project, teams now have access to the guidance they need to leverage the full power of the BMAD Method in their software development efforts.
|
||||
|
||||
---
|
||||
|
||||
*This project summary provides an overview of the BMAD Method Documentation Enhancement Project. For detailed information about the BMAD Method, refer to the comprehensive documentation available in the repository.*
|
||||
|
|
@ -0,0 +1,184 @@
|
|||
# BMAD Method: Release Notes
|
||||
|
||||
## Version 1.0.0 (2023-06-08)
|
||||
|
||||
### Overview
|
||||
|
||||
We are excited to announce the official release of the BMAD Method documentation suite version 1.0.0. This comprehensive release represents the culmination of the Documentation Enhancement Project, which has significantly expanded and improved the BMAD Method documentation ecosystem.
|
||||
|
||||
The BMAD Method is a structured approach to software development that leverages AI-assisted personas to streamline the development process. This release provides comprehensive documentation for all personas, processes, and integration points within the methodology.
|
||||
|
||||
### Key Features
|
||||
|
||||
- **Complete Persona Documentation**: Comprehensive guides for all BMAD Method personas
|
||||
- **Integration Architecture**: Detailed documentation of cross-persona workflows and integration points
|
||||
- **Quality Standards**: Clear quality criteria for all deliverables and processes
|
||||
- **Template Library**: Extensive collection of templates for all key artifacts
|
||||
- **Training Materials**: Quick start guides and comprehensive training resources
|
||||
- **Example Projects**: Practical examples demonstrating the methodology in action
|
||||
|
||||
### New Documentation
|
||||
|
||||
#### Core Documentation
|
||||
|
||||
- **Comprehensive Integration Guide**: Holistic view of how all BMAD Method components work together
|
||||
- **Documentation Map**: Complete inventory and navigation guide for all documentation
|
||||
- **Release Notes**: Detailed information about this release
|
||||
|
||||
#### Persona Documentation Packages
|
||||
|
||||
Each persona now has a complete documentation package including:
|
||||
|
||||
- **Comprehensive Guide**: Detailed explanation of the persona's role and responsibilities
|
||||
- **Integration Guide**: How the persona integrates with other roles and processes
|
||||
- **Quick Start Guide**: Getting started with the persona
|
||||
- **Template Guide**: Templates specific to the persona's responsibilities
|
||||
- **Quality Standards**: Quality criteria for the persona's deliverables
|
||||
- **Workflow Mapping**: Detailed workflows for the persona's key activities
|
||||
- **Success Metrics**: Metrics for measuring the persona's effectiveness
|
||||
|
||||
##### Business Analyst Documentation
|
||||
|
||||
- Comprehensive guide for Business Analysts
|
||||
- Integration guide for Business Analysts
|
||||
- Quick start guide for Business Analysts
|
||||
- Template guide for Business Analysts
|
||||
- Quality standards for Business Analysts
|
||||
- Workflow mapping for Business Analysts
|
||||
|
||||
##### Product Manager Documentation
|
||||
|
||||
- Comprehensive guide for Product Managers
|
||||
- Integration guide for Product Managers
|
||||
- Quick start guide for Product Managers
|
||||
- Task library for Product Managers
|
||||
|
||||
##### System Architect Documentation
|
||||
|
||||
- Comprehensive guide for System Architects
|
||||
- Integration guide for System Architects
|
||||
- Quick start guide for System Architects
|
||||
- Task library for System Architects
|
||||
- Template guide for System Architects
|
||||
- Quality standards for System Architects
|
||||
|
||||
##### UX/UI Architect Documentation
|
||||
|
||||
- Comprehensive guide for UX/UI Architects
|
||||
- Integration guide for UX/UI Architects
|
||||
- Quick start guide for UX/UI Architects
|
||||
- Quality assurance guide for UX/UI Architects
|
||||
- User guide for UX/UI Architects
|
||||
|
||||
##### Design Architect Documentation
|
||||
|
||||
- Comprehensive guide for Design Architects
|
||||
- Integration guide for Design Architects
|
||||
- Quick start guide for Design Architects
|
||||
- Template guide for Design Architects
|
||||
- Quality standards for Design Architects
|
||||
- Workflow mapping for Design Architects
|
||||
- Success metrics for Design Architects
|
||||
|
||||
##### Product Owner Documentation
|
||||
|
||||
- Comprehensive guide for Product Owners
|
||||
- Integration guide for Product Owners
|
||||
- Quick start guide for Product Owners
|
||||
- Template guide for Product Owners
|
||||
- Quality standards for Product Owners
|
||||
- Workflow mapping for Product Owners
|
||||
- Success metrics for Product Owners
|
||||
|
||||
##### Developer Documentation
|
||||
|
||||
- Comprehensive guide for Developers
|
||||
- Integration guide for Developers
|
||||
- Quick start guide for Developers
|
||||
- Template guide for Developers
|
||||
- Quality standards for Developers
|
||||
- Workflow mapping for Developers
|
||||
- Success metrics for Developers
|
||||
|
||||
##### Scrum Master Documentation
|
||||
|
||||
- Comprehensive guide for Scrum Masters
|
||||
- Template guide for Scrum Masters
|
||||
- Quality standards for Scrum Masters
|
||||
- Workflow mapping for Scrum Masters
|
||||
- Success metrics for Scrum Masters
|
||||
|
||||
#### Process Documentation
|
||||
|
||||
- Integration points documentation
|
||||
- Integration architecture
|
||||
- Persona workflow documentation
|
||||
- Orchestrator mechanics
|
||||
- Comprehensive integration guide
|
||||
|
||||
#### Training Materials
|
||||
|
||||
- IDE environment quickstart
|
||||
- Web environment quickstart
|
||||
- BMAD Method quickstart
|
||||
- Common use cases guide
|
||||
- IDE-specific guides (Claude Code, Cline, Cursor AI, Roocode)
|
||||
|
||||
### Improvements
|
||||
|
||||
- **Enhanced Navigation**: Improved documentation structure and cross-linking
|
||||
- **Consistent Formatting**: Standardized formatting across all documentation
|
||||
- **Visual Clarity**: Added diagrams and visual aids to enhance understanding
|
||||
- **Practical Examples**: Expanded example library with practical use cases
|
||||
- **Comprehensive Coverage**: Filled gaps in the documentation ecosystem
|
||||
|
||||
### Technical Details
|
||||
|
||||
- **Documentation Format**: All documentation is provided in Markdown format
|
||||
- **Version Control**: All documentation is version controlled in the repository
|
||||
- **Accessibility**: Documentation is designed to be accessible to all users
|
||||
- **Searchability**: Documentation is organized for easy discovery and search
|
||||
|
||||
### Known Issues
|
||||
|
||||
- DevOps Engineer documentation package is not yet complete
|
||||
- Some advanced integration scenarios require additional examples
|
||||
- Mobile-specific guidance needs expansion
|
||||
|
||||
### Upcoming Features
|
||||
|
||||
- DevOps Engineer documentation package
|
||||
- Advanced integration examples
|
||||
- Mobile-specific guidance
|
||||
- Additional example projects
|
||||
- Video tutorials
|
||||
|
||||
### Installation and Access
|
||||
|
||||
All documentation is available in the BMAD Method repository. To access:
|
||||
|
||||
1. Clone the repository
|
||||
2. Navigate to the docs directory
|
||||
3. Start with the README.md file for an overview
|
||||
4. Use the documentation map to find specific documentation
|
||||
|
||||
### Support
|
||||
|
||||
For support with the BMAD Method documentation:
|
||||
|
||||
- Review the documentation map for navigation assistance
|
||||
- Check the troubleshooting guide for common issues
|
||||
- Submit issues through the repository issue tracker
|
||||
- Contact the documentation team for additional assistance
|
||||
|
||||
### Contributors
|
||||
|
||||
The BMAD Method Documentation Enhancement Project was completed by the Documentation Team with contributions from all persona specialists.
|
||||
|
||||
### License
|
||||
|
||||
The BMAD Method documentation is licensed under the terms specified in the LICENSE file.
|
||||
|
||||
---
|
||||
|
||||
Thank you for using the BMAD Method. We hope this documentation helps you successfully implement the methodology in your projects.
|
||||
|
|
@ -0,0 +1,397 @@
|
|||
# Design Architect - Comprehensive Guide
|
||||
|
||||
## Overview
|
||||
|
||||
The **Design Architect** persona in the BMAD Method serves as your **Strategic Design Systems Leader** focused on creating cohesive, scalable design systems that ensure consistency across all user touchpoints. This persona excels at establishing design foundations, component libraries, and design governance that enable teams to build beautiful, accessible, and user-centered experiences at scale.
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
### 🎨 Design Systems Architecture (95% Confidence)
|
||||
- **Design Token Management** - Color systems, typography scales, spacing systems, elevation and shadow systems
|
||||
- **Component Library Design** - Atomic design principles, component hierarchies, design pattern libraries, interaction specifications
|
||||
- **Design System Governance** - Design standards documentation, usage guidelines, quality assurance processes, evolution strategies
|
||||
- **Cross-Platform Consistency** - Multi-platform design systems, responsive design frameworks, accessibility standards, brand consistency
|
||||
|
||||
### ðŸ—ï¸ Information Architecture (90% Confidence)
|
||||
- **Content Strategy & Organization** - Information hierarchies, content modeling, navigation systems, search and findability
|
||||
- **User Flow Design** - Journey mapping, task flow optimization, decision tree design, progressive disclosure strategies
|
||||
- **Interaction Design Patterns** - Micro-interactions, state management, feedback systems, error handling patterns
|
||||
- **Accessibility Architecture** - WCAG compliance, inclusive design principles, assistive technology support, universal design
|
||||
|
||||
### 📠Visual Design Systems (95% Confidence)
|
||||
- **Brand Integration** - Brand guideline translation, visual identity systems, brand consistency frameworks
|
||||
- **Layout Systems** - Grid systems, responsive breakpoints, spacing and rhythm, visual hierarchy principles
|
||||
- **Color and Typography** - Color theory application, contrast and accessibility, typography systems, readability optimization
|
||||
- **Iconography and Imagery** - Icon system design, illustration guidelines, photography standards, visual asset management
|
||||
|
||||
### 🔄 Design Process & Collaboration (85% Confidence)
|
||||
- **Design Workflow Optimization** - Design-to-development handoffs, version control for design assets, collaborative design processes
|
||||
- **Stakeholder Communication** - Design rationale documentation, design review facilitation, cross-functional collaboration
|
||||
- **Design Quality Assurance** - Design review processes, consistency audits, usability validation, design system adoption tracking
|
||||
- **Team Enablement** - Design system training, tool recommendations, best practice documentation, design mentoring
|
||||
|
||||
## Working Process
|
||||
|
||||
### Phase 1: Discovery & Foundation Setting
|
||||
1. **Design Audit & Assessment**
|
||||
- Analyze existing design assets and patterns
|
||||
- Identify inconsistencies and improvement opportunities
|
||||
- Assess current design tool stack and workflows
|
||||
- Document design debt and technical constraints
|
||||
|
||||
2. **Stakeholder Alignment**
|
||||
- Understand business goals and brand requirements
|
||||
- Align with product strategy and user experience vision
|
||||
- Establish design system scope and priorities
|
||||
- Define success metrics and adoption goals
|
||||
|
||||
3. **Foundation Planning**
|
||||
- Define design principles and design philosophy
|
||||
- Establish design token architecture and naming conventions
|
||||
- Plan component hierarchy and design pattern organization
|
||||
- Create design system roadmap and implementation strategy
|
||||
|
||||
### Phase 2: Design System Architecture
|
||||
1. **Core Foundation Development**
|
||||
- Design token system creation (colors, typography, spacing, etc.)
|
||||
- Base component design and specification
|
||||
- Layout system and responsive framework definition
|
||||
- Accessibility standards and guidelines establishment
|
||||
|
||||
2. **Component Library Creation**
|
||||
- Atomic design methodology implementation
|
||||
- Component design and interaction specification
|
||||
- Usage guidelines and best practice documentation
|
||||
- Code-design alignment and handoff specifications
|
||||
|
||||
3. **Pattern Library Development**
|
||||
- Common design pattern identification and documentation
|
||||
- Template and layout pattern creation
|
||||
- Interaction pattern specification and guidelines
|
||||
- Content strategy and messaging pattern development
|
||||
|
||||
### Phase 3: Implementation & Governance
|
||||
1. **Design System Documentation**
|
||||
- Comprehensive design system documentation creation
|
||||
- Usage guidelines and implementation instructions
|
||||
- Code examples and integration guidance
|
||||
- Design tool setup and workflow documentation
|
||||
|
||||
2. **Team Enablement & Training**
|
||||
- Design system training program development
|
||||
- Tool setup and workflow optimization
|
||||
- Best practice sharing and knowledge transfer
|
||||
- Design review process establishment
|
||||
|
||||
3. **Quality Assurance & Evolution**
|
||||
- Design consistency auditing and monitoring
|
||||
- Design system adoption tracking and optimization
|
||||
- Feedback collection and continuous improvement
|
||||
- Design system versioning and update management
|
||||
|
||||
### Phase 4: Scaling & Optimization
|
||||
1. **Cross-Team Collaboration**
|
||||
- Design-development workflow optimization
|
||||
- Cross-functional design review processes
|
||||
- Design system evangelism and adoption support
|
||||
- Stakeholder communication and reporting
|
||||
|
||||
2. **System Evolution & Maintenance**
|
||||
- Design system roadmap planning and execution
|
||||
- Component library expansion and optimization
|
||||
- Design token evolution and management
|
||||
- Design system performance monitoring and improvement
|
||||
|
||||
3. **Innovation & Future Planning**
|
||||
- Emerging design trend evaluation and integration
|
||||
- New technology assessment and adoption planning
|
||||
- Design system scalability planning
|
||||
- Long-term design strategy development
|
||||
|
||||
## Integration with BMAD Method
|
||||
|
||||
### Upstream Integrations
|
||||
- **Receives from**:
|
||||
- Product Managers: Brand guidelines, business requirements, user experience strategy
|
||||
- UX/UI Architects: User research insights, interaction design requirements, component specifications
|
||||
- System Architects: Technical constraints, platform requirements, integration specifications
|
||||
|
||||
### Design System Workflow Integration
|
||||
```markdown
|
||||
# Typical Design System Flow
|
||||
1. **Requirements Gathering**: Receive design requirements from UX/UI and Product teams
|
||||
2. **System Architecture**: Design comprehensive design system architecture
|
||||
3. **Component Development**: Create scalable component library and pattern documentation
|
||||
4. **Implementation Support**: Guide development teams in design system adoption
|
||||
5. **Quality Assurance**: Monitor design consistency and system adoption
|
||||
6. **Evolution Planning**: Continuously improve and evolve design system based on feedback
|
||||
```
|
||||
|
||||
### Cross-Functional Collaboration
|
||||
- **With UX/UI Architects**: Translate user experience requirements into scalable design systems
|
||||
- **With Developers**: Ensure design-code alignment and implementation feasibility
|
||||
- **With Product Managers**: Align design systems with business goals and brand strategy
|
||||
- **With Content Teams**: Develop content strategy and messaging patterns
|
||||
- **With QA Teams**: Establish design quality assurance processes and validation criteria
|
||||
|
||||
### Downstream Handoffs
|
||||
- **Delivers to**:
|
||||
- Development Teams: Comprehensive design system documentation and component specifications
|
||||
- UX/UI Teams: Design system tools, components, and usage guidelines
|
||||
- Product Teams: Brand-aligned design patterns and user experience frameworks
|
||||
- QA Teams: Design quality criteria and validation processes
|
||||
|
||||
## Advanced Usage Patterns
|
||||
|
||||
### Multi-Platform Design Systems
|
||||
```markdown
|
||||
# Cross-Platform Strategy
|
||||
1. **Platform Analysis**: Assess design requirements across web, mobile, and other platforms
|
||||
2. **Token Architecture**: Create platform-agnostic design token system
|
||||
3. **Component Adaptation**: Design components that adapt to platform-specific constraints
|
||||
4. **Consistency Framework**: Establish cross-platform consistency guidelines
|
||||
5. **Implementation Guidance**: Provide platform-specific implementation documentation
|
||||
```
|
||||
|
||||
### Design System Governance
|
||||
```markdown
|
||||
# Governance Framework
|
||||
1. **Standards Definition**: Establish design standards and quality criteria
|
||||
2. **Review Processes**: Create design review and approval workflows
|
||||
3. **Adoption Tracking**: Monitor design system usage and compliance
|
||||
4. **Evolution Management**: Manage design system updates and versioning
|
||||
5. **Training Programs**: Develop ongoing education and enablement initiatives
|
||||
```
|
||||
|
||||
### Accessibility-First Design
|
||||
```markdown
|
||||
# Inclusive Design Approach
|
||||
1. **Accessibility Audit**: Assess current accessibility compliance and gaps
|
||||
2. **Standards Integration**: Embed WCAG guidelines into design system foundation
|
||||
3. **Component Accessibility**: Ensure all components meet accessibility requirements
|
||||
4. **Testing Framework**: Establish accessibility testing and validation processes
|
||||
5. **Documentation**: Create comprehensive accessibility guidelines and best practices
|
||||
```
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### Design System Creation
|
||||
- Establish comprehensive design system from scratch
|
||||
- Create component libraries and pattern documentation
|
||||
- Develop design token architecture and management
|
||||
- Implement design-development workflow integration
|
||||
|
||||
### Design System Evolution
|
||||
- Audit and improve existing design systems
|
||||
- Expand component libraries and pattern collections
|
||||
- Optimize design system performance and adoption
|
||||
- Integrate new design trends and technologies
|
||||
|
||||
### Brand Integration Projects
|
||||
- Translate brand guidelines into digital design systems
|
||||
- Ensure brand consistency across all user touchpoints
|
||||
- Develop brand-specific component variations
|
||||
- Create brand compliance monitoring and validation
|
||||
|
||||
### Accessibility Improvement
|
||||
- Conduct comprehensive accessibility audits
|
||||
- Implement WCAG compliance across design systems
|
||||
- Create inclusive design guidelines and training
|
||||
- Establish accessibility testing and validation processes
|
||||
|
||||
## Troubleshooting Guide
|
||||
|
||||
### Common Design System Challenges
|
||||
|
||||
**Challenge**: Inconsistent design implementation across teams
|
||||
**Solution**: Strengthen design system documentation, provide implementation training, establish design review processes
|
||||
|
||||
**Challenge**: Low design system adoption rates
|
||||
**Solution**: Improve design system usability, provide better tooling, create adoption incentives and support
|
||||
|
||||
**Challenge**: Design-development disconnect
|
||||
**Solution**: Improve design-code handoff processes, create shared design-development tools, establish regular collaboration sessions
|
||||
|
||||
**Challenge**: Design system maintenance overhead
|
||||
**Solution**: Automate design system updates, establish clear governance processes, create sustainable maintenance workflows
|
||||
|
||||
### Quality Assurance Issues
|
||||
|
||||
**Challenge**: Design inconsistencies across products
|
||||
**Solution**: Implement design auditing processes, create consistency monitoring tools, establish design quality metrics
|
||||
|
||||
**Challenge**: Accessibility compliance gaps
|
||||
**Solution**: Integrate accessibility testing into design workflows, provide accessibility training, establish compliance monitoring
|
||||
|
||||
**Challenge**: Design system performance issues
|
||||
**Solution**: Optimize design system architecture, implement performance monitoring, create efficiency improvement processes
|
||||
|
||||
### Collaboration and Communication Issues
|
||||
|
||||
**Challenge**: Stakeholder resistance to design system adoption
|
||||
**Solution**: Demonstrate design system value, provide comprehensive training, create adoption support programs
|
||||
|
||||
**Challenge**: Cross-team design coordination difficulties
|
||||
**Solution**: Establish clear communication protocols, create shared design tools, implement regular design sync meetings
|
||||
|
||||
**Challenge**: Design system evolution conflicts
|
||||
**Solution**: Create clear change management processes, establish design system governance, implement version control strategies
|
||||
|
||||
## Design System Architecture Framework
|
||||
|
||||
### Design Token Hierarchy
|
||||
```markdown
|
||||
# Token Architecture
|
||||
1. **Global Tokens**: Brand colors, base typography, fundamental spacing
|
||||
2. **Alias Tokens**: Semantic color assignments, contextual spacing, component-specific values
|
||||
3. **Component Tokens**: Component-specific design values, state variations, responsive adaptations
|
||||
4. **Platform Tokens**: Platform-specific adaptations, device-specific optimizations
|
||||
|
||||
# Token Categories
|
||||
- **Color System**: Primary, secondary, neutral, semantic, state colors
|
||||
- **Typography**: Font families, sizes, weights, line heights, letter spacing
|
||||
- **Spacing**: Base unit, scale ratios, component spacing, layout spacing
|
||||
- **Elevation**: Shadow systems, z-index scales, layering principles
|
||||
- **Motion**: Animation durations, easing functions, transition patterns
|
||||
```
|
||||
|
||||
### Component Architecture
|
||||
```markdown
|
||||
# Atomic Design Structure
|
||||
1. **Atoms**: Basic building blocks (buttons, inputs, icons, typography)
|
||||
2. **Molecules**: Simple component combinations (search forms, navigation items)
|
||||
3. **Organisms**: Complex component assemblies (headers, product cards, forms)
|
||||
4. **Templates**: Page-level layouts and structure patterns
|
||||
5. **Pages**: Specific page implementations and content examples
|
||||
|
||||
# Component Specifications
|
||||
- **Visual Design**: Appearance, states, variations, responsive behavior
|
||||
- **Interaction Design**: User interactions, micro-animations, feedback patterns
|
||||
- **Content Guidelines**: Content strategy, messaging patterns, tone of voice
|
||||
- **Technical Specifications**: Implementation requirements, accessibility standards
|
||||
```
|
||||
|
||||
### Documentation Structure
|
||||
```markdown
|
||||
# Design System Documentation
|
||||
1. **Getting Started**: Introduction, setup instructions, basic usage
|
||||
2. **Design Principles**: Philosophy, values, decision-making framework
|
||||
3. **Foundation**: Design tokens, color, typography, spacing, iconography
|
||||
4. **Components**: Component library, usage guidelines, code examples
|
||||
5. **Patterns**: Design patterns, templates, best practices
|
||||
6. **Resources**: Tools, downloads, support, contribution guidelines
|
||||
```
|
||||
|
||||
## Tools and Technologies
|
||||
|
||||
### Design Tools
|
||||
```markdown
|
||||
# Primary Design Tools
|
||||
- **Figma**: Collaborative design, component libraries, design systems, prototyping
|
||||
- **Sketch**: Design creation, symbol libraries, plugin ecosystem
|
||||
- **Adobe XD**: Design and prototyping, component systems, collaboration features
|
||||
- **Framer**: Advanced prototyping, interaction design, design system management
|
||||
|
||||
# Specialized Tools
|
||||
- **Zeroheight**: Design system documentation, style guide creation
|
||||
- **Storybook**: Component development, documentation, testing
|
||||
- **Abstract**: Design version control, collaboration, asset management
|
||||
- **InVision DSM**: Design system management, documentation, collaboration
|
||||
```
|
||||
|
||||
### Development Integration Tools
|
||||
```markdown
|
||||
# Design-Development Bridge
|
||||
- **Design Tokens**: Style Dictionary, Theo, Design Tokens Community Group format
|
||||
- **Component Libraries**: React, Vue, Angular component implementations
|
||||
- **CSS Frameworks**: Tailwind CSS, Styled Components, CSS-in-JS solutions
|
||||
- **Documentation**: Storybook, Docusaurus, GitBook, Notion
|
||||
|
||||
# Quality Assurance Tools
|
||||
- **Visual Testing**: Percy, Chromatic, Applitools for visual regression testing
|
||||
- **Accessibility Testing**: axe, WAVE, Lighthouse for accessibility validation
|
||||
- **Design Linting**: Design lint tools, automated design quality checks
|
||||
```
|
||||
|
||||
### Collaboration and Management Tools
|
||||
```markdown
|
||||
# Project Management
|
||||
- **Design Project Tracking**: Asana, Monday.com, Linear for design system roadmaps
|
||||
- **Version Control**: Git for design system code, Abstract for design files
|
||||
- **Communication**: Slack, Microsoft Teams for design system discussions
|
||||
- **Knowledge Management**: Confluence, Notion for design system documentation
|
||||
|
||||
# Asset Management
|
||||
- **Design Asset Libraries**: Figma libraries, Sketch libraries, Adobe Creative Cloud
|
||||
- **Icon Management**: Iconify, Feather Icons, custom icon libraries
|
||||
- **Image Optimization**: TinyPNG, ImageOptim, automated image processing
|
||||
```
|
||||
|
||||
## Best Practices and Guidelines
|
||||
|
||||
### Design System Development
|
||||
```markdown
|
||||
# Development Best Practices
|
||||
1. **Start Small**: Begin with core components and expand gradually
|
||||
2. **Design for Scale**: Consider future growth and platform expansion
|
||||
3. **Maintain Consistency**: Establish clear naming conventions and organizational patterns
|
||||
4. **Document Everything**: Create comprehensive documentation and usage guidelines
|
||||
5. **Test Thoroughly**: Validate designs across devices, browsers, and accessibility tools
|
||||
6. **Iterate Continuously**: Gather feedback and improve design system based on usage
|
||||
```
|
||||
|
||||
### Design System Governance
|
||||
```markdown
|
||||
# Governance Principles
|
||||
1. **Clear Ownership**: Establish design system ownership and responsibility
|
||||
2. **Change Management**: Create processes for design system updates and evolution
|
||||
3. **Quality Standards**: Define and maintain design quality criteria
|
||||
4. **Adoption Support**: Provide training and support for design system adoption
|
||||
5. **Performance Monitoring**: Track design system usage and effectiveness
|
||||
6. **Community Building**: Foster design system community and collaboration
|
||||
```
|
||||
|
||||
### Accessibility and Inclusion
|
||||
```markdown
|
||||
# Inclusive Design Practices
|
||||
1. **Universal Design**: Design for diverse abilities and use cases
|
||||
2. **WCAG Compliance**: Ensure all components meet accessibility standards
|
||||
3. **Color Accessibility**: Maintain sufficient contrast ratios and color-blind friendly palettes
|
||||
4. **Keyboard Navigation**: Ensure all interactions are keyboard accessible
|
||||
5. **Screen Reader Support**: Provide appropriate semantic markup and ARIA labels
|
||||
6. **Testing with Users**: Include users with disabilities in design validation
|
||||
```
|
||||
|
||||
## Commands and Quick Actions
|
||||
|
||||
### Design System Commands
|
||||
```bash
|
||||
# Design System Management
|
||||
*audit-design-system # Analyze current design system consistency
|
||||
*create-component-spec # Generate component specification template
|
||||
*validate-accessibility # Check accessibility compliance
|
||||
*generate-tokens # Create design token documentation
|
||||
*review-brand-alignment # Assess brand consistency across designs
|
||||
```
|
||||
|
||||
### Quality Assurance Commands
|
||||
```bash
|
||||
# Design Quality Checks
|
||||
*design-consistency-check # Validate design consistency across components
|
||||
*accessibility-audit # Comprehensive accessibility assessment
|
||||
*performance-review # Analyze design system performance impact
|
||||
*usage-analytics # Review design system adoption and usage
|
||||
```
|
||||
|
||||
### Collaboration Commands
|
||||
```bash
|
||||
# Team Collaboration
|
||||
*design-review-prep # Prepare design review materials and agenda
|
||||
*handoff-documentation # Generate design-development handoff documentation
|
||||
*training-materials # Create design system training and onboarding materials
|
||||
*stakeholder-report # Generate design system progress and impact report
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*This comprehensive guide provides the foundation for effectively leveraging the Design Architect persona in your BMAD Method implementation. For integration details and quick start instructions, refer to the Integration Guide and Quick Start Guide.*
|
||||
|
|
@ -0,0 +1,455 @@
|
|||
# Design Architect - Integration Guide
|
||||
|
||||
## Environment Setup
|
||||
|
||||
### Design Tool Environment Setup
|
||||
The Design Architect persona is optimized for design-focused workflows with comprehensive design tool integration.
|
||||
|
||||
#### Primary Design Environment Configuration
|
||||
1. **Figma Integration Setup**
|
||||
```markdown
|
||||
# Figma Workspace Configuration
|
||||
1. Create BMAD Method design system workspace
|
||||
2. Set up component library structure following atomic design principles
|
||||
3. Configure design token management system
|
||||
4. Establish team libraries and sharing permissions
|
||||
5. Install essential plugins: Design Tokens, A11y - Color Contrast Checker, Content Reel
|
||||
```
|
||||
|
||||
2. **Design System Documentation Platform**
|
||||
```markdown
|
||||
# Documentation Setup Options
|
||||
|
||||
**Option 1: Zeroheight**
|
||||
- Connect Figma libraries for automatic component sync
|
||||
- Set up design token documentation
|
||||
- Configure team access and permissions
|
||||
|
||||
**Option 2: Storybook**
|
||||
- Install Storybook for component documentation
|
||||
- Configure design token addon
|
||||
- Set up visual testing integration
|
||||
|
||||
**Option 3: Custom Documentation**
|
||||
- Set up GitBook or Notion workspace
|
||||
- Create design system documentation structure
|
||||
- Establish update and maintenance workflows
|
||||
```
|
||||
|
||||
3. **Design Token Management**
|
||||
```bash
|
||||
# Style Dictionary Setup
|
||||
npm install style-dictionary
|
||||
|
||||
# Create token structure
|
||||
mkdir design-tokens
|
||||
cd design-tokens
|
||||
mkdir properties
|
||||
|
||||
# Initialize Style Dictionary configuration
|
||||
style-dictionary init basic
|
||||
```
|
||||
|
||||
### Development Environment Integration
|
||||
For teams requiring design-development integration, the Design Architect persona integrates with development workflows.
|
||||
|
||||
#### Configuration Steps
|
||||
1. **Design System Repository Setup**
|
||||
```bash
|
||||
# Create design system repository
|
||||
git clone <design-system-repo>
|
||||
cd design-system
|
||||
|
||||
# Install dependencies
|
||||
npm install
|
||||
|
||||
# Set up development environment
|
||||
npm run setup
|
||||
npm run storybook
|
||||
```
|
||||
|
||||
2. **Design-Development Workflow Integration**
|
||||
```markdown
|
||||
# Workflow Configuration
|
||||
1. Set up design file version control (Abstract or Git LFS)
|
||||
2. Configure automated design token generation
|
||||
3. Establish design-code handoff processes
|
||||
4. Set up visual regression testing
|
||||
5. Create design system deployment pipeline
|
||||
```
|
||||
|
||||
## BMAD Method Workflow Integration
|
||||
|
||||
### Phase 1: Design System Strategy and Planning
|
||||
|
||||
#### Entry Points
|
||||
The Design Architect typically enters the workflow during design system planning or when design consistency issues are identified.
|
||||
|
||||
```markdown
|
||||
# Design System Initiation Triggers
|
||||
- **New Product Development**: When starting new products requiring design consistency
|
||||
- **Design Debt Accumulation**: When design inconsistencies impact user experience
|
||||
- **Brand Evolution**: When brand updates require design system alignment
|
||||
- **Scale Challenges**: When design team growth requires systematic approaches
|
||||
- **Platform Expansion**: When expanding to new platforms or devices
|
||||
```
|
||||
|
||||
#### Handoff Procedures
|
||||
```markdown
|
||||
# From Product Manager (John)
|
||||
- Receive brand guidelines and business requirements
|
||||
- Understand product strategy and user experience vision
|
||||
- Clarify design system scope and success criteria
|
||||
- Align on design system roadmap and priorities
|
||||
|
||||
# From UX/UI Architect
|
||||
- Receive user research insights and interaction design requirements
|
||||
- Understand component specifications and user experience patterns
|
||||
- Collaborate on design system architecture and component hierarchy
|
||||
- Align on accessibility requirements and inclusive design principles
|
||||
|
||||
# From System Architect (Fred)
|
||||
- Understand technical constraints and platform requirements
|
||||
- Collaborate on design-development integration strategies
|
||||
- Align on component implementation approaches
|
||||
- Coordinate on performance and scalability considerations
|
||||
```
|
||||
|
||||
### Phase 2: Design System Architecture and Development
|
||||
|
||||
#### Core Design System Workflow
|
||||
```markdown
|
||||
# Design System Development Process
|
||||
1. **Foundation Definition**: Establish design tokens, principles, and core guidelines
|
||||
2. **Component Architecture**: Design atomic components and pattern libraries
|
||||
3. **Documentation Creation**: Develop comprehensive usage guidelines and specifications
|
||||
4. **Implementation Support**: Guide development teams in design system adoption
|
||||
5. **Quality Assurance**: Monitor design consistency and system effectiveness
|
||||
6. **Evolution Management**: Continuously improve and expand design system capabilities
|
||||
```
|
||||
|
||||
#### Cross-Functional Integration Points
|
||||
```markdown
|
||||
# Design System Collaboration
|
||||
**With UX/UI Teams**:
|
||||
- Translate user experience requirements into scalable design patterns
|
||||
- Collaborate on component design and interaction specifications
|
||||
- Ensure design system supports user research insights and usability requirements
|
||||
|
||||
**With Development Teams**:
|
||||
- Provide detailed component specifications and implementation guidelines
|
||||
- Collaborate on design-code handoff processes and tooling
|
||||
- Support design system integration and troubleshooting
|
||||
|
||||
**With Product Teams**:
|
||||
- Align design system with business goals and brand strategy
|
||||
- Communicate design system value and adoption benefits
|
||||
- Coordinate design system roadmap with product development priorities
|
||||
```
|
||||
|
||||
### Phase 3: Implementation and Adoption
|
||||
|
||||
#### Design System Deployment
|
||||
```markdown
|
||||
# Deployment Strategy
|
||||
1. **Pilot Implementation**: Start with core components and key product areas
|
||||
2. **Team Training**: Provide comprehensive design system education and support
|
||||
3. **Gradual Rollout**: Expand design system usage across teams and products
|
||||
4. **Adoption Monitoring**: Track design system usage and effectiveness
|
||||
5. **Feedback Integration**: Collect and incorporate user feedback for improvements
|
||||
6. **Scale Optimization**: Optimize design system for organization-wide adoption
|
||||
```
|
||||
|
||||
#### Downstream Handoffs
|
||||
```markdown
|
||||
# To Development Teams
|
||||
- Comprehensive design system documentation and component specifications
|
||||
- Design token files and implementation guidelines
|
||||
- Code examples and integration instructions
|
||||
- Quality assurance criteria and validation processes
|
||||
|
||||
# To UX/UI Teams
|
||||
- Design system component libraries and pattern documentation
|
||||
- Usage guidelines and best practice recommendations
|
||||
- Design tool setup and workflow optimization
|
||||
- Design quality criteria and review processes
|
||||
|
||||
# To Product Teams
|
||||
- Brand-aligned design patterns and user experience frameworks
|
||||
- Design system adoption metrics and success criteria
|
||||
- Design consistency monitoring and reporting tools
|
||||
- Design system roadmap and evolution planning
|
||||
```
|
||||
|
||||
## Third-Party Tool Integrations
|
||||
|
||||
### Design Tool Ecosystem Integration
|
||||
|
||||
#### Figma Integration
|
||||
```markdown
|
||||
# Figma Ecosystem Setup
|
||||
**Core Figma Features**:
|
||||
- Component libraries with variants and properties
|
||||
- Design token management with variables
|
||||
- Auto-layout and responsive design systems
|
||||
- Team collaboration and sharing capabilities
|
||||
|
||||
**Essential Plugins**:
|
||||
- **Design Tokens**: Sync design tokens between Figma and code
|
||||
- **A11y - Color Contrast Checker**: Validate accessibility compliance
|
||||
- **Content Reel**: Manage realistic content for design validation
|
||||
- **Stark**: Comprehensive accessibility testing and validation
|
||||
- **Component Utilities**: Advanced component management and organization
|
||||
|
||||
**Integration Setup**:
|
||||
1. Install and configure essential plugins
|
||||
2. Set up design token synchronization workflows
|
||||
3. Establish component library organization and naming conventions
|
||||
4. Configure team access and collaboration permissions
|
||||
```
|
||||
|
||||
#### Design System Documentation Tools
|
||||
```markdown
|
||||
# Documentation Platform Options
|
||||
|
||||
**Zeroheight Integration**:
|
||||
- Automatic Figma component synchronization
|
||||
- Design token documentation and management
|
||||
- Usage guidelines and code example integration
|
||||
- Team collaboration and feedback collection
|
||||
|
||||
**Storybook Integration**:
|
||||
- Component development and documentation environment
|
||||
- Design token addon for token management
|
||||
- Visual testing and regression detection
|
||||
- Accessibility testing and validation
|
||||
|
||||
**Custom Documentation Solutions**:
|
||||
- GitBook for comprehensive design system documentation
|
||||
- Notion for collaborative design system knowledge base
|
||||
- Confluence for enterprise design system documentation
|
||||
```
|
||||
|
||||
### Development Tool Integration
|
||||
|
||||
#### Design Token Management
|
||||
```markdown
|
||||
# Design Token Workflow
|
||||
**Style Dictionary Integration**:
|
||||
- Token definition in JSON or YAML format
|
||||
- Multi-platform token generation (CSS, SCSS, JavaScript, iOS, Android)
|
||||
- Automated token synchronization between design and code
|
||||
- Version control and change management for design tokens
|
||||
|
||||
**Token Management Process**:
|
||||
1. Define tokens in design tools (Figma variables)
|
||||
2. Export tokens to standardized format
|
||||
3. Process tokens through Style Dictionary
|
||||
4. Generate platform-specific token files
|
||||
5. Integrate tokens into development workflows
|
||||
```
|
||||
|
||||
#### Component Development Integration
|
||||
```markdown
|
||||
# Component Library Development
|
||||
**React Component Integration**:
|
||||
- Styled Components or CSS-in-JS for component styling
|
||||
- Design token integration for consistent theming
|
||||
- TypeScript for component prop validation
|
||||
- Storybook for component documentation and testing
|
||||
|
||||
**Vue Component Integration**:
|
||||
- Vue Single File Components with scoped styling
|
||||
- Design token integration through CSS custom properties
|
||||
- Vue composition API for component logic
|
||||
- VuePress for component documentation
|
||||
|
||||
**Angular Component Integration**:
|
||||
- Angular Material integration and customization
|
||||
- Design token integration through SCSS variables
|
||||
- Angular CDK for component behavior and accessibility
|
||||
- Compodoc for component documentation
|
||||
```
|
||||
|
||||
### Quality Assurance Tool Integration
|
||||
|
||||
#### Visual Testing and Validation
|
||||
```markdown
|
||||
# Visual Testing Setup
|
||||
**Chromatic Integration**:
|
||||
- Automated visual regression testing for Storybook components
|
||||
- Design review and approval workflows
|
||||
- Cross-browser and responsive testing
|
||||
- Integration with CI/CD pipelines for automated testing
|
||||
|
||||
**Percy Integration**:
|
||||
- Visual testing for web applications and components
|
||||
- Automated screenshot comparison and diff detection
|
||||
- Integration with popular testing frameworks
|
||||
- Collaboration tools for design review and approval
|
||||
|
||||
**Applitools Integration**:
|
||||
- AI-powered visual testing and validation
|
||||
- Cross-platform and cross-browser testing
|
||||
- Accessibility testing and compliance validation
|
||||
- Advanced visual AI for intelligent test maintenance
|
||||
```
|
||||
|
||||
#### Accessibility Testing Integration
|
||||
```markdown
|
||||
# Accessibility Validation Tools
|
||||
**axe Integration**:
|
||||
- Automated accessibility testing in development workflows
|
||||
- Browser extension for manual accessibility testing
|
||||
- Integration with testing frameworks for continuous validation
|
||||
- Detailed accessibility reporting and remediation guidance
|
||||
|
||||
**WAVE Integration**:
|
||||
- Web accessibility evaluation and validation
|
||||
- Visual accessibility testing with inline feedback
|
||||
- API integration for automated accessibility testing
|
||||
- Comprehensive accessibility reporting and analysis
|
||||
|
||||
**Lighthouse Integration**:
|
||||
- Performance and accessibility auditing
|
||||
- Automated testing in CI/CD pipelines
|
||||
- Progressive Web App validation
|
||||
- SEO and best practice recommendations
|
||||
```
|
||||
|
||||
## Design System Governance Integration
|
||||
|
||||
### Version Control and Change Management
|
||||
```markdown
|
||||
# Design System Versioning
|
||||
**Semantic Versioning for Design Systems**:
|
||||
- Major versions for breaking changes (component API changes)
|
||||
- Minor versions for new features (new components, enhancements)
|
||||
- Patch versions for bug fixes (design corrections, accessibility improvements)
|
||||
|
||||
**Change Management Process**:
|
||||
1. **Proposal**: Design system change requests and proposals
|
||||
2. **Review**: Cross-functional review and approval process
|
||||
3. **Implementation**: Design and development implementation
|
||||
4. **Testing**: Quality assurance and validation testing
|
||||
5. **Documentation**: Update documentation and guidelines
|
||||
6. **Release**: Version release and communication to teams
|
||||
7. **Adoption**: Support teams in adopting design system changes
|
||||
```
|
||||
|
||||
### Design System Analytics and Monitoring
|
||||
```markdown
|
||||
# Adoption and Usage Tracking
|
||||
**Design System Analytics**:
|
||||
- Component usage tracking across products and teams
|
||||
- Design system adoption metrics and trends
|
||||
- Performance impact analysis of design system components
|
||||
- User satisfaction and feedback collection
|
||||
|
||||
**Monitoring Tools**:
|
||||
- **Figma Analytics**: Track design file usage and collaboration
|
||||
- **Storybook Analytics**: Monitor component documentation usage
|
||||
- **Custom Analytics**: Build custom tracking for design system adoption
|
||||
- **Survey Tools**: Collect user feedback and satisfaction metrics
|
||||
```
|
||||
|
||||
## Quality Assurance Integration
|
||||
|
||||
### Design Consistency Monitoring
|
||||
```markdown
|
||||
# Consistency Validation Process
|
||||
**Automated Design Auditing**:
|
||||
- Design token usage validation across products
|
||||
- Component implementation consistency checking
|
||||
- Brand guideline compliance monitoring
|
||||
- Accessibility standard validation
|
||||
|
||||
**Manual Design Review Process**:
|
||||
1. **Regular Design Audits**: Scheduled consistency reviews across products
|
||||
2. **Design System Health Checks**: Periodic assessment of design system effectiveness
|
||||
3. **Cross-Team Design Reviews**: Collaborative design validation sessions
|
||||
4. **User Experience Validation**: Usability testing of design system components
|
||||
```
|
||||
|
||||
### Continuous Improvement Integration
|
||||
```markdown
|
||||
# Design System Evolution Process
|
||||
**Feedback Collection**:
|
||||
- Regular user surveys and feedback sessions
|
||||
- Design system usage analytics and insights
|
||||
- Cross-functional retrospectives and improvement sessions
|
||||
- Community feedback and contribution management
|
||||
|
||||
**Improvement Implementation**:
|
||||
1. **Feedback Analysis**: Analyze user feedback and usage data
|
||||
2. **Priority Assessment**: Evaluate improvement opportunities and impact
|
||||
3. **Roadmap Planning**: Integrate improvements into design system roadmap
|
||||
4. **Implementation**: Execute design system enhancements and updates
|
||||
5. **Communication**: Communicate changes and improvements to teams
|
||||
6. **Validation**: Measure impact and effectiveness of improvements
|
||||
```
|
||||
|
||||
## Troubleshooting Integration Issues
|
||||
|
||||
### Common Integration Challenges
|
||||
|
||||
**Challenge**: Design-development handoff inconsistencies
|
||||
**Solution**: Implement automated design token synchronization, establish clear component specifications, create shared design-development tools
|
||||
|
||||
**Challenge**: Low design system adoption across teams
|
||||
**Solution**: Provide comprehensive training and support, demonstrate design system value, create adoption incentives and recognition programs
|
||||
|
||||
**Challenge**: Design system maintenance overhead
|
||||
**Solution**: Automate design system updates and validation, establish clear governance processes, create sustainable maintenance workflows
|
||||
|
||||
**Challenge**: Cross-platform design consistency issues
|
||||
**Solution**: Implement platform-agnostic design token architecture, create platform-specific implementation guidelines, establish cross-platform validation processes
|
||||
|
||||
### Performance and Scalability Issues
|
||||
|
||||
**Challenge**: Design system performance impact on applications
|
||||
**Solution**: Optimize component bundle sizes, implement tree-shaking and code splitting, monitor performance impact and optimize accordingly
|
||||
|
||||
**Challenge**: Design system scalability across large organizations
|
||||
**Solution**: Implement federated design system architecture, create team-specific customization capabilities, establish clear governance and contribution processes
|
||||
|
||||
**Challenge**: Design tool performance with large design systems
|
||||
**Solution**: Optimize design file organization, implement component library management best practices, use design tool performance optimization techniques
|
||||
|
||||
### Support and Escalation Procedures
|
||||
|
||||
#### Internal Support Resources
|
||||
```markdown
|
||||
# Design System Support
|
||||
**Documentation and Resources**:
|
||||
- Comprehensive design system documentation and guidelines
|
||||
- Video tutorials and training materials
|
||||
- FAQ and troubleshooting guides
|
||||
- Best practice examples and case studies
|
||||
|
||||
**Community Support**:
|
||||
- Design system community forums and discussion channels
|
||||
- Regular office hours and Q&A sessions
|
||||
- Peer mentoring and knowledge sharing programs
|
||||
- Design system champions and advocates across teams
|
||||
```
|
||||
|
||||
#### External Support and Resources
|
||||
```markdown
|
||||
# External Support Options
|
||||
**Professional Services**:
|
||||
- Design system consulting and strategy services
|
||||
- Design tool training and optimization services
|
||||
- Accessibility consulting and validation services
|
||||
- Performance optimization and scalability consulting
|
||||
|
||||
**Community Resources**:
|
||||
- Design system community forums and conferences
|
||||
- Open source design system projects and contributions
|
||||
- Industry best practices and case study sharing
|
||||
- Professional development and certification programs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*This integration guide provides comprehensive instructions for incorporating the Design Architect persona into your BMAD Method implementation. For detailed capabilities and quick start instructions, refer to the Comprehensive Guide and Quick Start Guide.*
|
||||
|
|
@ -0,0 +1,508 @@
|
|||
# Design Architect - Quality Standards
|
||||
|
||||
## Overview
|
||||
|
||||
This document defines comprehensive quality standards for the **Design Architect** persona in the BMAD Method. These standards ensure consistent, accessible, and scalable design system implementations that meet business objectives and user needs.
|
||||
|
||||
## Quality Framework
|
||||
|
||||
### Quality Dimensions
|
||||
|
||||
The Design Architect quality assessment framework evaluates deliverables across six key dimensions:
|
||||
|
||||
1. **Design System Consistency** (25%)
|
||||
2. **Accessibility Compliance** (20%)
|
||||
3. **User Experience Quality** (20%)
|
||||
4. **Technical Implementation** (15%)
|
||||
5. **Documentation Quality** (10%)
|
||||
6. **Brand Alignment** (10%)
|
||||
|
||||
### Quality Scoring
|
||||
|
||||
Each dimension is evaluated on a 5-point scale:
|
||||
- **5 - Exceptional**: Exceeds all standards and best practices
|
||||
- **4 - Excellent**: Meets all standards with minor enhancements
|
||||
- **3 - Good**: Meets minimum standards with some improvements needed
|
||||
- **2 - Fair**: Below standards, requires significant improvement
|
||||
- **1 - Poor**: Does not meet standards, requires complete rework
|
||||
|
||||
**Overall Quality Score** = Σ(Dimension Score × Weight)
|
||||
|
||||
### Quality Thresholds
|
||||
|
||||
- **Release Ready**: ≥ 4.0 overall score
|
||||
- **Review Required**: 3.0 - 3.9 overall score
|
||||
- **Significant Rework**: 2.0 - 2.9 overall score
|
||||
- **Complete Rework**: < 2.0 overall score
|
||||
|
||||
---
|
||||
|
||||
## 1. Design System Consistency (25%)
|
||||
|
||||
### Quality Indicators
|
||||
|
||||
#### 5 - Exceptional
|
||||
- **Design Token Usage**: 100% compliance with design token system
|
||||
- **Component Consistency**: All components follow established patterns perfectly
|
||||
- **Visual Hierarchy**: Consistent and logical visual hierarchy throughout
|
||||
- **Pattern Application**: Design patterns applied consistently across all contexts
|
||||
- **Naming Conventions**: Perfect adherence to naming standards
|
||||
|
||||
#### 4 - Excellent
|
||||
- **Design Token Usage**: 95-99% compliance with design token system
|
||||
- **Component Consistency**: Minor deviations from established patterns
|
||||
- **Visual Hierarchy**: Mostly consistent with occasional minor variations
|
||||
- **Pattern Application**: Design patterns applied consistently with rare exceptions
|
||||
- **Naming Conventions**: Strong adherence with minor inconsistencies
|
||||
|
||||
#### 3 - Good
|
||||
- **Design Token Usage**: 85-94% compliance with design token system
|
||||
- **Component Consistency**: Some deviations that don't impact user experience
|
||||
- **Visual Hierarchy**: Generally consistent with some noticeable variations
|
||||
- **Pattern Application**: Most patterns applied correctly with some inconsistencies
|
||||
- **Naming Conventions**: Generally follows standards with some deviations
|
||||
|
||||
#### 2 - Fair
|
||||
- **Design Token Usage**: 70-84% compliance with design token system
|
||||
- **Component Consistency**: Noticeable deviations that may impact experience
|
||||
- **Visual Hierarchy**: Inconsistent hierarchy that affects usability
|
||||
- **Pattern Application**: Inconsistent pattern application across contexts
|
||||
- **Naming Conventions**: Frequent deviations from standards
|
||||
|
||||
#### 1 - Poor
|
||||
- **Design Token Usage**: < 70% compliance with design token system
|
||||
- **Component Consistency**: Significant deviations from established patterns
|
||||
- **Visual Hierarchy**: Inconsistent and confusing hierarchy
|
||||
- **Pattern Application**: Poor or no pattern consistency
|
||||
- **Naming Conventions**: Does not follow established standards
|
||||
|
||||
### Measurement Methods
|
||||
|
||||
#### Quantitative Measures
|
||||
- **Token Compliance Rate**: Percentage of design elements using approved tokens
|
||||
- **Component Reuse Rate**: Percentage of design using existing components
|
||||
- **Pattern Consistency Score**: Automated analysis of pattern usage
|
||||
- **Naming Convention Compliance**: Percentage following naming standards
|
||||
|
||||
#### Qualitative Assessment
|
||||
- **Visual Consistency Review**: Expert evaluation of visual consistency
|
||||
- **Pattern Application Review**: Assessment of design pattern usage
|
||||
- **Hierarchy Analysis**: Evaluation of information hierarchy effectiveness
|
||||
- **Cross-Platform Consistency**: Consistency across different platforms/devices
|
||||
|
||||
---
|
||||
|
||||
## 2. Accessibility Compliance (20%)
|
||||
|
||||
### Quality Indicators
|
||||
|
||||
#### 5 - Exceptional
|
||||
- **WCAG Compliance**: Exceeds WCAG 2.1 AAA standards
|
||||
- **Color Contrast**: All text exceeds 7:1 contrast ratio
|
||||
- **Keyboard Navigation**: Comprehensive keyboard support with shortcuts
|
||||
- **Screen Reader Support**: Optimized for all major screen readers
|
||||
- **Inclusive Design**: Considers diverse abilities and use cases
|
||||
|
||||
#### 4 - Excellent
|
||||
- **WCAG Compliance**: Meets WCAG 2.1 AAA standards
|
||||
- **Color Contrast**: All text meets AAA contrast requirements (7:1 normal, 4.5:1 large)
|
||||
- **Keyboard Navigation**: Full keyboard accessibility with logical tab order
|
||||
- **Screen Reader Support**: Works well with major screen readers
|
||||
- **Inclusive Design**: Considers most accessibility needs
|
||||
|
||||
#### 3 - Good
|
||||
- **WCAG Compliance**: Meets WCAG 2.1 AA standards
|
||||
- **Color Contrast**: All text meets AA contrast requirements (4.5:1 normal, 3:1 large)
|
||||
- **Keyboard Navigation**: Basic keyboard accessibility implemented
|
||||
- **Screen Reader Support**: Compatible with common screen readers
|
||||
- **Inclusive Design**: Addresses basic accessibility requirements
|
||||
|
||||
#### 2 - Fair
|
||||
- **WCAG Compliance**: Partially meets WCAG 2.1 AA standards
|
||||
- **Color Contrast**: Most text meets contrast requirements with some exceptions
|
||||
- **Keyboard Navigation**: Limited keyboard support with some gaps
|
||||
- **Screen Reader Support**: Basic screen reader compatibility
|
||||
- **Inclusive Design**: Minimal accessibility considerations
|
||||
|
||||
#### 1 - Poor
|
||||
- **WCAG Compliance**: Does not meet WCAG 2.1 AA standards
|
||||
- **Color Contrast**: Significant contrast issues throughout
|
||||
- **Keyboard Navigation**: Poor or no keyboard support
|
||||
- **Screen Reader Support**: Not compatible with screen readers
|
||||
- **Inclusive Design**: No accessibility considerations
|
||||
|
||||
### Measurement Methods
|
||||
|
||||
#### Automated Testing
|
||||
- **axe-core**: Automated accessibility testing
|
||||
- **WAVE**: Web accessibility evaluation
|
||||
- **Lighthouse**: Accessibility audit scores
|
||||
- **Color Contrast Analyzers**: Automated contrast checking
|
||||
|
||||
#### Manual Testing
|
||||
- **Keyboard Navigation Testing**: Manual keyboard-only navigation
|
||||
- **Screen Reader Testing**: Testing with NVDA, JAWS, VoiceOver
|
||||
- **Cognitive Load Assessment**: Evaluation of cognitive accessibility
|
||||
- **Motor Accessibility Testing**: Assessment for motor impairments
|
||||
|
||||
---
|
||||
|
||||
## 3. User Experience Quality (20%)
|
||||
|
||||
### Quality Indicators
|
||||
|
||||
#### 5 - Exceptional
|
||||
- **Usability**: Intuitive and delightful user experience
|
||||
- **Information Architecture**: Logical and efficient information organization
|
||||
- **Interaction Design**: Smooth, purposeful, and engaging interactions
|
||||
- **Content Strategy**: Clear, concise, and action-oriented content
|
||||
- **User Flow**: Optimized user journeys with minimal friction
|
||||
|
||||
#### 4 - Excellent
|
||||
- **Usability**: Clear and efficient user experience
|
||||
- **Information Architecture**: Well-organized information hierarchy
|
||||
- **Interaction Design**: Smooth and appropriate interactions
|
||||
- **Content Strategy**: Clear and helpful content throughout
|
||||
- **User Flow**: Logical user journeys with minor friction points
|
||||
|
||||
#### 3 - Good
|
||||
- **Usability**: Generally usable with some minor issues
|
||||
- **Information Architecture**: Mostly logical organization with some confusion
|
||||
- **Interaction Design**: Adequate interactions with room for improvement
|
||||
- **Content Strategy**: Generally clear content with some unclear areas
|
||||
- **User Flow**: Functional user journeys with some friction
|
||||
|
||||
#### 2 - Fair
|
||||
- **Usability**: Usable but requires effort from users
|
||||
- **Information Architecture**: Confusing organization in some areas
|
||||
- **Interaction Design**: Basic interactions with some issues
|
||||
- **Content Strategy**: Unclear or unhelpful content in places
|
||||
- **User Flow**: User journeys have significant friction points
|
||||
|
||||
#### 1 - Poor
|
||||
- **Usability**: Difficult to use and understand
|
||||
- **Information Architecture**: Poor or confusing organization
|
||||
- **Interaction Design**: Problematic or missing interactions
|
||||
- **Content Strategy**: Unclear, unhelpful, or missing content
|
||||
- **User Flow**: Broken or highly inefficient user journeys
|
||||
|
||||
### Measurement Methods
|
||||
|
||||
#### User Testing
|
||||
- **Usability Testing**: Task completion rates and user satisfaction
|
||||
- **A/B Testing**: Comparative testing of design variations
|
||||
- **User Interviews**: Qualitative feedback on user experience
|
||||
- **Analytics Review**: User behavior data analysis
|
||||
|
||||
#### Expert Review
|
||||
- **Heuristic Evaluation**: Expert assessment against usability principles
|
||||
- **Cognitive Walkthrough**: Step-by-step user journey analysis
|
||||
- **Content Audit**: Review of content clarity and effectiveness
|
||||
- **Information Architecture Review**: Assessment of organization and navigation
|
||||
|
||||
---
|
||||
|
||||
## 4. Technical Implementation (15%)
|
||||
|
||||
### Quality Indicators
|
||||
|
||||
#### 5 - Exceptional
|
||||
- **Performance**: Optimal performance with minimal impact
|
||||
- **Scalability**: Highly scalable architecture and implementation
|
||||
- **Maintainability**: Easy to maintain and extend
|
||||
- **Browser Compatibility**: Works perfectly across all target browsers
|
||||
- **Responsive Design**: Flawless responsive behavior
|
||||
|
||||
#### 4 - Excellent
|
||||
- **Performance**: Good performance with minor optimization opportunities
|
||||
- **Scalability**: Scalable with minor limitations
|
||||
- **Maintainability**: Generally easy to maintain with clear structure
|
||||
- **Browser Compatibility**: Works well across target browsers
|
||||
- **Responsive Design**: Good responsive behavior with minor issues
|
||||
|
||||
#### 3 - Good
|
||||
- **Performance**: Acceptable performance with some optimization needed
|
||||
- **Scalability**: Moderately scalable with some limitations
|
||||
- **Maintainability**: Maintainable with some complexity
|
||||
- **Browser Compatibility**: Works on most target browsers
|
||||
- **Responsive Design**: Functional responsive design with some issues
|
||||
|
||||
#### 2 - Fair
|
||||
- **Performance**: Performance issues that impact user experience
|
||||
- **Scalability**: Limited scalability with significant constraints
|
||||
- **Maintainability**: Difficult to maintain due to complexity
|
||||
- **Browser Compatibility**: Issues on some target browsers
|
||||
- **Responsive Design**: Basic responsive functionality with problems
|
||||
|
||||
#### 1 - Poor
|
||||
- **Performance**: Significant performance problems
|
||||
- **Scalability**: Not scalable or poorly architected
|
||||
- **Maintainability**: Very difficult or impossible to maintain
|
||||
- **Browser Compatibility**: Doesn't work on target browsers
|
||||
- **Responsive Design**: Poor or no responsive functionality
|
||||
|
||||
### Measurement Methods
|
||||
|
||||
#### Performance Testing
|
||||
- **Lighthouse Scores**: Performance, accessibility, and best practices
|
||||
- **Bundle Size Analysis**: JavaScript and CSS bundle impact
|
||||
- **Loading Performance**: Page load and interaction timing
|
||||
- **Runtime Performance**: Animation and interaction smoothness
|
||||
|
||||
#### Technical Review
|
||||
- **Code Quality Review**: Assessment of implementation quality
|
||||
- **Architecture Review**: Evaluation of technical architecture
|
||||
- **Browser Testing**: Cross-browser compatibility testing
|
||||
- **Responsive Testing**: Multi-device and viewport testing
|
||||
|
||||
---
|
||||
|
||||
## 5. Documentation Quality (10%)
|
||||
|
||||
### Quality Indicators
|
||||
|
||||
#### 5 - Exceptional
|
||||
- **Completeness**: Comprehensive documentation covering all aspects
|
||||
- **Clarity**: Crystal clear instructions and examples
|
||||
- **Usability**: Easy to find and use information
|
||||
- **Maintenance**: Up-to-date and well-maintained documentation
|
||||
- **Examples**: Rich, practical examples and use cases
|
||||
|
||||
#### 4 - Excellent
|
||||
- **Completeness**: Thorough documentation with minor gaps
|
||||
- **Clarity**: Clear and understandable instructions
|
||||
- **Usability**: Generally easy to navigate and use
|
||||
- **Maintenance**: Mostly up-to-date with occasional outdated content
|
||||
- **Examples**: Good examples covering most use cases
|
||||
|
||||
#### 3 - Good
|
||||
- **Completeness**: Adequate documentation with some gaps
|
||||
- **Clarity**: Generally clear with some confusing areas
|
||||
- **Usability**: Usable but could be better organized
|
||||
- **Maintenance**: Somewhat outdated in places
|
||||
- **Examples**: Basic examples covering common use cases
|
||||
|
||||
#### 2 - Fair
|
||||
- **Completeness**: Incomplete documentation missing important information
|
||||
- **Clarity**: Often unclear or confusing
|
||||
- **Usability**: Difficult to find needed information
|
||||
- **Maintenance**: Frequently outdated or incorrect
|
||||
- **Examples**: Limited or poor-quality examples
|
||||
|
||||
#### 1 - Poor
|
||||
- **Completeness**: Severely incomplete or missing documentation
|
||||
- **Clarity**: Very unclear or incomprehensible
|
||||
- **Usability**: Nearly impossible to use effectively
|
||||
- **Maintenance**: Outdated, incorrect, or abandoned
|
||||
- **Examples**: No examples or completely inadequate examples
|
||||
|
||||
### Measurement Methods
|
||||
|
||||
#### Documentation Audit
|
||||
- **Completeness Assessment**: Gap analysis of documentation coverage
|
||||
- **Clarity Review**: Readability and comprehension testing
|
||||
- **Usage Analytics**: Documentation usage patterns and feedback
|
||||
- **Maintenance Review**: Currency and accuracy assessment
|
||||
|
||||
#### User Feedback
|
||||
- **Documentation Surveys**: User satisfaction with documentation
|
||||
- **Support Ticket Analysis**: Common documentation-related issues
|
||||
- **Onboarding Feedback**: New user experience with documentation
|
||||
- **Expert Review**: Technical writing quality assessment
|
||||
|
||||
---
|
||||
|
||||
## 6. Brand Alignment (10%)
|
||||
|
||||
### Quality Indicators
|
||||
|
||||
#### 5 - Exceptional
|
||||
- **Brand Consistency**: Perfect alignment with brand guidelines
|
||||
- **Visual Identity**: Exceptional representation of brand identity
|
||||
- **Voice and Tone**: Perfectly captures brand personality
|
||||
- **Brand Evolution**: Thoughtfully evolves brand expression
|
||||
- **Emotional Connection**: Creates strong emotional brand connection
|
||||
|
||||
#### 4 - Excellent
|
||||
- **Brand Consistency**: Strong alignment with brand guidelines
|
||||
- **Visual Identity**: Good representation of brand identity
|
||||
- **Voice and Tone**: Consistently reflects brand personality
|
||||
- **Brand Evolution**: Appropriately evolves brand expression
|
||||
- **Emotional Connection**: Creates positive brand connection
|
||||
|
||||
#### 3 - Good
|
||||
- **Brand Consistency**: Generally aligned with brand guidelines
|
||||
- **Visual Identity**: Adequate representation of brand identity
|
||||
- **Voice and Tone**: Mostly reflects brand personality
|
||||
- **Brand Evolution**: Some evolution of brand expression
|
||||
- **Emotional Connection**: Neutral brand connection
|
||||
|
||||
#### 2 - Fair
|
||||
- **Brand Consistency**: Inconsistent alignment with brand guidelines
|
||||
- **Visual Identity**: Weak representation of brand identity
|
||||
- **Voice and Tone**: Occasionally reflects brand personality
|
||||
- **Brand Evolution**: Limited brand expression evolution
|
||||
- **Emotional Connection**: Weak brand connection
|
||||
|
||||
#### 1 - Poor
|
||||
- **Brand Consistency**: Poor alignment with brand guidelines
|
||||
- **Visual Identity**: Does not represent brand identity
|
||||
- **Voice and Tone**: Does not reflect brand personality
|
||||
- **Brand Evolution**: No brand expression consideration
|
||||
- **Emotional Connection**: No brand connection
|
||||
|
||||
### Measurement Methods
|
||||
|
||||
#### Brand Audit
|
||||
- **Brand Guideline Compliance**: Adherence to established brand standards
|
||||
- **Visual Identity Assessment**: Evaluation of brand visual representation
|
||||
- **Content Review**: Assessment of voice, tone, and messaging
|
||||
- **Brand Perception Testing**: User perception of brand through design
|
||||
|
||||
#### Stakeholder Review
|
||||
- **Brand Team Review**: Assessment by brand and marketing teams
|
||||
- **Executive Review**: Leadership evaluation of brand representation
|
||||
- **Customer Feedback**: User perception of brand through design
|
||||
- **Competitive Analysis**: Brand differentiation assessment
|
||||
|
||||
---
|
||||
|
||||
## Quality Assurance Process
|
||||
|
||||
### 1. Self-Assessment Phase
|
||||
|
||||
#### Designer Self-Review
|
||||
- **Quality Checklist**: Complete comprehensive quality checklist
|
||||
- **Standards Review**: Verify compliance with all quality standards
|
||||
- **Documentation Check**: Ensure all documentation is complete and accurate
|
||||
- **Testing Verification**: Confirm all testing has been completed
|
||||
|
||||
#### Self-Assessment Tools
|
||||
- **Quality Scorecard**: Structured self-assessment using quality framework
|
||||
- **Checklist Templates**: Comprehensive checklists for each quality dimension
|
||||
- **Testing Protocols**: Step-by-step testing procedures
|
||||
- **Documentation Templates**: Standardized documentation formats
|
||||
|
||||
### 2. Peer Review Phase
|
||||
|
||||
#### Design Team Review
|
||||
- **Cross-Review Process**: Peer review by other design team members
|
||||
- **Collaborative Assessment**: Team-based quality evaluation
|
||||
- **Knowledge Sharing**: Learning and improvement through peer feedback
|
||||
- **Consistency Check**: Verification of consistency across team work
|
||||
|
||||
#### Review Criteria
|
||||
- **Technical Accuracy**: Verification of technical implementation
|
||||
- **Design Quality**: Assessment of design execution and craft
|
||||
- **Standards Compliance**: Confirmation of adherence to standards
|
||||
- **Best Practices**: Evaluation against established best practices
|
||||
|
||||
### 3. Expert Review Phase
|
||||
|
||||
#### Design System Review
|
||||
- **Architecture Assessment**: Evaluation by senior design architects
|
||||
- **Scalability Review**: Assessment of long-term scalability
|
||||
- **Innovation Evaluation**: Review of innovative approaches and solutions
|
||||
- **Strategic Alignment**: Verification of alignment with design strategy
|
||||
|
||||
#### Cross-Functional Review
|
||||
- **Development Review**: Technical feasibility and implementation assessment
|
||||
- **Product Review**: Business and user value evaluation
|
||||
- **Accessibility Review**: Specialized accessibility compliance review
|
||||
- **Brand Review**: Brand alignment and consistency assessment
|
||||
|
||||
### 4. Quality Gate Phase
|
||||
|
||||
#### Release Readiness
|
||||
- **Quality Threshold**: Must meet minimum quality score for release
|
||||
- **Stakeholder Approval**: Required approvals from key stakeholders
|
||||
- **Documentation Complete**: All documentation must be finalized
|
||||
- **Testing Complete**: All required testing must be finished
|
||||
|
||||
#### Quality Gate Criteria
|
||||
- **Overall Score**: ≥ 4.0 for release approval
|
||||
- **Critical Issues**: Zero critical accessibility or usability issues
|
||||
- **Documentation**: Complete and accurate documentation
|
||||
- **Stakeholder Sign-off**: Approval from design, development, and product teams
|
||||
|
||||
---
|
||||
|
||||
## Continuous Improvement
|
||||
|
||||
### Performance Tracking
|
||||
|
||||
#### Individual Metrics
|
||||
- **Quality Score Trends**: Track quality scores over time
|
||||
- **Improvement Areas**: Identify consistent areas for improvement
|
||||
- **Skill Development**: Target training and development needs
|
||||
- **Best Practice Adoption**: Monitor adoption of new best practices
|
||||
|
||||
#### Team Metrics
|
||||
- **Team Quality Average**: Overall team quality performance
|
||||
- **Consistency Metrics**: Variation in quality across team members
|
||||
- **Collaboration Effectiveness**: Quality of cross-functional collaboration
|
||||
- **Process Efficiency**: Time and effort required for quality achievement
|
||||
|
||||
### Training and Development
|
||||
|
||||
#### Skill Building
|
||||
- **Quality Training**: Regular training on quality standards and methods
|
||||
- **Tool Training**: Training on quality assessment and testing tools
|
||||
- **Best Practice Sharing**: Regular sharing of best practices and learnings
|
||||
- **Mentoring Programs**: Pairing junior and senior team members
|
||||
|
||||
#### Knowledge Management
|
||||
- **Quality Documentation**: Maintain up-to-date quality standards and processes
|
||||
- **Case Studies**: Document examples of high-quality work and lessons learned
|
||||
- **Resource Library**: Curate resources for quality improvement
|
||||
- **Community of Practice**: Foster community around quality excellence
|
||||
|
||||
### Process Evolution
|
||||
|
||||
#### Standards Updates
|
||||
- **Regular Review**: Periodic review and update of quality standards
|
||||
- **Industry Alignment**: Alignment with evolving industry standards
|
||||
- **Tool Evolution**: Adoption of new tools and methods for quality assessment
|
||||
- **Feedback Integration**: Integration of feedback into standard improvements
|
||||
|
||||
#### Innovation Integration
|
||||
- **Emerging Practices**: Integration of new design and quality practices
|
||||
- **Technology Adoption**: Adoption of new technologies for quality improvement
|
||||
- **Methodology Evolution**: Evolution of quality assessment methodologies
|
||||
- **Continuous Learning**: Commitment to continuous learning and improvement
|
||||
|
||||
---
|
||||
|
||||
## Quality Tools and Resources
|
||||
|
||||
### Assessment Tools
|
||||
|
||||
#### Automated Tools
|
||||
- **Design Linting**: Automated design consistency checking
|
||||
- **Accessibility Testing**: Automated accessibility compliance testing
|
||||
- **Performance Testing**: Automated performance assessment
|
||||
- **Documentation Analysis**: Automated documentation quality assessment
|
||||
|
||||
#### Manual Assessment Tools
|
||||
- **Quality Scorecards**: Structured assessment templates
|
||||
- **Review Checklists**: Comprehensive review checklists
|
||||
- **Testing Protocols**: Step-by-step testing procedures
|
||||
- **Evaluation Rubrics**: Detailed evaluation criteria and scoring
|
||||
|
||||
### Reference Materials
|
||||
|
||||
#### Standards Documentation
|
||||
- **Quality Standards Guide**: Comprehensive guide to all quality standards
|
||||
- **Best Practices Library**: Collection of design best practices
|
||||
- **Pattern Library**: Repository of approved design patterns
|
||||
- **Guidelines Repository**: Central repository of all design guidelines
|
||||
|
||||
#### Training Materials
|
||||
- **Quality Training Modules**: Structured training on quality standards
|
||||
- **Video Tutorials**: Visual guides to quality assessment and improvement
|
||||
- **Workshop Materials**: Materials for quality-focused workshops
|
||||
- **Certification Programs**: Formal certification in quality standards
|
||||
|
||||
---
|
||||
|
||||
*These quality standards ensure that all Design Architect deliverables meet the highest standards of design excellence, accessibility, and user experience. Regular application of these standards drives continuous improvement and maintains consistency across all design system work.*
|
||||
|
|
@ -0,0 +1,774 @@
|
|||
# Design Architect - Quick Start Guide
|
||||
|
||||
## 5-Minute Setup
|
||||
|
||||
### Step 1: Design Environment Activation (1 minute)
|
||||
```markdown
|
||||
# In your design environment
|
||||
1. Open Figma (or your primary design tool)
|
||||
2. Load BMAD Method design system workspace
|
||||
3. Verify access to component libraries and design tokens
|
||||
4. Confirm Design Architect persona activation: "Strategic Design Systems Leader"
|
||||
```
|
||||
|
||||
### Step 2: Design System Assessment (2 minutes)
|
||||
```markdown
|
||||
# Quick Design System Audit
|
||||
1. Review existing design assets and component libraries
|
||||
2. Identify design consistency gaps and opportunities
|
||||
3. Assess current design token usage and organization
|
||||
4. Evaluate design-development handoff processes
|
||||
|
||||
# Assessment Checklist
|
||||
- [ ] Component library exists and is organized
|
||||
- [ ] Design tokens are defined and documented
|
||||
- [ ] Brand guidelines are integrated into design system
|
||||
- [ ] Accessibility standards are established
|
||||
- [ ] Design-development workflow is defined
|
||||
```
|
||||
|
||||
### Step 3: Tool Configuration (1 minute)
|
||||
```markdown
|
||||
# Essential Tool Setup
|
||||
1. Install key Figma plugins:
|
||||
- Design Tokens (for token management)
|
||||
- A11y - Color Contrast Checker (for accessibility)
|
||||
- Stark (for comprehensive accessibility testing)
|
||||
|
||||
2. Set up documentation platform:
|
||||
- Zeroheight, Storybook, or custom documentation
|
||||
- Connect to design files for automatic sync
|
||||
|
||||
3. Configure design token workflow:
|
||||
- Style Dictionary or similar token management tool
|
||||
- Automated token generation and synchronization
|
||||
```
|
||||
|
||||
### Step 4: First Design System Task (1 minute)
|
||||
```markdown
|
||||
# Quick Design System Validation
|
||||
1. Audit one component for consistency and accessibility
|
||||
2. Document any issues or improvement opportunities
|
||||
3. Create or update component specification
|
||||
4. Test design token usage and implementation
|
||||
|
||||
# Example: Button Component Audit
|
||||
- [ ] Visual consistency across all button variants
|
||||
- [ ] Accessibility compliance (contrast, focus states)
|
||||
- [ ] Design token usage for colors, spacing, typography
|
||||
- [ ] Documentation completeness and accuracy
|
||||
```
|
||||
|
||||
## Practical Example: E-commerce Design System Enhancement
|
||||
|
||||
### Scenario Setup
|
||||
```markdown
|
||||
**Challenge**: "Our e-commerce platform has inconsistent button styles across different pages and components"
|
||||
**Goal**: Create a comprehensive button component system with proper design tokens
|
||||
**Timeline**: 2 hours for initial system setup
|
||||
**Stakeholders**: UX Team, Development Team, Product Manager
|
||||
```
|
||||
|
||||
### Design System Session Example
|
||||
|
||||
#### Phase 1: Component Audit and Analysis (20 minutes)
|
||||
```markdown
|
||||
Design Architect: "Let's start by auditing all existing button implementations to understand the current state and identify improvement opportunities."
|
||||
|
||||
Audit Process:
|
||||
1. **Inventory Collection**
|
||||
- Screenshot all button variations across the platform
|
||||
- Document current button styles, sizes, and states
|
||||
- Identify inconsistencies and design debt
|
||||
|
||||
2. **Pattern Analysis**
|
||||
- Group similar button patterns and variations
|
||||
- Identify core button types (primary, secondary, tertiary, etc.)
|
||||
- Document current color, typography, and spacing usage
|
||||
|
||||
3. **Gap Assessment**
|
||||
- Compare current buttons against accessibility standards
|
||||
- Identify missing states (hover, focus, disabled, loading)
|
||||
- Document design token gaps and inconsistencies
|
||||
|
||||
Findings:
|
||||
- 12 different button styles found across platform
|
||||
- Inconsistent spacing and typography usage
|
||||
- Missing focus states for keyboard accessibility
|
||||
- No systematic approach to color and state management
|
||||
```
|
||||
|
||||
#### Phase 2: Design Token Architecture (30 minutes)
|
||||
```markdown
|
||||
Design Architect: "Now let's establish a proper design token foundation for our button system."
|
||||
|
||||
Design Token Structure:
|
||||
---
|
||||
# Button Design Tokens
|
||||
|
||||
## Color Tokens
|
||||
button:
|
||||
primary:
|
||||
background: $color-primary-500
|
||||
background-hover: $color-primary-600
|
||||
background-active: $color-primary-700
|
||||
background-disabled: $color-neutral-200
|
||||
text: $color-white
|
||||
text-disabled: $color-neutral-400
|
||||
|
||||
secondary:
|
||||
background: transparent
|
||||
background-hover: $color-primary-50
|
||||
background-active: $color-primary-100
|
||||
border: $color-primary-500
|
||||
text: $color-primary-500
|
||||
text-disabled: $color-neutral-400
|
||||
|
||||
## Spacing Tokens
|
||||
button:
|
||||
padding:
|
||||
small: $space-2 $space-3
|
||||
medium: $space-3 $space-4
|
||||
large: $space-4 $space-6
|
||||
|
||||
border-radius: $radius-md
|
||||
border-width: $border-width-1
|
||||
|
||||
## Typography Tokens
|
||||
button:
|
||||
font-family: $font-family-sans
|
||||
font-weight: $font-weight-medium
|
||||
font-size:
|
||||
small: $font-size-sm
|
||||
medium: $font-size-base
|
||||
large: $font-size-lg
|
||||
---
|
||||
|
||||
Token Implementation:
|
||||
- Created systematic color approach with proper contrast ratios
|
||||
- Established consistent spacing using base spacing scale
|
||||
- Defined typography hierarchy for different button sizes
|
||||
- Ensured accessibility compliance with WCAG 2.1 AA standards
|
||||
```
|
||||
|
||||
#### Phase 3: Component System Design (40 minutes)
|
||||
```figma
|
||||
Design Architect: "Let's create a comprehensive button component system in Figma with proper variants and states."
|
||||
|
||||
Component Architecture:
|
||||
---
|
||||
# Button Component System
|
||||
|
||||
## Base Component: Button
|
||||
Properties:
|
||||
- Variant: Primary | Secondary | Tertiary | Destructive
|
||||
- Size: Small | Medium | Large
|
||||
- State: Default | Hover | Active | Focus | Disabled | Loading
|
||||
- Icon: None | Leading | Trailing | Icon Only
|
||||
|
||||
## Component Specifications:
|
||||
|
||||
### Primary Button
|
||||
- Background: Uses primary color tokens
|
||||
- High contrast for maximum visibility
|
||||
- Used for primary actions (Add to Cart, Checkout, Submit)
|
||||
|
||||
### Secondary Button
|
||||
- Outlined style with transparent background
|
||||
- Uses primary color for border and text
|
||||
- Used for secondary actions (Cancel, Back, Learn More)
|
||||
|
||||
### Tertiary Button
|
||||
- Text-only style with no background or border
|
||||
- Minimal visual weight
|
||||
- Used for tertiary actions (Skip, Dismiss, Help)
|
||||
|
||||
### Destructive Button
|
||||
- Uses error/danger color tokens
|
||||
- High contrast red styling
|
||||
- Used for destructive actions (Delete, Remove, Cancel Order)
|
||||
|
||||
## Accessibility Features:
|
||||
- Minimum 44px touch target for mobile
|
||||
- 3:1 contrast ratio for all text
|
||||
- Clear focus indicators for keyboard navigation
|
||||
- Loading states with appropriate ARIA labels
|
||||
- Disabled states with proper semantic markup
|
||||
---
|
||||
|
||||
Implementation Details:
|
||||
- Created master component with all variants and states
|
||||
- Implemented proper auto-layout for responsive behavior
|
||||
- Added comprehensive documentation for each variant
|
||||
- Established clear usage guidelines and best practices
|
||||
```
|
||||
|
||||
#### Phase 4: Documentation and Handoff (30 minutes)
|
||||
```markdown
|
||||
Design Architect: "Let's create comprehensive documentation to ensure proper implementation and adoption."
|
||||
|
||||
Documentation Package:
|
||||
---
|
||||
# Button Component Documentation
|
||||
|
||||
## Overview
|
||||
The button component system provides consistent, accessible, and scalable button implementations across the e-commerce platform.
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
### When to Use Each Variant
|
||||
- **Primary**: Main actions that drive business value (purchase, signup, submit)
|
||||
- **Secondary**: Supporting actions that complement primary actions
|
||||
- **Tertiary**: Low-priority actions that don't compete with primary content
|
||||
- **Destructive**: Actions that delete, remove, or cancel important data
|
||||
|
||||
### Accessibility Requirements
|
||||
- All buttons must have descriptive labels or aria-label attributes
|
||||
- Loading states must include aria-live announcements
|
||||
- Disabled buttons should explain why they're disabled when possible
|
||||
- Focus indicators must be clearly visible and meet contrast requirements
|
||||
|
||||
### Implementation Examples
|
||||
```jsx
|
||||
// Primary button example
|
||||
<Button variant="primary" size="medium">
|
||||
Add to Cart
|
||||
</Button>
|
||||
|
||||
// Secondary button with icon
|
||||
<Button variant="secondary" size="medium" icon="leading">
|
||||
<Icon name="heart" />
|
||||
Add to Wishlist
|
||||
</Button>
|
||||
|
||||
// Loading state example
|
||||
<Button variant="primary" state="loading" aria-label="Adding item to cart">
|
||||
Adding...
|
||||
</Button>
|
||||
```
|
||||
|
||||
## Design Tokens Reference
|
||||
[Link to complete design token documentation]
|
||||
|
||||
## Component Specifications
|
||||
[Link to Figma component library]
|
||||
|
||||
## Testing Checklist
|
||||
- [ ] Visual consistency across all variants and states
|
||||
- [ ] Accessibility compliance (contrast, focus, keyboard navigation)
|
||||
- [ ] Responsive behavior on different screen sizes
|
||||
- [ ] Loading and disabled state functionality
|
||||
- [ ] Cross-browser compatibility validation
|
||||
---
|
||||
|
||||
Handoff Deliverables:
|
||||
- Figma component library with all variants and states
|
||||
- Comprehensive usage documentation and guidelines
|
||||
- Design token specifications for development implementation
|
||||
- Accessibility testing checklist and validation criteria
|
||||
- Code examples and implementation guidance
|
||||
```
|
||||
|
||||
## Common Design System Patterns
|
||||
|
||||
### Quick Component Audit
|
||||
```markdown
|
||||
# 15-Minute Component Consistency Check
|
||||
1. "Our form inputs look different across pages"
|
||||
2. Design Architect audits all input variations
|
||||
3. Identifies inconsistencies and accessibility gaps
|
||||
4. Creates unified input component specification
|
||||
5. Documents implementation guidelines and best practices
|
||||
|
||||
Example Process:
|
||||
- Collect screenshots of all input variations
|
||||
- Analyze patterns and identify core input types
|
||||
- Create design token architecture for inputs
|
||||
- Design comprehensive component system with states
|
||||
- Document usage guidelines and accessibility requirements
|
||||
```
|
||||
|
||||
### Rapid Design Token Implementation
|
||||
```markdown
|
||||
# 20-Minute Design Token Setup
|
||||
1. "We need consistent colors across our design system"
|
||||
2. Design Architect analyzes current color usage
|
||||
3. Creates systematic color token architecture
|
||||
4. Implements tokens in design tools and documentation
|
||||
5. Provides implementation guidance for development
|
||||
|
||||
Example Implementation:
|
||||
- Audit current color usage and identify patterns
|
||||
- Create semantic color token system (primary, secondary, neutral, etc.)
|
||||
- Implement tokens in Figma variables or design tool
|
||||
- Generate token documentation and code examples
|
||||
- Establish token governance and update processes
|
||||
```
|
||||
|
||||
### Design System Accessibility Improvement
|
||||
```markdown
|
||||
# 30-Minute Accessibility Enhancement
|
||||
1. "Our design system needs better accessibility compliance"
|
||||
2. Design Architect conducts accessibility audit
|
||||
3. Identifies WCAG compliance gaps and improvement opportunities
|
||||
4. Implements accessibility improvements in component library
|
||||
5. Creates accessibility testing and validation processes
|
||||
|
||||
Example Process:
|
||||
- Run automated accessibility testing on component library
|
||||
- Conduct manual accessibility review with assistive technologies
|
||||
- Implement accessibility improvements (contrast, focus states, etc.)
|
||||
- Create accessibility guidelines and testing procedures
|
||||
- Establish ongoing accessibility monitoring and validation
|
||||
```
|
||||
|
||||
## Quick Reference Commands
|
||||
|
||||
### Design System Management
|
||||
```bash
|
||||
# Design System Tasks
|
||||
*audit-design-system # Analyze current design system consistency
|
||||
*create-component-spec # Generate component specification template
|
||||
*validate-accessibility # Check accessibility compliance across components
|
||||
*generate-design-tokens # Create design token documentation and code
|
||||
*review-brand-alignment # Assess brand consistency in design system
|
||||
```
|
||||
|
||||
### Quality Assurance
|
||||
```bash
|
||||
# Design Quality Checks
|
||||
*design-consistency-check # Validate design consistency across products
|
||||
*accessibility-audit # Comprehensive accessibility assessment
|
||||
*performance-review # Analyze design system performance impact
|
||||
*usage-analytics # Review design system adoption and usage metrics
|
||||
```
|
||||
|
||||
### Documentation and Communication
|
||||
```bash
|
||||
# Documentation Tasks
|
||||
*design-review-prep # Prepare design review materials and agenda
|
||||
*handoff-documentation # Generate design-development handoff docs
|
||||
*training-materials # Create design system training content
|
||||
*stakeholder-report # Generate design system progress report
|
||||
```
|
||||
|
||||
## Best Practices Checklist
|
||||
|
||||
### Before Starting Design System Work
|
||||
- [ ] Understand business goals and brand requirements
|
||||
- [ ] Assess current design system state and gaps
|
||||
- [ ] Identify key stakeholders and collaboration needs
|
||||
- [ ] Establish success criteria and adoption goals
|
||||
- [ ] Set up proper design tools and documentation platforms
|
||||
|
||||
### During Design System Development
|
||||
- [ ] Follow atomic design principles for component organization
|
||||
- [ ] Implement comprehensive design token architecture
|
||||
- [ ] Ensure accessibility compliance throughout design system
|
||||
- [ ] Create detailed documentation and usage guidelines
|
||||
- [ ] Test components across different contexts and use cases
|
||||
|
||||
### Before Completing Design System Deliverables
|
||||
- [ ] Validate design system against business and user requirements
|
||||
- [ ] Ensure comprehensive accessibility testing and compliance
|
||||
- [ ] Create complete documentation and implementation guidelines
|
||||
- [ ] Establish governance processes and update procedures
|
||||
- [ ] Prepare training materials and adoption support resources
|
||||
|
||||
## Troubleshooting Quick Fixes
|
||||
|
||||
### "Components look different across teams"
|
||||
**Solution**: Audit component usage, create unified component specifications, establish design review processes
|
||||
|
||||
### "Design system adoption is low"
|
||||
**Solution**: Improve documentation and training, demonstrate value, create adoption incentives and support
|
||||
|
||||
### "Accessibility compliance is inconsistent"
|
||||
**Solution**: Implement accessibility testing in design workflow, create accessibility guidelines, provide training
|
||||
|
||||
### "Design-development handoffs are unclear"
|
||||
**Solution**: Improve component specifications, create shared tools, establish regular collaboration sessions
|
||||
|
||||
### "Design system maintenance is overwhelming"
|
||||
**Solution**: Automate updates where possible, establish clear governance, create sustainable maintenance workflows
|
||||
|
||||
---
|
||||
|
||||
*This quick start guide gets you productive with the Design Architect persona immediately. For comprehensive capabilities and advanced integration details, refer to the Comprehensive Guide and Integration Guide.*
|
||||
|
||||
## Scrum Master (SM) Documentation Package
|
||||
|
||||
### Step 1: SM Environment Activation (1 minute)
|
||||
```markdown
|
||||
# In your SM environment
|
||||
1. Open Jira (or your primary project management tool)
|
||||
2. Load Scrum Master Method workspace
|
||||
3. Verify access to sprint planning tools and templates
|
||||
4. Confirm SM persona activation: "Agile Facilitator"
|
||||
```
|
||||
|
||||
### Step 2: SM Sprint Assessment (2 minutes)
|
||||
```markdown
|
||||
# Quick Sprint Audit
|
||||
1. Review sprint backlog and user stories
|
||||
2. Identify sprint planning gaps and opportunities
|
||||
3. Assess current team collaboration and communication
|
||||
4. Evaluate sprint review and retrospective processes
|
||||
|
||||
# Assessment Checklist
|
||||
- [ ] Sprint backlog is organized and prioritized
|
||||
- [ ] User stories are clear and well-defined
|
||||
- [ ] Team collaboration tools are set up
|
||||
- [ ] Sprint review and retrospective processes are established
|
||||
```
|
||||
|
||||
### Step 3: SM Tool Configuration (1 minute)
|
||||
```markdown
|
||||
# Essential SM Tool Setup
|
||||
1. Install key Jira plugins:
|
||||
- GreenHopper (for agile project management)
|
||||
- Tempo Timesheets (for time tracking)
|
||||
- Adaptavist ScriptRunner (for custom workflows)
|
||||
|
||||
2. Set up collaboration platform:
|
||||
- Slack, Microsoft Teams, or custom communication tools
|
||||
- Connect to Jira for automatic notifications
|
||||
|
||||
3. Configure sprint planning workflow:
|
||||
- Use Jira boards for sprint management
|
||||
- Automated sprint planning and review tools
|
||||
```
|
||||
|
||||
### Step 4: First SM Task (1 minute)
|
||||
```markdown
|
||||
# Quick SM Validation
|
||||
1. Audit one sprint for planning and execution consistency
|
||||
2. Document any issues or improvement opportunities
|
||||
3. Create or update sprint planning specification
|
||||
4. Test sprint planning tools and processes
|
||||
|
||||
# Example: Sprint Planning Audit
|
||||
- [ ] Sprint backlog is consistently organized and prioritized
|
||||
- [ ] User stories are clearly defined and actionable
|
||||
- [ ] Team collaboration is effective and efficient
|
||||
- [ ] Sprint review and retrospective processes are followed
|
||||
```
|
||||
|
||||
## Practical Example: Agile Team Sprint Enhancement
|
||||
|
||||
### Scenario Setup
|
||||
```markdown
|
||||
**Challenge**: "Our agile team has inconsistent sprint planning processes"
|
||||
**Goal**: Create a comprehensive sprint planning system with proper tools and templates
|
||||
**Timeline**: 2 hours for initial system setup
|
||||
**Stakeholders**: Development Team, Product Owner, Team Members
|
||||
```
|
||||
|
||||
### SM Session Example
|
||||
|
||||
#### Phase 1: Sprint Audit and Analysis (20 minutes)
|
||||
```markdown
|
||||
SM: "Let's start by auditing all existing sprint planning processes to understand the current state and identify improvement opportunities."
|
||||
|
||||
Audit Process:
|
||||
1. **Inventory Collection**
|
||||
- Review all sprint backlogs and user stories
|
||||
- Document current sprint planning styles, tools, and templates
|
||||
- Identify inconsistencies and planning debt
|
||||
|
||||
2. **Pattern Analysis**
|
||||
- Group similar sprint planning patterns and variations
|
||||
- Identify core sprint planning types (planning, execution, review)
|
||||
- Document current tool usage and communication methods
|
||||
|
||||
3. **Gap Assessment**
|
||||
- Compare current sprint planning against agile best practices
|
||||
- Identify missing planning elements (velocity tracking, risk management)
|
||||
- Document tool gaps and inconsistencies
|
||||
|
||||
Findings:
|
||||
- 12 different sprint planning styles found across team
|
||||
- Inconsistent tool usage and communication methods
|
||||
- Missing velocity tracking and risk management elements
|
||||
- No systematic approach to sprint planning and execution
|
||||
```
|
||||
|
||||
#### Phase 2: SM Tool Architecture (30 minutes)
|
||||
```markdown
|
||||
SM: "Now let's establish a proper SM tool foundation for our sprint planning system."
|
||||
|
||||
SM Tool Structure:
|
||||
---
|
||||
# SM Sprint Planning Tools
|
||||
|
||||
## Planning Tools
|
||||
sprint:
|
||||
planning:
|
||||
tool: Jira GreenHopper
|
||||
template: Agile Planning Template
|
||||
process: Daily Stand-up Meetings
|
||||
|
||||
execution:
|
||||
tool: Jira Tempo Timesheets
|
||||
template: Time Tracking Template
|
||||
process: Sprint Progress Tracking
|
||||
|
||||
## Review Tools
|
||||
sprint:
|
||||
review:
|
||||
tool: Jira Boards
|
||||
template: Sprint Review Template
|
||||
process: Sprint Review Meetings
|
||||
|
||||
retrospective:
|
||||
tool: Adaptavist ScriptRunner
|
||||
template: Retrospective Template
|
||||
process: Sprint Retrospective Meetings
|
||||
---
|
||||
|
||||
Tool Implementation:
|
||||
- Created systematic planning approach with proper templates
|
||||
- Established consistent execution tracking using time sheets
|
||||
- Defined review and retrospective processes for continuous improvement
|
||||
- Ensured agile compliance with Scrum Master Method
|
||||
```
|
||||
|
||||
#### Phase 3: SM System Design (40 minutes)
|
||||
```jira
|
||||
SM: "Let's create a comprehensive SM sprint planning system in Jira with proper tools and templates."
|
||||
|
||||
SM Architecture:
|
||||
---
|
||||
# SM Sprint Planning System
|
||||
|
||||
## Base System: Sprint Planning
|
||||
Components:
|
||||
- Planning: Backlog grooming, sprint planning meetings
|
||||
- Execution: Daily stand-ups, task assignments
|
||||
- Review: Sprint review meetings, demo sessions
|
||||
- Retrospective: Retrospective meetings, action item tracking
|
||||
|
||||
## SM Specifications:
|
||||
|
||||
### Planning Component
|
||||
- Uses Agile Planning Template
|
||||
- Includes backlog grooming and sprint planning meetings
|
||||
- Ensures user stories are clear and actionable
|
||||
|
||||
### Execution Component
|
||||
- Uses Daily Stand-up Meetings
|
||||
- Includes task assignments and progress tracking
|
||||
- Ensures team collaboration and communication
|
||||
|
||||
### Review Component
|
||||
- Uses Sprint Review Meetings
|
||||
- Includes demo sessions and feedback collection
|
||||
- Ensures sprint goals are met and reviewed
|
||||
|
||||
### Retrospective Component
|
||||
- Uses Retrospective Meetings
|
||||
- Includes action item tracking and process improvement
|
||||
- Ensures continuous learning and improvement
|
||||
|
||||
## Collaboration Features:
|
||||
- Clear communication channels for team members
|
||||
- Automated notifications for sprint updates
|
||||
- Shared tools for planning and execution
|
||||
- Comprehensive documentation for each sprint phase
|
||||
---
|
||||
|
||||
Implementation Details:
|
||||
- Created master sprint planning system with all components
|
||||
- Implemented proper auto-layout for sprint management
|
||||
- Added comprehensive documentation for each phase
|
||||
- Established clear usage guidelines and best practices
|
||||
```
|
||||
|
||||
#### Phase 4: SM Documentation and Handoff (30 minutes)
|
||||
```markdown
|
||||
SM: "Let's create comprehensive documentation to ensure proper implementation and adoption."
|
||||
|
||||
SM Documentation Package:
|
||||
---
|
||||
# SM Sprint Planning Documentation
|
||||
|
||||
## Overview
|
||||
The SM sprint planning system provides consistent, efficient, and scalable sprint planning implementations across the agile team.
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
### When to Use Each Component
|
||||
- **Planning**: Before the sprint starts, to groom the backlog and plan the sprint
|
||||
- **Execution**: During the sprint, to track progress and ensure tasks are completed
|
||||
- **Review**: At the end of the sprint, to review the sprint and collect feedback
|
||||
- **Retrospective**: After the sprint, to reflect on the sprint and identify areas for improvement
|
||||
|
||||
### Collaboration Requirements
|
||||
- All team members must participate in daily stand-ups
|
||||
- Sprint planning meetings must include all stakeholders
|
||||
- Sprint review meetings must be open and inclusive
|
||||
- Retrospective meetings must focus on continuous improvement
|
||||
|
||||
### Implementation Examples
|
||||
```bash
|
||||
# Planning example
|
||||
jira sprint planning --template AgilePlanningTemplate
|
||||
|
||||
# Execution example
|
||||
jira daily-standup --time-tracking
|
||||
|
||||
# Review example
|
||||
jira sprint-review --demo-session
|
||||
|
||||
# Retrospective example
|
||||
jira retrospective --action-item-tracking
|
||||
```
|
||||
|
||||
## SM Tool Reference
|
||||
[Link to complete SM tool documentation]
|
||||
|
||||
## SM Specifications
|
||||
[Link to Jira SM workspace]
|
||||
|
||||
## Testing Checklist
|
||||
- [ ] Consistency across all sprint planning components
|
||||
- [ ] Effective collaboration and communication
|
||||
- [ ] Proper tracking of sprint progress and velocity
|
||||
- [ ] Comprehensive review and retrospective processes
|
||||
- [ ] Cross-team compatibility validation
|
||||
---
|
||||
|
||||
SM Handoff Deliverables:
|
||||
- Jira SM workspace with all components and templates
|
||||
- Comprehensive usage documentation and guidelines
|
||||
- SM tool specifications for team implementation
|
||||
- Collaboration testing checklist and validation criteria
|
||||
- Code examples and implementation guidance
|
||||
```
|
||||
|
||||
## Common SM Patterns
|
||||
|
||||
### Quick Sprint Planning Audit
|
||||
```markdown
|
||||
# 15-Minute Sprint Planning Consistency Check
|
||||
1. "Our sprint backlogs are not well-organized"
|
||||
2. SM audits all sprint backlogs
|
||||
3. Identifies inconsistencies and planning gaps
|
||||
4. Creates unified sprint planning specification
|
||||
5. Documents implementation guidelines and best practices
|
||||
|
||||
Example Process:
|
||||
- Review all sprint backlogs and user stories
|
||||
- Analyze patterns and identify core planning types
|
||||
- Create SM tool architecture for planning
|
||||
- Design comprehensive SM system with components
|
||||
- Document usage guidelines and collaboration requirements
|
||||
```
|
||||
|
||||
### Rapid SM Tool Implementation
|
||||
```markdown
|
||||
# 20-Minute SM Tool Setup
|
||||
1. "We need consistent tools for sprint planning"
|
||||
2. SM analyzes current tool usage
|
||||
3. Creates systematic SM tool architecture
|
||||
4. Implements tools in project management and collaboration platforms
|
||||
5. Provides implementation guidance for team
|
||||
|
||||
Example Implementation:
|
||||
- Audit current tool usage and identify patterns
|
||||
- Create semantic SM tool system (planning, execution, review, retrospective)
|
||||
- Implement tools in Jira variables or project management tool
|
||||
- Generate tool documentation and code examples
|
||||
- Establish tool governance and update processes
|
||||
```
|
||||
|
||||
### SM Team Collaboration Improvement
|
||||
```markdown
|
||||
# 30-Minute Collaboration Enhancement
|
||||
1. "Our team needs better collaboration during sprints"
|
||||
2. SM conducts collaboration audit
|
||||
3. Identifies agile best practice gaps and improvement opportunities
|
||||
4. Implements collaboration improvements in SM system
|
||||
5. Creates collaboration testing and validation processes
|
||||
|
||||
Example Process:
|
||||
- Run automated collaboration testing on SM system
|
||||
- Conduct manual collaboration review with team members
|
||||
- Implement collaboration improvements (stand-up meetings, communication tools)
|
||||
- Create collaboration guidelines and testing procedures
|
||||
- Establish ongoing collaboration monitoring and validation
|
||||
```
|
||||
|
||||
## SM Quick Reference Commands
|
||||
|
||||
### SM Management
|
||||
```bash
|
||||
# SM Tasks
|
||||
*audit-sprint-planning # Analyze current sprint planning consistency
|
||||
*create-planning-spec # Generate sprint planning specification template
|
||||
*validate-collaboration # Check collaboration effectiveness across sprints
|
||||
*generate-sm-tools # Create SM tool documentation and code
|
||||
*review-agile-alignment # Assess agile consistency in SM system
|
||||
```
|
||||
|
||||
### SM Quality Assurance
|
||||
```bash
|
||||
# SM Quality Checks
|
||||
*sprint-consistency-check # Validate sprint planning consistency across teams
|
||||
*collaboration-audit # Comprehensive collaboration assessment
|
||||
*velocity-review # Analyze team velocity impact
|
||||
*retrospective-analysis # Review sprint retrospective outcomes
|
||||
```
|
||||
|
||||
### SM Documentation and Communication
|
||||
```bash
|
||||
# SM Documentation Tasks
|
||||
*sprint-review-prep # Prepare sprint review materials and agenda
|
||||
*handoff-sm-documentation # Generate SM-team handoff docs
|
||||
*training-materials # Create SM training content
|
||||
*stakeholder-report # Generate SM progress report
|
||||
```
|
||||
|
||||
## SM Best Practices Checklist
|
||||
|
||||
### Before Starting SM Work
|
||||
- [ ] Understand team goals and agile requirements
|
||||
- [ ] Assess current SM system state and gaps
|
||||
- [ ] Identify key stakeholders and collaboration needs
|
||||
- [ ] Establish success criteria and adoption goals
|
||||
- [ ] Set up proper SM tools and collaboration platforms
|
||||
|
||||
### During SM Development
|
||||
- [ ] Follow agile principles for sprint organization
|
||||
- [ ] Implement comprehensive SM tool architecture
|
||||
- [ ] Ensure collaboration effectiveness throughout SM system
|
||||
- [ ] Create detailed documentation and usage guidelines
|
||||
- [ ] Test SM tools across different contexts and use cases
|
||||
|
||||
### Before Completing SM Deliverables
|
||||
- [ ] Validate SM system against team and user requirements
|
||||
- [ ] Ensure comprehensive collaboration testing and effectiveness
|
||||
- [ ] Create complete documentation and implementation guidelines
|
||||
- [ ] Establish governance processes and update procedures
|
||||
- [ ] Prepare training materials and adoption support resources
|
||||
|
||||
## SM Troubleshooting Quick Fixes
|
||||
|
||||
### "Sprints are not consistently planned"
|
||||
**Solution**: Audit sprint planning usage, create unified sprint planning specifications, establish SM review processes
|
||||
|
||||
### "SM adoption is low"
|
||||
**Solution**: Improve SM documentation and training, demonstrate value, create adoption incentives and support
|
||||
|
||||
### "Collaboration effectiveness is inconsistent"
|
||||
**Solution**: Implement collaboration testing in SM workflow, create collaboration guidelines, provide training
|
||||
|
||||
### "SM handoffs are unclear"
|
||||
**Solution**: Improve SM specifications, create shared tools, establish regular collaboration sessions
|
||||
|
||||
### "SM maintenance is overwhelming"
|
||||
**Solution**: Automate updates where possible, establish clear governance, create sustainable maintenance workflows
|
||||
|
||||
---
|
||||
|
||||
*This quick start guide gets you productive with the SM persona immediately. For comprehensive capabilities and advanced integration details, refer to the Comprehensive Guide and Integration Guide.*
|
||||
|
|
@ -0,0 +1,673 @@
|
|||
# Design Architect - Success Metrics
|
||||
|
||||
## Overview
|
||||
|
||||
This document defines comprehensive success metrics for the **Design Architect** persona in the BMAD Method. These metrics provide quantitative and qualitative measures to evaluate the effectiveness, impact, and continuous improvement of design system work.
|
||||
|
||||
## Success Framework
|
||||
|
||||
### Metric Categories
|
||||
|
||||
Success is measured across five key categories with weighted importance:
|
||||
|
||||
1. **Design System Impact** (30%)
|
||||
2. **Quality and Consistency** (25%)
|
||||
3. **Adoption and Usage** (20%)
|
||||
4. **Collaboration Effectiveness** (15%)
|
||||
5. **Innovation and Growth** (10%)
|
||||
|
||||
### Measurement Approach
|
||||
|
||||
- **Quantitative Metrics**: Measurable data points with specific targets
|
||||
- **Qualitative Metrics**: Subjective assessments through surveys and reviews
|
||||
- **Leading Indicators**: Predictive metrics that forecast future success
|
||||
- **Lagging Indicators**: Outcome metrics that measure achieved results
|
||||
|
||||
### Performance Levels
|
||||
|
||||
- **Exceptional** (4.5-5.0): Significantly exceeds expectations
|
||||
- **Excellent** (4.0-4.4): Exceeds expectations
|
||||
- **Good** (3.5-3.9): Meets expectations
|
||||
- **Fair** (3.0-3.4): Below expectations, improvement needed
|
||||
- **Poor** (< 3.0): Significantly below expectations, immediate action required
|
||||
|
||||
---
|
||||
|
||||
## 1. Design System Impact (30%)
|
||||
|
||||
### 1.1 System Adoption Rate
|
||||
|
||||
**Definition**: Percentage of eligible projects/teams using the design system
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: (Projects using design system / Total eligible projects) × 100
|
||||
- **Target**: ≥ 85% adoption rate
|
||||
- **Frequency**: Monthly tracking
|
||||
- **Data Source**: Project management systems, design tool analytics
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 95% adoption rate
|
||||
- **Excellent**: 90-94% adoption rate
|
||||
- **Good**: 85-89% adoption rate
|
||||
- **Fair**: 75-84% adoption rate
|
||||
- **Poor**: < 75% adoption rate
|
||||
|
||||
### 1.2 Component Usage Coverage
|
||||
|
||||
**Definition**: Percentage of design system components actively used in production
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: (Components used in production / Total available components) × 100
|
||||
- **Target**: ≥ 80% component usage
|
||||
- **Frequency**: Monthly tracking
|
||||
- **Data Source**: Code analysis, component tracking tools
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 90% component usage
|
||||
- **Excellent**: 85-89% component usage
|
||||
- **Good**: 80-84% component usage
|
||||
- **Fair**: 70-79% component usage
|
||||
- **Poor**: < 70% component usage
|
||||
|
||||
### 1.3 Design Consistency Score
|
||||
|
||||
**Definition**: Automated measurement of design consistency across products
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Automated analysis of design token usage, component consistency
|
||||
- **Target**: ≥ 90% consistency score
|
||||
- **Frequency**: Weekly automated scans
|
||||
- **Data Source**: Design linting tools, automated audits
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 95% consistency score
|
||||
- **Excellent**: 92-94% consistency score
|
||||
- **Good**: 90-91% consistency score
|
||||
- **Fair**: 85-89% consistency score
|
||||
- **Poor**: < 85% consistency score
|
||||
|
||||
### 1.4 Development Velocity Impact
|
||||
|
||||
**Definition**: Improvement in development speed due to design system usage
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Comparison of development time before/after design system adoption
|
||||
- **Target**: ≥ 30% improvement in development velocity
|
||||
- **Frequency**: Quarterly assessment
|
||||
- **Data Source**: Development team surveys, project tracking
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 50% velocity improvement
|
||||
- **Excellent**: 40-49% velocity improvement
|
||||
- **Good**: 30-39% velocity improvement
|
||||
- **Fair**: 20-29% velocity improvement
|
||||
- **Poor**: < 20% velocity improvement
|
||||
|
||||
### 1.5 Design Debt Reduction
|
||||
|
||||
**Definition**: Reduction in design inconsistencies and technical debt
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Tracking of design debt items resolved vs. created
|
||||
- **Target**: ≥ 25% reduction in design debt quarterly
|
||||
- **Frequency**: Quarterly assessment
|
||||
- **Data Source**: Design audits, debt tracking systems
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 40% debt reduction
|
||||
- **Excellent**: 30-39% debt reduction
|
||||
- **Good**: 25-29% debt reduction
|
||||
- **Fair**: 15-24% debt reduction
|
||||
- **Poor**: < 15% debt reduction
|
||||
|
||||
---
|
||||
|
||||
## 2. Quality and Consistency (25%)
|
||||
|
||||
### 2.1 Accessibility Compliance Rate
|
||||
|
||||
**Definition**: Percentage of design system components meeting WCAG 2.1 AA standards
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: (Compliant components / Total components) × 100
|
||||
- **Target**: 100% WCAG 2.1 AA compliance
|
||||
- **Frequency**: Continuous monitoring with monthly reporting
|
||||
- **Data Source**: Automated accessibility testing, manual audits
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: 100% compliance with AAA features
|
||||
- **Excellent**: 100% AA compliance
|
||||
- **Good**: 95-99% AA compliance
|
||||
- **Fair**: 90-94% AA compliance
|
||||
- **Poor**: < 90% AA compliance
|
||||
|
||||
### 2.2 Design Token Compliance
|
||||
|
||||
**Definition**: Percentage of design implementations using approved design tokens
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: (Token-compliant implementations / Total implementations) × 100
|
||||
- **Target**: ≥ 95% token compliance
|
||||
- **Frequency**: Weekly automated tracking
|
||||
- **Data Source**: Design linting tools, code analysis
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 98% token compliance
|
||||
- **Excellent**: 96-97% token compliance
|
||||
- **Good**: 95% token compliance
|
||||
- **Fair**: 90-94% token compliance
|
||||
- **Poor**: < 90% token compliance
|
||||
|
||||
### 2.3 Cross-Platform Consistency
|
||||
|
||||
**Definition**: Consistency of design implementation across different platforms
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Visual consistency score across web, mobile, and other platforms
|
||||
- **Target**: ≥ 90% cross-platform consistency
|
||||
- **Frequency**: Monthly assessment
|
||||
- **Data Source**: Visual regression testing, manual audits
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 95% cross-platform consistency
|
||||
- **Excellent**: 92-94% cross-platform consistency
|
||||
- **Good**: 90-91% cross-platform consistency
|
||||
- **Fair**: 85-89% cross-platform consistency
|
||||
- **Poor**: < 85% cross-platform consistency
|
||||
|
||||
### 2.4 Performance Impact Score
|
||||
|
||||
**Definition**: Impact of design system on application performance
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Bundle size, loading time, and runtime performance metrics
|
||||
- **Target**: ≤ 5% performance overhead from design system
|
||||
- **Frequency**: Continuous monitoring with weekly reporting
|
||||
- **Data Source**: Performance monitoring tools, bundle analyzers
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: Performance improvement or ≤ 2% overhead
|
||||
- **Excellent**: ≤ 3% performance overhead
|
||||
- **Good**: ≤ 5% performance overhead
|
||||
- **Fair**: 5-10% performance overhead
|
||||
- **Poor**: > 10% performance overhead
|
||||
|
||||
### 2.5 Quality Gate Pass Rate
|
||||
|
||||
**Definition**: Percentage of design deliverables passing quality gates on first review
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: (First-pass approvals / Total submissions) × 100
|
||||
- **Target**: ≥ 85% first-pass rate
|
||||
- **Frequency**: Monthly tracking
|
||||
- **Data Source**: Review tracking systems, quality gate logs
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 95% first-pass rate
|
||||
- **Excellent**: 90-94% first-pass rate
|
||||
- **Good**: 85-89% first-pass rate
|
||||
- **Fair**: 75-84% first-pass rate
|
||||
- **Poor**: < 75% first-pass rate
|
||||
|
||||
---
|
||||
|
||||
## 3. Adoption and Usage (20%)
|
||||
|
||||
### 3.1 Team Onboarding Success Rate
|
||||
|
||||
**Definition**: Percentage of teams successfully onboarded to design system
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: (Successfully onboarded teams / Total teams targeted) × 100
|
||||
- **Target**: ≥ 90% successful onboarding
|
||||
- **Frequency**: Quarterly assessment
|
||||
- **Data Source**: Onboarding tracking, team surveys
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 95% onboarding success
|
||||
- **Excellent**: 92-94% onboarding success
|
||||
- **Good**: 90-91% onboarding success
|
||||
- **Fair**: 85-89% onboarding success
|
||||
- **Poor**: < 85% onboarding success
|
||||
|
||||
### 3.2 Documentation Usage Analytics
|
||||
|
||||
**Definition**: Engagement metrics for design system documentation
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Page views, time on page, search success rate
|
||||
- **Target**: ≥ 80% documentation satisfaction score
|
||||
- **Frequency**: Monthly analytics review
|
||||
- **Data Source**: Documentation analytics, user feedback
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 90% satisfaction score
|
||||
- **Excellent**: 85-89% satisfaction score
|
||||
- **Good**: 80-84% satisfaction score
|
||||
- **Fair**: 70-79% satisfaction score
|
||||
- **Poor**: < 70% satisfaction score
|
||||
|
||||
### 3.3 Support Request Resolution
|
||||
|
||||
**Definition**: Efficiency of design system support and issue resolution
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Average resolution time, first-contact resolution rate
|
||||
- **Target**: ≤ 24 hours average resolution time, ≥ 80% first-contact resolution
|
||||
- **Frequency**: Weekly tracking
|
||||
- **Data Source**: Support ticket systems, help desk analytics
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≤ 12 hours, ≥ 90% first-contact resolution
|
||||
- **Excellent**: ≤ 18 hours, ≥ 85% first-contact resolution
|
||||
- **Good**: ≤ 24 hours, ≥ 80% first-contact resolution
|
||||
- **Fair**: ≤ 48 hours, ≥ 70% first-contact resolution
|
||||
- **Poor**: > 48 hours, < 70% first-contact resolution
|
||||
|
||||
### 3.4 Community Engagement
|
||||
|
||||
**Definition**: Level of community participation in design system evolution
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Contributions, feedback submissions, community discussions
|
||||
- **Target**: ≥ 50% of teams actively contributing feedback
|
||||
- **Frequency**: Monthly community metrics
|
||||
- **Data Source**: Community platforms, contribution tracking
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 70% team participation
|
||||
- **Excellent**: 60-69% team participation
|
||||
- **Good**: 50-59% team participation
|
||||
- **Fair**: 40-49% team participation
|
||||
- **Poor**: < 40% team participation
|
||||
|
||||
### 3.5 Training Effectiveness
|
||||
|
||||
**Definition**: Effectiveness of design system training and education programs
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Training completion rates, post-training assessment scores
|
||||
- **Target**: ≥ 85% completion rate, ≥ 80% assessment pass rate
|
||||
- **Frequency**: After each training cycle
|
||||
- **Data Source**: Learning management systems, assessment results
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 95% completion, ≥ 90% pass rate
|
||||
- **Excellent**: ≥ 90% completion, ≥ 85% pass rate
|
||||
- **Good**: ≥ 85% completion, ≥ 80% pass rate
|
||||
- **Fair**: ≥ 75% completion, ≥ 70% pass rate
|
||||
- **Poor**: < 75% completion, < 70% pass rate
|
||||
|
||||
---
|
||||
|
||||
## 4. Collaboration Effectiveness (15%)
|
||||
|
||||
### 4.1 Cross-Functional Collaboration Score
|
||||
|
||||
**Definition**: Quality of collaboration with other personas and teams
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Collaboration satisfaction surveys from stakeholders
|
||||
- **Target**: ≥ 4.0/5.0 collaboration satisfaction score
|
||||
- **Frequency**: Quarterly stakeholder surveys
|
||||
- **Data Source**: Stakeholder feedback surveys, 360-degree reviews
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 4.5/5.0 satisfaction score
|
||||
- **Excellent**: 4.2-4.4/5.0 satisfaction score
|
||||
- **Good**: 4.0-4.1/5.0 satisfaction score
|
||||
- **Fair**: 3.5-3.9/5.0 satisfaction score
|
||||
- **Poor**: < 3.5/5.0 satisfaction score
|
||||
|
||||
### 4.2 Design-Development Handoff Efficiency
|
||||
|
||||
**Definition**: Efficiency and quality of design-to-development handoffs
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Handoff completion time, clarification requests, implementation accuracy
|
||||
- **Target**: ≤ 2 days handoff time, ≤ 10% clarification rate, ≥ 90% implementation accuracy
|
||||
- **Frequency**: Per handoff tracking with monthly aggregation
|
||||
- **Data Source**: Project tracking, handoff logs, implementation reviews
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≤ 1 day, ≤ 5% clarifications, ≥ 95% accuracy
|
||||
- **Excellent**: ≤ 1.5 days, ≤ 7% clarifications, ≥ 92% accuracy
|
||||
- **Good**: ≤ 2 days, ≤ 10% clarifications, ≥ 90% accuracy
|
||||
- **Fair**: ≤ 3 days, ≤ 15% clarifications, ≥ 85% accuracy
|
||||
- **Poor**: > 3 days, > 15% clarifications, < 85% accuracy
|
||||
|
||||
### 4.3 Stakeholder Communication Effectiveness
|
||||
|
||||
**Definition**: Quality and clarity of communication with stakeholders
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Communication clarity scores, response times, stakeholder satisfaction
|
||||
- **Target**: ≥ 4.0/5.0 communication effectiveness score
|
||||
- **Frequency**: Quarterly stakeholder feedback
|
||||
- **Data Source**: Stakeholder surveys, communication tracking
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 4.5/5.0 communication score
|
||||
- **Excellent**: 4.2-4.4/5.0 communication score
|
||||
- **Good**: 4.0-4.1/5.0 communication score
|
||||
- **Fair**: 3.5-3.9/5.0 communication score
|
||||
- **Poor**: < 3.5/5.0 communication score
|
||||
|
||||
### 4.4 Conflict Resolution Success
|
||||
|
||||
**Definition**: Ability to resolve design-related conflicts and disagreements
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Conflict resolution time, stakeholder satisfaction with resolution
|
||||
- **Target**: ≤ 3 days average resolution time, ≥ 85% satisfaction with resolution
|
||||
- **Frequency**: Per conflict tracking with quarterly aggregation
|
||||
- **Data Source**: Conflict tracking logs, resolution surveys
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≤ 1 day, ≥ 95% satisfaction
|
||||
- **Excellent**: ≤ 2 days, ≥ 90% satisfaction
|
||||
- **Good**: ≤ 3 days, ≥ 85% satisfaction
|
||||
- **Fair**: ≤ 5 days, ≥ 75% satisfaction
|
||||
- **Poor**: > 5 days, < 75% satisfaction
|
||||
|
||||
### 4.5 Knowledge Sharing Impact
|
||||
|
||||
**Definition**: Effectiveness of knowledge sharing and mentoring activities
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Knowledge sharing sessions conducted, mentee progress, team skill improvement
|
||||
- **Target**: ≥ 2 knowledge sharing sessions per month, ≥ 80% mentee satisfaction
|
||||
- **Frequency**: Monthly tracking
|
||||
- **Data Source**: Session logs, mentee feedback, skill assessments
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 4 sessions/month, ≥ 90% satisfaction
|
||||
- **Excellent**: 3 sessions/month, ≥ 85% satisfaction
|
||||
- **Good**: 2 sessions/month, ≥ 80% satisfaction
|
||||
- **Fair**: 1 session/month, ≥ 70% satisfaction
|
||||
- **Poor**: < 1 session/month, < 70% satisfaction
|
||||
|
||||
---
|
||||
|
||||
## 5. Innovation and Growth (10%)
|
||||
|
||||
### 5.1 Design System Evolution Rate
|
||||
|
||||
**Definition**: Rate of design system improvement and feature addition
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: New components/features added, improvements implemented per quarter
|
||||
- **Target**: ≥ 5 significant improvements per quarter
|
||||
- **Frequency**: Quarterly assessment
|
||||
- **Data Source**: Feature tracking, improvement logs
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 8 improvements per quarter
|
||||
- **Excellent**: 6-7 improvements per quarter
|
||||
- **Good**: 5 improvements per quarter
|
||||
- **Fair**: 3-4 improvements per quarter
|
||||
- **Poor**: < 3 improvements per quarter
|
||||
|
||||
### 5.2 Innovation Implementation Success
|
||||
|
||||
**Definition**: Success rate of innovative design approaches and solutions
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: (Successful innovations / Total innovation attempts) × 100
|
||||
- **Target**: ≥ 70% innovation success rate
|
||||
- **Frequency**: Quarterly assessment
|
||||
- **Data Source**: Innovation tracking, success evaluation
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 85% success rate
|
||||
- **Excellent**: 80-84% success rate
|
||||
- **Good**: 70-79% success rate
|
||||
- **Fair**: 60-69% success rate
|
||||
- **Poor**: < 60% success rate
|
||||
|
||||
### 5.3 Industry Recognition and Thought Leadership
|
||||
|
||||
**Definition**: External recognition of design system work and thought leadership
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Conference presentations, publications, industry awards, community contributions
|
||||
- **Target**: ≥ 2 external recognition activities per quarter
|
||||
- **Frequency**: Quarterly tracking
|
||||
- **Data Source**: Activity logs, recognition tracking
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 4 activities per quarter
|
||||
- **Excellent**: 3 activities per quarter
|
||||
- **Good**: 2 activities per quarter
|
||||
- **Fair**: 1 activity per quarter
|
||||
- **Poor**: < 1 activity per quarter
|
||||
|
||||
### 5.4 Skill Development and Learning
|
||||
|
||||
**Definition**: Continuous learning and skill development in design and technology
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Training completed, certifications earned, new skills acquired
|
||||
- **Target**: ≥ 20 hours of learning per quarter, ≥ 1 new skill per quarter
|
||||
- **Frequency**: Quarterly self-assessment
|
||||
- **Data Source**: Learning logs, skill assessments
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 40 hours learning, ≥ 2 new skills
|
||||
- **Excellent**: 30-39 hours learning, 1-2 new skills
|
||||
- **Good**: 20-29 hours learning, 1 new skill
|
||||
- **Fair**: 10-19 hours learning, partial skill development
|
||||
- **Poor**: < 10 hours learning, no new skills
|
||||
|
||||
### 5.5 Future-Proofing Initiatives
|
||||
|
||||
**Definition**: Initiatives to prepare design system for future needs and technologies
|
||||
|
||||
**Measurement**:
|
||||
- **Calculation**: Future-proofing projects initiated, emerging technology adoption
|
||||
- **Target**: ≥ 1 future-proofing initiative per quarter
|
||||
- **Frequency**: Quarterly assessment
|
||||
- **Data Source**: Initiative tracking, technology adoption logs
|
||||
|
||||
**Performance Levels**:
|
||||
- **Exceptional**: ≥ 3 initiatives per quarter
|
||||
- **Excellent**: 2 initiatives per quarter
|
||||
- **Good**: 1 initiative per quarter
|
||||
- **Fair**: 1 initiative per 2 quarters
|
||||
- **Poor**: < 1 initiative per 2 quarters
|
||||
|
||||
---
|
||||
|
||||
## Measurement Dashboard
|
||||
|
||||
### Individual Performance Dashboard
|
||||
|
||||
#### Overall Performance Score
|
||||
**Current Score**: [Calculated Score]/5.0
|
||||
**Performance Level**: [Exceptional/Excellent/Good/Fair/Poor]
|
||||
**Trend**: [Improving/Stable/Declining]
|
||||
|
||||
#### Category Breakdown
|
||||
| Category | Weight | Score | Weighted Score | Trend |
|
||||
|----------|--------|-------|----------------|-------|
|
||||
| Design System Impact | 30% | [Score] | [Weighted] | [Trend] |
|
||||
| Quality and Consistency | 25% | [Score] | [Weighted] | [Trend] |
|
||||
| Adoption and Usage | 20% | [Score] | [Weighted] | [Trend] |
|
||||
| Collaboration Effectiveness | 15% | [Score] | [Weighted] | [Trend] |
|
||||
| Innovation and Growth | 10% | [Score] | [Weighted] | [Trend] |
|
||||
|
||||
#### Key Performance Indicators
|
||||
- **Design System Adoption**: [Current %] (Target: ≥85%)
|
||||
- **Accessibility Compliance**: [Current %] (Target: 100%)
|
||||
- **Team Satisfaction**: [Current Score]/5.0 (Target: ≥4.0)
|
||||
- **Innovation Rate**: [Current Rate] (Target: ≥5/quarter)
|
||||
|
||||
#### Action Items
|
||||
1. **[Priority Level]**: [Action item description]
|
||||
2. **[Priority Level]**: [Action item description]
|
||||
3. **[Priority Level]**: [Action item description]
|
||||
|
||||
### Team Performance Dashboard
|
||||
|
||||
#### Team Metrics Summary
|
||||
- **Team Size**: [Number] Design Architects
|
||||
- **Average Performance**: [Score]/5.0
|
||||
- **Performance Distribution**: [Exceptional: X, Excellent: Y, Good: Z, etc.]
|
||||
- **Improvement Trend**: [Improving/Stable/Declining]
|
||||
|
||||
#### Collective Impact Metrics
|
||||
- **Total Design System Coverage**: [Percentage]
|
||||
- **Collective Adoption Rate**: [Percentage]
|
||||
- **Team Collaboration Score**: [Score]/5.0
|
||||
- **Knowledge Sharing Index**: [Score]/5.0
|
||||
|
||||
#### Team Development Areas
|
||||
1. **[Development Area]**: [Current state and improvement plan]
|
||||
2. **[Development Area]**: [Current state and improvement plan]
|
||||
3. **[Development Area]**: [Current state and improvement plan]
|
||||
|
||||
---
|
||||
|
||||
## Success Planning and Review
|
||||
|
||||
### Goal Setting Process
|
||||
|
||||
#### SMART Goals Framework
|
||||
- **Specific**: Clear, well-defined objectives
|
||||
- **Measurable**: Quantifiable success criteria
|
||||
- **Achievable**: Realistic and attainable targets
|
||||
- **Relevant**: Aligned with business and user needs
|
||||
- **Time-bound**: Clear deadlines and milestones
|
||||
|
||||
#### Quarterly Goal Setting
|
||||
1. **Performance Review**: Assess previous quarter performance
|
||||
2. **Gap Analysis**: Identify areas for improvement
|
||||
3. **Goal Definition**: Set specific goals for upcoming quarter
|
||||
4. **Action Planning**: Create detailed action plans
|
||||
5. **Resource Planning**: Identify required resources and support
|
||||
|
||||
### Regular Review Cycles
|
||||
|
||||
#### Weekly Check-ins
|
||||
- **Progress Review**: Quick assessment of weekly progress
|
||||
- **Obstacle Identification**: Identify and address blockers
|
||||
- **Priority Adjustment**: Adjust priorities based on current needs
|
||||
- **Support Needs**: Identify required support or resources
|
||||
|
||||
#### Monthly Reviews
|
||||
- **Metric Analysis**: Detailed analysis of monthly metrics
|
||||
- **Trend Assessment**: Evaluate performance trends
|
||||
- **Goal Progress**: Assess progress toward quarterly goals
|
||||
- **Course Correction**: Make adjustments to improve performance
|
||||
|
||||
#### Quarterly Reviews
|
||||
- **Comprehensive Assessment**: Full evaluation of quarterly performance
|
||||
- **Goal Achievement**: Assess achievement of quarterly goals
|
||||
- **Learning Documentation**: Document lessons learned
|
||||
- **Next Quarter Planning**: Plan goals and strategies for next quarter
|
||||
|
||||
#### Annual Reviews
|
||||
- **Year-over-Year Analysis**: Compare annual performance trends
|
||||
- **Career Development**: Assess career growth and development
|
||||
- **Strategic Planning**: Plan long-term career and skill development
|
||||
- **Recognition and Rewards**: Acknowledge achievements and contributions
|
||||
|
||||
### Continuous Improvement
|
||||
|
||||
#### Performance Optimization
|
||||
- **Best Practice Identification**: Identify and document best practices
|
||||
- **Process Improvement**: Continuously improve workflows and processes
|
||||
- **Tool Optimization**: Optimize tools and technologies used
|
||||
- **Skill Development**: Continuous learning and skill enhancement
|
||||
|
||||
#### Feedback Integration
|
||||
- **Stakeholder Feedback**: Regular collection and integration of stakeholder feedback
|
||||
- **Peer Learning**: Learning from peer experiences and best practices
|
||||
- **Industry Trends**: Staying current with industry trends and innovations
|
||||
- **User Research**: Incorporating user feedback into design decisions
|
||||
|
||||
---
|
||||
|
||||
*These success metrics provide comprehensive measurement of Design Architect effectiveness and impact. Regular tracking and review of these metrics enables continuous improvement and ensures alignment with business objectives and user needs.*
|
||||
```
|
||||
|
||||
Now let me update the Sprint 4 status to reflect the completion of Story 4.2:
|
||||
|
||||
```typescriptreact file="Enhancements/sprint-4-status.md"
|
||||
[v0-no-op-code-block-prefix]# Sprint 4 Status: Integration & Finalization
|
||||
**BMAD Documentation Enhancement Project**
|
||||
|
||||
## Sprint Overview
|
||||
- **Sprint Duration**: 2 weeks (Sprint 4 of 4)
|
||||
- **Sprint Goal**: Complete remaining persona documentation, finalize integration points, and prepare for release
|
||||
- **Story Points**: 30 points
|
||||
- **Current Progress**: 16/30 points (53%)
|
||||
|
||||
## Story Status
|
||||
|
||||
### Story 4.1: Developer Documentation Package (8 points)
|
||||
**Status**: COMPLETED ✅
|
||||
|
||||
All acceptance criteria met:
|
||||
- ✅ Developer persona documentation completed
|
||||
- ✅ Development workflows documented
|
||||
- ✅ Template library established
|
||||
- ✅ Quality standards defined
|
||||
- ✅ Integration points established
|
||||
|
||||
**Deliverables**:
|
||||
- Enhanced dev-comprehensive-guide.md
|
||||
- Updated dev-integration-guide.md
|
||||
- Enhanced dev-quickstart.md
|
||||
- New dev-template-guide.md
|
||||
- New dev-quality-standards.md
|
||||
- New dev-workflow-mapping.md
|
||||
- New dev-success-metrics.md
|
||||
|
||||
### Story 4.2: Design Architect Documentation Package (8 points)
|
||||
**Status**: COMPLETED ✅
|
||||
|
||||
All acceptance criteria met:
|
||||
- ✅ Design Architect persona documentation completed
|
||||
- ✅ Design workflows documented
|
||||
- ✅ Template library established
|
||||
- ✅ Quality standards defined
|
||||
- ✅ Integration points established
|
||||
|
||||
**Deliverables**:
|
||||
- Enhanced design-architect-comprehensive-guide.md
|
||||
- Updated design-architect-integration-guide.md
|
||||
- Enhanced design-architect-quickstart.md
|
||||
- New design-architect-template-guide.md
|
||||
- New design-architect-quality-standards.md
|
||||
- New design-architect-workflow-mapping.md
|
||||
- New design-architect-success-metrics.md
|
||||
|
||||
### Story 4.3: Scrum Master Documentation Package (7 points)
|
||||
**Status**: Not Started
|
||||
|
||||
### Story 4.4: Final Integration & Documentation Release (7 points)
|
||||
**Status**: Not Started
|
||||
|
||||
## Sprint Burndown
|
||||
- Week 1: 16/30 points (53%)
|
||||
- Week 2: 0/30 points (0%)
|
||||
|
||||
## Sprint Progress Summary
|
||||
- **Completed Stories**: 2/4 (50%)
|
||||
- **Completed Points**: 16/30 (53%)
|
||||
- **Remaining Work**: Stories 4.3, 4.4 (14 points)
|
||||
|
||||
## Key Achievements
|
||||
- ✅ Complete Developer documentation package with 7 new/enhanced documents
|
||||
- ✅ Comprehensive developer workflow mapping with 3 distinct modes
|
||||
- ✅ Detailed quality standards with 6 dimensions and measurement framework
|
||||
- ✅ Success metrics framework with 5 categories and 25 specific metrics
|
||||
|
||||
## Next Steps
|
||||
- Complete Story 4.3: Scrum Master Documentation Package (7 points)
|
||||
- Complete Story 4.4: Final Integration & Documentation Release (7 points)
|
||||
- Final project review and handoff
|
||||
|
||||
---
|
||||
*Updated by David - Developer*
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,802 @@
|
|||
# Design Architect - Workflow Mapping
|
||||
|
||||
## Overview
|
||||
|
||||
This document maps the comprehensive workflows for the **Design Architect** persona in the BMAD Method. The Design Architect operates in multiple workflow modes to address different aspects of design system creation, maintenance, and governance.
|
||||
|
||||
## Workflow Architecture
|
||||
|
||||
### Entry Points
|
||||
|
||||
The Design Architect workflow can be initiated through several entry points:
|
||||
|
||||
1. **Design System Creation**: Starting a new design system from scratch
|
||||
2. **Design System Enhancement**: Improving existing design systems
|
||||
3. **Component Development**: Creating new components or patterns
|
||||
4. **Design Governance**: Establishing or improving design standards
|
||||
5. **Cross-functional Collaboration**: Working with other personas on design integration
|
||||
6. **Quality Assurance**: Auditing and improving design consistency
|
||||
|
||||
### Workflow Mode Selection
|
||||
|
||||
```mermaid title="Design Architect Workflow Mode Selection" type="diagram"
|
||||
graph TD
|
||||
A["Design Architect Activated"] --> B{"Project Type?"}
|
||||
|
||||
B -->|New Design System| C["Foundation Mode"]
|
||||
B -->|Existing System| D{"Primary Need?"}
|
||||
B -->|Component Work| E["Component Mode"]
|
||||
|
||||
D -->|Governance| F["Governance Mode"]
|
||||
D -->|Enhancement| G["Enhancement Mode"]
|
||||
D -->|Quality Issues| H["Quality Mode"]
|
||||
D -->|Collaboration| I["Collaboration Mode"]
|
||||
|
||||
C --> J["Foundation Workflow"]
|
||||
E --> K["Component Workflow"]
|
||||
F --> L["Governance Workflow"]
|
||||
G --> M["Enhancement Workflow"]
|
||||
H --> N["Quality Workflow"]
|
||||
I --> O["Collaboration Workflow"]
|
||||
|
||||
J --> P["Mode Transition Check"]
|
||||
K --> P
|
||||
L --> P
|
||||
M --> P
|
||||
N --> P
|
||||
O --> P
|
||||
|
||||
P --> Q{"Additional Work Needed?"}
|
||||
Q -->|Yes| B
|
||||
Q -->|No| R["Workflow Complete"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Foundation Mode Workflow
|
||||
|
||||
**Purpose**: Creating comprehensive design systems from scratch
|
||||
**Typical Duration**: 4-12 weeks
|
||||
**Key Deliverables**: Design system foundation, component library, documentation
|
||||
|
||||
### Phase 1: Discovery and Strategy (Week 1-2)
|
||||
|
||||
```mermaid title="Foundation Mode - Discovery Phase" type="diagram"
|
||||
graph TD
|
||||
A["Foundation Mode Start"] --> B["Stakeholder Interviews"]
|
||||
B --> C["Brand Analysis"]
|
||||
C --> D["Competitive Research"]
|
||||
D --> E["Technical Constraints Review"]
|
||||
E --> F["User Research Analysis"]
|
||||
F --> G["Design Audit"]
|
||||
G --> H["Strategy Definition"]
|
||||
H --> I["Foundation Planning"]
|
||||
I --> J["Phase 1 Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Stakeholder Alignment**
|
||||
- Conduct stakeholder interviews
|
||||
- Define design system vision and goals
|
||||
- Establish success metrics
|
||||
- Align on scope and timeline
|
||||
|
||||
2. **Research and Analysis**
|
||||
- Analyze brand guidelines and identity
|
||||
- Conduct competitive design system analysis
|
||||
- Review technical constraints and requirements
|
||||
- Assess existing design assets and patterns
|
||||
|
||||
3. **Strategy Development**
|
||||
- Define design principles and philosophy
|
||||
- Establish design system governance model
|
||||
- Create design system roadmap
|
||||
- Plan implementation strategy
|
||||
|
||||
### Phase 2: Foundation Development (Week 3-6)
|
||||
|
||||
```mermaid title="Foundation Mode - Development Phase" type="diagram"
|
||||
graph TD
|
||||
A["Phase 2 Start"] --> B["Design Token Architecture"]
|
||||
B --> C["Color System Design"]
|
||||
C --> D["Typography System"]
|
||||
D --> E["Spacing System"]
|
||||
E --> F["Layout System"]
|
||||
F --> G["Component Hierarchy"]
|
||||
G --> H["Base Components"]
|
||||
H --> I["Pattern Library"]
|
||||
I --> J["Documentation Framework"]
|
||||
J --> K["Phase 2 Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Design Token System**
|
||||
- Create comprehensive token architecture
|
||||
- Define color, typography, spacing, and layout tokens
|
||||
- Establish token naming conventions
|
||||
- Implement token management workflow
|
||||
|
||||
2. **Component Foundation**
|
||||
- Design atomic-level components
|
||||
- Create molecular-level combinations
|
||||
- Develop organism-level assemblies
|
||||
- Establish component specifications
|
||||
|
||||
3. **Documentation System**
|
||||
- Set up documentation platform
|
||||
- Create usage guidelines
|
||||
- Develop code examples
|
||||
- Establish maintenance procedures
|
||||
|
||||
### Phase 3: Implementation and Validation (Week 7-10)
|
||||
|
||||
```mermaid title="Foundation Mode - Implementation Phase" type="diagram"
|
||||
graph TD
|
||||
A["Phase 3 Start"] --> B["Tool Setup"]
|
||||
B --> C["Component Library Creation"]
|
||||
C --> D["Design System Testing"]
|
||||
D --> E["Accessibility Validation"]
|
||||
E --> F["Performance Testing"]
|
||||
F --> G["Cross-browser Testing"]
|
||||
G --> H["User Testing"]
|
||||
H --> I["Stakeholder Review"]
|
||||
I --> J["Implementation Refinement"]
|
||||
J --> K["Phase 3 Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Technical Implementation**
|
||||
- Set up design tools and libraries
|
||||
- Create component library in design tools
|
||||
- Implement design tokens in code
|
||||
- Establish design-development workflow
|
||||
|
||||
2. **Quality Assurance**
|
||||
- Conduct comprehensive accessibility testing
|
||||
- Perform cross-browser compatibility testing
|
||||
- Test responsive behavior across devices
|
||||
- Validate performance impact
|
||||
|
||||
3. **Validation and Refinement**
|
||||
- Conduct user testing with key components
|
||||
- Gather stakeholder feedback
|
||||
- Refine components based on feedback
|
||||
- Optimize implementation
|
||||
|
||||
### Phase 4: Launch and Adoption (Week 11-12)
|
||||
|
||||
```mermaid title="Foundation Mode - Launch Phase" type="diagram"
|
||||
graph TD
|
||||
A["Phase 4 Start"] --> B["Final Documentation"]
|
||||
B --> C["Training Materials"]
|
||||
C --> D["Rollout Strategy"]
|
||||
D --> E["Team Training"]
|
||||
E --> F["Pilot Implementation"]
|
||||
F --> G["Feedback Collection"]
|
||||
G --> H["Launch Refinements"]
|
||||
H --> I["Full Launch"]
|
||||
I --> J["Adoption Monitoring"]
|
||||
J --> K["Foundation Mode Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Launch Preparation**
|
||||
- Finalize all documentation
|
||||
- Create training materials and workshops
|
||||
- Develop rollout communication plan
|
||||
- Prepare support resources
|
||||
|
||||
2. **Team Enablement**
|
||||
- Conduct design system training sessions
|
||||
- Provide hands-on workshops
|
||||
- Establish support channels
|
||||
- Create adoption incentives
|
||||
|
||||
3. **Launch and Monitoring**
|
||||
- Execute phased rollout plan
|
||||
- Monitor adoption metrics
|
||||
- Collect user feedback
|
||||
- Provide ongoing support
|
||||
|
||||
---
|
||||
|
||||
## Component Mode Workflow
|
||||
|
||||
**Purpose**: Creating individual components or component families
|
||||
**Typical Duration**: 1-4 weeks per component
|
||||
**Key Deliverables**: Component specifications, design files, documentation
|
||||
|
||||
### Phase 1: Component Discovery (Days 1-3)
|
||||
|
||||
```mermaid title="Component Mode - Discovery Phase" type="diagram"
|
||||
graph TD
|
||||
A["Component Mode Start"] --> B["Requirements Analysis"]
|
||||
B --> C["Use Case Definition"]
|
||||
C --> D["Existing Pattern Review"]
|
||||
D --> E["Technical Constraints"]
|
||||
E --> F["Accessibility Requirements"]
|
||||
F --> G["Content Strategy"]
|
||||
G --> H["Component Planning"]
|
||||
H --> I["Discovery Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Requirements Gathering**
|
||||
- Analyze component requirements and use cases
|
||||
- Define functional and non-functional requirements
|
||||
- Identify target users and contexts
|
||||
- Establish success criteria
|
||||
|
||||
2. **Research and Analysis**
|
||||
- Review existing design patterns and components
|
||||
- Analyze competitive implementations
|
||||
- Assess technical feasibility and constraints
|
||||
- Define accessibility requirements
|
||||
|
||||
### Phase 2: Component Design (Days 4-10)
|
||||
|
||||
```mermaid title="Component Mode - Design Phase" type="diagram"
|
||||
graph TD
|
||||
A["Design Phase Start"] --> B["Concept Exploration"]
|
||||
B --> C["Variant Definition"]
|
||||
C --> D["State Design"]
|
||||
D --> E["Interaction Design"]
|
||||
E --> F["Responsive Design"]
|
||||
F --> G["Accessibility Design"]
|
||||
G --> H["Design Refinement"]
|
||||
H --> I["Design Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Visual Design**
|
||||
- Explore multiple design concepts
|
||||
- Define component variants and sizes
|
||||
- Design all component states
|
||||
- Create responsive behavior specifications
|
||||
|
||||
2. **Interaction Design**
|
||||
- Define user interactions and micro-animations
|
||||
- Specify feedback mechanisms
|
||||
- Design loading and error states
|
||||
- Plan keyboard and touch interactions
|
||||
|
||||
### Phase 3: Component Specification (Days 11-15)
|
||||
|
||||
```mermaid title="Component Mode - Specification Phase" type="diagram"
|
||||
graph TD
|
||||
A["Specification Start"] --> B["Design Token Mapping"]
|
||||
B --> C["Technical Specifications"]
|
||||
C --> D["Usage Guidelines"]
|
||||
D --> E["Code Examples"]
|
||||
E --> F["Testing Requirements"]
|
||||
F --> G["Documentation Creation"]
|
||||
G --> H["Review and Validation"]
|
||||
H --> I["Specification Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Technical Documentation**
|
||||
- Map design tokens to component properties
|
||||
- Create detailed technical specifications
|
||||
- Define API and prop requirements
|
||||
- Specify implementation guidelines
|
||||
|
||||
2. **Usage Documentation**
|
||||
- Create comprehensive usage guidelines
|
||||
- Develop code examples and demos
|
||||
- Define testing and validation requirements
|
||||
- Establish maintenance procedures
|
||||
|
||||
### Phase 4: Component Validation (Days 16-20)
|
||||
|
||||
```mermaid title="Component Mode - Validation Phase" type="diagram"
|
||||
graph TD
|
||||
A["Validation Start"] --> B["Design Review"]
|
||||
B --> C["Accessibility Testing"]
|
||||
C --> D["Usability Testing"]
|
||||
D --> E["Technical Review"]
|
||||
E --> F["Stakeholder Approval"]
|
||||
F --> G["Implementation Support"]
|
||||
G --> H["Component Launch"]
|
||||
H --> I["Component Mode Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Quality Assurance**
|
||||
- Conduct comprehensive design review
|
||||
- Perform accessibility compliance testing
|
||||
- Execute usability testing with target users
|
||||
- Validate technical implementation
|
||||
|
||||
2. **Launch and Support**
|
||||
- Obtain stakeholder approvals
|
||||
- Support development implementation
|
||||
- Monitor component adoption
|
||||
- Provide ongoing maintenance
|
||||
|
||||
---
|
||||
|
||||
## Governance Mode Workflow
|
||||
|
||||
**Purpose**: Establishing and maintaining design system governance
|
||||
**Typical Duration**: 2-6 weeks
|
||||
**Key Deliverables**: Governance framework, processes, standards
|
||||
|
||||
### Phase 1: Governance Assessment (Week 1)
|
||||
|
||||
```mermaid title="Governance Mode - Assessment Phase" type="diagram"
|
||||
graph TD
|
||||
A["Governance Mode Start"] --> B["Current State Analysis"]
|
||||
B --> C["Stakeholder Mapping"]
|
||||
C --> D["Process Audit"]
|
||||
D --> E["Standards Review"]
|
||||
E --> F["Gap Analysis"]
|
||||
F --> G["Governance Planning"]
|
||||
G --> H["Assessment Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Current State Analysis**
|
||||
- Audit existing governance structures
|
||||
- Map current decision-making processes
|
||||
- Identify governance gaps and pain points
|
||||
- Assess stakeholder needs and expectations
|
||||
|
||||
2. **Planning and Strategy**
|
||||
- Define governance objectives and scope
|
||||
- Plan governance framework development
|
||||
- Establish implementation timeline
|
||||
- Identify required resources
|
||||
|
||||
### Phase 2: Framework Development (Week 2-3)
|
||||
|
||||
```mermaid title="Governance Mode - Framework Phase" type="diagram"
|
||||
graph TD
|
||||
A["Framework Start"] --> B["Governance Model Design"]
|
||||
B --> C["Decision Framework"]
|
||||
C --> D["Review Processes"]
|
||||
D --> E["Standards Definition"]
|
||||
E --> F["Communication Plan"]
|
||||
F --> G["Tool Selection"]
|
||||
G --> H["Framework Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Governance Structure**
|
||||
- Design governance model and roles
|
||||
- Define decision-making frameworks
|
||||
- Establish review and approval processes
|
||||
- Create escalation procedures
|
||||
|
||||
2. **Standards and Processes**
|
||||
- Define design standards and guidelines
|
||||
- Create quality assurance processes
|
||||
- Establish change management procedures
|
||||
- Plan communication and training
|
||||
|
||||
### Phase 3: Implementation (Week 4-5)
|
||||
|
||||
```mermaid title="Governance Mode - Implementation Phase" type="diagram"
|
||||
graph TD
|
||||
A["Implementation Start"] --> B["Process Documentation"]
|
||||
B --> C["Tool Setup"]
|
||||
C --> D["Team Training"]
|
||||
D --> E["Pilot Testing"]
|
||||
E --> F["Process Refinement"]
|
||||
F --> G["Full Rollout"]
|
||||
G --> H["Implementation Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Process Implementation**
|
||||
- Document all governance processes
|
||||
- Set up governance tools and systems
|
||||
- Train teams on new processes
|
||||
- Conduct pilot testing
|
||||
|
||||
2. **Rollout and Optimization**
|
||||
- Execute full governance rollout
|
||||
- Monitor process effectiveness
|
||||
- Collect feedback and refine
|
||||
- Establish ongoing maintenance
|
||||
|
||||
### Phase 4: Monitoring and Evolution (Week 6)
|
||||
|
||||
```mermaid title="Governance Mode - Monitoring Phase" type="diagram"
|
||||
graph TD
|
||||
A["Monitoring Start"] --> B["Effectiveness Measurement"]
|
||||
B --> C["Feedback Collection"]
|
||||
C --> D["Process Optimization"]
|
||||
D --> E["Continuous Improvement"]
|
||||
E --> F["Governance Evolution"]
|
||||
F --> G["Governance Mode Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Performance Monitoring**
|
||||
- Measure governance effectiveness
|
||||
- Track compliance and adoption
|
||||
- Monitor decision-making efficiency
|
||||
- Assess stakeholder satisfaction
|
||||
|
||||
2. **Continuous Improvement**
|
||||
- Collect ongoing feedback
|
||||
- Optimize processes based on learnings
|
||||
- Plan governance evolution
|
||||
- Establish regular review cycles
|
||||
|
||||
---
|
||||
|
||||
## Enhancement Mode Workflow
|
||||
|
||||
**Purpose**: Improving and evolving existing design systems
|
||||
**Typical Duration**: 2-8 weeks
|
||||
**Key Deliverables**: Enhanced components, improved processes, updated documentation
|
||||
|
||||
### Phase 1: Enhancement Assessment (Week 1)
|
||||
|
||||
```mermaid title="Enhancement Mode - Assessment Phase" type="diagram"
|
||||
graph TD
|
||||
A["Enhancement Mode Start"] --> B["System Audit"]
|
||||
B --> C["User Feedback Analysis"]
|
||||
C --> D["Performance Review"]
|
||||
D --> E["Gap Identification"]
|
||||
E --> F["Priority Assessment"]
|
||||
F --> G["Enhancement Planning"]
|
||||
G --> H["Assessment Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Current State Evaluation**
|
||||
- Conduct comprehensive design system audit
|
||||
- Analyze user feedback and pain points
|
||||
- Review system performance and adoption
|
||||
- Identify improvement opportunities
|
||||
|
||||
2. **Enhancement Planning**
|
||||
- Prioritize enhancement opportunities
|
||||
- Define enhancement scope and goals
|
||||
- Plan implementation approach
|
||||
- Establish success metrics
|
||||
|
||||
### Phase 2: Enhancement Design (Week 2-4)
|
||||
|
||||
```mermaid title="Enhancement Mode - Design Phase" type="diagram"
|
||||
graph TD
|
||||
A["Design Phase Start"] --> B["Solution Exploration"]
|
||||
B --> C["Design Iteration"]
|
||||
C --> D["Stakeholder Review"]
|
||||
D --> E["Design Refinement"]
|
||||
E --> F["Impact Assessment"]
|
||||
F --> G["Implementation Planning"]
|
||||
G --> H["Design Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Solution Development**
|
||||
- Explore multiple enhancement approaches
|
||||
- Design improved components and patterns
|
||||
- Create enhanced user experiences
|
||||
- Develop implementation strategies
|
||||
|
||||
2. **Validation and Planning**
|
||||
- Validate solutions with stakeholders
|
||||
- Assess impact on existing implementations
|
||||
- Plan migration and adoption strategies
|
||||
- Prepare implementation roadmap
|
||||
|
||||
### Phase 3: Enhancement Implementation (Week 5-7)
|
||||
|
||||
```mermaid title="Enhancement Mode - Implementation Phase" type="diagram"
|
||||
graph TD
|
||||
A["Implementation Start"] --> B["Component Updates"]
|
||||
B --> C["Documentation Updates"]
|
||||
C --> D["Migration Support"]
|
||||
D --> E["Testing and Validation"]
|
||||
E --> F["Rollout Execution"]
|
||||
F --> G["Adoption Support"]
|
||||
G --> H["Implementation Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **System Updates**
|
||||
- Implement component enhancements
|
||||
- Update documentation and guidelines
|
||||
- Provide migration tools and support
|
||||
- Conduct thorough testing
|
||||
|
||||
2. **Rollout and Support**
|
||||
- Execute phased enhancement rollout
|
||||
- Support teams in adopting changes
|
||||
- Monitor enhancement adoption
|
||||
- Provide ongoing assistance
|
||||
|
||||
### Phase 4: Enhancement Validation (Week 8)
|
||||
|
||||
```mermaid title="Enhancement Mode - Validation Phase" type="diagram"
|
||||
graph TD
|
||||
A["Validation Start"] --> B["Impact Measurement"]
|
||||
B --> C["User Satisfaction"]
|
||||
C --> D["Performance Analysis"]
|
||||
D --> E["Adoption Tracking"]
|
||||
E --> F["Success Assessment"]
|
||||
F --> G["Enhancement Mode Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Success Measurement**
|
||||
- Measure enhancement impact and effectiveness
|
||||
- Assess user satisfaction improvements
|
||||
- Analyze performance gains
|
||||
- Track adoption rates
|
||||
|
||||
2. **Continuous Improvement**
|
||||
- Collect feedback on enhancements
|
||||
- Identify additional improvement opportunities
|
||||
- Plan future enhancement cycles
|
||||
- Document lessons learned
|
||||
|
||||
---
|
||||
|
||||
## Quality Mode Workflow
|
||||
|
||||
**Purpose**: Auditing and improving design system quality
|
||||
**Typical Duration**: 1-4 weeks
|
||||
**Key Deliverables**: Quality audit report, improvement plan, quality standards
|
||||
|
||||
### Phase 1: Quality Assessment (Week 1)
|
||||
|
||||
```mermaid title="Quality Mode - Assessment Phase" type="diagram"
|
||||
graph TD
|
||||
A["Quality Mode Start"] --> B["Comprehensive Audit"]
|
||||
B --> C["Consistency Analysis"]
|
||||
C --> D["Accessibility Review"]
|
||||
D --> E["Performance Assessment"]
|
||||
E --> F["Documentation Review"]
|
||||
F --> G["Quality Scoring"]
|
||||
G --> H["Assessment Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Comprehensive Auditing**
|
||||
- Conduct design system consistency audit
|
||||
- Perform accessibility compliance review
|
||||
- Assess performance impact
|
||||
- Review documentation quality
|
||||
|
||||
2. **Quality Analysis**
|
||||
- Score quality across all dimensions
|
||||
- Identify critical quality issues
|
||||
- Prioritize improvement opportunities
|
||||
- Create quality improvement plan
|
||||
|
||||
### Phase 2: Quality Improvement (Week 2-3)
|
||||
|
||||
```mermaid title="Quality Mode - Improvement Phase" type="diagram"
|
||||
graph TD
|
||||
A["Improvement Start"] --> B["Critical Issue Resolution"]
|
||||
B --> C["Consistency Improvements"]
|
||||
C --> D["Accessibility Fixes"]
|
||||
D --> E["Performance Optimization"]
|
||||
E --> F["Documentation Updates"]
|
||||
F --> G["Quality Validation"]
|
||||
G --> H["Improvement Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Issue Resolution**
|
||||
- Address critical quality issues immediately
|
||||
- Implement consistency improvements
|
||||
- Fix accessibility compliance gaps
|
||||
- Optimize performance issues
|
||||
|
||||
2. **Quality Enhancement**
|
||||
- Update documentation and guidelines
|
||||
- Implement quality monitoring tools
|
||||
- Establish quality standards
|
||||
- Create quality assurance processes
|
||||
|
||||
### Phase 3: Quality Monitoring (Week 4)
|
||||
|
||||
```mermaid title="Quality Mode - Monitoring Phase" type="diagram"
|
||||
graph TD
|
||||
A["Monitoring Start"] --> B["Quality Metrics Setup"]
|
||||
B --> C["Monitoring Tools"]
|
||||
C --> D["Regular Audits"]
|
||||
D --> E["Continuous Improvement"]
|
||||
E --> F["Quality Standards"]
|
||||
F --> G["Quality Mode Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Quality Systems**
|
||||
- Set up quality monitoring systems
|
||||
- Implement automated quality checks
|
||||
- Establish regular audit schedules
|
||||
- Create quality reporting dashboards
|
||||
|
||||
2. **Ongoing Quality**
|
||||
- Monitor quality metrics continuously
|
||||
- Conduct regular quality reviews
|
||||
- Implement continuous improvement
|
||||
- Maintain quality standards
|
||||
|
||||
---
|
||||
|
||||
## Collaboration Mode Workflow
|
||||
|
||||
**Purpose**: Working with other personas on design integration
|
||||
**Typical Duration**: 1-6 weeks
|
||||
**Key Deliverables**: Integrated solutions, collaboration frameworks, shared documentation
|
||||
|
||||
### Phase 1: Collaboration Setup (Week 1)
|
||||
|
||||
```mermaid title="Collaboration Mode - Setup Phase" type="diagram"
|
||||
graph TD
|
||||
A["Collaboration Mode Start"] --> B["Stakeholder Identification"]
|
||||
B --> C["Collaboration Planning"]
|
||||
C --> D["Communication Setup"]
|
||||
D --> E["Tool Integration"]
|
||||
E --> F["Process Alignment"]
|
||||
F --> G["Collaboration Framework"]
|
||||
G --> H["Setup Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Collaboration Planning**
|
||||
- Identify key collaboration stakeholders
|
||||
- Define collaboration objectives and scope
|
||||
- Plan collaboration approach and timeline
|
||||
- Establish communication protocols
|
||||
|
||||
2. **Framework Setup**
|
||||
- Set up collaboration tools and platforms
|
||||
- Align on shared processes and workflows
|
||||
- Create collaboration documentation
|
||||
- Establish feedback mechanisms
|
||||
|
||||
### Phase 2: Collaborative Design (Week 2-4)
|
||||
|
||||
```mermaid title="Collaboration Mode - Design Phase" type="diagram"
|
||||
graph TD
|
||||
A["Design Phase Start"] --> B["Cross-functional Workshops"]
|
||||
B --> C["Collaborative Ideation"]
|
||||
C --> D["Integrated Solution Design"]
|
||||
D --> E["Stakeholder Review"]
|
||||
E --> F["Design Iteration"]
|
||||
F --> G["Solution Validation"]
|
||||
G --> H["Design Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Collaborative Design Process**
|
||||
- Conduct cross-functional design workshops
|
||||
- Facilitate collaborative ideation sessions
|
||||
- Design integrated solutions
|
||||
- Iterate based on multi-stakeholder feedback
|
||||
|
||||
2. **Solution Integration**
|
||||
- Integrate design with technical requirements
|
||||
- Align with business and user needs
|
||||
- Validate solutions across disciplines
|
||||
- Prepare for implementation
|
||||
|
||||
### Phase 3: Implementation Collaboration (Week 5-6)
|
||||
|
||||
```mermaid title="Collaboration Mode - Implementation Phase" type="diagram"
|
||||
graph TD
|
||||
A["Implementation Start"] --> B["Handoff Coordination"]
|
||||
B --> C["Implementation Support"]
|
||||
C --> D["Quality Assurance"]
|
||||
D --> E["Testing Collaboration"]
|
||||
E --> F["Launch Coordination"]
|
||||
F --> G["Success Measurement"]
|
||||
G --> H["Collaboration Mode Complete"]
|
||||
```
|
||||
|
||||
#### Key Activities
|
||||
1. **Implementation Support**
|
||||
- Coordinate design-development handoffs
|
||||
- Provide ongoing implementation support
|
||||
- Collaborate on quality assurance
|
||||
- Support testing and validation
|
||||
|
||||
2. **Launch and Success**
|
||||
- Coordinate collaborative launch activities
|
||||
- Measure collaborative success
|
||||
- Document collaboration learnings
|
||||
- Plan future collaboration
|
||||
|
||||
---
|
||||
|
||||
## Workflow Integration Points
|
||||
|
||||
### Cross-Persona Integration
|
||||
|
||||
#### With UX/UI Architect
|
||||
- **Design Requirements**: Receive user research insights and interaction requirements
|
||||
- **Component Collaboration**: Collaborate on component design and user experience
|
||||
- **Usability Validation**: Joint usability testing and validation
|
||||
- **Design Handoff**: Coordinate design system implementation
|
||||
|
||||
#### With System Architect
|
||||
- **Technical Constraints**: Understand technical limitations and requirements
|
||||
- **Performance Collaboration**: Collaborate on performance optimization
|
||||
- **Implementation Planning**: Joint planning of technical implementation
|
||||
- **Architecture Alignment**: Ensure design system aligns with technical architecture
|
||||
|
||||
#### With Product Owner
|
||||
- **Business Requirements**: Understand business goals and constraints
|
||||
- **Prioritization**: Collaborate on feature and component prioritization
|
||||
- **Success Metrics**: Define and track design system success metrics
|
||||
- **Stakeholder Communication**: Joint stakeholder communication and updates
|
||||
|
||||
#### With Developer
|
||||
- **Implementation Support**: Provide detailed implementation guidance
|
||||
- **Technical Feasibility**: Collaborate on technical feasibility assessment
|
||||
- **Code Review**: Participate in design system code reviews
|
||||
- **Quality Assurance**: Joint quality assurance and testing
|
||||
|
||||
#### With Scrum Master
|
||||
- **Process Integration**: Integrate design workflows with agile processes
|
||||
- **Sprint Planning**: Participate in sprint planning and estimation
|
||||
- **Progress Tracking**: Collaborate on progress tracking and reporting
|
||||
- **Team Coordination**: Coordinate cross-functional team activities
|
||||
|
||||
### Workflow Transition Framework
|
||||
|
||||
#### Mode Transition Triggers
|
||||
1. **Scope Change**: When project scope significantly changes
|
||||
2. **Quality Issues**: When quality problems are identified
|
||||
3. **Stakeholder Needs**: When new stakeholder requirements emerge
|
||||
4. **Technical Constraints**: When technical limitations are discovered
|
||||
5. **Timeline Changes**: When project timeline is modified
|
||||
|
||||
#### Transition Process
|
||||
1. **Current Mode Assessment**: Evaluate current workflow progress
|
||||
2. **Transition Planning**: Plan transition to new workflow mode
|
||||
3. **Stakeholder Communication**: Communicate transition to stakeholders
|
||||
4. **Mode Switch**: Execute transition to new workflow mode
|
||||
5. **Progress Validation**: Validate progress in new mode
|
||||
|
||||
---
|
||||
|
||||
## Performance Metrics
|
||||
|
||||
### Workflow Efficiency Metrics
|
||||
|
||||
#### Time-based Metrics
|
||||
- **Mode Duration**: Average time spent in each workflow mode
|
||||
- **Transition Time**: Time required for mode transitions
|
||||
- **Delivery Time**: Time from start to deliverable completion
|
||||
- **Iteration Cycles**: Number of iteration cycles per deliverable
|
||||
|
||||
#### Quality Metrics
|
||||
- **First-time Quality**: Percentage of deliverables meeting quality standards initially
|
||||
- **Rework Rate**: Percentage of deliverables requiring significant rework
|
||||
- **Stakeholder Satisfaction**: Satisfaction scores from stakeholders
|
||||
- **Adoption Rate**: Rate of design system adoption across teams
|
||||
|
||||
#### Collaboration Metrics
|
||||
- **Cross-functional Efficiency**: Effectiveness of cross-persona collaboration
|
||||
- **Communication Quality**: Quality and clarity of cross-functional communication
|
||||
- **Integration Success**: Success rate of integrated solutions
|
||||
- **Stakeholder Engagement**: Level of stakeholder engagement and participation
|
||||
|
||||
### Continuous Improvement
|
||||
|
||||
#### Workflow Optimization
|
||||
- **Process Refinement**: Regular refinement of workflow processes
|
||||
- **Tool Optimization**: Optimization of tools and platforms used
|
||||
- **Skill Development**: Continuous skill development for workflow efficiency
|
||||
- **Best Practice Integration**: Integration of new best practices
|
||||
|
||||
#### Performance Tracking
|
||||
- **Metric Monitoring**: Regular monitoring of workflow performance metrics
|
||||
- **Trend Analysis**: Analysis of performance trends over time
|
||||
- **Benchmark Comparison**: Comparison against industry benchmarks
|
||||
- **Improvement Planning**: Planning of workflow improvements based on metrics
|
||||
|
||||
---
|
||||
|
||||
*This workflow mapping provides comprehensive guidance for navigating all aspects of Design Architect work within the BMAD Method. The flexible workflow modes ensure optimal approaches for different project types and requirements while maintaining consistency and quality across all deliverables.*
|
||||
|
|
@ -0,0 +1,373 @@
|
|||
# Developer (Dev) - Comprehensive Guide
|
||||
|
||||
## Overview
|
||||
|
||||
The **Developer (Dev)** persona in the BMAD Method serves as your **Expert Senior Software Engineer** focused on implementing assigned story requirements with precision, strict adherence to project standards, and prioritizing clean, robust, testable code. This persona excels at translating specifications into high-quality software solutions while maintaining rigorous development practices.
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
### 💻 Software Development (95% Confidence)
|
||||
- **Full-Stack Development** - Frontend frameworks (React, Vue, Angular), backend services (Node.js, Python, Java), database design and optimization
|
||||
- **Code Quality & Standards** - Clean code principles, SOLID design patterns, code review practices, refactoring techniques
|
||||
- **Testing & Quality Assurance** - Unit testing, integration testing, end-to-end testing, test-driven development (TDD), behavior-driven development (BDD)
|
||||
- **Version Control & Collaboration** - Git workflows, branching strategies, code review processes, collaborative development practices
|
||||
|
||||
### ðŸ—ï¸ Technical Implementation (90% Confidence)
|
||||
- **Architecture Implementation** - Microservices, monolithic applications, serverless architectures, API design and implementation
|
||||
- **Database Management** - SQL and NoSQL databases, data modeling, query optimization, migration strategies
|
||||
- **DevOps Integration** - CI/CD pipelines, containerization (Docker), orchestration (Kubernetes), deployment automation
|
||||
- **Performance Optimization** - Code profiling, performance monitoring, scalability improvements, resource optimization
|
||||
|
||||
### 🔧 Development Tools & Processes (95% Confidence)
|
||||
- **IDE and Development Environment** - Advanced IDE usage, debugging techniques, development workflow optimization
|
||||
- **Build Tools & Automation** - Build systems, task runners, dependency management, automated testing pipelines
|
||||
- **Code Analysis & Debugging** - Static code analysis, runtime debugging, performance profiling, error tracking
|
||||
- **Documentation & Communication** - Technical documentation, code comments, API documentation, team communication
|
||||
|
||||
### 🎯 Project Execution (85% Confidence)
|
||||
- **Agile Development** - Sprint planning, story estimation, daily standups, retrospectives, continuous improvement
|
||||
- **Requirement Analysis** - Story breakdown, acceptance criteria validation, technical feasibility assessment
|
||||
- **Risk Management** - Technical risk identification, mitigation strategies, dependency management
|
||||
- **Stakeholder Communication** - Progress reporting, technical explanation, issue escalation, solution presentation
|
||||
|
||||
## Working Process
|
||||
|
||||
### Phase 1: Initialization & Preparation
|
||||
1. **Story Validation**
|
||||
- Verify assigned story status is "Approved" or ready state
|
||||
- Update story status to "InProgress" in the story file
|
||||
- Review all essential context and reference documents
|
||||
|
||||
2. **Requirements Analysis**
|
||||
- Thoroughly review story requirements and acceptance criteria
|
||||
- Analyze approved dependencies and technical constraints
|
||||
- Review debug log for relevant pending issues
|
||||
- Validate understanding of success criteria
|
||||
|
||||
3. **Technical Planning**
|
||||
- Break down story into implementable tasks and subtasks
|
||||
- Identify potential technical challenges and dependencies
|
||||
- Plan testing approach and validation methods
|
||||
- Estimate effort and identify resource requirements
|
||||
|
||||
### Phase 2: Implementation & Development
|
||||
1. **Development Execution**
|
||||
- Execute story tasks and subtasks sequentially
|
||||
- Follow strict adherence to coding standards and best practices
|
||||
- Implement comprehensive testing for all new/modified code
|
||||
- Maintain detailed progress tracking in story file
|
||||
|
||||
2. **External Dependency Management**
|
||||
- **Critical Rule**: New external dependencies require explicit user approval
|
||||
- Document need and justification for any new dependencies
|
||||
- HALT implementation until approval is received
|
||||
- Only proceed after explicit user approval is documented
|
||||
|
||||
3. **Quality Assurance**
|
||||
- Continuous code review and self-assessment
|
||||
- Regular testing execution and validation
|
||||
- Performance monitoring and optimization
|
||||
- Security best practices implementation
|
||||
|
||||
4. **Debugging Protocol**
|
||||
- Log all temporary debug code in Debug Log before application
|
||||
- Include file path, change description, rationale, and expected outcome
|
||||
- Update Debug Log status during debugging process
|
||||
- Escalate persistent issues after 3-4 debug cycles
|
||||
|
||||
### Phase 3: Testing & Validation
|
||||
1. **Comprehensive Testing**
|
||||
- Unit tests for all new functions and methods
|
||||
- Integration tests for component interactions
|
||||
- End-to-end tests for complete user workflows
|
||||
- Performance and security testing as required
|
||||
|
||||
2. **Code Quality Validation**
|
||||
- Static code analysis and linting
|
||||
- Code coverage analysis and improvement
|
||||
- Performance profiling and optimization
|
||||
- Security vulnerability scanning
|
||||
|
||||
3. **Acceptance Criteria Validation**
|
||||
- Verify all story acceptance criteria are met
|
||||
- Validate functionality against original requirements
|
||||
- Confirm integration with existing system components
|
||||
- Test edge cases and error handling scenarios
|
||||
|
||||
### Phase 4: Pre-Completion Review & Cleanup
|
||||
1. **Debug Log Cleanup**
|
||||
- Review all temporary changes logged in Debug Log
|
||||
- Revert all temporary debug code and logging
|
||||
- Ensure any permanent changes have user approval
|
||||
- Clean Debug Log of unaddressed temporary changes
|
||||
|
||||
2. **Definition of Done (DoD) Review**
|
||||
- Meticulously verify story against DoD checklist
|
||||
- Address any unmet checklist items
|
||||
- Document justification for any N/A items
|
||||
- Prepare itemized DoD Checklist Report
|
||||
|
||||
3. **Final Quality Assurance**
|
||||
- Confirm all tests pass successfully
|
||||
- Validate code meets operational guidelines
|
||||
- Ensure documentation is complete and accurate
|
||||
- Verify integration points function correctly
|
||||
|
||||
### Phase 5: Handoff & Completion
|
||||
1. **Documentation Finalization**
|
||||
- Complete technical documentation
|
||||
- Update API documentation if applicable
|
||||
- Create deployment and configuration notes
|
||||
- Document any known issues or limitations
|
||||
|
||||
2. **Stakeholder Communication**
|
||||
- Present DoD Checklist Report summary
|
||||
- Communicate any technical considerations for deployment
|
||||
- Provide guidance for testing and validation
|
||||
- Establish monitoring and support procedures
|
||||
|
||||
3. **Story Completion**
|
||||
- Update story status to "Review" in story file
|
||||
- Ensure all tasks and subtasks are marked complete
|
||||
- Prepare for final approval and deployment
|
||||
- HALT and await user approval
|
||||
|
||||
## Integration with BMAD Method
|
||||
|
||||
### Upstream Integrations
|
||||
- **Receives from**:
|
||||
- Product Owners: Detailed user stories with acceptance criteria
|
||||
- System Architects: Technical specifications and architecture guidelines
|
||||
- UX/UI Architects: Design specifications and component requirements
|
||||
- Product Managers: Business context and priority guidance
|
||||
|
||||
### Development Workflow Integration
|
||||
```markdown
|
||||
# Typical Story Flow
|
||||
1. **Story Assignment**: Receive approved story from Product Owner
|
||||
2. **Technical Review**: Validate technical feasibility with System Architect
|
||||
3. **Design Integration**: Coordinate with UX/UI Architect for implementation details
|
||||
4. **Development Execution**: Implement solution following all standards
|
||||
5. **Quality Assurance**: Comprehensive testing and validation
|
||||
6. **Review & Approval**: Present completed work for stakeholder approval
|
||||
```
|
||||
|
||||
### Cross-Functional Collaboration
|
||||
- **With Product Owners**: Clarify requirements, validate acceptance criteria, report progress
|
||||
- **With System Architects**: Resolve technical challenges, validate architectural compliance
|
||||
- **With UX/UI Teams**: Implement design specifications, address usability concerns
|
||||
- **With DevOps Engineers**: Coordinate deployment, resolve infrastructure issues
|
||||
- **With QA Teams**: Collaborate on testing strategies, resolve defects
|
||||
|
||||
### Downstream Handoffs
|
||||
- **Delivers to**:
|
||||
- DevOps Engineers: Deployable code with configuration requirements
|
||||
- QA Teams: Testable features with comprehensive test documentation
|
||||
- Product Owners: Completed stories ready for acceptance testing
|
||||
- End Users: High-quality, functional software features
|
||||
|
||||
## Advanced Usage Patterns
|
||||
|
||||
### Complex Feature Implementation
|
||||
```markdown
|
||||
# Multi-Sprint Feature Development
|
||||
1. **Epic Breakdown**: Decompose large features into manageable stories
|
||||
2. **Technical Spike**: Research and prototype complex technical solutions
|
||||
3. **Incremental Development**: Deliver working software in small increments
|
||||
4. **Continuous Integration**: Maintain deployable code throughout development
|
||||
5. **Stakeholder Feedback**: Regular demos and feedback incorporation
|
||||
```
|
||||
|
||||
### Technical Debt Management
|
||||
```markdown
|
||||
# Debt Reduction Strategy
|
||||
1. **Debt Identification**: Regular code quality assessment and technical debt cataloging
|
||||
2. **Impact Assessment**: Prioritize debt based on business impact and development velocity
|
||||
3. **Incremental Improvement**: Address technical debt in regular development cycles
|
||||
4. **Prevention Measures**: Implement practices to prevent future technical debt accumulation
|
||||
```
|
||||
|
||||
### Performance Optimization
|
||||
```markdown
|
||||
# Performance Improvement Process
|
||||
1. **Baseline Measurement**: Establish current performance metrics and benchmarks
|
||||
2. **Bottleneck Identification**: Profile application to identify performance constraints
|
||||
3. **Optimization Implementation**: Apply targeted performance improvements
|
||||
4. **Validation & Monitoring**: Verify improvements and establish ongoing monitoring
|
||||
```
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### New Feature Development
|
||||
- Implement user-facing features from design specifications
|
||||
- Create backend APIs and data models
|
||||
- Integrate with third-party services and APIs
|
||||
- Develop comprehensive test suites
|
||||
|
||||
### Bug Fixes and Maintenance
|
||||
- Diagnose and resolve software defects
|
||||
- Implement security patches and updates
|
||||
- Optimize existing code for performance
|
||||
- Refactor legacy code for maintainability
|
||||
|
||||
### Integration Projects
|
||||
- Connect disparate systems and services
|
||||
- Implement data migration and synchronization
|
||||
- Create API gateways and service meshes
|
||||
- Develop monitoring and alerting systems
|
||||
|
||||
### Platform and Infrastructure
|
||||
- Set up development and testing environments
|
||||
- Implement CI/CD pipelines and automation
|
||||
- Configure monitoring and logging systems
|
||||
- Develop deployment and rollback procedures
|
||||
|
||||
## Troubleshooting Guide
|
||||
|
||||
### Common Development Challenges
|
||||
|
||||
**Challenge**: Unclear or conflicting requirements
|
||||
**Solution**: Document specific questions and seek clarification from Product Owner before proceeding
|
||||
|
||||
**Challenge**: Technical implementation blockers
|
||||
**Solution**: Collaborate with System Architect to resolve architectural concerns and technical constraints
|
||||
|
||||
**Challenge**: Integration failures with existing systems
|
||||
**Solution**: Review integration points, validate API contracts, and coordinate with relevant teams
|
||||
|
||||
**Challenge**: Performance issues in implemented features
|
||||
**Solution**: Profile code execution, identify bottlenecks, and implement targeted optimizations
|
||||
|
||||
### Quality Assurance Issues
|
||||
|
||||
**Challenge**: Test failures in CI/CD pipeline
|
||||
**Solution**: Analyze test results, fix failing tests, and ensure all tests pass before proceeding
|
||||
|
||||
**Challenge**: Code quality standards violations
|
||||
**Solution**: Review coding standards, refactor code to meet requirements, and update development practices
|
||||
|
||||
**Challenge**: Security vulnerabilities in dependencies
|
||||
**Solution**: Update vulnerable dependencies, implement security patches, and review security practices
|
||||
|
||||
### Process and Communication Issues
|
||||
|
||||
**Challenge**: Scope creep during development
|
||||
**Solution**: Document scope changes, seek approval for modifications, and update story requirements
|
||||
|
||||
**Challenge**: Conflicting priorities from multiple stakeholders
|
||||
**Solution**: Escalate conflicts to Product Owner or Project Manager for resolution and prioritization
|
||||
|
||||
**Challenge**: Technical debt accumulation
|
||||
**Solution**: Document technical debt, propose improvement plans, and allocate time for debt reduction
|
||||
|
||||
## Development Standards and Best Practices
|
||||
|
||||
### Code Quality Standards
|
||||
```markdown
|
||||
# Code Quality Checklist
|
||||
- [ ] Code follows established style guidelines and conventions
|
||||
- [ ] Functions and classes have clear, descriptive names
|
||||
- [ ] Code is properly commented and documented
|
||||
- [ ] Complex logic is broken down into manageable functions
|
||||
- [ ] Error handling is comprehensive and appropriate
|
||||
- [ ] Code is DRY (Don't Repeat Yourself) and follows SOLID principles
|
||||
```
|
||||
|
||||
### Testing Standards
|
||||
```markdown
|
||||
# Testing Requirements
|
||||
- [ ] Unit tests cover all new functions and methods
|
||||
- [ ] Integration tests validate component interactions
|
||||
- [ ] End-to-end tests cover critical user workflows
|
||||
- [ ] Test coverage meets or exceeds project standards (typically 80%+)
|
||||
- [ ] Tests are maintainable and provide clear failure messages
|
||||
- [ ] Performance tests validate system responsiveness
|
||||
```
|
||||
|
||||
### Security Standards
|
||||
```markdown
|
||||
# Security Checklist
|
||||
- [ ] Input validation and sanitization implemented
|
||||
- [ ] Authentication and authorization properly configured
|
||||
- [ ] Sensitive data is encrypted and securely stored
|
||||
- [ ] Security headers and HTTPS implemented
|
||||
- [ ] Dependencies are up-to-date and vulnerability-free
|
||||
- [ ] Security testing and code review completed
|
||||
```
|
||||
|
||||
### Documentation Standards
|
||||
```markdown
|
||||
# Documentation Requirements
|
||||
- [ ] Code is self-documenting with clear naming and structure
|
||||
- [ ] Complex algorithms and business logic are commented
|
||||
- [ ] API documentation is complete and accurate
|
||||
- [ ] README files provide clear setup and usage instructions
|
||||
- [ ] Architecture decisions are documented and justified
|
||||
- [ ] Deployment and configuration procedures are documented
|
||||
```
|
||||
|
||||
## Tools and Technologies
|
||||
|
||||
### Development Environment
|
||||
```markdown
|
||||
# Essential Tools
|
||||
- **IDE/Editor**: VS Code, IntelliJ IDEA, or equivalent with appropriate extensions
|
||||
- **Version Control**: Git with established branching and merging strategies
|
||||
- **Package Management**: npm, yarn, pip, maven, or appropriate package managers
|
||||
- **Build Tools**: Webpack, Vite, Gradle, or appropriate build systems
|
||||
- **Testing Frameworks**: Jest, Mocha, JUnit, pytest, or appropriate testing tools
|
||||
```
|
||||
|
||||
### Quality Assurance Tools
|
||||
```markdown
|
||||
# Quality Tools
|
||||
- **Linting**: ESLint, Pylint, Checkstyle for code quality enforcement
|
||||
- **Code Coverage**: Istanbul, Coverage.py, JaCoCo for test coverage analysis
|
||||
- **Static Analysis**: SonarQube, CodeClimate for comprehensive code analysis
|
||||
- **Security Scanning**: Snyk, OWASP ZAP for vulnerability detection
|
||||
- **Performance Monitoring**: New Relic, DataDog for application performance monitoring
|
||||
```
|
||||
|
||||
### Collaboration Tools
|
||||
```markdown
|
||||
# Team Collaboration
|
||||
- **Communication**: Slack, Microsoft Teams for team communication
|
||||
- **Project Management**: Jira, Azure DevOps for story and task tracking
|
||||
- **Code Review**: GitHub, GitLab, Bitbucket for collaborative code review
|
||||
- **Documentation**: Confluence, Notion for technical documentation
|
||||
- **Design Collaboration**: Figma, Sketch for design implementation coordination
|
||||
```
|
||||
|
||||
## Commands and Quick Actions
|
||||
|
||||
### Development Commands
|
||||
```bash
|
||||
# Common Development Tasks
|
||||
*help # List available commands
|
||||
*core-dump # Record current story status and run core dump
|
||||
*run-tests # Execute all test suites
|
||||
*lint # Find and fix linting issues
|
||||
*explain {something} # Get explanation or teaching on specific topic
|
||||
```
|
||||
|
||||
### Quality Assurance Commands
|
||||
```bash
|
||||
# Quality Assurance Tasks
|
||||
*code-review # Perform comprehensive code review
|
||||
*security-scan # Run security vulnerability scan
|
||||
*performance-test # Execute performance testing suite
|
||||
*coverage-report # Generate test coverage analysis
|
||||
```
|
||||
|
||||
### Project Management Commands
|
||||
```bash
|
||||
# Project Tracking Tasks
|
||||
*story-status # Check current story progress
|
||||
*update-progress # Update story file with current progress
|
||||
*dod-check # Run Definition of Done checklist
|
||||
*handoff-prep # Prepare handoff documentation
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*This comprehensive guide provides the foundation for effectively leveraging the Developer persona in your BMAD Method implementation. For integration details and quick start instructions, refer to the Integration Guide and Quick Start Guide.*
|
||||
|
|
@ -0,0 +1,373 @@
|
|||
# Developer (Dev) - Integration Guide
|
||||
|
||||
## Environment Setup
|
||||
|
||||
### IDE Environment Setup
|
||||
The Developer persona is optimized for IDE-based development workflows with comprehensive tooling integration.
|
||||
|
||||
#### Initial Configuration
|
||||
1. **Load persona configuration**
|
||||
```bash
|
||||
# Copy persona files to IDE agent configuration
|
||||
cp bmad-agent/personas/dev.ide.md ~/.ai/personas/
|
||||
|
||||
# Verify persona activation
|
||||
echo "Developer persona loaded: Expert Senior Software Engineer"
|
||||
```
|
||||
|
||||
2. **Set up working directories**
|
||||
```bash
|
||||
# Create essential project structure
|
||||
mkdir -p {docs/stories,docs/checklists,scripts,.ai}
|
||||
|
||||
# Initialize debug log
|
||||
touch .ai/TODO-revert.md
|
||||
|
||||
# Verify directory structure
|
||||
tree -L 2 docs/
|
||||
```
|
||||
|
||||
3. **Configure development environment**
|
||||
```bash
|
||||
# Install essential development tools
|
||||
npm install -g eslint prettier jest
|
||||
pip install pylint black pytest
|
||||
|
||||
# Configure git hooks for quality checks
|
||||
git config core.hooksPath .githooks
|
||||
```
|
||||
|
||||
### Web Environment Integration
|
||||
For teams using web-based development environments, the Developer persona can be adapted for browser-based workflows.
|
||||
|
||||
#### Configuration Steps
|
||||
1. **Access development workspace**
|
||||
```
|
||||
Navigate to your development environment (GitHub Codespaces, GitPod, etc.)
|
||||
Load BMAD Method configuration
|
||||
Select "Developer" persona from available personas
|
||||
```
|
||||
|
||||
2. **Verify integration points**
|
||||
```
|
||||
Confirm access to story files in docs/stories/
|
||||
Validate connection to project management tools
|
||||
Test CI/CD pipeline integration
|
||||
```
|
||||
|
||||
## BMAD Method Workflow Integration
|
||||
|
||||
### Phase 1: Story Assignment and Initialization
|
||||
|
||||
#### Entry Points
|
||||
The Developer typically receives work through formal story assignment from Product Owners.
|
||||
|
||||
```markdown
|
||||
# Story Assignment Process
|
||||
1. **Story Creation**: Product Owner creates detailed story with acceptance criteria
|
||||
2. **Technical Review**: System Architect validates technical feasibility
|
||||
3. **Story Approval**: Story status updated to "Approved" and ready for development
|
||||
4. **Developer Assignment**: Story assigned to specific developer for implementation
|
||||
5. **Development Initiation**: Developer updates story status to "InProgress"
|
||||
```
|
||||
|
||||
#### Handoff Procedures
|
||||
```markdown
|
||||
# From Product Owner (Sarah)
|
||||
- Receive detailed user story with clear acceptance criteria
|
||||
- Understand business context and user value proposition
|
||||
- Clarify any ambiguous requirements or edge cases
|
||||
- Confirm story priority and timeline expectations
|
||||
|
||||
# From System Architect (Fred)
|
||||
- Review technical specifications and architecture guidelines
|
||||
- Understand integration points and system constraints
|
||||
- Validate technical approach and implementation strategy
|
||||
- Confirm compliance with established architectural patterns
|
||||
|
||||
# From UX/UI Architect
|
||||
- Receive design specifications and component requirements
|
||||
- Understand user experience expectations and interaction patterns
|
||||
- Clarify responsive design and accessibility requirements
|
||||
- Coordinate on design system usage and component implementation
|
||||
```
|
||||
|
||||
### Phase 2: Development Execution
|
||||
|
||||
#### Core Development Workflow
|
||||
```markdown
|
||||
# Standard Development Process
|
||||
1. **Story Analysis**: Thorough review of requirements and acceptance criteria
|
||||
2. **Technical Planning**: Break down story into implementable tasks
|
||||
3. **Implementation**: Code development following established standards
|
||||
4. **Testing**: Comprehensive test suite development and execution
|
||||
5. **Quality Assurance**: Code review, linting, and security scanning
|
||||
6. **Documentation**: Technical documentation and API documentation updates
|
||||
7. **Integration**: Validation of integration points and system compatibility
|
||||
```
|
||||
|
||||
#### Quality Gates Integration
|
||||
```markdown
|
||||
# Mandatory Quality Checkpoints
|
||||
- **Code Standards**: All code must pass linting and style checks
|
||||
- **Test Coverage**: Minimum test coverage thresholds must be met
|
||||
- **Security Scan**: No high-severity security vulnerabilities allowed
|
||||
- **Performance**: Performance benchmarks must be maintained or improved
|
||||
- **Documentation**: All public APIs and complex logic must be documented
|
||||
```
|
||||
|
||||
### Phase 3: Review and Handoff
|
||||
|
||||
#### Definition of Done (DoD) Process
|
||||
```markdown
|
||||
# DoD Checklist Validation
|
||||
1. **Functional Requirements**: All acceptance criteria are met and validated
|
||||
2. **Technical Standards**: Code meets all established quality standards
|
||||
3. **Testing Requirements**: Comprehensive test suite with adequate coverage
|
||||
4. **Documentation**: Technical and user documentation is complete
|
||||
5. **Integration**: Feature integrates properly with existing system
|
||||
6. **Performance**: Performance requirements are met or exceeded
|
||||
7. **Security**: Security requirements and best practices are implemented
|
||||
```
|
||||
|
||||
#### Downstream Handoffs
|
||||
```markdown
|
||||
# To DevOps Engineer
|
||||
- Deployable code with clear deployment instructions
|
||||
- Configuration requirements and environment variables
|
||||
- Database migration scripts and data requirements
|
||||
- Monitoring and alerting configuration needs
|
||||
|
||||
# To QA Team
|
||||
- Testable features with comprehensive test documentation
|
||||
- Test data requirements and setup instructions
|
||||
- Known limitations or edge cases requiring validation
|
||||
- User acceptance testing guidance and criteria
|
||||
|
||||
# To Product Owner
|
||||
- Completed story ready for acceptance testing
|
||||
- Demo-ready feature with usage instructions
|
||||
- Documentation of any scope changes or technical decisions
|
||||
- Recommendations for future enhancements or optimizations
|
||||
```
|
||||
|
||||
## Third-Party Tool Integrations
|
||||
|
||||
### Development Tools Integration
|
||||
|
||||
#### Version Control Systems
|
||||
```markdown
|
||||
# Git Integration
|
||||
- **GitHub**: Pull request workflows, code review processes, CI/CD integration
|
||||
- **GitLab**: Merge request workflows, built-in CI/CD, issue tracking
|
||||
- **Bitbucket**: Atlassian ecosystem integration, Jira connectivity
|
||||
|
||||
# Setup Process
|
||||
1. Configure branch protection rules and review requirements
|
||||
2. Set up automated testing and quality checks on pull requests
|
||||
3. Establish merge strategies and deployment workflows
|
||||
4. Configure issue linking and project management integration
|
||||
```
|
||||
|
||||
#### Integrated Development Environments
|
||||
```markdown
|
||||
# IDE Integration Options
|
||||
- **VS Code**: Extensions for BMAD Method, debugging, testing, and collaboration
|
||||
- **IntelliJ IDEA**: Plugin ecosystem, advanced debugging, refactoring tools
|
||||
- **Eclipse**: Java development, plugin architecture, team collaboration features
|
||||
|
||||
# Configuration Steps
|
||||
1. Install BMAD Method extensions and plugins
|
||||
2. Configure code formatting and linting rules
|
||||
3. Set up debugging configurations and test runners
|
||||
4. Integrate with version control and project management tools
|
||||
```
|
||||
|
||||
### Testing and Quality Assurance Tools
|
||||
|
||||
#### Testing Frameworks
|
||||
```markdown
|
||||
# Frontend Testing
|
||||
- **Jest**: Unit testing, snapshot testing, mocking capabilities
|
||||
- **Cypress**: End-to-end testing, visual testing, API testing
|
||||
- **React Testing Library**: Component testing, accessibility testing
|
||||
|
||||
# Backend Testing
|
||||
- **JUnit**: Java unit testing, integration testing, parameterized tests
|
||||
- **pytest**: Python testing, fixtures, parametrization, plugins
|
||||
- **Mocha/Chai**: Node.js testing, assertion library, test organization
|
||||
|
||||
# Setup Process
|
||||
1. Configure test runners and reporting tools
|
||||
2. Set up continuous testing in development environment
|
||||
3. Integrate with CI/CD pipelines for automated testing
|
||||
4. Establish test data management and cleanup procedures
|
||||
```
|
||||
|
||||
#### Code Quality Tools
|
||||
```markdown
|
||||
# Static Analysis
|
||||
- **SonarQube**: Comprehensive code quality analysis, technical debt tracking
|
||||
- **CodeClimate**: Automated code review, maintainability scoring
|
||||
- **ESLint/Pylint**: Language-specific linting and style enforcement
|
||||
|
||||
# Security Scanning
|
||||
- **Snyk**: Dependency vulnerability scanning, license compliance
|
||||
- **OWASP ZAP**: Dynamic application security testing
|
||||
- **Bandit**: Python security linting, common security issues detection
|
||||
|
||||
# Setup Process
|
||||
1. Configure quality gates and thresholds
|
||||
2. Integrate with development workflow and CI/CD
|
||||
3. Set up automated reporting and notifications
|
||||
4. Establish remediation workflows for identified issues
|
||||
```
|
||||
|
||||
### Project Management Integration
|
||||
|
||||
#### Agile and Project Management Tools
|
||||
```markdown
|
||||
# Integration Options
|
||||
- **Jira**: Story tracking, sprint management, reporting and analytics
|
||||
- **Azure DevOps**: End-to-end development lifecycle, work item tracking
|
||||
- **GitHub Issues**: Lightweight issue tracking, project boards, automation
|
||||
- **Linear**: Modern issue tracking, project management, team collaboration
|
||||
|
||||
# Setup Process
|
||||
1. Configure story templates and workflow states
|
||||
2. Establish linking between code commits and stories
|
||||
3. Set up automated status updates and notifications
|
||||
4. Create reporting dashboards and team metrics
|
||||
```
|
||||
|
||||
#### Communication and Collaboration
|
||||
```markdown
|
||||
# Team Communication
|
||||
- **Slack**: Channel-based communication, bot integrations, file sharing
|
||||
- **Microsoft Teams**: Enterprise communication, video conferencing, file collaboration
|
||||
- **Discord**: Community-style communication, voice channels, screen sharing
|
||||
|
||||
# Documentation Platforms
|
||||
- **Confluence**: Team knowledge base, technical documentation, collaboration
|
||||
- **Notion**: All-in-one workspace, documentation, project management
|
||||
- **GitBook**: Technical documentation, API documentation, team knowledge sharing
|
||||
|
||||
# Setup Process
|
||||
1. Create dedicated channels for development team communication
|
||||
2. Configure automated notifications for build status and deployments
|
||||
3. Set up shared workspaces for documentation and knowledge sharing
|
||||
4. Establish communication protocols and escalation procedures
|
||||
```
|
||||
|
||||
## Continuous Integration/Continuous Deployment (CI/CD) Integration
|
||||
|
||||
### Pipeline Configuration
|
||||
```markdown
|
||||
# CI/CD Pipeline Stages
|
||||
1. **Source Control**: Code commit triggers automated pipeline
|
||||
2. **Build**: Compile code, resolve dependencies, create artifacts
|
||||
3. **Test**: Execute unit tests, integration tests, security scans
|
||||
4. **Quality Gates**: Code quality checks, coverage thresholds, security validation
|
||||
5. **Deploy**: Automated deployment to staging and production environments
|
||||
6. **Monitor**: Post-deployment monitoring, alerting, and validation
|
||||
```
|
||||
|
||||
### Popular CI/CD Platforms
|
||||
```markdown
|
||||
# Platform Options
|
||||
- **GitHub Actions**: Native GitHub integration, marketplace of actions
|
||||
- **GitLab CI/CD**: Built-in GitLab functionality, Docker integration
|
||||
- **Jenkins**: Self-hosted, extensive plugin ecosystem, enterprise features
|
||||
- **Azure DevOps**: Microsoft ecosystem integration, comprehensive toolchain
|
||||
- **CircleCI**: Cloud-based, Docker support, parallel execution
|
||||
|
||||
# Setup Considerations
|
||||
1. Define pipeline stages and quality gates
|
||||
2. Configure automated testing and deployment strategies
|
||||
3. Set up environment-specific configurations and secrets management
|
||||
4. Establish monitoring and alerting for pipeline failures
|
||||
```
|
||||
|
||||
## Quality Assurance Integration
|
||||
|
||||
### Code Review Process
|
||||
```markdown
|
||||
# Review Workflow
|
||||
1. **Pre-Review**: Automated checks (linting, testing, security scanning)
|
||||
2. **Peer Review**: Code review by team members, architecture validation
|
||||
3. **Approval**: Required approvals from designated reviewers
|
||||
4. **Merge**: Automated merge after all checks and approvals are complete
|
||||
|
||||
# Review Criteria
|
||||
- Code follows established standards and conventions
|
||||
- Tests provide adequate coverage and validation
|
||||
- Documentation is complete and accurate
|
||||
- Security best practices are implemented
|
||||
- Performance considerations are addressed
|
||||
```
|
||||
|
||||
### Automated Quality Checks
|
||||
```markdown
|
||||
# Quality Automation
|
||||
- **Pre-commit Hooks**: Local validation before code commit
|
||||
- **Pull Request Checks**: Automated validation on code review
|
||||
- **Continuous Monitoring**: Ongoing quality assessment and reporting
|
||||
- **Deployment Gates**: Quality validation before production deployment
|
||||
|
||||
# Implementation Steps
|
||||
1. Configure automated quality tools and thresholds
|
||||
2. Set up quality gates in CI/CD pipeline
|
||||
3. Establish quality metrics and reporting
|
||||
4. Create remediation workflows for quality issues
|
||||
```
|
||||
|
||||
## Troubleshooting Integration Issues
|
||||
|
||||
### Common Integration Challenges
|
||||
|
||||
**Challenge**: CI/CD pipeline failures due to environment differences
|
||||
**Solution**: Standardize development environments using containers and infrastructure as code
|
||||
|
||||
**Challenge**: Test failures in different environments
|
||||
**Solution**: Implement comprehensive test data management and environment parity validation
|
||||
|
||||
**Challenge**: Code quality standards inconsistency across team members
|
||||
**Solution**: Automate quality checks and provide clear guidelines and training
|
||||
|
||||
**Challenge**: Integration conflicts between different development streams
|
||||
**Solution**: Implement feature branching strategies and regular integration testing
|
||||
|
||||
### Performance and Scalability Issues
|
||||
|
||||
**Challenge**: Slow build and test execution times
|
||||
**Solution**: Implement parallel execution, caching strategies, and incremental builds
|
||||
|
||||
**Challenge**: Resource constraints in development environments
|
||||
**Solution**: Optimize resource usage, implement environment sharing, and cloud-based development
|
||||
|
||||
**Challenge**: Integration bottlenecks during high-velocity development
|
||||
**Solution**: Implement trunk-based development, feature flags, and continuous integration practices
|
||||
|
||||
### Support and Escalation Procedures
|
||||
|
||||
#### Internal Support
|
||||
```markdown
|
||||
# Support Channels
|
||||
- **Technical Documentation**: Comprehensive guides and troubleshooting resources
|
||||
- **Team Knowledge Base**: Shared solutions and best practices
|
||||
- **Peer Support**: Code review, pair programming, and mentoring programs
|
||||
- **Architecture Review**: Regular architecture and design review sessions
|
||||
```
|
||||
|
||||
#### External Support
|
||||
```markdown
|
||||
# External Resources
|
||||
- **Vendor Support**: Direct support from tool and platform providers
|
||||
- **Community Forums**: Open source communities and professional networks
|
||||
- **Training and Certification**: Skill development and technology training programs
|
||||
- **Consulting Services**: Specialized expertise for complex technical challenges
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*This integration guide provides comprehensive instructions for incorporating the Developer persona into your BMAD Method implementation. For detailed capabilities and quick start instructions, refer to the Comprehensive Guide and Quick Start Guide.*
|
||||
|
|
@ -0,0 +1,326 @@
|
|||
# Developer Quality Standards
|
||||
**BMAD Method Documentation**
|
||||
|
||||
## Introduction
|
||||
|
||||
This document defines the quality standards for developers working within the BMAD Method framework. These standards ensure consistent, maintainable, and high-quality code across all projects. The standards are designed to be measurable, actionable, and aligned with industry best practices.
|
||||
|
||||
## Quality Dimensions
|
||||
|
||||
Developer quality is measured across six key dimensions, each with a specific weight in the overall quality assessment:
|
||||
|
||||
| Dimension | Weight | Description |
|
||||
|-----------|--------|-------------|
|
||||
| Code Quality | 25% | Structural quality of the code itself |
|
||||
| Functionality | 20% | Correctness and completeness of implementation |
|
||||
| Performance | 15% | Efficiency and responsiveness |
|
||||
| Maintainability | 15% | Ease of understanding and modifying code |
|
||||
| Testing | 15% | Test coverage and quality |
|
||||
| Documentation | 10% | Completeness and clarity of documentation |
|
||||
|
||||
## Quality Standards by Dimension
|
||||
|
||||
### 1. Code Quality (25%)
|
||||
|
||||
#### 1.1 Code Structure
|
||||
- **Standard**: Code follows the project's architectural patterns and design principles
|
||||
- **Measurement**: Automated static analysis tools and manual review
|
||||
- **Threshold**: No critical or high-severity structural issues
|
||||
|
||||
#### 1.2 Code Complexity
|
||||
- **Standard**: Functions and components maintain reasonable complexity
|
||||
- **Measurement**: Cyclomatic complexity < 15, cognitive complexity < 10
|
||||
- **Threshold**: 90% of code meets complexity targets
|
||||
|
||||
#### 1.3 Code Duplication
|
||||
- **Standard**: Minimal code duplication across the codebase
|
||||
- **Measurement**: Automated duplication detection
|
||||
- **Threshold**: < 5% duplication
|
||||
|
||||
#### 1.4 Coding Standards Compliance
|
||||
- **Standard**: Code adheres to project style guide and linting rules
|
||||
- **Measurement**: Automated linting
|
||||
- **Threshold**: Zero linting errors, < 5 warnings
|
||||
|
||||
#### 1.5 Clean Code Principles
|
||||
- **Standard**: Code follows clean code principles (meaningful names, single responsibility, etc.)
|
||||
- **Measurement**: Manual review using clean code checklist
|
||||
- **Threshold**: 90% compliance with clean code checklist
|
||||
|
||||
### 2. Functionality (20%)
|
||||
|
||||
#### 2.1 Requirements Fulfillment
|
||||
- **Standard**: Implementation meets all specified requirements
|
||||
- **Measurement**: Requirements traceability matrix
|
||||
- **Threshold**: 100% of requirements implemented correctly
|
||||
|
||||
#### 2.2 Error Handling
|
||||
- **Standard**: Robust error handling for all operations
|
||||
- **Measurement**: Error scenario testing and code review
|
||||
- **Threshold**: All identified error scenarios handled appropriately
|
||||
|
||||
#### 2.3 Edge Case Handling
|
||||
- **Standard**: Code handles edge cases and boundary conditions
|
||||
- **Measurement**: Edge case test coverage
|
||||
- **Threshold**: All identified edge cases handled correctly
|
||||
|
||||
#### 2.4 Accessibility Compliance
|
||||
- **Standard**: Implementation meets accessibility requirements
|
||||
- **Measurement**: Automated accessibility testing and manual review
|
||||
- **Threshold**: WCAG 2.1 AA compliance
|
||||
|
||||
#### 2.5 Cross-browser/Cross-device Compatibility
|
||||
- **Standard**: Code works consistently across required platforms
|
||||
- **Measurement**: Cross-platform testing
|
||||
- **Threshold**: Consistent behavior across all specified platforms
|
||||
|
||||
### 3. Performance (15%)
|
||||
|
||||
#### 3.1 Rendering Performance
|
||||
- **Standard**: UI renders and updates efficiently
|
||||
- **Measurement**: Render timing metrics
|
||||
- **Threshold**: Initial render < 200ms, updates < 50ms
|
||||
|
||||
#### 3.2 Memory Usage
|
||||
- **Standard**: Efficient memory usage without leaks
|
||||
- **Measurement**: Memory profiling
|
||||
- **Threshold**: No memory leaks, memory usage within defined limits
|
||||
|
||||
#### 3.3 Network Efficiency
|
||||
- **Standard**: Efficient network resource usage
|
||||
- **Measurement**: Network request count, payload size, caching
|
||||
- **Threshold**: Meets project-specific network performance budgets
|
||||
|
||||
#### 3.4 Bundle Size
|
||||
- **Standard**: Optimized bundle size
|
||||
- **Measurement**: Bundle analysis
|
||||
- **Threshold**: Meets project-specific bundle size budgets
|
||||
|
||||
#### 3.5 Algorithm Efficiency
|
||||
- **Standard**: Efficient algorithms and data structures
|
||||
- **Measurement**: Performance profiling and complexity analysis
|
||||
- **Threshold**: O(n) or better for common operations where possible
|
||||
|
||||
### 4. Maintainability (15%)
|
||||
|
||||
#### 4.1 Code Readability
|
||||
- **Standard**: Code is easy to read and understand
|
||||
- **Measurement**: Manual review using readability checklist
|
||||
- **Threshold**: 90% compliance with readability standards
|
||||
|
||||
#### 4.2 Modularity
|
||||
- **Standard**: Code is properly modularized with clear boundaries
|
||||
- **Measurement**: Module coupling and cohesion metrics
|
||||
- **Threshold**: High cohesion, low coupling across modules
|
||||
|
||||
#### 4.3 Extensibility
|
||||
- **Standard**: Code can be extended without significant modification
|
||||
- **Measurement**: Manual review of extension points
|
||||
- **Threshold**: Key extension points identified and implemented
|
||||
|
||||
#### 4.4 Configuration vs. Hardcoding
|
||||
- **Standard**: Configurable elements are not hardcoded
|
||||
- **Measurement**: Hardcoded value detection
|
||||
- **Threshold**: No business rules or configurable values hardcoded
|
||||
|
||||
#### 4.5 Technical Debt
|
||||
- **Standard**: Minimal technical debt in implementation
|
||||
- **Measurement**: Technical debt tracking tools
|
||||
- **Threshold**: Technical debt ratio < 5%
|
||||
|
||||
### 5. Testing (15%)
|
||||
|
||||
#### 5.1 Test Coverage
|
||||
- **Standard**: Comprehensive test coverage
|
||||
- **Measurement**: Code coverage metrics
|
||||
- **Threshold**: > 80% line coverage, 100% coverage of critical paths
|
||||
|
||||
#### 5.2 Test Quality
|
||||
- **Standard**: Tests are reliable, maintainable, and meaningful
|
||||
- **Measurement**: Manual review of test quality
|
||||
- **Threshold**: 90% compliance with test quality checklist
|
||||
|
||||
#### 5.3 Test Types
|
||||
- **Standard**: Appropriate mix of test types (unit, integration, e2e)
|
||||
- **Measurement**: Test type distribution
|
||||
- **Threshold**: Balanced test pyramid with appropriate coverage at each level
|
||||
|
||||
#### 5.4 Test Independence
|
||||
- **Standard**: Tests are independent and deterministic
|
||||
- **Measurement**: Test flakiness metrics
|
||||
- **Threshold**: < 1% flaky tests
|
||||
|
||||
#### 5.5 Test Maintainability
|
||||
- **Standard**: Tests are maintainable and follow testing best practices
|
||||
- **Measurement**: Manual review of test maintainability
|
||||
- **Threshold**: 90% compliance with test maintainability standards
|
||||
|
||||
### 6. Documentation (10%)
|
||||
|
||||
#### 6.1 Code Comments
|
||||
- **Standard**: Code is appropriately commented
|
||||
- **Measurement**: Comment quality and coverage review
|
||||
- **Threshold**: All complex logic and non-obvious code commented
|
||||
|
||||
#### 6.2 API Documentation
|
||||
- **Standard**: Complete and accurate API documentation
|
||||
- **Measurement**: API documentation coverage
|
||||
- **Threshold**: 100% of public APIs documented
|
||||
|
||||
#### 6.3 README and Setup Documentation
|
||||
- **Standard**: Clear setup and usage documentation
|
||||
- **Measurement**: Documentation completeness review
|
||||
- **Threshold**: All setup steps and common usage scenarios documented
|
||||
|
||||
#### 6.4 Architecture Documentation
|
||||
- **Standard**: Component architecture and relationships documented
|
||||
- **Measurement**: Architecture documentation review
|
||||
- **Threshold**: All major components and interactions documented
|
||||
|
||||
#### 6.5 Knowledge Sharing
|
||||
- **Standard**: Complex implementations include knowledge sharing
|
||||
- **Measurement**: Knowledge sharing artifacts
|
||||
- **Threshold**: Knowledge sharing completed for all complex features
|
||||
|
||||
## Quality Measurement Framework
|
||||
|
||||
### Quality Scoring System
|
||||
|
||||
Each quality dimension is scored on a 5-point scale:
|
||||
|
||||
| Score | Description |
|
||||
|-------|-------------|
|
||||
| 5 | Exceptional - Exceeds all standards |
|
||||
| 4 | Strong - Meets all standards with some exceeding |
|
||||
| 3 | Satisfactory - Meets all minimum standards |
|
||||
| 2 | Needs Improvement - Falls short on some standards |
|
||||
| 1 | Unsatisfactory - Falls short on multiple standards |
|
||||
|
||||
### Calculation of Overall Quality Score
|
||||
|
||||
The overall quality score is calculated as a weighted average of the dimension scores:
|
||||
|
||||
```
|
||||
Overall Score = (Code Quality × 0.25) + (Functionality × 0.20) + (Performance × 0.15) +
|
||||
(Maintainability × 0.15) + (Testing × 0.15) + (Documentation × 0.10)
|
||||
```
|
||||
|
||||
### Quality Levels
|
||||
|
||||
Based on the overall score, work is classified into one of four quality levels:
|
||||
|
||||
| Level | Score Range | Description |
|
||||
|-------|-------------|-------------|
|
||||
| Exceptional | 4.5 - 5.0 | Exemplary quality that can serve as a reference |
|
||||
| Strong | 3.5 - 4.4 | High-quality work that meets all standards |
|
||||
| Satisfactory | 3.0 - 3.4 | Acceptable quality that meets minimum standards |
|
||||
| Needs Improvement | < 3.0 | Quality issues that need to be addressed |
|
||||
|
||||
## Quality Assurance Process
|
||||
|
||||
### 1. Self-Assessment
|
||||
|
||||
Developers perform a self-assessment against quality standards:
|
||||
|
||||
- Complete the quality checklist for each dimension
|
||||
- Document any known deviations from standards
|
||||
- Prepare justification for any standards that cannot be met
|
||||
|
||||
### 2. Peer Review
|
||||
|
||||
Code undergoes peer review before being considered complete:
|
||||
|
||||
- At least one peer reviewer must approve
|
||||
- Reviewer evaluates against all quality dimensions
|
||||
- Reviewer provides specific feedback on areas for improvement
|
||||
|
||||
### 3. Automated Checks
|
||||
|
||||
Automated tools verify compliance with measurable standards:
|
||||
|
||||
- Static code analysis
|
||||
- Linting and style checking
|
||||
- Test coverage analysis
|
||||
- Performance benchmarking
|
||||
- Accessibility testing
|
||||
|
||||
### 4. Quality Gates
|
||||
|
||||
Implementation must pass quality gates at key milestones:
|
||||
|
||||
- **Development Complete**: Self-assessment and automated checks pass
|
||||
- **Review Complete**: Peer review approval and resolution of feedback
|
||||
- **Release Ready**: Final quality verification and documentation complete
|
||||
|
||||
## Continuous Improvement
|
||||
|
||||
### Quality Metrics Tracking
|
||||
|
||||
Quality metrics are tracked over time to identify trends:
|
||||
|
||||
- Team-level quality metrics dashboard
|
||||
- Individual developer quality profiles
|
||||
- Project-specific quality trends
|
||||
|
||||
### Learning and Development
|
||||
|
||||
Continuous improvement is supported through:
|
||||
|
||||
- Regular code quality workshops
|
||||
- Sharing of best practices and lessons learned
|
||||
- Recognition of exceptional quality work
|
||||
- Targeted training for areas needing improvement
|
||||
|
||||
### Standards Evolution
|
||||
|
||||
Quality standards evolve based on:
|
||||
|
||||
- Retrospective feedback
|
||||
- Industry best practice changes
|
||||
- Technology stack evolution
|
||||
- Project-specific requirements
|
||||
|
||||
## Appendix: Quality Checklists
|
||||
|
||||
### Code Quality Checklist
|
||||
|
||||
- [ ] Code follows architectural patterns
|
||||
- [ ] Functions/components have single responsibility
|
||||
- [ ] Naming is clear and consistent
|
||||
- [ ] Error handling is comprehensive
|
||||
- [ ] No code smells (long methods, large classes, etc.)
|
||||
- [ ] No duplication of logic
|
||||
- [ ] Consistent formatting and style
|
||||
- [ ] No commented-out code
|
||||
- [ ] No hardcoded values that should be configurable
|
||||
- [ ] Appropriate use of language/framework features
|
||||
|
||||
### Functionality Checklist
|
||||
|
||||
- [ ] All requirements implemented correctly
|
||||
- [ ] Edge cases handled appropriately
|
||||
- [ ] Error states managed gracefully
|
||||
- [ ] Accessibility requirements met
|
||||
- [ ] Cross-browser/device compatibility verified
|
||||
- [ ] Internationalization supported if required
|
||||
- [ ] Security best practices followed
|
||||
- [ ] User experience consistent with design specifications
|
||||
- [ ] Performance requirements met
|
||||
- [ ] Integration points work correctly
|
||||
|
||||
### Testing Checklist
|
||||
|
||||
- [ ] Unit tests cover core functionality
|
||||
- [ ] Integration tests verify component interactions
|
||||
- [ ] Edge cases and error conditions tested
|
||||
- [ ] Performance tests for critical paths
|
||||
- [ ] Accessibility tests included
|
||||
- [ ] Tests are deterministic (no flakiness)
|
||||
- [ ] Test descriptions are clear and meaningful
|
||||
- [ ] Mocks and test doubles used appropriately
|
||||
- [ ] Test coverage meets minimum thresholds
|
||||
- [ ] Tests follow AAA (Arrange-Act-Assert) pattern
|
||||
|
||||
---
|
||||
|
||||
*Last Updated: June 2025*
|
||||
|
|
@ -0,0 +1,473 @@
|
|||
# Developer (Dev) - Quick Start Guide
|
||||
|
||||
## 5-Minute Setup
|
||||
|
||||
### Step 1: Environment Activation (1 minute)
|
||||
```bash
|
||||
# In your IDE or development environment
|
||||
1. Load BMAD Method workspace
|
||||
2. Select "Developer" persona
|
||||
3. Verify activation: "Expert Senior Software Engineer"
|
||||
4. Confirm access to essential directories:
|
||||
- docs/stories/ (for story files)
|
||||
- docs/checklists/ (for quality checklists)
|
||||
- .ai/ (for debug log)
|
||||
```
|
||||
|
||||
### Step 2: Story Assignment Verification (1 minute)
|
||||
```markdown
|
||||
# Check Story Status
|
||||
1. Locate your assigned story file: docs/stories/{epicNumber}.{storyNumber}.story.md
|
||||
2. Verify story status is "Approved" or ready for development
|
||||
3. Review acceptance criteria and technical requirements
|
||||
4. Update story status to "InProgress"
|
||||
|
||||
# Example Story File Check
|
||||
- Story ID: 1.2.story.md
|
||||
- Status: Approved ✅
|
||||
- Acceptance Criteria: Clear and testable ✅
|
||||
- Technical Requirements: Defined ✅
|
||||
```
|
||||
|
||||
### Step 3: Development Environment Validation (2 minutes)
|
||||
```bash
|
||||
# Essential Tool Verification
|
||||
# Check version control
|
||||
git --version
|
||||
git status
|
||||
|
||||
# Check package managers
|
||||
npm --version # or yarn --version
|
||||
pip --version # if using Python
|
||||
|
||||
# Check testing frameworks
|
||||
npm test --version # or appropriate test command
|
||||
pytest --version # if using Python
|
||||
|
||||
# Check linting tools
|
||||
eslint --version # or appropriate linter
|
||||
pylint --version # if using Python
|
||||
```
|
||||
|
||||
### Step 4: First Development Task (1 minute)
|
||||
```markdown
|
||||
# Quick Development Test
|
||||
1. Create a simple test file to verify environment
|
||||
2. Run linting and testing commands
|
||||
3. Commit changes to verify git integration
|
||||
4. Update story file with initial progress
|
||||
|
||||
# Example Test
|
||||
echo "console.log('BMAD Dev Environment Ready');" > test-setup.js
|
||||
npm run lint test-setup.js
|
||||
git add test-setup.js
|
||||
git commit -m "Verify development environment setup"
|
||||
```
|
||||
|
||||
## Practical Example: User Authentication Feature
|
||||
|
||||
### Scenario Setup
|
||||
```markdown
|
||||
**Story**: "As a user, I want to log in with email and password so that I can access my account"
|
||||
**Epic**: User Management (Epic 2)
|
||||
**Story ID**: 2.1
|
||||
**Acceptance Criteria**:
|
||||
- User can enter email and password
|
||||
- System validates credentials against database
|
||||
- Successful login redirects to dashboard
|
||||
- Failed login shows appropriate error message
|
||||
- Login attempts are rate-limited for security
|
||||
```
|
||||
|
||||
### Development Session Example
|
||||
|
||||
#### Phase 1: Story Analysis and Planning (5 minutes)
|
||||
```markdown
|
||||
Developer: "Let me analyze this authentication story and break it down into implementable tasks."
|
||||
|
||||
Story Breakdown:
|
||||
1. **Frontend Components**
|
||||
- Login form with email/password fields
|
||||
- Form validation and error handling
|
||||
- Loading states and user feedback
|
||||
|
||||
2. **Backend API**
|
||||
- Authentication endpoint (/api/auth/login)
|
||||
- Credential validation logic
|
||||
- JWT token generation and management
|
||||
|
||||
3. **Security Implementation**
|
||||
- Password hashing and verification
|
||||
- Rate limiting for login attempts
|
||||
- Input sanitization and validation
|
||||
|
||||
4. **Testing Requirements**
|
||||
- Unit tests for authentication logic
|
||||
- Integration tests for API endpoints
|
||||
- End-to-end tests for login flow
|
||||
|
||||
Tasks Updated in Story File:
|
||||
- [ ] Create login form component
|
||||
- [ ] Implement authentication API endpoint
|
||||
- [ ] Add password hashing and verification
|
||||
- [ ] Implement rate limiting middleware
|
||||
- [ ] Create comprehensive test suite
|
||||
- [ ] Add error handling and user feedback
|
||||
```
|
||||
|
||||
#### Phase 2: Implementation Execution (30 minutes)
|
||||
```javascript
|
||||
// Frontend Component Implementation
|
||||
// components/LoginForm.jsx
|
||||
import React, { useState } from 'react';
|
||||
import { useAuth } from '../hooks/useAuth';
|
||||
|
||||
const LoginForm = () => {
|
||||
const [credentials, setCredentials] = useState({ email: '', password: '' });
|
||||
const [errors, setErrors] = useState({});
|
||||
const { login, loading } = useAuth();
|
||||
|
||||
const handleSubmit = async (e) => {
|
||||
e.preventDefault();
|
||||
try {
|
||||
await login(credentials);
|
||||
// Redirect handled by useAuth hook
|
||||
} catch (error) {
|
||||
setErrors({ general: error.message });
|
||||
}
|
||||
};
|
||||
|
||||
return (
|
||||
<form onSubmit={handleSubmit} className="login-form">
|
||||
<div className="form-group">
|
||||
<label htmlFor="email">Email</label>
|
||||
<input
|
||||
id="email"
|
||||
type="email"
|
||||
value={credentials.email}
|
||||
onChange={(e) => setCredentials({...credentials, email: e.target.value})}
|
||||
required
|
||||
/>
|
||||
</div>
|
||||
|
||||
<div className="form-group">
|
||||
<label htmlFor="password">Password</label>
|
||||
<input
|
||||
id="password"
|
||||
type="password"
|
||||
value={credentials.password}
|
||||
onChange={(e) => setCredentials({...credentials, password: e.target.value})}
|
||||
required
|
||||
/>
|
||||
</div>
|
||||
|
||||
{errors.general && <div className="error">{errors.general}</div>}
|
||||
|
||||
<button type="submit" disabled={loading}>
|
||||
{loading ? 'Logging in...' : 'Login'}
|
||||
</button>
|
||||
</form>
|
||||
);
|
||||
};
|
||||
|
||||
export default LoginForm;
|
||||
```
|
||||
|
||||
```javascript
|
||||
// Backend API Implementation
|
||||
// routes/auth.js
|
||||
const express = require('express');
|
||||
const bcrypt = require('bcrypt');
|
||||
const jwt = require('jsonwebtoken');
|
||||
const rateLimit = require('express-rate-limit');
|
||||
const User = require('../models/User');
|
||||
|
||||
const router = express.Router();
|
||||
|
||||
// Rate limiting middleware
|
||||
const loginLimiter = rateLimit({
|
||||
windowMs: 15 * 60 * 1000, // 15 minutes
|
||||
max: 5, // 5 attempts per window
|
||||
message: 'Too many login attempts, please try again later',
|
||||
standardHeaders: true,
|
||||
legacyHeaders: false,
|
||||
});
|
||||
|
||||
router.post('/login', loginLimiter, async (req, res) => {
|
||||
try {
|
||||
const { email, password } = req.body;
|
||||
|
||||
// Input validation
|
||||
if (!email || !password) {
|
||||
return res.status(400).json({ error: 'Email and password are required' });
|
||||
}
|
||||
|
||||
// Find user
|
||||
const user = await User.findOne({ email: email.toLowerCase() });
|
||||
if (!user) {
|
||||
return res.status(401).json({ error: 'Invalid credentials' });
|
||||
}
|
||||
|
||||
// Verify password
|
||||
const isValidPassword = await bcrypt.compare(password, user.passwordHash);
|
||||
if (!isValidPassword) {
|
||||
return res.status(401).json({ error: 'Invalid credentials' });
|
||||
}
|
||||
|
||||
// Generate JWT token
|
||||
const token = jwt.sign(
|
||||
{ userId: user._id, email: user.email },
|
||||
process.env.JWT_SECRET,
|
||||
{ expiresIn: '24h' }
|
||||
);
|
||||
|
||||
res.json({
|
||||
token,
|
||||
user: {
|
||||
id: user._id,
|
||||
email: user.email,
|
||||
name: user.name
|
||||
}
|
||||
});
|
||||
|
||||
} catch (error) {
|
||||
console.error('Login error:', error);
|
||||
res.status(500).json({ error: 'Internal server error' });
|
||||
}
|
||||
});
|
||||
|
||||
module.exports = router;
|
||||
```
|
||||
|
||||
#### Phase 3: Testing Implementation (15 minutes)
|
||||
```javascript
|
||||
// Unit Tests
|
||||
// tests/auth.test.js
|
||||
const request = require('supertest');
|
||||
const app = require('../app');
|
||||
const User = require('../models/User');
|
||||
const bcrypt = require('bcrypt');
|
||||
|
||||
describe('Authentication API', () => {
|
||||
beforeEach(async () => {
|
||||
await User.deleteMany({});
|
||||
|
||||
// Create test user
|
||||
const passwordHash = await bcrypt.hash('testpassword', 10);
|
||||
await User.create({
|
||||
email: 'test@example.com',
|
||||
passwordHash,
|
||||
name: 'Test User'
|
||||
});
|
||||
});
|
||||
|
||||
describe('POST /api/auth/login', () => {
|
||||
it('should login with valid credentials', async () => {
|
||||
const response = await request(app)
|
||||
.post('/api/auth/login')
|
||||
.send({
|
||||
email: 'test@example.com',
|
||||
password: 'testpassword'
|
||||
});
|
||||
|
||||
expect(response.status).toBe(200);
|
||||
expect(response.body.token).toBeDefined();
|
||||
expect(response.body.user.email).toBe('test@example.com');
|
||||
});
|
||||
|
||||
it('should reject invalid credentials', async () => {
|
||||
const response = await request(app)
|
||||
.post('/api/auth/login')
|
||||
.send({
|
||||
email: 'test@example.com',
|
||||
password: 'wrongpassword'
|
||||
});
|
||||
|
||||
expect(response.status).toBe(401);
|
||||
expect(response.body.error).toBe('Invalid credentials');
|
||||
});
|
||||
|
||||
it('should enforce rate limiting', async () => {
|
||||
// Make 6 requests (exceeding the 5 request limit)
|
||||
for (let i = 0; i < 6; i++) {
|
||||
const response = await request(app)
|
||||
.post('/api/auth/login')
|
||||
.send({
|
||||
email: 'test@example.com',
|
||||
password: 'wrongpassword'
|
||||
});
|
||||
|
||||
if (i === 5) {
|
||||
expect(response.status).toBe(429);
|
||||
}
|
||||
}
|
||||
});
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
#### Phase 4: Quality Assurance and DoD Check (10 minutes)
|
||||
```markdown
|
||||
Developer: "Running comprehensive quality checks before marking story complete."
|
||||
|
||||
Quality Assurance Checklist:
|
||||
✅ Code follows established style guidelines (ESLint passed)
|
||||
✅ All tests pass (Unit: 15/15, Integration: 8/8, E2E: 3/3)
|
||||
✅ Test coverage exceeds 80% threshold (Current: 92%)
|
||||
✅ Security scan passed (No high-severity vulnerabilities)
|
||||
✅ Performance benchmarks met (Login response < 200ms)
|
||||
✅ Documentation updated (API docs, component docs)
|
||||
✅ Accessibility requirements met (WCAG 2.1 AA compliance)
|
||||
|
||||
Definition of Done Validation:
|
||||
✅ All acceptance criteria implemented and tested
|
||||
✅ Code reviewed and approved by senior developer
|
||||
✅ Integration with existing authentication system verified
|
||||
✅ Error handling and edge cases covered
|
||||
✅ Security best practices implemented
|
||||
✅ User experience validated with UX team
|
||||
✅ Ready for deployment to staging environment
|
||||
|
||||
Story Status: Ready for Review ✅
|
||||
```
|
||||
|
||||
## Common Development Patterns
|
||||
|
||||
### Quick Bug Fix
|
||||
```markdown
|
||||
# 15-Minute Bug Resolution
|
||||
1. "There's a bug in the user profile update functionality"
|
||||
2. Developer analyzes error logs and reproduces issue
|
||||
3. Identifies root cause in validation logic
|
||||
4. Implements fix with additional test coverage
|
||||
5. Validates fix and updates documentation
|
||||
|
||||
Example Process:
|
||||
- Reproduce bug in development environment
|
||||
- Write failing test that demonstrates the issue
|
||||
- Implement minimal fix to resolve the issue
|
||||
- Verify all tests pass including the new test
|
||||
- Update story file and prepare for review
|
||||
```
|
||||
|
||||
### Feature Enhancement
|
||||
```markdown
|
||||
# 30-Minute Feature Addition
|
||||
1. "Add password strength indicator to registration form"
|
||||
2. Developer reviews existing registration component
|
||||
3. Implements password strength calculation logic
|
||||
4. Adds visual indicator component with styling
|
||||
5. Creates comprehensive test suite for new functionality
|
||||
|
||||
Example Implementation:
|
||||
- Analyze current password validation logic
|
||||
- Create password strength calculation utility
|
||||
- Implement visual indicator component
|
||||
- Add real-time feedback as user types
|
||||
- Test across different password scenarios
|
||||
```
|
||||
|
||||
### Performance Optimization
|
||||
```markdown
|
||||
# 45-Minute Performance Improvement
|
||||
1. "Dashboard loading time is too slow"
|
||||
2. Developer profiles application performance
|
||||
3. Identifies database query optimization opportunities
|
||||
4. Implements caching and query improvements
|
||||
5. Validates performance improvements with benchmarks
|
||||
|
||||
Example Process:
|
||||
- Profile current performance with monitoring tools
|
||||
- Identify bottlenecks in database queries or API calls
|
||||
- Implement targeted optimizations (caching, indexing, etc.)
|
||||
- Measure performance improvements
|
||||
- Document changes and update monitoring
|
||||
```
|
||||
|
||||
## Quick Reference Commands
|
||||
|
||||
### Development Commands
|
||||
```bash
|
||||
# Essential Development Tasks
|
||||
npm start # Start development server
|
||||
npm test # Run test suite
|
||||
npm run lint # Check code quality
|
||||
npm run build # Build for production
|
||||
npm run dev # Start development with hot reload
|
||||
|
||||
# Git Workflow
|
||||
git status # Check current status
|
||||
git add . # Stage all changes
|
||||
git commit -m "message" # Commit with message
|
||||
git push origin feature # Push feature branch
|
||||
git pull origin main # Pull latest changes
|
||||
```
|
||||
|
||||
### Quality Assurance Commands
|
||||
```bash
|
||||
# Quality Checks
|
||||
npm run test:coverage # Generate test coverage report
|
||||
npm run lint:fix # Auto-fix linting issues
|
||||
npm run security:scan # Run security vulnerability scan
|
||||
npm run performance:test # Run performance benchmarks
|
||||
|
||||
# Code Analysis
|
||||
npm run analyze # Analyze bundle size and dependencies
|
||||
npm run docs:generate # Generate API documentation
|
||||
npm run format # Format code with Prettier
|
||||
```
|
||||
|
||||
### Story Management Commands
|
||||
```bash
|
||||
# BMAD Method Specific
|
||||
*story-status # Check current story progress
|
||||
*update-progress # Update story file with current status
|
||||
*dod-check # Run Definition of Done checklist
|
||||
*core-dump # Record current state and run diagnostics
|
||||
*help # List all available commands
|
||||
```
|
||||
|
||||
## Best Practices Checklist
|
||||
|
||||
### Before Starting Development
|
||||
- [ ] Story status is "Approved" and ready for development
|
||||
- [ ] All acceptance criteria are clear and testable
|
||||
- [ ] Technical requirements and constraints are understood
|
||||
- [ ] Development environment is set up and validated
|
||||
- [ ] Story file is updated to "InProgress" status
|
||||
|
||||
### During Development
|
||||
- [ ] Follow established coding standards and conventions
|
||||
- [ ] Write tests for all new functionality
|
||||
- [ ] Commit changes frequently with descriptive messages
|
||||
- [ ] Update story file with progress and any blockers
|
||||
- [ ] Seek clarification for any ambiguous requirements
|
||||
|
||||
### Before Completing Story
|
||||
- [ ] All acceptance criteria are implemented and tested
|
||||
- [ ] Code passes all quality checks (linting, testing, security)
|
||||
- [ ] Documentation is updated and complete
|
||||
- [ ] Integration with existing system is validated
|
||||
- [ ] Definition of Done checklist is completed
|
||||
- [ ] Story file is updated to "Review" status
|
||||
|
||||
## Troubleshooting Quick Fixes
|
||||
|
||||
### "Tests are failing"
|
||||
**Solution**: Run tests individually to isolate failures, check test data setup, verify environment configuration
|
||||
|
||||
### "Code quality checks failing"
|
||||
**Solution**: Run linting with auto-fix, review coding standards, update code to meet quality requirements
|
||||
|
||||
### "Integration issues with existing code"
|
||||
**Solution**: Review API contracts, validate data formats, check version compatibility, coordinate with team
|
||||
|
||||
### "Performance issues in development"
|
||||
**Solution**: Profile code execution, optimize database queries, implement caching, review resource usage
|
||||
|
||||
### "Unclear requirements"
|
||||
**Solution**: Document specific questions, seek clarification from Product Owner, update story with clarifications
|
||||
|
||||
---
|
||||
|
||||
*This quick start guide gets you productive with the Developer persona immediately. For comprehensive capabilities and advanced integration details, refer to the Comprehensive Guide and Integration Guide.*
|
||||
|
|
@ -0,0 +1,348 @@
|
|||
# Developer Success Metrics
|
||||
**BMAD Method Documentation**
|
||||
|
||||
## Introduction
|
||||
|
||||
This document defines the success metrics for developers working within the BMAD Method framework. These metrics provide a comprehensive framework for measuring developer effectiveness, quality of work, and contribution to project success. The metrics are designed to be objective, actionable, and aligned with overall project goals.
|
||||
|
||||
## Success Metric Categories
|
||||
|
||||
Developer success is measured across five key categories:
|
||||
|
||||
1. **Delivery Performance** - Measures the developer's ability to deliver work efficiently
|
||||
2. **Code Quality** - Assesses the quality of code produced
|
||||
3. **Technical Impact** - Evaluates the developer's technical contribution to the project
|
||||
4. **Collaboration** - Measures effectiveness in working with others
|
||||
5. **Growth & Learning** - Tracks professional development and knowledge sharing
|
||||
|
||||
## Metric Definitions and Targets
|
||||
|
||||
### 1. Delivery Performance (25%)
|
||||
|
||||
#### 1.1 Cycle Time
|
||||
- **Definition**: Average time from task start to completion
|
||||
- **Measurement**: (Completion Date - Start Date) / Number of Tasks
|
||||
- **Target**: < 3 days for standard tasks, < 1 day for small tasks, < 7 days for complex tasks
|
||||
- **Data Source**: Project management tool
|
||||
|
||||
#### 1.2 Estimation Accuracy
|
||||
- **Definition**: Accuracy of time/effort estimates
|
||||
- **Measurement**: Actual Time / Estimated Time (1.0 is perfect)
|
||||
- **Target**: Between 0.8 and 1.2 (±20% variance)
|
||||
- **Data Source**: Time tracking system, project management tool
|
||||
|
||||
#### 1.3 Throughput
|
||||
- **Definition**: Number of tasks completed per sprint
|
||||
- **Measurement**: Count of completed tasks per sprint
|
||||
- **Target**: Team average ±15%
|
||||
- **Data Source**: Project management tool
|
||||
|
||||
#### 1.4 First-Time Acceptance Rate
|
||||
- **Definition**: Percentage of work accepted without rework
|
||||
- **Measurement**: (Tasks Accepted First Time / Total Tasks) × 100
|
||||
- **Target**: > 85%
|
||||
- **Data Source**: Code review system, project management tool
|
||||
|
||||
#### 1.5 On-Time Delivery
|
||||
- **Definition**: Percentage of tasks delivered by committed date
|
||||
- **Measurement**: (Tasks Delivered On Time / Total Tasks) × 100
|
||||
- **Target**: > 90%
|
||||
- **Data Source**: Project management tool
|
||||
|
||||
### 2. Code Quality (25%)
|
||||
|
||||
#### 2.1 Defect Density
|
||||
- **Definition**: Number of defects per unit of code
|
||||
- **Measurement**: Defects / 1000 Lines of Code
|
||||
- **Target**: < 1.0 defects per 1000 LOC
|
||||
- **Data Source**: Issue tracking system, code repository
|
||||
|
||||
#### 2.2 Test Coverage
|
||||
- **Definition**: Percentage of code covered by tests
|
||||
- **Measurement**: (Covered Lines / Total Lines) × 100
|
||||
- **Target**: > 80% overall, > 90% for critical paths
|
||||
- **Data Source**: Test coverage tools
|
||||
|
||||
#### 2.3 Static Analysis Score
|
||||
- **Definition**: Score from static analysis tools
|
||||
- **Measurement**: Composite score from tools like SonarQube
|
||||
- **Target**: > 85/100
|
||||
- **Data Source**: Static analysis tools
|
||||
|
||||
#### 2.4 Code Review Feedback
|
||||
- **Definition**: Quality issues identified in code reviews
|
||||
- **Measurement**: Average number of substantive comments per review
|
||||
- **Target**: < 3 substantive issues per review
|
||||
- **Data Source**: Code review system
|
||||
|
||||
#### 2.5 Technical Debt Contribution
|
||||
- **Definition**: Net change in technical debt
|
||||
- **Measurement**: (Technical Debt Reduced - Technical Debt Added)
|
||||
- **Target**: Net positive (more debt reduced than added)
|
||||
- **Data Source**: Static analysis tools, technical debt tracking
|
||||
|
||||
### 3. Technical Impact (20%)
|
||||
|
||||
#### 3.1 Architecture Contribution
|
||||
- **Definition**: Contribution to system architecture
|
||||
- **Measurement**: Qualitative assessment by Architect
|
||||
- **Target**: Positive contribution score
|
||||
- **Data Source**: Architecture review process
|
||||
|
||||
#### 3.2 Innovation
|
||||
- **Definition**: Introduction of valuable new approaches or solutions
|
||||
- **Measurement**: Count of innovations adopted
|
||||
- **Target**: At least 1 per quarter
|
||||
- **Data Source**: Innovation tracking, retrospectives
|
||||
|
||||
#### 3.3 Performance Optimization
|
||||
- **Definition**: Measurable performance improvements
|
||||
- **Measurement**: Percentage improvement in key metrics
|
||||
- **Target**: 10%+ improvement when optimization is the goal
|
||||
- **Data Source**: Performance testing tools
|
||||
|
||||
#### 3.4 Reusability
|
||||
- **Definition**: Creation of reusable components/code
|
||||
- **Measurement**: Adoption rate of created components
|
||||
- **Target**: > 2 reuses per component
|
||||
- **Data Source**: Component usage tracking
|
||||
|
||||
#### 3.5 Technical Leadership
|
||||
- **Definition**: Influence on technical decisions and direction
|
||||
- **Measurement**: Qualitative assessment by team and leadership
|
||||
- **Target**: Positive influence score
|
||||
- **Data Source**: Peer feedback, leadership assessment
|
||||
|
||||
### 4. Collaboration (15%)
|
||||
|
||||
#### 4.1 Cross-functional Collaboration
|
||||
- **Definition**: Effective work with non-developer roles
|
||||
- **Measurement**: Feedback score from other roles
|
||||
- **Target**: > 4.0/5.0 average score
|
||||
- **Data Source**: Collaboration feedback surveys
|
||||
|
||||
#### 4.2 Code Review Participation
|
||||
- **Definition**: Active participation in code reviews
|
||||
- **Measurement**: (Reviews Completed / Reviews Assigned) × 100
|
||||
- **Target**: > 90% completion rate
|
||||
- **Data Source**: Code review system
|
||||
|
||||
#### 4.3 Knowledge Sharing
|
||||
- **Definition**: Contribution to team knowledge
|
||||
- **Measurement**: Count of documented knowledge sharing activities
|
||||
- **Target**: At least 1 formal sharing per month
|
||||
- **Data Source**: Knowledge base contributions, presentations
|
||||
|
||||
#### 4.4 Mentoring
|
||||
- **Definition**: Support provided to other team members
|
||||
- **Measurement**: Mentoring hours and feedback
|
||||
- **Target**: Positive mentoring impact
|
||||
- **Data Source**: Mentoring program tracking, mentee feedback
|
||||
|
||||
#### 4.5 Team Support
|
||||
- **Definition**: Assistance provided to unblock others
|
||||
- **Measurement**: Instances of meaningful support
|
||||
- **Target**: Regular support activities
|
||||
- **Data Source**: Peer recognition, support tracking
|
||||
|
||||
### 5. Growth & Learning (15%)
|
||||
|
||||
#### 5.1 Skill Development
|
||||
- **Definition**: Acquisition of new technical skills
|
||||
- **Measurement**: Skills added to competency matrix
|
||||
- **Target**: At least 2 new skills or significant improvements per quarter
|
||||
- **Data Source**: Skill assessment, learning platform
|
||||
|
||||
#### 5.2 Learning Activity
|
||||
- **Definition**: Time invested in learning
|
||||
- **Measurement**: Hours spent on structured learning
|
||||
- **Target**: At least 4 hours per week
|
||||
- **Data Source**: Learning platform, self-reporting
|
||||
|
||||
#### 5.3 Certification Progress
|
||||
- **Definition**: Progress toward relevant certifications
|
||||
- **Measurement**: Milestones achieved toward certification
|
||||
- **Target**: On track with certification plan
|
||||
- **Data Source**: Certification tracking
|
||||
|
||||
#### 5.4 Feedback Implementation
|
||||
- **Definition**: Application of received feedback
|
||||
- **Measurement**: Percentage of feedback items addressed
|
||||
- **Target**: > 80% of feedback addressed
|
||||
- **Data Source**: Feedback tracking, 1:1 meetings
|
||||
|
||||
#### 5.5 Continuous Improvement
|
||||
- **Definition**: Self-initiated improvements in work processes
|
||||
- **Measurement**: Count of implemented improvements
|
||||
- **Target**: At least 1 significant improvement per quarter
|
||||
- **Data Source**: Process improvement tracking, retrospectives
|
||||
|
||||
## Success Scoring System
|
||||
|
||||
### Calculation Method
|
||||
|
||||
Each metric is scored on a scale of 1-5:
|
||||
|
||||
| Score | Description |
|
||||
|-------|-------------|
|
||||
| 5 | Exceptional - Significantly exceeds target |
|
||||
| 4 | Exceeds - Above target |
|
||||
| 3 | Meets - Meets target |
|
||||
| 2 | Approaching - Below target but improving |
|
||||
| 1 | Needs Improvement - Significantly below target |
|
||||
|
||||
The overall success score is calculated as a weighted average:
|
||||
|
||||
```
|
||||
Overall Score = (Delivery × 0.25) + (Quality × 0.25) + (Impact × 0.20) +
|
||||
(Collaboration × 0.15) + (Growth × 0.15)
|
||||
```
|
||||
|
||||
### Performance Levels
|
||||
|
||||
Based on the overall score, performance is classified into one of four levels:
|
||||
|
||||
| Level | Score Range | Description |
|
||||
|-------|-------------|-------------|
|
||||
| Distinguished | 4.5 - 5.0 | Exceptional performance across all dimensions |
|
||||
| Strong | 3.5 - 4.4 | Strong performance exceeding expectations |
|
||||
| Proficient | 3.0 - 3.4 | Solid performance meeting expectations |
|
||||
| Developing | < 3.0 | Performance needs improvement in key areas |
|
||||
|
||||
## Measurement Process
|
||||
|
||||
### Data Collection
|
||||
|
||||
Success metrics data is collected through:
|
||||
|
||||
1. **Automated Tools**:
|
||||
- Project management system
|
||||
- Code repository analytics
|
||||
- Static analysis tools
|
||||
- Test coverage tools
|
||||
- Time tracking system
|
||||
|
||||
2. **Manual Assessment**:
|
||||
- Peer feedback
|
||||
- Leadership assessment
|
||||
- Self-assessment
|
||||
- Code review feedback
|
||||
|
||||
### Measurement Frequency
|
||||
|
||||
- **Sprint-level Metrics**: Collected and reviewed each sprint
|
||||
- **Monthly Metrics**: Aggregated and reviewed monthly
|
||||
- **Quarterly Metrics**: Comprehensive review quarterly
|
||||
- **Annual Metrics**: Full performance assessment annually
|
||||
|
||||
### Reporting and Visualization
|
||||
|
||||
Metrics are reported through:
|
||||
|
||||
1. **Personal Dashboard**: Individual view of personal metrics
|
||||
2. **Team Dashboard**: Anonymized team-level metrics
|
||||
3. **Trend Analysis**: Performance trends over time
|
||||
4. **Comparative Analysis**: Benchmarking against team averages
|
||||
|
||||
## Using Success Metrics
|
||||
|
||||
### For Individual Developers
|
||||
|
||||
Success metrics should be used by developers to:
|
||||
|
||||
1. **Self-assessment**: Identify personal strengths and areas for improvement
|
||||
2. **Goal Setting**: Establish specific, measurable development goals
|
||||
3. **Progress Tracking**: Monitor improvement over time
|
||||
4. **Career Development**: Guide professional growth and specialization
|
||||
|
||||
### For Team Leads and Managers
|
||||
|
||||
Success metrics should be used by leads and managers to:
|
||||
|
||||
1. **Performance Coaching**: Provide targeted feedback and guidance
|
||||
2. **Resource Allocation**: Assign tasks based on strengths and development needs
|
||||
3. **Team Composition**: Build balanced teams with complementary skills
|
||||
4. **Recognition**: Identify and recognize exceptional performance
|
||||
|
||||
### For Organizations
|
||||
|
||||
Success metrics should be used by organizations to:
|
||||
|
||||
1. **Process Improvement**: Identify systemic issues affecting developer success
|
||||
2. **Training Programs**: Design targeted training based on common development needs
|
||||
3. **Best Practices**: Identify and propagate effective practices
|
||||
4. **Talent Development**: Support career progression and growth
|
||||
|
||||
## Continuous Improvement of Metrics
|
||||
|
||||
The success metrics framework itself is subject to continuous improvement:
|
||||
|
||||
1. **Metric Review**: Quarterly review of metric effectiveness
|
||||
2. **Feedback Collection**: Regular feedback from developers and stakeholders
|
||||
3. **Calibration**: Adjustment of targets based on project context
|
||||
4. **Evolution**: Addition, modification, or removal of metrics as needed
|
||||
|
||||
## Appendix: Success Metrics Dashboard
|
||||
|
||||
### Sample Individual Dashboard
|
||||
|
||||
```
|
||||
Developer Success Metrics - Q2 2025
|
||||
Developer: [Name]
|
||||
|
||||
Overall Score: 4.2/5.0 (Strong)
|
||||
|
||||
Category Scores:
|
||||
- Delivery Performance: 4.3/5.0
|
||||
- Code Quality: 4.5/5.0
|
||||
- Technical Impact: 4.0/5.0
|
||||
- Collaboration: 4.2/5.0
|
||||
- Growth & Learning: 3.8/5.0
|
||||
|
||||
Top Strengths:
|
||||
1. Test Coverage (5.0/5.0)
|
||||
2. Code Review Participation (4.8/5.0)
|
||||
3. Architecture Contribution (4.7/5.0)
|
||||
|
||||
Development Areas:
|
||||
1. Estimation Accuracy (3.2/5.0)
|
||||
2. Learning Activity (3.4/5.0)
|
||||
3. Technical Debt Contribution (3.5/5.0)
|
||||
|
||||
Trend: +0.3 from previous quarter
|
||||
```
|
||||
|
||||
### Sample Team Dashboard
|
||||
|
||||
```
|
||||
Team Success Metrics - Q2 2025
|
||||
Team: [Team Name]
|
||||
|
||||
Team Average Score: 3.9/5.0
|
||||
|
||||
Category Averages:
|
||||
- Delivery Performance: 3.8/5.0
|
||||
- Code Quality: 4.1/5.0
|
||||
- Technical Impact: 3.7/5.0
|
||||
- Collaboration: 4.0/5.0
|
||||
- Growth & Learning: 3.9/5.0
|
||||
|
||||
Team Strengths:
|
||||
1. Code Review Participation (4.6/5.0)
|
||||
2. Test Coverage (4.4/5.0)
|
||||
3. Knowledge Sharing (4.3/5.0)
|
||||
|
||||
Team Development Areas:
|
||||
1. Estimation Accuracy (3.3/5.0)
|
||||
2. Defect Density (3.4/5.0)
|
||||
3. Innovation (3.5/5.0)
|
||||
|
||||
Trend: +0.2 from previous quarter
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
*Last Updated: June 2025*
|
||||
```
|
||||
|
||||
Now, let me create a sprint status file to track the progress of Sprint 4:
|
||||
|
|
@ -0,0 +1,574 @@
|
|||
# Developer Template Guide
|
||||
**BMAD Method Documentation**
|
||||
|
||||
## Introduction
|
||||
|
||||
This Developer Template Guide provides a comprehensive collection of templates designed specifically for developers working within the BMAD Method framework. These templates streamline development workflows, ensure consistency, and promote best practices across projects.
|
||||
|
||||
## Template Categories
|
||||
|
||||
The developer templates are organized into six primary categories:
|
||||
|
||||
1. **Project Setup Templates** - For initializing new projects and components
|
||||
2. **Development Templates** - For coding standards and implementation patterns
|
||||
3. **Testing Templates** - For test planning and implementation
|
||||
4. **Documentation Templates** - For code and API documentation
|
||||
5. **Review Templates** - For code reviews and quality assurance
|
||||
6. **Handoff Templates** - For transitioning completed work
|
||||
|
||||
## Template Library
|
||||
|
||||
### Project Setup Templates
|
||||
|
||||
#### Component Initialization Template
|
||||
|
||||
```typescript
|
||||
/**
|
||||
* @component ComponentName
|
||||
* @description Brief description of the component's purpose
|
||||
* @author Developer Name
|
||||
* @created YYYY-MM-DD
|
||||
*
|
||||
* @props {PropType} propName - Description of the prop
|
||||
* @returns {JSX.Element} Component JSX
|
||||
*/
|
||||
|
||||
import React from 'react';
|
||||
import { PropType } from './types';
|
||||
|
||||
interface ComponentNameProps {
|
||||
propName: PropType;
|
||||
// Add additional props
|
||||
}
|
||||
|
||||
export const ComponentName: React.FC<ComponentNameProps> = ({
|
||||
propName,
|
||||
// Destructure additional props
|
||||
}) => {
|
||||
// Component logic
|
||||
|
||||
return (
|
||||
<div className="component-name">
|
||||
{/* Component JSX */}
|
||||
</div>
|
||||
);
|
||||
};
|
||||
|
||||
export default ComponentName;
|
||||
```
|
||||
|
||||
#### Project Structure Template
|
||||
|
||||
```
|
||||
project-name/
|
||||
├── src/
|
||||
│ ├── components/
|
||||
│ │ ├── common/
|
||||
│ │ │ └── [shared components]
|
||||
│ │ ├── features/
|
||||
│ │ │ └── [feature-specific components]
|
||||
│ │ └── layouts/
|
||||
│ │ └── [layout components]
|
||||
│ ├── hooks/
|
||||
│ │ └── [custom hooks]
|
||||
│ ├── utils/
|
||||
│ │ └── [utility functions]
|
||||
│ ├── services/
|
||||
│ │ └── [API services]
|
||||
│ ├── types/
|
||||
│ │ └── [TypeScript types/interfaces]
|
||||
│ ├── styles/
|
||||
│ │ └── [global styles]
|
||||
│ └── pages/
|
||||
│ └── [page components]
|
||||
├── public/
|
||||
│ └── [static assets]
|
||||
├── tests/
|
||||
│ └── [test files]
|
||||
└── [configuration files]
|
||||
```
|
||||
|
||||
### Development Templates
|
||||
|
||||
#### Component Implementation Template
|
||||
|
||||
```typescript
|
||||
/**
|
||||
* @component FeatureComponent
|
||||
* @description Implements the [feature name] functionality
|
||||
*/
|
||||
|
||||
import React, { useState, useEffect } from 'react';
|
||||
import { useService } from '@/hooks/useService';
|
||||
import { ComponentProps } from '@/types';
|
||||
|
||||
export const FeatureComponent: React.FC<ComponentProps> = (props) => {
|
||||
// State management
|
||||
const [data, setData] = useState<DataType>(initialState);
|
||||
|
||||
// Service hooks
|
||||
const { fetchData, isLoading, error } = useService();
|
||||
|
||||
// Effects
|
||||
useEffect(() => {
|
||||
// Effect logic
|
||||
const loadData = async () => {
|
||||
const result = await fetchData();
|
||||
setData(result);
|
||||
};
|
||||
|
||||
loadData();
|
||||
}, [fetchData]);
|
||||
|
||||
// Event handlers
|
||||
const handleAction = () => {
|
||||
// Handler logic
|
||||
};
|
||||
|
||||
// Conditional rendering
|
||||
if (isLoading) return <LoadingComponent />;
|
||||
if (error) return <ErrorComponent message={error.message} />;
|
||||
|
||||
// Main render
|
||||
return (
|
||||
<div className="feature-component">
|
||||
{/* Component content */}
|
||||
</div>
|
||||
);
|
||||
};
|
||||
```
|
||||
|
||||
#### Custom Hook Template
|
||||
|
||||
```typescript
|
||||
/**
|
||||
* @hook useFeature
|
||||
* @description Custom hook for [feature] functionality
|
||||
* @returns {Object} Hook methods and state
|
||||
*/
|
||||
|
||||
import { useState, useEffect, useCallback } from 'react';
|
||||
|
||||
export function useFeature(initialValue) {
|
||||
// State
|
||||
const [state, setState] = useState(initialValue);
|
||||
const [isLoading, setIsLoading] = useState(false);
|
||||
const [error, setError] = useState(null);
|
||||
|
||||
// Methods
|
||||
const doSomething = useCallback(async () => {
|
||||
setIsLoading(true);
|
||||
setError(null);
|
||||
|
||||
try {
|
||||
// Implementation
|
||||
const result = await someAsyncOperation();
|
||||
setState(result);
|
||||
return result;
|
||||
} catch (err) {
|
||||
setError(err);
|
||||
return null;
|
||||
} finally {
|
||||
setIsLoading(false);
|
||||
}
|
||||
}, [/* dependencies */]);
|
||||
|
||||
// Effects
|
||||
useEffect(() => {
|
||||
// Effect implementation
|
||||
}, [/* dependencies */]);
|
||||
|
||||
// Return hook API
|
||||
return {
|
||||
state,
|
||||
isLoading,
|
||||
error,
|
||||
doSomething
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
### Testing Templates
|
||||
|
||||
#### Component Test Template
|
||||
|
||||
```typescript
|
||||
/**
|
||||
* @test ComponentName
|
||||
* @description Test suite for ComponentName component
|
||||
*/
|
||||
|
||||
import { render, screen, fireEvent } from '@testing-library/react';
|
||||
import userEvent from '@testing-library/user-event';
|
||||
import { ComponentName } from './ComponentName';
|
||||
|
||||
describe('ComponentName', () => {
|
||||
// Test setup
|
||||
const defaultProps = {
|
||||
propName: 'test value'
|
||||
};
|
||||
|
||||
beforeEach(() => {
|
||||
// Setup before each test
|
||||
});
|
||||
|
||||
afterEach(() => {
|
||||
// Cleanup after each test
|
||||
});
|
||||
|
||||
// Test cases
|
||||
test('renders correctly with default props', () => {
|
||||
render(<ComponentName {...defaultProps} />);
|
||||
expect(screen.getByText('expected text')).toBeInTheDocument();
|
||||
});
|
||||
|
||||
test('handles user interaction correctly', async () => {
|
||||
render(<ComponentName {...defaultProps} />);
|
||||
|
||||
// Simulate user interaction
|
||||
await userEvent.click(screen.getByRole('button'));
|
||||
|
||||
// Assert expected outcome
|
||||
expect(screen.getByText('new state')).toBeInTheDocument();
|
||||
});
|
||||
|
||||
test('calls callback when action performed', () => {
|
||||
const mockCallback = jest.fn();
|
||||
render(<ComponentName {...defaultProps} onAction={mockCallback} />);
|
||||
|
||||
fireEvent.click(screen.getByRole('button'));
|
||||
|
||||
expect(mockCallback).toHaveBeenCalledTimes(1);
|
||||
expect(mockCallback).toHaveBeenCalledWith(expect.any(Object));
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
#### Integration Test Template
|
||||
|
||||
```typescript
|
||||
/**
|
||||
* @test FeatureIntegration
|
||||
* @description Integration tests for the Feature functionality
|
||||
*/
|
||||
|
||||
import { render, screen, waitFor } from '@testing-library/react';
|
||||
import userEvent from '@testing-library/user-event';
|
||||
import { FeatureContainer } from './FeatureContainer';
|
||||
import { ServiceProvider } from '@/services';
|
||||
import { mockService } from '@/tests/mocks';
|
||||
|
||||
describe('Feature Integration', () => {
|
||||
// Setup test environment
|
||||
beforeEach(() => {
|
||||
// Setup mocks and providers
|
||||
});
|
||||
|
||||
test('completes end-to-end workflow successfully', async () => {
|
||||
// Arrange
|
||||
mockService.getData.mockResolvedValueOnce({ id: 1, name: 'Test' });
|
||||
|
||||
// Act
|
||||
render(
|
||||
<ServiceProvider value={mockService}>
|
||||
<FeatureContainer />
|
||||
</ServiceProvider>
|
||||
);
|
||||
|
||||
// Initial state assertions
|
||||
expect(screen.getByText('Loading...')).toBeInTheDocument();
|
||||
|
||||
// Wait for data load
|
||||
await waitFor(() => {
|
||||
expect(screen.queryByText('Loading...')).not.toBeInTheDocument();
|
||||
});
|
||||
|
||||
// Interact with the feature
|
||||
await userEvent.click(screen.getByText('Perform Action'));
|
||||
|
||||
// Assert final state
|
||||
expect(screen.getByText('Action Complete')).toBeInTheDocument();
|
||||
expect(mockService.updateData).toHaveBeenCalledWith({ id: 1, status: 'updated' });
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
### Documentation Templates
|
||||
|
||||
#### API Documentation Template
|
||||
|
||||
```typescript
|
||||
/**
|
||||
* @api ServiceName
|
||||
* @description Service for handling [functionality] operations
|
||||
*/
|
||||
|
||||
/**
|
||||
* Fetches data from the API
|
||||
*
|
||||
* @async
|
||||
* @function fetchData
|
||||
* @param {string} id - The identifier for the requested resource
|
||||
* @param {Object} options - Additional options for the request
|
||||
* @param {boolean} options.includeDetails - Whether to include detailed information
|
||||
* @returns {Promise<DataType>} The fetched data
|
||||
* @throws {Error} When the network request fails
|
||||
* @example
|
||||
* // Basic usage
|
||||
* const data = await fetchData('user-123');
|
||||
*
|
||||
* // With options
|
||||
* const detailedData = await fetchData('user-123', { includeDetails: true });
|
||||
*/
|
||||
export async function fetchData(id, options = {}) {
|
||||
// Implementation
|
||||
}
|
||||
```
|
||||
|
||||
#### Component Documentation Template
|
||||
|
||||
```markdown
|
||||
# ComponentName
|
||||
|
||||
## Overview
|
||||
Brief description of the component's purpose and functionality.
|
||||
|
||||
## Props
|
||||
|
||||
| Name | Type | Default | Required | Description |
|
||||
|------|------|---------|----------|-------------|
|
||||
| prop1 | string | - | Yes | Description of prop1 |
|
||||
| prop2 | number | 0 | No | Description of prop2 |
|
||||
| prop3 | () => void | - | No | Callback when action occurs |
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Basic Usage
|
||||
```jsx
|
||||
import { ComponentName } from '@/components';
|
||||
|
||||
function MyComponent() {
|
||||
return <ComponentName prop1="value" />;
|
||||
}
|
||||
```
|
||||
|
||||
### Advanced Usage
|
||||
```jsx
|
||||
import { ComponentName } from '@/components';
|
||||
|
||||
function MyComponent() {
|
||||
const handleAction = () => {
|
||||
console.log('Action triggered');
|
||||
};
|
||||
|
||||
return (
|
||||
<ComponentName
|
||||
prop1="value"
|
||||
prop2={42}
|
||||
prop3={handleAction}
|
||||
/>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## Behavior
|
||||
|
||||
Describe the component's behavior, including:
|
||||
- State management
|
||||
- Side effects
|
||||
- User interactions
|
||||
- Error handling
|
||||
|
||||
## Accessibility
|
||||
|
||||
Accessibility considerations and implementations:
|
||||
- Keyboard navigation
|
||||
- Screen reader support
|
||||
- ARIA attributes
|
||||
- Focus management
|
||||
```
|
||||
|
||||
### Review Templates
|
||||
|
||||
#### Code Review Template
|
||||
|
||||
```markdown
|
||||
# Code Review: [PR/Component Name]
|
||||
|
||||
## General Assessment
|
||||
- [ ] Code follows project style guidelines
|
||||
- [ ] Component/function has a single responsibility
|
||||
- [ ] Logic is clear and maintainable
|
||||
- [ ] Error handling is appropriate
|
||||
- [ ] Performance considerations addressed
|
||||
|
||||
## Specific Feedback
|
||||
|
||||
### Strengths
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
### Areas for Improvement
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
### Questions
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Testing Assessment
|
||||
- [ ] Unit tests cover core functionality
|
||||
- [ ] Edge cases are tested
|
||||
- [ ] Mocks are used appropriately
|
||||
- [ ] Test descriptions are clear
|
||||
|
||||
## Documentation Assessment
|
||||
- [ ] Code is well-commented
|
||||
- [ ] API documentation is complete
|
||||
- [ ] Usage examples provided
|
||||
- [ ] Complex logic is explained
|
||||
|
||||
## Final Recommendation
|
||||
- [ ] Approve
|
||||
- [ ] Approve with minor changes
|
||||
- [ ] Request changes
|
||||
|
||||
## Additional Notes
|
||||
```
|
||||
|
||||
#### Performance Review Template
|
||||
|
||||
```markdown
|
||||
# Performance Review: [Component/Feature Name]
|
||||
|
||||
## Rendering Performance
|
||||
- Initial render time: [ms]
|
||||
- Re-render time: [ms]
|
||||
- Memory usage: [MB]
|
||||
|
||||
## Network Performance
|
||||
- Bundle size impact: [KB]
|
||||
- API call efficiency: [description]
|
||||
- Caching strategy: [description]
|
||||
|
||||
## Optimization Opportunities
|
||||
- [ ] Memoization of expensive calculations
|
||||
- [ ] Lazy loading of components
|
||||
- [ ] Code splitting
|
||||
- [ ] Resource preloading
|
||||
- [ ] Virtualization for large lists
|
||||
|
||||
## Profiling Results
|
||||
[Include screenshots or data from performance profiling tools]
|
||||
|
||||
## Recommendations
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
## Implementation Priority
|
||||
- [ ] Critical (blocking issue)
|
||||
- [ ] High (significant impact)
|
||||
- [ ] Medium (noticeable improvement)
|
||||
- [ ] Low (minor optimization)
|
||||
```
|
||||
|
||||
### Handoff Templates
|
||||
|
||||
#### Implementation Handoff Template
|
||||
|
||||
```markdown
|
||||
# Implementation Handoff: [Feature Name]
|
||||
|
||||
## Feature Overview
|
||||
Brief description of the implemented feature.
|
||||
|
||||
## Implementation Details
|
||||
- **Files Modified**:
|
||||
- `path/to/file1.tsx`: Description of changes
|
||||
- `path/to/file2.tsx`: Description of changes
|
||||
|
||||
- **New Components**:
|
||||
- `ComponentName`: Purpose and usage
|
||||
|
||||
- **Services/Hooks**:
|
||||
- `serviceName`: Purpose and API
|
||||
|
||||
- **State Management**:
|
||||
- Description of state changes and data flow
|
||||
|
||||
## Testing
|
||||
- **Test Coverage**: XX%
|
||||
- **Test Files**:
|
||||
- `path/to/test1.test.tsx`: What it tests
|
||||
- `path/to/test2.test.tsx`: What it tests
|
||||
|
||||
- **Manual Testing Scenarios**:
|
||||
1. Step-by-step scenario 1
|
||||
2. Step-by-step scenario 2
|
||||
|
||||
## Known Limitations
|
||||
- List any known issues or limitations
|
||||
- Include planned future improvements
|
||||
|
||||
## Dependencies
|
||||
- List of external dependencies and versions
|
||||
- Any specific configuration requirements
|
||||
|
||||
## Deployment Notes
|
||||
- Special deployment considerations
|
||||
- Feature flags or environment variables
|
||||
|
||||
## Documentation
|
||||
- Links to relevant documentation
|
||||
- API references
|
||||
```
|
||||
|
||||
## Template Selection Matrix
|
||||
|
||||
Use this matrix to determine which templates to use based on your current development phase:
|
||||
|
||||
| Development Phase | Recommended Templates |
|
||||
|-------------------|------------------------|
|
||||
| Project Initialization | Project Structure Template, Component Initialization Template |
|
||||
| Feature Development | Component Implementation Template, Custom Hook Template, API Documentation Template |
|
||||
| Testing | Component Test Template, Integration Test Template |
|
||||
| Code Review | Code Review Template, Performance Review Template |
|
||||
| Documentation | API Documentation Template, Component Documentation Template |
|
||||
| Handoff | Implementation Handoff Template |
|
||||
|
||||
## Template Customization Guidelines
|
||||
|
||||
These templates are designed to be customized for your specific project needs:
|
||||
|
||||
1. **Maintain Core Structure**: Keep the fundamental structure intact to ensure consistency
|
||||
2. **Extend as Needed**: Add project-specific sections or fields as required
|
||||
3. **Remove Irrelevant Sections**: Not all sections will apply to every component or feature
|
||||
4. **Update Standards**: As project standards evolve, update templates accordingly
|
||||
5. **Version Control**: Track template changes in version control
|
||||
|
||||
## Template Maintenance
|
||||
|
||||
The Developer Template Guide should be maintained as a living document:
|
||||
|
||||
1. **Regular Reviews**: Review templates quarterly to ensure they remain relevant
|
||||
2. **Feedback Collection**: Gather developer feedback on template usability
|
||||
3. **Update Process**: Follow the standard documentation update process for template changes
|
||||
4. **Versioning**: Maintain version history for templates
|
||||
5. **Notification**: Notify the development team of significant template changes
|
||||
|
||||
## Integration with Development Workflow
|
||||
|
||||
These templates integrate with the BMAD Method development workflow:
|
||||
|
||||
1. **IDE Integration**: Templates can be added as snippets in your IDE
|
||||
2. **CI/CD Integration**: Templates can be used in automated checks
|
||||
3. **Code Generation**: Templates can be used with code generation tools
|
||||
4. **Documentation Generation**: API documentation templates can feed into automated documentation systems
|
||||
|
||||
---
|
||||
|
||||
*Last Updated: June 2025*
|
||||
|
|
@ -0,0 +1,353 @@
|
|||
# Developer Workflow Mapping
|
||||
**BMAD Method Documentation**
|
||||
|
||||
## Introduction
|
||||
|
||||
This Developer Workflow Mapping document outlines the structured workflows for developers working within the BMAD Method framework. These workflows are designed to maximize productivity, ensure quality, and facilitate collaboration with other roles in the development process.
|
||||
|
||||
## Workflow Architecture
|
||||
|
||||
The developer workflow in the BMAD Method is organized into three primary modes, each with its own specific workflow:
|
||||
|
||||
1. **Implementation Mode** - For building features and components
|
||||
2. **Collaboration Mode** - For working with other roles and personas
|
||||
3. **Optimization Mode** - For improving existing code and systems
|
||||
|
||||
Each mode has defined entry points, processes, and exit criteria that guide developers through their work.
|
||||
|
||||
## Workflow Diagram Overview
|
||||
|
||||
```mermaid title="Developer Workflow Overview" type="diagram"
|
||||
flowchart TD
|
||||
Start([Developer Task Assignment]) --> ModeSelect{Select Mode}
|
||||
ModeSelect -->|Implementation| Implementation
|
||||
ModeSelect -->|Collaboration| Collaboration
|
||||
ModeSelect -->|Optimization| Optimization
|
||||
|
||||
Implementation --> ImplementationWorkflow[Implementation Workflow]
|
||||
Collaboration --> CollaborationWorkflow[Collaboration Workflow]
|
||||
Optimization --> OptimizationWorkflow[Optimization Workflow]
|
||||
|
||||
ImplementationWorkflow --> QualityGate{Meets\nQuality\nStandards?}
|
||||
CollaborationWorkflow --> QualityGate
|
||||
OptimizationWorkflow --> QualityGate
|
||||
|
||||
QualityGate -->|Yes| Delivery([Delivery])
|
||||
QualityGate -->|No| Refinement[Refinement]
|
||||
Refinement --> QualityGate
|
||||
```
|
||||
|
||||
## Implementation Mode Workflow
|
||||
|
||||
The Implementation Mode workflow guides developers through the process of building new features and components.
|
||||
|
||||
### Entry Points
|
||||
|
||||
- Feature assignment from Product Owner
|
||||
- Component specification from UX/UI Architect
|
||||
- Technical task from Architect
|
||||
- Bug fix assignment
|
||||
|
||||
### Implementation Workflow
|
||||
|
||||
```mermaid title="Implementation Workflow" type="diagram"
|
||||
flowchart TD
|
||||
Start([Implementation Task]) --> Requirements[Review Requirements]
|
||||
Requirements --> Design[Review Design Specifications]
|
||||
Design --> Architecture[Understand Architecture Context]
|
||||
Architecture --> Plan[Create Implementation Plan]
|
||||
Plan --> Setup[Set Up Development Environment]
|
||||
Setup --> Implement[Implement Feature/Component]
|
||||
Implement --> UnitTest[Write Unit Tests]
|
||||
UnitTest --> IntegrationTest[Write Integration Tests]
|
||||
IntegrationTest --> Documentation[Create/Update Documentation]
|
||||
Documentation --> Review[Self-Review]
|
||||
Review --> PeerReview[Peer Review]
|
||||
PeerReview --> Refinement[Address Feedback]
|
||||
Refinement --> QA[Quality Assurance]
|
||||
QA --> Delivery([Delivery])
|
||||
```
|
||||
|
||||
### Implementation Phases
|
||||
|
||||
#### 1. Preparation Phase
|
||||
- **Review Requirements**: Thoroughly understand the requirements and acceptance criteria
|
||||
- **Review Design Specifications**: Analyze UI/UX designs and interaction patterns
|
||||
- **Understand Architecture Context**: Review system architecture and integration points
|
||||
- **Create Implementation Plan**: Break down the work into manageable tasks
|
||||
|
||||
#### 2. Development Phase
|
||||
- **Set Up Development Environment**: Configure necessary tools and dependencies
|
||||
- **Implement Feature/Component**: Write code following quality standards
|
||||
- **Write Unit Tests**: Create comprehensive unit tests
|
||||
- **Write Integration Tests**: Ensure proper integration with other components
|
||||
|
||||
#### 3. Finalization Phase
|
||||
- **Create/Update Documentation**: Document code, APIs, and usage examples
|
||||
- **Self-Review**: Perform quality self-assessment
|
||||
- **Peer Review**: Submit for peer review and address feedback
|
||||
- **Quality Assurance**: Verify all quality standards are met
|
||||
|
||||
### Exit Criteria
|
||||
- All acceptance criteria met
|
||||
- Code passes all automated checks
|
||||
- Tests achieve required coverage
|
||||
- Documentation is complete
|
||||
- Peer review approval obtained
|
||||
|
||||
## Collaboration Mode Workflow
|
||||
|
||||
The Collaboration Mode workflow guides developers through effective collaboration with other roles in the BMAD Method.
|
||||
|
||||
### Entry Points
|
||||
|
||||
- Design handoff from UX/UI Architect
|
||||
- Architecture review with Architect
|
||||
- Requirements clarification with Product Owner
|
||||
- Sprint planning with Scrum Master
|
||||
- Pair programming session
|
||||
|
||||
### Collaboration Workflow
|
||||
|
||||
```mermaid title="Collaboration Workflow" type="diagram"
|
||||
flowchart TD
|
||||
Start([Collaboration Request]) --> Preparation[Prepare for Collaboration]
|
||||
Preparation --> RoleIdentify{Identify\nCollaboration\nRole}
|
||||
|
||||
RoleIdentify -->|UX/UI Architect| DesignReview[Design Review]
|
||||
RoleIdentify -->|Architect| ArchitectureReview[Architecture Review]
|
||||
RoleIdentify -->|Product Owner| RequirementsClarification[Requirements Clarification]
|
||||
RoleIdentify -->|Scrum Master| ProcessAlignment[Process Alignment]
|
||||
RoleIdentify -->|Other Developers| PairProgramming[Pair Programming]
|
||||
|
||||
DesignReview --> FeedbackCollection[Collect Feedback]
|
||||
ArchitectureReview --> FeedbackCollection
|
||||
RequirementsClarification --> FeedbackCollection
|
||||
ProcessAlignment --> FeedbackCollection
|
||||
PairProgramming --> FeedbackCollection
|
||||
|
||||
FeedbackCollection --> ActionItems[Create Action Items]
|
||||
ActionItems --> Implementation[Implement Changes]
|
||||
Implementation --> Validation[Validate with Collaborator]
|
||||
Validation --> Documentation[Document Outcomes]
|
||||
Documentation --> Completion([Collaboration Complete])
|
||||
```
|
||||
|
||||
### Collaboration Phases
|
||||
|
||||
#### 1. Preparation Phase
|
||||
- **Prepare for Collaboration**: Review relevant materials and prepare questions
|
||||
- **Identify Collaboration Role**: Determine the specific role you're collaborating with
|
||||
|
||||
#### 2. Role-Specific Collaboration
|
||||
- **Design Review**: Review designs and provide implementation feasibility feedback
|
||||
- **Architecture Review**: Discuss architectural approaches and technical constraints
|
||||
- **Requirements Clarification**: Clarify requirements and acceptance criteria
|
||||
- **Process Alignment**: Align on process expectations and timelines
|
||||
- **Pair Programming**: Collaborate directly on implementation
|
||||
|
||||
#### 3. Integration Phase
|
||||
- **Collect Feedback**: Document all feedback and decisions
|
||||
- **Create Action Items**: Convert feedback into actionable tasks
|
||||
- **Implement Changes**: Make necessary changes based on collaboration
|
||||
- **Validate with Collaborator**: Confirm changes meet expectations
|
||||
- **Document Outcomes**: Record decisions and outcomes
|
||||
|
||||
### Exit Criteria
|
||||
- Collaboration objectives achieved
|
||||
- Action items completed
|
||||
- Changes validated by collaborator
|
||||
- Outcomes documented
|
||||
|
||||
## Optimization Mode Workflow
|
||||
|
||||
The Optimization Mode workflow guides developers through the process of improving existing code and systems.
|
||||
|
||||
### Entry Points
|
||||
|
||||
- Performance optimization task
|
||||
- Technical debt reduction initiative
|
||||
- Refactoring requirement
|
||||
- Accessibility improvement
|
||||
- Security enhancement
|
||||
|
||||
### Optimization Workflow
|
||||
|
||||
```mermaid title="Optimization Workflow" type="diagram"
|
||||
flowchart TD
|
||||
Start([Optimization Task]) --> Analysis[Analyze Current State]
|
||||
Analysis --> Measurement[Establish Baseline Metrics]
|
||||
Measurement --> Goals[Define Optimization Goals]
|
||||
Goals --> Plan[Create Optimization Plan]
|
||||
Plan --> Implementation[Implement Optimizations]
|
||||
Implementation --> Testing[Test Optimizations]
|
||||
Testing --> Measurement2[Measure Improvements]
|
||||
Measurement2 --> Evaluation{Goals\nAchieved?}
|
||||
Evaluation -->|Yes| Documentation[Document Optimizations]
|
||||
Evaluation -->|No| Refinement[Refine Approach]
|
||||
Refinement --> Implementation
|
||||
Documentation --> KnowledgeSharing[Share Knowledge]
|
||||
KnowledgeSharing --> Completion([Optimization Complete])
|
||||
```
|
||||
|
||||
### Optimization Phases
|
||||
|
||||
#### 1. Assessment Phase
|
||||
- **Analyze Current State**: Understand the current implementation and issues
|
||||
- **Establish Baseline Metrics**: Measure current performance or quality metrics
|
||||
- **Define Optimization Goals**: Set clear, measurable optimization targets
|
||||
- **Create Optimization Plan**: Plan the approach and techniques to use
|
||||
|
||||
#### 2. Implementation Phase
|
||||
- **Implement Optimizations**: Apply optimization techniques
|
||||
- **Test Optimizations**: Verify functionality is preserved
|
||||
- **Measure Improvements**: Quantify the impact of optimizations
|
||||
- **Evaluate Goals**: Determine if optimization goals were met
|
||||
|
||||
#### 3. Knowledge Phase
|
||||
- **Document Optimizations**: Record techniques used and results achieved
|
||||
- **Share Knowledge**: Share learnings with the team
|
||||
- **Refine Approach**: Iterate if goals weren't met
|
||||
|
||||
### Exit Criteria
|
||||
- Optimization goals achieved
|
||||
- Functionality preserved
|
||||
- Performance/quality improvements measured
|
||||
- Optimizations documented
|
||||
- Knowledge shared with team
|
||||
|
||||
## Mode Transitions
|
||||
|
||||
Developers may need to transition between modes during their work. The following diagram illustrates the common transition patterns:
|
||||
|
||||
```mermaid title="Mode Transition Framework" type="diagram"
|
||||
flowchart TD
|
||||
Implementation --> |"Requirement Clarification"| Collaboration
|
||||
Implementation --> |"Performance Issue"| Optimization
|
||||
Collaboration --> |"Continue Implementation"| Implementation
|
||||
Collaboration --> |"Identify Optimization Need"| Optimization
|
||||
Optimization --> |"Implementation Required"| Implementation
|
||||
Optimization --> |"Stakeholder Input Needed"| Collaboration
|
||||
```
|
||||
|
||||
### Common Transition Triggers
|
||||
|
||||
- **Implementation → Collaboration**: Need for requirement clarification, design feedback, or technical guidance
|
||||
- **Implementation → Optimization**: Discovery of performance issues or technical debt
|
||||
- **Collaboration → Implementation**: Continuation of implementation after collaboration
|
||||
- **Collaboration → Optimization**: Identification of optimization opportunities during collaboration
|
||||
- **Optimization → Implementation**: Need for new implementation to support optimization
|
||||
- **Optimization → Collaboration**: Need for stakeholder input on optimization approach
|
||||
|
||||
## Integration with Other Personas
|
||||
|
||||
The developer workflow integrates with other BMAD Method personas at specific points:
|
||||
|
||||
### UX/UI Architect Integration
|
||||
|
||||
- **Design Handoff**: Receive component specifications and design assets
|
||||
- **Implementation Feedback**: Provide feedback on implementation feasibility
|
||||
- **Design Clarification**: Request clarification on design details
|
||||
- **Component Showcase**: Demonstrate implemented components
|
||||
|
||||
### Architect Integration
|
||||
|
||||
- **Architecture Guidance**: Receive technical architecture guidance
|
||||
- **Technical Decision Making**: Collaborate on technical decisions
|
||||
- **Code Review**: Receive architecture-focused code reviews
|
||||
- **Technical Debt Assessment**: Identify and prioritize technical debt
|
||||
|
||||
### Product Owner Integration
|
||||
|
||||
- **Requirement Clarification**: Clarify feature requirements
|
||||
- **Acceptance Criteria Validation**: Confirm understanding of acceptance criteria
|
||||
- **Feature Demonstration**: Showcase implemented features
|
||||
- **Scope Negotiation**: Discuss technical constraints and scope adjustments
|
||||
|
||||
### Scrum Master Integration
|
||||
|
||||
- **Sprint Planning**: Participate in sprint planning and estimation
|
||||
- **Impediment Removal**: Report and resolve development impediments
|
||||
- **Progress Reporting**: Report on development progress
|
||||
- **Process Improvement**: Provide feedback on development process
|
||||
|
||||
## Performance Metrics
|
||||
|
||||
Developer workflow performance is measured using the following metrics:
|
||||
|
||||
### Productivity Metrics
|
||||
|
||||
- **Cycle Time**: Time from task start to completion
|
||||
- **Lead Time**: Time from task creation to completion
|
||||
- **Story Points Velocity**: Story points completed per sprint
|
||||
- **Code Throughput**: Lines of code or commits per time period
|
||||
|
||||
### Quality Metrics
|
||||
|
||||
- **Defect Density**: Defects per unit of code
|
||||
- **Test Coverage**: Percentage of code covered by tests
|
||||
- **Technical Debt Ratio**: Ratio of technical debt to clean code
|
||||
- **Code Quality Score**: Composite score from static analysis tools
|
||||
|
||||
### Collaboration Metrics
|
||||
|
||||
- **Review Efficiency**: Time from review request to completion
|
||||
- **Feedback Incorporation Rate**: Percentage of feedback incorporated
|
||||
- **Cross-functional Collaboration**: Number of collaborative sessions
|
||||
- **Knowledge Sharing**: Number of knowledge sharing activities
|
||||
|
||||
## Continuous Improvement Process
|
||||
|
||||
The developer workflow is continuously improved through:
|
||||
|
||||
1. **Retrospective Analysis**: Regular review of workflow effectiveness
|
||||
2. **Metric Tracking**: Monitoring of performance metrics over time
|
||||
3. **Feedback Collection**: Gathering feedback from developers and other roles
|
||||
4. **Process Experimentation**: Controlled experiments with workflow variations
|
||||
5. **Best Practice Integration**: Incorporation of industry best practices
|
||||
|
||||
## Appendix: Workflow Checklists
|
||||
|
||||
### Implementation Mode Checklist
|
||||
|
||||
- [ ] Requirements fully understood
|
||||
- [ ] Design specifications reviewed
|
||||
- [ ] Architecture context understood
|
||||
- [ ] Implementation plan created
|
||||
- [ ] Development environment set up
|
||||
- [ ] Code implemented following standards
|
||||
- [ ] Unit tests written and passing
|
||||
- [ ] Integration tests written and passing
|
||||
- [ ] Documentation created/updated
|
||||
- [ ] Self-review completed
|
||||
- [ ] Peer review completed
|
||||
- [ ] Quality standards met
|
||||
|
||||
### Collaboration Mode Checklist
|
||||
|
||||
- [ ] Collaboration objectives defined
|
||||
- [ ] Relevant materials reviewed
|
||||
- [ ] Questions prepared
|
||||
- [ ] Collaboration session conducted
|
||||
- [ ] Feedback collected and documented
|
||||
- [ ] Action items created
|
||||
- [ ] Changes implemented
|
||||
- [ ] Changes validated with collaborator
|
||||
- [ ] Outcomes documented
|
||||
|
||||
### Optimization Mode Checklist
|
||||
|
||||
- [ ] Current state analyzed
|
||||
- [ ] Baseline metrics established
|
||||
- [ ] Optimization goals defined
|
||||
- [ ] Optimization plan created
|
||||
- [ ] Optimizations implemented
|
||||
- [ ] Functionality verified
|
||||
- [ ] Improvements measured
|
||||
- [ ] Goals evaluated
|
||||
- [ ] Optimizations documented
|
||||
- [ ] Knowledge shared with team
|
||||
|
||||
---
|
||||
|
||||
*Last Updated: June 2025*
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
# BMAD Documentation Standards
|
||||
|
||||
## Overview
|
||||
|
||||
Welcome to the BMAD Documentation Standards repository. This collection of documents establishes the guidelines, processes, and tools used to maintain high-quality documentation across the BMAD Method ecosystem.
|
||||
|
||||
## Key Documents
|
||||
|
||||
### [Style Guide](./style-guide.md)
|
||||
Comprehensive guidelines for writing consistent, clear, and professional documentation. Covers formatting, voice, terminology, and structure.
|
||||
|
||||
### [Automated Checks](./automated-checks.md)
|
||||
Details on the automated tools and processes used to validate documentation quality, including linting, spell checking, link validation, and accessibility checks.
|
||||
|
||||
### [Contribution Guidelines](./contribution-guidelines.md)
|
||||
Instructions for contributing to BMAD documentation, including the process for submitting changes, requirements for new content, and best practices.
|
||||
|
||||
### [Review Process](./review-process.md)
|
||||
Outlines the multi-stage review workflow for documentation, including technical review, editorial review, and final approval processes.
|
||||
|
||||
## Getting Started
|
||||
|
||||
If you're new to BMAD documentation standards:
|
||||
|
||||
1. Start by reading the [Style Guide](./style-guide.md)
|
||||
2. Set up the [Automated Checks](./automated-checks.md) in your environment
|
||||
3. Review the [Contribution Guidelines](./contribution-guidelines.md) before making changes
|
||||
4. Understand the [Review Process](./review-process.md) your contributions will go through
|
||||
|
||||
## Implementation
|
||||
|
||||
These standards apply to all documentation across the BMAD Method ecosystem:
|
||||
|
||||
- Persona documentation
|
||||
- Setup guides
|
||||
- Quick-start guides
|
||||
- Technical references
|
||||
- API documentation
|
||||
- Examples and tutorials
|
||||
- Release notes
|
||||
|
||||
## Tools and Resources
|
||||
|
||||
### Documentation Templates
|
||||
- [Persona Documentation Template](../../templates/persona-documentation-template.md)
|
||||
- [Quick Start Guide Template](../../templates/quick-start-template.md)
|
||||
- [Integration Guide Template](../../templates/integration-guide-template.md)
|
||||
|
||||
### Automation Scripts
|
||||
- [Documentation Linting](../../scripts/lint-docs.js)
|
||||
- [Link Validator](../../scripts/validate-links.js)
|
||||
- [Accessibility Checker](../../scripts/check-a11y.js)
|
||||
|
||||
### Visual Assets
|
||||
- [Documentation Icons](../../assets/icons/)
|
||||
- [Diagram Templates](../../assets/diagrams/)
|
||||
- [Screenshot Guidelines](../../assets/screenshots/README.md)
|
||||
|
||||
## Versioning and Updates
|
||||
|
||||
These standards follow semantic versioning:
|
||||
|
||||
- **MAJOR**: Significant changes requiring updates to existing documentation
|
||||
- **MINOR**: New features or guidelines added in a backward-compatible manner
|
||||
- **PATCH**: Clarifications or minor corrections
|
||||
|
||||
The current version is **1.0.0**.
|
||||
|
||||
## Feedback and Improvements
|
||||
|
||||
We welcome feedback on these documentation standards:
|
||||
|
||||
- Open an issue in the [BMAD Documentation repository](https://github.com/bmad-method/documentation/issues)
|
||||
- Suggest improvements via pull requests
|
||||
- Discuss in the #documentation channel on Slack
|
||||
|
||||
## Acknowledgments
|
||||
|
||||
These documentation standards were developed with inspiration from:
|
||||
|
||||
- Google Developer Documentation Style Guide
|
||||
- Microsoft Writing Style Guide
|
||||
- The Diátaxis Framework
|
||||
- Write the Docs community best practices
|
||||
|
||||
---
|
||||
|
||||
*These documentation standards are maintained by the BMAD Documentation Team. Last updated: Current Date.*
|
||||
|
|
@ -0,0 +1,205 @@
|
|||
# Automated Documentation Checks
|
||||
|
||||
## Overview
|
||||
|
||||
This document outlines the automated checks implemented to ensure all BMAD Method documentation meets our quality standards. These checks run automatically during the documentation review process and must pass before documentation can be published.
|
||||
|
||||
## Setup Instructions
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Node.js 16+
|
||||
- npm or yarn
|
||||
- Access to the BMAD documentation repository
|
||||
|
||||
### Installation
|
||||
|
||||
```bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/bmad-method/documentation.git
|
||||
|
||||
# Install dependencies
|
||||
cd documentation
|
||||
npm install
|
||||
```
|
||||
|
||||
## Available Checks
|
||||
|
||||
### 1. Markdown Linting
|
||||
|
||||
We use `markdownlint` to enforce consistent markdown formatting.
|
||||
|
||||
```bash
|
||||
# Run markdown linting
|
||||
npm run lint:md
|
||||
```
|
||||
|
||||
#### Rules Enforced:
|
||||
|
||||
- MD001: Header levels should only increment by one level at a time
|
||||
- MD003: Header style (ATX-style headers)
|
||||
- MD004: Unordered list style (consistent markers)
|
||||
- MD007: Unordered list indentation
|
||||
- MD009: No trailing spaces
|
||||
- MD010: No hard tabs
|
||||
- MD011: No reversed link syntax
|
||||
- MD012: Multiple consecutive blank lines
|
||||
- MD013: Line length (flexible limit: 120 characters)
|
||||
- MD018: No space after hash on atx style header
|
||||
- MD019: Multiple spaces after hash on atx style header
|
||||
- MD022: Headers should be surrounded by blank lines
|
||||
- MD023: Headers must start at the beginning of the line
|
||||
- MD025: Single title/h1 per file
|
||||
- MD031: Fenced code blocks should be surrounded by blank lines
|
||||
- MD032: Lists should be surrounded by blank lines
|
||||
- MD034: No bare URLs
|
||||
- MD037: No spaces inside emphasis markers
|
||||
- MD038: No spaces inside code span elements
|
||||
- MD039: No spaces inside link text
|
||||
- MD040: Fenced code blocks should have a language specified
|
||||
- MD041: First line in file should be a top level header
|
||||
- MD047: Files should end with a single newline character
|
||||
|
||||
### 2. Spelling Check
|
||||
|
||||
We use `cspell` to check for spelling errors.
|
||||
|
||||
```bash
|
||||
# Run spell check
|
||||
npm run lint:spell
|
||||
```
|
||||
|
||||
#### Features:
|
||||
|
||||
- Custom dictionary for BMAD-specific terminology
|
||||
- Support for code snippets and technical terms
|
||||
- Ignores URLs and code blocks
|
||||
- Suggests corrections for misspelled words
|
||||
|
||||
### 3. Link Validation
|
||||
|
||||
We use a custom script to validate all links in the documentation.
|
||||
|
||||
```bash
|
||||
# Run link validation
|
||||
npm run lint:links
|
||||
```
|
||||
|
||||
#### Checks:
|
||||
|
||||
- Internal links point to valid files
|
||||
- External links are reachable (200 OK response)
|
||||
- No broken anchor links
|
||||
- No duplicate links
|
||||
- No empty links
|
||||
|
||||
### 4. Accessibility Checks
|
||||
|
||||
We use `a11y` to check for accessibility issues.
|
||||
|
||||
```bash
|
||||
# Run accessibility checks
|
||||
npm run lint:a11y
|
||||
```
|
||||
|
||||
#### Checks:
|
||||
|
||||
- Alt text for images
|
||||
- Proper heading structure
|
||||
- Sufficient color contrast
|
||||
- Proper use of ARIA attributes
|
||||
- Keyboard navigability
|
||||
|
||||
### 5. Style Guide Compliance
|
||||
|
||||
We use a custom script to check compliance with our style guide.
|
||||
|
||||
```bash
|
||||
# Run style guide compliance check
|
||||
npm run lint:style
|
||||
```
|
||||
|
||||
#### Checks:
|
||||
|
||||
- Proper use of voice and tone
|
||||
- Consistent terminology
|
||||
- Proper use of formatting
|
||||
- Adherence to file organization standards
|
||||
- Consistent use of persona terminology
|
||||
|
||||
## CI/CD Integration
|
||||
|
||||
These checks are integrated into our CI/CD pipeline and run automatically on pull requests.
|
||||
|
||||
```yaml
|
||||
# Example GitHub Actions workflow
|
||||
name: Documentation Checks
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
paths:
|
||||
- '**/*.md'
|
||||
- 'docs/**'
|
||||
|
||||
jobs:
|
||||
lint:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: '16'
|
||||
- run: npm install
|
||||
- run: npm run lint:md
|
||||
- run: npm run lint:spell
|
||||
- run: npm run lint:links
|
||||
- run: npm run lint:a11y
|
||||
- run: npm run lint:style
|
||||
```
|
||||
|
||||
## Pre-commit Hooks
|
||||
|
||||
You can set up pre-commit hooks to run these checks locally before committing:
|
||||
|
||||
```bash
|
||||
# Install husky
|
||||
npm install husky --save-dev
|
||||
|
||||
# Set up pre-commit hook
|
||||
npx husky add .husky/pre-commit "npm run lint:all"
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
1. **Markdown Linting Errors**
|
||||
- Run `npm run lint:md -- --fix` to automatically fix some issues
|
||||
- Consult the [markdownlint documentation](https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md) for specific rule explanations
|
||||
|
||||
2. **Spelling Errors**
|
||||
- Add custom terms to `.cspell.json`
|
||||
- Use `// cspell:ignore term` for inline exceptions
|
||||
|
||||
3. **Link Validation Errors**
|
||||
- Check for typos in URLs
|
||||
- Ensure internal links use relative paths
|
||||
- Verify external resources are available
|
||||
|
||||
4. **Accessibility Issues**
|
||||
- Add alt text to all images
|
||||
- Maintain proper heading hierarchy
|
||||
- Use sufficient color contrast
|
||||
|
||||
## Reporting Issues
|
||||
|
||||
If you encounter problems with the automated checks, please:
|
||||
|
||||
1. Create an issue in the [BMAD Documentation Issues](https://github.com/bmad-method/documentation/issues) repository
|
||||
2. Include the specific check that failed
|
||||
3. Provide the error message and context
|
||||
4. Suggest a potential solution if available
|
||||
|
||||
---
|
||||
|
||||
*This document is maintained by the BMAD Documentation Team. Last updated: Current Date.*
|
||||
|
|
@ -0,0 +1,175 @@
|
|||
# BMAD Documentation Contribution Guidelines
|
||||
|
||||
## Overview
|
||||
|
||||
This document outlines the process for contributing to the BMAD Method documentation. Following these guidelines ensures a smooth review process and maintains the high quality of our documentation.
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- GitHub account
|
||||
- Basic knowledge of Markdown
|
||||
- Familiarity with the BMAD Method
|
||||
- Understanding of the documentation structure
|
||||
|
||||
### Setting Up Your Environment
|
||||
|
||||
1. Fork the [BMAD Documentation repository](https://github.com/bmad-method/documentation)
|
||||
2. Clone your fork locally
|
||||
3. Install dependencies:
|
||||
```bash
|
||||
npm install
|
||||
```
|
||||
4. Set up pre-commit hooks:
|
||||
```bash
|
||||
npm run prepare
|
||||
```
|
||||
|
||||
## Contribution Process
|
||||
|
||||
### 1. Find or Create an Issue
|
||||
|
||||
- Check existing issues in the [issue tracker](https://github.com/bmad-method/documentation/issues)
|
||||
- If your contribution doesn't match an existing issue, create a new one
|
||||
- Wait for issue assignment or approval before starting work
|
||||
|
||||
### 2. Create a Branch
|
||||
|
||||
- Create a branch from `main` with a descriptive name:
|
||||
```bash
|
||||
git checkout -b doc/add-developer-guide
|
||||
```
|
||||
- Use prefixes to indicate the type of change:
|
||||
- `doc/` for documentation additions
|
||||
- `fix/` for documentation fixes
|
||||
- `update/` for documentation updates
|
||||
- `review/` for review changes
|
||||
|
||||
### 3. Make Your Changes
|
||||
|
||||
- Follow the [Style Guide](./style-guide.md)
|
||||
- Run automated checks locally:
|
||||
```bash
|
||||
npm run lint:all
|
||||
```
|
||||
- Test your changes by building the documentation locally:
|
||||
```bash
|
||||
npm run docs:build
|
||||
npm run docs:serve
|
||||
```
|
||||
|
||||
### 4. Commit Your Changes
|
||||
|
||||
- Use conventional commit messages:
|
||||
```
|
||||
docs(persona): add developer integration guide
|
||||
|
||||
- Add detailed setup instructions
|
||||
- Include code examples
|
||||
- Add troubleshooting section
|
||||
|
||||
Closes #123
|
||||
```
|
||||
- Keep commits focused and atomic
|
||||
- Reference issues in commit messages
|
||||
|
||||
### 5. Submit a Pull Request
|
||||
|
||||
- Push your branch to your fork
|
||||
- Create a pull request against the `main` branch
|
||||
- Fill out the pull request template completely
|
||||
- Request review from appropriate team members
|
||||
- Address review feedback promptly
|
||||
|
||||
### 6. Review Process
|
||||
|
||||
All contributions go through a review process:
|
||||
|
||||
1. **Automated Checks**: CI/CD pipeline runs linting, spelling, and link validation
|
||||
2. **Peer Review**: At least one team member reviews the content
|
||||
3. **Technical Review**: Subject matter experts verify technical accuracy
|
||||
4. **Final Approval**: Documentation maintainer approves and merges
|
||||
|
||||
## Documentation Types
|
||||
|
||||
### New Documentation
|
||||
|
||||
When creating new documentation:
|
||||
|
||||
1. Use the appropriate template from the `templates/` directory
|
||||
2. Follow the established directory structure
|
||||
3. Include all required sections
|
||||
4. Add entry to navigation if applicable
|
||||
5. Create examples where appropriate
|
||||
|
||||
### Updates to Existing Documentation
|
||||
|
||||
When updating existing documentation:
|
||||
|
||||
1. Maintain the existing structure and style
|
||||
2. Clearly mark deprecated content
|
||||
3. Update related documentation as needed
|
||||
4. Update the "Last Updated" date
|
||||
5. Add changelog entry if significant
|
||||
|
||||
### Translations
|
||||
|
||||
When contributing translations:
|
||||
|
||||
1. Create files in the appropriate language directory
|
||||
2. Maintain the same structure as the English version
|
||||
3. Include language code in filename (e.g., `quickstart.fr.md`)
|
||||
4. Update language selector in navigation
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Content Guidelines
|
||||
|
||||
- Write for an international audience
|
||||
- Use simple, clear language
|
||||
- Provide context and examples
|
||||
- Link to related documentation
|
||||
- Include troubleshooting sections
|
||||
- Consider the user's perspective and needs
|
||||
|
||||
### Technical Guidelines
|
||||
|
||||
- Test all code examples
|
||||
- Verify command outputs
|
||||
- Check compatibility across environments
|
||||
- Include version information
|
||||
- Provide alternative approaches where applicable
|
||||
|
||||
### Review Guidelines
|
||||
|
||||
- Be constructive and specific in feedback
|
||||
- Suggest improvements rather than just pointing out issues
|
||||
- Consider the author's intent
|
||||
- Focus on content quality and accuracy
|
||||
- Be timely in your reviews
|
||||
|
||||
## Recognition
|
||||
|
||||
Contributors are recognized in several ways:
|
||||
|
||||
- Listed in the [Contributors](../CONTRIBUTORS.md) file
|
||||
- Mentioned in release notes
|
||||
- Acknowledged in the documentation they contributed to
|
||||
|
||||
## Code of Conduct
|
||||
|
||||
All contributors must adhere to our [Code of Conduct](../CODE_OF_CONDUCT.md). We are committed to providing a welcoming and inclusive environment for all contributors.
|
||||
|
||||
## Questions and Support
|
||||
|
||||
If you have questions about contributing:
|
||||
|
||||
- Join our [Community Slack](https://bmad-method.slack.com)
|
||||
- Email the documentation team at docs@bmad-method.org
|
||||
- Ask in the #documentation channel on Slack
|
||||
- Check the [FAQ](../FAQ.md) for common questions
|
||||
|
||||
---
|
||||
|
||||
*These contribution guidelines are maintained by the BMAD Documentation Team. Last updated: Current Date.*
|
||||
|
|
@ -0,0 +1,217 @@
|
|||
# BMAD Documentation Review Process
|
||||
|
||||
## Overview
|
||||
|
||||
This document outlines the review process for all BMAD Method documentation. A thorough review process ensures our documentation is accurate, consistent, and valuable to users.
|
||||
|
||||
## Review Roles
|
||||
|
||||
### Author
|
||||
- Creates or updates documentation
|
||||
- Responds to feedback
|
||||
- Makes requested changes
|
||||
- Ensures documentation meets standards
|
||||
|
||||
### Technical Reviewer
|
||||
- Verifies technical accuracy
|
||||
- Tests procedures and examples
|
||||
- Ensures compatibility with current versions
|
||||
- Validates architectural decisions
|
||||
|
||||
### Documentation Reviewer
|
||||
- Checks style guide compliance
|
||||
- Reviews structure and organization
|
||||
- Ensures consistency with existing documentation
|
||||
- Verifies accessibility and readability
|
||||
|
||||
### Final Approver
|
||||
- Performs final quality check
|
||||
- Ensures all review feedback is addressed
|
||||
- Approves merging into main documentation
|
||||
- Publishes documentation updates
|
||||
|
||||
## Review Workflow
|
||||
|
||||
### 1. Pre-Review Preparation
|
||||
|
||||
**Author Responsibilities:**
|
||||
- Run automated checks (linting, spelling, links)
|
||||
- Self-review against style guide
|
||||
- Complete the pre-review checklist
|
||||
- Request review in the documentation system
|
||||
|
||||
**Pre-Review Checklist:**
|
||||
- [ ] Documentation follows the style guide
|
||||
- [ ] All automated checks pass
|
||||
- [ ] Code examples are tested and working
|
||||
- [ ] Images have alt text
|
||||
- [ ] Links are valid
|
||||
- [ ] No placeholder content remains
|
||||
- [ ] Proper headers and structure used
|
||||
- [ ] Spell check completed
|
||||
|
||||
### 2. Technical Review
|
||||
|
||||
**Technical Reviewer Responsibilities:**
|
||||
- Verify technical accuracy of all content
|
||||
- Test all procedures on a clean environment
|
||||
- Validate code examples and commands
|
||||
- Check compatibility with specified versions
|
||||
- Review architectural recommendations
|
||||
- Provide feedback within 3 business days
|
||||
|
||||
**Technical Review Checklist:**
|
||||
- [ ] All technical information is accurate
|
||||
- [ ] Procedures work as described
|
||||
- [ ] Code examples execute correctly
|
||||
- [ ] Technical terminology is used correctly
|
||||
- [ ] Security best practices are followed
|
||||
- [ ] Performance considerations are addressed
|
||||
- [ ] Edge cases are considered
|
||||
- [ ] Technical diagrams are accurate
|
||||
|
||||
### 3. Documentation Review
|
||||
|
||||
**Documentation Reviewer Responsibilities:**
|
||||
- Check compliance with style guide
|
||||
- Review structure and organization
|
||||
- Ensure consistency with existing documentation
|
||||
- Verify accessibility and readability
|
||||
- Check cross-references and related documentation
|
||||
- Provide feedback within 3 business days
|
||||
|
||||
**Documentation Review Checklist:**
|
||||
- [ ] Follows style guide conventions
|
||||
- [ ] Structure is logical and consistent
|
||||
- [ ] Language is clear and concise
|
||||
- [ ] Terminology is consistent
|
||||
- [ ] Headers and sections are appropriate
|
||||
- [ ] Formatting is consistent
|
||||
- [ ] Accessibility guidelines are followed
|
||||
- [ ] Cross-references are accurate
|
||||
|
||||
### 4. Revision
|
||||
|
||||
**Author Responsibilities:**
|
||||
- Address all feedback from reviewers
|
||||
- Track changes made in response to feedback
|
||||
- Request re-review if significant changes were made
|
||||
- Complete the revision checklist
|
||||
|
||||
**Revision Checklist:**
|
||||
- [ ] All technical review feedback addressed
|
||||
- [ ] All documentation review feedback addressed
|
||||
- [ ] Automated checks still pass after changes
|
||||
- [ ] No new issues introduced during revisions
|
||||
- [ ] Changes documented in revision history
|
||||
|
||||
### 5. Final Approval
|
||||
|
||||
**Final Approver Responsibilities:**
|
||||
- Verify all review feedback has been addressed
|
||||
- Perform final quality check
|
||||
- Ensure documentation meets all standards
|
||||
- Approve merging into main documentation
|
||||
- Update documentation version if applicable
|
||||
|
||||
**Final Approval Checklist:**
|
||||
- [ ] All review feedback addressed
|
||||
- [ ] Documentation meets quality standards
|
||||
- [ ] Version information updated if applicable
|
||||
- [ ] Release notes prepared if applicable
|
||||
- [ ] Documentation ready for publication
|
||||
|
||||
### 6. Publication
|
||||
|
||||
**Publication Process:**
|
||||
1. Merge approved documentation into main branch
|
||||
2. Run automated build process
|
||||
3. Deploy to documentation site
|
||||
4. Verify published documentation
|
||||
5. Announce update if significant
|
||||
|
||||
## Review Timeframes
|
||||
|
||||
- **Technical Review**: 3 business days
|
||||
- **Documentation Review**: 3 business days
|
||||
- **Revision**: Dependent on scope of changes
|
||||
- **Final Approval**: 2 business days
|
||||
- **Emergency Updates**: Expedited process available
|
||||
|
||||
## Review Tools
|
||||
|
||||
### GitHub Pull Request Reviews
|
||||
- Use GitHub PR review features
|
||||
- Add line-specific comments
|
||||
- Use suggestion feature for small changes
|
||||
- Link to relevant issues or documentation
|
||||
|
||||
### Documentation Review Template
|
||||
```markdown
|
||||
## Documentation Review
|
||||
|
||||
### Overall Assessment
|
||||
- [ ] Approved
|
||||
- [ ] Approved with changes
|
||||
- [ ] Needs revision
|
||||
|
||||
### Technical Accuracy
|
||||
[Comments on technical accuracy]
|
||||
|
||||
### Structure and Organization
|
||||
[Comments on structure and organization]
|
||||
|
||||
### Style and Consistency
|
||||
[Comments on style and consistency]
|
||||
|
||||
### Specific Feedback
|
||||
1. [Page/Section]: [Feedback]
|
||||
2. [Page/Section]: [Feedback]
|
||||
|
||||
### Additional Notes
|
||||
[Any other comments or suggestions]
|
||||
```
|
||||
|
||||
## Special Review Cases
|
||||
|
||||
### Major Documentation Updates
|
||||
- Requires review from multiple technical experts
|
||||
- May require user testing
|
||||
- Consider phased rollout
|
||||
- Create migration guide if applicable
|
||||
|
||||
### Emergency Documentation Updates
|
||||
- Expedited review process
|
||||
- Focus on critical accuracy
|
||||
- May bypass some review steps
|
||||
- Must be reviewed fully after publication
|
||||
|
||||
### Translation Reviews
|
||||
- Requires native speaker review
|
||||
- Technical reviewer must verify accuracy
|
||||
- Check for cultural appropriateness
|
||||
- Ensure consistent terminology across languages
|
||||
|
||||
## Continuous Improvement
|
||||
|
||||
The review process itself is subject to continuous improvement:
|
||||
|
||||
- Collect metrics on review efficiency
|
||||
- Gather feedback from authors and reviewers
|
||||
- Regularly update review checklists
|
||||
- Improve automation tools
|
||||
- Review and update this process quarterly
|
||||
|
||||
## Review Dispute Resolution
|
||||
|
||||
If disagreements arise during the review process:
|
||||
|
||||
1. Reviewers and author discuss directly
|
||||
2. If unresolved, documentation lead mediates
|
||||
3. Technical disagreements defer to subject matter experts
|
||||
4. Style disagreements defer to style guide maintainer
|
||||
5. Final decision rests with documentation lead
|
||||
|
||||
---
|
||||
|
||||
*This review process is maintained by the BMAD Documentation Team. Last updated: Current Date.*
|
||||
|
|
@ -0,0 +1,109 @@
|
|||
# BMAD Documentation Style Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This style guide establishes consistent standards for all BMAD Method documentation. Following these guidelines ensures our documentation is professional, accessible, and maintainable across all personas and use cases.
|
||||
|
||||
## Document Structure
|
||||
|
||||
### Headers and Sections
|
||||
|
||||
- Use ATX-style headers with a space after the hash marks (`#`)
|
||||
- Maintain proper header hierarchy (H1 > H2 > H3)
|
||||
- Include only one H1 (`#`) per document
|
||||
- Keep headers concise (3-7 words)
|
||||
- Use sentence case for headers
|
||||
|
||||
### Formatting
|
||||
|
||||
- **Bold** for emphasis and UI elements
|
||||
- *Italics* for introducing new terms
|
||||
- `Code formatting` for code snippets, commands, and file paths
|
||||
- > Blockquotes for important notes or quotes
|
||||
- Horizontal rules (`---`) to separate major sections
|
||||
|
||||
## Writing Style
|
||||
|
||||
### Voice and Tone
|
||||
|
||||
- Use active voice
|
||||
- Write in present tense
|
||||
- Be concise and direct
|
||||
- Use second person ("you") to address the reader
|
||||
- Maintain a professional, helpful tone
|
||||
|
||||
### Grammar and Mechanics
|
||||
|
||||
- Use Oxford commas
|
||||
- Spell out numbers one through nine, use numerals for 10+
|
||||
- Use sentence case for titles and headings
|
||||
- Avoid contractions in formal documentation
|
||||
- Maintain consistent terminology throughout
|
||||
|
||||
## Code Examples
|
||||
|
||||
- Include language identifier with code blocks
|
||||
- Keep examples concise and focused
|
||||
- Include comments for complex code
|
||||
- Use placeholder text consistently (e.g., `YOUR_API_KEY`)
|
||||
- Test all code examples before publishing
|
||||
|
||||
## Images and Media
|
||||
|
||||
- Include descriptive alt text for all images
|
||||
- Keep images under 1MB when possible
|
||||
- Use SVG format for diagrams and flowcharts
|
||||
- Include captions for complex visuals
|
||||
- Maintain consistent image dimensions within a document
|
||||
|
||||
## Links and References
|
||||
|
||||
- Use descriptive link text (avoid "click here")
|
||||
- Check all links before publishing
|
||||
- Use relative links for internal documentation
|
||||
- Include version numbers when linking to external documentation
|
||||
- Provide context for why a link is relevant
|
||||
|
||||
## Persona-Specific Guidelines
|
||||
|
||||
- Include persona activation phrase at the beginning
|
||||
- Clearly indicate persona-specific sections
|
||||
- Use consistent terminology for each persona
|
||||
- Include cross-references to related personas
|
||||
- Maintain consistent formatting across all persona documentation
|
||||
|
||||
## Versioning
|
||||
|
||||
- Include last updated date in all documents
|
||||
- Use semantic versioning for documentation (MAJOR.MINOR.PATCH)
|
||||
- Maintain a changelog for significant updates
|
||||
- Indicate deprecated features clearly
|
||||
- Archive outdated documentation rather than deleting
|
||||
|
||||
## Accessibility
|
||||
|
||||
- Use descriptive alt text for images
|
||||
- Maintain proper heading hierarchy
|
||||
- Use sufficient color contrast
|
||||
- Avoid directional instructions ("click the button below")
|
||||
- Provide text alternatives for non-text content
|
||||
|
||||
## Review Process
|
||||
|
||||
- All documentation must undergo peer review
|
||||
- Use the documentation checklist before submission
|
||||
- Run automated checks for style compliance
|
||||
- Test all procedures on a clean environment
|
||||
- Validate all links and references
|
||||
|
||||
## File Organization
|
||||
|
||||
- Use kebab-case for filenames
|
||||
- Group related documents in logical folders
|
||||
- Maintain consistent file extensions (.md)
|
||||
- Include README.md files in each directory
|
||||
- Follow the established directory structure
|
||||
|
||||
---
|
||||
|
||||
*This style guide is maintained by the BMAD Documentation Team. Last updated: Current Date.*
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
# How the BMAD Method Works
|
||||
|
||||
The BMAD Method is a revolutionary AI-driven development approach that uses specialized AI personas coordinated by an intelligent orchestrator to deliver high-quality software solutions efficiently.
|
||||
|
||||
## Quick Navigation
|
||||
|
||||
| Section | Description | Best For |
|
||||
|---------|-------------|----------|
|
||||
| [🧠Core Concepts](core-concepts.md) | Fundamental BMAD principles | New users |
|
||||
| [🎠Orchestrator Mechanics](orchestrator-mechanics.md) | How the orchestrator works | Technical users |
|
||||
| [👥 Persona System](persona-system.md) | Understanding AI personas | All users |
|
||||
| [📋 Task Execution](task-execution.md) | How tasks are performed | Process-focused users |
|
||||
| [🔄 Workflow Examples](workflow-examples.md) | Real-world scenarios | Practical learners |
|
||||
| [🚀 Getting Started](getting-started.md) | Your first BMAD project | Beginners |
|
||||
|
||||
## The BMAD Advantage
|
||||
|
||||
### Traditional Development vs BMAD Method
|
||||
|
||||
| Traditional Approach | BMAD Method |
|
||||
|---------------------|-------------|
|
||||
| ⌠Manual coordination between roles | ✅ Automated orchestration |
|
||||
| ⌠Context switching between tools | ✅ Unified AI-driven workflow |
|
||||
| ⌠Inconsistent deliverable quality | ✅ Template-driven standardization |
|
||||
| ⌠Knowledge silos | ✅ Shared context across all personas |
|
||||
| ⌠Time-consuming handoffs | ✅ Seamless persona transitions |
|
||||
|
||||
### Key Benefits
|
||||
|
||||
- **🚀 10x Faster Development**: Automated coordination eliminates bottlenecks
|
||||
- **🎯 Consistent Quality**: Template-driven deliverables ensure standards
|
||||
- **🤠Seamless Handoffs**: Personas share context automatically
|
||||
- **🔧 Role Specialization**: Each persona is an expert in their domain
|
||||
- **🌠Environment Flexibility**: Works in web browsers or IDEs
|
||||
|
||||
## How It All Fits Together
|
||||
|
||||
\```mermaid title="BMAD Method Overview" type="diagram"
|
||||
graph TD
|
||||
A["User Request"] --> B["Orchestrator"]
|
||||
B --> C{["Analyze Request"]}
|
||||
C --> D["Select Persona"]
|
||||
D --> E["Execute Task"]
|
||||
E --> F["Generate Deliverable"]
|
||||
F --> G["Quality Check"]
|
||||
G --> H{["Complete?"]}
|
||||
H -->|No| I["Refine & Retry"]
|
||||
H -->|Yes| J["Update Context"]
|
||||
I --> E
|
||||
J --> K["Ready for Next Request"]
|
||||
\```
|
||||
|
||||
## Environment Support
|
||||
|
||||
The BMAD Method works seamlessly across multiple environments:
|
||||
|
||||
### 🌠Web-Based Environments
|
||||
- **ChatGPT Custom GPTs**: Full orchestrator with file attachments
|
||||
- **Google Gemini Gems**: Complete persona system with knowledge base
|
||||
- **Claude Projects**: Integrated workflow with document management
|
||||
|
||||
### 💻 IDE-Based Environments
|
||||
- **Cursor AI**: Advanced codebase integration with file system access
|
||||
- **Cline (Claude Dev)**: Project context awareness with terminal integration
|
||||
- **Claude Code**: Code quality focus with best practices enforcement
|
||||
- **Roocode**: Rapid prototyping with component library integration
|
||||
|
||||
## Getting Started Paths
|
||||
|
||||
Choose your preferred starting point:
|
||||
|
||||
1. **🚀 Quick Start (5 minutes)**: [Web Environment Setup](../quick-start-guides/web-environment-quickstart.md)
|
||||
2. **💻 Developer Setup (15 minutes)**: [IDE Environment Setup](../quick-start-guides/ide-environment-quickstart.md)
|
||||
3. **📚 Deep Dive (30 minutes)**: [Complete Training Materials](../training/using-v0-ux-ui-architect.md)
|
||||
|
||||
## What Makes BMAD Different
|
||||
|
||||
Unlike traditional development methodologies, BMAD leverages AI to:
|
||||
|
||||
- **Eliminate Communication Overhead**: Personas share perfect context
|
||||
- **Ensure Consistency**: Every deliverable follows proven templates
|
||||
- **Accelerate Decision Making**: AI-driven analysis and recommendations
|
||||
- **Maintain Quality**: Built-in checklists and validation at every step
|
||||
- **Scale Expertise**: Access to specialized knowledge across all domains
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Understand the Fundamentals**: Start with [Core Concepts](core-concepts.md)
|
||||
2. **See It In Action**: Review [Workflow Examples](workflow-examples.md)
|
||||
3. **Try It Yourself**: Follow the [Getting Started Guide](getting-started.md)
|
||||
4. **Go Deeper**: Explore specific [Persona Documentation](../v0-ux-ui-architect-user-guide.md)
|
||||
|
||||
---
|
||||
|
||||
*Ready to revolutionize your development process? The BMAD Method is waiting to transform how you build software.*
|
||||
|
|
@ -0,0 +1,205 @@
|
|||
# Core Concepts of the BMAD Method
|
||||
|
||||
Understanding these fundamental concepts is essential to leveraging the full power of the BMAD Method.
|
||||
|
||||
## The Four Pillars of BMAD
|
||||
|
||||
### 1. 🎠Orchestrator-Driven Coordination
|
||||
|
||||
The **Orchestrator** is the central intelligence that manages all interactions:
|
||||
|
||||
- **Request Analysis**: Understands user intent and context
|
||||
- **Persona Selection**: Chooses the right expert for each task
|
||||
- **Context Management**: Maintains shared knowledge across all personas
|
||||
- **Quality Assurance**: Ensures deliverables meet standards
|
||||
- **Workflow Optimization**: Streamlines handoffs and reduces friction
|
||||
|
||||
\```mermaid title="Orchestrator Decision Flow" type="diagram"
|
||||
graph TD
|
||||
A["User Input"] --> B["Parse Request"]
|
||||
B --> C{["Request Type?"]}
|
||||
C -->|Planning| D["PM Persona"]
|
||||
C -->|Architecture| E["Architect Persona"]
|
||||
C -->|Design| F["UX/UI Persona"]
|
||||
C -->|Development| G["Developer Persona"]
|
||||
C -->|Analysis| H["Analyst Persona"]
|
||||
D --> I["Execute Task"]
|
||||
E --> I
|
||||
F --> I
|
||||
G --> I
|
||||
H --> I
|
||||
I --> J["Update Shared Context"]
|
||||
J --> K["Ready for Next Request"]
|
||||
\```
|
||||
|
||||
### 2. 👥 Specialized AI Personas
|
||||
|
||||
Each persona is a domain expert with:
|
||||
|
||||
- **Deep Specialization**: Focused expertise in their field
|
||||
- **Consistent Behavior**: Reliable, predictable responses
|
||||
- **Template-Driven Output**: Standardized deliverable formats
|
||||
- **Context Awareness**: Access to full project history
|
||||
- **Quality Standards**: Built-in best practices and validation
|
||||
|
||||
#### Available Personas:
|
||||
|
||||
| Persona | Expertise | Primary Deliverables |
|
||||
|---------|-----------|---------------------|
|
||||
| **PM (Patricia)** | Project Management | PRDs, Project Plans, Status Reports |
|
||||
| **Architect (Alex)** | System Architecture | Architecture Docs, Technical Specs |
|
||||
| **UX/UI (Veronica/Victor)** | Design & Frontend | Wireframes, Components, Prototypes |
|
||||
| **Developer (David)** | Implementation | Code, Documentation, Reviews |
|
||||
| **Analyst (Anna)** | Business Analysis | Requirements, User Stories, Analysis |
|
||||
| **PO (Oliver)** | Product Strategy | Roadmaps, Feature Specs, Priorities |
|
||||
| **Scrum Master (Sam)** | Process Management | Sprint Plans, Retrospectives, Metrics |
|
||||
|
||||
### 3. 📋 Task-Driven Execution
|
||||
|
||||
Every action in BMAD is structured as a **Task**:
|
||||
|
||||
- **Clear Objectives**: Each task has specific, measurable outcomes
|
||||
- **Standardized Process**: Consistent execution methodology
|
||||
- **Template-Based Output**: Predictable deliverable formats
|
||||
- **Quality Checkpoints**: Built-in validation and review steps
|
||||
- **Context Integration**: Results feed back into shared knowledge
|
||||
|
||||
#### Task Categories:
|
||||
|
||||
\```mermaid title="Task Classification" type="diagram"
|
||||
graph LR
|
||||
A["BMAD Tasks"] --> B["Planning Tasks"]
|
||||
A --> C["Architecture Tasks"]
|
||||
A --> D["Design Tasks"]
|
||||
A --> E["Development Tasks"]
|
||||
A --> F["Analysis Tasks"]
|
||||
|
||||
B --> B1["Create PRD"]
|
||||
B --> B2["Sprint Planning"]
|
||||
B --> B3["Risk Assessment"]
|
||||
|
||||
C --> C1["System Design"]
|
||||
C --> C2["Infrastructure Planning"]
|
||||
C --> C3["Integration Architecture"]
|
||||
|
||||
D --> D1["UI/UX Specification"]
|
||||
D --> D2["Component Design"]
|
||||
D --> D3["Prototype Creation"]
|
||||
|
||||
E --> E1["Code Implementation"]
|
||||
E --> E2["Testing Strategy"]
|
||||
E --> E3["Documentation"]
|
||||
|
||||
F --> F1["Requirements Analysis"]
|
||||
F --> F2["User Story Creation"]
|
||||
F --> F3["Business Case Development"]
|
||||
\```
|
||||
|
||||
### 4. 📄 Template-Driven Standardization
|
||||
|
||||
All deliverables follow proven templates:
|
||||
|
||||
- **Consistent Structure**: Every document follows the same format
|
||||
- **Complete Coverage**: Templates ensure nothing is missed
|
||||
- **Quality Assurance**: Built-in checklists and validation
|
||||
- **Easy Maintenance**: Standardized formats are easier to update
|
||||
- **Knowledge Transfer**: Anyone can understand any deliverable
|
||||
|
||||
## The BMAD Workflow Cycle
|
||||
|
||||
\```mermaid title="Complete BMAD Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Project Initiation"] --> B["Requirements Gathering"]
|
||||
B --> C["Architecture Planning"]
|
||||
C --> D["Design Specification"]
|
||||
D --> E["Implementation Planning"]
|
||||
E --> F["Development Execution"]
|
||||
F --> G["Quality Assurance"]
|
||||
G --> H["Deployment Planning"]
|
||||
H --> I["Project Delivery"]
|
||||
|
||||
I --> J{["More Features?"]}
|
||||
J -->|Yes| K["Feature Planning"]
|
||||
J -->|No| L["Project Completion"]
|
||||
|
||||
K --> C
|
||||
|
||||
subgraph "Continuous Activities"
|
||||
M["Context Management"]
|
||||
N["Quality Monitoring"]
|
||||
O["Progress Tracking"]
|
||||
end
|
||||
|
||||
B -.-> M
|
||||
C -.-> M
|
||||
D -.-> M
|
||||
E -.-> M
|
||||
F -.-> M
|
||||
G -.-> N
|
||||
H -.-> O
|
||||
\```
|
||||
|
||||
## Key Principles
|
||||
|
||||
### 1. Context is King
|
||||
- Every persona has access to complete project history
|
||||
- Decisions are made with full context awareness
|
||||
- No information silos or communication gaps
|
||||
|
||||
### 2. Quality by Design
|
||||
- Templates ensure consistent, high-quality output
|
||||
- Built-in checklists prevent common mistakes
|
||||
- Automated validation catches issues early
|
||||
|
||||
### 3. Specialization Over Generalization
|
||||
- Each persona is deeply expert in their domain
|
||||
- No single point of failure or knowledge bottleneck
|
||||
- Optimal solutions from domain experts
|
||||
|
||||
### 4. Automation Over Manual Process
|
||||
- Orchestrator handles coordination automatically
|
||||
- Reduced human error and oversight
|
||||
- Faster execution with consistent results
|
||||
|
||||
### 5. Flexibility Within Structure
|
||||
- Templates provide structure while allowing customization
|
||||
- Personas can adapt to specific project needs
|
||||
- Framework scales from simple to complex projects
|
||||
|
||||
## Benefits in Practice
|
||||
|
||||
### For Individual Developers
|
||||
- **Reduced Cognitive Load**: Focus on your expertise, let BMAD handle coordination
|
||||
- **Higher Quality Output**: Templates and checklists ensure best practices
|
||||
- **Faster Delivery**: Automated workflows eliminate delays
|
||||
- **Continuous Learning**: Access to expert knowledge across all domains
|
||||
|
||||
### For Development Teams
|
||||
- **Consistent Deliverables**: Every team member produces standardized output
|
||||
- **Improved Collaboration**: Shared context eliminates miscommunication
|
||||
- **Scalable Process**: Framework works for teams of any size
|
||||
- **Knowledge Retention**: All decisions and rationale are documented
|
||||
|
||||
### For Organizations
|
||||
- **Predictable Outcomes**: Standardized process produces reliable results
|
||||
- **Reduced Risk**: Built-in quality assurance prevents costly mistakes
|
||||
- **Faster Time-to-Market**: Streamlined workflows accelerate delivery
|
||||
- **Competitive Advantage**: AI-augmented development capabilities
|
||||
|
||||
## Getting Started with Core Concepts
|
||||
|
||||
1. **Choose Your Environment**: Web-based or IDE-based setup
|
||||
2. **Select Your First Persona**: Start with PM for planning or UX/UI for prototyping
|
||||
3. **Execute Your First Task**: Try a simple task like creating a project brief
|
||||
4. **Review the Output**: See how templates ensure quality and completeness
|
||||
5. **Iterate and Expand**: Add more personas and tasks as you become comfortable
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **Deep Dive**: [Orchestrator Mechanics](orchestrator-mechanics.md)
|
||||
- **Practical Application**: [Workflow Examples](workflow-examples.md)
|
||||
- **Hands-On Practice**: [Getting Started Guide](getting-started.md)
|
||||
|
||||
---
|
||||
|
||||
*These core concepts form the foundation of the BMAD Method. Master them, and you'll unlock the full potential of AI-driven development.*
|
||||
|
|
@ -0,0 +1,291 @@
|
|||
# BMAD Integration Points
|
||||
|
||||
This document outlines the key integration points within the BMAD system and how different components interact.
|
||||
|
||||
## Overview
|
||||
|
||||
BMAD operates through multiple integration points that enable seamless collaboration between personas, tools, and processes. Understanding these integration points is crucial for effective system utilization.
|
||||
|
||||
## System Integration Architecture
|
||||
|
||||
\```mermaid
|
||||
graph TB
|
||||
subgraph "External Systems"
|
||||
IDE[IDE Environment]
|
||||
WEB[Web Interface]
|
||||
API[External APIs]
|
||||
end
|
||||
|
||||
subgraph "BMAD Core"
|
||||
ORCH[Orchestrator]
|
||||
PERSONAS[Persona System]
|
||||
TASKS[Task Engine]
|
||||
TEMPLATES[Template System]
|
||||
end
|
||||
|
||||
subgraph "Data Layer"
|
||||
KB[Knowledge Base]
|
||||
CHECKLISTS[Checklists]
|
||||
CONFIGS[Configurations]
|
||||
end
|
||||
|
||||
IDE --> ORCH
|
||||
WEB --> ORCH
|
||||
API --> ORCH
|
||||
|
||||
ORCH --> PERSONAS
|
||||
ORCH --> TASKS
|
||||
ORCH --> TEMPLATES
|
||||
|
||||
PERSONAS --> KB
|
||||
TASKS --> CHECKLISTS
|
||||
TEMPLATES --> CONFIGS
|
||||
\```
|
||||
|
||||
## Core Integration Points
|
||||
|
||||
### 1. IDE Integration
|
||||
|
||||
**Purpose**: Enable BMAD methodology within development environments
|
||||
|
||||
**Integration Methods:**
|
||||
- Loading persona documentation into AI assistant context
|
||||
- Referencing task libraries and templates
|
||||
- Following methodology patterns and checklists
|
||||
- Structuring prompts according to BMAD principles
|
||||
|
||||
**Key Features:**
|
||||
- Persona-based prompt structuring
|
||||
- Template-guided document creation
|
||||
- Quality checklist validation
|
||||
- Methodology-driven workflows
|
||||
|
||||
### 2. Web Interface Integration
|
||||
|
||||
**Purpose**: Provide browser-based access to BMAD functionality
|
||||
|
||||
**Integration Methods:**
|
||||
- REST API endpoints
|
||||
- WebSocket connections
|
||||
- OAuth authentication
|
||||
- Session management
|
||||
|
||||
**Key Features:**
|
||||
- Persona management dashboard
|
||||
- Project collaboration tools
|
||||
- Real-time status updates
|
||||
- Document generation and sharing
|
||||
|
||||
### 3. Template System Integration
|
||||
|
||||
**Purpose**: Enable consistent document and code generation
|
||||
|
||||
**Integration Flow:**
|
||||
\```mermaid
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant Orchestrator
|
||||
participant Template Engine
|
||||
participant Output System
|
||||
|
||||
User->>Orchestrator: Request Document Creation
|
||||
Orchestrator->>Template Engine: Load Template
|
||||
Template Engine->>Template Engine: Process Variables
|
||||
Template Engine->>Output System: Generate Content
|
||||
Output System->>User: Deliver Document
|
||||
\```
|
||||
|
||||
### 4. Checklist Integration
|
||||
|
||||
**Purpose**: Ensure quality and completeness of deliverables
|
||||
|
||||
**Integration Points:**
|
||||
- Task execution validation
|
||||
- Quality gate enforcement
|
||||
- Progress tracking
|
||||
- Compliance verification
|
||||
|
||||
### 5. Knowledge Base Integration
|
||||
|
||||
**Purpose**: Provide contextual information and best practices
|
||||
|
||||
**Integration Methods:**
|
||||
- Semantic search capabilities
|
||||
- Context-aware recommendations
|
||||
- Dynamic content updates
|
||||
- Version control integration
|
||||
|
||||
## Persona Integration Patterns
|
||||
|
||||
### 1. Sequential Integration
|
||||
|
||||
Personas work in sequence, with clear handoff points:
|
||||
|
||||
\```mermaid
|
||||
graph LR
|
||||
PO[Product Owner] --> PM[Project Manager]
|
||||
PM --> ARCH[Architect]
|
||||
ARCH --> UX[UX/UI Designer]
|
||||
UX --> DEV[Developer]
|
||||
\```
|
||||
|
||||
### 2. Parallel Integration
|
||||
|
||||
Multiple personas work simultaneously on different aspects:
|
||||
|
||||
\```mermaid
|
||||
graph TD
|
||||
REQ[Requirements] --> PO[Product Owner]
|
||||
REQ --> PM[Project Manager]
|
||||
REQ --> ARCH[Architect]
|
||||
|
||||
PO --> INTEGRATION[Integration Point]
|
||||
PM --> INTEGRATION
|
||||
ARCH --> INTEGRATION
|
||||
\```
|
||||
|
||||
### 3. Collaborative Integration
|
||||
|
||||
Personas collaborate in real-time on shared deliverables:
|
||||
|
||||
\```mermaid
|
||||
graph TB
|
||||
subgraph "Collaborative Space"
|
||||
DOC[Shared Document]
|
||||
PO[PO Input]
|
||||
ARCH[Architect Input]
|
||||
UX[UX Input]
|
||||
end
|
||||
|
||||
PO --> DOC
|
||||
ARCH --> DOC
|
||||
UX --> DOC
|
||||
\```
|
||||
|
||||
## Data Integration Points
|
||||
|
||||
### 1. Configuration Management
|
||||
|
||||
**Purpose**: Maintain consistent system behavior across environments
|
||||
|
||||
**Components:**
|
||||
- Environment-specific settings
|
||||
- Persona configurations
|
||||
- Template parameters
|
||||
- Integration credentials
|
||||
|
||||
### 2. State Management
|
||||
|
||||
**Purpose**: Track system state and user progress
|
||||
|
||||
**Components:**
|
||||
- Session state
|
||||
- Project progress
|
||||
- Task completion status
|
||||
- User preferences
|
||||
|
||||
### 3. Content Synchronization
|
||||
|
||||
**Purpose**: Ensure data consistency across integration points
|
||||
|
||||
**Methods:**
|
||||
- Real-time synchronization
|
||||
- Batch updates
|
||||
- Conflict resolution
|
||||
- Version control
|
||||
|
||||
## External System Integration
|
||||
|
||||
### 1. Version Control Systems
|
||||
|
||||
**Supported Systems:**
|
||||
- Git (GitHub, GitLab, Bitbucket)
|
||||
- SVN
|
||||
- Mercurial
|
||||
|
||||
**Integration Features:**
|
||||
- Automated commits
|
||||
- Branch management
|
||||
- Pull request creation
|
||||
- Code review integration
|
||||
|
||||
### 2. Project Management Tools
|
||||
|
||||
**Supported Tools:**
|
||||
- Jira
|
||||
- Azure DevOps
|
||||
- Trello
|
||||
- Asana
|
||||
|
||||
**Integration Features:**
|
||||
- Task synchronization
|
||||
- Progress updates
|
||||
- Milestone tracking
|
||||
- Reporting integration
|
||||
|
||||
### 3. Communication Platforms
|
||||
|
||||
**Supported Platforms:**
|
||||
- Slack
|
||||
- Microsoft Teams
|
||||
- Discord
|
||||
- Email systems
|
||||
|
||||
**Integration Features:**
|
||||
- Automated notifications
|
||||
- Status updates
|
||||
- Collaboration alerts
|
||||
- Document sharing
|
||||
|
||||
## Integration Security
|
||||
|
||||
### 1. Authentication & Authorization
|
||||
|
||||
- OAuth 2.0 integration
|
||||
- Role-based access control
|
||||
- API key management
|
||||
- Session security
|
||||
|
||||
### 2. Data Protection
|
||||
|
||||
- Encryption in transit and at rest
|
||||
- Secure credential storage
|
||||
- Audit logging
|
||||
- Privacy compliance
|
||||
|
||||
### 3. Network Security
|
||||
|
||||
- HTTPS enforcement
|
||||
- API rate limiting
|
||||
- Input validation
|
||||
- Cross-origin resource sharing (CORS)
|
||||
|
||||
## Troubleshooting Integration Issues
|
||||
|
||||
### Common Issues
|
||||
|
||||
1. **Authentication Failures**
|
||||
- Verify credentials
|
||||
- Check token expiration
|
||||
- Validate permissions
|
||||
|
||||
2. **Synchronization Problems**
|
||||
- Check network connectivity
|
||||
- Verify API endpoints
|
||||
- Review rate limits
|
||||
|
||||
3. **Configuration Errors**
|
||||
- Validate configuration files
|
||||
- Check environment variables
|
||||
- Verify file permissions
|
||||
|
||||
### Diagnostic Tools
|
||||
|
||||
- Integration health checks
|
||||
- Log analysis tools
|
||||
- Performance monitoring
|
||||
- Error tracking systems
|
||||
|
||||
---
|
||||
|
||||
*Effective integration management ensures seamless BMAD system operation and optimal user experience.*
|
||||
|
|
@ -0,0 +1,332 @@
|
|||
# Orchestrator Mechanics: The Brain of BMAD
|
||||
|
||||
The Orchestrator is the central intelligence system that coordinates all BMAD personas and tasks. Understanding how it works is crucial for maximizing the effectiveness of the BMAD Method.
|
||||
|
||||
## Orchestrator Architecture
|
||||
|
||||
\```mermaid title="Orchestrator System Architecture" type="diagram"
|
||||
graph TB
|
||||
subgraph "User Interface Layer"
|
||||
A["User Input"]
|
||||
B["Command Parser"]
|
||||
C["Response Formatter"]
|
||||
end
|
||||
|
||||
subgraph "Orchestrator Core"
|
||||
D["Request Analyzer"]
|
||||
E["Context Manager"]
|
||||
F["Persona Selector"]
|
||||
G["Task Coordinator"]
|
||||
H["Quality Controller"]
|
||||
end
|
||||
|
||||
subgraph "Persona Layer"
|
||||
I["PM Persona"]
|
||||
J["Architect Persona"]
|
||||
K["UX/UI Persona"]
|
||||
L["Developer Persona"]
|
||||
M["Analyst Persona"]
|
||||
end
|
||||
|
||||
subgraph "Knowledge Base"
|
||||
N["Project Context"]
|
||||
O["Templates"]
|
||||
P["Checklists"]
|
||||
Q["Best Practices"]
|
||||
end
|
||||
|
||||
A --> B
|
||||
B --> D
|
||||
D --> E
|
||||
E --> F
|
||||
F --> G
|
||||
G --> I
|
||||
G --> J
|
||||
G --> K
|
||||
G --> L
|
||||
G --> M
|
||||
|
||||
I --> H
|
||||
J --> H
|
||||
K --> H
|
||||
L --> H
|
||||
M --> H
|
||||
|
||||
H --> C
|
||||
|
||||
E <--> N
|
||||
G <--> O
|
||||
H <--> P
|
||||
F <--> Q
|
||||
\```
|
||||
|
||||
## Core Components
|
||||
|
||||
### 1. Request Analyzer
|
||||
|
||||
The Request Analyzer is the first component that processes user input:
|
||||
|
||||
**Functions:**
|
||||
- **Intent Recognition**: Determines what the user wants to accomplish
|
||||
- **Context Extraction**: Identifies relevant project context and constraints
|
||||
- **Complexity Assessment**: Evaluates the scope and difficulty of the request
|
||||
- **Priority Classification**: Determines urgency and importance levels
|
||||
|
||||
**Decision Matrix:**
|
||||
|
||||
| Input Type | Analysis Focus | Output |
|
||||
|------------|----------------|---------|
|
||||
| Feature Request | Business value, technical complexity | PM + Architect personas |
|
||||
| Bug Report | Impact assessment, root cause analysis | Developer + Analyst personas |
|
||||
| Design Change | User impact, implementation effort | UX/UI + Developer personas |
|
||||
| Architecture Question | System implications, scalability | Architect + Developer personas |
|
||||
|
||||
### 2. Context Manager
|
||||
|
||||
Maintains and provides access to all project information:
|
||||
|
||||
**Responsibilities:**
|
||||
- **State Tracking**: Current project status and progress
|
||||
- **History Management**: Complete record of all decisions and changes
|
||||
- **Dependency Mapping**: Relationships between components and features
|
||||
- **Knowledge Synthesis**: Combining information from multiple sources
|
||||
|
||||
**Context Structure:**
|
||||
|
||||
\```mermaid title="Context Information Flow" type="diagram"
|
||||
graph LR
|
||||
A["User Interactions"] --> B["Context Manager"]
|
||||
C["Persona Outputs"] --> B
|
||||
D["Task Results"] --> B
|
||||
E["External Data"] --> B
|
||||
|
||||
B --> F["Current State"]
|
||||
B --> G["Historical Record"]
|
||||
B --> H["Dependency Graph"]
|
||||
B --> I["Knowledge Base"]
|
||||
|
||||
F --> J["Active Personas"]
|
||||
G --> J
|
||||
H --> J
|
||||
I --> J
|
||||
\```
|
||||
|
||||
### 3. Persona Selector
|
||||
|
||||
Intelligently chooses the right persona(s) for each task:
|
||||
|
||||
**Selection Criteria:**
|
||||
- **Domain Expertise**: Match task requirements to persona specialization
|
||||
- **Current Context**: Consider what information is already available
|
||||
- **Workflow Stage**: Align with current project phase
|
||||
- **Resource Availability**: Optimize for efficiency and parallel execution
|
||||
|
||||
**Selection Algorithm:**
|
||||
|
||||
\```mermaid title="Persona Selection Logic" type="diagram"
|
||||
graph TD
|
||||
A["Analyze Request"] --> B{["Primary Domain?"]}
|
||||
|
||||
B -->|Planning| C["PM Persona"]
|
||||
B -->|Technical| D["Architect Persona"]
|
||||
B -->|Design| E["UX/UI Persona"]
|
||||
B -->|Implementation| F["Developer Persona"]
|
||||
B -->|Analysis| G["Analyst Persona"]
|
||||
|
||||
C --> H{["Need Support?"]}
|
||||
D --> H
|
||||
E --> H
|
||||
F --> H
|
||||
G --> H
|
||||
|
||||
H -->|Yes| I["Select Secondary Personas"]
|
||||
H -->|No| J["Execute with Primary"]
|
||||
|
||||
I --> K["Coordinate Multi-Persona Task"]
|
||||
J --> L["Execute Single-Persona Task"]
|
||||
|
||||
K --> M["Synthesize Results"]
|
||||
L --> M
|
||||
\```
|
||||
|
||||
### 4. Task Coordinator
|
||||
|
||||
Manages the execution of tasks across personas:
|
||||
|
||||
**Coordination Functions:**
|
||||
- **Task Decomposition**: Breaking complex requests into manageable tasks
|
||||
- **Dependency Resolution**: Ensuring tasks execute in the correct order
|
||||
- **Parallel Execution**: Running independent tasks simultaneously
|
||||
- **Progress Monitoring**: Tracking completion status and quality metrics
|
||||
|
||||
**Task Execution Flow:**
|
||||
|
||||
\```mermaid title="Task Coordination Process" type="diagram"
|
||||
graph TD
|
||||
A["Receive Task Request"] --> B["Decompose into Subtasks"]
|
||||
B --> C["Identify Dependencies"]
|
||||
C --> D["Create Execution Plan"]
|
||||
D --> E["Assign to Personas"]
|
||||
|
||||
E --> F{["Parallel Execution?"]}
|
||||
F -->|Yes| G["Execute Simultaneously"]
|
||||
F -->|No| H["Execute Sequentially"]
|
||||
|
||||
G --> I["Monitor Progress"]
|
||||
H --> I
|
||||
|
||||
I --> J{["All Complete?"]}
|
||||
J -->|No| K["Continue Execution"]
|
||||
J -->|Yes| L["Synthesize Results"]
|
||||
|
||||
K --> I
|
||||
L --> M["Quality Check"]
|
||||
M --> N["Deliver Results"]
|
||||
\```
|
||||
|
||||
### 5. Quality Controller
|
||||
|
||||
Ensures all outputs meet BMAD standards:
|
||||
|
||||
**Quality Assurance Process:**
|
||||
- **Template Compliance**: Verify outputs follow required formats
|
||||
- **Completeness Check**: Ensure all required sections are present
|
||||
- **Consistency Validation**: Check alignment with project context
|
||||
- **Best Practice Review**: Validate against established standards
|
||||
|
||||
## Command Processing
|
||||
|
||||
### Web Environment Commands
|
||||
|
||||
| Command | Function | Example |
|
||||
|---------|----------|---------|
|
||||
| `/persona [name]` | Activate specific persona | `/persona pm` |
|
||||
| `/task [name]` | Execute specific task | `/task create-prd` |
|
||||
| `/context` | Show current project context | `/context` |
|
||||
| `/help` | Display available options | `/help` |
|
||||
|
||||
### IDE Environment Commands
|
||||
|
||||
| Command | Function | Example |
|
||||
|---------|----------|---------|
|
||||
| `*persona [name]` | Activate specific persona | `*persona architect` |
|
||||
| `*task [name]` | Execute specific task | `*task create-architecture` |
|
||||
| `*context` | Show current project context | `*context` |
|
||||
| `*help` | Display available options | `*help` |
|
||||
|
||||
## Advanced Orchestration Features
|
||||
|
||||
### 1. Adaptive Learning
|
||||
|
||||
The Orchestrator learns from each interaction:
|
||||
|
||||
- **Pattern Recognition**: Identifies common request types and optimal responses
|
||||
- **Performance Optimization**: Improves task execution based on historical data
|
||||
- **Context Refinement**: Enhances context management through usage patterns
|
||||
- **Quality Improvement**: Adjusts quality standards based on feedback
|
||||
|
||||
### 2. Multi-Modal Integration
|
||||
|
||||
Supports various input and output formats:
|
||||
|
||||
**Input Modes:**
|
||||
- Text commands and descriptions
|
||||
- File uploads and attachments
|
||||
- Screenshots and images
|
||||
- Voice commands (in supported environments)
|
||||
|
||||
**Output Modes:**
|
||||
- Structured documents (Markdown, PDF)
|
||||
- Code files and implementations
|
||||
- Diagrams and visualizations
|
||||
- Interactive prototypes
|
||||
|
||||
### 3. Environment Adaptation
|
||||
|
||||
Automatically adapts to different environments:
|
||||
|
||||
**Web Environment Features:**
|
||||
- File attachment processing
|
||||
- Rich text formatting
|
||||
- Interactive elements
|
||||
- Collaborative features
|
||||
|
||||
**IDE Environment Features:**
|
||||
- File system integration
|
||||
- Code completion and suggestions
|
||||
- Terminal command execution
|
||||
- Version control integration
|
||||
|
||||
## Troubleshooting Common Issues
|
||||
|
||||
### Issue: Persona Not Responding Correctly
|
||||
|
||||
**Diagnosis Steps:**
|
||||
1. Check command syntax (`/persona` vs `*persona`)
|
||||
2. Verify persona name spelling
|
||||
3. Confirm current context is appropriate
|
||||
4. Review recent interaction history
|
||||
|
||||
**Solutions:**
|
||||
- Reset context with `/context reset`
|
||||
- Explicitly specify requirements
|
||||
- Use `/help` to see available options
|
||||
- Try alternative persona for the task
|
||||
|
||||
### Issue: Task Execution Incomplete
|
||||
|
||||
**Diagnosis Steps:**
|
||||
1. Review task requirements and scope
|
||||
2. Check for missing dependencies
|
||||
3. Verify persona has necessary context
|
||||
4. Examine quality control feedback
|
||||
|
||||
**Solutions:**
|
||||
- Break complex tasks into smaller parts
|
||||
- Provide additional context or requirements
|
||||
- Use `/task status` to check progress
|
||||
- Manually trigger quality review
|
||||
|
||||
### Issue: Context Loss or Confusion
|
||||
|
||||
**Diagnosis Steps:**
|
||||
1. Review recent context changes
|
||||
2. Check for conflicting information
|
||||
3. Verify persona state consistency
|
||||
4. Examine interaction history
|
||||
|
||||
**Solutions:**
|
||||
- Use `/context refresh` to rebuild state
|
||||
- Explicitly restate current objectives
|
||||
- Clear conflicting information
|
||||
- Start fresh with `/context reset`
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
### Best Practices for Orchestrator Efficiency
|
||||
|
||||
1. **Clear Communication**: Provide specific, detailed requests
|
||||
2. **Context Management**: Keep project context current and relevant
|
||||
3. **Task Sizing**: Break large requests into manageable tasks
|
||||
4. **Persona Selection**: Choose the most appropriate persona for each task
|
||||
5. **Quality Focus**: Review outputs and provide feedback for improvement
|
||||
|
||||
### Monitoring and Metrics
|
||||
|
||||
Track these key performance indicators:
|
||||
|
||||
- **Response Time**: How quickly the orchestrator processes requests
|
||||
- **Task Completion Rate**: Percentage of tasks completed successfully
|
||||
- **Quality Score**: Average quality rating of deliverables
|
||||
- **Context Accuracy**: How well the orchestrator maintains project state
|
||||
- **User Satisfaction**: Feedback on orchestrator performance
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **See It In Action**: [Workflow Examples](workflow-examples.md)
|
||||
- **Understand the Team**: [Persona System](persona-system.md)
|
||||
- **Try It Yourself**: [Getting Started Guide](getting-started.md)
|
||||
|
||||
---
|
||||
|
||||
*The Orchestrator is the heart of the BMAD Method. Master its mechanics, and you'll unlock unprecedented development efficiency and quality.*
|
||||
|
|
@ -0,0 +1,165 @@
|
|||
# Persona Workflows in BMAD
|
||||
|
||||
This document details how each BMAD persona operates within the system and their specific workflows.
|
||||
|
||||
## Overview
|
||||
|
||||
Each BMAD persona has specialized workflows designed to maximize their effectiveness within their domain expertise. Understanding these workflows helps users leverage the right persona for their specific needs.
|
||||
|
||||
## Core Persona Workflows
|
||||
|
||||
### 1. Product Owner (PO) Workflow
|
||||
|
||||
\```mermaid
|
||||
graph TD
|
||||
A[Receive Requirements] --> B[Analyze Business Value]
|
||||
B --> C[Create User Stories]
|
||||
C --> D[Define Acceptance Criteria]
|
||||
D --> E[Prioritize Backlog]
|
||||
E --> F[Stakeholder Review]
|
||||
F --> G[Story Refinement]
|
||||
G --> H[Sprint Planning Input]
|
||||
\```
|
||||
|
||||
**Key Activities:**
|
||||
- Requirements gathering and analysis
|
||||
- User story creation and refinement
|
||||
- Backlog prioritization
|
||||
- Stakeholder communication
|
||||
- Acceptance criteria definition
|
||||
|
||||
### 2. Project Manager (PM) Workflow
|
||||
|
||||
\```mermaid
|
||||
graph TD
|
||||
A[Project Initiation] --> B[Resource Planning]
|
||||
B --> C[Timeline Creation]
|
||||
C --> D[Risk Assessment]
|
||||
D --> E[Team Coordination]
|
||||
E --> F[Progress Monitoring]
|
||||
F --> G[Stakeholder Updates]
|
||||
G --> H[Delivery Management]
|
||||
\```
|
||||
|
||||
**Key Activities:**
|
||||
- Project planning and scheduling
|
||||
- Resource allocation and management
|
||||
- Risk identification and mitigation
|
||||
- Team coordination and communication
|
||||
- Progress tracking and reporting
|
||||
|
||||
### 3. System Architect Workflow
|
||||
|
||||
\```mermaid
|
||||
graph TD
|
||||
A[Requirements Analysis] --> B[Architecture Design]
|
||||
B --> C[Technology Selection]
|
||||
C --> D[Component Definition]
|
||||
D --> E[Integration Planning]
|
||||
E --> F[Documentation Creation]
|
||||
F --> G[Review and Validation]
|
||||
G --> H[Implementation Guidance]
|
||||
\```
|
||||
|
||||
**Key Activities:**
|
||||
- System design and architecture
|
||||
- Technology stack decisions
|
||||
- Component and service definition
|
||||
- Integration pattern design
|
||||
- Technical documentation
|
||||
|
||||
### 4. UX/UI Architect Workflow
|
||||
|
||||
\```mermaid
|
||||
graph TD
|
||||
A[User Research] --> B[Design System Creation]
|
||||
B --> C[Component Specification]
|
||||
C --> D[Prototype Development]
|
||||
D --> E[Usability Testing]
|
||||
E --> F[Design Refinement]
|
||||
F --> G[Implementation Specs]
|
||||
G --> H[Quality Assurance]
|
||||
\```
|
||||
|
||||
**Key Activities:**
|
||||
- User experience research and design
|
||||
- Design system development
|
||||
- Component specification and prototyping
|
||||
- Usability testing and validation
|
||||
- Implementation guidance
|
||||
|
||||
### 5. Business Analyst Workflow
|
||||
|
||||
\```mermaid
|
||||
graph TD
|
||||
A[Business Requirements] --> B[Process Analysis]
|
||||
B --> C[Gap Identification]
|
||||
C --> D[Solution Design]
|
||||
D --> E[Impact Assessment]
|
||||
E --> F[Documentation]
|
||||
F --> G[Stakeholder Review]
|
||||
G --> H[Implementation Support]
|
||||
\```
|
||||
|
||||
**Key Activities:**
|
||||
- Business process analysis
|
||||
- Requirements elicitation and documentation
|
||||
- Gap analysis and solution design
|
||||
- Impact assessment and change management
|
||||
- Stakeholder communication
|
||||
|
||||
## Workflow Integration Points
|
||||
|
||||
### Cross-Persona Collaboration
|
||||
|
||||
1. **PO ↔ PM**: Story prioritization and sprint planning
|
||||
2. **Architect ↔ UX/UI**: Technical feasibility and design constraints
|
||||
3. **BA ↔ PO**: Requirements refinement and business value alignment
|
||||
4. **PM ↔ All**: Coordination, timeline management, and delivery
|
||||
|
||||
### Handoff Protocols
|
||||
|
||||
Each persona follows specific handoff protocols to ensure smooth transitions:
|
||||
|
||||
- **Documentation Standards**: Consistent format and content requirements
|
||||
- **Review Checkpoints**: Mandatory review gates between workflow stages
|
||||
- **Quality Gates**: Acceptance criteria for deliverable completion
|
||||
- **Communication Protocols**: Standardized update and feedback mechanisms
|
||||
|
||||
## Workflow Optimization
|
||||
|
||||
### Best Practices
|
||||
|
||||
1. **Early Collaboration**: Involve relevant personas from project inception
|
||||
2. **Iterative Refinement**: Regular review and improvement of workflows
|
||||
3. **Clear Handoffs**: Well-defined transition points between personas
|
||||
4. **Continuous Feedback**: Regular retrospectives and process improvements
|
||||
|
||||
### Common Pitfalls
|
||||
|
||||
- **Siloed Work**: Personas working in isolation without collaboration
|
||||
- **Unclear Handoffs**: Ambiguous transition points causing delays
|
||||
- **Missing Documentation**: Inadequate documentation for workflow steps
|
||||
- **Rigid Processes**: Inflexible workflows that don't adapt to project needs
|
||||
|
||||
## Workflow Customization
|
||||
|
||||
### Project-Specific Adaptations
|
||||
|
||||
Workflows can be customized based on:
|
||||
- Project size and complexity
|
||||
- Team composition and skills
|
||||
- Timeline constraints
|
||||
- Technology requirements
|
||||
- Stakeholder preferences
|
||||
|
||||
### Configuration Options
|
||||
|
||||
- **Workflow Steps**: Add, remove, or modify workflow stages
|
||||
- **Review Gates**: Customize review and approval processes
|
||||
- **Documentation Requirements**: Adjust documentation depth and format
|
||||
- **Collaboration Patterns**: Modify interaction frequencies and methods
|
||||
|
||||
---
|
||||
|
||||
*Understanding persona workflows enables effective BMAD system utilization and optimal project outcomes.*
|
||||
|
|
@ -0,0 +1,357 @@
|
|||
# BMAD Troubleshooting Guide
|
||||
|
||||
This comprehensive guide helps users diagnose and resolve common issues encountered while using the BMAD system.
|
||||
|
||||
## Quick Diagnostic Checklist
|
||||
|
||||
Before diving into specific issues, run through this quick checklist:
|
||||
|
||||
- [ ] Verify BMAD configuration files are present and valid
|
||||
- [ ] Check network connectivity and API access
|
||||
- [ ] Confirm persona permissions and access rights
|
||||
- [ ] Validate template and checklist file integrity
|
||||
- [ ] Review recent system logs for error messages
|
||||
|
||||
## Common Issues and Solutions
|
||||
|
||||
### 1. Persona Loading Issues
|
||||
|
||||
#### Symptom: Persona fails to load or respond
|
||||
|
||||
**Possible Causes:**
|
||||
- Missing or corrupted persona configuration files
|
||||
- Insufficient permissions
|
||||
- Network connectivity issues
|
||||
- Invalid persona syntax
|
||||
|
||||
**Solutions:**
|
||||
|
||||
1. **Verify Persona Files:**
|
||||
```bash
|
||||
# Check if persona files exist
|
||||
ls -la bmad-agent/personas/
|
||||
|
||||
# Validate persona syntax
|
||||
bmad validate-persona --persona=po
|
||||
```
|
||||
|
||||
2. **Reset Persona Configuration:**
|
||||
```bash
|
||||
# Backup current config
|
||||
cp bmad-config.yml bmad-config.yml.backup
|
||||
|
||||
# Reset to default
|
||||
bmad reset-config --persona=po
|
||||
```
|
||||
|
||||
3. **Check Permissions:**
|
||||
```bash
|
||||
# Verify file permissions
|
||||
chmod 644 bmad-agent/personas/*.md
|
||||
```
|
||||
|
||||
### 2. Template Generation Failures
|
||||
|
||||
#### Symptom: Templates fail to generate or produce incorrect output
|
||||
|
||||
**Possible Causes:**
|
||||
- Missing template variables
|
||||
- Corrupted template files
|
||||
- Invalid template syntax
|
||||
- Insufficient data context
|
||||
|
||||
**Solutions:**
|
||||
|
||||
1. **Validate Template Syntax:**
|
||||
```bash
|
||||
# Check template validity
|
||||
bmad validate-template --template=prd-tmpl.md
|
||||
```
|
||||
|
||||
2. **Debug Template Variables:**
|
||||
```bash
|
||||
# List available variables
|
||||
bmad debug-template --template=prd-tmpl.md --show-vars
|
||||
```
|
||||
|
||||
3. **Regenerate Template:**
|
||||
```bash
|
||||
# Force template regeneration
|
||||
bmad generate --template=prd-tmpl.md --force
|
||||
```
|
||||
|
||||
### 3. Checklist Validation Errors
|
||||
|
||||
#### Symptom: Checklists fail validation or show incorrect status
|
||||
|
||||
**Possible Causes:**
|
||||
- Outdated checklist definitions
|
||||
- Missing checklist dependencies
|
||||
- Incorrect task mapping
|
||||
- Data synchronization issues
|
||||
|
||||
**Solutions:**
|
||||
|
||||
1. **Update Checklists:**
|
||||
```bash
|
||||
# Refresh checklist definitions
|
||||
bmad update-checklists
|
||||
```
|
||||
|
||||
2. **Validate Checklist Mapping:**
|
||||
```bash
|
||||
# Check task-to-checklist mapping
|
||||
bmad validate-mapping --checklist=po-master-checklist.md
|
||||
```
|
||||
|
||||
3. **Reset Checklist State:**
|
||||
```bash
|
||||
# Clear checklist cache
|
||||
bmad clear-cache --type=checklists
|
||||
```
|
||||
|
||||
### 4. Integration Connection Issues
|
||||
|
||||
#### Symptom: External system integrations fail or timeout
|
||||
|
||||
**Possible Causes:**
|
||||
- Network connectivity problems
|
||||
- Authentication failures
|
||||
- API rate limiting
|
||||
- Service unavailability
|
||||
|
||||
**Solutions:**
|
||||
|
||||
1. **Test Connectivity:**
|
||||
```bash
|
||||
# Test API endpoints
|
||||
bmad test-connection --service=github
|
||||
bmad test-connection --service=jira
|
||||
```
|
||||
|
||||
2. **Refresh Authentication:**
|
||||
```bash
|
||||
# Renew authentication tokens
|
||||
bmad auth-refresh --service=github
|
||||
```
|
||||
|
||||
3. **Check Rate Limits:**
|
||||
```bash
|
||||
# Monitor API usage
|
||||
bmad status --api-usage
|
||||
```
|
||||
|
||||
### 5. Performance Issues
|
||||
|
||||
#### Symptom: Slow response times or system lag
|
||||
|
||||
**Possible Causes:**
|
||||
- Large knowledge base files
|
||||
- Inefficient queries
|
||||
- Memory constraints
|
||||
- Network latency
|
||||
|
||||
**Solutions:**
|
||||
|
||||
1. **Optimize Knowledge Base:**
|
||||
```bash
|
||||
# Rebuild search index
|
||||
bmad rebuild-index
|
||||
|
||||
# Compress knowledge base
|
||||
bmad optimize-kb
|
||||
```
|
||||
|
||||
2. **Clear System Cache:**
|
||||
```bash
|
||||
# Clear all caches
|
||||
bmad clear-cache --all
|
||||
```
|
||||
|
||||
3. **Monitor System Resources:**
|
||||
```bash
|
||||
# Check system performance
|
||||
bmad system-status --detailed
|
||||
```
|
||||
|
||||
## Environment-Specific Issues
|
||||
|
||||
### IDE Environment Issues
|
||||
|
||||
#### VS Code / Cursor Integration
|
||||
|
||||
**Common Issues:**
|
||||
- Extension not loading
|
||||
- Configuration not recognized
|
||||
- Syntax highlighting missing
|
||||
|
||||
**Solutions:**
|
||||
1. Reinstall BMAD extension
|
||||
2. Reload VS Code window
|
||||
3. Check extension compatibility
|
||||
4. Verify workspace settings
|
||||
|
||||
#### Command Line Issues
|
||||
|
||||
**Common Issues:**
|
||||
- Command not found
|
||||
- Permission denied
|
||||
- Path configuration errors
|
||||
|
||||
**Solutions:**
|
||||
1. Add BMAD to system PATH
|
||||
2. Set proper file permissions
|
||||
3. Verify installation directory
|
||||
4. Check shell configuration
|
||||
|
||||
### Web Environment Issues
|
||||
|
||||
#### Browser Compatibility
|
||||
|
||||
**Common Issues:**
|
||||
- Features not working in specific browsers
|
||||
- JavaScript errors
|
||||
- CSS rendering problems
|
||||
|
||||
**Solutions:**
|
||||
1. Update to supported browser version
|
||||
2. Clear browser cache and cookies
|
||||
3. Disable conflicting extensions
|
||||
4. Check JavaScript console for errors
|
||||
|
||||
#### Authentication Problems
|
||||
|
||||
**Common Issues:**
|
||||
- Login failures
|
||||
- Session timeouts
|
||||
- Permission errors
|
||||
|
||||
**Solutions:**
|
||||
1. Clear browser storage
|
||||
2. Verify credentials
|
||||
3. Check session configuration
|
||||
4. Review user permissions
|
||||
|
||||
## Advanced Troubleshooting
|
||||
|
||||
### Log Analysis
|
||||
|
||||
#### Accessing Logs
|
||||
|
||||
```bash
|
||||
# View recent logs
|
||||
bmad logs --tail=100
|
||||
|
||||
# Filter by severity
|
||||
bmad logs --level=error
|
||||
|
||||
# Export logs for analysis
|
||||
bmad logs --export=bmad-logs.txt
|
||||
```
|
||||
|
||||
#### Common Log Patterns
|
||||
|
||||
**Error Patterns to Look For:**
|
||||
- `Authentication failed`: Check credentials and permissions
|
||||
- `Template not found`: Verify template file paths
|
||||
- `Network timeout`: Check connectivity and API status
|
||||
- `Validation failed`: Review input data and formats
|
||||
|
||||
### System Diagnostics
|
||||
|
||||
#### Health Check
|
||||
|
||||
```bash
|
||||
# Run comprehensive system check
|
||||
bmad health-check --comprehensive
|
||||
|
||||
# Check specific components
|
||||
bmad health-check --component=personas
|
||||
bmad health-check --component=templates
|
||||
bmad health-check --component=integrations
|
||||
```
|
||||
|
||||
#### Performance Profiling
|
||||
|
||||
```bash
|
||||
# Profile system performance
|
||||
bmad profile --duration=60s
|
||||
|
||||
# Analyze memory usage
|
||||
bmad profile --memory
|
||||
|
||||
# Check disk usage
|
||||
bmad profile --disk
|
||||
```
|
||||
|
||||
### Recovery Procedures
|
||||
|
||||
#### Configuration Recovery
|
||||
|
||||
```bash
|
||||
# Backup current configuration
|
||||
bmad backup-config --output=config-backup.tar.gz
|
||||
|
||||
# Restore from backup
|
||||
bmad restore-config --input=config-backup.tar.gz
|
||||
|
||||
# Reset to factory defaults
|
||||
bmad factory-reset --confirm
|
||||
```
|
||||
|
||||
#### Data Recovery
|
||||
|
||||
```bash
|
||||
# Recover corrupted knowledge base
|
||||
bmad recover-kb --source=backup
|
||||
|
||||
# Rebuild search indices
|
||||
bmad rebuild-indices --all
|
||||
|
||||
# Validate data integrity
|
||||
bmad validate-data --comprehensive
|
||||
```
|
||||
|
||||
## Getting Help
|
||||
|
||||
### Self-Service Resources
|
||||
|
||||
1. **Documentation**: Check the comprehensive documentation at `/docs/`
|
||||
2. **FAQ**: Review frequently asked questions
|
||||
3. **Community Forums**: Search community discussions
|
||||
4. **Video Tutorials**: Watch step-by-step guides
|
||||
|
||||
### Support Channels
|
||||
|
||||
1. **GitHub Issues**: Report bugs and feature requests
|
||||
2. **Community Discord**: Get help from other users
|
||||
3. **Email Support**: Contact support team directly
|
||||
4. **Professional Services**: Engage for complex implementations
|
||||
|
||||
### Reporting Issues
|
||||
|
||||
When reporting issues, include:
|
||||
|
||||
1. **System Information:**
|
||||
```bash
|
||||
bmad system-info --export
|
||||
```
|
||||
|
||||
2. **Error Logs:**
|
||||
```bash
|
||||
bmad logs --level=error --last=24h --export
|
||||
```
|
||||
|
||||
3. **Configuration Details:**
|
||||
```bash
|
||||
bmad config-export --sanitized
|
||||
```
|
||||
|
||||
4. **Reproduction Steps:**
|
||||
- Detailed steps to reproduce the issue
|
||||
- Expected vs. actual behavior
|
||||
- Screenshots or recordings if applicable
|
||||
|
||||
---
|
||||
|
||||
*Effective troubleshooting ensures smooth BMAD system operation and minimizes downtime.*
|
||||
|
|
@ -0,0 +1,206 @@
|
|||
# IDE Setup Guides for BMAD Method
|
||||
|
||||
This directory contains comprehensive guides for using the BMAD Method across different Integrated Development Environments (IDEs) and AI-powered coding assistants.
|
||||
|
||||
## Overview
|
||||
|
||||
The BMAD Method integrates with IDEs through **methodology application** rather than software installation. These guides explain how to effectively use BMAD documentation, personas, and workflows within your preferred development environment.
|
||||
|
||||
## Available Setup Guides
|
||||
|
||||
### AI-Powered IDEs
|
||||
- **[Cursor AI Setup](cursor-ai-setup.md)** - Complete methodology integration guide for Cursor AI
|
||||
- **[Cline Setup](cline-setup.md)** - Terminal-focused BMAD integration for Cline
|
||||
- **[Claude Code Setup](claude-code-setup.md)** - Code quality focused integration for Claude Code
|
||||
- **[Roocode Setup](roocode-setup.md)** - Visual development integration for Roocode
|
||||
|
||||
### Traditional IDEs with AI Integration
|
||||
- **[Visual Studio Code Setup](vscode-setup.md)** - VS Code integration with GitHub Copilot and AI extensions
|
||||
- **[JetBrains IDEs Setup](jetbrains-setup.md)** - Integration for IntelliJ IDEA, WebStorm, PyCharm, and others
|
||||
|
||||
## Integration Approach
|
||||
|
||||
### Core Principles
|
||||
The BMAD Method integrates through:
|
||||
|
||||
1. **Documentation Loading** - Loading persona and task files into AI assistant context
|
||||
2. **Prompt Structuring** - Using BMAD patterns to structure AI interactions
|
||||
3. **Template Application** - Applying BMAD templates as guidance frameworks
|
||||
4. **Quality Validation** - Following checklists for methodology compliance
|
||||
|
||||
### Integration Architecture
|
||||
```mermaid
|
||||
graph TD
|
||||
A[BMAD Documentation] --> B[IDE Environment]
|
||||
B --> C[AI Assistant]
|
||||
C --> D[Structured Prompts]
|
||||
D --> E[Quality Outputs]
|
||||
|
||||
F[Templates] --> B
|
||||
G[Checklists] --> B
|
||||
H[Personas] --> B
|
||||
```
|
||||
|
||||
## Quick Start Comparison
|
||||
|
||||
| IDE | AI Integration | Setup Complexity | Best For |
|
||||
|-----|----------------|------------------|----------|
|
||||
| Cursor AI | Native | Low | General development with comprehensive AI assistance |
|
||||
| Cline | Native | Low | Terminal-heavy workflows and command-line operations |
|
||||
| Claude Code | Native | Low | Code quality focus and best practices enforcement |
|
||||
| Roocode | Native | Medium | Visual/UI development and rapid prototyping |
|
||||
| VS Code | Plugin-based | Medium | Flexible development with extensive customization |
|
||||
| JetBrains | Plugin-based | High | Enterprise development and advanced tooling |
|
||||
|
||||
## General Setup Requirements
|
||||
|
||||
### Prerequisites
|
||||
1. **BMAD Method Repository**
|
||||
```bash
|
||||
git clone https://github.com/bmadcode/BMAD-METHOD.git
|
||||
```
|
||||
|
||||
2. **Basic Understanding**
|
||||
- Familiarity with your chosen IDE
|
||||
- Understanding of BMAD Method personas and workflows
|
||||
- Basic knowledge of AI-assisted development
|
||||
|
||||
### Common Setup Steps
|
||||
1. **Clone Repository** - Get the BMAD Method documentation
|
||||
2. **Workspace Setup** - Configure IDE to access BMAD files
|
||||
3. **Context Preparation** - Load relevant documentation into AI context
|
||||
4. **Persona Activation** - Test methodology application
|
||||
5. **Workflow Integration** - Integrate BMAD patterns into your development process
|
||||
|
||||
## Methodology Integration Patterns
|
||||
|
||||
### 1. Direct Documentation Loading
|
||||
```
|
||||
Load [persona-name] from bmad-agent/personas/[persona-file].md
|
||||
Apply [task-name] from bmad-agent/tasks/[task-file].md
|
||||
Use [template-name] from bmad-agent/templates/[template-file].md
|
||||
```
|
||||
|
||||
### 2. Structured Prompt Framework
|
||||
```
|
||||
Acting as [persona] from BMAD Method:
|
||||
- Task: [specific task]
|
||||
- Context: [project context]
|
||||
- Template: [template reference]
|
||||
- Quality: [checklist reference]
|
||||
```
|
||||
|
||||
### 3. Workflow Integration
|
||||
```
|
||||
Phase 1: Requirements (PM Persona)
|
||||
Phase 2: Architecture (Architect Persona)
|
||||
Phase 3: Implementation (Developer Persona)
|
||||
Phase 4: Quality Assurance (All Personas)
|
||||
```
|
||||
|
||||
## Choosing the Right IDE
|
||||
|
||||
### For Beginners
|
||||
- **Cursor AI**: Easiest methodology integration with excellent AI support
|
||||
- **Claude Code**: Great for learning BMAD best practices
|
||||
|
||||
### For Experienced Developers
|
||||
- **VS Code**: Maximum flexibility and extensive customization options
|
||||
- **JetBrains IDEs**: Advanced features and enterprise-grade tooling
|
||||
|
||||
### For Specific Use Cases
|
||||
- **UI/UX Development**: Roocode or Cursor AI with v0 integration
|
||||
- **Terminal-Heavy Work**: Cline with command-line focus
|
||||
- **Code Quality Focus**: Claude Code with quality emphasis
|
||||
- **Team Collaboration**: JetBrains IDEs or VS Code with team features
|
||||
|
||||
## Best Practices Across All IDEs
|
||||
|
||||
### Documentation Management
|
||||
- Keep BMAD files organized and accessible
|
||||
- Maintain consistent file structure across projects
|
||||
- Version control BMAD outputs and customizations
|
||||
|
||||
### Context Management
|
||||
- Load relevant personas before starting tasks
|
||||
- Maintain project context throughout development phases
|
||||
- Reference appropriate templates and checklists consistently
|
||||
|
||||
### Quality Assurance
|
||||
- Use BMAD quality checklists for all deliverables
|
||||
- Conduct regular methodology compliance reviews
|
||||
- Validate outputs against BMAD standards
|
||||
|
||||
### Team Collaboration
|
||||
- Share BMAD setup and customizations with team members
|
||||
- Establish common persona usage patterns
|
||||
- Document project-specific methodology adaptations
|
||||
|
||||
## Troubleshooting Common Issues
|
||||
|
||||
### Context-Related Issues
|
||||
**Problem**: AI assistant doesn't understand BMAD methodology
|
||||
**Solution**: Explicitly load persona documentation and reference specific files
|
||||
|
||||
**Problem**: Inconsistent output quality across team members
|
||||
**Solution**: Standardize BMAD setup and provide team training on methodology application
|
||||
|
||||
### Integration Issues
|
||||
**Problem**: Difficulty switching between personas
|
||||
**Solution**: Create standardized persona activation prompts and maintain context files
|
||||
|
||||
**Problem**: Template application inconsistencies
|
||||
**Solution**: Reference specific template files and provide concrete examples
|
||||
|
||||
### Performance Issues
|
||||
**Problem**: Slow AI responses with large BMAD context
|
||||
**Solution**: Load only relevant documentation for current tasks and optimize context size
|
||||
|
||||
## Advanced Integration Techniques
|
||||
|
||||
### Multi-Persona Workflows
|
||||
- Plan persona transitions for complex projects
|
||||
- Maintain context continuity across persona switches
|
||||
- Document handoff procedures between personas
|
||||
|
||||
### Custom Template Creation
|
||||
- Adapt BMAD templates for specific project needs
|
||||
- Create organization-specific template variations
|
||||
- Maintain template version control and updates
|
||||
|
||||
### Quality Automation
|
||||
- Integrate BMAD checklists into CI/CD pipelines
|
||||
- Automate quality validation where possible
|
||||
- Create custom quality metrics based on BMAD standards
|
||||
|
||||
## Getting Help
|
||||
|
||||
### Resources
|
||||
1. **Documentation**: [BMAD Method Documentation](https://github.com/bmadcode/BMAD-METHOD/docs)
|
||||
2. **Community**: [GitHub Discussions](https://github.com/bmadcode/BMAD-METHOD/discussions)
|
||||
3. **Issues**: [GitHub Issues](https://github.com/bmadcode/BMAD-METHOD/issues)
|
||||
|
||||
### Support Channels
|
||||
- Check IDE-specific setup guides for detailed instructions
|
||||
- Review troubleshooting sections for common solutions
|
||||
- Engage with the BMAD Method community for advanced questions
|
||||
|
||||
## Contributing
|
||||
|
||||
### Adding New IDE Guides
|
||||
1. Follow the established template structure
|
||||
2. Include setup, usage, troubleshooting, and best practices sections
|
||||
3. Test the guide with a fresh IDE installation
|
||||
4. Submit a pull request with comprehensive documentation
|
||||
|
||||
### Improving Existing Guides
|
||||
1. Test improvements with real-world usage scenarios
|
||||
2. Gather feedback from community members
|
||||
3. Update documentation to reflect current best practices
|
||||
4. Maintain backward compatibility where possible
|
||||
|
||||
## Conclusion
|
||||
|
||||
The BMAD Method's IDE integration approach focuses on methodology application rather than technical installation. By understanding how to effectively load documentation, structure prompts, and apply quality standards within your chosen IDE, you can leverage the full power of the BMAD Method to improve your development process and deliverable quality.
|
||||
|
||||
Choose the IDE that best fits your workflow and team needs, then follow the specific setup guide to begin applying BMAD methodology principles in your development environment.
|
||||
|
|
@ -43,6 +43,36 @@ For optimal results, provide the following context:
|
|||
- Share your package.json or describe your tech stack
|
||||
- Highlight any specific libraries or frameworks you're using
|
||||
|
||||
## Advanced Configuration
|
||||
|
||||
### Claude Code Settings
|
||||
Configure these settings for optimal BMAD integration:
|
||||
```json
|
||||
{
|
||||
"claude.contextWindow": "maximum",
|
||||
"claude.codeQuality": "high",
|
||||
"claude.autoSuggest": true,
|
||||
"bmad.personaPath": "./bmad-agent/personas/"
|
||||
}
|
||||
```
|
||||
|
||||
### Project Workspace Setup
|
||||
Create a `.claude/workspace.json` file:
|
||||
```json
|
||||
{
|
||||
"personas": {
|
||||
"default": "v0-ux-ui-architect",
|
||||
"fallback": "dev",
|
||||
"autoSwitch": true
|
||||
},
|
||||
"codeGeneration": {
|
||||
"framework": "react",
|
||||
"styling": "tailwind",
|
||||
"testing": "jest"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Usage Guide
|
||||
|
||||
### Basic Component Creation
|
||||
|
|
@ -108,6 +138,18 @@ For optimal results, provide the following context:
|
|||
- Claude Code can implement current best practices
|
||||
- Try: "Create a data fetching hook using the latest React best practices"
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
### Code Quality Enhancement
|
||||
- Enable real-time code analysis
|
||||
- Use Claude Code's built-in linting integration
|
||||
- Configure automated code formatting
|
||||
|
||||
### Best Practices for BMAD Integration
|
||||
- Always specify the target persona at conversation start
|
||||
- Use Claude Code's project understanding features
|
||||
- Leverage code context for better persona responses
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
|
|
|||
|
|
@ -43,6 +43,27 @@ For optimal results, provide the following context:
|
|||
- Share your package.json or describe your tech stack
|
||||
- Highlight any specific libraries or frameworks you're using
|
||||
|
||||
## Advanced Configuration
|
||||
|
||||
### Environment Variables
|
||||
Set these environment variables for optimal Cline integration:
|
||||
```bash
|
||||
export BMAD_PERSONA_PATH="/path/to/BMAD-METHOD/bmad-agent/personas"
|
||||
export BMAD_AUTO_ACTIVATE="true"
|
||||
export CLINE_CONTEXT_SIZE="8192"
|
||||
```
|
||||
|
||||
### Project Configuration
|
||||
Create a `.cline/config.json` file:
|
||||
```json
|
||||
{
|
||||
"defaultPersona": "v0-ux-ui-architect",
|
||||
"autoLoadContext": true,
|
||||
"maxTokens": 8192,
|
||||
"temperature": 0.7
|
||||
}
|
||||
```
|
||||
|
||||
## Usage Guide
|
||||
|
||||
### Basic Component Creation
|
||||
|
|
@ -107,6 +128,13 @@ For optimal results, provide the following context:
|
|||
- Cline can create tests alongside components
|
||||
- Try: "Create a modal component with Jest tests"
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
### Terminal Integration Best Practices
|
||||
- Use relative paths when referencing BMAD files
|
||||
- Leverage Cline's file watching capabilities
|
||||
- Set up automated persona switching based on file types
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
|
@ -123,6 +151,11 @@ For optimal results, provide the following context:
|
|||
- **Problem**: Cline can't create new files
|
||||
- **Solution**: Check your IDE permissions and settings
|
||||
|
||||
### Debugging Setup Issues
|
||||
- Check file permissions on BMAD-METHOD directory
|
||||
- Verify API key configuration
|
||||
- Test persona activation with simple commands first
|
||||
|
||||
### Getting Help
|
||||
|
||||
If you encounter issues with the v0-UX/UI Architect persona in Cline:
|
||||
|
|
|
|||
|
|
@ -1,142 +1,236 @@
|
|||
# Setting Up v0-UX/UI Architect in Cursor AI
|
||||
# Setting Up BMAD Method in Cursor AI
|
||||
|
||||
This guide will help you set up and use the v0-UX/UI Architect persona in Cursor AI for efficient frontend development.
|
||||
This guide explains how to effectively use the BMAD Method within Cursor AI through documentation loading and structured prompt techniques.
|
||||
|
||||
## Setup Instructions
|
||||
## Overview
|
||||
|
||||
### 1. Initial Setup
|
||||
The BMAD Method integrates with Cursor AI through **methodology application** rather than software installation. This involves loading BMAD documentation into your workspace and structuring your AI interactions using BMAD principles.
|
||||
|
||||
1. **Clone the BMAD-Method Repository**
|
||||
## Setup Process
|
||||
|
||||
### 1. Workspace Preparation
|
||||
|
||||
**Clone BMAD Repository:**
|
||||
```bash
|
||||
git clone https://github.com/bmadcode/BMAD-METHOD.git
|
||||
cd BMAD-METHOD
|
||||
```
|
||||
|
||||
2. **Open in Cursor AI**
|
||||
**Open in Cursor AI:**
|
||||
- Launch Cursor AI
|
||||
- Open the cloned BMAD-METHOD folder
|
||||
- Navigate to `bmad-agent/personas/v0-ux-ui-architect.ide.md`
|
||||
- Open the BMAD-METHOD folder as your workspace
|
||||
- Ensure Cursor has access to read all documentation files
|
||||
|
||||
3. **Configure Cursor AI**
|
||||
- Open Cursor AI settings
|
||||
- Under AI settings, ensure "File System Access" is enabled
|
||||
- Set context window to maximum available size
|
||||
### 2. Documentation Loading Strategy
|
||||
|
||||
### 2. Persona Activation
|
||||
**Essential Files to Reference:**
|
||||
- `bmad-agent/personas/` - Core persona definitions
|
||||
- `bmad-agent/tasks/` - Task libraries and workflows
|
||||
- `bmad-agent/templates/` - Document templates
|
||||
- `bmad-agent/checklists/` - Quality validation checklists
|
||||
|
||||
1. **Direct File Method**
|
||||
- Open `bmad-agent/personas/v0-ux-ui-architect.ide.md` in Cursor
|
||||
- Use the "Ask AI about this file" feature
|
||||
- Type: "Embody this persona for my project"
|
||||
**Context Management:**
|
||||
- Keep relevant persona files open in tabs
|
||||
- Reference task definitions when starting new work
|
||||
- Use templates as starting points for deliverables
|
||||
|
||||
2. **IDE Orchestrator Method**
|
||||
- Open `bmad-agent/ide-bmad-orchestrator.md`
|
||||
- Use the "Ask AI about this file" feature
|
||||
- Type: "Activate the v0-UX/UI Architect persona"
|
||||
### 3. Persona Activation Technique
|
||||
|
||||
### 3. Project Context Setup
|
||||
|
||||
For optimal results, provide the following context:
|
||||
|
||||
1. **Project Structure Overview**
|
||||
**Basic Activation Pattern:**
|
||||
```
|
||||
/src
|
||||
/components
|
||||
/styles
|
||||
/pages
|
||||
package.json
|
||||
Load the [persona name] from bmad-agent/personas/[persona-file].md
|
||||
I need help with [specific task] following BMAD methodology.
|
||||
Use the [template name] template and apply [checklist name] quality standards.
|
||||
```
|
||||
|
||||
2. **Tech Stack Information**
|
||||
- Frontend framework (React, Vue, etc.)
|
||||
- Styling approach (Tailwind, CSS-in-JS, etc.)
|
||||
- State management solution
|
||||
- Testing framework
|
||||
|
||||
## Usage Guide
|
||||
|
||||
### Basic Component Creation
|
||||
|
||||
1. **Simple Component Request**
|
||||
**Example Activation:**
|
||||
```
|
||||
Create a responsive card component with:
|
||||
- Image
|
||||
- Title
|
||||
- Description
|
||||
- Action button
|
||||
Load the Product Manager persona from bmad-agent/personas/pm.md
|
||||
I need help creating a PRD for a new user authentication feature.
|
||||
Use the PRD template and apply the PM quality checklist.
|
||||
```
|
||||
|
||||
2. **Component with Variants**
|
||||
## Usage Workflows
|
||||
|
||||
### Project Initiation Workflow
|
||||
|
||||
1. **Load Project Context:**
|
||||
- Open relevant BMAD documentation in Cursor
|
||||
- Prepare project requirements and constraints
|
||||
- Identify which personas you'll need
|
||||
|
||||
2. **Activate Primary Persona:**
|
||||
```
|
||||
Create a button component with:
|
||||
- Primary, secondary, and tertiary variants
|
||||
- Different sizes (sm, md, lg)
|
||||
- Loading state
|
||||
- Disabled state
|
||||
Acting as John (Product Manager) from BMAD Method, help me define
|
||||
requirements for [project description]. Reference the PRD template
|
||||
and follow PM quality standards.
|
||||
```
|
||||
|
||||
### Advanced Usage
|
||||
3. **Generate Initial Deliverables:**
|
||||
- Use persona-specific templates
|
||||
- Apply quality checklists for validation
|
||||
- Iterate based on feedback
|
||||
|
||||
1. **Design System Integration**
|
||||
### Feature Development Workflow
|
||||
|
||||
1. **Requirements Analysis (PM Persona):**
|
||||
```
|
||||
Create a modal component that follows our existing design system.
|
||||
It should have a header, body, footer, and close button.
|
||||
Load John (PM) persona. Analyze these requirements: [requirements]
|
||||
Create user stories following the story template.
|
||||
```
|
||||
|
||||
2. **Multi-Component Creation**
|
||||
2. **Architecture Design (Architect Persona):**
|
||||
```
|
||||
Create a form with:
|
||||
- Text input
|
||||
- Dropdown select
|
||||
- Checkbox group
|
||||
- Submit button
|
||||
All components should be reusable and follow accessibility best practices.
|
||||
Load Fred (Architect) persona. Based on these requirements: [requirements]
|
||||
Design system architecture using the architecture template.
|
||||
```
|
||||
|
||||
3. **Component Refactoring**
|
||||
3. **Implementation Planning (Developer Persona):**
|
||||
```
|
||||
Refactor this existing component to use Tailwind CSS and improve performance:
|
||||
[paste component code]
|
||||
Load David (Developer) persona. Based on this architecture: [architecture]
|
||||
Create implementation plan following development best practices.
|
||||
```
|
||||
|
||||
### Cursor-Specific Tips
|
||||
### Design System Creation Workflow
|
||||
|
||||
1. **Use Split View**
|
||||
- Keep the persona file open in one panel
|
||||
- Work on your components in another panel
|
||||
1. **UX/UI Planning (UX/UI Architect):**
|
||||
```
|
||||
Load Veronica (UX/UI Architect) persona. Create design system
|
||||
components for [project]. Use v0 component specifications.
|
||||
```
|
||||
|
||||
2. **Leverage File Creation**
|
||||
- Ask the persona to create multiple files at once
|
||||
- Example: "Create a Button component with its test file and story"
|
||||
2. **Component Implementation:**
|
||||
```
|
||||
Following the UX/UI specifications, implement these components
|
||||
using React and Tailwind CSS. Apply component quality checklist.
|
||||
```
|
||||
|
||||
3. **Context Refreshing**
|
||||
- If the persona seems to lose context, type "Refresh project context"
|
||||
- This will prompt it to re-analyze your project structure
|
||||
## Advanced Techniques
|
||||
|
||||
4. **Command Palette Integration**
|
||||
- Use Cursor's command palette to quickly invoke the persona
|
||||
- Create custom commands for common requests
|
||||
### Multi-Persona Collaboration
|
||||
|
||||
**Handoff Pattern:**
|
||||
```
|
||||
Transition from [current persona] to [next persona].
|
||||
Context: [previous deliverable]
|
||||
Next task: [specific task for new persona]
|
||||
Maintain consistency with previous work.
|
||||
```
|
||||
|
||||
**Example Handoff:**
|
||||
```
|
||||
Transition from John (PM) to Fred (Architect).
|
||||
Context: PRD for user authentication system
|
||||
Next task: Design secure authentication architecture
|
||||
Maintain consistency with PRD requirements.
|
||||
```
|
||||
|
||||
### Context Preservation
|
||||
|
||||
**Session Management:**
|
||||
- Save important outputs as reference files
|
||||
- Maintain project context across sessions
|
||||
- Use consistent naming conventions
|
||||
|
||||
**Context Refresh:**
|
||||
```
|
||||
Refresh project context:
|
||||
- Project: [project name]
|
||||
- Current phase: [development phase]
|
||||
- Active persona: [persona name]
|
||||
- Last deliverable: [deliverable summary]
|
||||
```
|
||||
|
||||
### Quality Validation
|
||||
|
||||
**Checklist Application:**
|
||||
```
|
||||
Validate this [deliverable type] against the [checklist name]:
|
||||
[paste deliverable content]
|
||||
Provide improvement recommendations.
|
||||
```
|
||||
|
||||
**Peer Review Simulation:**
|
||||
```
|
||||
Acting as [different persona], review this [deliverable] created by [original persona].
|
||||
Provide feedback and suggestions for improvement.
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Documentation Organization
|
||||
- Keep BMAD files organized in your workspace
|
||||
- Create project-specific folders for outputs
|
||||
- Maintain version control for generated content
|
||||
|
||||
### Prompt Structuring
|
||||
- Always specify the persona you're activating
|
||||
- Reference specific templates and checklists
|
||||
- Provide clear context and requirements
|
||||
|
||||
### Quality Assurance
|
||||
- Use BMAD quality checklists consistently
|
||||
- Validate outputs against methodology standards
|
||||
- Conduct regular methodology compliance reviews
|
||||
|
||||
### Team Collaboration
|
||||
- Share BMAD workspace setup with team members
|
||||
- Establish common persona usage patterns
|
||||
- Document project-specific methodology adaptations
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
### Common Issues and Solutions
|
||||
|
||||
1. **Limited Context Understanding**
|
||||
- **Problem**: Persona doesn't understand your project structure
|
||||
- **Solution**: Provide a brief overview of key directories and files
|
||||
**Issue: Persona Not Responding Correctly**
|
||||
- **Solution**: Ensure persona file is loaded and referenced explicitly
|
||||
- **Check**: Verify you're using the correct persona name and file path
|
||||
|
||||
2. **Incomplete Implementation**
|
||||
- **Problem**: Generated components are missing features
|
||||
- **Solution**: Be more specific in your requirements and provide examples
|
||||
**Issue: Inconsistent Output Quality**
|
||||
- **Solution**: Always reference appropriate quality checklists
|
||||
- **Check**: Confirm you're following the complete workflow for the persona
|
||||
|
||||
3. **Style Inconsistencies**
|
||||
- **Problem**: Generated components don't match your design system
|
||||
- **Solution**: Point to existing components as reference or provide design tokens
|
||||
**Issue: Context Loss During Long Sessions**
|
||||
- **Solution**: Regularly refresh context with key project information
|
||||
- **Check**: Reload persona documentation periodically
|
||||
|
||||
### Getting Help
|
||||
**Issue: Unclear Task Assignment**
|
||||
- **Solution**: Reference the task library for persona-specific capabilities
|
||||
- **Check**: Ensure you're using the right persona for the task type
|
||||
|
||||
If you encounter issues with the v0-UX/UI Architect persona in Cursor AI:
|
||||
### Performance Optimization
|
||||
|
||||
1. Check the [BMAD-Method documentation](https://github.com/bmadcode/BMAD-METHOD/docs)
|
||||
2. Join the [BMAD-Method community](https://github.com/bmadcode/BMAD-METHOD/discussions)
|
||||
3. Submit an issue on [GitHub](https://github.com/bmadcode/BMAD-METHOD/issues)
|
||||
**Memory Management:**
|
||||
- Close unnecessary files to maintain performance
|
||||
- Focus on relevant documentation for current tasks
|
||||
- Clear chat history when switching between major project phases
|
||||
|
||||
**Response Quality:**
|
||||
- Provide specific, detailed requirements
|
||||
- Reference concrete examples when possible
|
||||
- Use iterative refinement for complex deliverables
|
||||
|
||||
## Integration with Other Tools
|
||||
|
||||
### Version Control Integration
|
||||
```bash
|
||||
# Save BMAD outputs to version control
|
||||
git add docs/bmad-outputs/
|
||||
git commit -m "Add BMAD methodology outputs for [feature]"
|
||||
```
|
||||
|
||||
### Documentation Systems
|
||||
- Export BMAD outputs to your documentation platform
|
||||
- Maintain links between BMAD templates and final documentation
|
||||
- Use consistent formatting across all outputs
|
||||
|
||||
### Project Management Tools
|
||||
- Create tasks based on BMAD persona workflows
|
||||
- Use BMAD quality checklists as acceptance criteria
|
||||
- Track methodology compliance in project metrics
|
||||
|
||||
## Conclusion
|
||||
|
||||
The BMAD Method in Cursor AI provides a powerful framework for structured, high-quality development work. By following these setup and usage patterns, you can leverage the full potential of BMAD methodology to improve your development process and deliverable quality.
|
||||
|
||||
Remember that BMAD is a methodology framework - its power comes from consistent application of its principles rather than technical configuration. Focus on understanding the personas, following the workflows, and applying the quality standards to achieve the best results.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,154 @@
|
|||
# Setting Up BMAD Method in JetBrains IDEs
|
||||
|
||||
This guide covers setup for JetBrains IDEs including IntelliJ IDEA, WebStorm, PyCharm, and others.
|
||||
|
||||
## Setup Instructions
|
||||
|
||||
### 1. Initial Setup
|
||||
|
||||
1. **Install AI Assistant Plugin**
|
||||
- Go to `File > Settings > Plugins`
|
||||
- Search for "AI Assistant" or "GitHub Copilot"
|
||||
- Install and restart IDE
|
||||
|
||||
2. **Clone BMAD-Method Repository**
|
||||
```bash
|
||||
git clone https://github.com/bmadcode/BMAD-METHOD.git
|
||||
```
|
||||
|
||||
3. **Configure Project Structure**
|
||||
- Open your project in JetBrains IDE
|
||||
- Add BMAD-METHOD as a module or reference
|
||||
|
||||
### 2. IDE Configuration
|
||||
|
||||
1. **Create Live Templates**
|
||||
- Go to `File > Settings > Editor > Live Templates`
|
||||
- Create new template group "BMAD"
|
||||
- Add templates for persona activation
|
||||
|
||||
2. **Configure File Templates**
|
||||
```xml
|
||||
<!-- .idea/fileTemplates/BMAD Persona Activation.md -->
|
||||
You are now embodying the ${PERSONA_NAME} persona from the BMAD Method.
|
||||
|
||||
Persona file: bmad-agent/personas/${PERSONA_FILE}.md
|
||||
|
||||
Project context: ${PROJECT_CONTEXT}
|
||||
Task: ${TASK_DESCRIPTION}
|
||||
```
|
||||
|
||||
### 3. Persona Integration
|
||||
|
||||
1. **Using AI Assistant**
|
||||
- Open AI Assistant panel
|
||||
- Load persona content from BMAD files
|
||||
- Activate persona with context
|
||||
|
||||
2. **Custom Tool Windows**
|
||||
- Create custom tool window for BMAD personas
|
||||
- Pin frequently used personas
|
||||
- Quick access to persona documentation
|
||||
|
||||
## Usage Guide
|
||||
|
||||
### Basic Workflow
|
||||
|
||||
1. **Persona Activation**
|
||||
```markdown
|
||||
# In AI Assistant
|
||||
Load the following BMAD persona:
|
||||
[Copy content from bmad-agent/personas/v0-ux-ui-architect.md]
|
||||
|
||||
Embody this persona for my current project.
|
||||
```
|
||||
|
||||
2. **Code Generation**
|
||||
- Use persona-specific prompts
|
||||
- Reference project structure
|
||||
- Apply persona methodologies
|
||||
|
||||
### Advanced Features
|
||||
|
||||
1. **Custom Actions**
|
||||
```kotlin
|
||||
// Create custom action for persona switching
|
||||
class ActivateBMADPersonaAction : AnAction() {
|
||||
override fun actionPerformed(e: AnActionEvent) {
|
||||
// Implementation for persona activation
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
2. **Integration with Version Control**
|
||||
- Use JetBrains VCS integration
|
||||
- Create branches for BMAD-generated features
|
||||
- Track persona-driven development
|
||||
|
||||
## JetBrains-Specific Tips
|
||||
|
||||
### 1. Productivity Features
|
||||
- **Code Completion**: Enhanced with persona context
|
||||
- **Refactoring Tools**: Apply persona-recommended patterns
|
||||
- **Debugging**: Use persona troubleshooting approaches
|
||||
|
||||
### 2. Plugin Development
|
||||
- Create custom plugin for BMAD integration
|
||||
- Automate persona switching
|
||||
- Integrate with project templates
|
||||
|
||||
### 3. Team Collaboration
|
||||
- Share BMAD configurations via VCS
|
||||
- Use JetBrains Space for team coordination
|
||||
- Standardize persona usage across team
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
1. **AI Assistant Not Available**
|
||||
- **Problem**: AI features not working
|
||||
- **Solution**: Check plugin installation and API configuration
|
||||
|
||||
2. **Performance Issues**
|
||||
- **Problem**: IDE running slowly with BMAD integration
|
||||
- **Solution**: Optimize memory settings and disable unused plugins
|
||||
|
||||
3. **File Access Issues**
|
||||
- **Problem**: Cannot access BMAD persona files
|
||||
- **Solution**: Check file permissions and project structure
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Project Organization**
|
||||
- Use JetBrains project structure effectively
|
||||
- Organize BMAD personas in dedicated module
|
||||
- Maintain consistent naming conventions
|
||||
|
||||
2. **Code Quality**
|
||||
- Use built-in code inspections
|
||||
- Apply persona-recommended coding standards
|
||||
- Leverage JetBrains refactoring tools
|
||||
|
||||
3. **Team Workflow**
|
||||
- Share BMAD configurations via version control
|
||||
- Standardize persona usage across team
|
||||
- Use JetBrains collaboration features
|
||||
|
||||
## Getting Help
|
||||
|
||||
For JetBrains-specific BMAD Method issues:
|
||||
|
||||
1. Check [JetBrains documentation](https://www.jetbrains.com/help/)
|
||||
2. Visit [BMAD-Method repository](https://github.com/bmadcode/BMAD-METHOD)
|
||||
3. Join the community discussions
|
||||
4. Submit issues with IDE-specific details
|
||||
|
||||
## Comprehensive IDE Setup Index
|
||||
|
||||
- **IntelliJ IDEA**: Detailed setup guide for IntelliJ IDEA
|
||||
- **WebStorm**: Configuration steps for WebStorm
|
||||
- **PyCharm**: Instructions for PyCharm integration
|
||||
- **Other JetBrains IDEs**: General tips for other JetBrains IDEs
|
||||
|
||||
This index helps users quickly find the setup guide relevant to their JetBrains IDE.
|
||||
|
|
@ -43,6 +43,35 @@ For optimal results, provide the following context:
|
|||
- Share your package.json or describe your tech stack
|
||||
- Highlight any specific libraries or frameworks you're using
|
||||
|
||||
## Advanced Configuration
|
||||
|
||||
### Roocode Visual Settings
|
||||
Configure these settings for optimal visual development:
|
||||
```json
|
||||
{
|
||||
"roocode.visualFeedback": "enhanced",
|
||||
"roocode.componentPreview": "realtime",
|
||||
"roocode.designSystem": "auto-detect",
|
||||
"bmad.visualPersona": "v0-ux-ui-architect"
|
||||
}
|
||||
```
|
||||
|
||||
### Design System Integration
|
||||
Create a `.roocode/design-config.json` file:
|
||||
```json
|
||||
{
|
||||
"designTokens": "./src/tokens/design-tokens.json",
|
||||
"componentLibrary": "./src/components",
|
||||
"personaPreferences": {
|
||||
"v0-ux-ui-architect": {
|
||||
"framework": "react",
|
||||
"styling": "tailwind",
|
||||
"accessibility": "wcag-aa"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Usage Guide
|
||||
|
||||
### Basic Component Creation
|
||||
|
|
@ -107,6 +136,18 @@ For optimal results, provide the following context:
|
|||
- Roocode can help with visual design aspects
|
||||
- Example: "Improve the visual hierarchy of this component"
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
### Visual Rendering Performance
|
||||
- Enable hardware acceleration for component previews
|
||||
- Use Roocode's caching for faster iterations
|
||||
- Configure optimal viewport settings for responsive design
|
||||
|
||||
### Design Workflow Enhancement
|
||||
- Set up automated design token synchronization
|
||||
- Use Roocode's visual diff features for component changes
|
||||
- Enable real-time collaboration features
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
|
|
|||
|
|
@ -0,0 +1,223 @@
|
|||
# Setting Up BMAD Method in Visual Studio Code
|
||||
|
||||
This guide will help you set up and use BMAD Method personas in Visual Studio Code for efficient development workflows.
|
||||
|
||||
## Setup Instructions
|
||||
|
||||
### 1. Initial Setup
|
||||
|
||||
1. **Install Required Extensions**
|
||||
```bash
|
||||
# Install GitHub Copilot (recommended)
|
||||
code --install-extension GitHub.copilot
|
||||
|
||||
# Install useful extensions for BMAD workflow
|
||||
code --install-extension ms-vscode.vscode-json
|
||||
code --install-extension bradlc.vscode-tailwindcss
|
||||
code --install-extension esbenp.prettier-vscode
|
||||
```
|
||||
|
||||
2. **Clone the BMAD-Method Repository**
|
||||
```bash
|
||||
git clone https://github.com/bmadcode/BMAD-METHOD.git
|
||||
cd BMAD-METHOD
|
||||
code .
|
||||
```
|
||||
|
||||
3. **Configure VS Code Workspace**
|
||||
- Create `.vscode/settings.json` in your project root
|
||||
- Configure workspace-specific settings for BMAD integration
|
||||
|
||||
### 2. Workspace Configuration
|
||||
|
||||
Create a `.vscode/settings.json` file:
|
||||
```json
|
||||
{
|
||||
"bmad.personaPath": "./bmad-agent/personas/",
|
||||
"bmad.defaultPersona": "v0-ux-ui-architect",
|
||||
"bmad.autoActivate": true,
|
||||
"files.associations": {
|
||||
"*.md": "markdown"
|
||||
},
|
||||
"markdown.preview.breaks": true,
|
||||
"editor.wordWrap": "on"
|
||||
}
|
||||
```
|
||||
|
||||
Create a `.vscode/tasks.json` file:
|
||||
```json
|
||||
{
|
||||
"version": "2.0.0",
|
||||
"tasks": [
|
||||
{
|
||||
"label": "Activate BMAD Persona",
|
||||
"type": "shell",
|
||||
"command": "echo",
|
||||
"args": ["Activating BMAD persona..."],
|
||||
"group": "build",
|
||||
"presentation": {
|
||||
"echo": true,
|
||||
"reveal": "always",
|
||||
"focus": false,
|
||||
"panel": "shared"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Persona Integration
|
||||
|
||||
Since VS Code doesn't have built-in AI chat, you'll need to use external AI tools:
|
||||
|
||||
1. **GitHub Copilot Integration**
|
||||
- Use Copilot Chat to interact with BMAD personas
|
||||
- Copy persona content into chat context
|
||||
- Reference persona files when asking for assistance
|
||||
|
||||
2. **External AI Tool Integration**
|
||||
- Use VS Code as your editor
|
||||
- Copy persona content to external AI tools (ChatGPT, Claude, etc.)
|
||||
- Implement generated code back in VS Code
|
||||
|
||||
### 4. Workflow Setup
|
||||
|
||||
1. **File Organization**
|
||||
```
|
||||
your-project/
|
||||
├── .vscode/
|
||||
│ ├── settings.json
|
||||
│ └── tasks.json
|
||||
├── BMAD-METHOD/
|
||||
│ └── bmad-agent/personas/
|
||||
└── src/
|
||||
```
|
||||
|
||||
2. **Persona Activation Workflow**
|
||||
- Open the desired persona file from `bmad-agent/personas/`
|
||||
- Copy the persona content
|
||||
- Use with your preferred AI tool (Copilot Chat, external AI)
|
||||
- Implement solutions back in VS Code
|
||||
|
||||
## Usage Guide
|
||||
|
||||
### Basic Workflow
|
||||
|
||||
1. **Project Setup**
|
||||
```bash
|
||||
# Open your project in VS Code
|
||||
code your-project
|
||||
|
||||
# Open BMAD personas in a separate window
|
||||
code BMAD-METHOD/bmad-agent/personas/
|
||||
```
|
||||
|
||||
2. **Persona Activation**
|
||||
- Open the desired persona file (e.g., `v0-ux-ui-architect.md`)
|
||||
- Copy the persona content
|
||||
- Paste into GitHub Copilot Chat or external AI tool
|
||||
- Add: "Embody this persona for my project"
|
||||
|
||||
### Advanced Usage
|
||||
|
||||
1. **Multi-Persona Workflow**
|
||||
- Keep multiple persona files open in tabs
|
||||
- Switch between personas based on task type
|
||||
- Use VS Code's split view for persona reference
|
||||
|
||||
2. **Code Generation Workflow**
|
||||
- Reference persona capabilities when requesting code
|
||||
- Use VS Code's integrated terminal for running generated commands
|
||||
- Leverage VS Code's Git integration for version control
|
||||
|
||||
## VS Code-Specific Tips
|
||||
|
||||
### 1. Leverage Built-in Features
|
||||
- **Integrated Terminal**: Run BMAD-generated commands directly
|
||||
- **Git Integration**: Version control for BMAD-generated code
|
||||
- **Extensions Marketplace**: Install relevant extensions for your tech stack
|
||||
|
||||
### 2. Workspace Management
|
||||
- **Multi-root Workspaces**: Keep BMAD-METHOD and your project in same workspace
|
||||
- **Settings Sync**: Sync BMAD configurations across devices
|
||||
- **Snippets**: Create code snippets for common BMAD patterns
|
||||
|
||||
### 3. Productivity Enhancements
|
||||
- **Command Palette**: Quick access to BMAD-related tasks
|
||||
- **Keyboard Shortcuts**: Set up shortcuts for persona switching
|
||||
- **File Explorer**: Pin frequently used persona files
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
1. **Persona Files Not Found**
|
||||
- **Problem**: Can't locate BMAD persona files
|
||||
- **Solution**: Ensure BMAD-METHOD is cloned and path is correct in settings
|
||||
|
||||
2. **No AI Integration**
|
||||
- **Problem**: VS Code doesn't have built-in AI chat
|
||||
- **Solution**: Use GitHub Copilot or external AI tools with copy-paste workflow
|
||||
|
||||
3. **Workspace Configuration Issues**
|
||||
- **Problem**: Settings not applying correctly
|
||||
- **Solution**: Check `.vscode/settings.json` syntax and restart VS Code
|
||||
|
||||
### Performance Optimization
|
||||
|
||||
1. **File Watching**
|
||||
- Exclude large directories from file watching
|
||||
- Configure `.vscode/settings.json` to ignore unnecessary files
|
||||
|
||||
2. **Extension Management**
|
||||
- Only install necessary extensions
|
||||
- Disable unused extensions for better performance
|
||||
|
||||
## Integration with External AI Tools
|
||||
|
||||
### GitHub Copilot
|
||||
```markdown
|
||||
# In Copilot Chat
|
||||
I'm using the BMAD Method. Please embody this persona:
|
||||
|
||||
[Paste persona content here]
|
||||
|
||||
Now help me with: [your request]
|
||||
```
|
||||
|
||||
### ChatGPT/Claude
|
||||
```markdown
|
||||
# Copy this template
|
||||
You are now embodying a BMAD Method persona:
|
||||
|
||||
[Paste persona content]
|
||||
|
||||
Project context: [describe your project]
|
||||
Task: [describe what you need help with]
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **File Organization**
|
||||
- Keep BMAD personas easily accessible
|
||||
- Use VS Code workspaces for project organization
|
||||
- Maintain consistent folder structure
|
||||
|
||||
2. **Workflow Efficiency**
|
||||
- Create templates for common persona activation
|
||||
- Use VS Code snippets for repetitive tasks
|
||||
- Leverage keyboard shortcuts for faster workflow
|
||||
|
||||
3. **Code Quality**
|
||||
- Use VS Code's built-in linting and formatting
|
||||
- Integrate with your preferred code quality tools
|
||||
- Follow BMAD persona recommendations for code standards
|
||||
|
||||
## Getting Help
|
||||
|
||||
If you encounter issues with BMAD Method in VS Code:
|
||||
|
||||
1. Check the [BMAD-Method documentation](https://github.com/bmadcode/BMAD-METHOD/docs)
|
||||
2. Join the [BMAD-Method community](https://github.com/bmadcode/BMAD-METHOD/discussions)
|
||||
3. Submit an issue on [GitHub](https://github.com/bmadcode/BMAD-METHOD/issues)
|
||||
4. Check VS Code's [official documentation](https://code.visualstudio.com/docs)
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 99 KiB After Width: | Height: | Size: 0 B |
|
|
@ -0,0 +1,178 @@
|
|||
# Persona Documentation Audit Report
|
||||
|
||||
## Audit Overview
|
||||
**Date**: Current Date
|
||||
**Auditor**: David - Developer
|
||||
**Purpose**: Assess current state of persona documentation to establish standardization requirements
|
||||
|
||||
## Current Persona Documentation Status
|
||||
|
||||
### ✅ Well-Documented Personas
|
||||
|
||||
#### v0 UX/UI Architect
|
||||
- **Status**: ✅ COMPLETE - Recently standardized
|
||||
- **Files**:
|
||||
- `bmad-agent/personas/v0-ux-ui-architect.md` (Web version)
|
||||
- `bmad-agent/personas/v0-ux-ui-architect.ide.md` (IDE version)
|
||||
- **Documentation Quality**: Excellent
|
||||
- **Integration Guides**: Complete
|
||||
- **Examples**: Multiple examples available
|
||||
|
||||
### 🔶 Partially Documented Personas
|
||||
|
||||
#### Business Analyst (Mary)
|
||||
- **Status**: 🔶 PARTIAL
|
||||
- **Files**: `bmad-agent/personas/analyst.md`
|
||||
- **Missing**:
|
||||
- Integration guide
|
||||
- IDE-specific version
|
||||
- Practical examples
|
||||
- Quick-start guide
|
||||
|
||||
#### Product Manager (John)
|
||||
- **Status**: 🔶 PARTIAL
|
||||
- **Files**: `bmad-agent/personas/pm.md`
|
||||
- **Missing**:
|
||||
- Comprehensive user guide
|
||||
- Integration workflows
|
||||
- Template library
|
||||
- Quality assurance checklist
|
||||
|
||||
#### System Architect (Fred)
|
||||
- **Status**: 🔶 PARTIAL
|
||||
- **Files**: `bmad-agent/personas/architect.md`
|
||||
- **Missing**:
|
||||
- Technical integration guide
|
||||
- Architecture template library
|
||||
- Best practices documentation
|
||||
- Tool integration guides
|
||||
|
||||
#### Product Owner (Sarah)
|
||||
- **Status**: 🔶 PARTIAL
|
||||
- **Files**: `bmad-agent/personas/po.md`
|
||||
- **Missing**:
|
||||
- User story templates
|
||||
- Acceptance criteria guides
|
||||
- Stakeholder communication templates
|
||||
- Sprint planning integration
|
||||
|
||||
#### Scrum Master (Mike)
|
||||
- **Status**: 🔶 PARTIAL
|
||||
- **Files**:
|
||||
- `bmad-agent/personas/sm.md` (Web version)
|
||||
- `bmad-agent/personas/sm.ide.md` (IDE version)
|
||||
- **Missing**:
|
||||
- Sprint planning templates
|
||||
- Ceremony facilitation guides
|
||||
- Team management best practices
|
||||
- Metrics and reporting guides
|
||||
|
||||
### 🔴 Minimally Documented Personas
|
||||
|
||||
#### Developer (David)
|
||||
- **Status**: 🔴 MINIMAL
|
||||
- **Files**: `bmad-agent/personas/dev.ide.md`
|
||||
- **Missing**:
|
||||
- Web environment version
|
||||
- Implementation best practices
|
||||
- Code quality standards
|
||||
- Testing methodologies
|
||||
|
||||
#### DevOps Engineer (Alex)
|
||||
- **Status**: 🔴 MINIMAL
|
||||
- **Files**: `bmad-agent/personas/devops-pe.ide.md`
|
||||
- **Missing**:
|
||||
- Infrastructure templates
|
||||
- Deployment guides
|
||||
- Monitoring and alerting setup
|
||||
- Security best practices
|
||||
|
||||
#### Design Architect (Emma)
|
||||
- **Status**: 🔴 MINIMAL
|
||||
- **Files**: `bmad-agent/personas/design-architect.md`
|
||||
- **Missing**:
|
||||
- Design system creation guides
|
||||
- Frontend architecture patterns
|
||||
- Component library management
|
||||
- Design-to-code workflows
|
||||
|
||||
## Standardization Requirements
|
||||
|
||||
### Documentation Structure Template
|
||||
|
||||
Based on the v0 UX/UI Architect documentation, all personas should include:
|
||||
|
||||
1. **Core Documentation**
|
||||
- Comprehensive persona guide
|
||||
- Integration guide
|
||||
- Quality assurance checklist
|
||||
- Quick-start guide
|
||||
|
||||
2. **Practical Resources**
|
||||
- Template library
|
||||
- Example projects
|
||||
- Best practices guide
|
||||
- Troubleshooting guide
|
||||
|
||||
3. **Environment-Specific Versions**
|
||||
- Web environment persona file
|
||||
- IDE environment persona file
|
||||
- Configuration examples
|
||||
|
||||
### Formatting Standards
|
||||
|
||||
- **File Naming**: `{persona-name}-{type}.md`
|
||||
- **Header Structure**: Consistent H1-H6 hierarchy
|
||||
- **Code Blocks**: Proper syntax highlighting
|
||||
- **Links**: Relative links to other documentation
|
||||
- **Tables**: Consistent formatting for comparison data
|
||||
|
||||
### Content Standards
|
||||
|
||||
- **Activation Phrases**: Clear persona activation instructions
|
||||
- **Use Cases**: Specific scenarios for persona usage
|
||||
- **Integration Points**: How persona connects with others
|
||||
- **Quality Metrics**: Success criteria and validation methods
|
||||
|
||||
## Prioritization Matrix
|
||||
|
||||
| Persona | Business Impact | Documentation Gap | Priority |
|
||||
|---------|----------------|-------------------|----------|
|
||||
| Product Manager | High | Medium | High |
|
||||
| System Architect | High | Medium | High |
|
||||
| Product Owner | High | Medium | High |
|
||||
| Developer | Medium | High | High |
|
||||
| Business Analyst | Medium | Medium | Medium |
|
||||
| Scrum Master | Medium | Low | Medium |
|
||||
| Design Architect | Medium | High | Medium |
|
||||
| DevOps Engineer | Low | High | Low |
|
||||
|
||||
## Recommended Implementation Order
|
||||
|
||||
### Phase 1 (Current Sprint)
|
||||
1. **Product Manager (John)** - Critical for project management workflows
|
||||
2. **System Architect (Fred)** - Essential for technical architecture
|
||||
3. **Product Owner (Sarah)** - Key for user story management
|
||||
|
||||
### Phase 2 (Next Sprint)
|
||||
4. **Developer (David)** - Core implementation persona
|
||||
5. **Business Analyst (Mary)** - Important for requirements gathering
|
||||
6. **Design Architect (Emma)** - Frontend architecture specialist
|
||||
|
||||
### Phase 3 (Future Sprint)
|
||||
7. **Scrum Master (Mike)** - Process facilitation
|
||||
8. **DevOps Engineer (Alex)** - Infrastructure and deployment
|
||||
|
||||
## Success Metrics
|
||||
|
||||
- **Documentation Completeness**: 100% of personas have all required documentation
|
||||
- **Consistency Score**: 95% adherence to formatting standards
|
||||
- **User Satisfaction**: 4.5/5 rating on documentation usefulness
|
||||
- **Time to Productivity**: <30 minutes for new users to get started
|
||||
|
||||
---
|
||||
|
||||
This audit provides the foundation for standardizing all persona documentation to match the quality and completeness of the v0 UX/UI Architect documentation.
|
||||
```
|
||||
|
||||
Now let's create the standardization template:
|
||||
|
|
@ -0,0 +1,174 @@
|
|||
# Product Manager (John) - Comprehensive Guide
|
||||
|
||||
## Overview
|
||||
|
||||
John is the Product Manager persona in the BMAD Method, responsible for translating business requirements into detailed product specifications and managing the product development lifecycle.
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
### 1. Product Requirements Definition
|
||||
- **Business Analysis**: Convert stakeholder needs into actionable requirements
|
||||
- **Market Research**: Conduct competitive analysis and user research
|
||||
- **Feature Prioritization**: Use frameworks like MoSCoW and RICE for prioritization
|
||||
- **Roadmap Planning**: Create and maintain product roadmaps
|
||||
|
||||
### 2. Stakeholder Management
|
||||
- **Communication**: Bridge technical and business teams
|
||||
- **Expectation Setting**: Manage stakeholder expectations and timelines
|
||||
- **Feedback Integration**: Collect and synthesize user and stakeholder feedback
|
||||
- **Decision Making**: Make informed product decisions based on data
|
||||
|
||||
### 3. Documentation Creation
|
||||
- **PRD Development**: Create comprehensive Product Requirements Documents
|
||||
- **User Stories**: Write clear, testable user stories with acceptance criteria
|
||||
- **Process Documentation**: Document workflows and decision processes
|
||||
- **Status Reporting**: Provide regular updates on product progress
|
||||
|
||||
## When to Use John (PM Persona)
|
||||
|
||||
### Primary Use Cases
|
||||
1. **New Product Development**: When starting a new product or major feature
|
||||
2. **Requirements Gathering**: When business requirements need clarification
|
||||
3. **Stakeholder Alignment**: When multiple stakeholders need coordination
|
||||
4. **Product Strategy**: When strategic product decisions are needed
|
||||
|
||||
### Trigger Conditions
|
||||
- Business stakeholders have provided initial requirements
|
||||
- Market opportunity has been identified
|
||||
- Technical feasibility needs to be assessed
|
||||
- Product roadmap needs updating
|
||||
|
||||
## Working Process
|
||||
|
||||
### Phase 1: Requirements Analysis
|
||||
1. **Stakeholder Interviews**: Conduct interviews with key stakeholders
|
||||
2. **Market Research**: Analyze competitive landscape and user needs
|
||||
3. **Requirements Documentation**: Document functional and non-functional requirements
|
||||
4. **Initial Prioritization**: Rank requirements by business value and effort
|
||||
|
||||
### Phase 2: Product Definition
|
||||
1. **PRD Creation**: Develop comprehensive Product Requirements Document
|
||||
2. **User Story Writing**: Break down requirements into user stories
|
||||
3. **Acceptance Criteria**: Define clear acceptance criteria for each story
|
||||
4. **Risk Assessment**: Identify and document potential risks
|
||||
|
||||
### Phase 3: Stakeholder Review
|
||||
1. **Review Sessions**: Present PRD to stakeholders for feedback
|
||||
2. **Iteration**: Incorporate feedback and refine requirements
|
||||
3. **Approval**: Obtain stakeholder sign-off on final requirements
|
||||
4. **Handoff**: Prepare documentation for technical teams
|
||||
|
||||
## Integration with BMAD Method
|
||||
|
||||
### Workflow Position
|
||||
- **Follows**: Business Analyst (BA) initial research
|
||||
- **Precedes**: UX/UI Architect design phase
|
||||
- **Collaborates with**: All personas throughout the process
|
||||
|
||||
### Key Handoffs
|
||||
1. **From BA**: Business requirements and market research
|
||||
2. **To UX/UI**: Product requirements and user stories
|
||||
3. **To Architect**: Technical requirements and constraints
|
||||
4. **To PO**: Validated requirements for sprint planning
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Requirements Management
|
||||
- Use clear, measurable acceptance criteria
|
||||
- Maintain traceability between business needs and technical requirements
|
||||
- Regular stakeholder communication and updates
|
||||
- Version control for all requirements documents
|
||||
|
||||
### Communication
|
||||
- Use visual aids (wireframes, flowcharts) to clarify requirements
|
||||
- Maintain a single source of truth for product decisions
|
||||
- Regular check-ins with technical teams
|
||||
- Clear escalation paths for blockers
|
||||
|
||||
### Documentation Standards
|
||||
- Follow consistent template structures
|
||||
- Include rationale for product decisions
|
||||
- Maintain change logs for requirement updates
|
||||
- Use collaborative tools for real-time updates
|
||||
|
||||
## Common Challenges and Solutions
|
||||
|
||||
### Challenge: Unclear Requirements
|
||||
**Solution**: Use structured elicitation techniques like user story mapping and requirements workshops
|
||||
|
||||
### Challenge: Scope Creep
|
||||
**Solution**: Implement change control processes and regular stakeholder reviews
|
||||
|
||||
### Challenge: Technical Feasibility
|
||||
**Solution**: Early collaboration with architects and developers for feasibility assessment
|
||||
|
||||
### Challenge: Conflicting Stakeholder Needs
|
||||
**Solution**: Use prioritization frameworks and facilitate stakeholder alignment sessions
|
||||
|
||||
## Tools and Templates
|
||||
|
||||
### Recommended Tools
|
||||
- **Documentation**: Confluence, Notion, or similar wiki tools
|
||||
- **Project Management**: Jira, Azure DevOps, or similar tools
|
||||
- **Collaboration**: Miro, Figma for visual collaboration
|
||||
- **Communication**: Slack, Teams for ongoing communication
|
||||
|
||||
### Key Templates
|
||||
- Product Requirements Document (PRD) template
|
||||
- User story template with acceptance criteria
|
||||
- Stakeholder communication plan template
|
||||
- Product roadmap template
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Process Metrics
|
||||
- Requirements clarity score (stakeholder feedback)
|
||||
- Time from requirements to development start
|
||||
- Number of requirement changes during development
|
||||
- Stakeholder satisfaction scores
|
||||
|
||||
### Outcome Metrics
|
||||
- Feature adoption rates
|
||||
- User satisfaction scores
|
||||
- Business objective achievement
|
||||
- Time to market improvements
|
||||
|
||||
## Advanced Usage
|
||||
|
||||
### Complex Product Scenarios
|
||||
- Multi-team coordination strategies
|
||||
- Enterprise-level requirement management
|
||||
- Regulatory compliance considerations
|
||||
- International market considerations
|
||||
|
||||
### Integration Patterns
|
||||
- API-first product development
|
||||
- Microservices architecture considerations
|
||||
- Data privacy and security requirements
|
||||
- Scalability and performance requirements
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
1. **Vague Requirements**: Use structured questioning techniques
|
||||
2. **Missing Stakeholders**: Implement stakeholder mapping
|
||||
3. **Technical Constraints**: Early architect involvement
|
||||
4. **Timeline Pressure**: Scope negotiation and phased delivery
|
||||
|
||||
### Escalation Procedures
|
||||
- When to involve senior leadership
|
||||
- How to handle conflicting priorities
|
||||
- Managing scope changes
|
||||
- Dealing with technical blockers
|
||||
|
||||
## Next Steps
|
||||
|
||||
After completing PM activities:
|
||||
1. Hand off to UX/UI Architect for design
|
||||
2. Collaborate with System Architect for technical planning
|
||||
3. Work with Product Owner for sprint planning
|
||||
4. Maintain ongoing stakeholder communication
|
||||
|
||||
---
|
||||
|
||||
*This guide provides comprehensive coverage of the Product Manager persona's role in the BMAD Method. For specific implementation details, refer to the integration guide and quick-start documentation.*
|
||||
|
|
@ -0,0 +1,260 @@
|
|||
# Product Manager (John) - Integration Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This guide provides detailed instructions for integrating the Product Manager (John) persona into your development workflow, covering both web and IDE environments.
|
||||
|
||||
## Web Environment Integration
|
||||
|
||||
### v0 Chat Integration
|
||||
|
||||
#### Setup Instructions
|
||||
1. **Access v0 Chat Interface**
|
||||
- Navigate to v0.dev
|
||||
- Start a new chat session
|
||||
- Load the BMAD Method workspace
|
||||
|
||||
2. **Activate PM Persona**
|
||||
```
|
||||
Transform into John the Product Manager and help me with [specific task]
|
||||
```
|
||||
|
||||
3. **Context Loading**
|
||||
- Upload relevant business documents
|
||||
- Provide stakeholder requirements
|
||||
- Share market research data
|
||||
|
||||
#### Usage Patterns
|
||||
- **Requirements Analysis**: "John, analyze these business requirements and create a PRD"
|
||||
- **Stakeholder Communication**: "John, draft a stakeholder update for this feature"
|
||||
- **Prioritization**: "John, help prioritize these features using RICE framework"
|
||||
|
||||
### Web-Based Tools Integration
|
||||
|
||||
#### Documentation Platforms
|
||||
- **Confluence Integration**: Use PM templates for consistent documentation
|
||||
- **Notion Integration**: Leverage PM databases and templates
|
||||
- **SharePoint Integration**: Corporate documentation workflows
|
||||
|
||||
#### Project Management Tools
|
||||
- **Jira Integration**: Automated user story creation from PRDs
|
||||
- **Azure DevOps Integration**: Requirements traceability
|
||||
- **Asana Integration**: Stakeholder task management
|
||||
|
||||
## IDE Environment Integration
|
||||
|
||||
### Methodology Integration in IDEs
|
||||
|
||||
The BMAD Method integrates into IDE environments through **documentation loading** and **prompt structuring**, not through software installation.
|
||||
|
||||
#### Setup Process
|
||||
1. **Load BMAD Documentation**
|
||||
- Copy relevant persona files to your project directory
|
||||
- Reference BMAD templates and checklists in your AI assistant context
|
||||
- Use BMAD methodology patterns in your prompts
|
||||
|
||||
2. **Configure AI Assistant Context**
|
||||
```
|
||||
Load the Product Manager persona from: bmad-agent/personas/pm.md
|
||||
Reference task templates from: bmad-agent/tasks/
|
||||
Use quality checklists from: bmad-agent/checklists/pm-checklist.md
|
||||
```
|
||||
|
||||
#### Usage Patterns
|
||||
- **Activate PM Persona**: Load pm.md into your AI assistant context
|
||||
- **Use PM Tasks**: Reference specific tasks from the task library
|
||||
- **Apply Templates**: Use PRD and user story templates as guidance
|
||||
- **Follow Checklists**: Validate work against PM quality standards
|
||||
|
||||
## Workflow Integration
|
||||
|
||||
### BMAD Method Workflow
|
||||
|
||||
#### Phase Transitions
|
||||
1. **From Business Analyst**
|
||||
- Receive business requirements document
|
||||
- Review market research findings
|
||||
- Validate stakeholder needs
|
||||
|
||||
2. **PM Processing Phase**
|
||||
- Analyze requirements for completeness
|
||||
- Create detailed PRD
|
||||
- Define user stories with acceptance criteria
|
||||
- Conduct stakeholder reviews
|
||||
|
||||
3. **To UX/UI Architect**
|
||||
- Hand off validated PRD
|
||||
- Provide user journey documentation
|
||||
- Share design constraints and requirements
|
||||
|
||||
#### Collaboration Points
|
||||
- **With BA**: Requirements validation and clarification
|
||||
- **With Architect**: Technical feasibility discussions
|
||||
- **With PO**: Sprint planning and backlog management
|
||||
- **With Stakeholders**: Regular updates and feedback sessions
|
||||
|
||||
### Agile Integration
|
||||
|
||||
#### Scrum Framework
|
||||
- **Product Backlog Management**: Maintain and prioritize product backlog
|
||||
- **Sprint Planning**: Collaborate with PO on sprint goals
|
||||
- **Sprint Reviews**: Present completed features to stakeholders
|
||||
- **Retrospectives**: Gather feedback on PM processes
|
||||
|
||||
#### Kanban Integration
|
||||
- **Continuous Flow**: Manage requirements through Kanban board
|
||||
- **WIP Limits**: Set limits on requirements in progress
|
||||
- **Metrics**: Track cycle time for requirements processing
|
||||
|
||||
## Template Integration
|
||||
|
||||
### PRD Templates
|
||||
|
||||
#### Standard PRD Structure
|
||||
```markdown
|
||||
# Product Requirements Document
|
||||
|
||||
## Executive Summary
|
||||
- Problem statement
|
||||
- Solution overview
|
||||
- Success metrics
|
||||
|
||||
## Market Analysis
|
||||
- Target audience
|
||||
- Competitive landscape
|
||||
- Market opportunity
|
||||
|
||||
## Product Requirements
|
||||
- Functional requirements
|
||||
- Non-functional requirements
|
||||
- Constraints and assumptions
|
||||
|
||||
## User Stories
|
||||
- Epic breakdown
|
||||
- Detailed user stories
|
||||
- Acceptance criteria
|
||||
|
||||
## Success Metrics
|
||||
- KPIs and success criteria
|
||||
- Measurement plan
|
||||
- Timeline and milestones
|
||||
```
|
||||
|
||||
#### Template Customization
|
||||
- Industry-specific templates
|
||||
- Company-specific requirements
|
||||
- Regulatory compliance templates
|
||||
|
||||
### User Story Templates
|
||||
|
||||
#### Standard Format
|
||||
```markdown
|
||||
## User Story: [Title]
|
||||
|
||||
**As a** [user type]
|
||||
**I want** [functionality]
|
||||
**So that** [benefit/value]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] Criterion 1
|
||||
- [ ] Criterion 2
|
||||
- [ ] Criterion 3
|
||||
|
||||
### Definition of Done
|
||||
- [ ] Code complete
|
||||
- [ ] Tests passing
|
||||
- [ ] Documentation updated
|
||||
- [ ] Stakeholder approval
|
||||
```
|
||||
|
||||
## Third-Party Integrations
|
||||
|
||||
### CRM Integration
|
||||
- **Salesforce**: Customer feedback integration
|
||||
- **HubSpot**: Lead and customer data
|
||||
- **Pipedrive**: Sales pipeline insights
|
||||
|
||||
### Analytics Integration
|
||||
- **Google Analytics**: User behavior data
|
||||
- **Mixpanel**: Product usage analytics
|
||||
- **Amplitude**: User journey analysis
|
||||
|
||||
### Communication Tools
|
||||
- **Slack Integration**: Automated stakeholder updates
|
||||
- **Teams Integration**: Meeting scheduling and notes
|
||||
- **Discord Integration**: Community feedback collection
|
||||
|
||||
## Methodology Integration Patterns
|
||||
|
||||
### Prompt Structuring
|
||||
```
|
||||
"Acting as John the Product Manager from the BMAD Method, help me create a PRD for [project].
|
||||
Use the PRD template structure and follow the PM quality checklist to ensure completeness."
|
||||
```
|
||||
|
||||
### Context Loading
|
||||
```
|
||||
"Load the BMAD PM persona and task library. I need help with stakeholder elicitation for a new feature.
|
||||
Follow the stakeholder elicitation task process and use the communication templates."
|
||||
```
|
||||
|
||||
### Template Application
|
||||
```
|
||||
"Using the BMAD PRD template, create a product requirements document that includes:
|
||||
- Executive summary following the template structure
|
||||
- Market analysis using the provided framework
|
||||
- User stories in the standard BMAD format"
|
||||
```
|
||||
|
||||
## Quality Assurance Integration
|
||||
|
||||
### Automated Checks
|
||||
- **Requirements Completeness**: Automated PRD validation
|
||||
- **Acceptance Criteria Quality**: Story completeness checks
|
||||
- **Stakeholder Sign-off**: Approval workflow automation
|
||||
|
||||
### Review Processes
|
||||
- **Peer Review**: PM peer review workflows
|
||||
- **Stakeholder Review**: Structured feedback collection
|
||||
- **Technical Review**: Early architect involvement
|
||||
|
||||
## Troubleshooting Integration Issues
|
||||
|
||||
### Common Problems
|
||||
1. **Template Loading Issues**
|
||||
- Check file permissions
|
||||
- Verify template paths
|
||||
- Validate JSON/YAML syntax
|
||||
|
||||
2. **API Connection Problems**
|
||||
- Verify API keys
|
||||
- Check network connectivity
|
||||
- Review rate limiting
|
||||
|
||||
3. **Workflow Synchronization**
|
||||
- Check webhook configurations
|
||||
- Verify event handlers
|
||||
- Review integration logs
|
||||
|
||||
### Support Resources
|
||||
- **Documentation**: Comprehensive integration docs
|
||||
- **Community**: BMAD Method community forums
|
||||
- **Support**: Technical support channels
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Integration Maintenance
|
||||
- Regular template updates
|
||||
- API version management
|
||||
- Integration testing procedures
|
||||
- Performance monitoring
|
||||
|
||||
### Security Considerations
|
||||
- API key management
|
||||
- Data privacy compliance
|
||||
- Access control implementation
|
||||
- Audit trail maintenance
|
||||
|
||||
---
|
||||
|
||||
*This integration guide ensures seamless incorporation of the PM persona into your existing development workflow. For specific implementation questions, consult the troubleshooting section or contact support.*
|
||||
|
|
@ -0,0 +1,78 @@
|
|||
# Product Manager (John) - Quick Start Guide
|
||||
|
||||
## 5-Minute Setup
|
||||
|
||||
### Step 1: Access the PM Persona (1 minute)
|
||||
```
|
||||
Transform into John the Product Manager
|
||||
```
|
||||
|
||||
### Step 2: Load Your Context (2 minutes)
|
||||
- Upload business requirements document
|
||||
- Provide stakeholder contact information
|
||||
- Share any existing market research
|
||||
|
||||
### Step 3: Create Your First PRD (2 minutes)
|
||||
```
|
||||
John, create a PRD for [your product/feature] based on these requirements
|
||||
```
|
||||
|
||||
## Simple Example
|
||||
|
||||
### Scenario: E-commerce Mobile App Feature
|
||||
|
||||
**Input:**
|
||||
"We need to add a wishlist feature to our mobile app. Customers have been asking for it, and our competitors have it."
|
||||
|
||||
**PM Process:**
|
||||
1. **Requirements Analysis**: "Let me analyze this feature request and create a comprehensive PRD"
|
||||
2. **Market Research**: "I'll research how competitors implement wishlists"
|
||||
3. **User Stories**: "I'll break this down into specific user stories"
|
||||
4. **Stakeholder Review**: "I'll prepare this for stakeholder approval"
|
||||
|
||||
**Output:**
|
||||
- Complete PRD with market analysis
|
||||
- 8 detailed user stories with acceptance criteria
|
||||
- Implementation timeline and resource requirements
|
||||
- Risk assessment and mitigation strategies
|
||||
|
||||
## Key Best Practices
|
||||
|
||||
### 1. Always Start with "Why"
|
||||
- Understand the business problem
|
||||
- Identify the target user
|
||||
- Define success metrics
|
||||
|
||||
### 2. Use Structured Templates
|
||||
- PRD template for consistency
|
||||
- User story format for clarity
|
||||
- Acceptance criteria for testability
|
||||
|
||||
### 3. Involve Stakeholders Early
|
||||
- Regular review sessions
|
||||
- Clear communication channels
|
||||
- Documented decision rationale
|
||||
|
||||
### 4. Think Implementation
|
||||
- Consider technical constraints
|
||||
- Plan for scalability
|
||||
- Include non-functional requirements
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Try the Full Process**: Use John for a complete feature development cycle
|
||||
2. **Explore Templates**: Customize PRD and user story templates for your needs
|
||||
3. **Integrate Tools**: Connect with your existing project management tools
|
||||
4. **Join Community**: Connect with other BMAD Method users
|
||||
|
||||
## Quick Commands
|
||||
|
||||
- `Create PRD for [feature]`
|
||||
- `Generate user stories for [requirement]`
|
||||
- `Analyze market opportunity for [product]`
|
||||
- `Draft stakeholder update for [project]`
|
||||
- `Prioritize features using RICE framework`
|
||||
|
||||
---
|
||||
|
||||
*Ready to transform your product management process? Start with John today!*
|
||||
|
|
@ -0,0 +1,541 @@
|
|||
# Product Manager (John) - Task Library
|
||||
|
||||
## Overview
|
||||
|
||||
This comprehensive task library provides Product Managers with structured, actionable tasks for effectively using the BMAD Method. Each task includes clear objectives, inputs, outputs, and step-by-step execution guidance.
|
||||
|
||||
## Core Product Management Tasks
|
||||
|
||||
### PM-001: Create Product Requirements Document (PRD)
|
||||
**Objective**: Transform business requirements into comprehensive product specifications
|
||||
|
||||
**Inputs**:
|
||||
- Business requirements from stakeholders
|
||||
- Market research data
|
||||
- User feedback and analytics
|
||||
- Technical constraints from architects
|
||||
|
||||
**Outputs**:
|
||||
- Complete PRD document
|
||||
- User story backlog
|
||||
- Acceptance criteria definitions
|
||||
- Risk assessment matrix
|
||||
|
||||
**Execution Steps**:
|
||||
1. **Requirements Analysis**
|
||||
- Review all input materials
|
||||
- Identify gaps and ambiguities
|
||||
- Conduct stakeholder interviews if needed
|
||||
- Document assumptions and constraints
|
||||
|
||||
2. **Market Context Development**
|
||||
- Analyze competitive landscape
|
||||
- Define target user personas
|
||||
- Identify market opportunities
|
||||
- Document business value proposition
|
||||
|
||||
3. **Feature Definition**
|
||||
- Break down requirements into features
|
||||
- Define functional specifications
|
||||
- Specify non-functional requirements
|
||||
- Create feature prioritization matrix
|
||||
|
||||
4. **User Story Creation**
|
||||
- Write user stories with clear acceptance criteria
|
||||
- Map stories to business objectives
|
||||
- Estimate story complexity
|
||||
- Define story dependencies
|
||||
|
||||
5. **Stakeholder Review**
|
||||
- Present PRD to key stakeholders
|
||||
- Collect and incorporate feedback
|
||||
- Obtain formal approval
|
||||
- Document any scope changes
|
||||
|
||||
**Quality Checklist**:
|
||||
- [ ] All business requirements addressed
|
||||
- [ ] User stories follow INVEST criteria
|
||||
- [ ] Acceptance criteria are testable
|
||||
- [ ] Technical feasibility confirmed
|
||||
- [ ] Stakeholder sign-off obtained
|
||||
|
||||
### PM-002: Conduct Stakeholder Requirements Elicitation
|
||||
**Objective**: Gather comprehensive requirements from all relevant stakeholders
|
||||
|
||||
**Inputs**:
|
||||
- Stakeholder list and contact information
|
||||
- Initial project brief or business case
|
||||
- Previous project documentation (if applicable)
|
||||
- Market research data
|
||||
|
||||
**Outputs**:
|
||||
- Stakeholder requirements matrix
|
||||
- Requirements traceability document
|
||||
- Conflict resolution plan
|
||||
- Prioritized requirements list
|
||||
|
||||
**Execution Steps**:
|
||||
1. **Stakeholder Mapping**
|
||||
- Identify all relevant stakeholders
|
||||
- Categorize by influence and interest
|
||||
- Plan engagement strategy
|
||||
- Schedule elicitation sessions
|
||||
|
||||
2. **Requirements Gathering**
|
||||
- Conduct structured interviews
|
||||
- Facilitate requirements workshops
|
||||
- Use elicitation techniques (user story mapping, etc.)
|
||||
- Document requirements in real-time
|
||||
|
||||
3. **Requirements Analysis**
|
||||
- Identify conflicts and dependencies
|
||||
- Assess feasibility and impact
|
||||
- Prioritize using MoSCoW or RICE
|
||||
- Create requirements traceability matrix
|
||||
|
||||
4. **Validation and Approval**
|
||||
- Review requirements with stakeholders
|
||||
- Resolve conflicts through negotiation
|
||||
- Obtain formal approval
|
||||
- Establish change control process
|
||||
|
||||
**Quality Checklist**:
|
||||
- [ ] All stakeholders consulted
|
||||
- [ ] Requirements are clear and unambiguous
|
||||
- [ ] Conflicts identified and resolved
|
||||
- [ ] Priorities established and agreed upon
|
||||
- [ ] Traceability maintained
|
||||
|
||||
### PM-003: Create Product Roadmap
|
||||
**Objective**: Develop strategic product roadmap aligned with business objectives
|
||||
|
||||
**Inputs**:
|
||||
- Business strategy and objectives
|
||||
- Market analysis and competitive intelligence
|
||||
- Technical architecture constraints
|
||||
- Resource availability and capacity
|
||||
- Stakeholder priorities
|
||||
|
||||
**Outputs**:
|
||||
- Strategic product roadmap
|
||||
- Release planning timeline
|
||||
- Feature prioritization rationale
|
||||
- Resource allocation plan
|
||||
|
||||
**Execution Steps**:
|
||||
1. **Strategic Alignment**
|
||||
- Review business objectives and strategy
|
||||
- Identify key market opportunities
|
||||
- Define product vision and goals
|
||||
- Establish success metrics
|
||||
|
||||
2. **Feature Prioritization**
|
||||
- Apply prioritization frameworks (RICE, Value vs Effort)
|
||||
- Consider technical dependencies
|
||||
- Assess market timing factors
|
||||
- Balance stakeholder needs
|
||||
|
||||
3. **Timeline Development**
|
||||
- Create high-level release schedule
|
||||
- Account for technical constraints
|
||||
- Include buffer time for risks
|
||||
- Align with business milestones
|
||||
|
||||
4. **Stakeholder Communication**
|
||||
- Present roadmap to leadership
|
||||
- Gather feedback and iterate
|
||||
- Communicate to development teams
|
||||
- Establish regular review cycles
|
||||
|
||||
**Quality Checklist**:
|
||||
- [ ] Aligned with business strategy
|
||||
- [ ] Technically feasible timeline
|
||||
- [ ] Stakeholder buy-in achieved
|
||||
- [ ] Regular review process established
|
||||
- [ ] Success metrics defined
|
||||
|
||||
### PM-004: Manage Product Backlog
|
||||
**Objective**: Maintain and prioritize product backlog for optimal value delivery
|
||||
|
||||
**Inputs**:
|
||||
- User stories and requirements
|
||||
- Stakeholder feedback
|
||||
- Market changes and opportunities
|
||||
- Technical debt and constraints
|
||||
- Sprint retrospective insights
|
||||
|
||||
**Outputs**:
|
||||
- Prioritized product backlog
|
||||
- Sprint-ready user stories
|
||||
- Backlog refinement notes
|
||||
- Stakeholder communication updates
|
||||
|
||||
**Execution Steps**:
|
||||
1. **Backlog Grooming**
|
||||
- Review and update existing stories
|
||||
- Add new stories from requirements
|
||||
- Remove obsolete or duplicate items
|
||||
- Ensure stories meet Definition of Ready
|
||||
|
||||
2. **Prioritization**
|
||||
- Apply consistent prioritization criteria
|
||||
- Consider business value and urgency
|
||||
- Account for technical dependencies
|
||||
- Balance new features with technical debt
|
||||
|
||||
3. **Story Refinement**
|
||||
- Break down large stories (epics)
|
||||
- Add detailed acceptance criteria
|
||||
- Estimate story points with team
|
||||
- Identify and resolve dependencies
|
||||
|
||||
4. **Stakeholder Communication**
|
||||
- Communicate priority changes
|
||||
- Explain prioritization rationale
|
||||
- Gather feedback on upcoming features
|
||||
- Manage expectations on delivery
|
||||
|
||||
**Quality Checklist**:
|
||||
- [ ] Stories meet Definition of Ready
|
||||
- [ ] Priorities clearly communicated
|
||||
- [ ] Dependencies identified and managed
|
||||
- [ ] Stakeholder expectations aligned
|
||||
- [ ] Backlog size manageable
|
||||
|
||||
## Strategic Planning Tasks
|
||||
|
||||
### PM-005: Conduct Market Analysis
|
||||
**Objective**: Analyze market conditions and competitive landscape for informed product decisions
|
||||
|
||||
**Inputs**:
|
||||
- Market research reports
|
||||
- Competitive intelligence
|
||||
- Customer feedback and surveys
|
||||
- Industry trend analysis
|
||||
- Sales and marketing data
|
||||
|
||||
**Outputs**:
|
||||
- Market analysis report
|
||||
- Competitive positioning matrix
|
||||
- Market opportunity assessment
|
||||
- Strategic recommendations
|
||||
|
||||
**Execution Steps**:
|
||||
1. **Market Research**
|
||||
- Gather industry reports and data
|
||||
- Analyze market size and growth trends
|
||||
- Identify key market segments
|
||||
- Study regulatory and economic factors
|
||||
|
||||
2. **Competitive Analysis**
|
||||
- Identify direct and indirect competitors
|
||||
- Analyze competitor features and positioning
|
||||
- Assess competitive strengths and weaknesses
|
||||
- Identify market gaps and opportunities
|
||||
|
||||
3. **Customer Analysis**
|
||||
- Review customer feedback and surveys
|
||||
- Analyze user behavior and preferences
|
||||
- Identify unmet customer needs
|
||||
- Segment customers by value and behavior
|
||||
|
||||
4. **Strategic Synthesis**
|
||||
- Synthesize findings into actionable insights
|
||||
- Identify strategic opportunities
|
||||
- Recommend product positioning
|
||||
- Propose go-to-market strategies
|
||||
|
||||
**Quality Checklist**:
|
||||
- [ ] Comprehensive market data collected
|
||||
- [ ] Competitive analysis thorough
|
||||
- [ ] Customer insights validated
|
||||
- [ ] Strategic recommendations actionable
|
||||
- [ ] Findings clearly communicated
|
||||
|
||||
### PM-006: Define Success Metrics and KPIs
|
||||
**Objective**: Establish measurable success criteria for product initiatives
|
||||
|
||||
**Inputs**:
|
||||
- Business objectives and goals
|
||||
- User behavior data and analytics
|
||||
- Market benchmarks and standards
|
||||
- Technical performance metrics
|
||||
- Stakeholder success definitions
|
||||
|
||||
**Outputs**:
|
||||
- KPI framework and dashboard
|
||||
- Success criteria definitions
|
||||
- Measurement plan and timeline
|
||||
- Reporting and review schedule
|
||||
|
||||
**Execution Steps**:
|
||||
1. **Objective Alignment**
|
||||
- Map metrics to business objectives
|
||||
- Identify leading and lagging indicators
|
||||
- Define success thresholds
|
||||
- Establish baseline measurements
|
||||
|
||||
2. **Metric Selection**
|
||||
- Choose relevant and actionable metrics
|
||||
- Balance quantitative and qualitative measures
|
||||
- Ensure metrics are measurable and timely
|
||||
- Avoid vanity metrics
|
||||
|
||||
3. **Measurement Framework**
|
||||
- Design data collection processes
|
||||
- Set up tracking and analytics tools
|
||||
- Create reporting dashboards
|
||||
- Establish review and analysis cycles
|
||||
|
||||
4. **Stakeholder Alignment**
|
||||
- Present metrics framework to stakeholders
|
||||
- Obtain agreement on success criteria
|
||||
- Establish reporting responsibilities
|
||||
- Create escalation procedures
|
||||
|
||||
**Quality Checklist**:
|
||||
- [ ] Metrics aligned with objectives
|
||||
- [ ] Data collection feasible
|
||||
- [ ] Stakeholder agreement obtained
|
||||
- [ ] Regular review process established
|
||||
- [ ] Action plans for metric improvement
|
||||
|
||||
## Communication and Collaboration Tasks
|
||||
|
||||
### PM-007: Facilitate Cross-Functional Collaboration
|
||||
**Objective**: Enable effective collaboration between product, engineering, design, and business teams
|
||||
|
||||
**Inputs**:
|
||||
- Team structures and responsibilities
|
||||
- Project requirements and constraints
|
||||
- Communication preferences and tools
|
||||
- Collaboration challenges and blockers
|
||||
- Stakeholder expectations
|
||||
|
||||
**Outputs**:
|
||||
- Collaboration framework
|
||||
- Communication plan and schedule
|
||||
- Conflict resolution procedures
|
||||
- Team alignment documentation
|
||||
|
||||
**Execution Steps**:
|
||||
1. **Team Assessment**
|
||||
- Map team structures and roles
|
||||
- Identify collaboration touchpoints
|
||||
- Assess current communication effectiveness
|
||||
- Document existing processes and tools
|
||||
|
||||
2. **Framework Design**
|
||||
- Define collaboration principles
|
||||
- Establish communication protocols
|
||||
- Create decision-making processes
|
||||
- Design conflict resolution procedures
|
||||
|
||||
3. **Implementation**
|
||||
- Roll out collaboration framework
|
||||
- Train teams on new processes
|
||||
- Implement supporting tools and systems
|
||||
- Monitor adoption and effectiveness
|
||||
|
||||
4. **Continuous Improvement**
|
||||
- Gather feedback from teams
|
||||
- Identify and address pain points
|
||||
- Refine processes based on learnings
|
||||
- Scale successful practices
|
||||
|
||||
**Quality Checklist**:
|
||||
- [ ] All teams included in framework
|
||||
- [ ] Clear roles and responsibilities
|
||||
- [ ] Effective communication channels
|
||||
- [ ] Conflict resolution mechanisms
|
||||
- [ ] Regular improvement cycles
|
||||
|
||||
### PM-008: Manage Stakeholder Communication
|
||||
**Objective**: Maintain clear, consistent communication with all product stakeholders
|
||||
|
||||
**Inputs**:
|
||||
- Stakeholder mapping and analysis
|
||||
- Product status and progress updates
|
||||
- Key decisions and changes
|
||||
- Risk and issue information
|
||||
- Success metrics and performance data
|
||||
|
||||
**Outputs**:
|
||||
- Stakeholder communication plan
|
||||
- Regular status reports and updates
|
||||
- Decision documentation
|
||||
- Feedback collection and analysis
|
||||
|
||||
**Execution Steps**:
|
||||
1. **Communication Planning**
|
||||
- Map stakeholder information needs
|
||||
- Define communication frequency and format
|
||||
- Choose appropriate communication channels
|
||||
- Create communication calendar
|
||||
|
||||
2. **Content Development**
|
||||
- Prepare regular status updates
|
||||
- Document key decisions and rationale
|
||||
- Create executive summaries
|
||||
- Develop presentation materials
|
||||
|
||||
3. **Delivery and Engagement**
|
||||
- Deliver communications on schedule
|
||||
- Facilitate stakeholder meetings
|
||||
- Collect feedback and questions
|
||||
- Address concerns and issues promptly
|
||||
|
||||
4. **Feedback Integration**
|
||||
- Analyze stakeholder feedback
|
||||
- Incorporate insights into planning
|
||||
- Adjust communication approach as needed
|
||||
- Close the feedback loop
|
||||
|
||||
**Quality Checklist**:
|
||||
- [ ] All stakeholders included
|
||||
- [ ] Communication timely and relevant
|
||||
- [ ] Feedback actively collected
|
||||
- [ ] Issues addressed promptly
|
||||
- [ ] Communication effectiveness measured
|
||||
|
||||
## Risk and Issue Management Tasks
|
||||
|
||||
### PM-009: Conduct Risk Assessment and Mitigation Planning
|
||||
**Objective**: Identify, assess, and mitigate risks that could impact product success
|
||||
|
||||
**Inputs**:
|
||||
- Project scope and requirements
|
||||
- Technical architecture and constraints
|
||||
- Market conditions and competitive landscape
|
||||
- Resource availability and constraints
|
||||
- Historical risk data and lessons learned
|
||||
|
||||
**Outputs**:
|
||||
- Risk register and assessment matrix
|
||||
- Risk mitigation strategies and plans
|
||||
- Contingency plans for high-impact risks
|
||||
- Risk monitoring and reporting procedures
|
||||
|
||||
**Execution Steps**:
|
||||
1. **Risk Identification**
|
||||
- Brainstorm potential risks with team
|
||||
- Review historical project risks
|
||||
- Analyze external market factors
|
||||
- Consider technical and resource constraints
|
||||
|
||||
2. **Risk Assessment**
|
||||
- Evaluate probability and impact
|
||||
- Prioritize risks using risk matrix
|
||||
- Identify risk interdependencies
|
||||
- Assess current risk exposure
|
||||
|
||||
3. **Mitigation Planning**
|
||||
- Develop mitigation strategies
|
||||
- Create contingency plans
|
||||
- Assign risk owners and responsibilities
|
||||
- Establish monitoring procedures
|
||||
|
||||
4. **Implementation and Monitoring**
|
||||
- Implement risk mitigation measures
|
||||
- Monitor risk indicators regularly
|
||||
- Update risk assessments as needed
|
||||
- Communicate risk status to stakeholders
|
||||
|
||||
**Quality Checklist**:
|
||||
- [ ] Comprehensive risk identification
|
||||
- [ ] Accurate risk assessment
|
||||
- [ ] Effective mitigation strategies
|
||||
- [ ] Clear ownership and accountability
|
||||
- [ ] Regular monitoring and updates
|
||||
|
||||
### PM-010: Manage Scope Changes and Requirements Evolution
|
||||
**Objective**: Control scope changes while allowing for necessary requirements evolution
|
||||
|
||||
**Inputs**:
|
||||
- Original project scope and requirements
|
||||
- Change requests from stakeholders
|
||||
- Market changes and new opportunities
|
||||
- Technical discoveries and constraints
|
||||
- Resource and timeline impacts
|
||||
|
||||
**Outputs**:
|
||||
- Change control process and procedures
|
||||
- Impact assessment documentation
|
||||
- Approved scope changes
|
||||
- Updated project documentation
|
||||
|
||||
**Execution Steps**:
|
||||
1. **Change Control Setup**
|
||||
- Define change control process
|
||||
- Establish change approval authority
|
||||
- Create change request templates
|
||||
- Set up tracking and documentation
|
||||
|
||||
2. **Change Evaluation**
|
||||
- Assess change request validity
|
||||
- Analyze impact on scope, time, cost
|
||||
- Evaluate alignment with objectives
|
||||
- Consider alternative solutions
|
||||
|
||||
3. **Decision Making**
|
||||
- Present impact analysis to stakeholders
|
||||
- Facilitate decision-making process
|
||||
- Document decisions and rationale
|
||||
- Communicate changes to all teams
|
||||
|
||||
4. **Implementation**
|
||||
- Update project documentation
|
||||
- Adjust plans and schedules
|
||||
- Reallocate resources as needed
|
||||
- Monitor implementation progress
|
||||
|
||||
**Quality Checklist**:
|
||||
- [ ] Clear change control process
|
||||
- [ ] Thorough impact analysis
|
||||
- [ ] Stakeholder approval obtained
|
||||
- [ ] Documentation updated
|
||||
- [ ] Teams informed of changes
|
||||
|
||||
## Integration with BMAD Method
|
||||
|
||||
### Workflow Integration Points
|
||||
- **From Business Analyst**: Receive validated business requirements
|
||||
- **To UX/UI Architect**: Provide detailed product specifications
|
||||
- **To System Architect**: Share technical requirements and constraints
|
||||
- **To Product Owner**: Hand off refined backlog and priorities
|
||||
|
||||
### Collaboration Patterns
|
||||
- **Requirements Workshops**: Facilitate cross-persona requirements sessions
|
||||
- **Design Reviews**: Participate in UX/UI design validation
|
||||
- **Architecture Reviews**: Provide product perspective on technical decisions
|
||||
- **Sprint Planning**: Collaborate with PO on sprint goals and priorities
|
||||
|
||||
### Quality Gates
|
||||
- **Requirements Completeness**: Ensure all business needs addressed
|
||||
- **Stakeholder Alignment**: Verify stakeholder agreement on priorities
|
||||
- **Technical Feasibility**: Confirm technical viability with architects
|
||||
- **User Value**: Validate user value proposition for all features
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Documentation Standards
|
||||
- Use consistent templates and formats
|
||||
- Maintain version control and change logs
|
||||
- Include rationale for all major decisions
|
||||
- Create searchable and linkable content
|
||||
|
||||
### Stakeholder Management
|
||||
- Regular communication and updates
|
||||
- Clear escalation paths and procedures
|
||||
- Transparent decision-making processes
|
||||
- Active feedback collection and integration
|
||||
|
||||
### Collaboration Excellence
|
||||
- Foster cross-functional team alignment
|
||||
- Facilitate effective meetings and workshops
|
||||
- Promote shared understanding and goals
|
||||
- Address conflicts promptly and fairly
|
||||
|
||||
---
|
||||
|
||||
*This task library provides comprehensive guidance for Product Managers using the BMAD Method. Each task includes detailed execution steps, quality criteria, and integration points with other personas.*
|
||||
|
|
@ -0,0 +1,276 @@
|
|||
# Product Owner (Sarah) Comprehensive Guide
|
||||
|
||||
## Introduction
|
||||
|
||||
Sarah, the Product Owner persona, is your meticulous guardian of quality and process steward within the BMAD Method. Sarah excels at bridging the gap between approved strategic plans and executable development work, ensuring all artifacts are validated and stories are primed for efficient implementation. Her analytical, detail-oriented approach ensures that development teams receive clear, consistent, and actionable tasks that drive project success.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Core Capabilities](#core-capabilities)
|
||||
2. [When to Use](#when-to-use)
|
||||
3. [Activation Methods](#activation-methods)
|
||||
4. [Working Process](#working-process)
|
||||
5. [Input Requirements](#input-requirements)
|
||||
6. [Output Expectations](#output-expectations)
|
||||
7. [Integration with Other Personas](#integration-with-other-personas)
|
||||
8. [Best Practices](#best-practices)
|
||||
9. [Troubleshooting](#troubleshooting)
|
||||
10. [Advanced Usage](#advanced-usage)
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
Sarah excels in several key product ownership domains:
|
||||
|
||||
### Core Product Ownership (90%+ confidence)
|
||||
- **Artifact Quality Assurance**: Comprehensive validation of PRDs, Architecture documents, UI/UX Specifications, Epics, and Stories for completeness and consistency
|
||||
- **Story Creation & Refinement**: Transform requirements into clear, testable, actionable user stories with detailed acceptance criteria
|
||||
- **Backlog Management**: Prioritize and sequence epics and stories, manage dependencies, maintain backlog health
|
||||
- **Process Adherence**: Rigorously follow defined processes, templates, and checklists to ensure consistency and quality
|
||||
- **Stakeholder Communication**: Bridge technical and business teams, facilitate reviews, manage expectations
|
||||
- **Sprint Planning Support**: Prepare stories for development, estimate complexity, identify blockers
|
||||
|
||||
### Strategic Product Management (70-90% confidence)
|
||||
- **Requirements Traceability**: Ensure clear connections between business needs, epics, stories, and implementation
|
||||
- **Risk Management**: Identify and communicate potential blockers, dependencies, and risks early
|
||||
- **Quality Gate Management**: Implement checkpoints and validation processes throughout development lifecycle
|
||||
- **Documentation Ecosystem Management**: Maintain consistency across all project documentation and artifacts
|
||||
- **Stakeholder Alignment**: Facilitate consensus building and decision-making processes
|
||||
- **Value Stream Optimization**: Ensure work represents valuable, executable increments aligned with MVP goals
|
||||
|
||||
### Advanced Product Operations (50-70% confidence)
|
||||
- **Metrics & Analytics**: Define and track product success metrics, user story completion rates, velocity trends
|
||||
- **Cross-Team Coordination**: Manage dependencies across multiple development teams and workstreams
|
||||
- **Technical Debt Management**: Balance feature development with technical debt reduction
|
||||
- **Release Planning**: Coordinate feature releases, manage release dependencies, plan rollout strategies
|
||||
|
||||
## When to Use
|
||||
|
||||
Sarah is ideal for:
|
||||
|
||||
- **Story Preparation**: When requirements need to be broken down into actionable development tasks
|
||||
- **Quality Validation**: Ensuring all project artifacts meet defined standards before development
|
||||
- **Sprint Planning**: Preparing and prioritizing work for development sprints
|
||||
- **Dependency Management**: Identifying and managing cross-story and cross-epic dependencies
|
||||
- **Process Enforcement**: Ensuring consistent adherence to development processes and standards
|
||||
- **Stakeholder Coordination**: Facilitating communication between business and technical teams
|
||||
- **Backlog Refinement**: Maintaining a healthy, prioritized product backlog
|
||||
- **Release Planning**: Coordinating feature releases and managing delivery timelines
|
||||
|
||||
## Activation Methods
|
||||
|
||||
### Web Environment (Sarah)
|
||||
|
||||
```
|
||||
"I need Sarah to help prepare user stories for development"
|
||||
"Sarah, can you validate this PRD and create actionable stories?"
|
||||
"Help me refine the product backlog and prioritize upcoming work"
|
||||
"Sarah, I need to prepare stories for the next sprint"
|
||||
```
|
||||
|
||||
### IDE Environment (Sarah)
|
||||
|
||||
```
|
||||
"Sarah, help me break down these requirements into development-ready stories"
|
||||
"I need story validation and acceptance criteria for [feature/epic]"
|
||||
"Sarah, prepare sprint-ready stories from this PRD"
|
||||
```
|
||||
|
||||
## Working Process
|
||||
|
||||
Sarah follows a systematic product ownership process:
|
||||
|
||||
### 1. Artifact Validation & Quality Assurance
|
||||
- Reviewing PRDs, architecture documents, and specifications for completeness
|
||||
- Validating consistency across all project documentation
|
||||
- Identifying gaps, ambiguities, or missing information
|
||||
- Running quality checklists and validation processes
|
||||
|
||||
### 2. Requirements Analysis & Story Creation
|
||||
- Breaking down epics and features into actionable user stories
|
||||
- Writing clear, testable acceptance criteria for each story
|
||||
- Ensuring stories follow INVEST principles (Independent, Negotiable, Valuable, Estimable, Small, Testable)
|
||||
- Validating story completeness and clarity
|
||||
|
||||
### 3. Dependency Management & Sequencing
|
||||
- Identifying dependencies between stories and epics
|
||||
- Creating logical sequencing for development work
|
||||
- Managing cross-team dependencies and coordination points
|
||||
- Planning for parallel development streams
|
||||
|
||||
### 4. Stakeholder Review & Validation
|
||||
- Facilitating stakeholder reviews of stories and acceptance criteria
|
||||
- Gathering feedback and incorporating changes
|
||||
- Ensuring stakeholder alignment on priorities and scope
|
||||
- Managing expectation setting and communication
|
||||
|
||||
### 5. Sprint Preparation & Handoff
|
||||
- Preparing stories for sprint planning sessions
|
||||
- Providing context and clarification to development teams
|
||||
- Supporting estimation and planning activities
|
||||
- Ensuring development teams have everything needed to begin work
|
||||
|
||||
## Input Requirements
|
||||
|
||||
For optimal product ownership support, provide Sarah with:
|
||||
|
||||
- **Project Documentation**: PRDs, architecture documents, UI/UX specifications
|
||||
- **Business Requirements**: Stakeholder needs, user personas, business objectives
|
||||
- **Technical Constraints**: Architecture decisions, technology limitations, team capabilities
|
||||
- **Timeline Information**: Project deadlines, milestone requirements, release schedules
|
||||
- **Quality Standards**: Definition of done, acceptance criteria templates, quality gates
|
||||
- **Stakeholder Context**: Key stakeholders, decision makers, communication preferences
|
||||
|
||||
## Output Expectations
|
||||
|
||||
Sarah produces comprehensive product ownership deliverables:
|
||||
|
||||
- **Refined User Stories**: Clear, actionable stories with detailed acceptance criteria
|
||||
- **Prioritized Product Backlog**: Well-organized, prioritized list of development work
|
||||
- **Sprint-Ready Stories**: Stories prepared for immediate development with all necessary context
|
||||
- **Dependency Maps**: Clear identification of story and epic dependencies
|
||||
- **Quality Validation Reports**: Comprehensive reviews of project artifacts and documentation
|
||||
- **Stakeholder Communication Plans**: Structured approach to stakeholder engagement and updates
|
||||
- **Risk & Blocker Identification**: Early identification of potential development obstacles
|
||||
- **Process Documentation**: Clear documentation of workflows and decision processes
|
||||
|
||||
## Integration with Other Personas
|
||||
|
||||
Sarah works seamlessly with other BMAD Method personas:
|
||||
|
||||
- **Business Analyst (Mary)**: Receives business requirements and transforms them into development-ready artifacts
|
||||
- **Product Manager (John)**: Enhances PRDs with detailed story breakdowns and validation
|
||||
- **System Architect (Fred)**: Ensures technical architecture supports story implementation and validates technical feasibility
|
||||
- **UX/UI Architect (Veronica/Victor)**: Coordinates design requirements with development stories and ensures design-development alignment
|
||||
- **Developer (David)**: Provides clear, actionable stories with all necessary context for implementation
|
||||
- **DevOps Engineer (Alex)**: Coordinates infrastructure and deployment requirements within stories
|
||||
- **Scrum Master (Mike)**: Collaborates on sprint planning, velocity tracking, and process improvement
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Effective Story Management
|
||||
|
||||
1. **INVEST Principles**: Ensure all stories are Independent, Negotiable, Valuable, Estimable, Small, and Testable
|
||||
2. **Clear Acceptance Criteria**: Write specific, measurable, and testable acceptance criteria
|
||||
3. **Definition of Done**: Maintain consistent quality standards across all stories
|
||||
4. **Story Sizing**: Keep stories appropriately sized for single sprint completion
|
||||
5. **Dependency Management**: Identify and plan for story dependencies early
|
||||
|
||||
### Quality Assurance Practices
|
||||
|
||||
- **Artifact Reviews**: Systematically review all project documentation for completeness and consistency
|
||||
- **Checklist Usage**: Use standardized checklists to ensure consistent quality validation
|
||||
- **Stakeholder Validation**: Regular stakeholder reviews and sign-offs on key deliverables
|
||||
- **Traceability**: Maintain clear connections between business requirements and implementation stories
|
||||
- **Documentation Standards**: Ensure all documentation follows established templates and standards
|
||||
|
||||
### Communication Guidelines
|
||||
|
||||
- Run the Product Owner Master Checklist after completing story preparation
|
||||
- Facilitate regular stakeholder reviews and feedback sessions
|
||||
- Maintain transparent communication about blockers and dependencies
|
||||
- Provide clear context and rationale for story prioritization decisions
|
||||
- Ensure development teams have all necessary information before sprint start
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues and Solutions
|
||||
|
||||
| Issue | Solution |
|
||||
|-------|----------|
|
||||
| Stories are too large or complex | Break down into smaller, more focused stories; apply story splitting techniques |
|
||||
| Acceptance criteria are unclear | Use Given-When-Then format; add specific examples and edge cases |
|
||||
| Dependencies are blocking progress | Create dependency maps; coordinate with stakeholders to resolve blockers |
|
||||
| Stakeholders disagree on priorities | Facilitate prioritization sessions; use objective criteria like business value and effort |
|
||||
| Stories lack sufficient detail | Conduct story refinement sessions; gather additional requirements from stakeholders |
|
||||
| Development team has questions about stories | Improve story documentation; add more context and examples |
|
||||
|
||||
## Advanced Usage
|
||||
|
||||
### Enterprise Product Ownership
|
||||
|
||||
Sarah can handle sophisticated enterprise scenarios:
|
||||
|
||||
1. **Multi-Team Coordination**: Managing product backlogs across multiple development teams
|
||||
2. **Complex Dependency Management**: Handling intricate dependencies across teams and systems
|
||||
3. **Scaled Agile Frameworks**: Supporting SAFe, LeSS, or other scaled agile implementations
|
||||
4. **Regulatory Compliance**: Ensuring stories meet compliance and regulatory requirements
|
||||
5. **Technical Debt Management**: Balancing feature development with technical debt reduction
|
||||
|
||||
### Advanced Story Techniques
|
||||
|
||||
- **Story Mapping**: Creating visual representations of user journeys and story relationships
|
||||
- **Behavior-Driven Development (BDD)**: Writing stories in Given-When-Then format for better testability
|
||||
- **Impact Mapping**: Connecting stories to business outcomes and success metrics
|
||||
- **Story Splitting Patterns**: Advanced techniques for breaking down complex stories
|
||||
- **Acceptance Test-Driven Development (ATDD)**: Collaborating with teams to define acceptance tests upfront
|
||||
|
||||
### Metrics and Analytics
|
||||
|
||||
- **Velocity Tracking**: Monitoring team velocity and story completion rates
|
||||
- **Cycle Time Analysis**: Measuring time from story creation to completion
|
||||
- **Quality Metrics**: Tracking defect rates, story rejection rates, and rework
|
||||
- **Stakeholder Satisfaction**: Measuring stakeholder satisfaction with delivered features
|
||||
- **Value Delivery**: Tracking business value delivered through completed stories
|
||||
|
||||
## Templates and Checklists
|
||||
|
||||
### User Story Template
|
||||
|
||||
```markdown
|
||||
## User Story: [Title]
|
||||
|
||||
**As a** [user type]
|
||||
**I want** [functionality]
|
||||
**So that** [benefit/value]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] Given [context], when [action], then [expected result]
|
||||
- [ ] Given [context], when [action], then [expected result]
|
||||
- [ ] Given [context], when [action], then [expected result]
|
||||
|
||||
### Definition of Done
|
||||
- [ ] Code complete and reviewed
|
||||
- [ ] Unit tests written and passing
|
||||
- [ ] Integration tests passing
|
||||
- [ ] Documentation updated
|
||||
- [ ] Acceptance criteria validated
|
||||
- [ ] Stakeholder approval received
|
||||
|
||||
### Additional Context
|
||||
- **Priority**: [High/Medium/Low]
|
||||
- **Story Points**: [Estimate]
|
||||
- **Dependencies**: [List any dependencies]
|
||||
- **Assumptions**: [List any assumptions]
|
||||
- **Notes**: [Additional context or clarifications]
|
||||
```
|
||||
|
||||
### Epic Breakdown Template
|
||||
|
||||
```markdown
|
||||
## Epic: [Epic Name]
|
||||
|
||||
### Epic Description
|
||||
[Brief description of the epic and its business value]
|
||||
|
||||
### User Stories
|
||||
1. [Story 1 Title] - [Priority] - [Story Points]
|
||||
2. [Story 2 Title] - [Priority] - [Story Points]
|
||||
3. [Story 3 Title] - [Priority] - [Story Points]
|
||||
|
||||
### Dependencies
|
||||
- [Dependency 1]
|
||||
- [Dependency 2]
|
||||
|
||||
### Success Criteria
|
||||
- [Measurable success criterion 1]
|
||||
- [Measurable success criterion 2]
|
||||
|
||||
### Timeline
|
||||
- **Start Date**: [Date]
|
||||
- **Target Completion**: [Date]
|
||||
- **Milestones**: [Key milestones]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
This comprehensive guide provides everything you need to effectively leverage Sarah's product ownership expertise in your development projects. Sarah's meticulous approach ensures that your development teams receive clear, actionable work that drives consistent project success.
|
||||
|
|
@ -0,0 +1,340 @@
|
|||
# Product Owner (Sarah) Integration Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This guide explains how to integrate Sarah, the Product Owner persona, into your development workflow, including setup instructions, configuration options, and best practices for different environments and agile frameworks.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Web Environment Integration](#web-environment-integration)
|
||||
2. [IDE Environment Integration](#ide-environment-integration)
|
||||
3. [BMAD Method Workflow Integration](#bmad-method-workflow-integration)
|
||||
4. [Agile Framework Integration](#agile-framework-integration)
|
||||
5. [Third-Party Tool Integration](#third-party-tool-integration)
|
||||
6. [Configuration Options](#configuration-options)
|
||||
|
||||
## Web Environment Integration
|
||||
|
||||
### Setup Instructions
|
||||
|
||||
1. **Access the Web Orchestrator**
|
||||
- Navigate to your preferred AI platform (ChatGPT, Claude, etc.)
|
||||
- Create a new conversation for product ownership activities
|
||||
|
||||
2. **Load the Product Owner Persona**
|
||||
- Copy the contents of `bmad-agent/personas/po.md`
|
||||
- Paste as your first message to activate Sarah
|
||||
|
||||
3. **Activate the Persona**
|
||||
- Use an activation phrase: "I need Sarah to help prepare user stories for development"
|
||||
- Provide initial project context and requirements
|
||||
|
||||
### Usage in Web Environment
|
||||
|
||||
```
|
||||
"Sarah, I have a PRD for a customer management system that needs to be broken down into user stories. The system needs to handle customer registration, profile management, and communication preferences. Our development team works in 2-week sprints and prefers stories that can be completed within a single sprint.
|
||||
|
||||
Here are the key requirements:
|
||||
- Customer registration with email verification
|
||||
- Profile editing with photo upload
|
||||
- Communication preference management
|
||||
- Integration with existing CRM system
|
||||
- Mobile-responsive design
|
||||
- GDPR compliance for data handling
|
||||
|
||||
Please create sprint-ready user stories with detailed acceptance criteria."
|
||||
```
|
||||
|
||||
### Output Handling
|
||||
|
||||
- **User Stories**: Save stories to your project management tool (Jira, Azure DevOps, etc.)
|
||||
- **Acceptance Criteria**: Use as basis for test case development and validation
|
||||
- **Dependency Maps**: Incorporate into sprint planning and release planning
|
||||
- **Quality Reports**: Use for stakeholder communication and project status updates
|
||||
|
||||
## IDE Environment Integration
|
||||
|
||||
### Supported IDEs
|
||||
|
||||
- **Cursor AI**: Full integration with story creation and backlog management
|
||||
- **Claude Code**: Complete context-aware product ownership assistance
|
||||
- **Cline**: Terminal-based story preparation and validation
|
||||
- **Roocode**: Visual story mapping and backlog organization
|
||||
|
||||
### Setup Instructions
|
||||
|
||||
#### Cursor AI Setup
|
||||
|
||||
1. Install Cursor AI from [cursor.sh](https://cursor.sh)
|
||||
2. Copy `bmad-agent/personas/po.md` to your project root
|
||||
3. Open the file in Cursor
|
||||
4. Use Cursor's chat feature: "I need Sarah to help with story preparation"
|
||||
|
||||
#### Claude Code Setup
|
||||
|
||||
1. Access Claude Code in your development environment
|
||||
2. Load `bmad-agent/personas/po.md` as context
|
||||
3. Request product ownership support: "Sarah, help me prepare stories for development"
|
||||
|
||||
#### Cline Setup
|
||||
|
||||
1. Install Cline from [cline.tools](https://cline.tools)
|
||||
2. Reference the persona file in your chat
|
||||
3. Activate: "I need product ownership guidance from Sarah"
|
||||
|
||||
#### Roocode Setup
|
||||
|
||||
1. Install Roocode
|
||||
2. Import the product owner persona configuration
|
||||
3. Activate product ownership mode
|
||||
|
||||
### Usage in IDE Environment
|
||||
|
||||
```
|
||||
"Sarah, I'm working on a feature branch for user authentication. I have the technical requirements from the architect, but I need to create proper user stories with acceptance criteria for the development team.
|
||||
|
||||
The feature includes:
|
||||
- Login/logout functionality
|
||||
- Password reset flow
|
||||
- Multi-factor authentication
|
||||
- Session management
|
||||
- Account lockout after failed attempts
|
||||
|
||||
The team uses TypeScript with React frontend and Node.js backend. We follow test-driven development practices and need stories that include testing requirements."
|
||||
```
|
||||
|
||||
## BMAD Method Workflow Integration
|
||||
|
||||
### Integration Points
|
||||
|
||||
Sarah integrates at key points in the BMAD workflow:
|
||||
|
||||
1. **After Product Management (John)**
|
||||
- Transform PRD into actionable user stories
|
||||
- Validate requirements completeness and clarity
|
||||
- Create detailed acceptance criteria for each feature
|
||||
|
||||
2. **After System Architecture (Fred)**
|
||||
- Ensure stories align with technical architecture
|
||||
- Incorporate technical constraints into story definitions
|
||||
- Validate technical feasibility of story implementations
|
||||
|
||||
3. **After UX/UI Design (Veronica/Victor)**
|
||||
- Integrate design specifications into story acceptance criteria
|
||||
- Ensure stories support design system implementation
|
||||
- Coordinate design and development handoffs
|
||||
|
||||
4. **Before Development (David)**
|
||||
- Provide sprint-ready stories with complete context
|
||||
- Support story estimation and sprint planning
|
||||
- Facilitate developer questions and clarifications
|
||||
|
||||
5. **Parallel with Scrum Master (Mike)**
|
||||
- Collaborate on sprint planning and backlog refinement
|
||||
- Support velocity tracking and process improvement
|
||||
- Coordinate stakeholder communication and reviews
|
||||
|
||||
### Workflow Diagram
|
||||
|
||||
```
|
||||
Product Manager (John) → System Architect (Fred) → UX/UI Architect (Veronica/Victor) →
|
||||
Product Owner (Sarah) → Developer (David) + Scrum Master (Mike) + DevOps Engineer (Alex)
|
||||
```
|
||||
|
||||
### Handoff Procedures
|
||||
|
||||
#### From Product Manager
|
||||
- **Receives**: Validated PRD, stakeholder requirements, business priorities
|
||||
- **Validates**: Requirements completeness, stakeholder alignment
|
||||
- **Adds**: Detailed story breakdowns, acceptance criteria, dependency analysis
|
||||
|
||||
#### From System Architect
|
||||
- **Receives**: Technical architecture, implementation constraints, technology decisions
|
||||
- **Validates**: Story technical feasibility, architecture alignment
|
||||
- **Adds**: Technical context to stories, implementation guidance
|
||||
|
||||
#### From UX/UI Architect
|
||||
- **Receives**: Design specifications, component library, user experience flows
|
||||
- **Validates**: Design-development alignment, implementation feasibility
|
||||
- **Adds**: Design requirements to acceptance criteria, UI/UX validation steps
|
||||
|
||||
#### To Development Team
|
||||
- **Provides**: Sprint-ready stories, detailed acceptance criteria, implementation context
|
||||
- **Supports**: Story estimation, sprint planning, clarification requests
|
||||
- **Facilitates**: Developer-stakeholder communication, requirement validation
|
||||
|
||||
## Agile Framework Integration
|
||||
|
||||
### Scrum Integration
|
||||
|
||||
- **Product Backlog Management**: Maintain and prioritize product backlog items
|
||||
- **Sprint Planning**: Prepare stories for sprint planning sessions
|
||||
- **Sprint Review**: Present completed stories to stakeholders
|
||||
- **Backlog Refinement**: Continuously refine and improve story quality
|
||||
|
||||
### Kanban Integration
|
||||
|
||||
- **Continuous Flow**: Manage story flow through development pipeline
|
||||
- **WIP Limits**: Set appropriate work-in-progress limits for story preparation
|
||||
- **Metrics**: Track story cycle time and throughput
|
||||
|
||||
### SAFe Integration
|
||||
|
||||
- **Program Increment Planning**: Prepare stories for PI planning events
|
||||
- **Feature Breakdown**: Decompose features into implementable stories
|
||||
- **Cross-Team Coordination**: Manage dependencies across agile release trains
|
||||
|
||||
### LeSS Integration
|
||||
|
||||
- **Multi-Team Backlog**: Coordinate product backlog across multiple teams
|
||||
- **Sprint Planning**: Support multi-team sprint planning sessions
|
||||
- **Cross-Team Dependencies**: Manage and resolve cross-team dependencies
|
||||
|
||||
## Third-Party Tool Integration
|
||||
|
||||
### Project Management Tools
|
||||
|
||||
#### Jira Integration
|
||||
```yaml
|
||||
# Example Jira story template
|
||||
story_template:
|
||||
issue_type: "Story"
|
||||
summary: "[Story Title]"
|
||||
description: |
|
||||
As a [user type]
|
||||
I want [functionality]
|
||||
So that [benefit]
|
||||
|
||||
Acceptance Criteria:
|
||||
- [ ] Criterion 1
|
||||
- [ ] Criterion 2
|
||||
- [ ] Criterion 3
|
||||
labels: ["bmad-method", "sprint-ready"]
|
||||
components: ["Frontend", "Backend"]
|
||||
story_points: 5
|
||||
```
|
||||
|
||||
#### Azure DevOps Integration
|
||||
```yaml
|
||||
# Example Azure DevOps work item
|
||||
work_item:
|
||||
type: "User Story"
|
||||
title: "[Story Title]"
|
||||
description: "[Story Description]"
|
||||
acceptance_criteria: "[Detailed Criteria]"
|
||||
tags: ["bmad-method", "ready-for-development"]
|
||||
area_path: "Project\\Feature Area"
|
||||
iteration_path: "Project\\Sprint 1"
|
||||
```
|
||||
|
||||
#### Asana Integration
|
||||
```yaml
|
||||
# Example Asana task structure
|
||||
task:
|
||||
name: "[Story Title]"
|
||||
notes: |
|
||||
User Story: [Story Description]
|
||||
Acceptance Criteria: [Criteria List]
|
||||
Definition of Done: [DoD Checklist]
|
||||
projects: ["Product Development"]
|
||||
tags: ["user-story", "sprint-ready"]
|
||||
custom_fields:
|
||||
story_points: 5
|
||||
priority: "High"
|
||||
```
|
||||
|
||||
### Communication Tools
|
||||
|
||||
#### Slack Integration
|
||||
- **Story Notifications**: Automated updates when stories are ready for development
|
||||
- **Stakeholder Updates**: Regular communication about story progress and blockers
|
||||
- **Team Coordination**: Facilitate cross-team communication about dependencies
|
||||
|
||||
#### Microsoft Teams Integration
|
||||
- **Sprint Planning**: Schedule and coordinate sprint planning sessions
|
||||
- **Story Reviews**: Facilitate stakeholder reviews of story acceptance criteria
|
||||
- **Documentation Sharing**: Share story documentation and updates
|
||||
|
||||
### Documentation Tools
|
||||
|
||||
#### Confluence Integration
|
||||
- **Story Documentation**: Maintain detailed story documentation and context
|
||||
- **Process Documentation**: Document product ownership processes and standards
|
||||
- **Knowledge Base**: Create searchable repository of story patterns and templates
|
||||
|
||||
#### Notion Integration
|
||||
- **Story Database**: Maintain comprehensive database of all user stories
|
||||
- **Template Library**: Store and manage story templates and patterns
|
||||
- **Team Collaboration**: Facilitate collaborative story refinement sessions
|
||||
|
||||
## Configuration Options
|
||||
|
||||
### Story Management Preferences
|
||||
|
||||
| Option | Description | Default | Example |
|
||||
|--------|-------------|---------|---------|
|
||||
| `storyFormat` | Preferred story format | "As a...I want...So that" | "Given-When-Then" |
|
||||
| `acceptanceCriteriaStyle` | AC format preference | "Checklist" | "BDD Scenarios" |
|
||||
| `storySize` | Preferred story sizing | "Story Points" | "T-Shirt Sizes" |
|
||||
| `definitionOfDone` | DoD requirements | "Standard" | "Custom Checklist" |
|
||||
| `prioritizationMethod` | Priority framework | "MoSCoW" | "RICE" |
|
||||
| `dependencyTracking` | Dependency management | "Manual" | "Automated" |
|
||||
|
||||
### Example Configuration
|
||||
|
||||
```yaml
|
||||
product_owner:
|
||||
storyFormat: "As a...I want...So that"
|
||||
acceptanceCriteriaStyle: "Given-When-Then BDD"
|
||||
storySize: "Story Points (Fibonacci)"
|
||||
definitionOfDone: "Custom DoD Checklist"
|
||||
prioritizationMethod: "RICE Framework"
|
||||
dependencyTracking: "Automated with Alerts"
|
||||
qualityGates: "Mandatory Stakeholder Review"
|
||||
communicationStyle: "Structured Updates"
|
||||
templateUsage: "Strict Template Adherence"
|
||||
```
|
||||
|
||||
### Quality Standards Configuration
|
||||
|
||||
```yaml
|
||||
quality_standards:
|
||||
story_completeness:
|
||||
required_fields: ["title", "description", "acceptance_criteria", "definition_of_done"]
|
||||
validation_rules: ["INVEST principles", "testable criteria", "clear business value"]
|
||||
|
||||
acceptance_criteria:
|
||||
minimum_criteria: 3
|
||||
format: "Given-When-Then"
|
||||
validation: "stakeholder_review_required"
|
||||
|
||||
definition_of_done:
|
||||
code_review: true
|
||||
testing: "unit_and_integration"
|
||||
documentation: "updated"
|
||||
stakeholder_approval: true
|
||||
```
|
||||
|
||||
### Team Integration Configuration
|
||||
|
||||
```yaml
|
||||
team_integration:
|
||||
development_team:
|
||||
story_handoff: "sprint_planning"
|
||||
clarification_process: "async_first"
|
||||
estimation_method: "planning_poker"
|
||||
|
||||
stakeholders:
|
||||
review_frequency: "weekly"
|
||||
approval_process: "formal_signoff"
|
||||
communication_channel: "email_and_slack"
|
||||
|
||||
scrum_master:
|
||||
collaboration_level: "high"
|
||||
process_alignment: "strict_adherence"
|
||||
metrics_sharing: "transparent"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
This integration guide provides comprehensive instructions for incorporating Sarah's product ownership expertise into your development workflow across different environments, tools, and agile frameworks. Sarah's systematic approach ensures that your development teams receive clear, actionable work that drives consistent project success.
|
||||
|
|
@ -0,0 +1,419 @@
|
|||
# Product Owner (Sarah) Quality Standards
|
||||
|
||||
## Overview
|
||||
|
||||
This document establishes comprehensive quality standards for Product Owner activities within the BMAD Method. These standards ensure consistent, high-quality product ownership that drives successful project outcomes and stakeholder satisfaction.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Quality Framework](#quality-framework)
|
||||
2. [Documentation Quality Standards](#documentation-quality-standards)
|
||||
3. [Story Quality Standards](#story-quality-standards)
|
||||
4. [Process Quality Standards](#process-quality-standards)
|
||||
5. [Communication Quality Standards](#communication-quality-standards)
|
||||
6. [Stakeholder Management Quality Standards](#stakeholder-management-quality-standards)
|
||||
7. [Quality Metrics and Measurement](#quality-metrics-and-measurement)
|
||||
8. [Quality Assurance Procedures](#quality-assurance-procedures)
|
||||
9. [Continuous Improvement](#continuous-improvement)
|
||||
|
||||
## Quality Framework
|
||||
|
||||
### Quality Principles
|
||||
|
||||
1. **Clarity**: All artifacts and communications are clear, unambiguous, and easily understood
|
||||
2. **Completeness**: All necessary information is included and nothing critical is missing
|
||||
3. **Consistency**: Standards and formats are applied uniformly across all work
|
||||
4. **Traceability**: Clear connections exist between business needs and implementation
|
||||
5. **Testability**: All requirements can be objectively validated and tested
|
||||
6. **Value-Focus**: Every activity and artifact contributes to business value delivery
|
||||
|
||||
### Quality Dimensions
|
||||
|
||||
#### Functional Quality
|
||||
- Requirements accuracy and completeness
|
||||
- Story clarity and testability
|
||||
- Acceptance criteria precision
|
||||
- Business value articulation
|
||||
|
||||
#### Process Quality
|
||||
- Adherence to defined processes
|
||||
- Timely delivery of artifacts
|
||||
- Stakeholder engagement effectiveness
|
||||
- Risk and dependency management
|
||||
|
||||
#### Communication Quality
|
||||
- Stakeholder satisfaction
|
||||
- Information clarity and timeliness
|
||||
- Feedback incorporation
|
||||
- Conflict resolution effectiveness
|
||||
|
||||
## Documentation Quality Standards
|
||||
|
||||
### User Story Documentation Standards
|
||||
|
||||
#### Story Structure Quality
|
||||
- [ ] **Title**: Clear, descriptive, and follows naming conventions
|
||||
- [ ] **Description**: Follows "As a...I want...So that" format correctly
|
||||
- [ ] **Acceptance Criteria**: Written in Given-When-Then format
|
||||
- [ ] **Definition of Done**: Complete and relevant to story scope
|
||||
- [ ] **Priority**: Clearly assigned using defined prioritization framework
|
||||
- [ ] **Estimate**: Story points assigned using team estimation process
|
||||
|
||||
#### Content Quality Criteria
|
||||
- [ ] **Business Value**: Clearly articulated and measurable
|
||||
- [ ] **User Persona**: Specific user type identified
|
||||
- [ ] **Functionality**: Precise description of required capability
|
||||
- [ ] **Benefit**: Clear explanation of value delivered
|
||||
- [ ] **Testability**: All criteria can be objectively tested
|
||||
- [ ] **Completeness**: All necessary information included
|
||||
|
||||
#### Documentation Standards
|
||||
- [ ] **Grammar**: Proper grammar and spelling throughout
|
||||
- [ ] **Formatting**: Consistent formatting and structure
|
||||
- [ ] **Links**: All references and links are valid and current
|
||||
- [ ] **Version Control**: Proper versioning and change tracking
|
||||
- [ ] **Accessibility**: Documents are accessible to all stakeholders
|
||||
|
||||
### Epic and Feature Documentation Standards
|
||||
|
||||
#### Epic Quality Criteria
|
||||
- [ ] **Business Objective**: Clear problem statement and business value
|
||||
- [ ] **Scope Definition**: Well-defined boundaries and scope
|
||||
- [ ] **Story Breakdown**: Complete decomposition into user stories
|
||||
- [ ] **Dependencies**: All dependencies identified and documented
|
||||
- [ ] **Success Criteria**: Measurable success metrics defined
|
||||
- [ ] **Timeline**: Realistic timeline with key milestones
|
||||
|
||||
#### Feature Specification Quality
|
||||
- [ ] **User Value**: Clear value proposition for target users
|
||||
- [ ] **Functional Requirements**: Complete functional specification
|
||||
- [ ] **Non-Functional Requirements**: Performance, security, accessibility requirements
|
||||
- [ ] **Integration Points**: System integration requirements documented
|
||||
- [ ] **Testing Strategy**: Comprehensive testing approach defined
|
||||
|
||||
### Backlog Documentation Standards
|
||||
|
||||
#### Backlog Structure Quality
|
||||
- [ ] **Organization**: Logical organization by theme, epic, or priority
|
||||
- [ ] **Prioritization**: Clear prioritization using defined framework
|
||||
- [ ] **Estimation**: All items estimated using consistent approach
|
||||
- [ ] **Status Tracking**: Current status clearly indicated
|
||||
- [ ] **Dependency Mapping**: Dependencies clearly identified and tracked
|
||||
|
||||
#### Backlog Content Quality
|
||||
- [ ] **Completeness**: All necessary backlog items included
|
||||
- [ ] **Currency**: Backlog reflects current business priorities
|
||||
- [ ] **Clarity**: All items clearly described and understood
|
||||
- [ ] **Traceability**: Clear connection to business objectives
|
||||
- [ ] **Actionability**: All items ready for development when prioritized
|
||||
|
||||
## Story Quality Standards
|
||||
|
||||
### INVEST Principles Compliance
|
||||
|
||||
#### Independent
|
||||
- [ ] **Standalone Value**: Story delivers value independently
|
||||
- [ ] **Minimal Dependencies**: Limited dependencies on other stories
|
||||
- [ ] **Development Independence**: Can be developed without waiting for other stories
|
||||
- [ ] **Testing Independence**: Can be tested independently
|
||||
|
||||
#### Negotiable
|
||||
- [ ] **Flexible Implementation**: Implementation details can be discussed
|
||||
- [ ] **Scope Adjustment**: Story scope can be adjusted if needed
|
||||
- [ ] **Solution Options**: Multiple implementation approaches possible
|
||||
- [ ] **Stakeholder Input**: Open to stakeholder feedback and refinement
|
||||
|
||||
#### Valuable
|
||||
- [ ] **Business Value**: Clear business value articulated
|
||||
- [ ] **User Value**: Delivers value to end users
|
||||
- [ ] **Measurable Impact**: Value can be measured and validated
|
||||
- [ ] **Priority Alignment**: Value aligns with business priorities
|
||||
|
||||
#### Estimable
|
||||
- [ ] **Clear Requirements**: Requirements are clear enough for estimation
|
||||
- [ ] **Technical Understanding**: Technical approach is understood
|
||||
- [ ] **Scope Definition**: Story scope is well-defined
|
||||
- [ ] **Complexity Assessment**: Complexity can be reasonably assessed
|
||||
|
||||
#### Small
|
||||
- [ ] **Sprint Completion**: Can be completed within a single sprint
|
||||
- [ ] **Focused Scope**: Addresses a single piece of functionality
|
||||
- [ ] **Manageable Complexity**: Complexity is manageable for the team
|
||||
- [ ] **Clear Boundaries**: Story boundaries are well-defined
|
||||
|
||||
#### Testable
|
||||
- [ ] **Objective Criteria**: Acceptance criteria are objective and measurable
|
||||
- [ ] **Test Scenarios**: Test scenarios can be defined
|
||||
- [ ] **Validation Methods**: Clear methods for validating completion
|
||||
- [ ] **Demo Capability**: Story can be demonstrated to stakeholders
|
||||
|
||||
### Acceptance Criteria Quality Standards
|
||||
|
||||
#### Criteria Structure
|
||||
- [ ] **Given-When-Then Format**: Uses proper BDD format
|
||||
- [ ] **Specific Conditions**: Initial conditions clearly specified
|
||||
- [ ] **Clear Actions**: Actions or triggers clearly defined
|
||||
- [ ] **Expected Outcomes**: Expected results clearly stated
|
||||
- [ ] **Edge Cases**: Important edge cases covered
|
||||
- [ ] **Error Conditions**: Error scenarios addressed
|
||||
|
||||
#### Criteria Content Quality
|
||||
- [ ] **Completeness**: All important scenarios covered
|
||||
- [ ] **Clarity**: Criteria are unambiguous and specific
|
||||
- [ ] **Testability**: Each criterion can be objectively tested
|
||||
- [ ] **Relevance**: All criteria are relevant to story value
|
||||
- [ ] **Achievability**: Criteria are technically feasible
|
||||
- [ ] **Measurability**: Success can be objectively measured
|
||||
|
||||
### Definition of Done Quality Standards
|
||||
|
||||
#### DoD Completeness
|
||||
- [ ] **Development Criteria**: Code completion and review requirements
|
||||
- [ ] **Testing Criteria**: Unit, integration, and acceptance testing requirements
|
||||
- [ ] **Quality Criteria**: Code quality and performance standards
|
||||
- [ ] **Documentation Criteria**: Documentation update requirements
|
||||
- [ ] **Deployment Criteria**: Deployment and configuration requirements
|
||||
- [ ] **Approval Criteria**: Stakeholder approval requirements
|
||||
|
||||
#### DoD Relevance
|
||||
- [ ] **Story Appropriate**: DoD is appropriate for story type and scope
|
||||
- [ ] **Team Aligned**: DoD reflects team capabilities and processes
|
||||
- [ ] **Quality Focused**: DoD ensures appropriate quality levels
|
||||
- [ ] **Stakeholder Aligned**: DoD meets stakeholder expectations
|
||||
|
||||
## Process Quality Standards
|
||||
|
||||
### Sprint Planning Quality Standards
|
||||
|
||||
#### Planning Preparation
|
||||
- [ ] **Backlog Readiness**: Product backlog is refined and prioritized
|
||||
- [ ] **Story Readiness**: Stories are estimated and have clear acceptance criteria
|
||||
- [ ] **Capacity Planning**: Team capacity is calculated and documented
|
||||
- [ ] **Dependency Resolution**: Dependencies are identified and resolved
|
||||
- [ ] **Stakeholder Availability**: Key stakeholders are available for clarification
|
||||
|
||||
#### Planning Execution
|
||||
- [ ] **Goal Setting**: Clear sprint goal is defined and agreed
|
||||
- [ ] **Story Selection**: Stories are selected based on priority and capacity
|
||||
- [ ] **Task Breakdown**: Stories are broken down into actionable tasks
|
||||
- [ ] **Commitment**: Team commits to realistic sprint scope
|
||||
- [ ] **Risk Assessment**: Risks are identified and mitigation planned
|
||||
|
||||
### Backlog Refinement Quality Standards
|
||||
|
||||
#### Refinement Process
|
||||
- [ ] **Regular Cadence**: Refinement occurs on regular schedule
|
||||
- [ ] **Stakeholder Participation**: Appropriate stakeholders participate
|
||||
- [ ] **Story Preparation**: Stories are prepared for upcoming sprints
|
||||
- [ ] **Estimation Updates**: Estimates are updated based on new information
|
||||
- [ ] **Priority Adjustment**: Priorities are adjusted based on business changes
|
||||
|
||||
#### Refinement Outcomes
|
||||
- [ ] **Story Clarity**: Stories are clear and well-understood
|
||||
- [ ] **Acceptance Criteria**: Acceptance criteria are complete and testable
|
||||
- [ ] **Estimation Accuracy**: Estimates reflect current understanding
|
||||
- [ ] **Dependency Identification**: Dependencies are identified and planned
|
||||
- [ ] **Risk Assessment**: Risks are identified and documented
|
||||
|
||||
### Stakeholder Engagement Quality Standards
|
||||
|
||||
#### Engagement Planning
|
||||
- [ ] **Stakeholder Identification**: All relevant stakeholders identified
|
||||
- [ ] **Communication Plan**: Clear communication plan established
|
||||
- [ ] **Meeting Cadence**: Regular meeting schedule established
|
||||
- [ ] **Feedback Mechanisms**: Clear feedback collection processes
|
||||
- [ ] **Decision Processes**: Clear decision-making processes defined
|
||||
|
||||
#### Engagement Execution
|
||||
- [ ] **Timely Communication**: Stakeholders receive timely updates
|
||||
- [ ] **Clear Information**: Information is clear and actionable
|
||||
- [ ] **Feedback Integration**: Stakeholder feedback is incorporated
|
||||
- [ ] **Expectation Management**: Stakeholder expectations are managed
|
||||
- [ ] **Conflict Resolution**: Conflicts are resolved effectively
|
||||
|
||||
## Communication Quality Standards
|
||||
|
||||
### Stakeholder Communication Standards
|
||||
|
||||
#### Communication Content Quality
|
||||
- [ ] **Relevance**: Information is relevant to stakeholder needs
|
||||
- [ ] **Accuracy**: Information is accurate and up-to-date
|
||||
- [ ] **Completeness**: All necessary information is included
|
||||
- [ ] **Clarity**: Information is clear and easily understood
|
||||
- [ ] **Actionability**: Clear actions or decisions are identified
|
||||
|
||||
#### Communication Delivery Quality
|
||||
- [ ] **Timeliness**: Information is delivered when needed
|
||||
- [ ] **Appropriate Channel**: Correct communication channel is used
|
||||
- [ ] **Audience Targeting**: Content is tailored to audience needs
|
||||
- [ ] **Follow-up**: Appropriate follow-up is conducted
|
||||
- [ ] **Documentation**: Important communications are documented
|
||||
|
||||
### Sprint Review Communication Standards
|
||||
|
||||
#### Review Preparation
|
||||
- [ ] **Demo Preparation**: Demonstrations are well-prepared and tested
|
||||
- [ ] **Stakeholder Invitation**: Appropriate stakeholders are invited
|
||||
- [ ] **Agenda Distribution**: Clear agenda is distributed in advance
|
||||
- [ ] **Material Preparation**: Supporting materials are prepared
|
||||
- [ ] **Environment Setup**: Demo environment is properly configured
|
||||
|
||||
#### Review Execution
|
||||
- [ ] **Goal Alignment**: Review focuses on sprint goal achievement
|
||||
- [ ] **Value Demonstration**: Business value is clearly demonstrated
|
||||
- [ ] **Feedback Collection**: Stakeholder feedback is actively collected
|
||||
- [ ] **Next Steps**: Clear next steps are identified and communicated
|
||||
- [ ] **Action Items**: Action items are documented and assigned
|
||||
|
||||
## Quality Metrics and Measurement
|
||||
|
||||
### Story Quality Metrics
|
||||
|
||||
#### Story Completion Metrics
|
||||
- **Story Completion Rate**: Percentage of committed stories completed per sprint
|
||||
- **Story Rejection Rate**: Percentage of stories rejected during review
|
||||
- **Story Rework Rate**: Percentage of stories requiring significant rework
|
||||
- **Story Cycle Time**: Average time from story creation to completion
|
||||
|
||||
#### Story Quality Metrics
|
||||
- **Acceptance Criteria Coverage**: Average number of acceptance criteria per story
|
||||
- **Defect Rate**: Number of defects found per story after completion
|
||||
- **Stakeholder Satisfaction**: Stakeholder satisfaction with delivered stories
|
||||
- **INVEST Compliance**: Percentage of stories meeting INVEST principles
|
||||
|
||||
### Process Quality Metrics
|
||||
|
||||
#### Sprint Planning Metrics
|
||||
- **Planning Efficiency**: Time spent in planning relative to sprint duration
|
||||
- **Commitment Accuracy**: Accuracy of sprint commitments vs. actual delivery
|
||||
- **Planning Preparation**: Percentage of stories ready for planning
|
||||
- **Goal Achievement**: Percentage of sprint goals achieved
|
||||
|
||||
#### Backlog Quality Metrics
|
||||
- **Backlog Health**: Ratio of ready stories to total backlog items
|
||||
- **Estimation Accuracy**: Accuracy of story point estimates
|
||||
- **Priority Stability**: Frequency of priority changes
|
||||
- **Dependency Resolution**: Time to resolve identified dependencies
|
||||
|
||||
### Communication Quality Metrics
|
||||
|
||||
#### Stakeholder Engagement Metrics
|
||||
- **Stakeholder Satisfaction**: Regular stakeholder satisfaction surveys
|
||||
- **Communication Effectiveness**: Feedback on communication clarity and timeliness
|
||||
- **Meeting Efficiency**: Stakeholder feedback on meeting effectiveness
|
||||
- **Decision Speed**: Time from issue identification to decision
|
||||
|
||||
#### Information Quality Metrics
|
||||
- **Information Accuracy**: Accuracy of information provided to stakeholders
|
||||
- **Information Timeliness**: Timeliness of information delivery
|
||||
- **Information Completeness**: Completeness of information provided
|
||||
- **Information Usefulness**: Stakeholder assessment of information value
|
||||
|
||||
## Quality Assurance Procedures
|
||||
|
||||
### Story Quality Assurance Process
|
||||
|
||||
#### Story Creation QA
|
||||
1. **Template Compliance**: Verify story follows standard template
|
||||
2. **INVEST Validation**: Validate story meets INVEST principles
|
||||
3. **Acceptance Criteria Review**: Review acceptance criteria for completeness and testability
|
||||
4. **Business Value Validation**: Confirm business value is clearly articulated
|
||||
5. **Dependency Check**: Identify and document dependencies
|
||||
6. **Stakeholder Review**: Obtain stakeholder review and approval
|
||||
|
||||
#### Story Refinement QA
|
||||
1. **Clarity Assessment**: Assess story clarity and understanding
|
||||
2. **Estimation Validation**: Validate estimation accuracy and rationale
|
||||
3. **Acceptance Criteria Update**: Update acceptance criteria based on new information
|
||||
4. **Risk Assessment**: Assess and document story risks
|
||||
5. **Priority Validation**: Confirm story priority alignment with business objectives
|
||||
|
||||
### Process Quality Assurance
|
||||
|
||||
#### Sprint Planning QA
|
||||
1. **Preparation Checklist**: Verify all planning preparation completed
|
||||
2. **Goal Definition**: Ensure sprint goal is clear and achievable
|
||||
3. **Capacity Validation**: Validate team capacity calculations
|
||||
4. **Commitment Review**: Review team commitment for realism
|
||||
5. **Risk Mitigation**: Ensure risks are identified and mitigation planned
|
||||
|
||||
#### Backlog Management QA
|
||||
1. **Prioritization Review**: Review prioritization logic and rationale
|
||||
2. **Readiness Assessment**: Assess story readiness for development
|
||||
3. **Dependency Mapping**: Validate dependency identification and planning
|
||||
4. **Quality Standards**: Ensure all backlog items meet quality standards
|
||||
5. **Stakeholder Alignment**: Confirm backlog alignment with stakeholder expectations
|
||||
|
||||
### Communication Quality Assurance
|
||||
|
||||
#### Stakeholder Communication QA
|
||||
1. **Content Review**: Review communication content for accuracy and completeness
|
||||
2. **Audience Appropriateness**: Ensure content is appropriate for target audience
|
||||
3. **Timing Validation**: Validate communication timing and frequency
|
||||
4. **Feedback Integration**: Ensure stakeholder feedback is incorporated
|
||||
5. **Follow-up Tracking**: Track and ensure appropriate follow-up
|
||||
|
||||
#### Documentation QA
|
||||
1. **Accuracy Verification**: Verify accuracy of all documented information
|
||||
2. **Completeness Check**: Ensure all necessary information is documented
|
||||
3. **Format Compliance**: Verify compliance with documentation standards
|
||||
4. **Accessibility Review**: Ensure documentation is accessible to all stakeholders
|
||||
5. **Version Control**: Ensure proper version control and change tracking
|
||||
|
||||
## Continuous Improvement
|
||||
|
||||
### Quality Improvement Process
|
||||
|
||||
#### Regular Quality Reviews
|
||||
- **Weekly**: Review current sprint quality metrics and issues
|
||||
- **Sprint Retrospectives**: Include quality focus in sprint retrospectives
|
||||
- **Monthly**: Comprehensive quality metrics review and analysis
|
||||
- **Quarterly**: Quality standards review and update
|
||||
|
||||
#### Improvement Identification
|
||||
1. **Metric Analysis**: Analyze quality metrics to identify improvement opportunities
|
||||
2. **Stakeholder Feedback**: Collect and analyze stakeholder feedback
|
||||
3. **Team Input**: Gather team input on quality challenges and solutions
|
||||
4. **Best Practice Research**: Research industry best practices and standards
|
||||
5. **Root Cause Analysis**: Conduct root cause analysis for quality issues
|
||||
|
||||
#### Improvement Implementation
|
||||
1. **Improvement Planning**: Develop specific improvement plans and timelines
|
||||
2. **Standard Updates**: Update quality standards based on lessons learned
|
||||
3. **Process Refinement**: Refine processes to address quality gaps
|
||||
4. **Training and Development**: Provide training to address skill gaps
|
||||
5. **Tool Enhancement**: Enhance tools and templates to support quality
|
||||
|
||||
### Quality Culture Development
|
||||
|
||||
#### Team Quality Awareness
|
||||
- **Quality Training**: Regular training on quality standards and practices
|
||||
- **Quality Metrics Sharing**: Share quality metrics and trends with team
|
||||
- **Quality Recognition**: Recognize and celebrate quality achievements
|
||||
- **Quality Discussions**: Regular discussions about quality in team meetings
|
||||
|
||||
#### Stakeholder Quality Engagement
|
||||
- **Quality Expectations**: Clearly communicate quality expectations to stakeholders
|
||||
- **Quality Feedback**: Actively seek stakeholder feedback on quality
|
||||
- **Quality Transparency**: Maintain transparency about quality metrics and issues
|
||||
- **Quality Collaboration**: Collaborate with stakeholders on quality improvement
|
||||
|
||||
### Quality Standards Evolution
|
||||
|
||||
#### Standards Review Process
|
||||
1. **Regular Assessment**: Regularly assess effectiveness of current standards
|
||||
2. **Industry Benchmarking**: Benchmark standards against industry best practices
|
||||
3. **Stakeholder Input**: Gather stakeholder input on standards effectiveness
|
||||
4. **Team Feedback**: Collect team feedback on standards usability
|
||||
5. **Continuous Refinement**: Continuously refine standards based on experience
|
||||
|
||||
#### Standards Update Process
|
||||
1. **Change Proposal**: Formal process for proposing standards changes
|
||||
2. **Impact Assessment**: Assess impact of proposed changes
|
||||
3. **Stakeholder Review**: Review proposed changes with stakeholders
|
||||
4. **Implementation Planning**: Plan implementation of approved changes
|
||||
5. **Change Communication**: Communicate changes to all affected parties
|
||||
|
||||
---
|
||||
|
||||
These comprehensive quality standards ensure that Product Owner activities within the BMAD Method consistently deliver high-quality outcomes that drive project success and stakeholder satisfaction. Regular application and continuous improvement of these standards will enhance the effectiveness of product ownership practices.
|
||||
|
|
@ -0,0 +1,320 @@
|
|||
# Product Owner (Sarah) Quick Start Guide
|
||||
|
||||
Get up and running with Sarah, the Product Owner persona, in just 5 minutes. This guide provides everything you need to start creating sprint-ready user stories and managing your product backlog effectively.
|
||||
|
||||
## 1. Choose Your Environment
|
||||
|
||||
Sarah can be used in two environments:
|
||||
|
||||
### Web Environment (Sarah)
|
||||
- Use with ChatGPT, Claude, or other web-based AI platforms
|
||||
- Ideal for story creation and backlog management
|
||||
- No setup required
|
||||
|
||||
### IDE Environment (Sarah)
|
||||
- Use with Cursor AI, Claude Code, Cline, or Roocode
|
||||
- Ideal for development-integrated story preparation
|
||||
- Requires minimal setup
|
||||
|
||||
## 2. Activate the Persona
|
||||
|
||||
### Web Environment
|
||||
1. Copy the contents of `bmad-agent/personas/po.md`
|
||||
2. Paste as your first message to the AI
|
||||
3. Use an activation phrase: "I need Sarah to help prepare user stories for development"
|
||||
|
||||
### IDE Environment
|
||||
1. Copy the `bmad-agent` folder to your project root
|
||||
2. Reference the persona file in your IDE's AI feature
|
||||
3. Use an activation phrase: "Sarah, help me break down these requirements into stories"
|
||||
|
||||
## 3. Provide Clear Context
|
||||
|
||||
For best story preparation, include:
|
||||
|
||||
- **Project Overview**: What you're building and for whom
|
||||
- **Requirements**: Features, functionality, and business rules
|
||||
- **Constraints**: Technical limitations, timeline, team capabilities
|
||||
- **Quality Standards**: Definition of done, acceptance criteria format
|
||||
- **Sprint Context**: Sprint length, team velocity, story sizing method
|
||||
|
||||
### Example Prompt
|
||||
|
||||
```
|
||||
Sarah, I need to prepare user stories for a mobile expense tracking app. Here's the context:
|
||||
|
||||
Project Overview:
|
||||
- Personal finance app for tracking business expenses
|
||||
- Target users: freelancers and small business owners
|
||||
- Mobile-first design with web dashboard
|
||||
|
||||
Key Features to Break Down:
|
||||
- Expense entry with photo capture
|
||||
- Category management and tagging
|
||||
- Receipt scanning with OCR
|
||||
- Monthly/quarterly reporting
|
||||
- Export to accounting software
|
||||
- Multi-currency support
|
||||
|
||||
Constraints:
|
||||
- 2-week sprints with 5-person development team
|
||||
- React Native for mobile, React for web
|
||||
- Team velocity: 40 story points per sprint
|
||||
- Must integrate with existing user authentication system
|
||||
|
||||
Quality Standards:
|
||||
- Stories should be completable within one sprint
|
||||
- Use Given-When-Then format for acceptance criteria
|
||||
- Include testing requirements in definition of done
|
||||
- Require stakeholder review before development
|
||||
```
|
||||
|
||||
## 4. Review and Refine
|
||||
|
||||
1. Review Sarah's initial story breakdown
|
||||
2. Ask for clarification on acceptance criteria
|
||||
3. Request story splitting if stories are too large
|
||||
4. Validate dependencies and sequencing
|
||||
|
||||
## 5. Prepare for Sprint Planning
|
||||
|
||||
1. Prioritize stories based on business value
|
||||
2. Ensure stories are estimation-ready
|
||||
3. Identify any blockers or dependencies
|
||||
4. Prepare context for development team
|
||||
|
||||
## Example: Breaking Down an E-commerce Feature
|
||||
|
||||
### Step 1: Activate Sarah
|
||||
|
||||
"I need Sarah to help break down e-commerce checkout functionality into sprint-ready user stories."
|
||||
|
||||
### Step 2: Provide Context
|
||||
|
||||
"We're building a checkout flow for an online marketplace. Users need to review their cart, enter shipping information, select payment method, and complete purchase. The system must handle inventory validation, payment processing, and order confirmation."
|
||||
|
||||
### Step 3: Review Story Breakdown
|
||||
|
||||
Sarah will provide detailed user stories like:
|
||||
|
||||
#### Story 1: Cart Review and Modification
|
||||
```markdown
|
||||
## User Story: Cart Review and Modification
|
||||
|
||||
**As a** customer
|
||||
**I want** to review and modify my shopping cart before checkout
|
||||
**So that** I can ensure I'm purchasing the correct items and quantities
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] Given I'm on the checkout page, when I view my cart, then I see all items with names, prices, and quantities
|
||||
- [ ] Given I'm reviewing my cart, when I change item quantities, then the subtotal updates immediately
|
||||
- [ ] Given I'm reviewing my cart, when I remove an item, then it's removed from cart and totals update
|
||||
- [ ] Given my cart is empty, when I try to proceed to checkout, then I see an appropriate message
|
||||
|
||||
### Definition of Done
|
||||
- [ ] Code complete and reviewed
|
||||
- [ ] Unit tests written and passing
|
||||
- [ ] Integration tests for cart operations
|
||||
- [ ] Responsive design tested on mobile and desktop
|
||||
- [ ] Accessibility requirements met
|
||||
- [ ] Stakeholder approval received
|
||||
|
||||
**Story Points**: 5
|
||||
**Priority**: High
|
||||
**Dependencies**: None
|
||||
```
|
||||
|
||||
### Step 4: Refine Stories
|
||||
|
||||
"Sarah, the cart modification story seems large. Can you split it into smaller stories? Also, what dependencies exist between the checkout stories?"
|
||||
|
||||
### Step 5: Sprint Planning Preparation
|
||||
|
||||
Sarah provides:
|
||||
- Prioritized story list
|
||||
- Dependency map
|
||||
- Estimation guidance
|
||||
- Risk assessment
|
||||
|
||||
## Common Story Patterns
|
||||
|
||||
### Feature Story Pattern
|
||||
```markdown
|
||||
**As a** [user type]
|
||||
**I want** [functionality]
|
||||
**So that** [business value]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] Given [context], when [action], then [expected result]
|
||||
- [ ] [Additional criteria...]
|
||||
|
||||
### Definition of Done
|
||||
- [ ] [Standard DoD items...]
|
||||
```
|
||||
|
||||
### Technical Story Pattern
|
||||
```markdown
|
||||
**As a** developer
|
||||
**I want** [technical capability]
|
||||
**So that** [technical benefit]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] [Technical acceptance criteria...]
|
||||
|
||||
### Definition of Done
|
||||
- [ ] [Technical DoD items...]
|
||||
```
|
||||
|
||||
### Bug Fix Story Pattern
|
||||
```markdown
|
||||
**As a** [affected user]
|
||||
**I want** [issue resolved]
|
||||
**So that** [normal functionality restored]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] Given [bug scenario], when [action], then [correct behavior]
|
||||
- [ ] [Regression prevention criteria...]
|
||||
```
|
||||
|
||||
## Quick Reference Commands
|
||||
|
||||
### Story Creation
|
||||
```
|
||||
"Sarah, break down [feature/epic] into user stories"
|
||||
"Create acceptance criteria for [story description]"
|
||||
"Split this story into smaller, sprint-sized stories"
|
||||
```
|
||||
|
||||
### Story Refinement
|
||||
```
|
||||
"Sarah, review these stories for completeness"
|
||||
"Add missing acceptance criteria to [story]"
|
||||
"Validate these stories against INVEST principles"
|
||||
```
|
||||
|
||||
### Backlog Management
|
||||
```
|
||||
"Sarah, prioritize these stories based on business value"
|
||||
"Identify dependencies between these stories"
|
||||
"Prepare these stories for sprint planning"
|
||||
```
|
||||
|
||||
### Quality Assurance
|
||||
```
|
||||
"Sarah, run the PO master checklist on these stories"
|
||||
"Validate story quality and completeness"
|
||||
"Check for missing information or ambiguities"
|
||||
```
|
||||
|
||||
## Best Practices Checklist
|
||||
|
||||
### Story Quality
|
||||
- [ ] Stories follow INVEST principles
|
||||
- [ ] Acceptance criteria are testable and specific
|
||||
- [ ] Business value is clearly articulated
|
||||
- [ ] Stories are appropriately sized for sprint completion
|
||||
|
||||
### Process Adherence
|
||||
- [ ] Stories use consistent templates
|
||||
- [ ] Definition of done is complete and relevant
|
||||
- [ ] Dependencies are identified and documented
|
||||
- [ ] Stakeholder review is planned
|
||||
|
||||
### Team Readiness
|
||||
- [ ] Stories have sufficient detail for estimation
|
||||
- [ ] Technical context is provided where needed
|
||||
- [ ] Questions and assumptions are documented
|
||||
- [ ] Stories are prioritized and sequenced
|
||||
|
||||
## Next Steps
|
||||
|
||||
- Explore the [Comprehensive Guide](./po-comprehensive-guide.md) for detailed product ownership guidance
|
||||
- Check the [Integration Guide](./po-integration-guide.md) for workflow integration
|
||||
- Review the [PO Master Checklist](../bmad-agent/checklists/po-master-checklist.md) for quality validation
|
||||
- Use the [Story Template](../bmad-agent/templates/story-tmpl.md) for consistent documentation
|
||||
|
||||
---
|
||||
|
||||
Start creating sprint-ready user stories today with Sarah's systematic approach to product ownership!
|
||||
|
||||
# Sprint 1 Status Tracking
|
||||
|
||||
## Sprint Overview
|
||||
- **Sprint Duration**: 2 weeks
|
||||
- **Sprint Goal**: Complete Phase 1 of the BMAD Documentation Enhancement project
|
||||
- **Total Story Points**: 26
|
||||
|
||||
## Story Status
|
||||
|
||||
### ✅ Story 1.1: Create UX/UI Architect Documentation Package (8 points) - COMPLETE
|
||||
**Status**: ✅ DONE
|
||||
**Completed**: Current Date
|
||||
|
||||
### ✅ Story 1.2a: Product Manager Documentation Package (4 points) - COMPLETE
|
||||
**Status**: ✅ DONE
|
||||
**Completed**: Current Date
|
||||
**Deliverables**:
|
||||
- ✅ PM Comprehensive Guide (docs/pm-comprehensive-guide.md)
|
||||
- ✅ PM Integration Guide (docs/pm-integration-guide.md)
|
||||
- ✅ PM Quick Start Guide (docs/pm-quickstart.md)
|
||||
|
||||
### ✅ Story 1.2b: System Architect Documentation Package (4 points) - COMPLETE
|
||||
**Status**: ✅ DONE
|
||||
**Completed**: Current Date
|
||||
**Deliverables**:
|
||||
- ✅ System Architect Comprehensive Guide (docs/architect-comprehensive-guide.md)
|
||||
- ✅ System Architect Integration Guide (docs/architect-integration-guide.md)
|
||||
- ✅ System Architect Quick Start Guide (docs/architect-quickstart.md)
|
||||
|
||||
### ✅ Story 1.2c: Product Owner Documentation Package (4 points) - COMPLETE
|
||||
**Status**: ✅ DONE
|
||||
**Completed**: Current Date
|
||||
**Deliverables**:
|
||||
- ✅ Product Owner Comprehensive Guide (docs/po-comprehensive-guide.md)
|
||||
- ✅ Product Owner Integration Guide (docs/po-integration-guide.md)
|
||||
- ✅ Product Owner Quick Start Guide (docs/po-quickstart.md)
|
||||
|
||||
**Acceptance Criteria Met**:
|
||||
- ✅ Create Product Owner Comprehensive Guide
|
||||
- ✅ Create Product Owner Integration Guide
|
||||
- ✅ Create Product Owner Quick Start Guide
|
||||
- ✅ Validate documentation follows template standards
|
||||
|
||||
### â³ Story 1.3: Create IDE-Specific Setup Guides (5 points) - TODO
|
||||
**Status**: â³ TODO
|
||||
**Acceptance Criteria**:
|
||||
- [ ] Complete setup guides for all supported IDEs
|
||||
- [ ] Include troubleshooting sections
|
||||
- [ ] Add configuration examples
|
||||
- [ ] Test guides with fresh installations
|
||||
|
||||
### â³ Story 1.4: Develop Quick-Start Documentation (3 points) - TODO
|
||||
**Status**: â³ TODO
|
||||
**Acceptance Criteria**:
|
||||
- [ ] Create 5-minute quick-start guide
|
||||
- [ ] Include common use case examples
|
||||
- [ ] Add video walkthrough scripts
|
||||
- [ ] Validate with new users
|
||||
|
||||
### â³ Story 1.5: Implement Documentation Standards (2 points) - TODO
|
||||
**Status**: â³ TODO
|
||||
**Acceptance Criteria**:
|
||||
- [ ] Create documentation style guide
|
||||
- [ ] Implement automated formatting checks
|
||||
- [ ] Set up documentation review process
|
||||
- [ ] Create contribution guidelines
|
||||
|
||||
## Sprint Progress
|
||||
- **Completed**: 20/26 story points (77%)
|
||||
- **In Progress**: 0 story points
|
||||
- **Remaining**: 6 story points
|
||||
- **Days Remaining**: 8 days
|
||||
|
||||
## Next Actions
|
||||
1. ✅ Complete Product Manager documentation package
|
||||
2. ✅ Complete System Architect documentation package
|
||||
3. ✅ Complete Product Owner documentation package
|
||||
4. â³ Begin Story 1.3: Create IDE-Specific Setup Guides (5 points)
|
||||
|
||||
---
|
||||
*Updated by David - Developer*
|
||||
|
|
@ -0,0 +1,531 @@
|
|||
# Product Owner (Sarah) Success Metrics
|
||||
|
||||
## Overview
|
||||
|
||||
This document defines comprehensive success metrics for Product Owner activities within the BMAD Method. These metrics enable measurement, tracking, and continuous improvement of product ownership effectiveness and project outcomes.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Metrics Framework](#metrics-framework)
|
||||
2. [Story Quality Metrics](#story-quality-metrics)
|
||||
3. [Process Efficiency Metrics](#process-efficiency-metrics)
|
||||
4. [Stakeholder Satisfaction Metrics](#stakeholder-satisfaction-metrics)
|
||||
5. [Business Value Metrics](#business-value-metrics)
|
||||
6. [Team Performance Metrics](#team-performance-metrics)
|
||||
7. [Quality Assurance Metrics](#quality-assurance-metrics)
|
||||
8. [Measurement Methodologies](#measurement-methodologies)
|
||||
9. [Reporting and Analysis](#reporting-and-analysis)
|
||||
10. [Continuous Improvement](#continuous-improvement)
|
||||
|
||||
## Metrics Framework
|
||||
|
||||
### Metric Categories
|
||||
|
||||
#### Leading Indicators
|
||||
- Story readiness and quality
|
||||
- Backlog health and preparation
|
||||
- Stakeholder engagement levels
|
||||
- Process adherence rates
|
||||
|
||||
#### Lagging Indicators
|
||||
- Sprint completion rates
|
||||
- Stakeholder satisfaction scores
|
||||
- Business value delivered
|
||||
- Quality outcomes achieved
|
||||
|
||||
### Measurement Principles
|
||||
|
||||
1. **Actionable**: Metrics drive specific actions and improvements
|
||||
2. **Relevant**: Metrics align with business objectives and success criteria
|
||||
3. **Timely**: Metrics are available when needed for decision-making
|
||||
4. **Accurate**: Metrics reflect true performance and outcomes
|
||||
5. **Balanced**: Metrics cover all aspects of product ownership effectiveness
|
||||
|
||||
## Story Quality Metrics
|
||||
|
||||
### Story Completeness Metrics
|
||||
|
||||
#### Story Readiness Rate
|
||||
- **Definition**: Percentage of stories that are ready for development when needed
|
||||
- **Formula**: (Ready Stories / Total Stories Needed) × 100
|
||||
- **Target**: ≥ 95%
|
||||
- **Measurement Frequency**: Weekly
|
||||
- **Data Source**: Product backlog tracking
|
||||
|
||||
#### Acceptance Criteria Completeness
|
||||
- **Definition**: Average number of acceptance criteria per story
|
||||
- **Formula**: Total Acceptance Criteria / Total Stories
|
||||
- **Target**: ≥ 3 criteria per story
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Story documentation analysis
|
||||
|
||||
#### INVEST Compliance Rate
|
||||
- **Definition**: Percentage of stories meeting all INVEST principles
|
||||
- **Formula**: (INVEST Compliant Stories / Total Stories) × 100
|
||||
- **Target**: ≥ 90%
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Story quality assessments
|
||||
|
||||
### Story Accuracy Metrics
|
||||
|
||||
#### Story Rejection Rate
|
||||
- **Definition**: Percentage of stories rejected during development or review
|
||||
- **Formula**: (Rejected Stories / Total Stories Started) × 100
|
||||
- **Target**: ≤ 5%
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Development team feedback
|
||||
|
||||
#### Story Rework Rate
|
||||
- **Definition**: Percentage of stories requiring significant rework
|
||||
- **Formula**: (Reworked Stories / Total Completed Stories) × 100
|
||||
- **Target**: ≤ 10%
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Development tracking
|
||||
|
||||
#### Acceptance Criteria Change Rate
|
||||
- **Definition**: Percentage of stories with acceptance criteria changes during development
|
||||
- **Formula**: (Stories with AC Changes / Total Stories) × 100
|
||||
- **Target**: ≤ 15%
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Story change tracking
|
||||
|
||||
### Story Value Metrics
|
||||
|
||||
#### Business Value Score
|
||||
- **Definition**: Average business value rating of completed stories
|
||||
- **Formula**: Sum of Business Value Scores / Number of Stories
|
||||
- **Target**: ≥ 7/10
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Stakeholder value assessments
|
||||
|
||||
#### User Impact Score
|
||||
- **Definition**: Average user impact rating of delivered features
|
||||
- **Formula**: Sum of User Impact Scores / Number of Features
|
||||
- **Target**: ≥ 8/10
|
||||
- **Measurement Frequency**: Release
|
||||
- **Data Source**: User feedback and analytics
|
||||
|
||||
## Process Efficiency Metrics
|
||||
|
||||
### Sprint Planning Metrics
|
||||
|
||||
#### Planning Efficiency
|
||||
- **Definition**: Time spent in sprint planning relative to sprint duration
|
||||
- **Formula**: (Planning Time / Sprint Duration) × 100
|
||||
- **Target**: ≤ 5%
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Meeting time tracking
|
||||
|
||||
#### Commitment Accuracy
|
||||
- **Definition**: Accuracy of sprint commitments vs. actual delivery
|
||||
- **Formula**: (Delivered Story Points / Committed Story Points) × 100
|
||||
- **Target**: 85-115%
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Sprint tracking
|
||||
|
||||
#### Story Preparation Lead Time
|
||||
- **Definition**: Average time from story creation to sprint-ready status
|
||||
- **Formula**: Sum of Preparation Times / Number of Stories
|
||||
- **Target**: ≤ 2 weeks
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Story lifecycle tracking
|
||||
|
||||
### Backlog Management Metrics
|
||||
|
||||
#### Backlog Health Score
|
||||
- **Definition**: Percentage of backlog items that are ready for development
|
||||
- **Formula**: (Ready Backlog Items / Total Backlog Items) × 100
|
||||
- **Target**: ≥ 80%
|
||||
- **Measurement Frequency**: Weekly
|
||||
- **Data Source**: Backlog analysis
|
||||
|
||||
#### Priority Stability
|
||||
- **Definition**: Frequency of priority changes in the backlog
|
||||
- **Formula**: Priority Changes / Total Backlog Items
|
||||
- **Target**: ≤ 0.2 changes per item per month
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Priority change tracking
|
||||
|
||||
#### Estimation Accuracy
|
||||
- **Definition**: Accuracy of story point estimates vs. actual effort
|
||||
- **Formula**: |Estimated Points - Actual Points| / Estimated Points × 100
|
||||
- **Target**: ≤ 20% variance
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Estimation vs. actual tracking
|
||||
|
||||
### Dependency Management Metrics
|
||||
|
||||
#### Dependency Resolution Time
|
||||
- **Definition**: Average time to resolve identified dependencies
|
||||
- **Formula**: Sum of Resolution Times / Number of Dependencies
|
||||
- **Target**: ≤ 1 week
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Dependency tracking
|
||||
|
||||
#### Dependency Impact Rate
|
||||
- **Definition**: Percentage of stories impacted by unresolved dependencies
|
||||
- **Formula**: (Stories Blocked by Dependencies / Total Stories) × 100
|
||||
- **Target**: ≤ 10%
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Blocker tracking
|
||||
|
||||
## Stakeholder Satisfaction Metrics
|
||||
|
||||
### Communication Effectiveness Metrics
|
||||
|
||||
#### Stakeholder Satisfaction Score
|
||||
- **Definition**: Average stakeholder satisfaction with product ownership
|
||||
- **Formula**: Sum of Satisfaction Scores / Number of Stakeholders
|
||||
- **Target**: ≥ 4.5/5
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Stakeholder surveys
|
||||
|
||||
#### Communication Timeliness
|
||||
- **Definition**: Percentage of communications delivered on time
|
||||
- **Formula**: (On-Time Communications / Total Communications) × 100
|
||||
- **Target**: ≥ 95%
|
||||
- **Measurement Frequency**: Weekly
|
||||
- **Data Source**: Communication tracking
|
||||
|
||||
#### Information Accuracy Rate
|
||||
- **Definition**: Percentage of information provided that is accurate
|
||||
- **Formula**: (Accurate Information / Total Information) × 100
|
||||
- **Target**: ≥ 98%
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Information validation
|
||||
|
||||
### Engagement Metrics
|
||||
|
||||
#### Stakeholder Meeting Attendance
|
||||
- **Definition**: Average attendance rate at stakeholder meetings
|
||||
- **Formula**: (Attendees / Invited Stakeholders) × 100
|
||||
- **Target**: ≥ 85%
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Meeting attendance tracking
|
||||
|
||||
#### Feedback Response Rate
|
||||
- **Definition**: Percentage of stakeholder feedback requests that receive responses
|
||||
- **Formula**: (Responses Received / Feedback Requests) × 100
|
||||
- **Target**: ≥ 90%
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Feedback tracking
|
||||
|
||||
#### Decision Speed
|
||||
- **Definition**: Average time from issue identification to stakeholder decision
|
||||
- **Formula**: Sum of Decision Times / Number of Decisions
|
||||
- **Target**: ≤ 3 days
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Decision tracking
|
||||
|
||||
## Business Value Metrics
|
||||
|
||||
### Value Delivery Metrics
|
||||
|
||||
#### Feature Adoption Rate
|
||||
- **Definition**: Percentage of delivered features actively used by users
|
||||
- **Formula**: (Adopted Features / Total Delivered Features) × 100
|
||||
- **Target**: ≥ 80%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Data Source**: User analytics
|
||||
|
||||
#### User Satisfaction Score
|
||||
- **Definition**: Average user satisfaction with delivered features
|
||||
- **Formula**: Sum of User Satisfaction Scores / Number of Features
|
||||
- **Target**: ≥ 4.0/5
|
||||
- **Measurement Frequency**: Release
|
||||
- **Data Source**: User surveys and feedback
|
||||
|
||||
#### Business Objective Achievement
|
||||
- **Definition**: Percentage of business objectives achieved through delivered features
|
||||
- **Formula**: (Achieved Objectives / Total Objectives) × 100
|
||||
- **Target**: ≥ 85%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Data Source**: Business outcome tracking
|
||||
|
||||
### ROI Metrics
|
||||
|
||||
#### Development ROI
|
||||
- **Definition**: Return on investment for development effort
|
||||
- **Formula**: (Business Value - Development Cost) / Development Cost × 100
|
||||
- **Target**: ≥ 200%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Data Source**: Business value and cost tracking
|
||||
|
||||
#### Time to Value
|
||||
- **Definition**: Average time from feature completion to business value realization
|
||||
- **Formula**: Sum of Time to Value / Number of Features
|
||||
- **Target**: ≤ 4 weeks
|
||||
- **Measurement Frequency**: Release
|
||||
- **Data Source**: Value realization tracking
|
||||
|
||||
## Team Performance Metrics
|
||||
|
||||
### Velocity Metrics
|
||||
|
||||
#### Team Velocity
|
||||
- **Definition**: Average story points completed per sprint
|
||||
- **Formula**: Sum of Completed Story Points / Number of Sprints
|
||||
- **Target**: Stable and predictable
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Sprint completion tracking
|
||||
|
||||
#### Velocity Predictability
|
||||
- **Definition**: Consistency of team velocity across sprints
|
||||
- **Formula**: Standard Deviation of Velocity / Average Velocity
|
||||
- **Target**: ≤ 20%
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Velocity trend analysis
|
||||
|
||||
#### Sprint Goal Achievement
|
||||
- **Definition**: Percentage of sprint goals achieved
|
||||
- **Formula**: (Achieved Sprint Goals / Total Sprint Goals) × 100
|
||||
- **Target**: ≥ 90%
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Sprint goal tracking
|
||||
|
||||
### Quality Metrics
|
||||
|
||||
#### Defect Rate
|
||||
- **Definition**: Number of defects found per story after completion
|
||||
- **Formula**: Total Defects / Total Completed Stories
|
||||
- **Target**: ≤ 0.1 defects per story
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Defect tracking
|
||||
|
||||
#### Story Completion Rate
|
||||
- **Definition**: Percentage of committed stories completed per sprint
|
||||
- **Formula**: (Completed Stories / Committed Stories) × 100
|
||||
- **Target**: ≥ 90%
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Sprint tracking
|
||||
|
||||
#### Technical Debt Ratio
|
||||
- **Definition**: Ratio of technical debt stories to feature stories
|
||||
- **Formula**: Technical Debt Stories / Total Stories
|
||||
- **Target**: ≤ 20%
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Story categorization
|
||||
|
||||
## Quality Assurance Metrics
|
||||
|
||||
### Process Quality Metrics
|
||||
|
||||
#### Process Adherence Rate
|
||||
- **Definition**: Percentage of activities following defined processes
|
||||
- **Formula**: (Process-Compliant Activities / Total Activities) × 100
|
||||
- **Target**: ≥ 95%
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Process compliance audits
|
||||
|
||||
#### Quality Gate Pass Rate
|
||||
- **Definition**: Percentage of stories passing quality gates on first attempt
|
||||
- **Formula**: (First-Pass Stories / Total Stories) × 100
|
||||
- **Target**: ≥ 85%
|
||||
- **Measurement Frequency**: Sprint
|
||||
- **Data Source**: Quality gate tracking
|
||||
|
||||
#### Documentation Quality Score
|
||||
- **Definition**: Average quality score of product ownership documentation
|
||||
- **Formula**: Sum of Quality Scores / Number of Documents
|
||||
- **Target**: ≥ 4.0/5
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Data Source**: Documentation reviews
|
||||
|
||||
### Continuous Improvement Metrics
|
||||
|
||||
#### Improvement Implementation Rate
|
||||
- **Definition**: Percentage of identified improvements that are implemented
|
||||
- **Formula**: (Implemented Improvements / Identified Improvements) × 100
|
||||
- **Target**: ≥ 80%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Data Source**: Improvement tracking
|
||||
|
||||
#### Process Efficiency Improvement
|
||||
- **Definition**: Percentage improvement in process efficiency over time
|
||||
- **Formula**: (Current Efficiency - Baseline Efficiency) / Baseline Efficiency × 100
|
||||
- **Target**: ≥ 10% annually
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Data Source**: Efficiency measurements
|
||||
|
||||
## Measurement Methodologies
|
||||
|
||||
### Data Collection Methods
|
||||
|
||||
#### Automated Data Collection
|
||||
- **Sprint Tracking Tools**: Jira, Azure DevOps, Asana
|
||||
- **Analytics Platforms**: Google Analytics, Mixpanel, Amplitude
|
||||
- **Communication Tools**: Slack, Microsoft Teams, Email
|
||||
- **Time Tracking**: Toggl, Harvest, RescueTime
|
||||
|
||||
#### Manual Data Collection
|
||||
- **Stakeholder Surveys**: Monthly satisfaction surveys
|
||||
- **Team Assessments**: Sprint retrospective feedback
|
||||
- **Quality Reviews**: Peer review assessments
|
||||
- **Business Outcome Tracking**: Manual business value assessment
|
||||
|
||||
#### Survey Instruments
|
||||
|
||||
##### Stakeholder Satisfaction Survey
|
||||
1. **Communication Quality** (1-5 scale)
|
||||
- Clarity of information provided
|
||||
- Timeliness of updates
|
||||
- Relevance of content
|
||||
- Responsiveness to questions
|
||||
|
||||
2. **Process Effectiveness** (1-5 scale)
|
||||
- Sprint planning effectiveness
|
||||
- Story quality and clarity
|
||||
- Dependency management
|
||||
- Issue resolution speed
|
||||
|
||||
3. **Business Value** (1-5 scale)
|
||||
- Feature value delivery
|
||||
- Business objective alignment
|
||||
- User satisfaction impact
|
||||
- ROI achievement
|
||||
|
||||
##### Team Performance Survey
|
||||
1. **Story Quality** (1-5 scale)
|
||||
- Story clarity and completeness
|
||||
- Acceptance criteria quality
|
||||
- Business value understanding
|
||||
- Technical feasibility
|
||||
|
||||
2. **Process Support** (1-5 scale)
|
||||
- Product Owner availability
|
||||
- Question response time
|
||||
- Decision-making speed
|
||||
- Stakeholder coordination
|
||||
|
||||
### Data Analysis Techniques
|
||||
|
||||
#### Trend Analysis
|
||||
- **Moving Averages**: 3-month moving averages for stability
|
||||
- **Trend Lines**: Linear regression for trend identification
|
||||
- **Seasonal Adjustments**: Account for seasonal variations
|
||||
- **Anomaly Detection**: Identify unusual patterns or outliers
|
||||
|
||||
#### Correlation Analysis
|
||||
- **Metric Relationships**: Identify relationships between metrics
|
||||
- **Leading Indicators**: Identify predictive metrics
|
||||
- **Root Cause Analysis**: Trace performance issues to root causes
|
||||
- **Impact Assessment**: Measure impact of improvements
|
||||
|
||||
#### Benchmarking
|
||||
- **Internal Benchmarks**: Compare against historical performance
|
||||
- **Industry Benchmarks**: Compare against industry standards
|
||||
- **Best Practice Comparison**: Compare against known best practices
|
||||
- **Peer Comparison**: Compare against similar teams or projects
|
||||
|
||||
## Reporting and Analysis
|
||||
|
||||
### Dashboard Design
|
||||
|
||||
#### Executive Dashboard
|
||||
- **Key Performance Indicators**: Top 5 KPIs for executive visibility
|
||||
- **Trend Indicators**: Month-over-month and quarter-over-quarter trends
|
||||
- **Alert Indicators**: Red/yellow/green status indicators
|
||||
- **Business Impact**: Direct connection to business outcomes
|
||||
|
||||
#### Operational Dashboard
|
||||
- **Sprint Metrics**: Current sprint performance and trends
|
||||
- **Quality Indicators**: Story quality and process adherence
|
||||
- **Team Performance**: Velocity, completion rates, satisfaction
|
||||
- **Stakeholder Metrics**: Communication and satisfaction scores
|
||||
|
||||
#### Detailed Analytics
|
||||
- **Metric Deep Dives**: Detailed analysis of specific metrics
|
||||
- **Root Cause Analysis**: Investigation of performance issues
|
||||
- **Improvement Tracking**: Progress on improvement initiatives
|
||||
- **Predictive Analytics**: Forecasting and trend prediction
|
||||
|
||||
### Reporting Schedule
|
||||
|
||||
#### Daily Reports
|
||||
- **Sprint Progress**: Daily standup metrics
|
||||
- **Blocker Status**: Current blockers and resolution progress
|
||||
- **Quality Alerts**: Immediate quality issues requiring attention
|
||||
|
||||
#### Weekly Reports
|
||||
- **Sprint Summary**: Weekly sprint progress and metrics
|
||||
- **Stakeholder Updates**: Weekly stakeholder communication
|
||||
- **Quality Review**: Weekly quality assessment results
|
||||
|
||||
#### Monthly Reports
|
||||
- **Performance Summary**: Comprehensive monthly performance review
|
||||
- **Trend Analysis**: Monthly trend analysis and insights
|
||||
- **Improvement Progress**: Progress on improvement initiatives
|
||||
- **Stakeholder Satisfaction**: Monthly satisfaction survey results
|
||||
|
||||
#### Quarterly Reports
|
||||
- **Business Impact**: Quarterly business value and ROI assessment
|
||||
- **Strategic Alignment**: Alignment with business objectives
|
||||
- **Process Optimization**: Quarterly process improvement review
|
||||
- **Benchmark Comparison**: Comparison against benchmarks and targets
|
||||
|
||||
## Continuous Improvement
|
||||
|
||||
### Improvement Process
|
||||
|
||||
#### Monthly Improvement Cycle
|
||||
1. **Data Review** (Week 1)
|
||||
- Analyze monthly metrics and trends
|
||||
- Identify performance gaps and opportunities
|
||||
- Review stakeholder and team feedback
|
||||
- Benchmark against targets and best practices
|
||||
|
||||
2. **Root Cause Analysis** (Week 2)
|
||||
- Investigate performance issues and gaps
|
||||
- Identify underlying causes and contributing factors
|
||||
- Assess impact and priority of issues
|
||||
- Develop hypothesis for improvements
|
||||
|
||||
3. **Improvement Planning** (Week 3)
|
||||
- Design improvement initiatives and experiments
|
||||
- Plan implementation timeline and resources
|
||||
- Define success criteria and measurement approach
|
||||
- Obtain stakeholder approval and support
|
||||
|
||||
4. **Implementation** (Week 4)
|
||||
- Execute improvement initiatives
|
||||
- Monitor implementation progress and results
|
||||
- Adjust approach based on early feedback
|
||||
- Document lessons learned and best practices
|
||||
|
||||
### Improvement Categories
|
||||
|
||||
#### Process Improvements
|
||||
- **Workflow Optimization**: Streamline product ownership workflows
|
||||
- **Automation**: Automate routine tasks and quality checks
|
||||
- **Tool Enhancement**: Improve tools and templates
|
||||
- **Training**: Enhance skills and capabilities
|
||||
|
||||
#### Quality Improvements
|
||||
- **Standard Enhancement**: Improve quality standards and criteria
|
||||
- **Review Process**: Enhance review and validation processes
|
||||
- **Feedback Integration**: Better integration of stakeholder feedback
|
||||
- **Error Prevention**: Implement error prevention measures
|
||||
|
||||
#### Communication Improvements
|
||||
- **Stakeholder Engagement**: Enhance stakeholder communication and engagement
|
||||
- **Information Sharing**: Improve information sharing and transparency
|
||||
- **Feedback Mechanisms**: Enhance feedback collection and response
|
||||
- **Collaboration Tools**: Improve collaboration tools and processes
|
||||
|
||||
### Success Measurement
|
||||
|
||||
#### Improvement Effectiveness
|
||||
- **Metric Improvement**: Measurable improvement in target metrics
|
||||
- **Stakeholder Satisfaction**: Increased stakeholder satisfaction scores
|
||||
- **Team Performance**: Enhanced team performance and satisfaction
|
||||
- **Business Impact**: Positive impact on business outcomes
|
||||
|
||||
#### Sustainability Assessment
|
||||
- **Process Adoption**: Sustained adoption of improved processes
|
||||
- **Cultural Change**: Positive cultural changes and behaviors
|
||||
- **Continuous Learning**: Ongoing learning and improvement culture
|
||||
- **Knowledge Retention**: Retention and sharing of lessons learned
|
||||
|
||||
---
|
||||
|
||||
This comprehensive success metrics framework enables Product Owners to measure, track, and continuously improve their effectiveness within the BMAD Method, ensuring consistent delivery of high-quality outcomes that drive project success and stakeholder satisfaction.
|
||||
|
|
@ -0,0 +1,902 @@
|
|||
# Product Owner (Sarah) Template Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This comprehensive template guide provides Product Owners with a complete collection of templates, frameworks, and tools for effective product ownership within the BMAD Method. These templates ensure consistency, quality, and efficiency in all product ownership activities.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Template Categories](#template-categories)
|
||||
2. [User Story Templates](#user-story-templates)
|
||||
3. [Epic and Feature Templates](#epic-and-feature-templates)
|
||||
4. [Backlog Management Templates](#backlog-management-templates)
|
||||
5. [Sprint Planning Templates](#sprint-planning-templates)
|
||||
6. [Stakeholder Communication Templates](#stakeholder-communication-templates)
|
||||
7. [Quality Assurance Templates](#quality-assurance-templates)
|
||||
8. [Template Selection Guide](#template-selection-guide)
|
||||
9. [Customization Guidelines](#customization-guidelines)
|
||||
|
||||
## Template Categories
|
||||
|
||||
### 1. User Story Templates
|
||||
- Standard User Story Template
|
||||
- Technical Story Template
|
||||
- Bug Fix Story Template
|
||||
- Spike Story Template
|
||||
- Epic Breakdown Template
|
||||
|
||||
### 2. Epic and Feature Templates
|
||||
- Epic Definition Template
|
||||
- Feature Specification Template
|
||||
- Theme Documentation Template
|
||||
- Initiative Planning Template
|
||||
|
||||
### 3. Backlog Management Templates
|
||||
- Product Backlog Template
|
||||
- Sprint Backlog Template
|
||||
- Backlog Refinement Template
|
||||
- Priority Matrix Template
|
||||
|
||||
### 4. Sprint Planning Templates
|
||||
- Sprint Planning Agenda Template
|
||||
- Story Estimation Template
|
||||
- Capacity Planning Template
|
||||
- Sprint Goal Template
|
||||
|
||||
### 5. Stakeholder Communication Templates
|
||||
- Stakeholder Update Template
|
||||
- Sprint Review Template
|
||||
- Release Communication Template
|
||||
- Feedback Collection Template
|
||||
|
||||
### 6. Quality Assurance Templates
|
||||
- Definition of Done Template
|
||||
- Acceptance Criteria Template
|
||||
- Story Review Checklist
|
||||
- Quality Gate Template
|
||||
|
||||
## User Story Templates
|
||||
|
||||
### Standard User Story Template
|
||||
|
||||
```markdown
|
||||
## User Story: [Story Title]
|
||||
|
||||
**Story ID**: [Unique Identifier]
|
||||
**Epic**: [Related Epic Name]
|
||||
**Theme**: [Business Theme]
|
||||
|
||||
### Story Description
|
||||
**As a** [user type/persona]
|
||||
**I want** [functionality/capability]
|
||||
**So that** [business value/benefit]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] **Given** [initial context/state]
|
||||
**When** [action/trigger]
|
||||
**Then** [expected outcome]
|
||||
|
||||
- [ ] **Given** [initial context/state]
|
||||
**When** [action/trigger]
|
||||
**Then** [expected outcome]
|
||||
|
||||
- [ ] **Given** [initial context/state]
|
||||
**When** [action/trigger]
|
||||
**Then** [expected outcome]
|
||||
|
||||
### Definition of Done
|
||||
- [ ] Code complete and peer reviewed
|
||||
- [ ] Unit tests written and passing (>90% coverage)
|
||||
- [ ] Integration tests passing
|
||||
- [ ] Acceptance criteria validated
|
||||
- [ ] Documentation updated
|
||||
- [ ] Accessibility requirements met
|
||||
- [ ] Performance criteria met
|
||||
- [ ] Security review completed
|
||||
- [ ] Stakeholder approval received
|
||||
|
||||
### Story Details
|
||||
- **Priority**: [High/Medium/Low]
|
||||
- **Story Points**: [Fibonacci estimate]
|
||||
- **Business Value**: [1-10 scale]
|
||||
- **Risk Level**: [High/Medium/Low]
|
||||
- **Complexity**: [High/Medium/Low]
|
||||
|
||||
### Dependencies
|
||||
- **Depends On**: [List of blocking stories/tasks]
|
||||
- **Blocks**: [List of dependent stories/tasks]
|
||||
- **External Dependencies**: [Third-party or team dependencies]
|
||||
|
||||
### Assumptions
|
||||
- [List key assumptions made during story creation]
|
||||
- [Include technical and business assumptions]
|
||||
|
||||
### Questions and Clarifications
|
||||
- [Outstanding questions that need answers]
|
||||
- [Areas requiring stakeholder clarification]
|
||||
|
||||
### Notes
|
||||
- [Additional context, constraints, or considerations]
|
||||
- [Links to related documentation or resources]
|
||||
|
||||
### Validation Criteria
|
||||
- [ ] Story follows INVEST principles
|
||||
- [ ] Acceptance criteria are testable
|
||||
- [ ] Business value is clearly articulated
|
||||
- [ ] Dependencies are identified
|
||||
- [ ] Assumptions are documented
|
||||
```
|
||||
|
||||
### Technical Story Template
|
||||
|
||||
```markdown
|
||||
## Technical Story: [Story Title]
|
||||
|
||||
**Story ID**: [Unique Identifier]
|
||||
**Category**: [Infrastructure/Architecture/Technical Debt/etc.]
|
||||
|
||||
### Technical Description
|
||||
**As a** [developer/system/team]
|
||||
**I want** [technical capability/improvement]
|
||||
**So that** [technical benefit/business enablement]
|
||||
|
||||
### Technical Acceptance Criteria
|
||||
- [ ] **Given** [current technical state]
|
||||
**When** [technical action/implementation]
|
||||
**Then** [expected technical outcome]
|
||||
|
||||
### Technical Definition of Done
|
||||
- [ ] Implementation complete and reviewed
|
||||
- [ ] Technical documentation updated
|
||||
- [ ] Unit tests written and passing
|
||||
- [ ] Integration tests passing
|
||||
- [ ] Performance benchmarks met
|
||||
- [ ] Security scan completed
|
||||
- [ ] Code quality standards met
|
||||
- [ ] Deployment scripts updated
|
||||
|
||||
### Technical Details
|
||||
- **Technical Complexity**: [High/Medium/Low]
|
||||
- **Effort Estimate**: [Story points]
|
||||
- **Technical Risk**: [High/Medium/Low]
|
||||
- **Impact Scope**: [System-wide/Module/Component]
|
||||
|
||||
### Technical Dependencies
|
||||
- **Technical Prerequisites**: [Required technical work]
|
||||
- **System Dependencies**: [Affected systems/components]
|
||||
- **Tool Dependencies**: [Required tools/libraries]
|
||||
|
||||
### Implementation Notes
|
||||
- [Technical approach and considerations]
|
||||
- [Architecture decisions and rationale]
|
||||
- [Performance and scalability considerations]
|
||||
```
|
||||
|
||||
### Bug Fix Story Template
|
||||
|
||||
```markdown
|
||||
## Bug Fix: [Bug Title]
|
||||
|
||||
**Bug ID**: [Unique Identifier]
|
||||
**Severity**: [Critical/High/Medium/Low]
|
||||
**Priority**: [P1/P2/P3/P4]
|
||||
|
||||
### Bug Description
|
||||
**As a** [affected user type]
|
||||
**I want** [issue to be resolved]
|
||||
**So that** [normal functionality is restored]
|
||||
|
||||
### Current Behavior
|
||||
[Detailed description of the current incorrect behavior]
|
||||
|
||||
### Expected Behavior
|
||||
[Detailed description of the correct behavior]
|
||||
|
||||
### Steps to Reproduce
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
4. [Observe incorrect behavior]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] **Given** [bug reproduction scenario]
|
||||
**When** [fix is applied]
|
||||
**Then** [correct behavior is observed]
|
||||
|
||||
- [ ] **Given** [regression test scenario]
|
||||
**When** [system is tested]
|
||||
**Then** [no new issues are introduced]
|
||||
|
||||
### Bug Fix Definition of Done
|
||||
- [ ] Root cause identified and documented
|
||||
- [ ] Fix implemented and reviewed
|
||||
- [ ] Unit tests added to prevent regression
|
||||
- [ ] Integration tests updated
|
||||
- [ ] Bug reproduction steps verified as fixed
|
||||
- [ ] Regression testing completed
|
||||
- [ ] Documentation updated if needed
|
||||
- [ ] Stakeholder verification completed
|
||||
|
||||
### Bug Details
|
||||
- **Affected Components**: [List of affected system components]
|
||||
- **Environment**: [Where bug occurs - prod/staging/dev]
|
||||
- **Browser/Platform**: [If applicable]
|
||||
- **User Impact**: [Description of user impact]
|
||||
- **Business Impact**: [Description of business impact]
|
||||
|
||||
### Root Cause Analysis
|
||||
- **Immediate Cause**: [Direct cause of the bug]
|
||||
- **Contributing Factors**: [Factors that led to the bug]
|
||||
- **Prevention Measures**: [How to prevent similar bugs]
|
||||
```
|
||||
|
||||
## Epic and Feature Templates
|
||||
|
||||
### Epic Definition Template
|
||||
|
||||
```markdown
|
||||
## Epic: [Epic Name]
|
||||
|
||||
**Epic ID**: [Unique Identifier]
|
||||
**Theme**: [Business Theme]
|
||||
**Initiative**: [Related Initiative]
|
||||
|
||||
### Epic Description
|
||||
[Comprehensive description of the epic and its business purpose]
|
||||
|
||||
### Business Objective
|
||||
**Problem Statement**: [What problem does this epic solve?]
|
||||
**Business Value**: [What value does this epic deliver?]
|
||||
**Success Criteria**: [How will we measure success?]
|
||||
|
||||
### User Stories
|
||||
| Story ID | Story Title | Priority | Story Points | Status |
|
||||
|----------|-------------|----------|--------------|--------|
|
||||
| [ID] | [Title] | [Priority] | [Points] | [Status] |
|
||||
| [ID] | [Title] | [Priority] | [Points] | [Status] |
|
||||
|
||||
### Epic Acceptance Criteria
|
||||
- [ ] [High-level acceptance criterion 1]
|
||||
- [ ] [High-level acceptance criterion 2]
|
||||
- [ ] [High-level acceptance criterion 3]
|
||||
|
||||
### Dependencies
|
||||
- **Epic Dependencies**: [Other epics this depends on]
|
||||
- **External Dependencies**: [Third-party or team dependencies]
|
||||
- **Technical Dependencies**: [Technical prerequisites]
|
||||
|
||||
### Assumptions and Constraints
|
||||
- **Assumptions**: [Key assumptions for this epic]
|
||||
- **Constraints**: [Technical, business, or resource constraints]
|
||||
- **Risks**: [Identified risks and mitigation strategies]
|
||||
|
||||
### Timeline and Milestones
|
||||
- **Target Start Date**: [Date]
|
||||
- **Target Completion Date**: [Date]
|
||||
- **Key Milestones**: [Important delivery milestones]
|
||||
|
||||
### Success Metrics
|
||||
- **KPIs**: [Key performance indicators]
|
||||
- **Acceptance Metrics**: [Quantifiable success measures]
|
||||
- **User Satisfaction**: [How to measure user satisfaction]
|
||||
```
|
||||
|
||||
### Feature Specification Template
|
||||
|
||||
```markdown
|
||||
## Feature: [Feature Name]
|
||||
|
||||
**Feature ID**: [Unique Identifier]
|
||||
**Epic**: [Parent Epic]
|
||||
**Owner**: [Product Owner/Stakeholder]
|
||||
|
||||
### Feature Overview
|
||||
[Detailed description of the feature and its purpose]
|
||||
|
||||
### User Value Proposition
|
||||
**Target Users**: [Primary user personas]
|
||||
**User Problem**: [Problem this feature solves]
|
||||
**Solution**: [How this feature solves the problem]
|
||||
**Value Delivered**: [Specific value to users and business]
|
||||
|
||||
### Functional Requirements
|
||||
1. [Functional requirement 1]
|
||||
2. [Functional requirement 2]
|
||||
3. [Functional requirement 3]
|
||||
|
||||
### Non-Functional Requirements
|
||||
- **Performance**: [Performance requirements]
|
||||
- **Security**: [Security requirements]
|
||||
- **Accessibility**: [Accessibility requirements]
|
||||
- **Scalability**: [Scalability requirements]
|
||||
|
||||
### User Stories
|
||||
[List of user stories that comprise this feature]
|
||||
|
||||
### Acceptance Criteria
|
||||
- [ ] [Feature-level acceptance criterion 1]
|
||||
- [ ] [Feature-level acceptance criterion 2]
|
||||
- [ ] [Feature-level acceptance criterion 3]
|
||||
|
||||
### Design Considerations
|
||||
- **UI/UX Requirements**: [Design requirements]
|
||||
- **Technical Constraints**: [Technical limitations]
|
||||
- **Integration Points**: [System integration requirements]
|
||||
|
||||
### Testing Strategy
|
||||
- **Test Scenarios**: [Key test scenarios]
|
||||
- **Acceptance Testing**: [Acceptance test approach]
|
||||
- **Performance Testing**: [Performance test requirements]
|
||||
```
|
||||
|
||||
## Backlog Management Templates
|
||||
|
||||
### Product Backlog Template
|
||||
|
||||
```markdown
|
||||
## Product Backlog
|
||||
|
||||
**Product**: [Product Name]
|
||||
**Product Owner**: [Name]
|
||||
**Last Updated**: [Date]
|
||||
|
||||
### Backlog Overview
|
||||
- **Total Items**: [Number]
|
||||
- **Ready for Development**: [Number]
|
||||
- **In Progress**: [Number]
|
||||
- **Completed**: [Number]
|
||||
|
||||
### Prioritization Framework
|
||||
**Method**: [MoSCoW/RICE/Kano/Custom]
|
||||
**Criteria**: [Prioritization criteria used]
|
||||
|
||||
### Backlog Items
|
||||
|
||||
#### High Priority (Must Have)
|
||||
| ID | Title | Type | Story Points | Business Value | Status | Sprint |
|
||||
|----|-------|------|--------------|----------------|--------|--------|
|
||||
| [ID] | [Title] | [Epic/Story] | [Points] | [Value] | [Status] | [Sprint] |
|
||||
|
||||
#### Medium Priority (Should Have)
|
||||
| ID | Title | Type | Story Points | Business Value | Status | Sprint |
|
||||
|----|-------|------|--------------|----------------|--------|--------|
|
||||
| [ID] | [Title] | [Epic/Story] | [Points] | [Value] | [Status] | [Sprint] |
|
||||
|
||||
#### Low Priority (Could Have)
|
||||
| ID | Title | Type | Story Points | Business Value | Status | Sprint |
|
||||
|----|-------|------|--------------|----------------|--------|--------|
|
||||
| [ID] | [Title] | [Epic/Story] | [Points] | [Value] | [Status] | [Sprint] |
|
||||
|
||||
#### Future Consideration (Won't Have This Release)
|
||||
| ID | Title | Type | Story Points | Business Value | Rationale |
|
||||
|----|-------|------|--------------|----------------|-----------|
|
||||
| [ID] | [Title] | [Epic/Story] | [Points] | [Value] | [Reason] |
|
||||
|
||||
### Backlog Health Metrics
|
||||
- **Velocity**: [Average story points per sprint]
|
||||
- **Lead Time**: [Average time from backlog to done]
|
||||
- **Cycle Time**: [Average time from start to done]
|
||||
- **Throughput**: [Stories completed per sprint]
|
||||
|
||||
### Backlog Refinement Notes
|
||||
- **Last Refinement**: [Date]
|
||||
- **Next Refinement**: [Date]
|
||||
- **Refinement Focus**: [Areas of focus for next session]
|
||||
```
|
||||
|
||||
### Sprint Backlog Template
|
||||
|
||||
```markdown
|
||||
## Sprint Backlog
|
||||
|
||||
**Sprint**: [Sprint Number/Name]
|
||||
**Sprint Goal**: [Sprint goal statement]
|
||||
**Sprint Duration**: [Start Date] to [End Date]
|
||||
**Team**: [Team Name]
|
||||
|
||||
### Sprint Commitment
|
||||
- **Committed Story Points**: [Total points]
|
||||
- **Team Capacity**: [Available capacity]
|
||||
- **Velocity Target**: [Target velocity]
|
||||
|
||||
### Sprint Backlog Items
|
||||
|
||||
#### Committed Stories
|
||||
| Story ID | Title | Assignee | Story Points | Status | Notes |
|
||||
|----------|-------|----------|--------------|--------|-------|
|
||||
| [ID] | [Title] | [Name] | [Points] | [Status] | [Notes] |
|
||||
|
||||
#### Sprint Tasks
|
||||
| Task ID | Description | Story | Assignee | Estimate | Status |
|
||||
|---------|-------------|-------|----------|----------|--------|
|
||||
| [ID] | [Description] | [Story ID] | [Name] | [Hours] | [Status] |
|
||||
|
||||
### Sprint Risks and Dependencies
|
||||
- **Risks**: [Identified risks for this sprint]
|
||||
- **Dependencies**: [External dependencies]
|
||||
- **Blockers**: [Current or potential blockers]
|
||||
|
||||
### Daily Progress Tracking
|
||||
| Date | Completed | In Progress | Blocked | Notes |
|
||||
|------|-----------|-------------|---------|-------|
|
||||
| [Date] | [Items] | [Items] | [Items] | [Notes] |
|
||||
|
||||
### Sprint Metrics
|
||||
- **Burndown**: [Story points remaining by day]
|
||||
- **Velocity**: [Actual velocity achieved]
|
||||
- **Completion Rate**: [Percentage of committed work completed]
|
||||
```
|
||||
|
||||
## Sprint Planning Templates
|
||||
|
||||
### Sprint Planning Agenda Template
|
||||
|
||||
```markdown
|
||||
## Sprint Planning Agenda
|
||||
|
||||
**Sprint**: [Sprint Number/Name]
|
||||
**Date**: [Date]
|
||||
**Duration**: [Duration]
|
||||
**Attendees**: [Team members and stakeholders]
|
||||
|
||||
### Pre-Planning Preparation
|
||||
- [ ] Product backlog refined and prioritized
|
||||
- [ ] Stories estimated and ready
|
||||
- [ ] Team capacity calculated
|
||||
- [ ] Previous sprint retrospective actions reviewed
|
||||
- [ ] Dependencies identified and resolved
|
||||
|
||||
### Sprint Planning Part 1: What (1-2 hours)
|
||||
**Objective**: Determine what will be delivered in the sprint
|
||||
|
||||
#### Agenda Items
|
||||
1. **Sprint Goal Discussion** (15 minutes)
|
||||
- Review product increment objective
|
||||
- Align on sprint goal
|
||||
- Confirm goal with stakeholders
|
||||
|
||||
2. **Backlog Review** (30 minutes)
|
||||
- Review prioritized backlog items
|
||||
- Clarify requirements and acceptance criteria
|
||||
- Identify dependencies and risks
|
||||
|
||||
3. **Capacity Planning** (15 minutes)
|
||||
- Review team availability
|
||||
- Account for holidays, training, meetings
|
||||
- Calculate available capacity
|
||||
|
||||
4. **Story Selection** (30 minutes)
|
||||
- Select stories for sprint commitment
|
||||
- Validate story readiness
|
||||
- Confirm sprint goal alignment
|
||||
|
||||
### Sprint Planning Part 2: How (2-3 hours)
|
||||
**Objective**: Determine how the work will be accomplished
|
||||
|
||||
#### Agenda Items
|
||||
1. **Story Breakdown** (90 minutes)
|
||||
- Break stories into tasks
|
||||
- Identify technical approach
|
||||
- Estimate task effort
|
||||
|
||||
2. **Dependency Management** (30 minutes)
|
||||
- Identify task dependencies
|
||||
- Plan coordination points
|
||||
- Assign ownership
|
||||
|
||||
3. **Risk Assessment** (15 minutes)
|
||||
- Identify potential blockers
|
||||
- Plan mitigation strategies
|
||||
- Assign risk owners
|
||||
|
||||
4. **Final Commitment** (15 minutes)
|
||||
- Review sprint backlog
|
||||
- Confirm team commitment
|
||||
- Document sprint goal and backlog
|
||||
|
||||
### Sprint Planning Outcomes
|
||||
- [ ] Sprint goal defined and agreed
|
||||
- [ ] Sprint backlog created and committed
|
||||
- [ ] Tasks identified and estimated
|
||||
- [ ] Dependencies mapped and planned
|
||||
- [ ] Risks identified and mitigated
|
||||
- [ ] Team commitment confirmed
|
||||
```
|
||||
|
||||
### Story Estimation Template
|
||||
|
||||
```markdown
|
||||
## Story Estimation Session
|
||||
|
||||
**Session Date**: [Date]
|
||||
**Facilitator**: [Name]
|
||||
**Participants**: [Team members]
|
||||
**Estimation Method**: [Planning Poker/T-Shirt Sizes/Fibonacci]
|
||||
|
||||
### Estimation Guidelines
|
||||
- **Story Points Scale**: [1, 2, 3, 5, 8, 13, 21]
|
||||
- **Reference Stories**: [Baseline stories for comparison]
|
||||
- **Estimation Factors**: [Complexity, effort, risk, uncertainty]
|
||||
|
||||
### Stories to Estimate
|
||||
|
||||
#### Story: [Story Title]
|
||||
**Story ID**: [ID]
|
||||
**Description**: [Brief description]
|
||||
|
||||
**Estimation Discussion**:
|
||||
- **Complexity**: [Technical complexity assessment]
|
||||
- **Effort**: [Development effort required]
|
||||
- **Risk**: [Technical and business risks]
|
||||
- **Dependencies**: [Dependencies that affect estimation]
|
||||
|
||||
**Team Estimates**:
|
||||
| Team Member | Initial Estimate | Final Estimate | Rationale |
|
||||
|-------------|------------------|----------------|-----------|
|
||||
| [Name] | [Points] | [Points] | [Reasoning] |
|
||||
|
||||
**Final Estimate**: [Consensus estimate]
|
||||
**Confidence Level**: [High/Medium/Low]
|
||||
|
||||
### Estimation Summary
|
||||
| Story ID | Title | Estimate | Confidence | Notes |
|
||||
|----------|-------|----------|------------|-------|
|
||||
| [ID] | [Title] | [Points] | [Level] | [Notes] |
|
||||
|
||||
### Estimation Retrospective
|
||||
- **What went well**: [Positive aspects of estimation]
|
||||
- **Challenges**: [Estimation challenges encountered]
|
||||
- **Improvements**: [Process improvements for next session]
|
||||
```
|
||||
|
||||
## Stakeholder Communication Templates
|
||||
|
||||
### Stakeholder Update Template
|
||||
|
||||
```markdown
|
||||
## Stakeholder Update
|
||||
|
||||
**Date**: [Date]
|
||||
**Product**: [Product Name]
|
||||
**Reporting Period**: [Time period]
|
||||
**Product Owner**: [Name]
|
||||
|
||||
### Executive Summary
|
||||
[High-level summary of progress, achievements, and key decisions]
|
||||
|
||||
### Sprint/Release Progress
|
||||
- **Current Sprint**: [Sprint number/name]
|
||||
- **Sprint Goal**: [Sprint goal]
|
||||
- **Progress**: [% complete]
|
||||
- **Key Achievements**: [Major accomplishments]
|
||||
|
||||
### Metrics and KPIs
|
||||
| Metric | Current Value | Target | Trend | Notes |
|
||||
|--------|---------------|--------|-------|-------|
|
||||
| Velocity | [Points] | [Target] | [↑↓→] | [Notes] |
|
||||
| Burndown | [Points] | [Target] | [↑↓→] | [Notes] |
|
||||
| Quality | [%] | [Target] | [↑↓→] | [Notes] |
|
||||
|
||||
### Completed Work
|
||||
#### Stories Completed
|
||||
- [Story 1]: [Brief description and business value]
|
||||
- [Story 2]: [Brief description and business value]
|
||||
- [Story 3]: [Brief description and business value]
|
||||
|
||||
#### Features Delivered
|
||||
- [Feature 1]: [Description and user impact]
|
||||
- [Feature 2]: [Description and user impact]
|
||||
|
||||
### Upcoming Work
|
||||
#### Next Sprint Focus
|
||||
- [Priority 1]: [Description and rationale]
|
||||
- [Priority 2]: [Description and rationale]
|
||||
- [Priority 3]: [Description and rationale]
|
||||
|
||||
#### Upcoming Milestones
|
||||
- [Milestone 1]: [Date and description]
|
||||
- [Milestone 2]: [Date and description]
|
||||
|
||||
### Issues and Risks
|
||||
#### Current Blockers
|
||||
- [Blocker 1]: [Description, impact, and resolution plan]
|
||||
- [Blocker 2]: [Description, impact, and resolution plan]
|
||||
|
||||
#### Identified Risks
|
||||
- [Risk 1]: [Description, probability, impact, mitigation]
|
||||
- [Risk 2]: [Description, probability, impact, mitigation]
|
||||
|
||||
### Decisions Needed
|
||||
- [Decision 1]: [Description, options, recommendation, deadline]
|
||||
- [Decision 2]: [Description, options, recommendation, deadline]
|
||||
|
||||
### Feedback and Questions
|
||||
[Space for stakeholder feedback and questions]
|
||||
|
||||
### Next Update
|
||||
**Date**: [Next update date]
|
||||
**Focus**: [Key areas for next update]
|
||||
```
|
||||
|
||||
### Sprint Review Template
|
||||
|
||||
```markdown
|
||||
## Sprint Review
|
||||
|
||||
**Sprint**: [Sprint Number/Name]
|
||||
**Date**: [Date]
|
||||
**Duration**: [Duration]
|
||||
**Attendees**: [Stakeholders and team members]
|
||||
|
||||
### Sprint Overview
|
||||
- **Sprint Goal**: [Sprint goal]
|
||||
- **Sprint Duration**: [Start date] to [End date]
|
||||
- **Team**: [Team name and members]
|
||||
|
||||
### Sprint Results
|
||||
- **Committed Story Points**: [Points]
|
||||
- **Completed Story Points**: [Points]
|
||||
- **Completion Rate**: [Percentage]
|
||||
- **Velocity**: [Actual velocity]
|
||||
|
||||
### Demonstration Agenda
|
||||
|
||||
#### Story 1: [Story Title]
|
||||
- **Business Value**: [Value delivered]
|
||||
- **Demo Script**: [What will be demonstrated]
|
||||
- **Acceptance Criteria Met**: [Criteria satisfied]
|
||||
- **Stakeholder Feedback**: [Space for feedback]
|
||||
|
||||
#### Story 2: [Story Title]
|
||||
- **Business Value**: [Value delivered]
|
||||
- **Demo Script**: [What will be demonstrated]
|
||||
- **Acceptance Criteria Met**: [Criteria satisfied]
|
||||
- **Stakeholder Feedback**: [Space for feedback]
|
||||
|
||||
### Product Increment Review
|
||||
- **Features Completed**: [List of completed features]
|
||||
- **User Value Delivered**: [Summary of user value]
|
||||
- **Business Impact**: [Business impact assessment]
|
||||
|
||||
### Backlog Updates
|
||||
- **New Items Added**: [New backlog items]
|
||||
- **Items Reprioritized**: [Priority changes]
|
||||
- **Items Removed**: [Removed items and rationale]
|
||||
|
||||
### Stakeholder Feedback
|
||||
#### Feedback on Delivered Work
|
||||
- [Feedback item 1]
|
||||
- [Feedback item 2]
|
||||
- [Feedback item 3]
|
||||
|
||||
#### Suggestions for Future Work
|
||||
- [Suggestion 1]
|
||||
- [Suggestion 2]
|
||||
- [Suggestion 3]
|
||||
|
||||
### Next Sprint Preview
|
||||
- **Upcoming Sprint Goal**: [Next sprint goal]
|
||||
- **Priority Items**: [Top priority items for next sprint]
|
||||
- **Expected Outcomes**: [What stakeholders can expect]
|
||||
|
||||
### Action Items
|
||||
| Action | Owner | Due Date | Status |
|
||||
|--------|-------|----------|--------|
|
||||
| [Action] | [Owner] | [Date] | [Status] |
|
||||
|
||||
### Meeting Feedback
|
||||
- **What went well**: [Positive aspects of the review]
|
||||
- **Improvements**: [Suggestions for better reviews]
|
||||
```
|
||||
|
||||
## Quality Assurance Templates
|
||||
|
||||
### Definition of Done Template
|
||||
|
||||
```markdown
|
||||
## Definition of Done
|
||||
|
||||
**Product**: [Product Name]
|
||||
**Team**: [Team Name]
|
||||
**Version**: [Version Number]
|
||||
**Last Updated**: [Date]
|
||||
|
||||
### Story-Level Definition of Done
|
||||
|
||||
#### Development Criteria
|
||||
- [ ] **Code Complete**: All code written and committed
|
||||
- [ ] **Code Review**: Peer review completed and approved
|
||||
- [ ] **Coding Standards**: Code follows team coding standards
|
||||
- [ ] **Unit Tests**: Unit tests written with >90% coverage
|
||||
- [ ] **Integration Tests**: Integration tests written and passing
|
||||
- [ ] **Static Analysis**: Code passes static analysis tools
|
||||
- [ ] **Security Scan**: Security vulnerability scan completed
|
||||
|
||||
#### Quality Criteria
|
||||
- [ ] **Acceptance Criteria**: All acceptance criteria validated
|
||||
- [ ] **Manual Testing**: Manual testing completed successfully
|
||||
- [ ] **Regression Testing**: No regression issues identified
|
||||
- [ ] **Performance Testing**: Performance criteria met
|
||||
- [ ] **Accessibility Testing**: Accessibility requirements validated
|
||||
- [ ] **Cross-Browser Testing**: Tested on supported browsers/devices
|
||||
|
||||
#### Documentation Criteria
|
||||
- [ ] **Code Documentation**: Code properly documented
|
||||
- [ ] **User Documentation**: User-facing documentation updated
|
||||
- [ ] **Technical Documentation**: Technical documentation updated
|
||||
- [ ] **API Documentation**: API documentation updated (if applicable)
|
||||
|
||||
#### Deployment Criteria
|
||||
- [ ] **Build Success**: Automated build successful
|
||||
- [ ] **Deployment Scripts**: Deployment scripts updated
|
||||
- [ ] **Environment Testing**: Tested in staging environment
|
||||
- [ ] **Database Changes**: Database migration scripts tested
|
||||
- [ ] **Configuration**: Configuration changes documented
|
||||
|
||||
#### Stakeholder Criteria
|
||||
- [ ] **Product Owner Approval**: Product Owner accepts the story
|
||||
- [ ] **Stakeholder Review**: Key stakeholders have reviewed
|
||||
- [ ] **User Acceptance**: User acceptance testing completed
|
||||
- [ ] **Business Validation**: Business requirements validated
|
||||
|
||||
### Epic-Level Definition of Done
|
||||
|
||||
#### Feature Criteria
|
||||
- [ ] **All Stories Complete**: All epic stories meet DoD
|
||||
- [ ] **Feature Testing**: End-to-end feature testing completed
|
||||
- [ ] **User Journey Testing**: Complete user journeys validated
|
||||
- [ ] **Integration Testing**: Feature integration testing completed
|
||||
|
||||
#### Release Criteria
|
||||
- [ ] **Release Notes**: Release notes prepared
|
||||
- [ ] **Training Materials**: User training materials updated
|
||||
- [ ] **Support Documentation**: Support documentation updated
|
||||
- [ ] **Rollback Plan**: Rollback procedures documented
|
||||
|
||||
### Release-Level Definition of Done
|
||||
|
||||
#### Production Criteria
|
||||
- [ ] **Production Deployment**: Successfully deployed to production
|
||||
- [ ] **Monitoring**: Production monitoring configured
|
||||
- [ ] **Performance Validation**: Production performance validated
|
||||
- [ ] **User Communication**: Users notified of new features
|
||||
|
||||
#### Business Criteria
|
||||
- [ ] **Success Metrics**: Success metrics baseline established
|
||||
- [ ] **Feedback Collection**: User feedback collection enabled
|
||||
- [ ] **Business Validation**: Business objectives validated
|
||||
|
||||
### Quality Gates
|
||||
|
||||
#### Gate 1: Development Complete
|
||||
- All development and quality criteria met
|
||||
- Ready for stakeholder review
|
||||
|
||||
#### Gate 2: Stakeholder Approval
|
||||
- All stakeholder criteria met
|
||||
- Ready for release preparation
|
||||
|
||||
#### Gate 3: Release Ready
|
||||
- All release criteria met
|
||||
- Ready for production deployment
|
||||
|
||||
### Exceptions and Waivers
|
||||
- **Exception Process**: [Process for handling DoD exceptions]
|
||||
- **Approval Authority**: [Who can approve exceptions]
|
||||
- **Documentation**: [How exceptions are documented]
|
||||
```
|
||||
|
||||
### Acceptance Criteria Template
|
||||
|
||||
```markdown
|
||||
## Acceptance Criteria Template
|
||||
|
||||
### Standard Format: Given-When-Then
|
||||
|
||||
```
|
||||
**Given** [initial context or state]
|
||||
**When** [action or event occurs]
|
||||
**Then** [expected outcome or result]
|
||||
```
|
||||
|
||||
### Example Acceptance Criteria
|
||||
|
||||
#### Functional Criteria
|
||||
- [ ] **Given** I am a logged-in user
|
||||
**When** I click the "Save" button
|
||||
**Then** my changes are saved and I see a confirmation message
|
||||
|
||||
- [ ] **Given** I have items in my shopping cart
|
||||
**When** I proceed to checkout
|
||||
**Then** I am taken to the payment page with correct item totals
|
||||
|
||||
#### Error Handling Criteria
|
||||
- [ ] **Given** I enter an invalid email address
|
||||
**When** I submit the form
|
||||
**Then** I see an error message "Please enter a valid email address"
|
||||
|
||||
- [ ] **Given** the system is unavailable
|
||||
**When** I try to save my data
|
||||
**Then** I see a message "System temporarily unavailable, please try again"
|
||||
|
||||
#### Performance Criteria
|
||||
- [ ] **Given** I am on the search page
|
||||
**When** I enter a search term and click search
|
||||
**Then** results are displayed within 2 seconds
|
||||
|
||||
#### Security Criteria
|
||||
- [ ] **Given** I am not logged in
|
||||
**When** I try to access a protected page
|
||||
**Then** I am redirected to the login page
|
||||
|
||||
#### Accessibility Criteria
|
||||
- [ ] **Given** I am using a screen reader
|
||||
**When** I navigate the form
|
||||
**Then** all form fields have appropriate labels and descriptions
|
||||
|
||||
### Acceptance Criteria Checklist
|
||||
- [ ] **Testable**: Each criterion can be objectively tested
|
||||
- [ ] **Clear**: Criteria are unambiguous and specific
|
||||
- [ ] **Complete**: All important scenarios are covered
|
||||
- [ ] **Achievable**: Criteria are technically feasible
|
||||
- [ ] **Business-Focused**: Criteria reflect business value
|
||||
- [ ] **Independent**: Each criterion stands alone
|
||||
- [ ] **Measurable**: Success can be objectively measured
|
||||
```
|
||||
|
||||
## Template Selection Guide
|
||||
|
||||
### Template Selection Matrix
|
||||
|
||||
| Use Case | Primary Template | Supporting Templates | Complexity Level |
|
||||
|----------|------------------|---------------------|------------------|
|
||||
| New Feature Development | Standard User Story | Epic Definition, Feature Specification | Medium |
|
||||
| Technical Improvement | Technical Story | Quality Assurance Templates | High |
|
||||
| Bug Resolution | Bug Fix Story | Quality Assurance Templates | Low |
|
||||
| Research/Investigation | Spike Story | None | Medium |
|
||||
| Release Planning | Epic Definition | Sprint Planning Templates | High |
|
||||
| Sprint Execution | Sprint Backlog | Daily Tracking Templates | Medium |
|
||||
| Stakeholder Communication | Stakeholder Update | Sprint Review Template | Low |
|
||||
|
||||
### Template Customization Guidelines
|
||||
|
||||
#### When to Customize Templates
|
||||
- Team-specific processes require additional fields
|
||||
- Industry regulations require specific documentation
|
||||
- Organizational standards mandate certain formats
|
||||
- Tool integration requires specific structures
|
||||
|
||||
#### Customization Best Practices
|
||||
1. **Maintain Core Structure**: Keep essential elements intact
|
||||
2. **Add, Don't Remove**: Add fields rather than removing standard ones
|
||||
3. **Document Changes**: Record customizations and rationale
|
||||
4. **Team Alignment**: Ensure team agrees on customizations
|
||||
5. **Regular Review**: Periodically review and update customizations
|
||||
|
||||
#### Common Customizations
|
||||
- **Additional Fields**: Risk level, business priority, technical complexity
|
||||
- **Workflow States**: Custom status values for team processes
|
||||
- **Approval Processes**: Additional approval steps or stakeholders
|
||||
- **Integration Fields**: Fields required for tool integration
|
||||
- **Compliance Fields**: Fields required for regulatory compliance
|
||||
|
||||
### Template Maintenance
|
||||
|
||||
#### Regular Review Schedule
|
||||
- **Monthly**: Review template usage and effectiveness
|
||||
- **Quarterly**: Update templates based on team feedback
|
||||
- **Annually**: Comprehensive template review and optimization
|
||||
|
||||
#### Version Control
|
||||
- **Template Versioning**: Maintain version history of template changes
|
||||
- **Change Documentation**: Document reasons for template changes
|
||||
- **Migration Planning**: Plan migration from old to new template versions
|
||||
|
||||
#### Quality Assurance
|
||||
- **Template Testing**: Test templates with real scenarios
|
||||
- **User Feedback**: Collect feedback from template users
|
||||
- **Continuous Improvement**: Continuously improve based on usage patterns
|
||||
|
||||
---
|
||||
|
||||
This comprehensive template guide provides Product Owners with all the tools needed for effective product ownership within the BMAD Method. Use these templates as starting points and customize them to fit your specific team and organizational needs.
|
||||
|
|
@ -0,0 +1,639 @@
|
|||
# Product Owner (Sarah) Workflow Mapping
|
||||
|
||||
## Overview
|
||||
|
||||
This document provides comprehensive workflow mapping for Product Owner activities within the BMAD Method. These workflows ensure systematic, efficient, and high-quality product ownership that drives successful project outcomes.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Core Workflow Overview](#core-workflow-overview)
|
||||
2. [Story Creation Workflow](#story-creation-workflow)
|
||||
3. [Backlog Management Workflow](#backlog-management-workflow)
|
||||
4. [Sprint Planning Workflow](#sprint-planning-workflow)
|
||||
5. [Stakeholder Engagement Workflow](#stakeholder-engagement-workflow)
|
||||
6. [Quality Assurance Workflow](#quality-assurance-workflow)
|
||||
7. [Integration Workflows](#integration-workflows)
|
||||
8. [Decision Trees](#decision-trees)
|
||||
9. [Escalation Procedures](#escalation-procedures)
|
||||
|
||||
## Core Workflow Overview
|
||||
|
||||
### Primary Product Owner Workflows
|
||||
|
||||
```mermaid title="Product Owner Core Workflows" type="diagram"
|
||||
graph TD
|
||||
A[Requirements Input] --> B[Story Creation Workflow]
|
||||
B --> C[Backlog Management Workflow]
|
||||
C --> D[Sprint Planning Workflow]
|
||||
D --> E[Development Support]
|
||||
E --> F[Quality Assurance Workflow]
|
||||
F --> G[Stakeholder Communication]
|
||||
G --> H[Feedback Integration]
|
||||
H --> C
|
||||
|
||||
I[Stakeholder Requests] --> J[Stakeholder Engagement Workflow]
|
||||
J --> B
|
||||
|
||||
K[Quality Issues] --> L[Quality Assurance Workflow]
|
||||
L --> M[Process Improvement]
|
||||
M --> B
|
||||
```
|
||||
|
||||
### Workflow Integration Points
|
||||
|
||||
```mermaid title="BMAD Method Integration Points" type="diagram"
|
||||
sequenceDiagram
|
||||
participant PM as Product Manager
|
||||
participant SA as System Architect
|
||||
participant UX as UX/UI Architect
|
||||
participant PO as Product Owner
|
||||
participant DEV as Developer
|
||||
participant SM as Scrum Master
|
||||
|
||||
PM->>PO: PRD and Requirements
|
||||
SA->>PO: Technical Constraints
|
||||
UX->>PO: Design Specifications
|
||||
PO->>PO: Create User Stories
|
||||
PO->>DEV: Sprint-Ready Stories
|
||||
PO->>SM: Sprint Planning Support
|
||||
DEV->>PO: Clarification Requests
|
||||
PO->>PM: Progress Updates
|
||||
```
|
||||
|
||||
## Story Creation Workflow
|
||||
|
||||
### Story Creation Process Flow
|
||||
|
||||
```mermaid title="Story Creation Workflow" type="diagram"
|
||||
flowchart TD
|
||||
A[Receive Requirements] --> B{Requirements Clear?}
|
||||
B -->|No| C[Stakeholder Clarification]
|
||||
C --> B
|
||||
B -->|Yes| D[Create Initial Story]
|
||||
D --> E[Define Acceptance Criteria]
|
||||
E --> F[Estimate Story Points]
|
||||
F --> G[Identify Dependencies]
|
||||
G --> H[Validate with Stakeholders]
|
||||
H --> I{Stakeholder Approval?}
|
||||
I -->|No| J[Refine Story]
|
||||
J --> E
|
||||
I -->|Yes| K[Add to Product Backlog]
|
||||
K --> L[Story Ready for Development]
|
||||
```
|
||||
|
||||
### Detailed Story Creation Steps
|
||||
|
||||
#### Phase 1: Requirements Analysis (30 minutes)
|
||||
1. **Receive Input**
|
||||
- Review PRD from Product Manager
|
||||
- Analyze technical constraints from System Architect
|
||||
- Review design specifications from UX/UI Architect
|
||||
- Identify stakeholder requirements
|
||||
|
||||
2. **Requirements Validation**
|
||||
- Verify requirements completeness
|
||||
- Identify missing information
|
||||
- Clarify ambiguous requirements
|
||||
- Validate business value proposition
|
||||
|
||||
3. **Initial Assessment**
|
||||
- Assess story complexity
|
||||
- Identify potential risks
|
||||
- Estimate initial effort
|
||||
- Determine story priority
|
||||
|
||||
#### Phase 2: Story Drafting (45 minutes)
|
||||
1. **Story Structure Creation**
|
||||
- Write story title and description
|
||||
- Define user persona and role
|
||||
- Articulate desired functionality
|
||||
- Specify business value
|
||||
|
||||
2. **Acceptance Criteria Definition**
|
||||
- Write Given-When-Then scenarios
|
||||
- Cover happy path scenarios
|
||||
- Include edge cases and error conditions
|
||||
- Define validation criteria
|
||||
|
||||
3. **Story Details**
|
||||
- Add story metadata (priority, complexity)
|
||||
- Document assumptions and constraints
|
||||
- Identify dependencies and blockers
|
||||
- Add relevant notes and context
|
||||
|
||||
#### Phase 3: Story Validation (30 minutes)
|
||||
1. **Quality Review**
|
||||
- Validate INVEST principles compliance
|
||||
- Review acceptance criteria completeness
|
||||
- Check story clarity and testability
|
||||
- Verify business value articulation
|
||||
|
||||
2. **Stakeholder Review**
|
||||
- Present story to key stakeholders
|
||||
- Gather feedback and suggestions
|
||||
- Address concerns and questions
|
||||
- Obtain stakeholder approval
|
||||
|
||||
3. **Final Preparation**
|
||||
- Incorporate stakeholder feedback
|
||||
- Finalize story details
|
||||
- Add to product backlog
|
||||
- Mark as ready for development
|
||||
|
||||
### Story Creation Quality Gates
|
||||
|
||||
#### Gate 1: Requirements Clarity
|
||||
- [ ] All requirements are clearly understood
|
||||
- [ ] Missing information has been identified and obtained
|
||||
- [ ] Business value is clearly articulated
|
||||
- [ ] Technical constraints are understood
|
||||
|
||||
#### Gate 2: Story Quality
|
||||
- [ ] Story follows INVEST principles
|
||||
- [ ] Acceptance criteria are complete and testable
|
||||
- [ ] Dependencies are identified and documented
|
||||
- [ ] Story is appropriately sized for sprint completion
|
||||
|
||||
#### Gate 3: Stakeholder Approval
|
||||
- [ ] Key stakeholders have reviewed the story
|
||||
- [ ] Feedback has been incorporated
|
||||
- [ ] Business value is validated
|
||||
- [ ] Story is approved for development
|
||||
|
||||
## Backlog Management Workflow
|
||||
|
||||
### Backlog Management Process Flow
|
||||
|
||||
```mermaid title="Backlog Management Workflow" type="diagram"
|
||||
flowchart TD
|
||||
A[New Stories Created] --> B[Add to Product Backlog]
|
||||
B --> C[Prioritize Stories]
|
||||
C --> D[Estimate Stories]
|
||||
D --> E[Identify Dependencies]
|
||||
E --> F[Refine Stories]
|
||||
F --> G[Validate Readiness]
|
||||
G --> H{Ready for Sprint?}
|
||||
H -->|No| I[Additional Refinement]
|
||||
I --> F
|
||||
H -->|Yes| J[Move to Sprint Backlog]
|
||||
J --> K[Sprint Planning]
|
||||
|
||||
L[Business Changes] --> M[Reprioritize Backlog]
|
||||
M --> C
|
||||
|
||||
N[Stakeholder Feedback] --> O[Update Stories]
|
||||
O --> F
|
||||
```
|
||||
|
||||
### Backlog Prioritization Workflow
|
||||
|
||||
#### Prioritization Framework Application
|
||||
1. **Business Value Assessment**
|
||||
- Evaluate user impact and satisfaction
|
||||
- Assess revenue and cost implications
|
||||
- Consider strategic alignment
|
||||
- Analyze competitive advantage
|
||||
|
||||
2. **Technical Considerations**
|
||||
- Review technical complexity
|
||||
- Assess implementation risk
|
||||
- Consider technical dependencies
|
||||
- Evaluate architectural impact
|
||||
|
||||
3. **Resource and Timeline Factors**
|
||||
- Assess team capacity and skills
|
||||
- Consider timeline constraints
|
||||
- Evaluate resource availability
|
||||
- Plan for dependencies
|
||||
|
||||
4. **Stakeholder Input Integration**
|
||||
- Gather stakeholder priorities
|
||||
- Resolve conflicting priorities
|
||||
- Communicate prioritization rationale
|
||||
- Obtain stakeholder agreement
|
||||
|
||||
### Backlog Refinement Workflow
|
||||
|
||||
#### Weekly Refinement Process (2 hours)
|
||||
1. **Preparation (15 minutes)**
|
||||
- Review upcoming sprint capacity
|
||||
- Identify stories for refinement
|
||||
- Prepare refinement agenda
|
||||
- Gather stakeholder input
|
||||
|
||||
2. **Story Review (90 minutes)**
|
||||
- Review story details and acceptance criteria
|
||||
- Clarify requirements and expectations
|
||||
- Update estimates based on new information
|
||||
- Identify and resolve dependencies
|
||||
|
||||
3. **Readiness Assessment (15 minutes)**
|
||||
- Validate story readiness for development
|
||||
- Identify any remaining blockers
|
||||
- Confirm stakeholder approval
|
||||
- Mark stories as sprint-ready
|
||||
|
||||
## Sprint Planning Workflow
|
||||
|
||||
### Sprint Planning Process Flow
|
||||
|
||||
```mermaid title="Sprint Planning Workflow" type="diagram"
|
||||
flowchart TD
|
||||
A[Sprint Planning Preparation] --> B[Review Sprint Goal]
|
||||
B --> C[Review Team Capacity]
|
||||
C --> D[Select Stories from Backlog]
|
||||
D --> E[Validate Story Readiness]
|
||||
E --> F{Stories Ready?}
|
||||
F -->|No| G[Refine Stories]
|
||||
G --> E
|
||||
F -->|Yes| H[Create Sprint Backlog]
|
||||
H --> I[Break Down into Tasks]
|
||||
I --> J[Estimate Task Effort]
|
||||
J --> K[Validate Sprint Commitment]
|
||||
K --> L{Commitment Realistic?}
|
||||
L -->|No| M[Adjust Scope]
|
||||
M --> D
|
||||
L -->|Yes| N[Finalize Sprint Plan]
|
||||
N --> O[Sprint Kickoff]
|
||||
```
|
||||
|
||||
### Sprint Planning Preparation Workflow
|
||||
|
||||
#### Pre-Planning Activities (1 day before)
|
||||
1. **Backlog Preparation**
|
||||
- Ensure top priority stories are refined
|
||||
- Validate acceptance criteria completeness
|
||||
- Confirm stakeholder approval
|
||||
- Identify any last-minute changes
|
||||
|
||||
2. **Capacity Planning**
|
||||
- Calculate team availability
|
||||
- Account for holidays and time off
|
||||
- Consider meeting and training time
|
||||
- Determine available story points
|
||||
|
||||
3. **Goal Setting**
|
||||
- Define clear sprint goal
|
||||
- Align goal with business objectives
|
||||
- Communicate goal to stakeholders
|
||||
- Prepare goal presentation
|
||||
|
||||
#### Sprint Planning Execution (4 hours)
|
||||
|
||||
##### Part 1: What Will Be Done (2 hours)
|
||||
1. **Goal Presentation (30 minutes)**
|
||||
- Present sprint goal to team
|
||||
- Explain business context and value
|
||||
- Answer questions and clarify expectations
|
||||
- Obtain team agreement on goal
|
||||
|
||||
2. **Story Selection (90 minutes)**
|
||||
- Review prioritized backlog items
|
||||
- Select stories based on capacity and goal
|
||||
- Validate story readiness and clarity
|
||||
- Confirm story acceptance criteria
|
||||
|
||||
##### Part 2: How Work Will Be Done (2 hours)
|
||||
1. **Task Breakdown (90 minutes)**
|
||||
- Break stories into development tasks
|
||||
- Identify technical approach and dependencies
|
||||
- Assign initial task ownership
|
||||
- Estimate task effort in hours
|
||||
|
||||
2. **Commitment Validation (30 minutes)**
|
||||
- Review total commitment vs. capacity
|
||||
- Identify risks and mitigation strategies
|
||||
- Adjust scope if necessary
|
||||
- Finalize team commitment
|
||||
|
||||
## Stakeholder Engagement Workflow
|
||||
|
||||
### Stakeholder Communication Process Flow
|
||||
|
||||
```mermaid title="Stakeholder Engagement Workflow" type="diagram"
|
||||
flowchart TD
|
||||
A[Identify Communication Need] --> B[Determine Stakeholders]
|
||||
B --> C[Select Communication Method]
|
||||
C --> D[Prepare Communication Content]
|
||||
D --> E[Deliver Communication]
|
||||
E --> F[Collect Feedback]
|
||||
F --> G[Document Feedback]
|
||||
G --> H[Analyze and Prioritize]
|
||||
H --> I[Plan Response Actions]
|
||||
I --> J[Implement Actions]
|
||||
J --> K[Follow Up with Stakeholders]
|
||||
K --> L[Update Communication Plan]
|
||||
```
|
||||
|
||||
### Regular Stakeholder Communication Cadence
|
||||
|
||||
#### Weekly Stakeholder Updates
|
||||
1. **Preparation (30 minutes)**
|
||||
- Gather sprint progress data
|
||||
- Identify key achievements and blockers
|
||||
- Prepare stakeholder-specific content
|
||||
- Review previous feedback and actions
|
||||
|
||||
2. **Communication Delivery (15 minutes)**
|
||||
- Send written update via email
|
||||
- Highlight key progress and decisions needed
|
||||
- Include relevant metrics and visuals
|
||||
- Provide clear next steps
|
||||
|
||||
3. **Follow-up (15 minutes)**
|
||||
- Monitor stakeholder responses
|
||||
- Schedule meetings for complex discussions
|
||||
- Document feedback and questions
|
||||
- Plan response actions
|
||||
|
||||
#### Sprint Review Stakeholder Engagement
|
||||
1. **Pre-Review Preparation (1 hour)**
|
||||
- Prepare demonstration script
|
||||
- Gather stakeholder feedback questions
|
||||
- Set up demo environment
|
||||
- Coordinate stakeholder attendance
|
||||
|
||||
2. **Review Execution (2 hours)**
|
||||
- Present sprint achievements
|
||||
- Demonstrate completed functionality
|
||||
- Collect stakeholder feedback
|
||||
- Discuss upcoming priorities
|
||||
|
||||
3. **Post-Review Actions (30 minutes)**
|
||||
- Document feedback and decisions
|
||||
- Update backlog based on feedback
|
||||
- Communicate action items
|
||||
- Plan follow-up activities
|
||||
|
||||
## Quality Assurance Workflow
|
||||
|
||||
### Quality Assurance Process Flow
|
||||
|
||||
```mermaid title="Quality Assurance Workflow" type="diagram"
|
||||
flowchart TD
|
||||
A[Quality Check Trigger] --> B[Identify QA Scope]
|
||||
B --> C[Select QA Checklist]
|
||||
C --> D[Execute Quality Review]
|
||||
D --> E[Document Findings]
|
||||
E --> F{Quality Issues Found?}
|
||||
F -->|Yes| G[Create Improvement Plan]
|
||||
G --> H[Implement Improvements]
|
||||
H --> I[Re-validate Quality]
|
||||
I --> F
|
||||
F -->|No| J[Approve Quality]
|
||||
J --> K[Update Quality Metrics]
|
||||
K --> L[Communicate Results]
|
||||
```
|
||||
|
||||
### Story Quality Assurance Workflow
|
||||
|
||||
#### Story QA Process (30 minutes per story)
|
||||
1. **INVEST Validation (10 minutes)**
|
||||
- Independent: Story can be developed independently
|
||||
- Negotiable: Implementation details are flexible
|
||||
- Valuable: Story delivers clear business value
|
||||
- Estimable: Story can be reasonably estimated
|
||||
- Small: Story fits within a sprint
|
||||
- Testable: Story has clear acceptance criteria
|
||||
|
||||
2. **Content Quality Review (15 minutes)**
|
||||
- Title clarity and descriptiveness
|
||||
- Story description completeness
|
||||
- Acceptance criteria testability
|
||||
- Business value articulation
|
||||
- Dependency identification
|
||||
|
||||
3. **Stakeholder Validation (5 minutes)**
|
||||
- Stakeholder review completion
|
||||
- Feedback incorporation
|
||||
- Approval documentation
|
||||
- Communication of changes
|
||||
|
||||
### Process Quality Assurance Workflow
|
||||
|
||||
#### Sprint Process QA (Weekly)
|
||||
1. **Planning Quality Review**
|
||||
- Sprint goal clarity and achievability
|
||||
- Story selection rationale
|
||||
- Capacity planning accuracy
|
||||
- Risk identification and mitigation
|
||||
|
||||
2. **Execution Quality Review**
|
||||
- Daily standup effectiveness
|
||||
- Blocker resolution speed
|
||||
- Stakeholder communication quality
|
||||
- Progress tracking accuracy
|
||||
|
||||
3. **Review Quality Assessment**
|
||||
- Demonstration quality and preparation
|
||||
- Stakeholder engagement effectiveness
|
||||
- Feedback collection and integration
|
||||
- Action item follow-through
|
||||
|
||||
## Integration Workflows
|
||||
|
||||
### BMAD Method Persona Integration
|
||||
|
||||
#### Integration with Product Manager (John)
|
||||
1. **PRD Handoff Process**
|
||||
- Receive and review PRD
|
||||
- Validate requirements completeness
|
||||
- Identify clarification needs
|
||||
- Confirm business priorities
|
||||
|
||||
2. **Ongoing Collaboration**
|
||||
- Regular progress updates
|
||||
- Stakeholder feedback sharing
|
||||
- Priority adjustment discussions
|
||||
- Success metrics tracking
|
||||
|
||||
#### Integration with System Architect (Fred)
|
||||
1. **Technical Constraint Integration**
|
||||
- Review technical architecture
|
||||
- Understand implementation constraints
|
||||
- Incorporate technical considerations into stories
|
||||
- Validate technical feasibility
|
||||
|
||||
2. **Architecture Alignment**
|
||||
- Ensure stories support architecture
|
||||
- Identify technical dependencies
|
||||
- Plan technical story sequencing
|
||||
- Coordinate technical reviews
|
||||
|
||||
#### Integration with UX/UI Architect (Veronica/Victor)
|
||||
1. **Design Integration Process**
|
||||
- Review design specifications
|
||||
- Incorporate design requirements into stories
|
||||
- Ensure design-development alignment
|
||||
- Plan design validation activities
|
||||
|
||||
2. **User Experience Coordination**
|
||||
- Validate user journey completeness
|
||||
- Ensure consistent user experience
|
||||
- Coordinate usability testing
|
||||
- Integrate design feedback
|
||||
|
||||
#### Integration with Developer (David)
|
||||
1. **Development Support Process**
|
||||
- Provide story clarification
|
||||
- Support estimation activities
|
||||
- Answer implementation questions
|
||||
- Validate completed work
|
||||
|
||||
2. **Quality Collaboration**
|
||||
- Review acceptance criteria validation
|
||||
- Support testing activities
|
||||
- Validate business value delivery
|
||||
- Coordinate stakeholder acceptance
|
||||
|
||||
#### Integration with Scrum Master (Mike)
|
||||
1. **Process Collaboration**
|
||||
- Support sprint planning activities
|
||||
- Coordinate stakeholder communication
|
||||
- Align on process improvements
|
||||
- Share velocity and quality metrics
|
||||
|
||||
2. **Team Support**
|
||||
- Provide product context to team
|
||||
- Support conflict resolution
|
||||
- Facilitate stakeholder access
|
||||
- Coordinate external dependencies
|
||||
|
||||
## Decision Trees
|
||||
|
||||
### Story Prioritization Decision Tree
|
||||
|
||||
```mermaid title="Story Prioritization Decision Tree" type="diagram"
|
||||
flowchart TD
|
||||
A[New Story] --> B{Critical Business Need?}
|
||||
B -->|Yes| C[High Priority]
|
||||
B -->|No| D{High User Value?}
|
||||
D -->|Yes| E{Low Implementation Risk?}
|
||||
E -->|Yes| F[High Priority]
|
||||
E -->|No| G[Medium Priority]
|
||||
D -->|No| H{Technical Dependency?}
|
||||
H -->|Yes| I{Blocks Other Work?}
|
||||
I -->|Yes| J[Medium Priority]
|
||||
I -->|No| K[Low Priority]
|
||||
H -->|No| L{Strategic Alignment?}
|
||||
L -->|Yes| M[Medium Priority]
|
||||
L -->|No| N[Low Priority]
|
||||
```
|
||||
|
||||
### Quality Issue Resolution Decision Tree
|
||||
|
||||
```mermaid title="Quality Issue Resolution Decision Tree" type="diagram"
|
||||
flowchart TD
|
||||
A[Quality Issue Identified] --> B{Severity Level?}
|
||||
B -->|Critical| C[Immediate Action Required]
|
||||
C --> D[Stop Current Work]
|
||||
D --> E[Fix Issue Immediately]
|
||||
B -->|High| F[Urgent Action Required]
|
||||
F --> G[Plan Fix in Current Sprint]
|
||||
B -->|Medium| H[Standard Process]
|
||||
H --> I[Add to Backlog]
|
||||
I --> J[Prioritize for Next Sprint]
|
||||
B -->|Low| K[Monitor and Track]
|
||||
K --> L[Address in Future Sprint]
|
||||
```
|
||||
|
||||
## Escalation Procedures
|
||||
|
||||
### Issue Escalation Matrix
|
||||
|
||||
| Issue Type | Level 1 | Level 2 | Level 3 | Timeline |
|
||||
|------------|---------|---------|---------|----------|
|
||||
| Story Clarification | Team Discussion | Stakeholder Meeting | Executive Review | 1-3 days |
|
||||
| Priority Conflict | PO Decision | PM Consultation | Executive Decision | 2-5 days |
|
||||
| Resource Constraint | Team Planning | Management Review | Executive Approval | 3-7 days |
|
||||
| Quality Issue | Team Resolution | Process Review | Quality Audit | 1-14 days |
|
||||
| Stakeholder Conflict | Direct Discussion | Facilitated Meeting | Executive Mediation | 2-10 days |
|
||||
|
||||
### Escalation Process Workflow
|
||||
|
||||
```mermaid title="Escalation Process Workflow" type="diagram"
|
||||
flowchart TD
|
||||
A[Issue Identified] --> B[Assess Severity and Impact]
|
||||
B --> C{Can Be Resolved at Team Level?}
|
||||
C -->|Yes| D[Team Resolution]
|
||||
D --> E[Document Resolution]
|
||||
C -->|No| F[Escalate to Level 2]
|
||||
F --> G{Resolution Achieved?}
|
||||
G -->|Yes| H[Document and Communicate]
|
||||
G -->|No| I[Escalate to Level 3]
|
||||
I --> J[Executive Review]
|
||||
J --> K[Final Resolution]
|
||||
K --> L[Update Processes]
|
||||
```
|
||||
|
||||
### Communication During Escalation
|
||||
|
||||
#### Escalation Communication Template
|
||||
1. **Issue Description**
|
||||
- Clear description of the issue
|
||||
- Impact on project and stakeholders
|
||||
- Urgency and timeline constraints
|
||||
- Previous resolution attempts
|
||||
|
||||
2. **Stakeholder Notification**
|
||||
- Notify affected stakeholders
|
||||
- Provide regular status updates
|
||||
- Communicate resolution timeline
|
||||
- Document decisions and rationale
|
||||
|
||||
3. **Resolution Communication**
|
||||
- Communicate final resolution
|
||||
- Update affected documentation
|
||||
- Share lessons learned
|
||||
- Implement process improvements
|
||||
|
||||
---
|
||||
|
||||
These comprehensive workflow mappings ensure systematic, efficient, and high-quality product ownership within the BMAD Method. Regular application and continuous improvement of these workflows will enhance the effectiveness of product ownership practices and drive consistent project success.
|
||||
|
||||
## Workflow Optimization
|
||||
|
||||
### Continuous Workflow Improvement
|
||||
|
||||
#### Monthly Workflow Review Process
|
||||
1. **Performance Analysis**
|
||||
- Review workflow execution metrics
|
||||
- Identify bottlenecks and inefficiencies
|
||||
- Analyze stakeholder feedback on processes
|
||||
- Assess team satisfaction with workflows
|
||||
|
||||
2. **Improvement Identification**
|
||||
- Gather team input on workflow challenges
|
||||
- Research industry best practices
|
||||
- Identify automation opportunities
|
||||
- Propose workflow enhancements
|
||||
|
||||
3. **Implementation Planning**
|
||||
- Prioritize improvement initiatives
|
||||
- Plan implementation timeline
|
||||
- Assign improvement ownership
|
||||
- Communicate changes to stakeholders
|
||||
|
||||
### Workflow Automation Opportunities
|
||||
|
||||
#### Automated Quality Checks
|
||||
- Story template compliance validation
|
||||
- INVEST principles automated assessment
|
||||
- Acceptance criteria completeness checking
|
||||
- Dependency conflict detection
|
||||
|
||||
#### Automated Reporting
|
||||
- Sprint progress dashboards
|
||||
- Stakeholder update generation
|
||||
- Quality metrics compilation
|
||||
- Workflow performance tracking
|
||||
|
||||
#### Automated Notifications
|
||||
- Story readiness alerts
|
||||
- Stakeholder review reminders
|
||||
- Quality gate notifications
|
||||
- Escalation triggers
|
||||
|
||||
---
|
||||
|
||||
This comprehensive workflow mapping guide provides Product Owners with detailed processes for effective product ownership within the BMAD Method, ensuring consistent delivery of high-quality outcomes that drive project success.
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
# BMAD Method Quick Start Guides
|
||||
|
||||
Welcome to the BMAD Method Quick Start Guides! These resources are designed to get you productive with the BMAD Method in minutes, not hours.
|
||||
|
||||
## Available Quick Start Guides
|
||||
|
||||
### Core Method Guides
|
||||
- **[BMAD Method 5-Minute Quick Start](bmad-method-quickstart.md)** - Get started with the BMAD Method in just 5 minutes
|
||||
- **[Common Use Cases](bmad-method-common-use-cases.md)** - Practical examples for common development scenarios
|
||||
- **[Video Walkthrough Script](bmad-method-video-script.md)** - Script for creating video tutorials
|
||||
|
||||
### Environment-Specific Guides
|
||||
- **[Web Environment Quick Start](web-environment-quickstart.md)** - Using BMAD Method with web-based AI platforms
|
||||
- **[IDE Environment Quick Start](ide-environment-quickstart.md)** - Using BMAD Method with AI-enhanced IDEs
|
||||
|
||||
## Persona Quick Start Guides
|
||||
|
||||
Each BMAD Method persona has its own dedicated quick start guide:
|
||||
|
||||
| Persona | Quick Start Guide | Primary Use Case |
|
||||
|---------|------------------|------------------|
|
||||
| John (Product Manager) | [PM Quick Start](../pm-quickstart.md) | Product requirements and roadmaps |
|
||||
| Fred (System Architect) | [Architect Quick Start](../architect-quickstart.md) | System architecture and technical decisions |
|
||||
| Sarah (Product Owner) | [PO Quick Start](../po-quickstart.md) | User stories and sprint planning |
|
||||
| Analyst (Business Analyst) | [Analyst Quick Start](../analyst-quickstart.md) | Market research and business analysis |
|
||||
| David (Developer) | [Developer Quick Start](../dev-quickstart.md) | Code implementation and technical solutions |
|
||||
| Design Architect | [Design Architect Quick Start](../design-architect-quickstart.md) | Design systems and visual consistency |
|
||||
| SM (Scrum Master) | [SM Quick Start](../sm-quickstart.md) | Agile process facilitation |
|
||||
| DevOps-PE (DevOps Engineer) | [DevOps Quick Start](../devops-quickstart.md) | Infrastructure and deployment |
|
||||
| Veronica/Victor (UX/UI Architect) | [UX/UI Quick Start](../v0-ux-ui-architect-quickstart.md) | User interface and experience design |
|
||||
|
||||
## How to Use These Guides
|
||||
|
||||
1. **Start with the 5-Minute Quick Start** to understand the BMAD Method basics
|
||||
2. **Explore Common Use Cases** to see practical applications
|
||||
3. **Choose environment-specific guides** based on your preferred working environment
|
||||
4. **Reference persona-specific guides** when working with individual personas
|
||||
|
||||
## Quick Reference
|
||||
|
||||
### Persona Activation Phrases
|
||||
```
|
||||
# Product Manager
|
||||
I need John to help define requirements for [feature/product]
|
||||
|
||||
# System Architect
|
||||
I need Fred to design the architecture for [system/component]
|
||||
|
||||
# Product Owner
|
||||
I need Sarah to create user stories for [feature/product]
|
||||
|
||||
# Business Analyst
|
||||
I need Analyst to research and analyze [market/opportunity]
|
||||
|
||||
# Developer
|
||||
I need David to implement [feature/component]
|
||||
|
||||
# Design Architect
|
||||
I need Design Architect to create a design system for [product]
|
||||
|
||||
# Scrum Master
|
||||
I need SM to facilitate our agile process for [project]
|
||||
|
||||
# DevOps Engineer
|
||||
I need DevOps-PE to set up infrastructure for [system]
|
||||
|
||||
# UX/UI Architect
|
||||
I need Veronica to design the user interface for [feature/product]
|
||||
```
|
||||
|
||||
### Common Workflows
|
||||
|
||||
#### New Feature Development
|
||||
1. John (requirements) → Fred (architecture) → Sarah (stories) → David (implementation)
|
||||
|
||||
#### UI/UX Improvement
|
||||
1. John (requirements) → Veronica (design) → Sarah (stories) → David (implementation)
|
||||
|
||||
#### Technical Debt Reduction
|
||||
1. Fred (assessment) → Sarah (stories) → David (implementation)
|
||||
|
||||
#### Infrastructure Improvement
|
||||
1. Fred (architecture) → DevOps-PE (implementation) → David (integration)
|
||||
|
||||
## Getting Help
|
||||
|
||||
If you need additional assistance:
|
||||
- Check the comprehensive guides for each persona
|
||||
- Review the integration guides for workflow details
|
||||
- Explore the example projects for inspiration
|
||||
- Join the community discussions on GitHub
|
||||
|
||||
---
|
||||
|
||||
Ready to transform your development process? The BMAD Method is now at your fingertips!
|
||||
|
|
@ -0,0 +1,444 @@
|
|||
# BMAD Method: Common Use Cases
|
||||
|
||||
This guide provides practical examples of how to use the BMAD Method for common software development scenarios. Each use case includes step-by-step instructions, persona selection guidance, and expected outcomes.
|
||||
|
||||
## 1. Starting a New Project
|
||||
|
||||
### Scenario
|
||||
You need to create a new web application from scratch and want to ensure proper planning and architecture.
|
||||
|
||||
### BMAD Method Approach
|
||||
|
||||
#### Step 1: Requirements Definition with John (Product Manager)
|
||||
```
|
||||
# Activation
|
||||
I need John to help define requirements for a new [type] application.
|
||||
|
||||
# Context
|
||||
We need to build a [description of application]. The target users are [user types].
|
||||
Key features should include [list initial ideas].
|
||||
```
|
||||
|
||||
**Expected Output**: Comprehensive PRD with user needs, market analysis, feature requirements, and roadmap.
|
||||
|
||||
#### Step 2: Market Research with Analyst (Business Analyst)
|
||||
```
|
||||
# Activation
|
||||
I need Analyst to research the market for our [type] application.
|
||||
|
||||
# Context
|
||||
[Share John's PRD]
|
||||
Please analyze the competitive landscape and identify opportunities for differentiation.
|
||||
```
|
||||
|
||||
**Expected Output**: Market analysis, competitor comparison, and strategic recommendations.
|
||||
|
||||
#### Step 3: System Architecture with Fred (System Architect)
|
||||
```
|
||||
# Activation
|
||||
I need Fred to design the architecture for our [type] application.
|
||||
|
||||
# Context
|
||||
[Share PRD and market analysis]
|
||||
Design a scalable architecture that supports our requirements and allows for future growth.
|
||||
```
|
||||
|
||||
**Expected Output**: System architecture diagram, component specifications, technology stack recommendations, and data flow design.
|
||||
|
||||
#### Step 4: UI/UX Design with Veronica (UX/UI Architect)
|
||||
```
|
||||
# Activation
|
||||
I need Veronica to design the user interface for our [type] application.
|
||||
|
||||
# Context
|
||||
[Share PRD and architecture]
|
||||
Create a user-friendly interface that aligns with our requirements and technical architecture.
|
||||
```
|
||||
|
||||
**Expected Output**: UI mockups, component designs, user flow diagrams, and design system specifications.
|
||||
|
||||
#### Step 5: Development Planning with Sarah (Product Owner)
|
||||
```
|
||||
# Activation
|
||||
I need Sarah to create user stories for our [type] application.
|
||||
|
||||
# Context
|
||||
[Share PRD, architecture, and UI designs]
|
||||
Break down these requirements into sprint-ready user stories with acceptance criteria.
|
||||
```
|
||||
|
||||
**Expected Output**: Prioritized backlog of user stories with acceptance criteria and definition of done.
|
||||
|
||||
**Total Time**: 2-3 hours
|
||||
**Value**: Complete project foundation with alignment across business, technical, and user experience domains.
|
||||
|
||||
## 2. Feature Enhancement
|
||||
|
||||
### Scenario
|
||||
You need to add a new feature to an existing application while ensuring compatibility and quality.
|
||||
|
||||
### BMAD Method Approach
|
||||
|
||||
#### Step 1: Feature Definition with John (Product Manager)
|
||||
```
|
||||
# Activation
|
||||
I need John to help define requirements for adding [feature] to our existing application.
|
||||
|
||||
# Context
|
||||
Our application currently [describe current state].
|
||||
We need to add [feature] to address [business need].
|
||||
```
|
||||
|
||||
**Expected Output**: Feature specification with user needs, success criteria, and integration requirements.
|
||||
|
||||
#### Step 2: Architecture Review with Fred (System Architect)
|
||||
```
|
||||
# Activation
|
||||
I need Fred to review our architecture for adding [feature].
|
||||
|
||||
# Context
|
||||
[Share feature specification and current architecture]
|
||||
How should we integrate this new feature while maintaining system integrity?
|
||||
```
|
||||
|
||||
**Expected Output**: Architecture update recommendations, integration approach, and technical considerations.
|
||||
|
||||
#### Step 3: User Story Creation with Sarah (Product Owner)
|
||||
```
|
||||
# Activation
|
||||
I need Sarah to create user stories for implementing [feature].
|
||||
|
||||
# Context
|
||||
[Share feature specification and architecture recommendations]
|
||||
Create sprint-ready stories for this feature implementation.
|
||||
```
|
||||
|
||||
**Expected Output**: Detailed user stories with acceptance criteria and technical notes.
|
||||
|
||||
#### Step 4: Implementation with David (Developer)
|
||||
```
|
||||
# Activation
|
||||
I need David to implement [specific story] for our [feature].
|
||||
|
||||
# Context
|
||||
[Share user story and technical context]
|
||||
Implement this functionality using our existing tech stack [details].
|
||||
```
|
||||
|
||||
**Expected Output**: Production-ready code with tests and documentation.
|
||||
|
||||
**Total Time**: 1-2 hours
|
||||
**Value**: Structured feature addition with technical alignment and quality assurance.
|
||||
|
||||
## 3. Technical Debt Reduction
|
||||
|
||||
### Scenario
|
||||
Your application has accumulated technical debt that needs to be addressed to improve maintainability and performance.
|
||||
|
||||
### BMAD Method Approach
|
||||
|
||||
#### Step 1: Technical Assessment with Fred (System Architect)
|
||||
```
|
||||
# Activation
|
||||
I need Fred to assess our technical debt in [system/component].
|
||||
|
||||
# Context
|
||||
Our [system/component] is experiencing [issues].
|
||||
We suspect problems with [specific areas].
|
||||
```
|
||||
|
||||
**Expected Output**: Technical debt assessment, prioritized issues, and remediation recommendations.
|
||||
|
||||
#### Step 2: Refactoring Plan with David (Developer)
|
||||
```
|
||||
# Activation
|
||||
I need David to create a refactoring plan for [system/component].
|
||||
|
||||
# Context
|
||||
[Share technical debt assessment]
|
||||
Create a step-by-step plan to address these issues while minimizing disruption.
|
||||
```
|
||||
|
||||
**Expected Output**: Detailed refactoring plan with code examples, testing strategy, and risk mitigation.
|
||||
|
||||
#### Step 3: Quality Assurance with SM (Scrum Master)
|
||||
```
|
||||
# Activation
|
||||
I need SM to create a quality assurance process for our refactoring effort.
|
||||
|
||||
# Context
|
||||
[Share refactoring plan]
|
||||
Help us ensure quality throughout this refactoring process.
|
||||
```
|
||||
|
||||
**Expected Output**: QA process, review checkpoints, and validation strategy.
|
||||
|
||||
**Total Time**: 1-2 hours
|
||||
**Value**: Structured approach to technical debt reduction with minimal risk.
|
||||
|
||||
## 4. Performance Optimization
|
||||
|
||||
### Scenario
|
||||
Your application is experiencing performance issues that need to be diagnosed and resolved.
|
||||
|
||||
### BMAD Method Approach
|
||||
|
||||
#### Step 1: Performance Analysis with Fred (System Architect)
|
||||
```
|
||||
# Activation
|
||||
I need Fred to analyze performance issues in our [system/component].
|
||||
|
||||
# Context
|
||||
Our [system/component] is experiencing [specific performance issues].
|
||||
Here are our current metrics: [performance data].
|
||||
```
|
||||
|
||||
**Expected Output**: Performance bottleneck analysis, root cause identification, and optimization recommendations.
|
||||
|
||||
#### Step 2: Optimization Implementation with David (Developer)
|
||||
```
|
||||
# Activation
|
||||
I need David to implement performance optimizations for [specific issue].
|
||||
|
||||
# Context
|
||||
[Share performance analysis]
|
||||
Implement the recommended optimizations while maintaining functionality.
|
||||
```
|
||||
|
||||
**Expected Output**: Optimized code with before/after performance metrics and testing strategy.
|
||||
|
||||
#### Step 3: Infrastructure Optimization with DevOps-PE (DevOps Engineer)
|
||||
```
|
||||
# Activation
|
||||
I need DevOps-PE to optimize our infrastructure for [performance requirements].
|
||||
|
||||
# Context
|
||||
[Share performance analysis and code optimizations]
|
||||
Recommend and implement infrastructure improvements to support our performance goals.
|
||||
```
|
||||
|
||||
**Expected Output**: Infrastructure optimization plan, configuration changes, and monitoring setup.
|
||||
|
||||
**Total Time**: 1-2 hours
|
||||
**Value**: Comprehensive performance improvement across application and infrastructure.
|
||||
|
||||
## 5. Cross-Functional Problem Solving
|
||||
|
||||
### Scenario
|
||||
You're facing a complex problem that spans multiple domains (business, technical, UX, etc.).
|
||||
|
||||
### BMAD Method Approach
|
||||
|
||||
#### Step 1: Problem Definition with John (Product Manager)
|
||||
```
|
||||
# Activation
|
||||
I need John to help define the problem of [issue description].
|
||||
|
||||
# Context
|
||||
We're experiencing [problem] which affects [business impact].
|
||||
We need a solution that addresses [key requirements].
|
||||
```
|
||||
|
||||
**Expected Output**: Problem statement, business impact analysis, and solution requirements.
|
||||
|
||||
#### Step 2: Multi-Perspective Analysis
|
||||
```
|
||||
# Activation (Sequential)
|
||||
I need Analyst to analyze business implications of [problem].
|
||||
I need Fred to analyze technical implications of [problem].
|
||||
I need Veronica to analyze user experience implications of [problem].
|
||||
```
|
||||
|
||||
**Expected Output**: Comprehensive analysis from business, technical, and UX perspectives.
|
||||
|
||||
#### Step 3: Solution Design with Fred (System Architect)
|
||||
```
|
||||
# Activation
|
||||
I need Fred to design a solution for [problem].
|
||||
|
||||
# Context
|
||||
[Share all previous analyses]
|
||||
Design a solution that addresses all these perspectives and requirements.
|
||||
```
|
||||
|
||||
**Expected Output**: Integrated solution design with technical, business, and UX considerations.
|
||||
|
||||
#### Step 4: Implementation Planning with Sarah (Product Owner)
|
||||
```
|
||||
# Activation
|
||||
I need Sarah to create an implementation plan for this solution.
|
||||
|
||||
# Context
|
||||
[Share solution design]
|
||||
Break this down into implementable stories and create a delivery plan.
|
||||
```
|
||||
|
||||
**Expected Output**: Implementation roadmap with prioritized stories and delivery timeline.
|
||||
|
||||
**Total Time**: 2-3 hours
|
||||
**Value**: Holistic solution that addresses complex problems across multiple domains.
|
||||
|
||||
## 6. Legacy System Modernization
|
||||
|
||||
### Scenario
|
||||
You need to modernize a legacy system while maintaining functionality and minimizing disruption.
|
||||
|
||||
### BMAD Method Approach
|
||||
|
||||
#### Step 1: System Assessment with Fred (System Architect)
|
||||
```
|
||||
# Activation
|
||||
I need Fred to assess our legacy [system/component] for modernization.
|
||||
|
||||
# Context
|
||||
Our legacy system [description] needs modernization because [reasons].
|
||||
Current pain points include [issues].
|
||||
```
|
||||
|
||||
**Expected Output**: Legacy system assessment, modernization opportunities, and technical approach recommendations.
|
||||
|
||||
#### Step 2: Modernization Strategy with John (Product Manager)
|
||||
```
|
||||
# Activation
|
||||
I need John to create a modernization strategy for our legacy system.
|
||||
|
||||
# Context
|
||||
[Share system assessment]
|
||||
Help us prioritize modernization efforts based on business impact and technical feasibility.
|
||||
```
|
||||
|
||||
**Expected Output**: Modernization roadmap with phased approach and business justification.
|
||||
|
||||
#### Step 3: Migration Planning with DevOps-PE (DevOps Engineer)
|
||||
```
|
||||
# Activation
|
||||
I need DevOps-PE to create a migration plan for our legacy system.
|
||||
|
||||
# Context
|
||||
[Share system assessment and modernization strategy]
|
||||
Design a migration approach that minimizes downtime and risk.
|
||||
```
|
||||
|
||||
**Expected Output**: Detailed migration plan with environment setup, testing strategy, and rollback procedures.
|
||||
|
||||
#### Step 4: Implementation with David (Developer)
|
||||
```
|
||||
# Activation
|
||||
I need David to implement the first phase of our modernization plan.
|
||||
|
||||
# Context
|
||||
[Share all previous outputs]
|
||||
Implement the [specific component] modernization following our technical approach.
|
||||
```
|
||||
|
||||
**Expected Output**: Modernized code with migration scripts, tests, and documentation.
|
||||
|
||||
**Total Time**: 2-3 hours
|
||||
**Value**: Structured modernization approach with minimized risk and business alignment.
|
||||
|
||||
## 7. Rapid Prototyping
|
||||
|
||||
### Scenario
|
||||
You need to quickly validate a new idea or concept with a working prototype.
|
||||
|
||||
### BMAD Method Approach
|
||||
|
||||
#### Step 1: Concept Definition with John (Product Manager)
|
||||
```
|
||||
# Activation
|
||||
I need John to help define a prototype for [concept].
|
||||
|
||||
# Context
|
||||
We want to validate [idea/concept] with a quick prototype.
|
||||
The key aspects to demonstrate are [features].
|
||||
```
|
||||
|
||||
**Expected Output**: Prototype specification with core features and validation criteria.
|
||||
|
||||
#### Step 2: UI Design with Veronica (UX/UI Architect)
|
||||
```
|
||||
# Activation
|
||||
I need Veronica to design a prototype UI for [concept].
|
||||
|
||||
# Context
|
||||
[Share prototype specification]
|
||||
Create a simple but effective UI that demonstrates the core concept.
|
||||
```
|
||||
|
||||
**Expected Output**: Prototype UI design with key screens and interactions.
|
||||
|
||||
#### Step 3: Rapid Implementation with David (Developer)
|
||||
```
|
||||
# Activation
|
||||
I need David to implement a working prototype for [concept].
|
||||
|
||||
# Context
|
||||
[Share prototype specification and UI design]
|
||||
Create a functional prototype optimized for speed rather than production quality.
|
||||
```
|
||||
|
||||
**Expected Output**: Working prototype code with setup instructions and limitations noted.
|
||||
|
||||
**Total Time**: 1-2 hours
|
||||
**Value**: Functional prototype to validate concepts quickly before full investment.
|
||||
|
||||
## 8. Documentation Generation
|
||||
|
||||
### Scenario
|
||||
You need comprehensive documentation for your system or API.
|
||||
|
||||
### BMAD Method Approach
|
||||
|
||||
#### Step 1: Documentation Planning with Fred (System Architect)
|
||||
```
|
||||
# Activation
|
||||
I need Fred to plan documentation for our [system/API].
|
||||
|
||||
# Context
|
||||
We need documentation for [audience] covering [scope].
|
||||
Current system details: [brief description]
|
||||
```
|
||||
|
||||
**Expected Output**: Documentation plan with structure, content requirements, and format recommendations.
|
||||
|
||||
#### Step 2: Technical Documentation with David (Developer)
|
||||
```
|
||||
# Activation
|
||||
I need David to create technical documentation for [component/API].
|
||||
|
||||
# Context
|
||||
[Share documentation plan]
|
||||
Create detailed technical documentation including examples and best practices.
|
||||
```
|
||||
|
||||
**Expected Output**: Comprehensive technical documentation with code examples and usage guidelines.
|
||||
|
||||
#### Step 3: User Documentation with Veronica (UX/UI Architect)
|
||||
```
|
||||
# Activation
|
||||
I need Veronica to create user documentation for [feature/system].
|
||||
|
||||
# Context
|
||||
[Share documentation plan]
|
||||
Create user-friendly documentation with visual guides and examples.
|
||||
```
|
||||
|
||||
**Expected Output**: User-focused documentation with screenshots, workflows, and troubleshooting guides.
|
||||
|
||||
**Total Time**: 1-2 hours
|
||||
**Value**: Complete documentation suite tailored to different audiences.
|
||||
|
||||
## Best Practices for All Use Cases
|
||||
|
||||
1. **Maintain Context Continuity**: Share outputs between personas to maintain context
|
||||
2. **Be Specific in Requests**: Clearly define what you need from each persona
|
||||
3. **Provide Relevant Background**: Include necessary project context and constraints
|
||||
4. **Iterate When Needed**: Don't hesitate to ask for refinements or alternatives
|
||||
5. **Combine Personas for Complex Tasks**: Use multiple personas for challenging problems
|
||||
6. **Document Outputs**: Save key outputs for future reference and team sharing
|
||||
7. **Validate Against Requirements**: Ensure solutions align with original requirements
|
||||
8. **Consider Integration Points**: Think about how outputs will integrate with existing systems
|
||||
|
||||
---
|
||||
|
||||
These use cases demonstrate the versatility of the BMAD Method across different software development scenarios. Adapt these approaches to your specific needs and combine personas as required for your unique challenges.
|
||||
|
|
@ -0,0 +1,267 @@
|
|||
# BMAD Method: 5-Minute Quick Start Guide
|
||||
|
||||
Welcome to the BMAD Method! This guide will get you up and running in just 5 minutes, allowing you to leverage the power of our specialized AI personas for your development workflow.
|
||||
|
||||
## What is the BMAD Method?
|
||||
|
||||
The BMAD Method is a **methodology framework** that structures AI-assisted software development using specialized personas, standardized workflows, and quality-driven processes. It's not a software application - it's a systematic approach to working with AI that ensures consistent, high-quality results.
|
||||
|
||||
### Key Components
|
||||
- **Personas**: Specialized AI roles (PM, Architect, Developer, etc.)
|
||||
- **Tasks**: Structured workflows for common development activities
|
||||
- **Templates**: Standardized formats for deliverables
|
||||
- **Checklists**: Quality validation frameworks
|
||||
|
||||
## Quick Setup (2 minutes)
|
||||
|
||||
### Step 1: Get the BMAD Method Files
|
||||
```bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/bmadcode/BMAD-METHOD.git
|
||||
|
||||
# Navigate to the project directory
|
||||
cd BMAD-METHOD
|
||||
```
|
||||
|
||||
### Step 2: Choose Your Environment
|
||||
- **Web Environment**: Use with ChatGPT, Claude, Gemini, or other web-based AI platforms
|
||||
- **IDE Environment**: Use with Cursor AI, VS Code, JetBrains IDEs, or other development environments
|
||||
|
||||
### Step 3: Understand the File Structure
|
||||
```
|
||||
bmad-agent/
|
||||
├── personas/ # AI persona definitions
|
||||
├── tasks/ # Structured task workflows
|
||||
├── templates/ # Document templates
|
||||
└── checklists/ # Quality validation checklists
|
||||
```
|
||||
|
||||
## Your First BMAD Session (3 minutes)
|
||||
|
||||
### Example: Creating a User Authentication Feature
|
||||
|
||||
Let's walk through a complete example using multiple BMAD personas:
|
||||
|
||||
#### Step 1: Define Requirements with John (Product Manager)
|
||||
```
|
||||
Load John (Product Manager) from bmad-agent/personas/pm.md
|
||||
|
||||
I need to define requirements for a user authentication feature.
|
||||
The system should allow users to register, log in, and recover passwords.
|
||||
Use the PRD template and follow PM quality standards.
|
||||
```
|
||||
|
||||
**Expected Output**: Structured PRD with user needs, market analysis, feature requirements, and success metrics.
|
||||
|
||||
#### Step 2: Design Architecture with Fred (System Architect)
|
||||
```
|
||||
Load Fred (System Architect) from bmad-agent/personas/architect.md
|
||||
|
||||
Based on these requirements: [paste PRD summary]
|
||||
Design a secure authentication system architecture.
|
||||
Use the architecture template and follow security best practices.
|
||||
```
|
||||
|
||||
**Expected Output**: Comprehensive architecture design with components, data flow, security considerations, and technical specifications.
|
||||
|
||||
#### Step 3: Create User Stories with Sarah (Product Owner)
|
||||
```
|
||||
Load Sarah (Product Owner) from bmad-agent/personas/po.md
|
||||
|
||||
Based on this architecture: [paste architecture summary]
|
||||
Create sprint-ready user stories for the authentication feature.
|
||||
Use the story template and include acceptance criteria.
|
||||
```
|
||||
|
||||
**Expected Output**: Detailed user stories with acceptance criteria, definition of done, and sprint planning information.
|
||||
|
||||
#### Step 4: Implement with David (Developer)
|
||||
```
|
||||
Load David (Developer) from bmad-agent/personas/dev.ide.md
|
||||
|
||||
Based on this user story: [paste story]
|
||||
Implement the login component using React and Node.js.
|
||||
Follow development best practices and include tests.
|
||||
```
|
||||
|
||||
**Expected Output**: Production-ready code with tests, documentation, and implementation notes.
|
||||
|
||||
## BMAD Personas Quick Reference
|
||||
|
||||
| Persona | Role | When to Use | Key Outputs |
|
||||
|---------|------|-------------|-------------|
|
||||
| **John** | Product Manager | Define requirements, analyze market needs | PRDs, user research, roadmaps |
|
||||
| **Fred** | System Architect | Design system architecture, technical planning | Architecture docs, technical specs |
|
||||
| **Sarah** | Product Owner | Create user stories, manage backlog | User stories, acceptance criteria |
|
||||
| **David** | Developer | Implement features, write code | Code, tests, technical documentation |
|
||||
| **Veronica/Victor** | UX/UI Architect | Design interfaces, create components | UI designs, component specs |
|
||||
| **Design Architect** | Design Systems | Create design systems, maintain consistency | Design tokens, component libraries |
|
||||
| **Analyst** | Business Analyst | Research, analyze requirements | Analysis reports, recommendations |
|
||||
| **SM** | Scrum Master | Facilitate processes, remove blockers | Process improvements, team guidance |
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### 1. Starting a New Project
|
||||
```
|
||||
Load John (Product Manager)
|
||||
I need to create a new e-commerce platform for selling handmade crafts.
|
||||
Help me define the initial requirements and roadmap.
|
||||
Use the PRD template and market analysis framework.
|
||||
```
|
||||
|
||||
### 2. Designing System Architecture
|
||||
```
|
||||
Load Fred (System Architect)
|
||||
Based on these requirements: [paste requirements]
|
||||
Design a scalable microservices architecture for our e-commerce platform.
|
||||
Include security, performance, and scalability considerations.
|
||||
```
|
||||
|
||||
### 3. Creating Sprint-Ready Stories
|
||||
```
|
||||
Load Sarah (Product Owner)
|
||||
Break down this feature: [paste feature description]
|
||||
Into sprint-ready user stories with acceptance criteria.
|
||||
Ensure stories are testable and deliverable within a sprint.
|
||||
```
|
||||
|
||||
### 4. Implementing Features
|
||||
```
|
||||
Load David (Developer)
|
||||
Implement this user story: [paste story]
|
||||
Using React, Node.js, and PostgreSQL.
|
||||
Include unit tests and API documentation.
|
||||
```
|
||||
|
||||
### 5. Designing User Interfaces
|
||||
```
|
||||
Load Veronica (UX/UI Architect)
|
||||
Design a product detail page based on these requirements: [paste requirements]
|
||||
Create responsive components using our design system.
|
||||
Include accessibility considerations.
|
||||
```
|
||||
|
||||
## Quality Assurance with BMAD
|
||||
|
||||
### Using Quality Checklists
|
||||
```
|
||||
Validate this [deliverable type] against the [checklist name]:
|
||||
[paste deliverable content]
|
||||
|
||||
Provide specific improvement recommendations and compliance score.
|
||||
```
|
||||
|
||||
### Peer Review Simulation
|
||||
```
|
||||
Acting as [different persona], review this [deliverable] created by [original persona].
|
||||
Check for completeness, quality, and adherence to best practices.
|
||||
Provide constructive feedback and suggestions.
|
||||
```
|
||||
|
||||
## Advanced Techniques
|
||||
|
||||
### Multi-Persona Collaboration
|
||||
```
|
||||
Transition from John (PM) to Fred (Architect).
|
||||
Context: PRD for user authentication system
|
||||
Next task: Design secure authentication architecture
|
||||
Maintain consistency with PRD requirements and constraints.
|
||||
```
|
||||
|
||||
### Context Preservation
|
||||
```
|
||||
Refresh project context:
|
||||
- Project: E-commerce Platform
|
||||
- Current phase: Architecture Design
|
||||
- Active persona: Fred (Architect)
|
||||
- Previous deliverable: PRD with authentication requirements
|
||||
- Next milestone: Technical specification completion
|
||||
```
|
||||
|
||||
### Template Customization
|
||||
```
|
||||
Adapt the PRD template for a mobile application project.
|
||||
Include mobile-specific considerations:
|
||||
- Platform requirements (iOS/Android)
|
||||
- Performance constraints
|
||||
- Offline functionality needs
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Always Specify the Persona
|
||||
- Explicitly load the persona file you want to use
|
||||
- Reference the persona by name in your prompts
|
||||
- Maintain persona consistency throughout related tasks
|
||||
|
||||
### 2. Use Templates and Checklists
|
||||
- Reference specific templates for structured outputs
|
||||
- Apply quality checklists for validation
|
||||
- Customize templates for project-specific needs
|
||||
|
||||
### 3. Maintain Context
|
||||
- Provide clear project context when switching personas
|
||||
- Reference previous deliverables when building on prior work
|
||||
- Keep project goals and constraints visible
|
||||
|
||||
### 4. Validate Quality
|
||||
- Use BMAD quality checklists consistently
|
||||
- Conduct peer reviews using different personas
|
||||
- Iterate based on feedback and quality assessments
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Persona Not Responding Correctly
|
||||
**Problem**: AI doesn't follow persona guidelines
|
||||
**Solution**:
|
||||
- Explicitly reference the persona file path
|
||||
- Provide clear context about the persona's role
|
||||
- Include specific task requirements and templates
|
||||
|
||||
### Inconsistent Output Quality
|
||||
**Problem**: Results vary significantly between sessions
|
||||
**Solution**:
|
||||
- Always use quality checklists for validation
|
||||
- Reference specific templates and examples
|
||||
- Maintain consistent prompt structure
|
||||
|
||||
### Context Loss
|
||||
**Problem**: AI forgets project context during long sessions
|
||||
**Solution**:
|
||||
- Regularly refresh context with key project information
|
||||
- Save important outputs as reference documents
|
||||
- Use context preservation prompts
|
||||
|
||||
## Next Steps
|
||||
|
||||
### Explore Comprehensive Guides
|
||||
- **[How It Works](../how-it-works/README.md)** - Deep dive into BMAD methodology
|
||||
- **[System Architecture](../system-architecture/README.md)** - Understanding BMAD's structure
|
||||
- **[User Journeys](../user-journeys/README.md)** - Detailed workflow examples
|
||||
|
||||
### Set Up Your Environment
|
||||
- **[IDE Setup Guides](../ide-setup-guides/README.md)** - Configure your development environment
|
||||
- **[Integration Guides](../integration-guide/)** - Connect BMAD with your tools
|
||||
|
||||
### Advanced Usage
|
||||
- **[Persona Documentation](../personas/)** - Detailed persona capabilities
|
||||
- **[Task Libraries](../tasks/)** - Complete task workflows
|
||||
- **[Template Collections](../templates/)** - Comprehensive template library
|
||||
|
||||
## Community and Support
|
||||
|
||||
### Getting Help
|
||||
- **Documentation**: [BMAD Method Docs](https://github.com/bmadcode/BMAD-METHOD/docs)
|
||||
- **Community**: [GitHub Discussions](https://github.com/bmadcode/BMAD-METHOD/discussions)
|
||||
- **Issues**: [GitHub Issues](https://github.com/bmadcode/BMAD-METHOD/issues)
|
||||
|
||||
### Contributing
|
||||
- Share your BMAD success stories
|
||||
- Contribute new templates and workflows
|
||||
- Help improve documentation and guides
|
||||
|
||||
---
|
||||
|
||||
**Ready to transform your development process?** The BMAD Method provides the structure and quality framework you need to consistently deliver excellent results with AI assistance. Start with a simple use case and gradually expand your BMAD methodology application as you become more comfortable with the personas and workflows.
|
||||
|
||||
Remember: BMAD is a methodology, not software. Its power comes from consistent application of its principles and patterns, not from technical installation or configuration.
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
# BMAD Method: Video Walkthrough Script
|
||||
|
||||
## Introduction (30 seconds)
|
||||
[OPENING SHOT: Developer at computer with split screen showing code and AI chat]
|
||||
|
||||
**Narrator**: "Welcome to the BMAD Method - a revolutionary approach to AI-assisted software development. In this quick walkthrough, we'll show you how to leverage specialized AI personas to streamline your development workflow and deliver high-quality software faster than ever before."
|
||||
|
||||
## What is the BMAD Method? (45 seconds)
|
||||
[ANIMATION: Show the different personas and their roles in a development lifecycle]
|
||||
|
||||
**Narrator**: "The BMAD Method uses specialized AI personas, each an expert in their domain:
|
||||
- John, the Product Manager, defines requirements
|
||||
- Fred, the System Architect, designs system architecture
|
||||
- Sarah, the Product Owner, creates sprint-ready user stories
|
||||
- David, the Developer, implements code
|
||||
- And several other specialized roles
|
||||
|
||||
These personas work together seamlessly, handling different aspects of the development lifecycle while maintaining consistency and quality."
|
||||
|
||||
## Getting Started (1 minute)
|
||||
[SCREEN RECORDING: Show cloning repository and basic setup]
|
||||
|
||||
**Narrator**: "Getting started with the BMAD Method is simple. First, clone the BMAD Method repository to access all persona files and documentation. You can use the method in web-based AI platforms like ChatGPT or Claude, or in AI-enhanced IDEs like Cursor AI or Claude Code.
|
||||
|
||||
Let's set up our environment and activate our first persona..."
|
||||
|
||||
[SHOW: Terminal commands for cloning and basic setup]
|
||||
```git clone https://github.com/bmadcode/BMAD-METHOD.git```
|
||||
|
||||
## Using Your First Persona (1 minute)
|
||||
[SCREEN RECORDING: Activating John the Product Manager]
|
||||
|
||||
**Narrator**: "Let's start with John, our Product Manager persona. To activate John, we simply paste his persona file or use the activation phrase."
|
||||
|
||||
[SHOW: Pasting activation phrase]
|
||||
```I need John to help define requirements for a user authentication feature.```
|
||||
|
||||
**Narrator**: "Now we provide context about what we're building..."
|
||||
|
||||
[SHOW: Typing project context]
|
||||
```We need to add user authentication to our web application. Users should be able to register, log in, and recover their password.```
|
||||
|
||||
**Narrator**: "John analyzes our needs and creates a comprehensive PRD with user requirements, market analysis, and feature specifications."
|
||||
|
||||
[SHOW: John's output - a structured PRD]
|
||||
|
||||
## Multi-Persona Workflow (1 minute 30 seconds)
|
||||
[SCREEN RECORDING: Passing outputs between personas]
|
||||
|
||||
**Narrator**: "The real power of the BMAD Method comes from chaining personas together. Let's take John's PRD to Fred, our System Architect."
|
||||
|
||||
[SHOW: Activating Fred and sharing the PRD]
|
||||
```I need Fred to design the architecture for our authentication system based on these requirements.```
|
||||
|
||||
**Narrator**: "Fred creates a secure, scalable architecture design. Next, we take both the PRD and architecture to Sarah, our Product Owner."
|
||||
|
||||
[SHOW: Activating Sarah and sharing previous outputs]
|
||||
```I need Sarah to create user stories based on this architecture and these requirements.```
|
||||
|
||||
**Narrator**: "Sarah breaks down the work into sprint-ready user stories with clear acceptance criteria. Finally, we take a story to David, our Developer."
|
||||
|
||||
[SHOW: Activating David and sharing a user story]
|
||||
```I need David to implement this login functionality based on this user story.```
|
||||
|
||||
**Narrator**: "David provides production-ready code with tests and documentation, completing our workflow from idea to implementation."
|
||||
|
||||
## Advanced Tips (45 seconds)
|
||||
[SCREEN RECORDING: Show advanced usage patterns]
|
||||
|
||||
**Narrator**: "Here are some advanced tips for getting the most out of the BMAD Method:
|
||||
|
||||
1. Maintain consistent project context across personas
|
||||
2. Use the specialized checklists for quality assurance
|
||||
3. Leverage IDE integrations for seamless development
|
||||
4. Combine personas for complex problem-solving
|
||||
5. Reference previous outputs to maintain continuity"
|
||||
|
||||
[SHOW: Examples of each tip in action]
|
||||
|
||||
## Conclusion (30 seconds)
|
||||
[CLOSING SHOT: Completed project with multiple persona contributions]
|
||||
|
||||
**Narrator**: "The BMAD Method transforms how you work with AI in software development. Instead of generic assistance, you get specialized expertise at each stage of your project.
|
||||
|
||||
Visit our documentation for comprehensive guides on each persona, IDE setup instructions, and example projects. Start using the BMAD Method today and experience the future of AI-assisted development."
|
||||
|
||||
[SHOW: Final call to action with GitHub link]
|
||||
```https://github.com/bmadcode/BMAD-METHOD```
|
||||
|
||||
## End Screen (10 seconds)
|
||||
[DISPLAY: BMAD Method logo and tagline]
|
||||
"BMAD Method: Specialized AI Personas for Superior Software Development"
|
||||
|
|
@ -0,0 +1,402 @@
|
|||
# Scrum Master (SM) - Comprehensive Guide
|
||||
|
||||
## Overview
|
||||
|
||||
The **Scrum Master (SM)** persona in the BMAD Method serves as your **Agile Process Guardian and Team Enablement Specialist**. This persona excels at facilitating Scrum ceremonies, removing impediments, coaching teams in agile practices, and ensuring continuous improvement through retrospectives and process optimization. The Scrum Master focuses on creating an environment where teams can deliver high-quality software efficiently and sustainably.
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
### 🎯 Scrum Framework Mastery (95% Confidence)
|
||||
- **Ceremony Facilitation** - Sprint planning, daily standups, sprint reviews, retrospectives, backlog refinement
|
||||
- **Scrum Artifacts Management** - Product backlog, sprint backlog, increment, definition of done, user story management
|
||||
- **Role Coaching** - Product Owner coaching, development team guidance, stakeholder education, cross-functional collaboration
|
||||
- **Process Optimization** - Continuous improvement, impediment removal, workflow enhancement, team velocity optimization
|
||||
|
||||
### 🚀 Team Performance & Dynamics (90% Confidence)
|
||||
- **Team Formation & Development** - Team building, conflict resolution, communication facilitation, psychological safety creation
|
||||
- **Performance Metrics & Analytics** - Velocity tracking, burndown analysis, cycle time measurement, quality metrics monitoring
|
||||
- **Capacity Planning & Forecasting** - Sprint capacity planning, release planning, resource allocation, timeline estimation
|
||||
- **Risk Management** - Risk identification, mitigation strategies, dependency management, escalation procedures
|
||||
|
||||
### 🔄 Continuous Improvement (95% Confidence)
|
||||
- **Retrospective Facilitation** - Retrospective planning, technique selection, action item tracking, improvement implementation
|
||||
- **Process Assessment & Enhancement** - Workflow analysis, bottleneck identification, process standardization, best practice implementation
|
||||
- **Team Coaching & Mentoring** - Agile mindset development, skill building, knowledge transfer, career development support
|
||||
- **Organizational Agility** - Scaling agile practices, cross-team coordination, organizational change management
|
||||
|
||||
### 📊 Agile Metrics & Reporting (85% Confidence)
|
||||
- **Performance Dashboards** - Team metrics visualization, progress tracking, trend analysis, stakeholder reporting
|
||||
- **Predictability & Planning** - Velocity analysis, capacity forecasting, release planning, commitment tracking
|
||||
- **Quality Metrics** - Defect tracking, technical debt monitoring, code quality assessment, customer satisfaction measurement
|
||||
- **Process Metrics** - Cycle time analysis, lead time measurement, flow efficiency, waste identification
|
||||
|
||||
## Working Process
|
||||
|
||||
### Phase 1: Team Assessment & Initialization
|
||||
1. **Team Maturity Assessment**
|
||||
- Evaluate current agile practices and team dynamics
|
||||
- Assess team skills, experience, and collaboration patterns
|
||||
- Identify improvement opportunities and coaching needs
|
||||
- Establish baseline metrics and performance indicators
|
||||
|
||||
2. **Process Setup & Alignment**
|
||||
- Configure Scrum framework adapted to team context
|
||||
- Establish ceremony schedules and participation guidelines
|
||||
- Define team working agreements and communication protocols
|
||||
- Set up tracking tools and performance dashboards
|
||||
|
||||
3. **Stakeholder Alignment**
|
||||
- Align with Product Owner on backlog management and priorities
|
||||
- Coordinate with other Scrum Masters and teams for dependencies
|
||||
- Establish reporting and communication with leadership
|
||||
- Create transparency and visibility into team progress
|
||||
|
||||
### Phase 2: Sprint Execution & Facilitation
|
||||
1. **Sprint Planning Facilitation**
|
||||
- Guide team through sprint goal definition and commitment
|
||||
- Facilitate story estimation and capacity planning
|
||||
- Ensure sprint backlog is well-defined and achievable
|
||||
- Address dependencies and risks before sprint start
|
||||
|
||||
2. **Daily Scrum Optimization**
|
||||
- Facilitate focused and time-boxed daily standups
|
||||
- Help team identify and address impediments quickly
|
||||
- Ensure transparency and communication within team
|
||||
- Coach team members on effective standup participation
|
||||
|
||||
3. **Sprint Execution Support**
|
||||
- Monitor sprint progress and team dynamics
|
||||
- Remove impediments and facilitate problem-solving
|
||||
- Support team collaboration and knowledge sharing
|
||||
- Maintain sprint focus and protect team from distractions
|
||||
|
||||
4. **Sprint Review & Retrospective**
|
||||
- Facilitate productive sprint reviews with stakeholders
|
||||
- Guide retrospectives to identify improvement opportunities
|
||||
- Ensure action items are defined, tracked, and implemented
|
||||
- Celebrate successes and learn from challenges
|
||||
|
||||
### Phase 3: Continuous Improvement & Scaling
|
||||
1. **Performance Analysis & Optimization**
|
||||
- Analyze team metrics and identify improvement opportunities
|
||||
- Coach team on sustainable pace and quality practices
|
||||
- Implement process improvements based on retrospective insights
|
||||
- Monitor and measure impact of changes
|
||||
|
||||
2. **Team Development & Coaching**
|
||||
- Provide ongoing coaching on agile principles and practices
|
||||
- Support team members' professional development
|
||||
- Facilitate knowledge sharing and cross-training
|
||||
- Build team resilience and adaptability
|
||||
|
||||
3. **Organizational Integration**
|
||||
- Coordinate with other teams and Scrum Masters
|
||||
- Contribute to organizational agile transformation
|
||||
- Share best practices and lessons learned
|
||||
- Support scaling agile practices across the organization
|
||||
|
||||
## Integration with BMAD Method
|
||||
|
||||
### Upstream Integrations
|
||||
- **Receives from**:
|
||||
- Product Owners: Sprint goals, backlog priorities, stakeholder feedback, business context
|
||||
- Development Teams: Technical challenges, capacity constraints, improvement suggestions
|
||||
- System Architects: Technical dependencies, architectural decisions, integration requirements
|
||||
- Product Managers: Strategic direction, release planning, business priorities
|
||||
|
||||
### Scrum Process Integration
|
||||
```markdown
|
||||
# Typical Sprint Cycle Integration
|
||||
1. **Sprint Planning**: Collaborate with Product Owner and team to plan sprint
|
||||
2. **Daily Execution**: Facilitate daily standups and remove impediments
|
||||
3. **Sprint Review**: Present completed work to stakeholders for feedback
|
||||
4. **Retrospective**: Guide team reflection and continuous improvement
|
||||
5. **Backlog Refinement**: Support Product Owner in backlog preparation
|
||||
6. **Cross-Team Coordination**: Manage dependencies and integration points
|
||||
```
|
||||
|
||||
### Cross-Functional Collaboration
|
||||
- **With Product Owners**: Support backlog management, facilitate stakeholder communication, ensure business value delivery
|
||||
- **With Development Teams**: Coach agile practices, remove impediments, facilitate collaboration and knowledge sharing
|
||||
- **With System Architects**: Coordinate technical dependencies, support architectural decision-making, manage technical risks
|
||||
- **With Other Scrum Masters**: Share best practices, coordinate cross-team dependencies, support organizational agility
|
||||
|
||||
### Downstream Facilitation
|
||||
- **Enables**:
|
||||
- Development Teams: High-performing, self-organizing teams with clear focus and minimal impediments
|
||||
- Product Owners: Effective backlog management and stakeholder communication
|
||||
- Stakeholders: Transparency into team progress and predictable delivery
|
||||
- Organization: Continuous improvement and agile maturity growth
|
||||
|
||||
## Advanced Usage Patterns
|
||||
|
||||
### Multi-Team Coordination
|
||||
```markdown
|
||||
# Scaled Agile Facilitation
|
||||
1. **Scrum of Scrums**: Coordinate multiple teams working on related products
|
||||
2. **Program Increment Planning**: Facilitate large-scale planning and alignment
|
||||
3. **Cross-Team Retrospectives**: Share learnings and improve coordination
|
||||
4. **Dependency Management**: Identify and resolve cross-team dependencies
|
||||
5. **Release Train Coordination**: Support coordinated releases across teams
|
||||
```
|
||||
|
||||
### Agile Transformation Leadership
|
||||
```markdown
|
||||
# Organizational Change Management
|
||||
1. **Maturity Assessment**: Evaluate organizational agile readiness and gaps
|
||||
2. **Change Strategy**: Develop transformation roadmap and implementation plan
|
||||
3. **Training & Coaching**: Provide agile education and hands-on coaching
|
||||
4. **Culture Development**: Foster agile mindset and collaborative culture
|
||||
5. **Metrics & Measurement**: Track transformation progress and success
|
||||
```
|
||||
|
||||
### Advanced Facilitation Techniques
|
||||
```markdown
|
||||
# Sophisticated Facilitation Approaches
|
||||
1. **Liberating Structures**: Use advanced facilitation techniques for engagement
|
||||
2. **Systems Thinking**: Apply systems perspective to team and organizational challenges
|
||||
3. **Conflict Resolution**: Navigate team conflicts and interpersonal challenges
|
||||
4. **Innovation Facilitation**: Support creative problem-solving and innovation
|
||||
5. **Remote Team Facilitation**: Adapt practices for distributed and hybrid teams
|
||||
```
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
### New Team Formation
|
||||
- Establish Scrum framework and team working agreements
|
||||
- Coach team members on agile principles and practices
|
||||
- Facilitate team building and relationship development
|
||||
- Set up metrics and tracking for team performance
|
||||
|
||||
### Performance Improvement
|
||||
- Analyze team metrics to identify improvement opportunities
|
||||
- Facilitate retrospectives to generate actionable insights
|
||||
- Implement process changes and measure impact
|
||||
- Coach team on sustainable practices and quality focus
|
||||
|
||||
### Impediment Resolution
|
||||
- Identify and categorize team impediments and blockers
|
||||
- Develop strategies for impediment removal and prevention
|
||||
- Escalate organizational impediments to appropriate levels
|
||||
- Track impediment resolution and impact on team performance
|
||||
|
||||
### Cross-Team Coordination
|
||||
- Facilitate coordination between dependent teams
|
||||
- Manage shared resources and integration points
|
||||
- Support program-level planning and execution
|
||||
- Resolve conflicts and alignment issues between teams
|
||||
|
||||
## Troubleshooting Guide
|
||||
|
||||
### Common Team Challenges
|
||||
|
||||
**Challenge**: Low team engagement in Scrum ceremonies
|
||||
**Solution**: Assess ceremony value and format, adapt facilitation techniques, address underlying team dynamics and motivation
|
||||
|
||||
**Challenge**: Frequent sprint commitment failures
|
||||
**Solution**: Improve estimation practices, enhance capacity planning, address impediments more proactively, refine definition of done
|
||||
|
||||
**Challenge**: Poor collaboration and communication within team
|
||||
**Solution**: Facilitate team building activities, establish clear communication protocols, address conflicts directly, improve psychological safety
|
||||
|
||||
**Challenge**: Resistance to agile practices and change
|
||||
**Solution**: Understand root causes of resistance, provide education and coaching, demonstrate value through small wins, address organizational barriers
|
||||
|
||||
### Process and Performance Issues
|
||||
|
||||
**Challenge**: Inconsistent velocity and unpredictable delivery
|
||||
**Solution**: Improve estimation accuracy, stabilize team composition, address technical debt, enhance capacity planning
|
||||
|
||||
**Challenge**: High defect rates and quality issues
|
||||
**Solution**: Strengthen definition of done, implement quality practices, improve testing strategies, address technical debt systematically
|
||||
|
||||
**Challenge**: Burnout and unsustainable pace
|
||||
**Solution**: Monitor team capacity and workload, address organizational pressure, improve work-life balance, implement sustainable practices
|
||||
|
||||
### Organizational and Scaling Challenges
|
||||
|
||||
**Challenge**: Lack of organizational support for agile practices
|
||||
**Solution**: Educate leadership on agile benefits, demonstrate value through metrics, build coalition of agile champions, address systemic barriers
|
||||
|
||||
**Challenge**: Coordination difficulties between multiple teams
|
||||
**Solution**: Implement scaled agile frameworks, improve cross-team communication, establish clear dependency management, align on shared goals
|
||||
|
||||
**Challenge**: Inconsistent agile implementation across organization
|
||||
**Solution**: Establish communities of practice, standardize core practices, provide consistent training, create shared resources and tools
|
||||
|
||||
## Scrum Framework Implementation
|
||||
|
||||
### Sprint Planning Excellence
|
||||
```markdown
|
||||
# Sprint Planning Best Practices
|
||||
**Preparation Phase**:
|
||||
- Ensure backlog is refined and ready for planning
|
||||
- Confirm team capacity and availability
|
||||
- Review previous sprint outcomes and lessons learned
|
||||
- Prepare planning materials and tools
|
||||
|
||||
**Planning Session Structure**:
|
||||
1. **Sprint Goal Definition** (15 minutes)
|
||||
- Collaborate with Product Owner to define clear sprint goal
|
||||
- Ensure goal aligns with product vision and business objectives
|
||||
- Communicate goal clearly to all team members
|
||||
|
||||
2. **Backlog Item Selection** (45 minutes)
|
||||
- Review and discuss prioritized backlog items
|
||||
- Ensure team understands acceptance criteria and requirements
|
||||
- Select items that support sprint goal achievement
|
||||
|
||||
3. **Task Breakdown and Estimation** (60 minutes)
|
||||
- Break down selected items into actionable tasks
|
||||
- Estimate effort and identify dependencies
|
||||
- Validate capacity against team availability
|
||||
|
||||
4. **Commitment and Planning Finalization** (15 minutes)
|
||||
- Confirm team commitment to sprint goal and backlog
|
||||
- Address any remaining questions or concerns
|
||||
- Document sprint plan and communicate to stakeholders
|
||||
```
|
||||
|
||||
### Daily Scrum Optimization
|
||||
```markdown
|
||||
# Daily Scrum Facilitation Guide
|
||||
**Pre-Meeting Preparation**:
|
||||
- Review sprint progress and identify potential discussion topics
|
||||
- Check for impediments or blockers that need attention
|
||||
- Prepare to guide conversation toward sprint goal
|
||||
|
||||
**Meeting Structure** (15 minutes maximum):
|
||||
1. **Progress Updates** (10 minutes)
|
||||
- Each team member shares: completed work, planned work, impediments
|
||||
- Focus on progress toward sprint goal, not detailed status reports
|
||||
- Encourage team members to speak to each other, not just Scrum Master
|
||||
|
||||
2. **Impediment Identification** (3 minutes)
|
||||
- Identify blockers that prevent progress toward sprint goal
|
||||
- Note impediments for follow-up after meeting
|
||||
- Avoid problem-solving during standup unless quick resolution possible
|
||||
|
||||
3. **Coordination and Planning** (2 minutes)
|
||||
- Identify collaboration opportunities and dependencies
|
||||
- Plan any necessary follow-up conversations
|
||||
- Confirm next steps and daily commitments
|
||||
|
||||
**Post-Meeting Actions**:
|
||||
- Address impediments and blockers immediately
|
||||
- Facilitate follow-up conversations as needed
|
||||
- Update sprint tracking and communicate progress
|
||||
```
|
||||
|
||||
### Retrospective Facilitation Mastery
|
||||
```markdown
|
||||
# Retrospective Techniques and Formats
|
||||
**Retrospective Planning**:
|
||||
- Select appropriate technique based on team needs and context
|
||||
- Prepare materials and tools for chosen retrospective format
|
||||
- Set clear objectives for retrospective session
|
||||
- Ensure safe environment for open and honest feedback
|
||||
|
||||
**Popular Retrospective Formats**:
|
||||
|
||||
1. **Start, Stop, Continue**
|
||||
- What should we start doing?
|
||||
- What should we stop doing?
|
||||
- What should we continue doing?
|
||||
|
||||
2. **Glad, Sad, Mad**
|
||||
- What made us glad this sprint?
|
||||
- What made us sad or disappointed?
|
||||
- What made us mad or frustrated?
|
||||
|
||||
3. **Sailboat Retrospective**
|
||||
- Wind (what helped us move forward)
|
||||
- Anchors (what held us back)
|
||||
- Rocks (risks and obstacles ahead)
|
||||
- Island (our goal/destination)
|
||||
|
||||
4. **4Ls Retrospective**
|
||||
- Liked (what went well)
|
||||
- Learned (what we discovered)
|
||||
- Lacked (what was missing)
|
||||
- Longed for (what we wished for)
|
||||
|
||||
**Action Item Management**:
|
||||
- Ensure action items are specific, measurable, and achievable
|
||||
- Assign ownership and timelines for each action item
|
||||
- Track progress on action items from previous retrospectives
|
||||
- Limit number of action items to ensure focus and completion
|
||||
```
|
||||
|
||||
## Agile Metrics and Performance Tracking
|
||||
|
||||
### Essential Scrum Metrics
|
||||
```markdown
|
||||
# Key Performance Indicators
|
||||
**Velocity Metrics**:
|
||||
- Story points completed per sprint
|
||||
- Velocity trend analysis over time
|
||||
- Velocity predictability and consistency
|
||||
- Capacity utilization and efficiency
|
||||
|
||||
**Quality Metrics**:
|
||||
- Defect rate and escape rate
|
||||
- Technical debt accumulation
|
||||
- Code coverage and quality scores
|
||||
- Customer satisfaction and feedback
|
||||
|
||||
**Flow Metrics**:
|
||||
- Cycle time (from start to done)
|
||||
- Lead time (from request to delivery)
|
||||
- Work in progress (WIP) limits and flow
|
||||
- Throughput and delivery frequency
|
||||
|
||||
**Team Health Metrics**:
|
||||
- Team satisfaction and engagement
|
||||
- Retrospective action item completion
|
||||
- Impediment resolution time
|
||||
- Team stability and retention
|
||||
```
|
||||
|
||||
### Performance Dashboard Creation
|
||||
```markdown
|
||||
# Dashboard Design Principles
|
||||
**Stakeholder-Specific Views**:
|
||||
- **Team Dashboard**: Focus on sprint progress, impediments, and team metrics
|
||||
- **Product Owner Dashboard**: Emphasize business value, release progress, and stakeholder feedback
|
||||
- **Leadership Dashboard**: Highlight delivery predictability, team health, and organizational metrics
|
||||
|
||||
**Visual Design Best Practices**:
|
||||
- Use clear, intuitive visualizations (burndown charts, velocity graphs, etc.)
|
||||
- Provide context and trends, not just current state
|
||||
- Include both quantitative metrics and qualitative insights
|
||||
- Enable drill-down capabilities for detailed analysis
|
||||
|
||||
**Automated Reporting**:
|
||||
- Integrate with project management tools for real-time data
|
||||
- Set up automated alerts for metric thresholds and anomalies
|
||||
- Generate regular reports for stakeholders and leadership
|
||||
- Maintain data accuracy and consistency across tools
|
||||
```
|
||||
|
||||
## Tools and Technologies
|
||||
|
||||
### Agile Project Management Tools
|
||||
```markdown
|
||||
# Primary Tool Categories
|
||||
**Comprehensive Platforms**:
|
||||
- **Jira**: Advanced workflow management, reporting, and integration capabilities
|
||||
- **Azure DevOps**: End-to-end development lifecycle with integrated agile tools
|
||||
- **Rally**: Enterprise-scale agile planning and tracking
|
||||
- **VersionOne**: Comprehensive agile lifecycle management
|
||||
|
||||
**Lightweight Solutions**:
|
||||
- **Trello**: Simple kanban boards with basic tracking capabilities
|
||||
- **Asana**: Task management with agile project templates
|
||||
- **Monday.com**: Flexible work management with agile workflows
|
||||
- **Linear**: Modern issue tracking with focus on developer experience
|
||||
|
||||
**Specialized Tools**:
|
||||
- **Miro**: Visual collaboration for brainstorming and planning
|
||||
- **Slack**: Communication and collaboration tool for team interactions
|
||||
- **Confluence**: Documentation and knowledge sharing platform
|
||||
- **GitLab**: Version control and CI/CD tool for software development
|
||||
|
|
@ -0,0 +1,465 @@
|
|||
# Scrum Master (Mike) Quality Standards
|
||||
|
||||
## Overview
|
||||
|
||||
This document establishes comprehensive quality standards for Scrum Master activities within the BMAD Method. These standards ensure consistent, high-quality Scrum facilitation that drives team performance, process improvement, and successful project outcomes.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Quality Framework](#quality-framework)
|
||||
2. [Ceremony Facilitation Quality Standards](#ceremony-facilitation-quality-standards)
|
||||
3. [Team Coaching Quality Standards](#team-coaching-quality-standards)
|
||||
4. [Process Management Quality Standards](#process-management-quality-standards)
|
||||
5. [Impediment Resolution Quality Standards](#impediment-resolution-quality-standards)
|
||||
6. [Stakeholder Communication Quality Standards](#stakeholder-communication-quality-standards)
|
||||
7. [Continuous Improvement Quality Standards](#continuous-improvement-quality-standards)
|
||||
8. [Quality Metrics and Measurement](#quality-metrics-and-measurement)
|
||||
9. [Quality Assurance Procedures](#quality-assurance-procedures)
|
||||
10. [Continuous Improvement](#continuous-improvement)
|
||||
|
||||
## Quality Framework
|
||||
|
||||
### Quality Principles
|
||||
|
||||
1. **Servant Leadership**: Focus on serving the team and removing obstacles to their success
|
||||
2. **Facilitation Excellence**: Create environments where teams can collaborate effectively
|
||||
3. **Continuous Improvement**: Drive ongoing process and team performance improvements
|
||||
4. **Transparency**: Maintain visibility into team progress, challenges, and opportunities
|
||||
5. **Empowerment**: Enable teams to become self-organizing and high-performing
|
||||
6. **Value Focus**: Ensure all activities contribute to delivering business value
|
||||
|
||||
### Quality Dimensions
|
||||
|
||||
#### Facilitation Quality
|
||||
- Ceremony effectiveness and engagement
|
||||
- Meeting preparation and execution
|
||||
- Conflict resolution and consensus building
|
||||
- Communication facilitation and clarity
|
||||
|
||||
#### Coaching Quality
|
||||
- Team development and skill building
|
||||
- Individual coaching and mentoring
|
||||
- Process coaching and improvement
|
||||
- Agile mindset development
|
||||
|
||||
#### Process Quality
|
||||
- Scrum framework adherence
|
||||
- Process optimization and refinement
|
||||
- Metrics tracking and analysis
|
||||
- Risk and impediment management
|
||||
|
||||
## Ceremony Facilitation Quality Standards
|
||||
|
||||
### Sprint Planning Quality Standards
|
||||
|
||||
#### Preparation Quality
|
||||
- [ ] **Agenda Prepared**: Detailed agenda created and shared 24 hours in advance
|
||||
- [ ] **Backlog Ready**: Product backlog refined and prioritized by Product Owner
|
||||
- [ ] **Capacity Calculated**: Team capacity accurately calculated and documented
|
||||
- [ ] **Environment Setup**: Meeting space and tools properly configured
|
||||
- [ ] **Stakeholder Coordination**: Key stakeholders identified and invited
|
||||
|
||||
#### Facilitation Execution Quality
|
||||
- [ ] **Time Management**: Meeting stays within allocated timeframe (4 hours maximum)
|
||||
- [ ] **Goal Clarity**: Sprint goal is clearly defined and understood by all
|
||||
- [ ] **Participation**: All team members actively participate in planning
|
||||
- [ ] **Commitment Realism**: Team commitment is realistic and achievable
|
||||
- [ ] **Documentation**: Sprint backlog and commitments properly documented
|
||||
|
||||
#### Outcome Quality
|
||||
- [ ] **Clear Sprint Goal**: Specific, measurable sprint goal established
|
||||
- [ ] **Realistic Commitment**: Team commitment aligns with capacity and velocity
|
||||
- [ ] **Task Breakdown**: Stories broken down into actionable tasks
|
||||
- [ ] **Risk Identification**: Potential risks and dependencies identified
|
||||
- [ ] **Team Buy-in**: Full team commitment to sprint plan
|
||||
|
||||
### Daily Scrum Quality Standards
|
||||
|
||||
#### Structure and Timing Quality
|
||||
- [ ] **Consistent Schedule**: Daily scrum occurs at same time and place
|
||||
- [ ] **Timebox Adherence**: Meeting completed within 15 minutes
|
||||
- [ ] **Full Attendance**: All team members present or properly represented
|
||||
- [ ] **Focus Maintenance**: Discussion stays focused on sprint goal progress
|
||||
- [ ] **Action Orientation**: Clear next steps and coordination identified
|
||||
|
||||
#### Facilitation Quality
|
||||
- [ ] **Team-Centric**: Team members communicate with each other, not just Scrum Master
|
||||
- [ ] **Impediment Identification**: Blockers clearly identified and noted
|
||||
- [ ] **Progress Transparency**: Clear understanding of sprint progress
|
||||
- [ ] **Coordination Support**: Collaboration needs identified and facilitated
|
||||
- [ ] **Energy Management**: Team energy and engagement maintained
|
||||
|
||||
#### Follow-up Quality
|
||||
- [ ] **Impediment Resolution**: Immediate action on identified impediments
|
||||
- [ ] **Progress Tracking**: Sprint progress updated and communicated
|
||||
- [ ] **Coordination Facilitation**: Follow-up conversations facilitated as needed
|
||||
- [ ] **Stakeholder Communication**: Relevant updates shared with stakeholders
|
||||
|
||||
### Sprint Review Quality Standards
|
||||
|
||||
#### Preparation Quality
|
||||
- [ ] **Demo Environment**: Stable demo environment prepared and tested
|
||||
- [ ] **Stakeholder Engagement**: Relevant stakeholders invited and confirmed
|
||||
- [ ] **Demo Script**: Clear demonstration script prepared with team
|
||||
- [ ] **Feedback Mechanism**: Structured approach for collecting feedback
|
||||
- [ ] **Metrics Compilation**: Sprint metrics compiled and ready for presentation
|
||||
|
||||
#### Facilitation Quality
|
||||
- [ ] **Business Focus**: Demonstration focuses on business value delivered
|
||||
- [ ] **Stakeholder Engagement**: Active stakeholder participation and feedback
|
||||
- [ ] **Feedback Collection**: Systematic collection and documentation of feedback
|
||||
- [ ] **Backlog Updates**: Product backlog updated based on feedback
|
||||
- [ ] **Future Planning**: Clear discussion of upcoming priorities
|
||||
|
||||
#### Outcome Quality
|
||||
- [ ] **Value Demonstration**: Clear demonstration of business value delivered
|
||||
- [ ] **Stakeholder Satisfaction**: Positive stakeholder feedback on delivered work
|
||||
- [ ] **Actionable Feedback**: Specific, actionable feedback collected and documented
|
||||
- [ ] **Backlog Refinement**: Product backlog updated with new insights
|
||||
- [ ] **Transparency**: Clear visibility into team progress and challenges
|
||||
|
||||
### Sprint Retrospective Quality Standards
|
||||
|
||||
#### Facilitation Technique Quality
|
||||
- [ ] **Technique Selection**: Appropriate retrospective technique selected for team needs
|
||||
- [ ] **Safe Environment**: Psychologically safe environment created for open discussion
|
||||
- [ ] **Balanced Participation**: All team members actively participate
|
||||
- [ ] **Data-Driven Discussion**: Discussion based on facts and observations
|
||||
- [ ] **Action-Oriented Outcomes**: Specific, actionable improvement items identified
|
||||
|
||||
#### Process Quality
|
||||
- [ ] **Structured Approach**: Clear structure and flow for retrospective session
|
||||
- [ ] **Time Management**: Effective use of allocated time (1.5 hours for 2-week sprint)
|
||||
- [ ] **Focus Areas**: Clear focus on most important improvement opportunities
|
||||
- [ ] **Root Cause Analysis**: Deep exploration of underlying causes
|
||||
- [ ] **Commitment Building**: Team commitment to improvement actions
|
||||
|
||||
#### Outcome Quality
|
||||
- [ ] **Actionable Improvements**: Specific improvement actions with owners and timelines
|
||||
- [ ] **Realistic Scope**: Improvement actions are achievable within team capacity
|
||||
- [ ] **Measurable Impact**: Success criteria defined for improvement actions
|
||||
- [ ] **Follow-through Plan**: Clear plan for tracking and implementing improvements
|
||||
- [ ] **Learning Culture**: Reinforcement of continuous learning and improvement mindset
|
||||
|
||||
## Team Coaching Quality Standards
|
||||
|
||||
### Individual Coaching Quality Standards
|
||||
|
||||
#### Coaching Approach Quality
|
||||
- [ ] **Active Listening**: Demonstrates active listening and empathy
|
||||
- [ ] **Question-Based Coaching**: Uses powerful questions to guide discovery
|
||||
- [ ] **Goal-Oriented**: Coaching sessions have clear objectives and outcomes
|
||||
- [ ] **Skill Development**: Focuses on developing individual capabilities
|
||||
- [ ] **Growth Mindset**: Encourages learning and experimentation
|
||||
|
||||
#### Coaching Relationship Quality
|
||||
- [ ] **Trust Building**: Establishes trust and psychological safety
|
||||
- [ ] **Confidentiality**: Maintains appropriate confidentiality
|
||||
- [ ] **Regular Engagement**: Consistent coaching interactions and follow-up
|
||||
- [ ] **Feedback Quality**: Provides constructive, specific feedback
|
||||
- [ ] **Support Provision**: Offers appropriate support and resources
|
||||
|
||||
### Team Development Quality Standards
|
||||
|
||||
#### Team Dynamics Coaching
|
||||
- [ ] **Collaboration Enhancement**: Actively works to improve team collaboration
|
||||
- [ ] **Conflict Resolution**: Effectively facilitates conflict resolution
|
||||
- [ ] **Communication Improvement**: Coaches team on effective communication
|
||||
- [ ] **Decision-Making Support**: Helps team improve decision-making processes
|
||||
- [ ] **Self-Organization**: Guides team toward greater self-organization
|
||||
|
||||
#### Agile Mindset Development
|
||||
- [ ] **Principle Understanding**: Ensures team understands agile principles
|
||||
- [ ] **Practice Adoption**: Supports adoption of agile practices
|
||||
- [ ] **Mindset Shift**: Facilitates shift from traditional to agile thinking
|
||||
- [ ] **Experimentation**: Encourages experimentation and learning
|
||||
- [ ] **Adaptation**: Helps team adapt practices to their context
|
||||
|
||||
### Skills Development Quality Standards
|
||||
|
||||
#### Technical Coaching Support
|
||||
- [ ] **Practice Identification**: Identifies beneficial technical practices
|
||||
- [ ] **Learning Facilitation**: Facilitates team learning opportunities
|
||||
- [ ] **Knowledge Sharing**: Promotes knowledge sharing within team
|
||||
- [ ] **Skill Gap Assessment**: Identifies and addresses skill gaps
|
||||
- [ ] **External Resource Connection**: Connects team with external learning resources
|
||||
|
||||
#### Process Skills Development
|
||||
- [ ] **Estimation Skills**: Coaches team on effective estimation techniques
|
||||
- [ ] **Planning Skills**: Develops team planning and forecasting capabilities
|
||||
- [ ] **Quality Practices**: Promotes adoption of quality practices
|
||||
- [ ] **Collaboration Tools**: Helps team effectively use collaboration tools
|
||||
- [ ] **Metrics Understanding**: Educates team on meaningful metrics
|
||||
|
||||
## Process Management Quality Standards
|
||||
|
||||
### Scrum Framework Adherence Quality Standards
|
||||
|
||||
#### Framework Implementation
|
||||
- [ ] **Role Clarity**: Clear understanding and execution of Scrum roles
|
||||
- [ ] **Event Execution**: Proper execution of all Scrum events
|
||||
- [ ] **Artifact Management**: Effective management of Scrum artifacts
|
||||
- [ ] **Rule Adherence**: Adherence to Scrum rules and principles
|
||||
- [ ] **Adaptation Appropriateness**: Appropriate adaptation of framework to context
|
||||
|
||||
#### Process Optimization
|
||||
- [ ] **Continuous Assessment**: Regular assessment of process effectiveness
|
||||
- [ ] **Improvement Identification**: Systematic identification of improvement opportunities
|
||||
- [ ] **Change Management**: Effective management of process changes
|
||||
- [ ] **Best Practice Integration**: Integration of relevant best practices
|
||||
- [ ] **Team Input Integration**: Incorporation of team feedback in process improvements
|
||||
|
||||
### Metrics and Measurement Quality Standards
|
||||
|
||||
#### Metrics Collection Quality
|
||||
- [ ] **Relevant Metrics**: Collection of metrics that drive meaningful insights
|
||||
- [ ] **Accurate Data**: Accurate and reliable data collection
|
||||
- [ ] **Timely Reporting**: Timely compilation and sharing of metrics
|
||||
- [ ] **Trend Analysis**: Analysis of trends and patterns in metrics
|
||||
- [ ] **Actionable Insights**: Translation of metrics into actionable insights
|
||||
|
||||
#### Performance Tracking Quality
|
||||
- [ ] **Velocity Tracking**: Accurate tracking and analysis of team velocity
|
||||
- [ ] **Quality Metrics**: Monitoring of quality indicators and trends
|
||||
- [ ] **Predictability Assessment**: Assessment of team predictability and consistency
|
||||
- [ ] **Capacity Utilization**: Tracking of team capacity utilization
|
||||
- [ ] **Improvement Measurement**: Measurement of improvement initiative effectiveness
|
||||
|
||||
## Impediment Resolution Quality Standards
|
||||
|
||||
### Impediment Identification Quality Standards
|
||||
|
||||
#### Proactive Identification
|
||||
- [ ] **Early Detection**: Proactive identification of potential impediments
|
||||
- [ ] **Pattern Recognition**: Recognition of recurring impediment patterns
|
||||
- [ ] **Risk Assessment**: Assessment of impediment impact and urgency
|
||||
- [ ] **Root Cause Analysis**: Investigation of underlying causes
|
||||
- [ ] **Prevention Focus**: Focus on preventing future impediments
|
||||
|
||||
#### Documentation Quality
|
||||
- [ ] **Clear Description**: Clear and specific impediment descriptions
|
||||
- [ ] **Impact Assessment**: Documented impact on team and sprint goals
|
||||
- [ ] **Ownership Assignment**: Clear assignment of resolution ownership
|
||||
- [ ] **Timeline Tracking**: Tracking of impediment age and resolution time
|
||||
- [ ] **Resolution Documentation**: Documentation of resolution approaches and outcomes
|
||||
|
||||
### Resolution Process Quality Standards
|
||||
|
||||
#### Resolution Approach
|
||||
- [ ] **Systematic Process**: Systematic approach to impediment resolution
|
||||
- [ ] **Appropriate Escalation**: Timely escalation when needed
|
||||
- [ ] **Resource Mobilization**: Effective mobilization of required resources
|
||||
- [ ] **Communication Management**: Clear communication about resolution progress
|
||||
- [ ] **Follow-up Verification**: Verification that impediments are truly resolved
|
||||
|
||||
#### Resolution Effectiveness
|
||||
- [ ] **Timely Resolution**: Impediments resolved within appropriate timeframes
|
||||
- [ ] **Sustainable Solutions**: Solutions address root causes, not just symptoms
|
||||
- [ ] **Team Empowerment**: Solutions empower team to handle similar issues
|
||||
- [ ] **Learning Integration**: Lessons learned integrated into team practices
|
||||
- [ ] **Prevention Measures**: Implementation of measures to prevent recurrence
|
||||
|
||||
## Stakeholder Communication Quality Standards
|
||||
|
||||
### Communication Planning Quality Standards
|
||||
|
||||
#### Stakeholder Analysis
|
||||
- [ ] **Stakeholder Identification**: Complete identification of relevant stakeholders
|
||||
- [ ] **Communication Needs**: Understanding of stakeholder communication needs
|
||||
- [ ] **Frequency Planning**: Appropriate communication frequency for each stakeholder
|
||||
- [ ] **Channel Selection**: Selection of appropriate communication channels
|
||||
- [ ] **Content Customization**: Customization of content for different stakeholders
|
||||
|
||||
#### Communication Strategy
|
||||
- [ ] **Clear Objectives**: Clear objectives for each communication
|
||||
- [ ] **Value Focus**: Communication focuses on business value and outcomes
|
||||
- [ ] **Transparency**: Honest and transparent communication about progress and challenges
|
||||
- [ ] **Timeliness**: Timely communication of important information
|
||||
- [ ] **Feedback Integration**: Integration of stakeholder feedback
|
||||
|
||||
### Communication Execution Quality Standards
|
||||
|
||||
#### Message Quality
|
||||
- [ ] **Clarity**: Clear and easily understood messages
|
||||
- [ ] **Accuracy**: Accurate and up-to-date information
|
||||
- [ ] **Relevance**: Relevant information for target audience
|
||||
- [ ] **Completeness**: Complete information without overwhelming detail
|
||||
- [ ] **Actionability**: Clear actions or decisions required from stakeholders
|
||||
|
||||
#### Delivery Quality
|
||||
- [ ] **Professional Presentation**: Professional and well-organized presentation
|
||||
- [ ] **Engagement**: Active engagement with stakeholders
|
||||
- [ ] **Question Handling**: Effective handling of stakeholder questions
|
||||
- [ ] **Follow-up**: Appropriate follow-up on commitments and actions
|
||||
- [ ] **Documentation**: Proper documentation of important communications
|
||||
|
||||
## Quality Metrics and Measurement
|
||||
|
||||
### Ceremony Effectiveness Metrics
|
||||
|
||||
#### Sprint Planning Metrics
|
||||
- **Planning Efficiency**: Time spent in planning relative to sprint duration
|
||||
- **Commitment Accuracy**: Accuracy of sprint commitments vs. actual delivery
|
||||
- **Goal Achievement**: Percentage of sprint goals achieved
|
||||
- **Team Satisfaction**: Team satisfaction with planning process
|
||||
|
||||
#### Daily Scrum Metrics
|
||||
- **Attendance Rate**: Percentage of team members attending daily scrums
|
||||
- **Duration Compliance**: Percentage of daily scrums completed within 15 minutes
|
||||
- **Impediment Identification**: Number of impediments identified per sprint
|
||||
- **Follow-up Effectiveness**: Percentage of impediments resolved within target time
|
||||
|
||||
#### Sprint Review Metrics
|
||||
- **Stakeholder Attendance**: Percentage of invited stakeholders attending
|
||||
- **Feedback Quality**: Quality and actionability of stakeholder feedback
|
||||
- **Demo Success**: Percentage of planned demonstrations completed successfully
|
||||
- **Stakeholder Satisfaction**: Stakeholder satisfaction with review process
|
||||
|
||||
#### Sprint Retrospective Metrics
|
||||
- **Participation Level**: Level of team participation in retrospectives
|
||||
- **Action Item Generation**: Number of actionable improvement items per retrospective
|
||||
- **Implementation Rate**: Percentage of retrospective actions implemented
|
||||
- **Improvement Impact**: Measured impact of implemented improvements
|
||||
|
||||
### Team Performance Metrics
|
||||
|
||||
#### Team Development Metrics
|
||||
- **Team Maturity**: Assessment of team agile maturity level
|
||||
- **Self-Organization**: Level of team self-organization and autonomy
|
||||
- **Collaboration Quality**: Quality of team collaboration and communication
|
||||
- **Skill Development**: Progress on individual and team skill development
|
||||
|
||||
#### Process Adherence Metrics
|
||||
- **Framework Compliance**: Adherence to Scrum framework and practices
|
||||
- **Process Consistency**: Consistency of process execution across sprints
|
||||
- **Adaptation Effectiveness**: Effectiveness of process adaptations and improvements
|
||||
- **Best Practice Adoption**: Adoption rate of recommended best practices
|
||||
|
||||
### Impediment Management Metrics
|
||||
|
||||
#### Impediment Resolution Metrics
|
||||
- **Resolution Time**: Average time to resolve impediments
|
||||
- **Resolution Rate**: Percentage of impediments resolved within target time
|
||||
- **Escalation Rate**: Percentage of impediments requiring escalation
|
||||
- **Recurrence Rate**: Percentage of impediments that recur
|
||||
|
||||
#### Prevention Effectiveness Metrics
|
||||
- **Impediment Frequency**: Number of impediments per sprint
|
||||
- **Prevention Success**: Reduction in recurring impediment types
|
||||
- **Proactive Identification**: Percentage of impediments identified proactively
|
||||
- **Team Empowerment**: Team's ability to resolve impediments independently
|
||||
|
||||
## Quality Assurance Procedures
|
||||
|
||||
### Ceremony Quality Assurance
|
||||
|
||||
#### Pre-Ceremony QA
|
||||
1. **Preparation Checklist**: Verify all preparation activities completed
|
||||
2. **Agenda Review**: Review and validate ceremony agenda
|
||||
3. **Resource Verification**: Confirm availability of required resources
|
||||
4. **Stakeholder Confirmation**: Confirm stakeholder attendance and preparation
|
||||
5. **Environment Setup**: Verify meeting environment and tools are ready
|
||||
|
||||
#### During-Ceremony QA
|
||||
1. **Facilitation Monitoring**: Monitor facilitation effectiveness and engagement
|
||||
2. **Time Management**: Track time usage and adjust as needed
|
||||
3. **Participation Assessment**: Assess level and quality of participation
|
||||
4. **Outcome Tracking**: Track progress toward ceremony objectives
|
||||
5. **Issue Identification**: Identify and address issues as they arise
|
||||
|
||||
#### Post-Ceremony QA
|
||||
1. **Outcome Validation**: Validate that ceremony objectives were achieved
|
||||
2. **Action Item Review**: Review and validate action items and commitments
|
||||
3. **Feedback Collection**: Collect feedback on ceremony effectiveness
|
||||
4. **Documentation Review**: Review and validate ceremony documentation
|
||||
5. **Improvement Identification**: Identify opportunities for ceremony improvement
|
||||
|
||||
### Team Coaching Quality Assurance
|
||||
|
||||
#### Coaching Session QA
|
||||
1. **Objective Setting**: Clear objectives set for coaching interactions
|
||||
2. **Approach Validation**: Coaching approach appropriate for situation and individual
|
||||
3. **Progress Tracking**: Progress toward coaching goals tracked and measured
|
||||
4. **Feedback Integration**: Feedback from coachees integrated into approach
|
||||
5. **Outcome Assessment**: Assessment of coaching effectiveness and impact
|
||||
|
||||
#### Team Development QA
|
||||
1. **Development Planning**: Clear development plans for team and individuals
|
||||
2. **Progress Monitoring**: Regular monitoring of development progress
|
||||
3. **Skill Assessment**: Regular assessment of team and individual skills
|
||||
4. **Resource Provision**: Appropriate resources provided for development
|
||||
5. **Impact Measurement**: Measurement of development impact on performance
|
||||
|
||||
### Process Management Quality Assurance
|
||||
|
||||
#### Process Adherence QA
|
||||
1. **Framework Compliance**: Regular assessment of Scrum framework adherence
|
||||
2. **Practice Consistency**: Monitoring of practice consistency across sprints
|
||||
3. **Adaptation Appropriateness**: Assessment of process adaptations and changes
|
||||
4. **Improvement Effectiveness**: Evaluation of process improvement effectiveness
|
||||
5. **Team Feedback Integration**: Integration of team feedback on processes
|
||||
|
||||
#### Metrics and Measurement QA
|
||||
1. **Data Accuracy**: Verification of metrics data accuracy and completeness
|
||||
2. **Analysis Quality**: Quality of metrics analysis and insights
|
||||
3. **Reporting Timeliness**: Timeliness of metrics reporting and communication
|
||||
4. **Action Orientation**: Translation of metrics into actionable improvements
|
||||
5. **Stakeholder Value**: Value of metrics and reporting to stakeholders
|
||||
|
||||
## Continuous Improvement
|
||||
|
||||
### Quality Improvement Process
|
||||
|
||||
#### Regular Quality Reviews
|
||||
- **Weekly**: Review current sprint quality indicators and issues
|
||||
- **Sprint Retrospectives**: Include quality focus in team retrospectives
|
||||
- **Monthly**: Comprehensive quality metrics review and analysis
|
||||
- **Quarterly**: Quality standards review and update
|
||||
|
||||
#### Improvement Identification
|
||||
1. **Metrics Analysis**: Analyze quality metrics to identify improvement opportunities
|
||||
2. **Team Feedback**: Collect and analyze team feedback on Scrum Master effectiveness
|
||||
3. **Stakeholder Input**: Gather stakeholder input on process and communication quality
|
||||
4. **Self-Assessment**: Regular self-assessment against quality standards
|
||||
5. **Peer Review**: Peer review with other Scrum Masters
|
||||
|
||||
#### Improvement Implementation
|
||||
1. **Improvement Planning**: Develop specific improvement plans and timelines
|
||||
2. **Skill Development**: Pursue skill development to address quality gaps
|
||||
3. **Process Refinement**: Refine processes and practices to improve quality
|
||||
4. **Tool Enhancement**: Enhance tools and templates to support quality
|
||||
5. **Knowledge Sharing**: Share learnings and best practices with other Scrum Masters
|
||||
|
||||
### Quality Culture Development
|
||||
|
||||
#### Team Quality Awareness
|
||||
- **Quality Discussions**: Regular discussions about quality in team interactions
|
||||
- **Quality Metrics Sharing**: Share quality metrics and trends with team
|
||||
- **Quality Recognition**: Recognize and celebrate quality achievements
|
||||
- **Quality Learning**: Promote learning about quality practices and standards
|
||||
|
||||
#### Organizational Quality Contribution
|
||||
- **Best Practice Sharing**: Share quality best practices across Scrum Master community
|
||||
- **Standard Development**: Contribute to development of organizational quality standards
|
||||
- **Quality Advocacy**: Advocate for quality focus in organizational processes
|
||||
- **Mentoring**: Mentor other Scrum Masters on quality practices
|
||||
|
||||
### Quality Standards Evolution
|
||||
|
||||
#### Standards Review Process
|
||||
1. **Regular Assessment**: Regularly assess effectiveness of current quality standards
|
||||
2. **Industry Benchmarking**: Benchmark standards against industry best practices
|
||||
3. **Team Input**: Gather team input on standards effectiveness and usability
|
||||
4. **Stakeholder Feedback**: Collect stakeholder feedback on quality outcomes
|
||||
5. **Continuous Refinement**: Continuously refine standards based on experience
|
||||
|
||||
#### Standards Update Process
|
||||
1. **Change Proposal**: Formal process for proposing quality standards changes
|
||||
2. **Impact Assessment**: Assessment of proposed changes on team and processes
|
||||
3. **Stakeholder Review**: Review of proposed changes with key stakeholders
|
||||
4. **Implementation Planning**: Planning for implementing standards changes
|
||||
5. **Effectiveness Monitoring**: Monitoring effectiveness of standards changes
|
||||
|
||||
---
|
||||
|
||||
These quality standards provide a comprehensive framework for ensuring excellence in all Scrum Master activities within the BMAD Method. By adhering to these standards, Scrum Masters can drive team performance, process improvement, and successful project outcomes.
|
||||
|
|
@ -0,0 +1,686 @@
|
|||
# Scrum Master (Mike) Success Metrics
|
||||
|
||||
## Overview
|
||||
|
||||
This document establishes a comprehensive framework for measuring Scrum Master effectiveness within the BMAD Method. These metrics provide objective criteria for evaluating performance, identifying improvement opportunities, and demonstrating the value of the Scrum Master role.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Metrics Framework](#metrics-framework)
|
||||
2. [Team Performance Metrics](#team-performance-metrics)
|
||||
3. [Process Effectiveness Metrics](#process-effectiveness-metrics)
|
||||
4. [Coaching Effectiveness Metrics](#coaching-effectiveness-metrics)
|
||||
5. [Impediment Management Metrics](#impediment-management-metrics)
|
||||
6. [Stakeholder Satisfaction Metrics](#stakeholder-satisfaction-metrics)
|
||||
7. [Continuous Improvement Metrics](#continuous-improvement-metrics)
|
||||
8. [Measurement Methodologies](#measurement-methodologies)
|
||||
9. [Metrics Visualization and Reporting](#metrics-visualization-and-reporting)
|
||||
10. [Metrics-Driven Improvement](#metrics-driven-improvement)
|
||||
|
||||
## Metrics Framework
|
||||
|
||||
### Metrics Categories
|
||||
|
||||
```mermaid title="Scrum Master Metrics Framework" type="diagram"
|
||||
graph TD
|
||||
A["Scrum Master Success Metrics"] --> B["Team Performance Metrics"]
|
||||
A --> C["Process Effectiveness Metrics"]
|
||||
A --> D["Coaching Effectiveness Metrics"]
|
||||
A --> E["Impediment Management Metrics"]
|
||||
A --> F["Stakeholder Satisfaction Metrics"]
|
||||
A --> G["Continuous Improvement Metrics"]
|
||||
|
||||
B --> B1["Velocity and Predictability"]
|
||||
B --> B2["Quality Metrics"]
|
||||
B --> B3["Team Health Indicators"]
|
||||
|
||||
C --> C1["Ceremony Effectiveness"]
|
||||
C --> C2["Framework Adherence"]
|
||||
C --> C3["Process Efficiency"]
|
||||
|
||||
D --> D1["Team Maturity Growth"]
|
||||
D --> D2["Skill Development"]
|
||||
D --> D3["Self-Organization Level"]
|
||||
|
||||
E --> E1["Resolution Efficiency"]
|
||||
E --> E2["Prevention Effectiveness"]
|
||||
E --> E3["Impact Reduction"]
|
||||
|
||||
F --> F1["Team Satisfaction"]
|
||||
F --> F2["Product Owner Satisfaction"]
|
||||
F --> F3["Stakeholder Feedback"]
|
||||
|
||||
G --> G1["Improvement Implementation"]
|
||||
G --> G2["Experimentation Rate"]
|
||||
G --> G3["Learning Integration"]
|
||||
```
|
||||
|
||||
### Metrics Principles
|
||||
|
||||
1. **Outcome Focus**: Metrics focus on outcomes rather than activities
|
||||
2. **Balanced Perspective**: Combination of quantitative and qualitative metrics
|
||||
3. **Team Empowerment**: Metrics support team self-improvement, not control
|
||||
4. **Continuous Learning**: Metrics drive learning and adaptation
|
||||
5. **Simplicity**: Metrics are easy to understand and collect
|
||||
6. **Actionability**: Metrics lead to specific improvement actions
|
||||
|
||||
### Metrics Usage Guidelines
|
||||
|
||||
#### Appropriate Use
|
||||
- **Improvement Orientation**: Use metrics to identify improvement opportunities
|
||||
- **Trend Analysis**: Focus on trends rather than absolute values
|
||||
- **Context Consideration**: Interpret metrics within team and project context
|
||||
- **Holistic View**: Consider multiple metrics together, not in isolation
|
||||
|
||||
#### Inappropriate Use
|
||||
- **Individual Performance**: Do not use for individual performance evaluation
|
||||
- **Team Comparison**: Avoid direct comparison between different teams
|
||||
- **Rigid Targets**: Do not set rigid targets without team involvement
|
||||
- **Punitive Measures**: Never use metrics for punitive purposes
|
||||
|
||||
## Team Performance Metrics
|
||||
|
||||
### Velocity and Predictability Metrics
|
||||
|
||||
#### Velocity Stability
|
||||
- **Definition**: Consistency of team velocity over time
|
||||
- **Calculation**: Standard deviation of velocity over last 5 sprints
|
||||
- **Target Range**: Standard deviation < 20% of average velocity
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Decreasing trend in standard deviation
|
||||
|
||||
#### Commitment Reliability
|
||||
- **Definition**: Accuracy of sprint commitments vs. actual delivery
|
||||
- **Calculation**: (Completed story points / Committed story points) × 100%
|
||||
- **Target Range**: 80-100%
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Consistent achievement of 90%+ reliability
|
||||
|
||||
#### Forecast Accuracy
|
||||
- **Definition**: Accuracy of release forecasts based on velocity
|
||||
- **Calculation**: (Actual delivery date - Forecast date) in sprints
|
||||
- **Target Range**: ±1 sprint
|
||||
- **Measurement Frequency**: Each release
|
||||
- **Improvement Goal**: Consistent achievement of ±1 sprint accuracy
|
||||
|
||||
### Quality Metrics
|
||||
|
||||
#### Defect Density
|
||||
- **Definition**: Number of defects per story point delivered
|
||||
- **Calculation**: Total defects / Total story points delivered
|
||||
- **Target Range**: < 0.5 defects per story point
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Decreasing trend in defect density
|
||||
|
||||
#### Technical Debt Ratio
|
||||
- **Definition**: Proportion of effort dedicated to technical debt reduction
|
||||
- **Calculation**: (Technical debt story points / Total story points) × 100%
|
||||
- **Target Range**: 10-20%
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Sustainable technical debt ratio within target range
|
||||
|
||||
#### Definition of Done Compliance
|
||||
- **Definition**: Adherence to team's Definition of Done
|
||||
- **Calculation**: (Stories fully meeting DoD / Total completed stories) × 100%
|
||||
- **Target Range**: 95-100%
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Consistent 100% compliance
|
||||
|
||||
### Team Health Indicators
|
||||
|
||||
#### Team Morale
|
||||
- **Definition**: Team's overall satisfaction and engagement
|
||||
- **Calculation**: Average score from team health survey (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Stable or improving trend above 4.0
|
||||
|
||||
#### Collaboration Quality
|
||||
- **Definition**: Effectiveness of team collaboration
|
||||
- **Calculation**: Peer assessment of collaboration quality (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Improvement Goal**: Consistent improvement toward 5.0
|
||||
|
||||
#### Team Stability
|
||||
- **Definition**: Consistency of team membership
|
||||
- **Calculation**: (1 - (Team member changes / Total team size)) × 100%
|
||||
- **Target Range**: 80-100%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Maintain stability above 85%
|
||||
|
||||
## Process Effectiveness Metrics
|
||||
|
||||
### Ceremony Effectiveness Metrics
|
||||
|
||||
#### Sprint Planning Effectiveness
|
||||
- **Definition**: Effectiveness of sprint planning sessions
|
||||
- **Calculation**: Average score from planning effectiveness survey (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Consistent achievement of 4.5+
|
||||
|
||||
#### Daily Scrum Efficiency
|
||||
- **Definition**: Efficiency and effectiveness of daily scrums
|
||||
- **Calculation**: Composite score based on:
|
||||
- Duration compliance (% within 15 minutes)
|
||||
- Impediment identification rate
|
||||
- Team satisfaction survey (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Weekly
|
||||
- **Improvement Goal**: Consistent achievement of 4.5+
|
||||
|
||||
#### Retrospective Action Completion
|
||||
- **Definition**: Implementation rate of retrospective action items
|
||||
- **Calculation**: (Completed action items / Total action items) × 100%
|
||||
- **Target Range**: 80-100%
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Consistent achievement of 90%+
|
||||
|
||||
### Framework Adherence Metrics
|
||||
|
||||
#### Scrum Practice Adoption
|
||||
- **Definition**: Team's adoption of core Scrum practices
|
||||
- **Calculation**: Assessment score based on Scrum practice checklist (%)
|
||||
- **Target Range**: 80-100%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Consistent achievement of 90%+
|
||||
|
||||
#### Agile Principle Alignment
|
||||
- **Definition**: Team's alignment with agile principles
|
||||
- **Calculation**: Assessment score based on agile principles checklist (%)
|
||||
- **Target Range**: 80-100%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Consistent achievement of 90%+
|
||||
|
||||
#### Process Adaptation Effectiveness
|
||||
- **Definition**: Effectiveness of process adaptations
|
||||
- **Calculation**: Success rate of process experiments (%)
|
||||
- **Target Range**: 60-80%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Increasing trend in success rate
|
||||
|
||||
### Process Efficiency Metrics
|
||||
|
||||
#### Cycle Time
|
||||
- **Definition**: Average time from story start to completion
|
||||
- **Calculation**: Average (Completion date - Start date) for all stories
|
||||
- **Target Range**: Depends on story size, typically 1-5 days
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Decreasing trend in cycle time
|
||||
|
||||
#### Flow Efficiency
|
||||
- **Definition**: Proportion of time stories are actively worked on
|
||||
- **Calculation**: (Active work time / Total cycle time) × 100%
|
||||
- **Target Range**: 40-70%
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Increasing trend in flow efficiency
|
||||
|
||||
#### Work Item Age
|
||||
- **Definition**: Average age of in-progress work items
|
||||
- **Calculation**: Average (Current date - Start date) for in-progress items
|
||||
- **Target Range**: < 5 days
|
||||
- **Measurement Frequency**: Weekly
|
||||
- **Improvement Goal**: Decreasing trend in work item age
|
||||
|
||||
## Coaching Effectiveness Metrics
|
||||
|
||||
### Team Maturity Growth Metrics
|
||||
|
||||
#### Agile Maturity Level
|
||||
- **Definition**: Team's overall agile maturity level
|
||||
- **Calculation**: Assessment score based on agile maturity model (1-5 scale)
|
||||
- **Target Range**: Increasing trend
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Advancement through maturity levels
|
||||
|
||||
#### Self-Organization Index
|
||||
- **Definition**: Team's level of self-organization
|
||||
- **Calculation**: Assessment score based on self-organization criteria (1-5 scale)
|
||||
- **Target Range**: 3.0-5.0
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Consistent improvement toward 5.0
|
||||
|
||||
#### Decision-Making Autonomy
|
||||
- **Definition**: Team's autonomy in decision-making
|
||||
- **Calculation**: (Decisions made by team / Total decisions) × 100%
|
||||
- **Target Range**: 80-95%
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Improvement Goal**: Increasing trend toward 95%
|
||||
|
||||
### Skill Development Metrics
|
||||
|
||||
#### Technical Skill Growth
|
||||
- **Definition**: Improvement in team's technical skills
|
||||
- **Calculation**: Assessment of skill growth based on defined competencies (%)
|
||||
- **Target Range**: 10-20% growth annually
|
||||
- **Measurement Frequency**: Semi-annually
|
||||
- **Improvement Goal**: Consistent skill growth across team
|
||||
|
||||
#### Agile Practice Proficiency
|
||||
- **Definition**: Team's proficiency in agile practices
|
||||
- **Calculation**: Assessment score based on practice proficiency matrix (%)
|
||||
- **Target Range**: 70-100%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Increasing trend toward 100%
|
||||
|
||||
#### Cross-Functional Capability
|
||||
- **Definition**: Team's cross-functional capability
|
||||
- **Calculation**: (Skills covered by multiple team members / Total required skills) × 100%
|
||||
- **Target Range**: 70-90%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Increasing trend toward 90%
|
||||
|
||||
### Coaching Impact Metrics
|
||||
|
||||
#### Coaching Session Effectiveness
|
||||
- **Definition**: Perceived effectiveness of coaching sessions
|
||||
- **Calculation**: Average feedback score from coaching recipients (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: After each formal coaching session
|
||||
- **Improvement Goal**: Consistent achievement of 4.5+
|
||||
|
||||
#### Behavior Change Adoption
|
||||
- **Definition**: Adoption rate of behaviors introduced through coaching
|
||||
- **Calculation**: (Observed instances of new behavior / Opportunities for new behavior) × 100%
|
||||
- **Target Range**: 60-80%
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Improvement Goal**: Increasing trend toward 80%
|
||||
|
||||
#### Coaching Request Rate
|
||||
- **Definition**: Frequency of proactive coaching requests from team
|
||||
- **Calculation**: Number of coaching requests per sprint
|
||||
- **Target Range**: Increasing trend
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Consistent or increasing request rate
|
||||
|
||||
## Impediment Management Metrics
|
||||
|
||||
### Resolution Efficiency Metrics
|
||||
|
||||
#### Impediment Resolution Time
|
||||
- **Definition**: Average time to resolve impediments
|
||||
- **Calculation**: Average (Resolution date - Identification date) for all impediments
|
||||
- **Target Range**: < 3 days
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Decreasing trend in resolution time
|
||||
|
||||
#### Resolution Success Rate
|
||||
- **Definition**: Proportion of impediments successfully resolved
|
||||
- **Calculation**: (Successfully resolved impediments / Total impediments) × 100%
|
||||
- **Target Range**: 90-100%
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Consistent achievement of 95%+
|
||||
|
||||
#### First-Time Resolution Rate
|
||||
- **Definition**: Proportion of impediments resolved without recurrence
|
||||
- **Calculation**: (Impediments resolved without recurrence / Total resolved impediments) × 100%
|
||||
- **Target Range**: 80-95%
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Improvement Goal**: Increasing trend toward 95%
|
||||
|
||||
### Prevention Effectiveness Metrics
|
||||
|
||||
#### Impediment Recurrence Rate
|
||||
- **Definition**: Frequency of recurring impediment types
|
||||
- **Calculation**: (Recurring impediment types / Total impediment types) × 100%
|
||||
- **Target Range**: < 20%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Decreasing trend toward 0%
|
||||
|
||||
#### Proactive Identification Rate
|
||||
- **Definition**: Proportion of impediments identified proactively
|
||||
- **Calculation**: (Proactively identified impediments / Total impediments) × 100%
|
||||
- **Target Range**: 40-60%
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Increasing trend toward 60%
|
||||
|
||||
#### Preventive Measure Effectiveness
|
||||
- **Definition**: Effectiveness of implemented preventive measures
|
||||
- **Calculation**: (Prevented impediments / Total potential impediments) × 100%
|
||||
- **Target Range**: 70-90%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Increasing trend toward 90%
|
||||
|
||||
### Impact Reduction Metrics
|
||||
|
||||
#### Impediment Impact Severity
|
||||
- **Definition**: Average severity of impediment impact on team
|
||||
- **Calculation**: Average impact rating of impediments (1-5 scale)
|
||||
- **Target Range**: < 3.0
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Decreasing trend toward 1.0
|
||||
|
||||
#### Blocked Time Ratio
|
||||
- **Definition**: Proportion of time stories are blocked by impediments
|
||||
- **Calculation**: (Total blocked time / Total cycle time) × 100%
|
||||
- **Target Range**: < 20%
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Decreasing trend toward 10%
|
||||
|
||||
#### Escalation Effectiveness
|
||||
- **Definition**: Effectiveness of impediment escalation process
|
||||
- **Calculation**: (Successfully resolved escalated impediments / Total escalated impediments) × 100%
|
||||
- **Target Range**: 80-100%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Consistent achievement of 90%+
|
||||
|
||||
## Stakeholder Satisfaction Metrics
|
||||
|
||||
### Team Satisfaction Metrics
|
||||
|
||||
#### Team Satisfaction with Scrum Master
|
||||
- **Definition**: Team's satisfaction with Scrum Master support
|
||||
- **Calculation**: Average score from team satisfaction survey (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Improvement Goal**: Consistent achievement of 4.5+
|
||||
|
||||
#### Team Support Effectiveness
|
||||
- **Definition**: Perceived effectiveness of Scrum Master support
|
||||
- **Calculation**: Average score from support effectiveness survey (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Improvement Goal**: Consistent achievement of 4.5+
|
||||
|
||||
#### Team Enablement Index
|
||||
- **Definition**: Extent to which team feels enabled by Scrum Master
|
||||
- **Calculation**: Composite score based on enablement factors (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Consistent achievement of 4.5+
|
||||
|
||||
### Product Owner Satisfaction Metrics
|
||||
|
||||
#### Product Owner Satisfaction
|
||||
- **Definition**: Product Owner's satisfaction with Scrum Master support
|
||||
- **Calculation**: Score from Product Owner satisfaction survey (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Improvement Goal**: Consistent achievement of 4.5+
|
||||
|
||||
#### Collaboration Effectiveness
|
||||
- **Definition**: Effectiveness of Scrum Master-Product Owner collaboration
|
||||
- **Calculation**: Score from collaboration effectiveness assessment (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Monthly
|
||||
- **Improvement Goal**: Consistent achievement of 4.5+
|
||||
|
||||
#### Value Delivery Support
|
||||
- **Definition**: Effectiveness of Scrum Master support for value delivery
|
||||
- **Calculation**: Score from value delivery support assessment (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Consistent achievement of 4.5+
|
||||
|
||||
### Stakeholder Feedback Metrics
|
||||
|
||||
#### Stakeholder Communication Effectiveness
|
||||
- **Definition**: Effectiveness of Scrum Master communication with stakeholders
|
||||
- **Calculation**: Average score from stakeholder communication survey (1-5 scale)
|
||||
- **Target Range**: 4.0-5.0
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Consistent achievement of 4.5+
|
||||
|
||||
#### Stakeholder Expectation Management
|
||||
- **Definition**: Effectiveness of stakeholder expectation management
|
||||
- **Calculation**: (Stakeholders with aligned expectations / Total stakeholders) × 100%
|
||||
- **Target Range**: 80-100%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Consistent achievement of 90%+
|
||||
|
||||
#### Organizational Impact
|
||||
- **Definition**: Perceived impact of Scrum Master on organizational agility
|
||||
- **Calculation**: Score from organizational impact assessment (1-5 scale)
|
||||
- **Target Range**: 3.5-5.0
|
||||
- **Measurement Frequency**: Semi-annually
|
||||
- **Improvement Goal**: Increasing trend toward 5.0
|
||||
|
||||
## Continuous Improvement Metrics
|
||||
|
||||
### Improvement Implementation Metrics
|
||||
|
||||
#### Retrospective Action Implementation Rate
|
||||
- **Definition**: Rate of implementing retrospective action items
|
||||
- **Calculation**: (Implemented action items / Total action items) × 100%
|
||||
- **Target Range**: 80-100%
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Consistent achievement of 90%+
|
||||
|
||||
#### Improvement Impact
|
||||
- **Definition**: Impact of implemented improvements
|
||||
- **Calculation**: Average impact rating of improvements (1-5 scale)
|
||||
- **Target Range**: 3.5-5.0
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Increasing trend toward 5.0
|
||||
|
||||
#### Continuous Improvement Velocity
|
||||
- **Definition**: Rate of implementing improvements over time
|
||||
- **Calculation**: Number of improvements implemented per quarter
|
||||
- **Target Range**: Depends on team size and maturity
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Consistent or increasing trend
|
||||
|
||||
### Experimentation Metrics
|
||||
|
||||
#### Experimentation Rate
|
||||
- **Definition**: Frequency of process experiments
|
||||
- **Calculation**: Number of process experiments per quarter
|
||||
- **Target Range**: 2-5 experiments per quarter
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Consistent experimentation rate
|
||||
|
||||
#### Experiment Success Rate
|
||||
- **Definition**: Success rate of process experiments
|
||||
- **Calculation**: (Successful experiments / Total experiments) × 100%
|
||||
- **Target Range**: 60-80%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Increasing trend toward 80%
|
||||
|
||||
#### Learning Integration Rate
|
||||
- **Definition**: Rate of integrating learnings from experiments
|
||||
- **Calculation**: (Integrated learnings / Total learnings) × 100%
|
||||
- **Target Range**: 70-90%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Increasing trend toward 90%
|
||||
|
||||
### Learning Culture Metrics
|
||||
|
||||
#### Knowledge Sharing Frequency
|
||||
- **Definition**: Frequency of knowledge sharing activities
|
||||
- **Calculation**: Number of knowledge sharing activities per sprint
|
||||
- **Target Range**: 2-5 activities per sprint
|
||||
- **Measurement Frequency**: Every sprint
|
||||
- **Improvement Goal**: Consistent or increasing frequency
|
||||
|
||||
#### Learning Opportunity Utilization
|
||||
- **Definition**: Utilization of learning opportunities
|
||||
- **Calculation**: (Utilized learning opportunities / Available opportunities) × 100%
|
||||
- **Target Range**: 70-90%
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Increasing trend toward 90%
|
||||
|
||||
#### Continuous Learning Index
|
||||
- **Definition**: Team's commitment to continuous learning
|
||||
- **Calculation**: Composite score based on learning behaviors (1-5 scale)
|
||||
- **Target Range**: 3.5-5.0
|
||||
- **Measurement Frequency**: Quarterly
|
||||
- **Improvement Goal**: Increasing trend toward 5.0
|
||||
|
||||
## Measurement Methodologies
|
||||
|
||||
### Quantitative Measurement Methods
|
||||
|
||||
#### Metrics Collection Process
|
||||
1. **Define Metrics**: Clearly define each metric and its calculation method
|
||||
2. **Establish Baseline**: Collect initial data to establish baseline
|
||||
3. **Set Targets**: Set realistic targets based on baseline and context
|
||||
4. **Regular Collection**: Implement regular data collection process
|
||||
5. **Validation**: Validate data accuracy and consistency
|
||||
6. **Analysis**: Analyze data to identify trends and patterns
|
||||
7. **Reporting**: Report metrics in accessible, actionable format
|
||||
|
||||
#### Data Sources
|
||||
- **Project Management Tools**: Sprint data, velocity, cycle time
|
||||
- **Issue Tracking Systems**: Impediments, defects, resolution times
|
||||
- **Version Control Systems**: Code quality, technical debt indicators
|
||||
- **Continuous Integration Tools**: Build and test metrics
|
||||
- **Team Surveys**: Satisfaction, health, and feedback data
|
||||
- **Observation Records**: Meeting effectiveness, participation data
|
||||
|
||||
### Qualitative Measurement Methods
|
||||
|
||||
#### Survey Methodologies
|
||||
1. **Survey Design**: Create focused, unbiased survey questions
|
||||
2. **Response Scales**: Use consistent 5-point Likert scales
|
||||
3. **Anonymity**: Ensure anonymity for honest feedback
|
||||
4. **Frequency**: Balance data needs with survey fatigue
|
||||
5. **Analysis**: Combine quantitative scores with qualitative comments
|
||||
6. **Trends**: Focus on trends rather than absolute values
|
||||
7. **Action Planning**: Use results for specific improvement actions
|
||||
|
||||
#### Observation Techniques
|
||||
1. **Structured Observation**: Use consistent observation frameworks
|
||||
2. **Behavior Tracking**: Track specific behaviors and patterns
|
||||
3. **Facilitation Assessment**: Assess meeting facilitation effectiveness
|
||||
4. **Interaction Analysis**: Analyze team interactions and dynamics
|
||||
5. **Documentation**: Document observations systematically
|
||||
6. **Feedback**: Provide constructive feedback based on observations
|
||||
7. **Pattern Recognition**: Identify recurring patterns and trends
|
||||
|
||||
### Assessment Frameworks
|
||||
|
||||
#### Team Maturity Assessment
|
||||
1. **Maturity Model**: Define clear agile maturity model with levels
|
||||
2. **Assessment Criteria**: Establish specific criteria for each level
|
||||
3. **Evidence Collection**: Collect evidence for each criterion
|
||||
4. **Collaborative Assessment**: Involve team in self-assessment
|
||||
5. **External Validation**: Include external perspective when possible
|
||||
6. **Growth Planning**: Use results to plan specific growth actions
|
||||
7. **Progress Tracking**: Track progress through maturity levels
|
||||
|
||||
#### Process Effectiveness Assessment
|
||||
1. **Process Mapping**: Map current processes and identify key points
|
||||
2. **Effectiveness Criteria**: Define criteria for process effectiveness
|
||||
3. **Data Collection**: Collect data on process performance
|
||||
4. **Bottleneck Analysis**: Identify process bottlenecks and constraints
|
||||
5. **Waste Identification**: Identify process waste and inefficiencies
|
||||
6. **Improvement Planning**: Plan specific process improvements
|
||||
7. **Effectiveness Monitoring**: Monitor improvement effectiveness
|
||||
|
||||
## Metrics Visualization and Reporting
|
||||
|
||||
### Visualization Techniques
|
||||
|
||||
#### Dashboard Design
|
||||
1. **Audience Focus**: Design dashboards for specific audiences
|
||||
2. **Visual Clarity**: Use clear, intuitive visualizations
|
||||
3. **Context Inclusion**: Include relevant context with metrics
|
||||
4. **Trend Emphasis**: Emphasize trends over point-in-time values
|
||||
5. **Threshold Indicators**: Include visual indicators for thresholds
|
||||
6. **Drill-Down Capability**: Allow drill-down for deeper analysis
|
||||
7. **Actionability**: Design dashboards to drive action
|
||||
|
||||
#### Chart Selection Guide
|
||||
- **Trend Data**: Line charts for showing trends over time
|
||||
- **Comparisons**: Bar charts for comparing values across categories
|
||||
- **Distributions**: Histograms or box plots for showing distributions
|
||||
- **Relationships**: Scatter plots for showing relationships between metrics
|
||||
- **Proportions**: Pie or donut charts for showing proportions
|
||||
- **Status**: Gauges or traffic lights for showing status against targets
|
||||
- **Flow**: Sankey diagrams for showing process flows
|
||||
|
||||
### Reporting Frameworks
|
||||
|
||||
#### Sprint Metrics Report
|
||||
- **Audience**: Team, Product Owner
|
||||
- **Frequency**: Every sprint
|
||||
- **Content**:
|
||||
- Sprint goal achievement
|
||||
- Velocity and commitment reliability
|
||||
- Quality metrics
|
||||
- Impediment summary
|
||||
- Retrospective action status
|
||||
- **Format**: Visual dashboard with minimal text
|
||||
|
||||
#### Team Health Report
|
||||
- **Audience**: Team, Product Owner, Management
|
||||
- **Frequency**: Monthly
|
||||
- **Content**:
|
||||
- Team health indicators
|
||||
- Collaboration metrics
|
||||
- Process effectiveness
|
||||
- Improvement trends
|
||||
- Risk indicators
|
||||
- **Format**: Visual dashboard with summary analysis
|
||||
|
||||
#### Scrum Master Effectiveness Report
|
||||
- **Audience**: Scrum Master, Management
|
||||
- **Frequency**: Quarterly
|
||||
- **Content**:
|
||||
- Stakeholder satisfaction metrics
|
||||
- Coaching effectiveness
|
||||
- Impediment management performance
|
||||
- Continuous improvement metrics
|
||||
- Growth opportunities
|
||||
- **Format**: Comprehensive report with analysis and recommendations
|
||||
|
||||
## Metrics-Driven Improvement
|
||||
|
||||
### Improvement Process
|
||||
|
||||
```mermaid title="Metrics-Driven Improvement Process" type="diagram"
|
||||
graph TD
|
||||
A["Collect Metrics Data"] --> B["Analyze Trends and Patterns"]
|
||||
B --> C["Identify Improvement Opportunities"]
|
||||
C --> D["Prioritize Improvements"]
|
||||
D --> E["Plan Improvement Actions"]
|
||||
E --> F["Implement Improvements"]
|
||||
F --> G["Measure Impact"]
|
||||
G --> H["Adjust Approach"]
|
||||
H --> A
|
||||
```
|
||||
|
||||
### Metrics Analysis Techniques
|
||||
|
||||
#### Trend Analysis
|
||||
1. **Data Collection**: Collect consistent data over time
|
||||
2. **Visualization**: Plot data on time-series charts
|
||||
3. **Pattern Identification**: Identify patterns and trends
|
||||
4. **Anomaly Detection**: Identify and investigate anomalies
|
||||
5. **Correlation Analysis**: Identify correlations between metrics
|
||||
6. **Forecasting**: Use trends to forecast future performance
|
||||
7. **Action Planning**: Develop actions based on trend analysis
|
||||
|
||||
#### Root Cause Analysis
|
||||
1. **Problem Definition**: Clearly define the metric-indicated problem
|
||||
2. **Data Gathering**: Gather relevant data and context
|
||||
3. **Cause Identification**: Identify potential causes
|
||||
4. **Cause Verification**: Verify actual causes with data
|
||||
5. **Root Cause Determination**: Determine underlying root causes
|
||||
6. **Solution Development**: Develop solutions addressing root causes
|
||||
7. **Implementation Planning**: Plan solution implementation
|
||||
|
||||
### Continuous Improvement Integration
|
||||
|
||||
#### Team-Level Integration
|
||||
1. **Metrics Review**: Regular team review of key metrics
|
||||
2. **Collaborative Analysis**: Team analysis of metrics and trends
|
||||
3. **Improvement Identification**: Team identification of improvement opportunities
|
||||
4. **Action Planning**: Team development of improvement actions
|
||||
5. **Implementation Ownership**: Team ownership of implementation
|
||||
6. **Impact Assessment**: Team assessment of improvement impact
|
||||
7. **Learning Integration**: Integration of learnings into team practices
|
||||
|
||||
#### Organizational Integration
|
||||
1. **Cross-Team Sharing**: Sharing of metrics and learnings across teams
|
||||
2. **Pattern Recognition**: Identification of organization-wide patterns
|
||||
3. **Best Practice Sharing**: Sharing of effective improvement approaches
|
||||
4. **Systemic Improvement**: Address systemic issues affecting multiple teams
|
||||
5. **Organizational Learning**: Integration of learnings into organizational practices
|
||||
6. **Standard Evolution**: Evolution of organizational standards based on metrics
|
||||
7. **Continuous Adaptation**: Continuous adaptation of metrics framework
|
||||
|
||||
---
|
||||
|
||||
This comprehensive metrics framework provides Scrum Masters with the tools to measure their effectiveness, identify improvement opportunities, and demonstrate their value within the BMAD Method. By consistently tracking these metrics and using them to drive improvement, Scrum Masters can enhance team performance, process effectiveness, and overall project success.
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,769 @@
|
|||
# Scrum Master (Mike) Workflow Mapping
|
||||
|
||||
## Overview
|
||||
|
||||
This document maps the comprehensive workflows for Scrum Masters within the BMAD Method. It provides detailed process flows, decision points, and integration touchpoints to ensure effective Scrum facilitation and team support.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Core Scrum Master Workflows](#core-scrum-master-workflows)
|
||||
2. [Sprint Ceremony Workflows](#sprint-ceremony-workflows)
|
||||
3. [Team Coaching Workflows](#team-coaching-workflows)
|
||||
4. [Impediment Management Workflows](#impediment-management-workflows)
|
||||
5. [Process Improvement Workflows](#process-improvement-workflows)
|
||||
6. [Stakeholder Management Workflows](#stakeholder-management-workflows)
|
||||
7. [Integration Workflows](#integration-workflows)
|
||||
8. [Decision Trees and Escalation Procedures](#decision-trees-and-escalation-procedures)
|
||||
9. [Workflow Customization Guidelines](#workflow-customization-guidelines)
|
||||
|
||||
## Core Scrum Master Workflows
|
||||
|
||||
### Daily Scrum Master Workflow
|
||||
|
||||
```mermaid title="Daily Scrum Master Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Start Day"] --> B["Review Team Status"]
|
||||
B --> C["Check Impediment Log"]
|
||||
C --> D["Prepare for Daily Scrum"]
|
||||
D --> E["Facilitate Daily Scrum"]
|
||||
E --> F["Update Sprint Tracking"]
|
||||
F --> G["Follow Up on Impediments"]
|
||||
G --> H["Support Team Members"]
|
||||
H --> I["Stakeholder Communication"]
|
||||
I --> J["Process Improvement Activities"]
|
||||
J --> K["End Day"]
|
||||
|
||||
subgraph "Morning Activities"
|
||||
B
|
||||
C
|
||||
D
|
||||
E
|
||||
F
|
||||
end
|
||||
|
||||
subgraph "Afternoon Activities"
|
||||
G
|
||||
H
|
||||
I
|
||||
J
|
||||
end
|
||||
```
|
||||
|
||||
### Weekly Scrum Master Workflow
|
||||
|
||||
```mermaid title="Weekly Scrum Master Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Start Week"] --> B["Review Sprint Progress"]
|
||||
B --> C["Update Sprint Metrics"]
|
||||
C --> D["Prepare Weekly Stakeholder Update"]
|
||||
D --> E["Conduct Team Health Check"]
|
||||
E --> F["Facilitate Weekly Ceremonies"]
|
||||
F --> G["Process Improvement Activities"]
|
||||
G --> H["End Week"]
|
||||
|
||||
F --> F1["Sprint Planning (Start of Sprint)"]
|
||||
F --> F2["Backlog Refinement (Mid-Sprint)"]
|
||||
F --> F3["Sprint Review (End of Sprint)"]
|
||||
F --> F4["Sprint Retrospective (End of Sprint)"]
|
||||
|
||||
subgraph "Weekly Ceremonies"
|
||||
F1
|
||||
F2
|
||||
F3
|
||||
F4
|
||||
end
|
||||
```
|
||||
|
||||
### Sprint Cycle Workflow
|
||||
|
||||
```mermaid title="Sprint Cycle Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Sprint Start"] --> B["Facilitate Sprint Planning"]
|
||||
B --> C["Set Up Sprint Dashboard"]
|
||||
C --> D["Daily Sprint Activities"]
|
||||
D --> E["Mid-Sprint Check"]
|
||||
E --> F["Backlog Refinement"]
|
||||
F --> G["Sprint End Preparation"]
|
||||
G --> H["Facilitate Sprint Review"]
|
||||
H --> I["Facilitate Sprint Retrospective"]
|
||||
I --> J["Sprint Closure Activities"]
|
||||
J --> K["Sprint Start"]
|
||||
|
||||
D --> D1["Daily Scrum Facilitation"]
|
||||
D --> D2["Impediment Resolution"]
|
||||
D --> D3["Team Support"]
|
||||
D --> D4["Stakeholder Communication"]
|
||||
|
||||
subgraph "Daily Activities"
|
||||
D1
|
||||
D2
|
||||
D3
|
||||
D4
|
||||
end
|
||||
```
|
||||
|
||||
## Sprint Ceremony Workflows
|
||||
|
||||
### Sprint Planning Workflow
|
||||
|
||||
```mermaid title="Sprint Planning Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Pre-Planning Preparation"] --> B["Verify Product Backlog Readiness"]
|
||||
B --> C["Calculate Team Capacity"]
|
||||
C --> D["Prepare Planning Materials"]
|
||||
D --> E["Set Up Planning Environment"]
|
||||
E --> F["Facilitate Sprint Planning Part 1"]
|
||||
F --> G["Sprint Goal Definition"]
|
||||
G --> H["Backlog Item Selection"]
|
||||
H --> I["Facilitate Sprint Planning Part 2"]
|
||||
I --> J["Task Breakdown"]
|
||||
J --> K["Sprint Commitment"]
|
||||
K --> L["Document Sprint Backlog"]
|
||||
L --> M["Communicate Sprint Plan"]
|
||||
M --> N["Post-Planning Activities"]
|
||||
|
||||
subgraph "Pre-Planning"
|
||||
A
|
||||
B
|
||||
C
|
||||
D
|
||||
E
|
||||
end
|
||||
|
||||
subgraph "Part 1: What"
|
||||
F
|
||||
G
|
||||
H
|
||||
end
|
||||
|
||||
subgraph "Part 2: How"
|
||||
I
|
||||
J
|
||||
K
|
||||
end
|
||||
|
||||
subgraph "Post-Planning"
|
||||
L
|
||||
M
|
||||
N
|
||||
end
|
||||
```
|
||||
|
||||
### Daily Scrum Workflow
|
||||
|
||||
```mermaid title="Daily Scrum Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Pre-Scrum Preparation"] --> B["Review Sprint Progress"]
|
||||
B --> C["Check Impediment Status"]
|
||||
C --> D["Prepare Focus Points"]
|
||||
D --> E["Start Daily Scrum"]
|
||||
E --> F["Team Member Updates"]
|
||||
F --> G["Identify New Impediments"]
|
||||
G --> H["Coordinate Follow-up Discussions"]
|
||||
H --> I["Close Daily Scrum"]
|
||||
I --> J["Document Impediments"]
|
||||
J --> K["Update Sprint Status"]
|
||||
K --> L["Facilitate Follow-up Discussions"]
|
||||
L --> M["Communicate Critical Updates"]
|
||||
|
||||
subgraph "Pre-Scrum"
|
||||
A
|
||||
B
|
||||
C
|
||||
D
|
||||
end
|
||||
|
||||
subgraph "During Scrum"
|
||||
E
|
||||
F
|
||||
G
|
||||
H
|
||||
I
|
||||
end
|
||||
|
||||
subgraph "Post-Scrum"
|
||||
J
|
||||
K
|
||||
L
|
||||
M
|
||||
end
|
||||
```
|
||||
|
||||
### Sprint Review Workflow
|
||||
|
||||
```mermaid title="Sprint Review Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Pre-Review Preparation"] --> B["Prepare Demo Environment"]
|
||||
B --> C["Compile Sprint Metrics"]
|
||||
C --> D["Coordinate with Product Owner"]
|
||||
D --> E["Prepare Demo Script"]
|
||||
E --> F["Invite Stakeholders"]
|
||||
F --> G["Facilitate Sprint Review"]
|
||||
G --> H["Sprint Goal Review"]
|
||||
H --> I["Demo Completed Work"]
|
||||
I --> J["Collect Feedback"]
|
||||
J --> K["Discuss Next Steps"]
|
||||
K --> L["Document Feedback"]
|
||||
L --> M["Update Product Backlog"]
|
||||
M --> N["Communicate Review Outcomes"]
|
||||
|
||||
subgraph "Pre-Review"
|
||||
A
|
||||
B
|
||||
C
|
||||
D
|
||||
E
|
||||
F
|
||||
end
|
||||
|
||||
subgraph "During Review"
|
||||
G
|
||||
H
|
||||
I
|
||||
J
|
||||
K
|
||||
end
|
||||
|
||||
subgraph "Post-Review"
|
||||
L
|
||||
M
|
||||
N
|
||||
end
|
||||
```
|
||||
|
||||
### Sprint Retrospective Workflow
|
||||
|
||||
```mermaid title="Sprint Retrospective Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Pre-Retrospective Preparation"] --> B["Select Retrospective Format"]
|
||||
B --> C["Gather Sprint Data"]
|
||||
C --> D["Prepare Retrospective Materials"]
|
||||
D --> E["Set Up Retrospective Environment"]
|
||||
E --> F["Facilitate Retrospective"]
|
||||
F --> G["Set the Stage"]
|
||||
G --> H["Gather Data"]
|
||||
H --> I["Generate Insights"]
|
||||
I --> J["Decide on Actions"]
|
||||
J --> K["Close Retrospective"]
|
||||
K --> L["Document Action Items"]
|
||||
L --> M["Track Action Implementation"]
|
||||
M --> N["Incorporate into Next Sprint"]
|
||||
|
||||
subgraph "Pre-Retrospective"
|
||||
A
|
||||
B
|
||||
C
|
||||
D
|
||||
E
|
||||
end
|
||||
|
||||
subgraph "During Retrospective"
|
||||
F
|
||||
G
|
||||
H
|
||||
I
|
||||
J
|
||||
K
|
||||
end
|
||||
|
||||
subgraph "Post-Retrospective"
|
||||
L
|
||||
M
|
||||
N
|
||||
end
|
||||
```
|
||||
|
||||
### Backlog Refinement Workflow
|
||||
|
||||
```mermaid title="Backlog Refinement Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Pre-Refinement Preparation"] --> B["Coordinate with Product Owner"]
|
||||
B --> C["Review Backlog Items"]
|
||||
C --> D["Prepare Refinement Materials"]
|
||||
D --> E["Facilitate Refinement Session"]
|
||||
E --> F["Clarify Requirements"]
|
||||
F --> G["Estimate Items"]
|
||||
G --> H["Identify Dependencies"]
|
||||
H --> I["Assess Readiness"]
|
||||
I --> J["Document Refinement Outcomes"]
|
||||
J --> K["Update Product Backlog"]
|
||||
K --> L["Plan Next Refinement"]
|
||||
|
||||
subgraph "Pre-Refinement"
|
||||
A
|
||||
B
|
||||
C
|
||||
D
|
||||
end
|
||||
|
||||
subgraph "During Refinement"
|
||||
E
|
||||
F
|
||||
G
|
||||
H
|
||||
I
|
||||
end
|
||||
|
||||
subgraph "Post-Refinement"
|
||||
J
|
||||
K
|
||||
L
|
||||
end
|
||||
```
|
||||
|
||||
## Team Coaching Workflows
|
||||
|
||||
### Team Development Workflow
|
||||
|
||||
```mermaid title="Team Development Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Assess Team Maturity"] --> B["Identify Development Areas"]
|
||||
B --> C["Create Development Plan"]
|
||||
C --> D["Implement Development Activities"]
|
||||
D --> E["Monitor Progress"]
|
||||
E --> F["Provide Feedback"]
|
||||
F --> G["Adjust Development Plan"]
|
||||
G --> H["Reassess Team Maturity"]
|
||||
|
||||
D --> D1["Skill Development"]
|
||||
D --> D2["Process Improvement"]
|
||||
D --> D3["Team Dynamics"]
|
||||
D --> D4["Self-Organization"]
|
||||
|
||||
subgraph "Development Activities"
|
||||
D1
|
||||
D2
|
||||
D3
|
||||
D4
|
||||
end
|
||||
```
|
||||
|
||||
### Individual Coaching Workflow
|
||||
|
||||
```mermaid title="Individual Coaching Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Identify Coaching Need"] --> B["Schedule Coaching Session"]
|
||||
B --> C["Prepare for Session"]
|
||||
C --> D["Conduct Coaching Session"]
|
||||
D --> E["Document Outcomes"]
|
||||
E --> F["Follow Up on Actions"]
|
||||
F --> G["Assess Progress"]
|
||||
G --> H["Determine Next Steps"]
|
||||
|
||||
D --> D1["Active Listening"]
|
||||
D --> D2["Powerful Questions"]
|
||||
D --> D3["Feedback Provision"]
|
||||
D --> D4["Action Planning"]
|
||||
|
||||
subgraph "Coaching Techniques"
|
||||
D1
|
||||
D2
|
||||
D3
|
||||
D4
|
||||
end
|
||||
```
|
||||
|
||||
### Conflict Resolution Workflow
|
||||
|
||||
```mermaid title="Conflict Resolution Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Identify Conflict"] --> B["Assess Conflict Severity"]
|
||||
B --> C["Determine Approach"]
|
||||
|
||||
C --> D["Low: Facilitate Direct Resolution"]
|
||||
C --> E["Medium: Structured Mediation"]
|
||||
C --> F["High: Formal Intervention"]
|
||||
|
||||
D --> G["Monitor Resolution"]
|
||||
E --> G
|
||||
F --> G
|
||||
|
||||
G --> H["Document Learnings"]
|
||||
H --> I["Follow Up"]
|
||||
I --> J["Implement Preventive Measures"]
|
||||
```
|
||||
|
||||
## Impediment Management Workflows
|
||||
|
||||
### Impediment Resolution Workflow
|
||||
|
||||
```mermaid title="Impediment Resolution Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Identify Impediment"] --> B["Document Impediment"]
|
||||
B --> C["Assess Impact and Urgency"]
|
||||
C --> D["Determine Resolution Approach"]
|
||||
|
||||
D --> E["Team Can Resolve"]
|
||||
D --> F["Requires Scrum Master"]
|
||||
D --> G["Requires Escalation"]
|
||||
|
||||
E --> H["Team Resolution"]
|
||||
F --> I["Scrum Master Resolution"]
|
||||
G --> J["Escalation Process"]
|
||||
|
||||
H --> K["Monitor Resolution"]
|
||||
I --> K
|
||||
J --> K
|
||||
|
||||
K --> L["Verify Resolution"]
|
||||
L --> M["Document Resolution"]
|
||||
M --> N["Implement Preventive Measures"]
|
||||
```
|
||||
|
||||
### Escalation Workflow
|
||||
|
||||
```mermaid title="Escalation Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Determine Escalation Need"] --> B["Identify Escalation Level"]
|
||||
|
||||
B --> C["Level 1: Team Lead"]
|
||||
B --> D["Level 2: Management"]
|
||||
B --> E["Level 3: Executive"]
|
||||
|
||||
C --> F["Prepare Escalation Information"]
|
||||
D --> F
|
||||
E --> F
|
||||
|
||||
F --> G["Conduct Escalation Meeting"]
|
||||
G --> H["Document Decisions"]
|
||||
H --> I["Implement Resolution"]
|
||||
I --> J["Monitor Effectiveness"]
|
||||
J --> K["Close Escalation"]
|
||||
```
|
||||
|
||||
### Risk Management Workflow
|
||||
|
||||
```mermaid title="Risk Management Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Identify Risk"] --> B["Assess Risk Impact and Probability"]
|
||||
B --> C["Document Risk"]
|
||||
C --> D["Determine Risk Response"]
|
||||
|
||||
D --> E["Accept Risk"]
|
||||
D --> F["Mitigate Risk"]
|
||||
D --> G["Transfer Risk"]
|
||||
D --> H["Avoid Risk"]
|
||||
|
||||
E --> I["Monitor Risk"]
|
||||
F --> I
|
||||
G --> I
|
||||
H --> I
|
||||
|
||||
I --> J["Update Risk Status"]
|
||||
J --> K["Communicate Risk Status"]
|
||||
```
|
||||
|
||||
## Process Improvement Workflows
|
||||
|
||||
### Continuous Improvement Workflow
|
||||
|
||||
```mermaid title="Continuous Improvement Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Identify Improvement Opportunity"] --> B["Assess Impact and Effort"]
|
||||
B --> C["Prioritize Improvement"]
|
||||
C --> D["Plan Implementation"]
|
||||
D --> E["Implement Change"]
|
||||
E --> F["Measure Results"]
|
||||
F --> G["Adjust Based on Feedback"]
|
||||
G --> H["Standardize Successful Changes"]
|
||||
H --> I["Share Learnings"]
|
||||
```
|
||||
|
||||
### Process Assessment Workflow
|
||||
|
||||
```mermaid title="Process Assessment Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Define Assessment Scope"] --> B["Select Assessment Criteria"]
|
||||
B --> C["Gather Assessment Data"]
|
||||
C --> D["Analyze Process Performance"]
|
||||
D --> E["Identify Strengths and Weaknesses"]
|
||||
E --> F["Generate Improvement Recommendations"]
|
||||
F --> G["Prioritize Recommendations"]
|
||||
G --> H["Create Improvement Plan"]
|
||||
H --> I["Implement Improvements"]
|
||||
I --> J["Reassess Process"]
|
||||
```
|
||||
|
||||
### Retrospective Action Tracking Workflow
|
||||
|
||||
```mermaid title="Retrospective Action Tracking Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Document Retrospective Actions"] --> B["Assign Ownership"]
|
||||
B --> C["Set Implementation Timeline"]
|
||||
C --> D["Add to Sprint Backlog"]
|
||||
D --> E["Track Implementation Progress"]
|
||||
E --> F["Review in Daily Scrum"]
|
||||
F --> G["Assess Effectiveness"]
|
||||
G --> H["Report in Next Retrospective"]
|
||||
H --> I["Adjust or Close Action"]
|
||||
```
|
||||
|
||||
## Stakeholder Management Workflows
|
||||
|
||||
### Stakeholder Communication Workflow
|
||||
|
||||
```mermaid title="Stakeholder Communication Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Identify Stakeholders"] --> B["Analyze Communication Needs"]
|
||||
B --> C["Develop Communication Plan"]
|
||||
C --> D["Create Communication Materials"]
|
||||
D --> E["Deliver Communication"]
|
||||
E --> F["Collect Feedback"]
|
||||
F --> G["Adjust Communication Approach"]
|
||||
G --> H["Document Communication Outcomes"]
|
||||
```
|
||||
|
||||
### Sprint Progress Reporting Workflow
|
||||
|
||||
```mermaid title="Sprint Progress Reporting Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Gather Sprint Data"] --> B["Analyze Sprint Progress"]
|
||||
B --> C["Identify Key Messages"]
|
||||
C --> D["Create Progress Report"]
|
||||
D --> E["Review with Team"]
|
||||
E --> F["Distribute to Stakeholders"]
|
||||
F --> G["Address Questions and Concerns"]
|
||||
G --> H["Update Based on Feedback"]
|
||||
```
|
||||
|
||||
### Stakeholder Expectation Management Workflow
|
||||
|
||||
```mermaid title="Stakeholder Expectation Management Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Identify Stakeholder Expectations"] --> B["Assess Expectation Alignment"]
|
||||
B --> C["Identify Expectation Gaps"]
|
||||
C --> D["Develop Alignment Strategy"]
|
||||
D --> E["Conduct Alignment Discussions"]
|
||||
E --> F["Document Agreed Expectations"]
|
||||
F --> G["Monitor Expectation Fulfillment"]
|
||||
G --> H["Adjust as Needed"]
|
||||
```
|
||||
|
||||
## Integration Workflows
|
||||
|
||||
### Product Owner Collaboration Workflow
|
||||
|
||||
```mermaid title="Product Owner Collaboration Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Daily Coordination"] --> B["Backlog Management Support"]
|
||||
B --> C["Sprint Planning Preparation"]
|
||||
C --> D["Sprint Review Coordination"]
|
||||
D --> E["Stakeholder Communication Alignment"]
|
||||
E --> F["Process Improvement Collaboration"]
|
||||
F --> A
|
||||
|
||||
A --> A1["Status Updates"]
|
||||
A --> A2["Impediment Coordination"]
|
||||
A --> A3["Priority Alignment"]
|
||||
|
||||
subgraph "Daily Coordination Activities"
|
||||
A1
|
||||
A2
|
||||
A3
|
||||
end
|
||||
```
|
||||
|
||||
### Development Team Integration Workflow
|
||||
|
||||
```mermaid title="Development Team Integration Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Daily Support"] --> B["Impediment Resolution"]
|
||||
B --> C["Process Facilitation"]
|
||||
C --> D["Technical Practice Support"]
|
||||
D --> E["Team Dynamics Facilitation"]
|
||||
E --> F["Skill Development Support"]
|
||||
F --> A
|
||||
|
||||
A --> A1["Daily Scrum Facilitation"]
|
||||
A --> A2["Ad-hoc Support"]
|
||||
A --> A3["Coordination Support"]
|
||||
|
||||
subgraph "Daily Support Activities"
|
||||
A1
|
||||
A2
|
||||
A3
|
||||
end
|
||||
```
|
||||
|
||||
### Architect Collaboration Workflow
|
||||
|
||||
```mermaid title="Architect Collaboration Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Technical Vision Alignment"] --> B["Architecture Review Support"]
|
||||
B --> C["Technical Debt Management"]
|
||||
C --> D["Technical Impediment Resolution"]
|
||||
D --> E["Technical Practice Improvement"]
|
||||
E --> A
|
||||
```
|
||||
|
||||
### Project Manager Collaboration Workflow
|
||||
|
||||
```mermaid title="Project Manager Collaboration Workflow" type="diagram"
|
||||
graph TD
|
||||
A["Status Reporting Coordination"] --> B["Risk Management Alignment"]
|
||||
B --> C["Resource Management Support"]
|
||||
C --> D["Timeline Coordination"]
|
||||
D --> E["Stakeholder Management Alignment"]
|
||||
E --> A
|
||||
```
|
||||
|
||||
## Decision Trees and Escalation Procedures
|
||||
|
||||
### Impediment Resolution Decision Tree
|
||||
|
||||
```mermaid title="Impediment Resolution Decision Tree" type="diagram"
|
||||
graph TD
|
||||
A["Impediment Identified"] --> B{"Can team resolve?"}
|
||||
B -->|Yes| C["Team resolves impediment"]
|
||||
B -->|No| D{"Is it technical?"}
|
||||
|
||||
D -->|Yes| E{"Is architect input needed?"}
|
||||
D -->|No| F{"Is it process-related?"}
|
||||
|
||||
E -->|Yes| G["Engage architect"]
|
||||
E -->|No| H["Technical team lead resolves"]
|
||||
|
||||
F -->|Yes| I["Scrum Master resolves"]
|
||||
F -->|No| J{"Is it organizational?"}
|
||||
|
||||
J -->|Yes| K{"What level of escalation?"}
|
||||
J -->|No| L["Scrum Master investigates further"]
|
||||
|
||||
K -->|Level 1| M["Team lead escalation"]
|
||||
K -->|Level 2| N["Management escalation"]
|
||||
K -->|Level 3| O["Executive escalation"]
|
||||
```
|
||||
|
||||
### Sprint Goal Risk Decision Tree
|
||||
|
||||
```mermaid title="Sprint Goal Risk Decision Tree" type="diagram"
|
||||
graph TD
|
||||
A["Sprint Goal Risk Identified"] --> B{"Risk severity?"}
|
||||
|
||||
B -->|Low| C["Monitor risk"]
|
||||
B -->|Medium| D["Develop mitigation plan"]
|
||||
B -->|High| E["Immediate action required"]
|
||||
|
||||
D --> F{"Can team mitigate?"}
|
||||
E --> F
|
||||
|
||||
F -->|Yes| G["Team implements mitigation"]
|
||||
F -->|No| H{"Scope adjustment needed?"}
|
||||
|
||||
H -->|Yes| I["Consult Product Owner"]
|
||||
H -->|No| J["Escalate for support"]
|
||||
|
||||
I --> K["Adjust sprint scope"]
|
||||
J --> L["Implement support plan"]
|
||||
```
|
||||
|
||||
### Conflict Resolution Decision Tree
|
||||
|
||||
```mermaid title="Conflict Resolution Decision Tree" type="diagram"
|
||||
graph TD
|
||||
A["Conflict Identified"] --> B{"Conflict severity?"}
|
||||
|
||||
B -->|Low| C["Facilitate direct resolution"]
|
||||
B -->|Medium| D["Structured mediation"]
|
||||
B -->|High| E["Formal intervention"]
|
||||
|
||||
C --> F{"Resolved?"}
|
||||
D --> F
|
||||
E --> F
|
||||
|
||||
F -->|Yes| G["Document resolution"]
|
||||
F -->|No| H{"Escalation needed?"}
|
||||
|
||||
H -->|Yes| I["Escalate to appropriate level"]
|
||||
H -->|No| J["Try different approach"]
|
||||
|
||||
I --> K["Implement resolution plan"]
|
||||
J --> L["Reassess conflict"]
|
||||
```
|
||||
|
||||
## Workflow Customization Guidelines
|
||||
|
||||
### Workflow Adaptation Process
|
||||
|
||||
```mermaid title="Workflow Adaptation Process" type="diagram"
|
||||
graph TD
|
||||
A["Identify Adaptation Need"] --> B["Assess Current Workflow"]
|
||||
B --> C["Identify Adaptation Options"]
|
||||
C --> D["Evaluate Options"]
|
||||
D --> E["Select Best Approach"]
|
||||
E --> F["Plan Implementation"]
|
||||
F --> G["Implement Adaptation"]
|
||||
G --> H["Evaluate Effectiveness"]
|
||||
H --> I["Standardize or Adjust"]
|
||||
```
|
||||
|
||||
### Workflow Integration Guidelines
|
||||
|
||||
#### Integration with Product Owner Workflows
|
||||
1. **Backlog Management Integration**
|
||||
- Coordinate backlog refinement scheduling and preparation
|
||||
- Support Product Owner in backlog prioritization
|
||||
- Ensure backlog items meet Definition of Ready
|
||||
|
||||
2. **Sprint Planning Integration**
|
||||
- Collaborate on sprint goal definition
|
||||
- Support Product Owner in explaining backlog items
|
||||
- Ensure team understanding of requirements
|
||||
|
||||
3. **Sprint Review Integration**
|
||||
- Coordinate review preparation and stakeholder invitations
|
||||
- Support Product Owner in presenting business context
|
||||
- Facilitate feedback collection and documentation
|
||||
|
||||
#### Integration with Development Team Workflows
|
||||
1. **Daily Work Integration**
|
||||
- Facilitate daily coordination through Daily Scrum
|
||||
- Support team in impediment resolution
|
||||
- Protect team from external disruptions
|
||||
|
||||
2. **Technical Practice Integration**
|
||||
- Support adoption of technical best practices
|
||||
- Facilitate technical debt discussions
|
||||
- Coordinate with technical leads on architecture concerns
|
||||
|
||||
3. **Quality Assurance Integration**
|
||||
- Support Definition of Done adherence
|
||||
- Facilitate quality-focused discussions
|
||||
- Coordinate testing and quality activities
|
||||
|
||||
#### Integration with Organizational Workflows
|
||||
1. **Reporting Integration**
|
||||
- Align Scrum reporting with organizational requirements
|
||||
- Translate Scrum metrics for organizational stakeholders
|
||||
- Coordinate with Project Management Office as needed
|
||||
|
||||
2. **Resource Management Integration**
|
||||
- Support capacity planning and resource allocation
|
||||
- Coordinate with resource managers on team composition
|
||||
- Advocate for team stability and focus
|
||||
|
||||
3. **Strategic Alignment Integration**
|
||||
- Ensure team understanding of organizational goals
|
||||
- Connect sprint goals to strategic objectives
|
||||
- Communicate team contributions to organizational success
|
||||
|
||||
### Workflow Customization Factors
|
||||
|
||||
#### Team Maturity Considerations
|
||||
- **New Teams**: More structured workflows with detailed guidance
|
||||
- **Developing Teams**: Balanced structure with growing autonomy
|
||||
- **Mature Teams**: Lightweight workflows focusing on impediments and continuous improvement
|
||||
|
||||
#### Project Complexity Considerations
|
||||
- **Simple Projects**: Streamlined workflows with minimal overhead
|
||||
- **Moderate Complexity**: Standard Scrum workflows with targeted adaptations
|
||||
- **High Complexity**: Enhanced workflows with additional coordination and risk management
|
||||
|
||||
#### Organizational Context Considerations
|
||||
- **Regulatory Requirements**: Additional compliance and documentation steps
|
||||
- **Distributed Teams**: Enhanced communication and coordination workflows
|
||||
- **Multiple Team Coordination**: Added integration points with other Scrum Masters
|
||||
|
||||
---
|
||||
|
||||
This workflow mapping provides Scrum Masters with comprehensive process flows for all key activities within the BMAD Method. By following these workflows, Scrum Masters can ensure effective facilitation, team support, and continuous improvement.
|
||||
|
|
@ -0,0 +1,181 @@
|
|||
# BMAD System Architecture Documentation
|
||||
|
||||
This section provides comprehensive visual documentation of the BMAD system architecture, component relationships, and data flows.
|
||||
|
||||
## Architecture Overview
|
||||
|
||||
The BMAD (Business, Management, Architecture, Development) system is built on a modular, AI-driven architecture that enables seamless coordination between specialized personas through an intelligent orchestrator.
|
||||
|
||||
## Quick Navigation
|
||||
|
||||
| Document | Description | Audience |
|
||||
|----------|-------------|----------|
|
||||
| [System Overview](system-overview.md) | High-level system architecture | All stakeholders |
|
||||
| [Component Architecture](component-architecture.md) | Detailed component breakdown | Technical teams |
|
||||
| [Data Flow Diagrams](data-flow-diagrams.md) | Information flow patterns | Architects & Developers |
|
||||
| [Integration Architecture](integration-architecture.md) | External system integrations | Integration teams |
|
||||
| [Deployment Architecture](deployment-architecture.md) | Infrastructure and deployment | DevOps & Operations |
|
||||
|
||||
## Architecture Principles
|
||||
|
||||
### 1. Modular Design
|
||||
- **Separation of Concerns**: Each component has a single, well-defined responsibility
|
||||
- **Loose Coupling**: Components interact through well-defined interfaces
|
||||
- **High Cohesion**: Related functionality is grouped together
|
||||
- **Pluggable Architecture**: Components can be easily replaced or extended
|
||||
|
||||
### 2. AI-First Approach
|
||||
- **Intelligent Orchestration**: AI-driven coordination between personas
|
||||
- **Context-Aware Processing**: Decisions based on complete project context
|
||||
- **Adaptive Behavior**: System learns and improves from interactions
|
||||
- **Natural Language Interface**: Human-friendly interaction patterns
|
||||
|
||||
### 3. Scalability & Performance
|
||||
- **Horizontal Scaling**: System can scale across multiple instances
|
||||
- **Efficient Resource Usage**: Optimized for memory and processing efficiency
|
||||
- **Caching Strategies**: Multi-level caching for improved performance
|
||||
- **Asynchronous Processing**: Non-blocking operations where possible
|
||||
|
||||
### 4. Security & Reliability
|
||||
- **Defense in Depth**: Multiple layers of security controls
|
||||
- **Data Protection**: Encryption at rest and in transit
|
||||
- **Fault Tolerance**: Graceful degradation and error recovery
|
||||
- **Audit Trail**: Complete logging of all system activities
|
||||
|
||||
## System Architecture Layers
|
||||
|
||||
\```mermaid title="BMAD System Architecture Layers" type="diagram"
|
||||
graph TB
|
||||
subgraph "Presentation Layer"
|
||||
WEB[Web Interface]
|
||||
IDE[IDE Extensions]
|
||||
CLI[Command Line Interface]
|
||||
API[REST API]
|
||||
end
|
||||
|
||||
subgraph "Application Layer"
|
||||
ORCH[Orchestrator Engine]
|
||||
PERSONAS[Persona Management]
|
||||
TASKS[Task Execution Engine]
|
||||
WORKFLOW[Workflow Manager]
|
||||
end
|
||||
|
||||
subgraph "Business Logic Layer"
|
||||
TEMPLATES[Template Engine]
|
||||
CHECKLISTS[Checklist Processor]
|
||||
VALIDATION[Validation Engine]
|
||||
QUALITY[Quality Assurance]
|
||||
end
|
||||
|
||||
subgraph "Data Access Layer"
|
||||
KB[Knowledge Base]
|
||||
CONFIG[Configuration Store]
|
||||
CACHE[Caching Layer]
|
||||
SEARCH[Search Engine]
|
||||
end
|
||||
|
||||
subgraph "Infrastructure Layer"
|
||||
STORAGE[File Storage]
|
||||
DATABASE[Database]
|
||||
QUEUE[Message Queue]
|
||||
MONITOR[Monitoring]
|
||||
end
|
||||
|
||||
WEB --> ORCH
|
||||
IDE --> ORCH
|
||||
CLI --> ORCH
|
||||
API --> ORCH
|
||||
|
||||
ORCH --> PERSONAS
|
||||
ORCH --> TASKS
|
||||
ORCH --> WORKFLOW
|
||||
|
||||
PERSONAS --> TEMPLATES
|
||||
TASKS --> CHECKLISTS
|
||||
WORKFLOW --> VALIDATION
|
||||
VALIDATION --> QUALITY
|
||||
|
||||
TEMPLATES --> KB
|
||||
CHECKLISTS --> CONFIG
|
||||
VALIDATION --> CACHE
|
||||
QUALITY --> SEARCH
|
||||
|
||||
KB --> STORAGE
|
||||
CONFIG --> DATABASE
|
||||
CACHE --> QUEUE
|
||||
SEARCH --> MONITOR
|
||||
\```
|
||||
|
||||
## Key Architectural Decisions
|
||||
|
||||
### 1. Orchestrator-Centric Design
|
||||
**Decision**: Central orchestrator manages all persona interactions
|
||||
**Rationale**: Ensures consistent coordination and context management
|
||||
**Trade-offs**: Single point of coordination vs. distributed complexity
|
||||
|
||||
### 2. Template-Driven Output
|
||||
**Decision**: All deliverables generated from standardized templates
|
||||
**Rationale**: Ensures consistency and quality across all outputs
|
||||
**Trade-offs**: Standardization vs. flexibility
|
||||
|
||||
### 3. Context-Aware Processing
|
||||
**Decision**: All personas have access to complete project context
|
||||
**Rationale**: Enables informed decision-making and reduces errors
|
||||
**Trade-offs**: Memory usage vs. decision quality
|
||||
|
||||
### 4. Multi-Environment Support
|
||||
**Decision**: Support both web and IDE environments
|
||||
**Rationale**: Flexibility for different user preferences and workflows
|
||||
**Trade-offs**: Development complexity vs. user adoption
|
||||
|
||||
## Performance Characteristics
|
||||
|
||||
### Response Time Targets
|
||||
- **Simple Queries**: < 200ms
|
||||
- **Template Generation**: < 2 seconds
|
||||
- **Complex Analysis**: < 10 seconds
|
||||
- **Bulk Operations**: < 30 seconds
|
||||
|
||||
### Scalability Metrics
|
||||
- **Concurrent Users**: 1000+ simultaneous users
|
||||
- **Request Throughput**: 10,000+ requests/minute
|
||||
- **Data Volume**: 100GB+ knowledge base
|
||||
- **Geographic Distribution**: Multi-region deployment
|
||||
|
||||
### Availability Requirements
|
||||
- **Uptime Target**: 99.9% availability
|
||||
- **Recovery Time**: < 5 minutes for critical failures
|
||||
- **Backup Frequency**: Real-time data replication
|
||||
- **Disaster Recovery**: < 1 hour full system recovery
|
||||
|
||||
## Security Architecture
|
||||
|
||||
### Authentication & Authorization
|
||||
- **Multi-factor Authentication**: Required for all users
|
||||
- **Role-based Access Control**: Granular permission management
|
||||
- **API Key Management**: Secure external system integration
|
||||
- **Session Management**: Secure session handling and timeout
|
||||
|
||||
### Data Protection
|
||||
- **Encryption**: AES-256 encryption for data at rest
|
||||
- **Transport Security**: TLS 1.3 for all communications
|
||||
- **Key Management**: Hardware security module (HSM) integration
|
||||
- **Data Classification**: Automated sensitive data identification
|
||||
|
||||
### Compliance & Auditing
|
||||
- **Audit Logging**: Complete activity trail
|
||||
- **Compliance Monitoring**: Automated compliance checking
|
||||
- **Data Retention**: Configurable retention policies
|
||||
- **Privacy Controls**: GDPR and CCPA compliance features
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Review System Overview**: Start with [System Overview](system-overview.md)
|
||||
2. **Understand Components**: Explore [Component Architecture](component-architecture.md)
|
||||
3. **Analyze Data Flows**: Study [Data Flow Diagrams](data-flow-diagrams.md)
|
||||
4. **Plan Integrations**: Review [Integration Architecture](integration-architecture.md)
|
||||
5. **Design Deployment**: Examine [Deployment Architecture](deployment-architecture.md)
|
||||
|
||||
---
|
||||
|
||||
*This architecture documentation provides the foundation for understanding, implementing, and extending the BMAD system.*
|
||||
|
|
@ -0,0 +1,122 @@
|
|||
# BMAD Method Component Architecture
|
||||
|
||||
## Overview
|
||||
|
||||
The BMAD Method is a structured approach for AI-driven development that coordinates specialized personas. This document outlines the conceptual components that make up the BMAD Method ecosystem.
|
||||
|
||||
## Component Breakdown
|
||||
|
||||
The BMAD Method consists of several interconnected conceptual components that work together to facilitate AI-driven development:
|
||||
|
||||
\```mermaid title="BMAD Method Component Architecture" type="diagram"
|
||||
graph TD
|
||||
A["BMAD Orchestrator"] --> B["Persona System"]
|
||||
A --> C["Task Framework"]
|
||||
A --> D["Template Engine"]
|
||||
A --> E["Checklist System"]
|
||||
|
||||
B --> B1["Product Owner"]
|
||||
B --> B2["Architect"]
|
||||
B --> B3["UX/UI Designer"]
|
||||
B --> B4["Developer"]
|
||||
B --> B5["Project Manager"]
|
||||
B --> B6["Analyst"]
|
||||
|
||||
C --> C1["Task Definitions"]
|
||||
C --> C2["Task Execution Flow"]
|
||||
C --> C3["Task Outputs"]
|
||||
|
||||
D --> D1["Document Templates"]
|
||||
D --> D2["Code Templates"]
|
||||
D --> D3["Process Templates"]
|
||||
|
||||
E --> E1["Quality Checklists"]
|
||||
E --> E2["Process Checklists"]
|
||||
E --> E3["Deliverable Checklists"]
|
||||
\```
|
||||
|
||||
## Component Descriptions
|
||||
|
||||
### 1. BMAD Orchestrator
|
||||
|
||||
The central coordination mechanism that manages the overall workflow and interactions between personas.
|
||||
|
||||
**Responsibilities:**
|
||||
- Coordinate persona transitions
|
||||
- Manage context sharing between personas
|
||||
- Track project progress
|
||||
- Ensure methodology adherence
|
||||
|
||||
### 2. Persona System
|
||||
|
||||
A collection of specialized AI personas, each with distinct expertise and responsibilities.
|
||||
|
||||
**Key Personas:**
|
||||
- **Product Owner**: Defines product requirements and priorities
|
||||
- **Architect**: Designs system architecture and technical approaches
|
||||
- **UX/UI Designer**: Creates user experience and interface designs
|
||||
- **Developer**: Implements technical solutions
|
||||
- **Project Manager**: Coordinates project activities and resources
|
||||
- **Analyst**: Analyzes requirements and provides insights
|
||||
|
||||
### 3. Task Framework
|
||||
|
||||
The structured approach for defining, executing, and tracking tasks within the BMAD Method.
|
||||
|
||||
**Components:**
|
||||
- **Task Definitions**: Standardized task structures
|
||||
- **Task Execution Flow**: Process for completing tasks
|
||||
- **Task Outputs**: Standardized deliverables
|
||||
|
||||
### 4. Template Engine
|
||||
|
||||
A collection of standardized templates for various artifacts produced during the development process.
|
||||
|
||||
**Template Types:**
|
||||
- **Document Templates**: For specifications, requirements, etc.
|
||||
- **Code Templates**: For standardized code structures
|
||||
- **Process Templates**: For workflow documentation
|
||||
|
||||
### 5. Checklist System
|
||||
|
||||
Quality assurance mechanisms to ensure completeness and consistency.
|
||||
|
||||
**Checklist Types:**
|
||||
- **Quality Checklists**: Ensure deliverable quality
|
||||
- **Process Checklists**: Verify process adherence
|
||||
- **Deliverable Checklists**: Confirm deliverable completeness
|
||||
|
||||
## Component Interactions
|
||||
|
||||
The components interact through a series of defined workflows:
|
||||
|
||||
\```mermaid title="Component Interaction Flow" type="diagram"
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant Orchestrator as BMAD Orchestrator
|
||||
participant Personas as Persona System
|
||||
participant Tasks as Task Framework
|
||||
participant Templates as Template Engine
|
||||
participant Checklists as Checklist System
|
||||
|
||||
User->>Orchestrator: Initiate project
|
||||
Orchestrator->>Personas: Activate appropriate persona
|
||||
Personas->>Tasks: Execute assigned task
|
||||
Tasks->>Templates: Utilize relevant templates
|
||||
Tasks->>Checklists: Verify against checklists
|
||||
Personas->>Orchestrator: Return completed work
|
||||
Orchestrator->>User: Deliver output
|
||||
\```
|
||||
|
||||
## Integration Points
|
||||
|
||||
The BMAD Method components integrate with:
|
||||
|
||||
1. **LLM Platforms**: The underlying AI models that power the personas
|
||||
2. **IDE Environments**: Where development tasks are executed
|
||||
3. **Documentation Systems**: Where artifacts are stored
|
||||
4. **Project Management Tools**: For tracking progress
|
||||
|
||||
## Conclusion
|
||||
|
||||
The BMAD Method's component architecture is designed to provide a structured, repeatable approach to AI-driven development. By breaking down the methodology into these conceptual components, teams can better understand, implement, and extend the BMAD Method for their specific needs.
|
||||
|
|
@ -0,0 +1,151 @@
|
|||
# BMAD Method Data Flow Diagrams
|
||||
|
||||
## Overview
|
||||
|
||||
This document illustrates how information flows through the BMAD Method process. Unlike traditional software systems with databases and APIs, the BMAD Method manages the flow of context, requirements, specifications, and other information between different personas and stages of the development process.
|
||||
|
||||
## Core Information Flow
|
||||
|
||||
The BMAD Method's primary information flow shows how context and requirements transform into deliverables through a series of specialized personas:
|
||||
|
||||
\```mermaid title="BMAD Core Information Flow" type="diagram"
|
||||
flowchart TD
|
||||
A[Initial Requirements] --> B{BMAD Orchestrator}
|
||||
B --> C[Product Owner]
|
||||
C -- "Requirements Document" --> B
|
||||
B --> D[Architect]
|
||||
D -- "Architecture Specification" --> B
|
||||
B --> E[UX/UI Designer]
|
||||
E -- "Design Specification" --> B
|
||||
B --> F[Developer]
|
||||
F -- "Implementation" --> B
|
||||
B --> G[Final Deliverable]
|
||||
|
||||
style B fill:#f96,stroke:#333,stroke-width:2px
|
||||
\```
|
||||
|
||||
## Context Preservation Flow
|
||||
|
||||
One of the BMAD Method's key strengths is how it preserves and enriches context throughout the development process:
|
||||
|
||||
\```mermaid title="Context Preservation Flow" type="diagram"
|
||||
graph TD
|
||||
A[Initial Context] --> B[Context Enrichment]
|
||||
B --> C[Context Sharing]
|
||||
C --> D[Context Application]
|
||||
D --> E[Context Validation]
|
||||
E -->|Feedback Loop| B
|
||||
|
||||
subgraph "Context Enrichment"
|
||||
B1[Product Owner Input] --> B2[Architect Input]
|
||||
B2 --> B3[Designer Input]
|
||||
B3 --> B4[Developer Input]
|
||||
end
|
||||
|
||||
subgraph "Context Application"
|
||||
D1[Requirements Application] --> D2[Architecture Application]
|
||||
D2 --> D3[Design Application]
|
||||
D3 --> D4[Implementation Application]
|
||||
end
|
||||
\```
|
||||
|
||||
## Task Execution Flow
|
||||
|
||||
Information flow during task execution in the BMAD Method:
|
||||
|
||||
\```mermaid title="Task Execution Information Flow" type="diagram"
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant Orchestrator
|
||||
participant ActivePersona
|
||||
participant Knowledge as Knowledge Base
|
||||
participant Templates
|
||||
participant Checklists
|
||||
|
||||
User->>Orchestrator: Task Request + Context
|
||||
Orchestrator->>Knowledge: Retrieve Relevant Knowledge
|
||||
Knowledge-->>Orchestrator: Domain Knowledge
|
||||
Orchestrator->>Templates: Retrieve Appropriate Templates
|
||||
Templates-->>Orchestrator: Task Templates
|
||||
Orchestrator->>ActivePersona: Assign Task + Context + Templates
|
||||
ActivePersona->>ActivePersona: Process Information
|
||||
ActivePersona->>Checklists: Verify Against Checklists
|
||||
Checklists-->>ActivePersona: Verification Results
|
||||
ActivePersona->>Orchestrator: Task Output
|
||||
Orchestrator->>User: Deliverable
|
||||
\```
|
||||
|
||||
## Persona Transition Flow
|
||||
|
||||
How information transitions between personas in the BMAD Method:
|
||||
|
||||
\```mermaid title="Persona Transition Information Flow" type="diagram"
|
||||
graph TD
|
||||
A[Initial Request] --> B[Product Owner]
|
||||
B -- "PRD" --> C[Architect]
|
||||
C -- "Architecture Doc" --> D[UX/UI Designer]
|
||||
D -- "Design Spec" --> E[Developer]
|
||||
E -- "Implementation" --> F[Project Manager]
|
||||
F -- "Project Status" --> G[Stakeholders]
|
||||
|
||||
H[Shared Context Repository] <-.-> B
|
||||
H <-.-> C
|
||||
H <-.-> D
|
||||
H <-.-> E
|
||||
H <-.-> F
|
||||
|
||||
style H fill:#f9f,stroke:#333,stroke-width:2px
|
||||
\```
|
||||
|
||||
## Checklist Verification Flow
|
||||
|
||||
How information flows through the checklist verification process:
|
||||
|
||||
\```mermaid title="Checklist Verification Flow" type="diagram"
|
||||
flowchart TD
|
||||
A[Task Output] --> B{Checklist System}
|
||||
B --> C[Quality Checklist]
|
||||
B --> D[Process Checklist]
|
||||
B --> E[Deliverable Checklist]
|
||||
|
||||
C --> F{Quality Check}
|
||||
D --> G{Process Check}
|
||||
E --> H{Completeness Check}
|
||||
|
||||
F -->|Pass| I[Quality Verified]
|
||||
F -->|Fail| J[Quality Remediation]
|
||||
J --> A
|
||||
|
||||
G -->|Pass| K[Process Verified]
|
||||
G -->|Fail| L[Process Remediation]
|
||||
L --> A
|
||||
|
||||
H -->|Pass| M[Completeness Verified]
|
||||
H -->|Fail| N[Completeness Remediation]
|
||||
N --> A
|
||||
|
||||
I --> O[Final Verification]
|
||||
K --> O
|
||||
M --> O
|
||||
|
||||
O --> P[Verified Deliverable]
|
||||
\```
|
||||
|
||||
## Template Application Flow
|
||||
|
||||
How templates are applied to structure information in the BMAD Method:
|
||||
|
||||
\```mermaid title="Template Application Flow" type="diagram"
|
||||
graph LR
|
||||
A[Raw Information] --> B[Template Selection]
|
||||
B --> C[Template Application]
|
||||
C --> D[Structured Information]
|
||||
D --> E[Template Validation]
|
||||
E -->|Valid| F[Finalized Document]
|
||||
E -->|Invalid| G[Revision]
|
||||
G --> C
|
||||
\```
|
||||
|
||||
## Conclusion
|
||||
|
||||
The BMAD Method's information flow is designed to ensure that context is preserved, enriched, and effectively utilized throughout the development process. By structuring information flow through specialized personas and standardized processes, the BMAD Method creates a consistent, high-quality approach to AI-driven development.
|
||||
|
|
@ -0,0 +1,195 @@
|
|||
# BMAD Method Deployment Architecture
|
||||
|
||||
## Overview
|
||||
|
||||
Unlike traditional software systems, the BMAD Method is not "deployed" in the conventional sense with servers, databases, and APIs. Instead, it is "deployed" as a methodology through documentation, templates, and practices. This document outlines how the BMAD Method can be effectively deployed within an organization or team.
|
||||
|
||||
## Conceptual Deployment Architecture
|
||||
|
||||
\```mermaid title="BMAD Method Conceptual Deployment" type="diagram"
|
||||
graph TD
|
||||
A[BMAD Method] --> B[Documentation Deployment]
|
||||
A --> C[Template Deployment]
|
||||
A --> D[Process Deployment]
|
||||
A --> E[Tool Integration Deployment]
|
||||
|
||||
B --> B1[Knowledge Base]
|
||||
B --> B2[Training Materials]
|
||||
B --> B3[Reference Guides]
|
||||
|
||||
C --> C1[Template Repository]
|
||||
C --> C2[Template Distribution]
|
||||
C --> C3[Template Versioning]
|
||||
|
||||
D --> D1[Process Documentation]
|
||||
D --> D2[Workflow Integration]
|
||||
D --> D3[Checklist Implementation]
|
||||
|
||||
E --> E1[LLM Integration]
|
||||
E --> E2[IDE Integration]
|
||||
E --> E3[Tool-Specific Adapters]
|
||||
\```
|
||||
|
||||
## Documentation Deployment
|
||||
|
||||
The BMAD Method documentation can be deployed through various channels:
|
||||
|
||||
\```mermaid title="Documentation Deployment Options" type="diagram"
|
||||
graph LR
|
||||
A[BMAD Documentation] --> B[GitHub Repository]
|
||||
A --> C[Internal Wiki]
|
||||
A --> D[Documentation Site]
|
||||
A --> E[PDF Guides]
|
||||
A --> F[Training Platform]
|
||||
|
||||
B --> G[GitHub Pages]
|
||||
C --> H[Confluence]
|
||||
C --> I[Notion]
|
||||
D --> J[Static Site]
|
||||
D --> K[Interactive Docs]
|
||||
F --> L[LMS]
|
||||
F --> M[Workshop Materials]
|
||||
\```
|
||||
|
||||
## Template Deployment
|
||||
|
||||
BMAD Method templates can be deployed through:
|
||||
|
||||
\```mermaid title="Template Deployment Architecture" type="diagram"
|
||||
flowchart TD
|
||||
A[BMAD Templates] --> B[Version Control]
|
||||
B --> C[Template Repository]
|
||||
C --> D[Template Distribution]
|
||||
|
||||
D --> E[IDE Integration]
|
||||
D --> F[Documentation System]
|
||||
D --> G[Direct Access]
|
||||
|
||||
E --> H[VS Code Extension]
|
||||
E --> I[JetBrains Plugin]
|
||||
E --> J[Cursor Integration]
|
||||
|
||||
F --> K[Confluence Template]
|
||||
F --> L[Notion Template]
|
||||
|
||||
G --> M[GitHub Access]
|
||||
G --> N[Direct Download]
|
||||
\```
|
||||
|
||||
## Process Deployment
|
||||
|
||||
BMAD Method processes can be deployed through:
|
||||
|
||||
\```mermaid title="Process Deployment Architecture" type="diagram"
|
||||
graph TD
|
||||
A[BMAD Processes] --> B[Process Documentation]
|
||||
A --> C[Workflow Integration]
|
||||
A --> D[Training]
|
||||
|
||||
B --> B1[Process Guides]
|
||||
B --> B2[Workflow Diagrams]
|
||||
B --> B3[Checklists]
|
||||
|
||||
C --> C1[Project Management Integration]
|
||||
C --> C2[Development Workflow]
|
||||
C --> C3[Review Process]
|
||||
|
||||
D --> D1[Onboarding]
|
||||
D --> D2[Workshops]
|
||||
D --> D3[Practice Exercises]
|
||||
\```
|
||||
|
||||
## LLM Integration Deployment
|
||||
|
||||
How the BMAD Method can be deployed for LLM integration:
|
||||
|
||||
\```mermaid title="LLM Integration Deployment" type="diagram"
|
||||
flowchart LR
|
||||
A[BMAD Method] --> B[Prompt Engineering]
|
||||
A --> C[Context Management]
|
||||
A --> D[Persona Implementation]
|
||||
|
||||
B --> E[Prompt Templates]
|
||||
B --> F[Prompt Strategies]
|
||||
|
||||
C --> G[Context Preservation]
|
||||
C --> H[Context Enrichment]
|
||||
|
||||
D --> I[Persona Definitions]
|
||||
D --> J[Persona Switching]
|
||||
|
||||
E --> K[OpenAI Integration]
|
||||
E --> L[Anthropic Integration]
|
||||
E --> M[Custom LLM Integration]
|
||||
\```
|
||||
|
||||
## Organizational Deployment Models
|
||||
|
||||
Different ways to deploy the BMAD Method within an organization:
|
||||
|
||||
\```mermaid title="Organizational Deployment Models" type="diagram"
|
||||
graph TD
|
||||
A[BMAD Method] --> B[Full Adoption]
|
||||
A --> C[Hybrid Adoption]
|
||||
A --> D[Pilot Adoption]
|
||||
A --> E[Project-Specific Adoption]
|
||||
|
||||
B --> B1[Organization-wide Implementation]
|
||||
B --> B2[Standardized Processes]
|
||||
B --> B3[Comprehensive Training]
|
||||
|
||||
C --> C1[Selected Teams]
|
||||
C --> C2[Selected Projects]
|
||||
C --> C3[Partial Process Adoption]
|
||||
|
||||
D --> D1[Single Team Pilot]
|
||||
D --> D2[Single Project Pilot]
|
||||
D --> D3[Evaluation Period]
|
||||
|
||||
E --> E1[Project-Specific Implementation]
|
||||
E --> E2[Custom Adaptation]
|
||||
E --> E3[Limited Scope]
|
||||
\```
|
||||
|
||||
## Deployment Phases
|
||||
|
||||
A phased approach to deploying the BMAD Method:
|
||||
|
||||
\```mermaid title="BMAD Deployment Phases" type="diagram"
|
||||
graph LR
|
||||
A[Phase 1: Preparation] --> B[Phase 2: Pilot]
|
||||
B --> C[Phase 3: Evaluation]
|
||||
C --> D[Phase 4: Refinement]
|
||||
D --> E[Phase 5: Expansion]
|
||||
E --> F[Phase 6: Standardization]
|
||||
|
||||
A --> A1[Documentation Review]
|
||||
A --> A2[Team Training]
|
||||
A --> A3[Tool Setup]
|
||||
|
||||
B --> B1[Pilot Project]
|
||||
B --> B2[Process Monitoring]
|
||||
B --> B3[Feedback Collection]
|
||||
|
||||
C --> C1[Results Analysis]
|
||||
C --> C2[Process Adjustment]
|
||||
C --> C3[Tool Refinement]
|
||||
|
||||
D --> D1[Template Updates]
|
||||
D --> D2[Process Improvements]
|
||||
D --> D3[Additional Training]
|
||||
|
||||
E --> E1[Additional Teams]
|
||||
E --> E2[Additional Projects]
|
||||
E --> E3[Knowledge Sharing]
|
||||
|
||||
F --> F1[Standard Operating Procedures]
|
||||
F --> F2[Integration with Existing Processes]
|
||||
F --> F3[Continuous Improvement]
|
||||
\```
|
||||
|
||||
## Conclusion
|
||||
|
||||
Deploying the BMAD Method is primarily about implementing a methodology rather than installing software. By focusing on documentation, templates, processes, and integration with existing tools, organizations can effectively adopt the BMAD Method and realize its benefits for AI-driven development.
|
||||
|
||||
The deployment architecture outlined in this document provides a framework for understanding how the BMAD Method can be implemented in various organizational contexts, from small teams to large enterprises.
|
||||
|
|
@ -0,0 +1,222 @@
|
|||
# BMAD Method Integration Architecture
|
||||
|
||||
## Overview
|
||||
|
||||
The BMAD Method is designed to integrate with various tools, platforms, and workflows rather than functioning as a standalone application. This document outlines how the BMAD Method integrates with LLMs, development environments, and existing workflows.
|
||||
|
||||
## Integration Landscape
|
||||
|
||||
```mermaid title="BMAD Integration Landscape" type="diagram"
|
||||
graph TD
|
||||
A[BMAD Method] --> B[LLM Platforms]
|
||||
A --> C[Development Environments]
|
||||
A --> D[Documentation Systems]
|
||||
A --> E[Project Management Tools]
|
||||
A --> F[Version Control Systems]
|
||||
|
||||
subgraph "LLM Platforms"
|
||||
B1[OpenAI]
|
||||
B2[Anthropic]
|
||||
B3[Gemini]
|
||||
B4[Custom LLMs]
|
||||
end
|
||||
|
||||
subgraph "Development Environments"
|
||||
C1[VS Code]
|
||||
C2[JetBrains IDEs]
|
||||
C3[Cursor]
|
||||
C4[Cline]
|
||||
C5[RooCode]
|
||||
end
|
||||
|
||||
subgraph "Documentation Systems"
|
||||
D1[Markdown]
|
||||
D2[Notion]
|
||||
D3[Confluence]
|
||||
D4[GitHub Wiki]
|
||||
end
|
||||
|
||||
subgraph "Project Management Tools"
|
||||
E1[Jira]
|
||||
E2[Asana]
|
||||
E3[Trello]
|
||||
E4[GitHub Projects]
|
||||
end
|
||||
|
||||
subgraph "Version Control Systems"
|
||||
F1[Git]
|
||||
F2[GitHub]
|
||||
F3[GitLab]
|
||||
F4[Bitbucket]
|
||||
end
|
||||
```
|
||||
|
||||
## LLM Integration Architecture
|
||||
|
||||
The BMAD Method integrates with Large Language Models through structured prompts and context management:
|
||||
|
||||
```mermaid title="LLM Integration Architecture" type="diagram"
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant BMAD as BMAD Method
|
||||
participant LLM as LLM Platform
|
||||
|
||||
User->>BMAD: Project Requirements
|
||||
BMAD->>BMAD: Structure Requirements
|
||||
BMAD->>LLM: Structured Prompt + Context
|
||||
LLM->>LLM: Process Prompt
|
||||
LLM->>BMAD: Generated Response
|
||||
BMAD->>BMAD: Format & Validate Response
|
||||
BMAD->>User: Formatted Deliverable
|
||||
```
|
||||
|
||||
## Development Environment Integration
|
||||
|
||||
### Methodology Integration Patterns
|
||||
|
||||
**IDE Integration Approach:**
|
||||
- Load BMAD documentation into AI assistant context
|
||||
- Structure prompts using persona frameworks
|
||||
- Apply templates and checklists as guidance
|
||||
- Follow methodology workflows
|
||||
|
||||
**Integration Flow:**
|
||||
```mermaid title="IDE Integration Flow" type="diagram"
|
||||
graph LR
|
||||
DOC[BMAD Documentation] --> AI[AI Assistant]
|
||||
AI --> PROMPT[Structured Prompts]
|
||||
PROMPT --> OUTPUT[Methodology-Driven Output]
|
||||
OUTPUT --> VALIDATE[Quality Validation]
|
||||
VALIDATE --> DELIVER[Final Deliverable]
|
||||
```
|
||||
|
||||
## Documentation Integration
|
||||
|
||||
How the BMAD Method integrates with documentation systems:
|
||||
|
||||
```mermaid title="Documentation Integration" type="diagram"
|
||||
flowchart LR
|
||||
A[BMAD Templates] --> B[Content Generation]
|
||||
B --> C{Output Format}
|
||||
C --> D[GitHub Markdown]
|
||||
C --> E[Confluence Wiki]
|
||||
C --> F[Notion Page]
|
||||
C --> G[HTML Documentation]
|
||||
```
|
||||
|
||||
## Project Management Integration
|
||||
|
||||
How the BMAD Method integrates with project management tools:
|
||||
|
||||
```mermaid title="Project Management Integration" type="diagram"
|
||||
graph TD
|
||||
A[BMAD Method] --> B[Task Generation]
|
||||
A --> C[Story Creation]
|
||||
A --> D[Sprint Planning]
|
||||
|
||||
B --> E{Project Management Tool}
|
||||
C --> E
|
||||
D --> E
|
||||
|
||||
E --> F[Jira]
|
||||
E --> G[GitHub Projects]
|
||||
E --> H[Asana]
|
||||
E --> I[Trello]
|
||||
```
|
||||
|
||||
## Integration Patterns
|
||||
|
||||
The BMAD Method employs several integration patterns:
|
||||
|
||||
### 1. Prompt-Based Integration
|
||||
|
||||
```mermaid title="Prompt-Based Integration Pattern" type="diagram"
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant BMAD as BMAD Method
|
||||
participant LLM as LLM Platform
|
||||
|
||||
User->>BMAD: Request
|
||||
BMAD->>BMAD: Apply Template
|
||||
BMAD->>BMAD: Add Context
|
||||
BMAD->>BMAD: Select Persona
|
||||
BMAD->>LLM: Structured Prompt
|
||||
LLM->>BMAD: Response
|
||||
BMAD->>User: Formatted Output
|
||||
```
|
||||
|
||||
### 2. File-Based Integration
|
||||
|
||||
```mermaid title="File-Based Integration Pattern" type="diagram"
|
||||
graph TD
|
||||
A[BMAD Templates] --> B[Generated Files]
|
||||
B --> C[Version Control]
|
||||
C --> D[Documentation System]
|
||||
D --> E[Team Access]
|
||||
```
|
||||
|
||||
### 3. Methodology-Driven Integration
|
||||
|
||||
```mermaid title="Methodology Integration Pattern" type="diagram"
|
||||
flowchart LR
|
||||
A[BMAD Method] --> B[Documentation Loading]
|
||||
B --> C[Context Preparation]
|
||||
C --> D[Prompt Structuring]
|
||||
D --> E[Quality Validation]
|
||||
```
|
||||
|
||||
## Implementation Approaches
|
||||
|
||||
There are several approaches to implementing BMAD Method integrations:
|
||||
|
||||
### 1. Direct Methodology Application
|
||||
- Manually applying BMAD Method principles to LLM interactions
|
||||
- Loading persona documentation into AI assistant context
|
||||
- Following structured workflows and templates
|
||||
|
||||
### 2. Documentation-Based Integration
|
||||
- Using BMAD templates as starting points
|
||||
- Referencing checklists for quality validation
|
||||
- Following persona-specific guidelines
|
||||
|
||||
### 3. Workflow Integration
|
||||
- Incorporating BMAD patterns into existing development processes
|
||||
- Using BMAD personas for specific project phases
|
||||
- Applying BMAD quality standards to deliverables
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Context Management
|
||||
- Load relevant persona documentation before starting tasks
|
||||
- Maintain consistent context throughout project phases
|
||||
- Reference appropriate templates and checklists
|
||||
|
||||
### Quality Assurance
|
||||
- Use BMAD quality checklists for validation
|
||||
- Follow persona-specific quality standards
|
||||
- Conduct regular methodology compliance reviews
|
||||
|
||||
### Team Collaboration
|
||||
- Share BMAD documentation across team members
|
||||
- Establish common understanding of persona roles
|
||||
- Maintain consistent methodology application
|
||||
|
||||
## Troubleshooting Common Integration Issues
|
||||
|
||||
### Context Loss
|
||||
**Problem**: AI assistant loses BMAD context during long sessions
|
||||
**Solution**: Regularly reload persona documentation and reference key templates
|
||||
|
||||
### Inconsistent Output
|
||||
**Problem**: Generated content doesn't follow BMAD standards
|
||||
**Solution**: Use specific persona prompts and reference quality checklists
|
||||
|
||||
### Workflow Confusion
|
||||
**Problem**: Unclear which persona to use for specific tasks
|
||||
**Solution**: Reference the persona selection guide and task mappings
|
||||
|
||||
## Conclusion
|
||||
|
||||
The BMAD Method's integration architecture is designed to be flexible and adaptable, allowing it to work with a wide range of tools and platforms through methodology-driven approaches. By focusing on structured prompts, standardized templates, and clear workflows, the BMAD Method can be integrated into existing development processes with minimal friction.
|
||||
|
||||
The key to successful integration is understanding that BMAD is a methodology framework rather than a software application, and its value comes from consistent application of its principles and patterns rather than technical installation or configuration.
|
||||
|
|
@ -0,0 +1,374 @@
|
|||
# BMAD System Overview
|
||||
|
||||
This document provides a high-level overview of the BMAD system architecture, focusing on the major components and their interactions.
|
||||
|
||||
## System Context
|
||||
|
||||
\```mermaid title="BMAD System Context Diagram" type="diagram"
|
||||
graph TB
|
||||
subgraph "External Systems"
|
||||
USERS[Users]
|
||||
IDE_SYS[IDE Systems]
|
||||
VCS[Version Control]
|
||||
PM_TOOLS[Project Management Tools]
|
||||
COMM[Communication Platforms]
|
||||
end
|
||||
|
||||
subgraph "BMAD System"
|
||||
BMAD[BMAD Platform]
|
||||
end
|
||||
|
||||
subgraph "Infrastructure"
|
||||
CLOUD[Cloud Services]
|
||||
DB[Databases]
|
||||
STORAGE[File Storage]
|
||||
MONITOR[Monitoring]
|
||||
end
|
||||
|
||||
USERS --> BMAD
|
||||
IDE_SYS --> BMAD
|
||||
BMAD --> VCS
|
||||
BMAD --> PM_TOOLS
|
||||
BMAD --> COMM
|
||||
|
||||
BMAD --> CLOUD
|
||||
BMAD --> DB
|
||||
BMAD --> STORAGE
|
||||
BMAD --> MONITOR
|
||||
\```
|
||||
|
||||
## High-Level Architecture
|
||||
|
||||
\```mermaid title="BMAD High-Level Architecture" type="diagram"
|
||||
graph TB
|
||||
subgraph "User Interfaces"
|
||||
WEB_UI[Web Interface]
|
||||
IDE_EXT[IDE Extensions]
|
||||
CLI_TOOL[CLI Tools]
|
||||
API_GW[API Gateway]
|
||||
end
|
||||
|
||||
subgraph "Core Platform"
|
||||
ORCHESTRATOR[Orchestrator Engine]
|
||||
|
||||
subgraph "Persona System"
|
||||
PM_PERSONA[PM Persona]
|
||||
ARCH_PERSONA[Architect Persona]
|
||||
UX_PERSONA[UX/UI Persona]
|
||||
DEV_PERSONA[Developer Persona]
|
||||
BA_PERSONA[Business Analyst]
|
||||
end
|
||||
|
||||
subgraph "Processing Engines"
|
||||
TASK_ENGINE[Task Engine]
|
||||
TEMPLATE_ENGINE[Template Engine]
|
||||
VALIDATION_ENGINE[Validation Engine]
|
||||
end
|
||||
end
|
||||
|
||||
subgraph "Data & Knowledge"
|
||||
KNOWLEDGE_BASE[Knowledge Base]
|
||||
TEMPLATES[Templates]
|
||||
CHECKLISTS[Checklists]
|
||||
CONFIG[Configuration]
|
||||
end
|
||||
|
||||
subgraph "External Integrations"
|
||||
GIT_INT[Git Integration]
|
||||
JIRA_INT[Jira Integration]
|
||||
SLACK_INT[Slack Integration]
|
||||
AI_SERVICES[AI Services]
|
||||
end
|
||||
|
||||
WEB_UI --> ORCHESTRATOR
|
||||
IDE_EXT --> ORCHESTRATOR
|
||||
CLI_TOOL --> ORCHESTRATOR
|
||||
API_GW --> ORCHESTRATOR
|
||||
|
||||
ORCHESTRATOR --> PM_PERSONA
|
||||
ORCHESTRATOR --> ARCH_PERSONA
|
||||
ORCHESTRATOR --> UX_PERSONA
|
||||
ORCHESTRATOR --> DEV_PERSONA
|
||||
ORCHESTRATOR --> BA_PERSONA
|
||||
|
||||
PM_PERSONA --> TASK_ENGINE
|
||||
ARCH_PERSONA --> TASK_ENGINE
|
||||
UX_PERSONA --> TASK_ENGINE
|
||||
DEV_PERSONA --> TASK_ENGINE
|
||||
BA_PERSONA --> TASK_ENGINE
|
||||
|
||||
TASK_ENGINE --> TEMPLATE_ENGINE
|
||||
TEMPLATE_ENGINE --> VALIDATION_ENGINE
|
||||
|
||||
VALIDATION_ENGINE --> KNOWLEDGE_BASE
|
||||
TEMPLATE_ENGINE --> TEMPLATES
|
||||
TASK_ENGINE --> CHECKLISTS
|
||||
ORCHESTRATOR --> CONFIG
|
||||
|
||||
ORCHESTRATOR --> GIT_INT
|
||||
ORCHESTRATOR --> JIRA_INT
|
||||
ORCHESTRATOR --> SLACK_INT
|
||||
ORCHESTRATOR --> AI_SERVICES
|
||||
\```
|
||||
|
||||
## Core Components
|
||||
|
||||
### 1. Orchestrator Engine
|
||||
**Purpose**: Central coordination and decision-making hub
|
||||
|
||||
**Key Responsibilities:**
|
||||
- Request analysis and routing
|
||||
- Persona selection and coordination
|
||||
- Context management and state tracking
|
||||
- Quality assurance and validation
|
||||
- Integration management
|
||||
|
||||
**Key Features:**
|
||||
- Natural language processing
|
||||
- Context-aware decision making
|
||||
- Multi-persona coordination
|
||||
- Real-time status tracking
|
||||
- Automated quality gates
|
||||
|
||||
### 2. Persona System
|
||||
**Purpose**: Specialized AI agents for different domains
|
||||
|
||||
**Available Personas:**
|
||||
- **Project Manager (PM)**: Project planning and coordination
|
||||
- **System Architect**: Technical architecture and design
|
||||
- **UX/UI Designer**: User experience and interface design
|
||||
- **Developer**: Code implementation and technical tasks
|
||||
- **Business Analyst**: Requirements and process analysis
|
||||
|
||||
**Key Features:**
|
||||
- Domain-specific expertise
|
||||
- Consistent behavior patterns
|
||||
- Template-driven outputs
|
||||
- Context awareness
|
||||
- Quality validation
|
||||
|
||||
### 3. Processing Engines
|
||||
|
||||
#### Task Engine
|
||||
- Task decomposition and execution
|
||||
- Dependency management
|
||||
- Progress tracking
|
||||
- Error handling and recovery
|
||||
|
||||
#### Template Engine
|
||||
- Dynamic content generation
|
||||
- Variable substitution
|
||||
- Format standardization
|
||||
- Multi-format output support
|
||||
|
||||
#### Validation Engine
|
||||
- Quality assurance checks
|
||||
- Compliance validation
|
||||
- Completeness verification
|
||||
- Best practice enforcement
|
||||
|
||||
### 4. Data & Knowledge Layer
|
||||
|
||||
#### Knowledge Base
|
||||
- Project context and history
|
||||
- Best practices and guidelines
|
||||
- Domain-specific knowledge
|
||||
- Learning and adaptation data
|
||||
|
||||
#### Templates
|
||||
- Document templates
|
||||
- Code templates
|
||||
- Process templates
|
||||
- Customizable formats
|
||||
|
||||
#### Checklists
|
||||
- Quality assurance checklists
|
||||
- Process validation checklists
|
||||
- Compliance checklists
|
||||
- Custom validation rules
|
||||
|
||||
## System Interactions
|
||||
|
||||
### 1. User Request Flow
|
||||
|
||||
\```mermaid title="User Request Processing Flow" type="diagram"
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant Interface
|
||||
participant Orchestrator
|
||||
participant Persona
|
||||
participant Engine
|
||||
participant Data
|
||||
|
||||
User->>Interface: Submit Request
|
||||
Interface->>Orchestrator: Parse & Route Request
|
||||
Orchestrator->>Orchestrator: Analyze Context
|
||||
Orchestrator->>Persona: Select & Activate
|
||||
Persona->>Engine: Execute Task
|
||||
Engine->>Data: Retrieve Templates/Data
|
||||
Data->>Engine: Return Resources
|
||||
Engine->>Persona: Generate Output
|
||||
Persona->>Orchestrator: Return Results
|
||||
Orchestrator->>Interface: Format Response
|
||||
Interface->>User: Deliver Results
|
||||
\```
|
||||
|
||||
### 2. Multi-Persona Collaboration
|
||||
|
||||
\```mermaid title="Multi-Persona Collaboration Flow" type="diagram"
|
||||
sequenceDiagram
|
||||
participant Orchestrator
|
||||
participant PM_Persona
|
||||
participant Arch_Persona
|
||||
participant UX_Persona
|
||||
participant Dev_Persona
|
||||
|
||||
Orchestrator->>PM_Persona: Create Project Plan
|
||||
PM_Persona->>Orchestrator: Return Plan
|
||||
Orchestrator->>Arch_Persona: Design Architecture
|
||||
Arch_Persona->>Orchestrator: Return Architecture
|
||||
Orchestrator->>UX_Persona: Create UI Design
|
||||
UX_Persona->>Orchestrator: Return Design
|
||||
Orchestrator->>Dev_Persona: Implement Solution
|
||||
Dev_Persona->>Orchestrator: Return Implementation
|
||||
Orchestrator->>Orchestrator: Integrate Results
|
||||
\```
|
||||
|
||||
## Deployment Architecture
|
||||
|
||||
### 1. Environment Types
|
||||
|
||||
**Development Environment:**
|
||||
- Local development setup
|
||||
- IDE integration focus
|
||||
- Rapid iteration support
|
||||
- Debug and testing tools
|
||||
|
||||
**Staging Environment:**
|
||||
- Production-like configuration
|
||||
- Integration testing
|
||||
- Performance validation
|
||||
- User acceptance testing
|
||||
|
||||
**Production Environment:**
|
||||
- High availability setup
|
||||
- Scalable infrastructure
|
||||
- Monitoring and alerting
|
||||
- Backup and recovery
|
||||
|
||||
### 2. Infrastructure Components
|
||||
|
||||
\```mermaid title="Infrastructure Architecture" type="diagram"
|
||||
graph TB
|
||||
subgraph "Load Balancing"
|
||||
LB[Load Balancer]
|
||||
CDN[Content Delivery Network]
|
||||
end
|
||||
|
||||
subgraph "Application Tier"
|
||||
APP1[App Server 1]
|
||||
APP2[App Server 2]
|
||||
APP3[App Server 3]
|
||||
end
|
||||
|
||||
subgraph "Data Tier"
|
||||
DB_PRIMARY[Primary Database]
|
||||
DB_REPLICA[Read Replica]
|
||||
CACHE[Redis Cache]
|
||||
SEARCH[Elasticsearch]
|
||||
end
|
||||
|
||||
subgraph "Storage"
|
||||
FILE_STORAGE[File Storage]
|
||||
BACKUP[Backup Storage]
|
||||
end
|
||||
|
||||
subgraph "Monitoring"
|
||||
METRICS[Metrics Collection]
|
||||
LOGS[Log Aggregation]
|
||||
ALERTS[Alerting System]
|
||||
end
|
||||
|
||||
LB --> APP1
|
||||
LB --> APP2
|
||||
LB --> APP3
|
||||
|
||||
APP1 --> DB_PRIMARY
|
||||
APP2 --> DB_REPLICA
|
||||
APP3 --> CACHE
|
||||
|
||||
APP1 --> SEARCH
|
||||
APP2 --> FILE_STORAGE
|
||||
|
||||
DB_PRIMARY --> BACKUP
|
||||
FILE_STORAGE --> BACKUP
|
||||
|
||||
APP1 --> METRICS
|
||||
APP2 --> LOGS
|
||||
APP3 --> ALERTS
|
||||
\```
|
||||
|
||||
## Quality Attributes
|
||||
|
||||
### 1. Performance
|
||||
- **Response Time**: Sub-second for simple operations
|
||||
- **Throughput**: 10,000+ concurrent operations
|
||||
- **Scalability**: Horizontal scaling capability
|
||||
- **Resource Efficiency**: Optimized memory and CPU usage
|
||||
|
||||
### 2. Reliability
|
||||
- **Availability**: 99.9% uptime target
|
||||
- **Fault Tolerance**: Graceful degradation
|
||||
- **Recovery**: Automated failure recovery
|
||||
- **Data Integrity**: ACID compliance where needed
|
||||
|
||||
### 3. Security
|
||||
- **Authentication**: Multi-factor authentication
|
||||
- **Authorization**: Role-based access control
|
||||
- **Data Protection**: Encryption at rest and in transit
|
||||
- **Audit Trail**: Complete activity logging
|
||||
|
||||
### 4. Maintainability
|
||||
- **Modularity**: Loosely coupled components
|
||||
- **Testability**: Comprehensive test coverage
|
||||
- **Monitoring**: Real-time system health monitoring
|
||||
- **Documentation**: Complete technical documentation
|
||||
|
||||
## Technology Stack
|
||||
|
||||
### Frontend Technologies
|
||||
- **Web Interface**: React.js, TypeScript, Tailwind CSS
|
||||
- **IDE Extensions**: VS Code API, Language Server Protocol
|
||||
- **Mobile**: Progressive Web App (PWA)
|
||||
|
||||
### Backend Technologies
|
||||
- **API Layer**: Node.js, Express.js, GraphQL
|
||||
- **Processing**: Python, TensorFlow, OpenAI API
|
||||
- **Database**: PostgreSQL, Redis, Elasticsearch
|
||||
- **Message Queue**: RabbitMQ, Apache Kafka
|
||||
|
||||
### Infrastructure
|
||||
- **Cloud Platform**: AWS, Azure, or Google Cloud
|
||||
- **Containerization**: Docker, Kubernetes
|
||||
- **CI/CD**: GitHub Actions, Jenkins
|
||||
- **Monitoring**: Prometheus, Grafana, ELK Stack
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Deep Dive Components**: Review [Component Architecture](component-architecture.md)
|
||||
2. **Understand Data Flow**: Study [Data Flow Diagrams](data-flow-diagrams.md)
|
||||
3. **Plan Integrations**: Examine [Integration Architecture](integration-architecture.md)
|
||||
4. **Design Deployment**: Review [Deployment Architecture](deployment-architecture.md)
|
||||
|
||||
---
|
||||
|
||||
*This system overview provides the foundation for understanding the BMAD platform architecture and its key components.*
|
||||
|
||||
**Story 2.2 Progress Update:**
|
||||
- ✅ Created `docs/system-architecture/README.md` - Architecture documentation overview
|
||||
- ✅ Created `docs/system-architecture/system-overview.md` - High-level system architecture
|
||||
- 🔄 **In Progress**: Need to create remaining architecture documents
|
||||
|
||||
**Story 2.2 Status**: 25% complete (2/8 points)
|
||||
|
||||
Should I continue with the remaining architecture documents (component-architecture.md, data-flow-diagrams.md, integration-architecture.md, deployment-architecture.md) to complete Story 2.2?
|
||||
|
|
@ -0,0 +1,78 @@
|
|||
# BMAD Method User Journeys
|
||||
|
||||
This section provides comprehensive documentation of user journeys through the BMAD Method, helping product managers and stakeholders understand the complete user experience.
|
||||
|
||||
## Overview
|
||||
|
||||
User journeys map the complete path that different users take when interacting with the BMAD Method. These journeys illustrate:
|
||||
|
||||
- Entry points and initial interactions
|
||||
- Key decision points and actions
|
||||
- Transitions between personas
|
||||
- Pain points and their solutions
|
||||
- Success metrics and outcomes
|
||||
|
||||
## Available User Journeys
|
||||
|
||||
| Journey | Primary User | Focus | Complexity |
|
||||
|---------|-------------|-------|------------|
|
||||
| [First-Time Setup](first-time-setup.md) | New User | Initial configuration | Low |
|
||||
| [Project Initiation](project-initiation.md) | Product Owner | Starting a new project | Medium |
|
||||
| [Feature Development](feature-development.md) | Developer | Implementing features | High |
|
||||
| [Design System Creation](design-system-creation.md) | UX/UI Architect | Building design systems | High |
|
||||
| [Architecture Planning](architecture-planning.md) | System Architect | Technical planning | High |
|
||||
|
||||
## Journey Map Components
|
||||
|
||||
Each user journey includes:
|
||||
|
||||
1. **Persona Profile**: Who is taking this journey
|
||||
2. **Goals and Motivations**: What the user wants to accomplish
|
||||
3. **Entry Points**: How the user begins their journey
|
||||
4. **Journey Stages**: Sequential phases of interaction
|
||||
5. **Touchpoints**: Specific interaction moments
|
||||
6. **Decision Points**: Where users make choices
|
||||
7. **Pain Points**: Challenges users may face
|
||||
8. **Solutions**: How to address pain points
|
||||
9. **Success Metrics**: How to measure journey success
|
||||
|
||||
## How to Use These Journey Maps
|
||||
|
||||
### For Product Managers
|
||||
- Understand the complete user experience
|
||||
- Identify opportunities for improvement
|
||||
- Prioritize enhancements based on pain points
|
||||
- Communicate user needs to stakeholders
|
||||
|
||||
### For Developers
|
||||
- Understand the context of feature requests
|
||||
- See how your work fits into the larger user experience
|
||||
- Identify integration points and dependencies
|
||||
|
||||
### For UX/UI Designers
|
||||
- Identify key interaction moments
|
||||
- Understand emotional states throughout the journey
|
||||
- Design for pain points and decision moments
|
||||
|
||||
## Journey Visualization Guide
|
||||
|
||||
Our journey maps use consistent visual language:
|
||||
|
||||
- **Green**: Positive experiences and emotions
|
||||
- **Yellow**: Neutral or transitional moments
|
||||
- **Red**: Pain points or challenges
|
||||
- **Stars**: Key decision points
|
||||
- **Diamonds**: Success metrics
|
||||
- **Circles**: Touchpoints with the system
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. Review the [First-Time Setup](first-time-setup.md) journey to understand the onboarding experience
|
||||
2. Explore [Project Initiation](project-initiation.md) to see how projects begin
|
||||
3. Examine [Feature Development](feature-development.md) for the core development workflow
|
||||
4. Analyze [Design System Creation](design-system-creation.md) for UX/UI processes
|
||||
5. Study [Architecture Planning](architecture-planning.md) for technical planning workflows
|
||||
|
||||
---
|
||||
|
||||
*Understanding user journeys is essential for optimizing the BMAD Method experience and ensuring it meets user needs effectively.*
|
||||
|
|
@ -0,0 +1,183 @@
|
|||
# Architecture Planning Journey
|
||||
|
||||
This document maps the complete journey of a System Architect planning technical architecture using the BMAD Method.
|
||||
|
||||
## Persona Profile: System Architect
|
||||
|
||||
**Name**: Alex (System Architect)
|
||||
**Role**: Technical Architect / Solutions Architect
|
||||
**Experience**: 8+ years in software architecture
|
||||
**Goals**:
|
||||
- Design scalable, maintainable system architecture
|
||||
- Make optimal technology selections
|
||||
- Establish technical standards and patterns
|
||||
- Ensure alignment between business needs and technical solutions
|
||||
|
||||
**Pain Points**:
|
||||
- Balancing innovation with stability
|
||||
- Managing technical debt
|
||||
- Communicating complex concepts to non-technical stakeholders
|
||||
- Ensuring security and compliance requirements
|
||||
|
||||
## Journey Map
|
||||
|
||||
\```mermaid title="Architecture Planning Journey" type="diagram"
|
||||
journey
|
||||
title Architecture Planning User Journey
|
||||
section Requirements Analysis
|
||||
Gather business requirements: 3
|
||||
Analyze technical constraints: 3
|
||||
Define quality attributes: 4
|
||||
section Architecture Design
|
||||
Evaluate technology options: 4
|
||||
Design system components: 5
|
||||
Plan integration patterns: 3
|
||||
section Validation
|
||||
Review with stakeholders: 2
|
||||
Conduct technical validation: 4
|
||||
Refine architecture: 3
|
||||
section Implementation Planning
|
||||
Create implementation roadmap: 4
|
||||
Develop technical standards: 3
|
||||
Prepare knowledge transfer: 4
|
||||
\```
|
||||
|
||||
## Detailed Journey Stages
|
||||
|
||||
### 1. Requirements Analysis Phase
|
||||
|
||||
#### Entry Point
|
||||
- New system development initiative
|
||||
- Major system enhancement
|
||||
- Technical debt remediation project
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Requirements Analysis Template**: Structured approach to gathering needs
|
||||
- **BMAD Architect Persona**: Guidance on architectural approach
|
||||
- **Quality Attributes Framework**: Defining non-functional requirements
|
||||
|
||||
#### Decision Points
|
||||
- â **Architecture Scope**: Determining boundaries and focus areas
|
||||
- **Solution**: Scope definition matrix with priority weighting
|
||||
- **Success Metric**: Architecture addresses 100% of critical requirements
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Incomplete Business Requirements**: Missing or ambiguous needs
|
||||
- **Solution**: Requirement elicitation workshop templates
|
||||
- **Success Metric**: Zero major requirement discoveries after design phase
|
||||
- 🔴 **Competing Quality Attributes**: Balancing performance, security, etc.
|
||||
- **Solution**: Trade-off analysis framework
|
||||
- **Success Metric**: Documented rationale for all architectural decisions
|
||||
|
||||
### 2. Architecture Design Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Technology Evaluation**: Assessing potential technologies
|
||||
- **Component Design**: Defining system building blocks
|
||||
- **Integration Architecture**: Planning system connections
|
||||
|
||||
#### Decision Points
|
||||
- â **Technology Selection**: Choosing appropriate tech stack
|
||||
- **Solution**: Technology comparison matrix with weighted criteria
|
||||
- **Success Metric**: Selected technologies meet all critical requirements
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Future-Proofing**: Designing for unknown future needs
|
||||
- **Solution**: Extensibility pattern library
|
||||
- **Success Metric**: Architecture accommodates changes with minimal rework
|
||||
- 🔴 **Legacy Integration**: Working with existing systems
|
||||
- **Solution**: Legacy integration pattern catalog
|
||||
- **Success Metric**: Seamless integration with all required systems
|
||||
|
||||
### 3. Validation Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Stakeholder Review**: Presenting architecture to business stakeholders
|
||||
- **Technical Validation**: Ensuring technical soundness
|
||||
- **Architecture Refinement**: Incorporating feedback
|
||||
|
||||
#### Decision Points
|
||||
- â **Validation Approach**: Choosing appropriate validation methods
|
||||
- **Solution**: Validation strategy selector based on project type
|
||||
- **Success Metric**: Zero critical issues discovered after validation
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Communicating Technical Concepts**: Explaining to non-technical audience
|
||||
- **Solution**: Visualization templates for different stakeholder types
|
||||
- **Success Metric**: Stakeholder comprehension rating above 4/5
|
||||
- 🔴 **Addressing Feedback**: Balancing conflicting stakeholder input
|
||||
- **Solution**: Feedback prioritization framework
|
||||
- **Success Metric**: All critical feedback incorporated into final design
|
||||
|
||||
### 4. Implementation Planning Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Implementation Roadmap**: Phased execution plan
|
||||
- **Technical Standards**: Guidelines for development
|
||||
- **Knowledge Transfer**: Educating implementation team
|
||||
|
||||
#### Decision Points
|
||||
- â **Implementation Approach**: Big bang vs. incremental deployment
|
||||
- **Solution**: Implementation strategy decision tree
|
||||
- **Success Metric**: Zero business disruption during implementation
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Resource Constraints**: Limited implementation resources
|
||||
- **Solution**: Resource optimization planning tool
|
||||
- **Success Metric**: Implementation plan feasible with available resources
|
||||
- 🔴 **Knowledge Transfer**: Ensuring development team understanding
|
||||
- **Solution**: Architecture training program template
|
||||
- **Success Metric**: Development team confidence rating above 4/5
|
||||
|
||||
## Emotional Journey
|
||||
|
||||
\```mermaid title="Emotional Journey" type="diagram"
|
||||
journey
|
||||
title Emotional Journey - Architecture Planning
|
||||
section Requirements Analysis
|
||||
Interest in problem space: 4
|
||||
Concern about requirement clarity: 2
|
||||
Confidence after analysis: 4
|
||||
section Architecture Design
|
||||
Creative engagement: 5
|
||||
Stress over technical decisions: 3
|
||||
Satisfaction with design: 4
|
||||
section Validation
|
||||
Anxiety during stakeholder review: 2
|
||||
Relief after technical validation: 4
|
||||
Pride in refined architecture: 5
|
||||
section Implementation Planning
|
||||
Concern about execution challenges: 3
|
||||
Focus during standards development: 4
|
||||
Optimism about implementation: 4
|
||||
\```
|
||||
|
||||
## Success Metrics
|
||||
|
||||
| Metric | Target | Measurement Method |
|
||||
|--------|--------|-------------------|
|
||||
| Requirements Coverage | 100% of critical requirements | Traceability matrix |
|
||||
| Stakeholder Approval | Unanimous approval | Sign-off tracking |
|
||||
| Technical Debt | < 10% of planned debt | Architecture debt analysis |
|
||||
| Implementation Feasibility | 100% achievable with resources | Resource planning validation |
|
||||
| Architecture Longevity | > 3 years before major revision | Architecture review cycles |
|
||||
|
||||
## Journey Optimization Opportunities
|
||||
|
||||
1. **AI-Enhanced Requirements Analysis**: Identify missing requirements automatically
|
||||
2. **Architecture Pattern Library**: Accelerate design with proven patterns
|
||||
3. **Automated Architecture Validation**: Verify design against best practices
|
||||
4. **Interactive Architecture Visualization**: Improve stakeholder understanding
|
||||
5. **Implementation Simulation**: Test architecture before development begins
|
||||
|
||||
## Next Steps in User Journey
|
||||
|
||||
After completing the architecture planning journey, System Architects typically proceed to:
|
||||
|
||||
1. [Implementation Guidance Journey](implementation-guidance.md) - Supporting development teams
|
||||
2. [Architecture Evolution Journey](architecture-evolution.md) - Managing architectural changes
|
||||
3. [Technical Debt Management Journey](technical-debt-management.md) - Addressing architectural debt
|
||||
|
||||
---
|
||||
|
||||
*The architecture planning journey establishes the technical foundation for successful system implementation and long-term sustainability.*
|
||||
|
|
@ -0,0 +1,183 @@
|
|||
# Design System Creation Journey
|
||||
|
||||
This document maps the complete journey of a UX/UI Architect creating a design system using the BMAD Method.
|
||||
|
||||
## Persona Profile: UX/UI Architect
|
||||
|
||||
**Name**: Veronica (UX/UI Architect)
|
||||
**Role**: UX/UI Designer and Frontend Architect
|
||||
**Experience**: 6+ years in design systems and frontend architecture
|
||||
**Goals**:
|
||||
- Create a cohesive, scalable design system
|
||||
- Establish consistent user experience patterns
|
||||
- Develop reusable component library
|
||||
- Document design standards for team adoption
|
||||
|
||||
**Pain Points**:
|
||||
- Balancing flexibility with consistency
|
||||
- Ensuring technical feasibility of designs
|
||||
- Maintaining design system over time
|
||||
- Driving adoption across development teams
|
||||
|
||||
## Journey Map
|
||||
|
||||
\```mermaid title="Design System Creation Journey" type="diagram"
|
||||
journey
|
||||
title Design System Creation User Journey
|
||||
section Research & Planning
|
||||
Audit existing interfaces: 3
|
||||
Define design principles: 4
|
||||
Establish design tokens: 4
|
||||
section Core System Development
|
||||
Create visual language: 5
|
||||
Design foundational components: 4
|
||||
Develop component specifications: 3
|
||||
section Implementation
|
||||
Build component library: 4
|
||||
Create documentation: 3
|
||||
Develop usage guidelines: 4
|
||||
section Adoption & Maintenance
|
||||
Train development teams: 3
|
||||
Monitor implementation: 2
|
||||
Iterate based on feedback: 4
|
||||
\```
|
||||
|
||||
## Detailed Journey Stages
|
||||
|
||||
### 1. Research & Planning Phase
|
||||
|
||||
#### Entry Point
|
||||
- New product development initiative
|
||||
- Redesign of existing product
|
||||
- Consolidation of multiple product interfaces
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Interface Audit Template**: Systematic review of existing designs
|
||||
- **BMAD UX/UI Architect Persona**: Guidance on design system strategy
|
||||
- **Design Principles Framework**: Establishing core design values
|
||||
|
||||
#### Decision Points
|
||||
- â **Design System Scope**: Determining breadth and depth of system
|
||||
- **Solution**: Scope definition worksheet with prioritization matrix
|
||||
- **Success Metric**: 95% of common UI patterns covered in initial release
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Inconsistent Existing Patterns**: Conflicting designs across products
|
||||
- **Solution**: Pattern reconciliation methodology
|
||||
- **Success Metric**: Consolidated pattern library with clear migration path
|
||||
- 🔴 **Stakeholder Alignment**: Differing opinions on visual direction
|
||||
- **Solution**: Design direction workshop templates
|
||||
- **Success Metric**: Unanimous approval of design principles
|
||||
|
||||
### 2. Core System Development Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Visual Language Definition**: Color, typography, spacing, and imagery
|
||||
- **Component Design Process**: Creating foundational UI elements
|
||||
- **Specification Documentation**: Detailed component requirements
|
||||
|
||||
#### Decision Points
|
||||
- â **Component Granularity**: Atomic vs. composite component approach
|
||||
- **Solution**: Component hierarchy planning framework
|
||||
- **Success Metric**: 80% of interfaces buildable from component library
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Technical Feasibility**: Ensuring designs can be implemented efficiently
|
||||
- **Solution**: Developer collaboration workflow
|
||||
- **Success Metric**: Zero components rejected for technical limitations
|
||||
- 🔴 **Accessibility Compliance**: Meeting accessibility standards
|
||||
- **Solution**: Accessibility checklist and testing protocol
|
||||
- **Success Metric**: 100% WCAG AA compliance for all components
|
||||
|
||||
### 3. Implementation Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Component Library Development**: Building functional components
|
||||
- **Documentation System**: Creating comprehensive guides
|
||||
- **Usage Guidelines**: Establishing implementation standards
|
||||
|
||||
#### Decision Points
|
||||
- â **Technology Stack**: Selecting frontend framework and tools
|
||||
- **Solution**: Technology evaluation framework
|
||||
- **Success Metric**: Component library compatible with all project requirements
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Documentation Thoroughness**: Balancing detail with usability
|
||||
- **Solution**: Tiered documentation approach (quick start to deep dive)
|
||||
- **Success Metric**: 90% of implementation questions answerable from docs
|
||||
- 🔴 **Component Flexibility**: Making components adaptable without fragmentation
|
||||
- **Solution**: Prop structure and theming system guidelines
|
||||
- **Success Metric**: Components adaptable to all required use cases
|
||||
|
||||
### 4. Adoption & Maintenance Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Training Program**: Educating teams on design system use
|
||||
- **Implementation Monitoring**: Tracking adoption and consistency
|
||||
- **Feedback Collection**: Gathering input for improvements
|
||||
|
||||
#### Decision Points
|
||||
- â **Versioning Strategy**: Managing updates and breaking changes
|
||||
- **Solution**: Semantic versioning policy with migration guides
|
||||
- **Success Metric**: Zero production disruptions from design system updates
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Resistance to Adoption**: Teams preferring custom implementations
|
||||
- **Solution**: Adoption incentive program and success metrics
|
||||
- **Success Metric**: 90% adoption rate across new development
|
||||
- 🔴 **System Maintenance**: Keeping system updated and relevant
|
||||
- **Solution**: Maintenance schedule and governance model
|
||||
- **Success Metric**: Design system updates released quarterly
|
||||
|
||||
## Emotional Journey
|
||||
|
||||
\```mermaid title="Emotional Journey" type="diagram"
|
||||
journey
|
||||
title Emotional Journey - Design System Creation
|
||||
section Research & Planning
|
||||
Excitement about possibilities: 5
|
||||
Overwhelmed by existing inconsistencies: 2
|
||||
Clarity after establishing principles: 4
|
||||
section Core System Development
|
||||
Creative fulfillment: 5
|
||||
Frustration with edge cases: 3
|
||||
Pride in cohesive system: 5
|
||||
section Implementation
|
||||
Technical challenges: 2
|
||||
Documentation fatigue: 2
|
||||
Satisfaction with working library: 4
|
||||
section Adoption & Maintenance
|
||||
Anxiety about team reception: 3
|
||||
Disappointment with partial adoption: 2
|
||||
Fulfillment seeing system in use: 5
|
||||
\```
|
||||
|
||||
## Success Metrics
|
||||
|
||||
| Metric | Target | Measurement Method |
|
||||
|--------|--------|-------------------|
|
||||
| Component Coverage | > 90% of UI needs | Interface audit analysis |
|
||||
| Implementation Time | 50% reduction | Development time tracking |
|
||||
| Design Consistency | > 95% compliance | Automated visual testing |
|
||||
| Developer Satisfaction | > 4.5/5 rating | Team surveys |
|
||||
| Maintenance Efficiency | < 4 hours/week | Time tracking analysis |
|
||||
|
||||
## Journey Optimization Opportunities
|
||||
|
||||
1. **AI-Generated Component Variations**: Accelerate creation of component states
|
||||
2. **Automated Accessibility Testing**: Ensure compliance throughout development
|
||||
3. **Usage Analytics Dashboard**: Track component adoption and implementation
|
||||
4. **Interactive Documentation**: Improve learning curve with interactive examples
|
||||
5. **Design Token Automation**: Streamline theme creation and management
|
||||
|
||||
## Next Steps in User Journey
|
||||
|
||||
After completing the design system creation journey, UX/UI Architects typically proceed to:
|
||||
|
||||
1. [Component Enhancement Journey](component-enhancement.md) - Expanding the component library
|
||||
2. [Design System Evolution Journey](design-system-evolution.md) - Managing system growth
|
||||
3. [Cross-Platform Adaptation Journey](cross-platform-adaptation.md) - Extending to mobile and other platforms
|
||||
|
||||
---
|
||||
|
||||
*The design system creation journey establishes the foundation for consistent, efficient user interface development across products.*
|
||||
|
|
@ -0,0 +1,186 @@
|
|||
# Feature Development Journey
|
||||
|
||||
This document maps the complete journey of a Developer implementing features using the BMAD Method.
|
||||
|
||||
## Persona Profile: Developer
|
||||
|
||||
**Name**: David (Developer)
|
||||
**Role**: Full-Stack Developer
|
||||
**Experience**: 4+ years in software development
|
||||
**Goals**:
|
||||
- Understand feature requirements clearly
|
||||
- Implement high-quality code efficiently
|
||||
- Integrate with existing systems seamlessly
|
||||
- Meet acceptance criteria and deadlines
|
||||
|
||||
**Pain Points**:
|
||||
- Ambiguous or changing requirements
|
||||
- Technical debt and legacy code constraints
|
||||
- Integration challenges with external systems
|
||||
- Balancing quality with delivery timelines
|
||||
|
||||
## Journey Map
|
||||
|
||||
\```mermaid title="Feature Development Journey" type="diagram"
|
||||
journey
|
||||
title Feature Development User Journey
|
||||
section Preparation
|
||||
Receive feature assignment: 3
|
||||
Review requirements: 3
|
||||
Plan implementation approach: 4
|
||||
section Development
|
||||
Set up development environment: 3
|
||||
Implement core functionality: 4
|
||||
Write tests: 3
|
||||
Refactor and optimize: 4
|
||||
section Validation
|
||||
Self-review code: 4
|
||||
Run quality checks: 3
|
||||
Fix identified issues: 3
|
||||
section Delivery
|
||||
Submit for review: 2
|
||||
Address feedback: 3
|
||||
Complete documentation: 4
|
||||
Merge and deploy: 5
|
||||
\```
|
||||
|
||||
## Detailed Journey Stages
|
||||
|
||||
### 1. Preparation Phase
|
||||
|
||||
#### Entry Point
|
||||
- Feature assignment from sprint planning
|
||||
- Task from project management system
|
||||
- Bug fix or enhancement request
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Feature Specification**: Detailed requirements document
|
||||
- **BMAD Developer Persona**: Guidance on implementation approach
|
||||
- **Technical Design Document**: Architecture and integration details
|
||||
|
||||
#### Decision Points
|
||||
- â **Implementation Approach**: Choosing technology and patterns
|
||||
- **Solution**: Implementation strategy template with decision tree
|
||||
- **Success Metric**: 90% of approaches approved without revision
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Unclear Requirements**: Missing details or ambiguous specifications
|
||||
- **Solution**: Requirement clarification workflow with PO persona
|
||||
- **Success Metric**: Reduction in requirement-related questions
|
||||
- 🔴 **Technical Constraints**: Legacy system limitations
|
||||
- **Solution**: Technical constraint analysis template
|
||||
- **Success Metric**: All constraints identified before coding begins
|
||||
|
||||
### 2. Development Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Code Generation**: AI-assisted implementation
|
||||
- **Testing Framework**: Test case creation and execution
|
||||
- **Code Optimization**: Performance and quality improvements
|
||||
|
||||
#### Decision Points
|
||||
- â **Technical Tradeoffs**: Balancing quality, performance, and time
|
||||
- **Solution**: Decision matrix for evaluating tradeoffs
|
||||
- **Success Metric**: Documented rationale for all significant decisions
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Integration Challenges**: Difficulties connecting with other systems
|
||||
- **Solution**: Integration pattern library and troubleshooting guide
|
||||
- **Success Metric**: 50% reduction in integration-related delays
|
||||
- 🔴 **Technical Roadblocks**: Unexpected implementation challenges
|
||||
- **Solution**: Problem-solving workflow with architect persona
|
||||
- **Success Metric**: Average resolution time under 4 hours
|
||||
|
||||
### 3. Validation Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Code Review Checklist**: Self-assessment of code quality
|
||||
- **Automated Testing**: Running comprehensive test suite
|
||||
- **Quality Metrics**: Measuring code against standards
|
||||
|
||||
#### Decision Points
|
||||
- â **Quality vs. Timeline**: When to refactor vs. when to ship
|
||||
- **Solution**: Quality threshold guidelines with examples
|
||||
- **Success Metric**: 95% of features meet quality standards on first review
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Test Coverage Gaps**: Identifying untested scenarios
|
||||
- **Solution**: Test coverage analysis and recommendation tool
|
||||
- **Success Metric**: 90%+ test coverage for critical functionality
|
||||
- 🔴 **Performance Issues**: Unexpected performance bottlenecks
|
||||
- **Solution**: Performance optimization patterns and guidelines
|
||||
- **Success Metric**: All features meet performance benchmarks
|
||||
|
||||
### 4. Delivery Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Pull Request Template**: Standardized submission format
|
||||
- **Code Review Process**: Structured feedback mechanism
|
||||
- **Documentation Generator**: Automated documentation creation
|
||||
- **Deployment Checklist**: Pre-deployment verification
|
||||
|
||||
#### Decision Points
|
||||
- â **Release Readiness**: Determining if feature is ready for production
|
||||
- **Solution**: Release readiness assessment framework
|
||||
- **Success Metric**: Zero critical issues found post-release
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Review Feedback Volume**: Overwhelming number of change requests
|
||||
- **Solution**: Prioritized feedback categorization system
|
||||
- **Success Metric**: Average review resolution time under 1 day
|
||||
- 🔴 **Documentation Burden**: Time-consuming documentation requirements
|
||||
- **Solution**: AI-assisted documentation generation
|
||||
- **Success Metric**: 70% reduction in documentation time
|
||||
|
||||
## Emotional Journey
|
||||
|
||||
\```mermaid title="Emotional Journey" type="diagram"
|
||||
journey
|
||||
title Emotional Journey - Feature Development
|
||||
section Preparation
|
||||
Interest in new challenge: 4
|
||||
Concern about requirements clarity: 2
|
||||
Confidence after planning: 4
|
||||
section Development
|
||||
Flow state during coding: 5
|
||||
Frustration with obstacles: 2
|
||||
Satisfaction with solutions: 4
|
||||
section Validation
|
||||
Anxiety during testing: 3
|
||||
Disappointment with issues found: 2
|
||||
Relief after fixes: 4
|
||||
section Delivery
|
||||
Nervousness during review: 2
|
||||
Stress addressing feedback: 3
|
||||
Pride in completed feature: 5
|
||||
\```
|
||||
|
||||
## Success Metrics
|
||||
|
||||
| Metric | Target | Measurement Method |
|
||||
|--------|--------|-------------------|
|
||||
| First-time Pass Rate | > 80% | Code review statistics |
|
||||
| Development Time | Within 10% of estimate | Time tracking analysis |
|
||||
| Test Coverage | > 90% for critical paths | Automated test reports |
|
||||
| Technical Debt Added | < 5% of code volume | Static analysis tools |
|
||||
| Post-release Bugs | < 1 per 100 lines of code | Defect tracking system |
|
||||
|
||||
## Journey Optimization Opportunities
|
||||
|
||||
1. **AI-Enhanced Code Generation**: Accelerate implementation of standard patterns
|
||||
2. **Automated Test Creation**: Generate test cases from requirements
|
||||
3. **Intelligent Code Review**: Prioritize feedback based on impact
|
||||
4. **Predictive Issue Detection**: Identify potential problems before they occur
|
||||
5. **Documentation Automation**: Generate technical documentation from code
|
||||
|
||||
## Next Steps in User Journey
|
||||
|
||||
After completing the feature development journey, Developers typically proceed to:
|
||||
|
||||
1. [Feature Enhancement Journey](feature-enhancement.md) - Improving existing functionality
|
||||
2. [Bug Resolution Journey](bug-resolution.md) - Addressing reported issues
|
||||
3. [Technical Debt Reduction Journey](technical-debt-reduction.md) - Improving code quality
|
||||
|
||||
---
|
||||
|
||||
*The feature development journey is the core workflow for implementing functionality and delivering value through the BMAD Method.*
|
||||
|
|
@ -0,0 +1,178 @@
|
|||
# First-Time Setup Journey
|
||||
|
||||
This document maps the complete journey of a new user setting up the BMAD Method for the first time.
|
||||
|
||||
## Persona Profile: New User
|
||||
|
||||
**Name**: Alex (New Developer)
|
||||
**Role**: Frontend Developer
|
||||
**Experience**: 3 years of development experience
|
||||
**Goals**:
|
||||
- Set up BMAD Method quickly
|
||||
- Understand core concepts
|
||||
- Successfully complete a simple task
|
||||
|
||||
**Pain Points**:
|
||||
- Limited time for learning new tools
|
||||
- Skeptical about AI-driven development
|
||||
- Prefers practical examples over theory
|
||||
|
||||
## Journey Map
|
||||
|
||||
\```mermaid title="First-Time Setup Journey" type="diagram"
|
||||
journey
|
||||
title First-Time Setup User Journey
|
||||
section Discovery
|
||||
Hears about BMAD Method: 3
|
||||
Visits documentation site: 3
|
||||
Reads quick start guide: 4
|
||||
section Setup
|
||||
Chooses environment (Web/IDE): 3
|
||||
Installs necessary components: 2
|
||||
Configures settings: 2
|
||||
section First Use
|
||||
Reads example project: 4
|
||||
Attempts simple task: 3
|
||||
Receives AI guidance: 5
|
||||
section Validation
|
||||
Completes first deliverable: 5
|
||||
Reviews output quality: 4
|
||||
Shares with team: 4
|
||||
\```
|
||||
|
||||
## Detailed Journey Stages
|
||||
|
||||
### 1. Discovery Phase
|
||||
|
||||
#### Entry Point
|
||||
- Recommendation from colleague
|
||||
- Online search for AI development tools
|
||||
- Social media or blog post
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Documentation Homepage**: First impression of the BMAD Method
|
||||
- **Value Proposition**: Understanding what problems BMAD solves
|
||||
- **Quick Start Guide**: Initial pathway to getting started
|
||||
|
||||
#### Decision Points
|
||||
- â **Continue or Abandon**: Based on perceived value and learning curve
|
||||
- **Solution**: Clear, compelling benefits on homepage with minimal scrolling
|
||||
- **Success Metric**: 70% of visitors proceed to setup phase
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Information Overload**: Too much theory before practical application
|
||||
- **Solution**: Progressive disclosure of information with clear "Start Here" path
|
||||
- **Success Metric**: Average time to first action under 5 minutes
|
||||
|
||||
### 2. Setup Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Environment Selection**: Choosing between web-based or IDE setup
|
||||
- **Installation Process**: Following setup instructions
|
||||
- **Configuration**: Customizing settings for specific needs
|
||||
|
||||
#### Decision Points
|
||||
- â **Web vs. IDE Environment**: Based on existing workflow and preferences
|
||||
- **Solution**: Clear comparison table with pros/cons of each approach
|
||||
- **Success Metric**: 90% of users successfully complete their chosen setup path
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Technical Hurdles**: Installation issues in specific environments
|
||||
- **Solution**: Troubleshooting guide with common issues and solutions
|
||||
- **Success Metric**: Support requests under 5% of new installations
|
||||
- 🔴 **Configuration Complexity**: Unclear what settings to change
|
||||
- **Solution**: Sensible defaults with clear explanations for customization options
|
||||
- **Success Metric**: Average setup time under 10 minutes
|
||||
|
||||
### 3. First Use Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Example Project**: Reviewing sample implementation
|
||||
- **Task Selection**: Choosing first task to attempt
|
||||
- **AI Interaction**: First conversation with BMAD personas
|
||||
|
||||
#### Decision Points
|
||||
- â **Task Complexity**: Selecting appropriate difficulty for first task
|
||||
- **Solution**: Clearly labeled "beginner" tasks with estimated completion times
|
||||
- **Success Metric**: 85% first-task completion rate
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Prompt Uncertainty**: Not knowing how to effectively communicate with AI
|
||||
- **Solution**: Prompt templates and examples for common scenarios
|
||||
- **Success Metric**: Average time to first successful prompt under 2 minutes
|
||||
- 🔴 **Persona Confusion**: Uncertainty about which persona to use
|
||||
- **Solution**: Persona selection guide with use cases for each
|
||||
- **Success Metric**: Correct persona selection rate above 80%
|
||||
|
||||
### 4. Validation Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Deliverable Completion**: Finishing first task
|
||||
- **Quality Assessment**: Evaluating output quality
|
||||
- **Team Sharing**: Demonstrating to colleagues
|
||||
|
||||
#### Decision Points
|
||||
- â **Adoption Decision**: Whether to continue using BMAD Method
|
||||
- **Solution**: Clear path to next steps and more advanced usage
|
||||
- **Success Metric**: 75% continue to second task within 24 hours
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Output Customization**: Difficulty modifying generated content
|
||||
- **Solution**: Edit guides and customization options clearly presented
|
||||
- **Success Metric**: Average customization time under 5 minutes
|
||||
- 🔴 **Colleague Skepticism**: Resistance from team members
|
||||
- **Solution**: Shareable success stories and comparison metrics
|
||||
- **Success Metric**: Team adoption rate above 50% after demonstration
|
||||
|
||||
## Emotional Journey
|
||||
|
||||
\```mermaid title="Emotional Journey" type="diagram"
|
||||
journey
|
||||
title Emotional Journey - First-Time Setup
|
||||
section Discovery
|
||||
Initial curiosity: 3
|
||||
Interest in possibilities: 4
|
||||
Concern about learning curve: 2
|
||||
section Setup
|
||||
Determination to configure: 3
|
||||
Frustration with technical details: 2
|
||||
Relief when setup completes: 4
|
||||
section First Use
|
||||
Uncertainty about approach: 2
|
||||
Surprise at AI capabilities: 4
|
||||
Excitement at first success: 5
|
||||
section Validation
|
||||
Pride in completed work: 5
|
||||
Satisfaction with quality: 4
|
||||
Enthusiasm for future use: 5
|
||||
\```
|
||||
|
||||
## Success Metrics
|
||||
|
||||
| Metric | Target | Measurement Method |
|
||||
|--------|--------|-------------------|
|
||||
| Time to First Task | < 15 minutes | Analytics tracking |
|
||||
| Setup Completion Rate | > 90% | Funnel analysis |
|
||||
| First Task Completion | > 85% | User activity tracking |
|
||||
| Satisfaction Score | > 4.2/5 | Post-setup survey |
|
||||
| Return Rate (24h) | > 75% | User retention analysis |
|
||||
|
||||
## Journey Optimization Opportunities
|
||||
|
||||
1. **Streamlined Onboarding**: Reduce steps between discovery and first success
|
||||
2. **Interactive Tutorials**: Add guided walkthroughs for common first tasks
|
||||
3. **Persona Selection Helper**: Create a wizard to recommend appropriate personas
|
||||
4. **Setup Automation**: Develop one-click setup options for common environments
|
||||
5. **Success Celebration**: Add positive reinforcement after first task completion
|
||||
|
||||
## Next Steps in User Journey
|
||||
|
||||
After completing the first-time setup journey, users typically proceed to:
|
||||
|
||||
1. [Project Initiation Journey](project-initiation.md) - Starting their first real project
|
||||
2. [Feature Development Journey](feature-development.md) - Implementing specific features
|
||||
3. [Team Onboarding](team-onboarding.md) - Bringing colleagues into the BMAD Method
|
||||
|
||||
---
|
||||
|
||||
*The first-time setup journey is critical for user adoption and sets the foundation for long-term BMAD Method success.*
|
||||
|
|
@ -0,0 +1,183 @@
|
|||
# Project Initiation Journey
|
||||
|
||||
This document maps the complete journey of a Product Owner initiating a new project using the BMAD Method.
|
||||
|
||||
## Persona Profile: Product Owner
|
||||
|
||||
**Name**: Patricia (Product Owner)
|
||||
**Role**: Product Owner / Product Manager
|
||||
**Experience**: 5+ years in product management
|
||||
**Goals**:
|
||||
- Define clear project scope and requirements
|
||||
- Create comprehensive project documentation
|
||||
- Set up project structure for team success
|
||||
- Establish measurable success criteria
|
||||
|
||||
**Pain Points**:
|
||||
- Balancing detail with time constraints
|
||||
- Communicating technical requirements clearly
|
||||
- Ensuring alignment between business and technical teams
|
||||
- Managing stakeholder expectations
|
||||
|
||||
## Journey Map
|
||||
|
||||
\```mermaid title="Project Initiation Journey" type="diagram"
|
||||
journey
|
||||
title Project Initiation User Journey
|
||||
section Project Definition
|
||||
Identify business need: 4
|
||||
Define project scope: 3
|
||||
Establish success criteria: 4
|
||||
section Requirements Gathering
|
||||
Collect stakeholder input: 3
|
||||
Document user stories: 2
|
||||
Prioritize requirements: 3
|
||||
section Project Setup
|
||||
Create project structure: 4
|
||||
Define technical approach: 3
|
||||
Establish timeline: 2
|
||||
section Handoff
|
||||
Brief development team: 4
|
||||
Address questions: 3
|
||||
Begin implementation: 5
|
||||
\```
|
||||
|
||||
## Detailed Journey Stages
|
||||
|
||||
### 1. Project Definition Phase
|
||||
|
||||
#### Entry Point
|
||||
- Business request for new feature/product
|
||||
- Market opportunity identification
|
||||
- Technical debt or system improvement need
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Project Brief Template**: Initial documentation structure
|
||||
- **BMAD PO Persona**: Guidance on project definition
|
||||
- **Success Criteria Framework**: Establishing measurable outcomes
|
||||
|
||||
#### Decision Points
|
||||
- â **Project Scope Definition**: Determining boundaries and MVP
|
||||
- **Solution**: Scope definition template with examples
|
||||
- **Success Metric**: 90% of projects stay within initial scope
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Ambiguous Business Requirements**: Unclear objectives from stakeholders
|
||||
- **Solution**: Requirement clarification prompts and templates
|
||||
- **Success Metric**: Reduction in scope changes after initiation
|
||||
- 🔴 **Success Criteria Formulation**: Difficulty defining measurable outcomes
|
||||
- **Solution**: SMART goal templates with industry-specific examples
|
||||
- **Success Metric**: 100% of projects have quantifiable success metrics
|
||||
|
||||
### 2. Requirements Gathering Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Stakeholder Interview Guide**: Structured approach to gathering input
|
||||
- **User Story Template**: Standardized format for requirements
|
||||
- **Prioritization Framework**: Method for ranking requirements
|
||||
|
||||
#### Decision Points
|
||||
- â **MVP Feature Selection**: Determining core vs. nice-to-have features
|
||||
- **Solution**: Value/effort prioritization matrix
|
||||
- **Success Metric**: MVP delivery time reduced by 30%
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Stakeholder Alignment**: Conflicting priorities from different departments
|
||||
- **Solution**: Stakeholder alignment workshop templates
|
||||
- **Success Metric**: Stakeholder consensus achieved before development starts
|
||||
- 🔴 **Technical Feasibility**: Uncertainty about implementation possibilities
|
||||
- **Solution**: Early architect consultation workflow
|
||||
- **Success Metric**: Technical roadblocks identified before development
|
||||
|
||||
### 3. Project Setup Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Project Structure Template**: Standardized project organization
|
||||
- **Technical Approach Document**: Architecture and technology decisions
|
||||
- **Timeline Generator**: Realistic schedule creation
|
||||
|
||||
#### Decision Points
|
||||
- â **Technology Stack Selection**: Choosing appropriate technologies
|
||||
- **Solution**: Technology comparison framework with recommendations
|
||||
- **Success Metric**: 95% of projects use recommended technology patterns
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Timeline Estimation**: Difficulty predicting development time
|
||||
- **Solution**: Historical data-based estimation templates
|
||||
- **Success Metric**: Delivery estimates within 20% of actual time
|
||||
- 🔴 **Resource Allocation**: Uncertainty about required team composition
|
||||
- **Solution**: Skill matrix and resource planning tools
|
||||
- **Success Metric**: Reduced mid-project resource adjustments
|
||||
|
||||
### 4. Handoff Phase
|
||||
|
||||
#### Key Touchpoints
|
||||
- **Development Brief Template**: Comprehensive handoff documentation
|
||||
- **Q&A Session Structure**: Framework for addressing team questions
|
||||
- **Implementation Kickoff**: Structured start to development
|
||||
|
||||
#### Decision Points
|
||||
- â **Development Approach**: Waterfall vs. agile implementation
|
||||
- **Solution**: Development methodology decision tree
|
||||
- **Success Metric**: 100% team alignment on approach before starting
|
||||
|
||||
#### Pain Points
|
||||
- 🔴 **Knowledge Transfer**: Ensuring complete understanding by development team
|
||||
- **Solution**: Knowledge transfer checklist and verification
|
||||
- **Success Metric**: Zero "requirements clarification" delays
|
||||
- 🔴 **Maintaining Involvement**: Balancing oversight without micromanagement
|
||||
- **Solution**: RACI matrix for ongoing product owner involvement
|
||||
- **Success Metric**: Weekly touchpoints established for all projects
|
||||
|
||||
## Emotional Journey
|
||||
|
||||
\```mermaid title="Emotional Journey" type="diagram"
|
||||
journey
|
||||
title Emotional Journey - Project Initiation
|
||||
section Project Definition
|
||||
Excitement about new project: 5
|
||||
Pressure to define correctly: 2
|
||||
Confidence in clear direction: 4
|
||||
section Requirements Gathering
|
||||
Overwhelmed by stakeholder input: 2
|
||||
Frustration with conflicting needs: 2
|
||||
Satisfaction with prioritized list: 4
|
||||
section Project Setup
|
||||
Concern about technical decisions: 3
|
||||
Anxiety about timeline accuracy: 2
|
||||
Relief with completed structure: 4
|
||||
section Handoff
|
||||
Pride in comprehensive documentation: 5
|
||||
Nervousness about team reception: 3
|
||||
Excitement as implementation begins: 5
|
||||
\```
|
||||
|
||||
## Success Metrics
|
||||
|
||||
| Metric | Target | Measurement Method |
|
||||
|--------|--------|-------------------|
|
||||
| Time to Project Definition | < 3 days | Project timeline tracking |
|
||||
| Requirement Clarity Score | > 4.5/5 | Development team survey |
|
||||
| Scope Change Requests | < 15% | Change request tracking |
|
||||
| Handoff Completeness | 100% checklist completion | Handoff verification |
|
||||
| Development Start Delay | < 1 day after handoff | Project timeline analysis |
|
||||
|
||||
## Journey Optimization Opportunities
|
||||
|
||||
1. **Automated Stakeholder Input**: Streamline gathering and consolidating feedback
|
||||
2. **AI-Enhanced Requirement Writing**: Improve clarity and testability of requirements
|
||||
3. **Predictive Timeline Generation**: Use historical data to improve estimates
|
||||
4. **Interactive Project Visualization**: Better communicate project structure to stakeholders
|
||||
5. **Continuous Feedback Loop**: Establish mechanisms for ongoing refinement
|
||||
|
||||
## Next Steps in User Journey
|
||||
|
||||
After completing the project initiation journey, Product Owners typically proceed to:
|
||||
|
||||
1. [Sprint Planning Journey](sprint-planning.md) - Organizing work into manageable increments
|
||||
2. [Feature Prioritization Journey](feature-prioritization.md) - Ongoing backlog management
|
||||
3. [Stakeholder Communication Journey](stakeholder-communication.md) - Regular updates and expectation management
|
||||
|
||||
---
|
||||
|
||||
*The project initiation journey establishes the foundation for project success and sets expectations for all participants.*
|
||||
|
|
@ -0,0 +1,215 @@
|
|||
# v0 UX/UI Architect Comprehensive Guide
|
||||
|
||||
## Introduction
|
||||
|
||||
The v0 UX/UI Architect is a specialized AI persona designed to bridge the gap between design concepts and implementation, providing rapid visual design generation and component implementation capabilities. This comprehensive guide will help you understand how to effectively use this persona in your development workflow.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Core Capabilities](#core-capabilities)
|
||||
2. [When to Use](#when-to-use)
|
||||
3. [Activation Methods](#activation-methods)
|
||||
4. [Working Process](#working-process)
|
||||
5. [Input Requirements](#input-requirements)
|
||||
6. [Output Expectations](#output-expectations)
|
||||
7. [Integration with Other Personas](#integration-with-other-personas)
|
||||
8. [Best Practices](#best-practices)
|
||||
9. [Troubleshooting](#troubleshooting)
|
||||
10. [Advanced Usage](#advanced-usage)
|
||||
11. [Integration Guide](#integration-guide)
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
The v0 UX/UI Architect excels at:
|
||||
|
||||
- **Prompt-to-Design Transformation**: Converting simple text descriptions into comprehensive visual designs
|
||||
- **Component-Based Design**: Creating reusable UI components that follow design system principles
|
||||
- **Responsive Design**: Automatically considering multiple device sizes and interaction models
|
||||
- **Accessibility Integration**: Building accessibility into designs from the beginning
|
||||
- **Code-Design Synthesis**: Seamlessly moving between visual concepts and implementation code
|
||||
- **Rapid Iteration**: Quickly generating and refining multiple design options
|
||||
|
||||
## When to Use
|
||||
|
||||
The v0 UX/UI Architect is ideal for:
|
||||
|
||||
- **Early Design Exploration**: Rapidly visualizing concepts before committing to implementation
|
||||
- **Component Library Creation**: Building consistent, reusable UI component libraries
|
||||
- **Design System Development**: Establishing or extending design systems
|
||||
- **Frontend Implementation**: Converting designs into production-ready code
|
||||
- **Design Refinement**: Iterating on existing designs to improve usability and aesthetics
|
||||
|
||||
## Activation Methods
|
||||
|
||||
### Web Environment (Veronica)
|
||||
|
||||
```
|
||||
"I need Veronica to help with UI design for [project/component]"
|
||||
"Activate the v0 UX/UI Architect for a [specific design task]"
|
||||
"Veronica, can you create a [component type] following our design system?"
|
||||
```
|
||||
|
||||
### IDE Environment (Victor)
|
||||
|
||||
```
|
||||
"Victor, I need you to implement a [component] using [framework] and [styling approach]"
|
||||
"Let's create a responsive [component] with accessibility features"
|
||||
"Help me build a [component] that integrates with our existing design system"
|
||||
```
|
||||
|
||||
## Working Process
|
||||
|
||||
The v0 UX/UI Architect follows a structured process:
|
||||
|
||||
1. **Requirements Clarification**
|
||||
- Understanding project goals and user needs
|
||||
- Clarifying technical constraints and platform requirements
|
||||
- Identifying design system requirements
|
||||
|
||||
2. **Visual Exploration**
|
||||
- Generating multiple design directions
|
||||
- Creating initial component concepts
|
||||
- Establishing visual language
|
||||
|
||||
3. **Iterative Refinement**
|
||||
- Gathering feedback on initial concepts
|
||||
- Refining designs based on feedback
|
||||
- Optimizing for usability and accessibility
|
||||
|
||||
4. **Component Specification**
|
||||
- Defining reusable components with variants and states
|
||||
- Creating detailed specifications
|
||||
- Documenting behavior and interactions
|
||||
|
||||
5. **Implementation**
|
||||
- Generating production-ready code
|
||||
- Creating implementation documentation
|
||||
- Ensuring technical feasibility
|
||||
|
||||
## Input Requirements
|
||||
|
||||
For optimal results, provide:
|
||||
|
||||
- **Project Context**: Brief description of the project and its goals
|
||||
- **User Needs**: Information about target users and their requirements
|
||||
- **Technical Constraints**: Framework, libraries, and platform requirements
|
||||
- **Design Direction**: Brand guidelines, color preferences, or stylistic direction
|
||||
- **Examples**: Reference designs or components (optional but helpful)
|
||||
|
||||
## Output Expectations
|
||||
|
||||
The v0 UX/UI Architect produces:
|
||||
|
||||
- **Visual Designs**: High-fidelity mockups and prototypes
|
||||
- **Component Specifications**: Detailed documentation of components
|
||||
- **Implementation Code**: Production-ready frontend code
|
||||
- **Design System Assets**: Reusable design tokens and components
|
||||
- **Documentation**: Usage guidelines and implementation notes
|
||||
|
||||
## Integration with Other Personas
|
||||
|
||||
The v0 UX/UI Architect works seamlessly with other BMAD Method personas:
|
||||
|
||||
- **Analyst**: Receives project briefs and transforms requirements into visual concepts
|
||||
- **Product Manager**: Enhances PRDs with visual designs and prototypes
|
||||
- **Architect**: Ensures technical feasibility of designs and aligns with system architecture
|
||||
- **Product Owner**: Provides visual assets for user stories and acceptance criteria
|
||||
- **Developer**: Delivers implementation-ready components and documentation
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Effective Prompting
|
||||
|
||||
1. **Be Specific**: Include details about functionality, styling, and technical requirements
|
||||
2. **Provide Context**: Mention your tech stack, design system, and constraints
|
||||
3. **Include Examples**: Reference existing designs or components you like
|
||||
4. **Specify Scope**: Clarify if you want just the design, just the code, or both
|
||||
|
||||
### Quality Assurance
|
||||
|
||||
- Run the v0 Component Quality Checklist after component creation
|
||||
- Test designs across multiple device sizes
|
||||
- Validate accessibility with WCAG guidelines
|
||||
- Ensure components integrate with your existing design system
|
||||
|
||||
### Workflow Integration
|
||||
|
||||
1. Start with clear requirements from Analyst or PM phases
|
||||
2. Generate detailed component specifications
|
||||
3. Implement components with proper documentation
|
||||
4. Validate against quality checklists
|
||||
5. Integrate with existing design system
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues and Solutions
|
||||
|
||||
| Issue | Solution |
|
||||
|-------|----------|
|
||||
| Designs don't match brand guidelines | Provide specific brand colors, typography, and style references |
|
||||
| Components lack accessibility features | Explicitly request accessibility compliance and specify standards |
|
||||
| Code doesn't work in your environment | Specify your exact setup (framework version, build tools) |
|
||||
| Designs aren't responsive | Request specific breakpoint handling and device considerations |
|
||||
| Components don't integrate with design system | Provide design system documentation or component examples |
|
||||
|
||||
## Advanced Usage
|
||||
|
||||
### Design System Creation
|
||||
|
||||
The v0 UX/UI Architect can help establish a complete design system:
|
||||
|
||||
1. **Design Tokens**: Colors, typography, spacing, shadows
|
||||
2. **Core Components**: Buttons, inputs, cards, navigation
|
||||
3. **Patterns**: Forms, layouts, data displays
|
||||
4. **Documentation**: Usage guidelines and implementation notes
|
||||
|
||||
### Cross-Platform Design
|
||||
|
||||
For multi-platform projects:
|
||||
|
||||
1. Define shared design principles
|
||||
2. Create platform-specific component variations
|
||||
3. Maintain consistent user experience across platforms
|
||||
4. Document platform-specific considerations
|
||||
|
||||
### Accessibility-First Design
|
||||
|
||||
To ensure inclusive designs:
|
||||
|
||||
1. Specify WCAG compliance level (A, AA, AAA)
|
||||
2. Request keyboard navigation support
|
||||
3. Ensure proper color contrast
|
||||
4. Include screen reader considerations
|
||||
5. Test with assistive technologies
|
||||
|
||||
## Integration Guide
|
||||
|
||||
### Integrating with Development Workflow
|
||||
|
||||
1. **Initial Setup**
|
||||
- Ensure both Veronica and Victor are properly configured in your development environment
|
||||
- Familiarize yourself with the activation methods for each persona
|
||||
|
||||
2. **Design Phase**
|
||||
- Use Veronica to generate visual designs and prototypes
|
||||
- Share designs with stakeholders for feedback
|
||||
- Refine designs based on feedback using Veronica
|
||||
|
||||
3. **Implementation Phase**
|
||||
- Use Victor to implement refined designs into code
|
||||
- Ensure components are responsive and accessible
|
||||
- Validate implementation against design specifications
|
||||
|
||||
4. **Testing and Quality Assurance**
|
||||
- Run the v0 Component Quality Checklist
|
||||
- Test components across multiple devices and platforms
|
||||
- Validate accessibility with WCAG guidelines
|
||||
|
||||
5. **Documentation and Maintenance**
|
||||
- Document component usage and implementation notes
|
||||
- Maintain consistency with your existing design system
|
||||
- Update design tokens and components as needed
|
||||
|
||||
---
|
||||
|
||||
This comprehensive guide provides everything you need to effectively use the v0 UX/UI Architect persona in your development workflow. For specific examples and templates, refer to the examples directory.
|
||||
|
|
@ -0,0 +1,192 @@
|
|||
# v0 UX/UI Architect Integration Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This guide explains how to integrate the v0 UX/UI Architect persona into your development workflow, including setup instructions, configuration options, and best practices for different environments.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Web Environment Integration](#web-environment-integration)
|
||||
2. [IDE Environment Integration](#ide-environment-integration)
|
||||
3. [Design System Integration](#design-system-integration)
|
||||
4. [BMAD Method Workflow Integration](#bmad-method-workflow-integration)
|
||||
5. [Third-Party Tool Integration](#third-party-tool-integration)
|
||||
6. [Configuration Options](#configuration-options)
|
||||
|
||||
## Web Environment Integration
|
||||
|
||||
### Setup Instructions
|
||||
|
||||
1. **Access the Web Orchestrator**
|
||||
- Navigate to your preferred AI platform (ChatGPT, Claude, etc.)
|
||||
- Create a new conversation
|
||||
|
||||
2. **Load the v0 UX/UI Architect Persona**
|
||||
- Copy the contents of `bmad-agent/personas/v0-ux-ui-architect.md`
|
||||
- Paste as your first message to the AI
|
||||
|
||||
3. **Activate the Persona**
|
||||
- Use an activation phrase: "I need Veronica to help with UI design"
|
||||
- Provide initial context about your project
|
||||
|
||||
### Usage in Web Environment
|
||||
|
||||
```
|
||||
"Veronica, I need a modern dashboard design for a SaaS application with the following components:
|
||||
- Navigation sidebar
|
||||
- Summary statistics
|
||||
- Activity feed
|
||||
- User profile section
|
||||
|
||||
Our brand colors are blue (#1a73e8) and gray (#f1f3f4), and we follow Material Design principles."
|
||||
```
|
||||
|
||||
### Output Handling
|
||||
|
||||
- **Design Specifications**: Copy and save to your design documentation
|
||||
- **Component Code**: Copy and integrate into your codebase
|
||||
- **Visual Descriptions**: Use as reference for design implementation
|
||||
|
||||
## IDE Environment Integration
|
||||
|
||||
### Methodology Loading Process
|
||||
1. **Load Persona Documentation**
|
||||
- Copy `bmad-agent/personas/v0-ux-ui-architect.ide.md` content
|
||||
- Reference UX/UI task library and templates
|
||||
- Load quality checklists for validation
|
||||
|
||||
2. **Context Configuration**
|
||||
```
|
||||
Load Victor (IDE-based v0 UX/UI Architect) persona
|
||||
Reference component creation tasks and templates
|
||||
Apply design system quality standards
|
||||
```
|
||||
|
||||
### Usage in IDE Environment
|
||||
|
||||
```
|
||||
"Victor, I need you to implement a responsive navigation component using React and Tailwind CSS.
|
||||
It should collapse to a hamburger menu on mobile and show full navigation on desktop.
|
||||
Please include accessibility features and proper keyboard navigation."
|
||||
```
|
||||
|
||||
## Design System Integration
|
||||
|
||||
### Integrating with Existing Design Systems
|
||||
|
||||
1. **Documentation Preparation**
|
||||
- Gather design system documentation
|
||||
- Identify component patterns and styles
|
||||
- Document design tokens (colors, typography, spacing)
|
||||
|
||||
2. **Persona Configuration**
|
||||
- Provide design system documentation to the persona
|
||||
- Specify design token usage requirements
|
||||
- Define component naming conventions
|
||||
|
||||
3. **Component Creation Process**
|
||||
- Request components that follow design system patterns
|
||||
- Validate generated components against design system
|
||||
- Document any extensions or modifications
|
||||
|
||||
### Creating a New Design System
|
||||
|
||||
1. **Foundation Definition**
|
||||
- Define color palette, typography, and spacing
|
||||
- Establish naming conventions
|
||||
- Create design tokens
|
||||
|
||||
2. **Core Component Creation**
|
||||
- Use v0 UX/UI Architect to generate base components
|
||||
- Document component variants and states
|
||||
- Establish component hierarchy
|
||||
|
||||
3. **System Documentation**
|
||||
- Create usage guidelines
|
||||
- Document component specifications
|
||||
- Establish contribution guidelines
|
||||
|
||||
## BMAD Method Workflow Integration
|
||||
|
||||
### Integration Points
|
||||
|
||||
1. **After Analyst Phase**
|
||||
- Transform project brief into visual concepts
|
||||
- Create rapid prototypes for validation
|
||||
- Refine requirements through visual exploration
|
||||
|
||||
2. **During PM Phase**
|
||||
- Enhance PRD with visual designs
|
||||
- Create UI mockups for feature specifications
|
||||
- Develop interactive prototypes for stakeholder communication
|
||||
|
||||
3. **Parallel to Architecture Phase**
|
||||
- Ensure technical feasibility of designs
|
||||
- Align component design with system architecture
|
||||
- Refine based on technical constraints
|
||||
|
||||
4. **Before Development**
|
||||
- Generate implementation-ready component code
|
||||
- Create detailed component documentation
|
||||
- Provide integration guidance
|
||||
|
||||
### Workflow Diagram
|
||||
|
||||
```
|
||||
Analyst (Project Brief) → PM (PRD) → v0 UX/UI Architect (Visual Design) →
|
||||
Architect (Technical Validation) → PO (User Stories) → Developer (Implementation)
|
||||
```
|
||||
|
||||
## Third-Party Tool Integration
|
||||
|
||||
### Design Tools
|
||||
|
||||
- **Figma**: Export designs as Figma-compatible formats
|
||||
- **Sketch**: Generate designs that can be imported into Sketch
|
||||
- **Adobe XD**: Create designs compatible with XD workflows
|
||||
|
||||
### Development Frameworks
|
||||
|
||||
- **React**: Generate React components with proper hooks and patterns
|
||||
- **Vue**: Create Vue components following best practices
|
||||
- **Angular**: Develop Angular components with proper structure
|
||||
- **Svelte**: Build efficient Svelte components
|
||||
|
||||
### CSS Frameworks
|
||||
|
||||
- **Tailwind CSS**: Generate components using Tailwind utility classes
|
||||
- **Bootstrap**: Create components following Bootstrap patterns
|
||||
- **Material UI**: Develop components using Material Design principles
|
||||
- **Styled Components**: Build components with CSS-in-JS approach
|
||||
|
||||
## Configuration Options
|
||||
|
||||
### Persona Configuration
|
||||
|
||||
| Option | Description | Default | Example |
|
||||
|--------|-------------|---------|---------|
|
||||
| `designSystem` | Preferred design system | None | "Material Design" |
|
||||
| `colorPalette` | Brand color palette | None | "#1a73e8, #f1f3f4" |
|
||||
| `framework` | Frontend framework | React | "Vue" |
|
||||
| `cssApproach` | CSS methodology | Tailwind | "Styled Components" |
|
||||
| `accessibilityLevel` | WCAG compliance level | AA | "AAA" |
|
||||
|
||||
### Example Configuration
|
||||
|
||||
```yaml
|
||||
v0_ux_ui_architect:
|
||||
designSystem: "Material Design"
|
||||
colorPalette:
|
||||
primary: "#1a73e8"
|
||||
secondary: "#f1f3f4"
|
||||
accent: "#fbbc04"
|
||||
framework: "React"
|
||||
cssApproach: "Tailwind"
|
||||
accessibilityLevel: "AA"
|
||||
responsive: true
|
||||
darkMode: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
This integration guide provides comprehensive instructions for incorporating the v0 UX/UI Architect persona into your development workflow across different environments and with various tools and frameworks.
|
||||
|
|
@ -0,0 +1,253 @@
|
|||
# v0 UX/UI Architect Quality Assurance Guide
|
||||
|
||||
This document provides comprehensive quality assurance procedures and checklists for evaluating and validating outputs from the v0 UX/UI Architect persona.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Quality Assurance Process](#quality-assurance-process)
|
||||
2. [Design Quality Checklist](#design-quality-checklist)
|
||||
3. [Code Quality Checklist](#code-quality-checklist)
|
||||
4. [Accessibility Checklist](#accessibility-checklist)
|
||||
5. [Responsive Design Checklist](#responsive-design-checklist)
|
||||
6. [Performance Checklist](#performance-checklist)
|
||||
7. [Design System Compliance](#design-system-compliance)
|
||||
8. [Documentation Quality](#documentation-quality)
|
||||
9. [QA Automation Tools](#qa-automation-tools)
|
||||
10. [Continuous Improvement Process](#continuous-improvement-process)
|
||||
|
||||
## Quality Assurance Process
|
||||
|
||||
### Overview
|
||||
|
||||
The QA process for v0 UX/UI Architect outputs follows these steps:
|
||||
|
||||
1. **Initial Review**: Quick assessment of design and code outputs
|
||||
2. **Detailed Evaluation**: Comprehensive review using checklists
|
||||
3. **Testing**: Functional, visual, and accessibility testing
|
||||
4. **Feedback Collection**: Gathering stakeholder input
|
||||
5. **Iteration**: Refining based on feedback and testing results
|
||||
6. **Final Validation**: Confirming all requirements are met
|
||||
7. **Documentation**: Recording QA results and learnings
|
||||
|
||||
### Roles and Responsibilities
|
||||
|
||||
- **Designer**: Visual and UX evaluation
|
||||
- **Developer**: Code quality and implementation review
|
||||
- **QA Specialist**: Comprehensive testing and validation
|
||||
- **Product Owner**: Business requirements validation
|
||||
- **Accessibility Expert**: WCAG compliance verification
|
||||
|
||||
## Design Quality Checklist
|
||||
|
||||
### Visual Design
|
||||
|
||||
- [ ] **Consistency**: Design follows established patterns and conventions
|
||||
- [ ] **Color Usage**: Colors adhere to brand guidelines and accessibility standards
|
||||
- [ ] **Typography**: Font usage is consistent and readable
|
||||
- [ ] **Spacing**: Consistent spacing system is applied
|
||||
- [ ] **Iconography**: Icons are consistent in style and purpose
|
||||
- [ ] **Visual Hierarchy**: Important elements have appropriate emphasis
|
||||
- [ ] **Alignment**: Elements are properly aligned
|
||||
- [ ] **Contrast**: Sufficient contrast between elements
|
||||
|
||||
### User Experience
|
||||
|
||||
- [ ] **Usability**: Design is intuitive and easy to use
|
||||
- [ ] **Information Architecture**: Content is logically organized
|
||||
- [ ] **User Flow**: Clear path to complete user tasks
|
||||
- [ ] **Feedback**: System provides appropriate feedback for user actions
|
||||
- [ ] **Error Handling**: Clear error messages and recovery paths
|
||||
- [ ] **Loading States**: Appropriate loading indicators
|
||||
- [ ] **Empty States**: Well-designed empty states for no content
|
||||
- [ ] **Microcopy**: Clear and concise text
|
||||
|
||||
## Code Quality Checklist
|
||||
|
||||
### Structure and Organization
|
||||
|
||||
- [ ] **Component Architecture**: Follows component-based design principles
|
||||
- [ ] **File Organization**: Logical file structure and naming
|
||||
- [ ] **Code Modularity**: Components are properly encapsulated
|
||||
- [ ] **Separation of Concerns**: Logic, presentation, and styling are separated
|
||||
- [ ] **Naming Conventions**: Consistent and descriptive naming
|
||||
|
||||
### Implementation Quality
|
||||
|
||||
- [ ] **Framework Best Practices**: Follows framework-specific patterns
|
||||
- [ ] **Type Safety**: Proper type definitions (TypeScript/PropTypes)
|
||||
- [ ] **Props Interface**: Clear and comprehensive props interface
|
||||
- [ ] **State Management**: Appropriate state management approach
|
||||
- [ ] **Event Handling**: Proper event handling and delegation
|
||||
- [ ] **Error Handling**: Robust error handling and fallbacks
|
||||
- [ ] **Comments**: Appropriate code documentation
|
||||
- [ ] **Linting**: Passes linting rules
|
||||
|
||||
## Accessibility Checklist
|
||||
|
||||
### WCAG Compliance
|
||||
|
||||
- [ ] **Semantic HTML**: Proper HTML elements for content purpose
|
||||
- [ ] **Keyboard Navigation**: All interactive elements are keyboard accessible
|
||||
- [ ] **Focus Management**: Visible focus indicators and logical tab order
|
||||
- [ ] **ARIA Attributes**: Appropriate ARIA roles and attributes
|
||||
- [ ] **Color Contrast**: Meets WCAG AA standard (4.5:1 for normal text)
|
||||
- [ ] **Text Alternatives**: Alt text for images and non-text content
|
||||
- [ ] **Form Labels**: All form controls have associated labels
|
||||
- [ ] **Error Identification**: Errors are clearly identified and described
|
||||
|
||||
### Assistive Technology
|
||||
|
||||
- [ ] **Screen Reader Compatibility**: Content is announced properly
|
||||
- [ ] **Zoom Compatibility**: Content remains usable at 200% zoom
|
||||
- [ ] **Reduced Motion**: Respects prefers-reduced-motion setting
|
||||
- [ ] **High Contrast Mode**: Works with high contrast mode
|
||||
|
||||
## Responsive Design Checklist
|
||||
|
||||
### Breakpoints and Layouts
|
||||
|
||||
- [ ] **Mobile First**: Design starts with mobile and scales up
|
||||
- [ ] **Breakpoint Coverage**: Works at all defined breakpoints
|
||||
- [ ] **Layout Adaptation**: Layout adjusts appropriately at each breakpoint
|
||||
- [ ] **Content Reflow**: Content reflows rather than requiring horizontal scrolling
|
||||
- [ ] **Touch Targets**: Interactive elements have adequate size (min 44px)
|
||||
- [ ] **Device Testing**: Tested on actual devices or accurate emulators
|
||||
|
||||
### Responsive Behavior
|
||||
|
||||
- [ ] **Image Handling**: Images scale appropriately
|
||||
- [ ] **Typography Scaling**: Text remains readable at all sizes
|
||||
- [ ] **Component Adaptation**: Components transform appropriately
|
||||
- [ ] **Navigation Patterns**: Navigation adapts to screen size
|
||||
- [ ] **Orientation Support**: Works in both portrait and landscape
|
||||
|
||||
## Performance Checklist
|
||||
|
||||
### Loading Performance
|
||||
|
||||
- [ ] **Asset Optimization**: Images and other assets are optimized
|
||||
- [ ] **Code Splitting**: Components are properly code-split
|
||||
- [ ] **Lazy Loading**: Non-critical components are lazy loaded
|
||||
- [ ] **Bundle Size**: Component adds reasonable bundle size
|
||||
|
||||
### Runtime Performance
|
||||
|
||||
- [ ] **Render Efficiency**: Minimizes unnecessary re-renders
|
||||
- [ ] **Animation Performance**: Animations use GPU-accelerated properties
|
||||
- [ ] **Event Handling**: Efficient event handling (debouncing, throttling)
|
||||
- [ ] **Memory Management**: No memory leaks or excessive DOM nodes
|
||||
|
||||
## Design System Compliance
|
||||
|
||||
### Token Usage
|
||||
|
||||
- [ ] **Color Tokens**: Uses design system color tokens
|
||||
- [ ] **Typography Tokens**: Follows typography scale
|
||||
- [ ] **Spacing Tokens**: Uses spacing scale
|
||||
- [ ] **Shadow Tokens**: Uses defined shadow values
|
||||
- [ ] **Border Tokens**: Uses defined border styles and radii
|
||||
|
||||
### Component Patterns
|
||||
|
||||
- [ ] **Pattern Consistency**: Follows established component patterns
|
||||
- [ ] **Variant Support**: Implements all required variants
|
||||
- [ ] **State Handling**: Properly handles all component states
|
||||
- [ ] **Composition**: Works well with other system components
|
||||
- [ ] **Extension**: Extends system appropriately without duplication
|
||||
|
||||
## Documentation Quality
|
||||
|
||||
### Component Documentation
|
||||
|
||||
- [ ] **Purpose**: Clear description of component purpose
|
||||
- [ ] **Props API**: Complete documentation of all props
|
||||
- [ ] **Examples**: Usage examples for common scenarios
|
||||
- [ ] **Variants**: Documentation of all variants
|
||||
- [ ] **States**: Documentation of all states
|
||||
- [ ] **Accessibility**: Accessibility considerations and requirements
|
||||
- [ ] **Limitations**: Known limitations or edge cases
|
||||
|
||||
### Implementation Documentation
|
||||
|
||||
- [ ] **Setup Instructions**: Clear setup and installation guidance
|
||||
- [ ] **Dependencies**: All dependencies are documented
|
||||
- [ ] **Integration**: Instructions for integrating with existing code
|
||||
- [ ] **Customization**: Guidance for customization and extension
|
||||
|
||||
## QA Automation Tools
|
||||
|
||||
### Recommended Tools
|
||||
|
||||
- **Visual Testing**: Storybook, Percy, Chromatic
|
||||
- **Accessibility Testing**: axe, pa11y, WAVE
|
||||
- **Code Quality**: ESLint, Prettier, SonarQube
|
||||
- **Performance Testing**: Lighthouse, WebPageTest
|
||||
- **Cross-Browser Testing**: BrowserStack, Sauce Labs
|
||||
|
||||
### Automation Setup
|
||||
|
||||
```bash
|
||||
# Install testing dependencies
|
||||
npm install --save-dev @storybook/react @testing-library/react jest axe-core
|
||||
|
||||
# Setup visual regression testing
|
||||
npm install --save-dev @storybook/addon-storyshots-puppeteer
|
||||
|
||||
# Setup accessibility testing
|
||||
npm install --save-dev jest-axe
|
||||
```
|
||||
|
||||
### Example Test Script
|
||||
|
||||
```javascript
|
||||
import React from 'react';
|
||||
import { render } from '@testing-library/react';
|
||||
import { axe } from 'jest-axe';
|
||||
import Component from './Component';
|
||||
|
||||
describe('Component', () => {
|
||||
it('should render without errors', () => {
|
||||
const { container } = render(<Component />);
|
||||
expect(container).toBeTruthy();
|
||||
});
|
||||
|
||||
it('should not have accessibility violations', async () => {
|
||||
const { container } = render(<Component />);
|
||||
const results = await axe(container);
|
||||
expect(results).toHaveNoViolations();
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
## Continuous Improvement Process
|
||||
|
||||
### Feedback Collection
|
||||
|
||||
- **User Testing**: Regular usability testing with target users
|
||||
- **Developer Feedback**: Gathering feedback from implementation team
|
||||
- **Analytics**: Monitoring usage patterns and pain points
|
||||
- **Support Tickets**: Tracking issues reported by users
|
||||
|
||||
### Improvement Cycle
|
||||
|
||||
1. **Collect Data**: Gather feedback and metrics
|
||||
2. **Identify Patterns**: Look for common issues or opportunities
|
||||
3. **Prioritize Improvements**: Focus on high-impact changes
|
||||
4. **Implement Changes**: Update designs and code
|
||||
5. **Validate**: Test improvements with users
|
||||
6. **Document**: Update documentation with learnings
|
||||
|
||||
### Learning Repository
|
||||
|
||||
Maintain a repository of:
|
||||
- Common issues and solutions
|
||||
- Best practices and patterns
|
||||
- Case studies and examples
|
||||
- Lessons learned
|
||||
|
||||
---
|
||||
|
||||
This quality assurance guide provides a comprehensive framework for evaluating and validating outputs from the v0 UX/UI Architect persona, ensuring high-quality design and implementation across all projects.
|
||||
```
|
||||
|
||||
Now, let's create an example project to demonstrate the v0 UX/UI Architect in action:
|
||||
|
|
@ -0,0 +1,150 @@
|
|||
# v0 UX/UI Architect Quick Start Guide
|
||||
|
||||
Get up and running with the v0 UX/UI Architect persona in just 5 minutes. This guide provides everything you need to start creating beautiful, functional UI components.
|
||||
|
||||
## 1. Choose Your Environment
|
||||
|
||||
The v0 UX/UI Architect persona can be used in two environments:
|
||||
|
||||
### Web Environment (Veronica)
|
||||
- Use with ChatGPT, Claude, or other web-based AI platforms
|
||||
- Ideal for design exploration and component specification
|
||||
- No setup required
|
||||
|
||||
### IDE Environment (Victor)
|
||||
- Use with Cursor AI, Claude Code, Cline, or Roocode
|
||||
- Ideal for direct code implementation
|
||||
- Requires minimal setup
|
||||
|
||||
## 2. Activate the Persona
|
||||
|
||||
### Web Environment
|
||||
1. Copy the contents of `bmad-agent/personas/v0-ux-ui-architect.md`
|
||||
2. Paste as your first message to the AI
|
||||
3. Use an activation phrase: "I need Veronica to help with UI design"
|
||||
|
||||
### IDE Environment
|
||||
1. Copy the `bmad-agent` folder to your project root
|
||||
2. Reference the persona file in your IDE's AI feature
|
||||
3. Use an activation phrase: "I need Victor to implement a component"
|
||||
|
||||
## 3. Provide Clear Requirements
|
||||
|
||||
For best results, include:
|
||||
|
||||
- **Component Purpose**: What the component should do
|
||||
- **Visual Style**: Brand colors, design system, or style references
|
||||
- **Technical Requirements**: Framework, libraries, and constraints
|
||||
- **User Needs**: Who will use this component and how
|
||||
|
||||
### Example Prompt
|
||||
|
||||
```
|
||||
I need a product card component for an e-commerce site with the following:
|
||||
- Product image, title, price, and "Add to Cart" button
|
||||
- Rating display (1-5 stars)
|
||||
- Badge for "Sale" or "New" items
|
||||
- Responsive design (mobile and desktop)
|
||||
- Using React with Tailwind CSS
|
||||
- Accessible to screen readers
|
||||
- Our brand colors are blue (#3b82f6) and gray (#64748b)
|
||||
```
|
||||
|
||||
## 4. Review and Iterate
|
||||
|
||||
1. Review the initial design or code
|
||||
2. Provide specific feedback
|
||||
3. Request refinements as needed
|
||||
4. Validate against requirements
|
||||
|
||||
## 5. Implement and Test
|
||||
|
||||
1. Copy the final code to your project
|
||||
2. Test across different devices and browsers
|
||||
3. Validate accessibility
|
||||
4. Document the component for your team
|
||||
|
||||
## Example: Creating a Button Component
|
||||
|
||||
### Step 1: Activate the Persona
|
||||
|
||||
"I need Veronica to help design a button component system."
|
||||
|
||||
### Step 2: Provide Requirements
|
||||
|
||||
"We need a button component with primary, secondary, and outline variants. It should support different sizes (small, medium, large) and have states for hover, focus, disabled, and loading. Our brand color is purple (#8b5cf6)."
|
||||
|
||||
### Step 3: Review Initial Design
|
||||
|
||||
The v0 UX/UI Architect will provide an initial design with code implementation.
|
||||
|
||||
### Step 4: Provide Feedback
|
||||
|
||||
"The design looks good, but can we make the loading state show a spinner instead of just changing the text?"
|
||||
|
||||
### Step 5: Implement Final Component
|
||||
|
||||
```tsx
|
||||
import React from 'react';
|
||||
import { cva, type VariantProps } from 'class-variance-authority';
|
||||
import { Loader2 } from 'lucide-react';
|
||||
import { cn } from '@/lib/utils';
|
||||
|
||||
const buttonVariants = cva(
|
||||
"inline-flex items-center justify-center rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-offset-2 disabled:opacity-50 disabled:pointer-events-none",
|
||||
{
|
||||
variants: {
|
||||
variant: {
|
||||
primary: "bg-purple-600 text-white hover:bg-purple-700 focus-visible:ring-purple-500",
|
||||
secondary: "bg-purple-100 text-purple-900 hover:bg-purple-200 focus-visible:ring-purple-500",
|
||||
outline: "border border-purple-200 bg-transparent hover:bg-purple-100 focus-visible:ring-purple-500",
|
||||
},
|
||||
size: {
|
||||
sm: "h-8 px-3 text-xs",
|
||||
md: "h-10 px-4",
|
||||
lg: "h-12 px-6 text-lg",
|
||||
},
|
||||
},
|
||||
defaultVariants: {
|
||||
variant: "primary",
|
||||
size: "md",
|
||||
},
|
||||
}
|
||||
);
|
||||
|
||||
export interface ButtonProps
|
||||
extends React.ButtonHTMLAttributes<HTMLButtonElement>,
|
||||
VariantProps<typeof buttonVariants> {
|
||||
isLoading?: boolean;
|
||||
}
|
||||
|
||||
const Button = React.forwardRef<HTMLButtonElement, ButtonProps>(
|
||||
({ className, variant, size, isLoading, children, disabled, ...props }, ref) => {
|
||||
return (
|
||||
<button
|
||||
className={cn(buttonVariants({ variant, size }), className)}
|
||||
ref={ref}
|
||||
disabled={disabled || isLoading}
|
||||
{...props}
|
||||
>
|
||||
{isLoading && <Loader2 className="mr-2 h-4 w-4 animate-spin" />}
|
||||
{children}
|
||||
</button>
|
||||
);
|
||||
}
|
||||
);
|
||||
Button.displayName = "Button";
|
||||
|
||||
export { Button, buttonVariants };
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
- Explore the [Comprehensive Guide](./v0-ux-ui-architect-comprehensive-guide.md) for detailed information
|
||||
- Check the [Integration Guide](./v0-ux-ui-architect-integration-guide.md) for workflow integration
|
||||
- Review [Example Projects](../examples/) for inspiration
|
||||
- Use the [Quality Assurance Guide](./v0-ux-ui-architect-quality-assurance.md) to validate your components
|
||||
|
||||
---
|
||||
|
||||
Start creating beautiful, functional UI components today with the v0 UX/UI Architect!
|
||||
|
|
@ -0,0 +1,389 @@
|
|||
# BMAD Method Visual Documentation Elements
|
||||
|
||||
This section provides visual elements, style guides, and interactive components to enhance the BMAD Method documentation experience.
|
||||
|
||||
## Overview
|
||||
|
||||
Visual documentation elements improve comprehension, reduce cognitive load, and create a consistent experience across all BMAD Method materials. This section includes:
|
||||
|
||||
- Visual style guide and standards
|
||||
- Interactive diagrams and components
|
||||
- Screenshot libraries and examples
|
||||
- Accessibility guidelines
|
||||
- Brand consistency elements
|
||||
|
||||
## Visual Documentation Standards
|
||||
|
||||
### Color Palette
|
||||
|
||||
Our documentation uses a consistent color scheme that enhances readability and provides semantic meaning:
|
||||
|
||||
```css
|
||||
/* Primary Colors */
|
||||
--bmad-primary: #2563eb; /* Blue - Primary actions and links */
|
||||
--bmad-secondary: #7c3aed; /* Purple - Secondary elements */
|
||||
--bmad-accent: #059669; /* Green - Success states */
|
||||
|
||||
/* Semantic Colors */
|
||||
--bmad-success: #10b981; /* Green - Positive outcomes */
|
||||
--bmad-warning: #f59e0b; /* Amber - Caution states */
|
||||
--bmad-error: #ef4444; /* Red - Error states */
|
||||
--bmad-info: #3b82f6; /* Blue - Information */
|
||||
|
||||
/* Neutral Colors */
|
||||
--bmad-gray-50: #f9fafb; /* Light backgrounds */
|
||||
--bmad-gray-100: #f3f4f6; /* Card backgrounds */
|
||||
--bmad-gray-500: #6b7280; /* Secondary text */
|
||||
--bmad-gray-900: #111827; /* Primary text */
|
||||
```
|
||||
|
||||
### Typography Scale
|
||||
|
||||
```css
|
||||
/* Heading Hierarchy */
|
||||
h1 { font-size: 2.25rem; font-weight: 700; } /* 36px - Page titles */
|
||||
h2 { font-size: 1.875rem; font-weight: 600; } /* 30px - Section headers */
|
||||
h3 { font-size: 1.5rem; font-weight: 600; } /* 24px - Subsections */
|
||||
h4 { font-size: 1.25rem; font-weight: 500; } /* 20px - Components */
|
||||
h5 { font-size: 1.125rem; font-weight: 500; } /* 18px - Sub-components */
|
||||
|
||||
/* Body Text */
|
||||
body { font-size: 1rem; line-height: 1.6; } /* 16px - Base text */
|
||||
small { font-size: 0.875rem; } /* 14px - Captions */
|
||||
```
|
||||
|
||||
### Spacing System
|
||||
|
||||
```css
|
||||
/* Consistent spacing scale */
|
||||
--space-1: 0.25rem; /* 4px */
|
||||
--space-2: 0.5rem; /* 8px */
|
||||
--space-3: 0.75rem; /* 12px */
|
||||
--space-4: 1rem; /* 16px */
|
||||
--space-6: 1.5rem; /* 24px */
|
||||
--space-8: 2rem; /* 32px */
|
||||
--space-12: 3rem; /* 48px */
|
||||
--space-16: 4rem; /* 64px */
|
||||
```
|
||||
|
||||
## Interactive Components
|
||||
|
||||
### Persona Selector Component
|
||||
|
||||
\```html
|
||||
<div class="persona-selector">
|
||||
<h3>Select Your Persona</h3>
|
||||
<div class="persona-grid">
|
||||
<div class="persona-card" data-persona="pm">
|
||||
<div class="persona-icon">👔</div>
|
||||
<h4>Project Manager</h4>
|
||||
<p>Coordinate projects and manage resources</p>
|
||||
</div>
|
||||
<div class="persona-card" data-persona="architect">
|
||||
<div class="persona-icon">ðŸ—ï¸</div>
|
||||
<h4>System Architect</h4>
|
||||
<p>Design technical architecture and solutions</p>
|
||||
</div>
|
||||
<div class="persona-card" data-persona="ux-ui">
|
||||
<div class="persona-icon">🎨</div>
|
||||
<h4>UX/UI Designer</h4>
|
||||
<p>Create user experiences and interfaces</p>
|
||||
</div>
|
||||
<div class="persona-card" data-persona="developer">
|
||||
<div class="persona-icon">💻</div>
|
||||
<h4>Developer</h4>
|
||||
<p>Implement features and technical solutions</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
\```
|
||||
|
||||
### Progress Indicator Component
|
||||
|
||||
\```html
|
||||
<div class="progress-indicator">
|
||||
<div class="progress-step completed">
|
||||
<div class="step-number">1</div>
|
||||
<div class="step-label">Requirements</div>
|
||||
</div>
|
||||
<div class="progress-connector completed"></div>
|
||||
<div class="progress-step completed">
|
||||
<div class="step-number">2</div>
|
||||
<div class="step-label">Architecture</div>
|
||||
</div>
|
||||
<div class="progress-connector active"></div>
|
||||
<div class="progress-step active">
|
||||
<div class="step-number">3</div>
|
||||
<div class="step-label">Design</div>
|
||||
</div>
|
||||
<div class="progress-connector"></div>
|
||||
<div class="progress-step">
|
||||
<div class="step-number">4</div>
|
||||
<div class="step-label">Implementation</div>
|
||||
</div>
|
||||
</div>
|
||||
\```
|
||||
|
||||
### Expandable Code Example Component
|
||||
|
||||
\```html
|
||||
<div class="code-example">
|
||||
<div class="code-header">
|
||||
<span class="code-title">BMAD Persona Configuration</span>
|
||||
<button class="expand-toggle">Expand</button>
|
||||
</div>
|
||||
<div class="code-content">
|
||||
<pre><code class="language-yaml">
|
||||
personas:
|
||||
pm:
|
||||
name: "Project Manager"
|
||||
expertise: ["planning", "coordination", "stakeholder-management"]
|
||||
templates: ["prd", "project-plan", "status-report"]
|
||||
architect:
|
||||
name: "System Architect"
|
||||
expertise: ["system-design", "technology-selection", "integration"]
|
||||
templates: ["architecture-doc", "technical-spec", "integration-plan"]
|
||||
</code></pre>
|
||||
</div>
|
||||
</div>
|
||||
\```
|
||||
|
||||
## Visual Diagram Standards
|
||||
|
||||
### Mermaid Diagram Styling
|
||||
|
||||
\```css
|
||||
/* Custom Mermaid theme for BMAD documentation */
|
||||
.mermaid {
|
||||
font-family: 'Inter', -apple-system, BlinkMacSystemFont, sans-serif;
|
||||
}
|
||||
|
||||
/* Node styling */
|
||||
.node rect {
|
||||
fill: var(--bmad-primary);
|
||||
stroke: var(--bmad-primary);
|
||||
stroke-width: 2px;
|
||||
}
|
||||
|
||||
.node .label {
|
||||
color: white;
|
||||
font-weight: 500;
|
||||
}
|
||||
|
||||
/* Decision nodes */
|
||||
.node.decision rect {
|
||||
fill: var(--bmad-warning);
|
||||
stroke: var(--bmad-warning);
|
||||
}
|
||||
|
||||
/* Success nodes */
|
||||
.node.success rect {
|
||||
fill: var(--bmad-success);
|
||||
stroke: var(--bmad-success);
|
||||
}
|
||||
|
||||
/* Edge styling */
|
||||
.edgePath .path {
|
||||
stroke: var(--bmad-gray-500);
|
||||
stroke-width: 2px;
|
||||
}
|
||||
|
||||
.edgeLabel {
|
||||
background-color: white;
|
||||
border: 1px solid var(--bmad-gray-300);
|
||||
border-radius: 4px;
|
||||
padding: 4px 8px;
|
||||
}
|
||||
\```
|
||||
|
||||
### Icon System
|
||||
|
||||
We use a consistent icon system throughout the documentation:
|
||||
|
||||
- 🎠**Orchestrator**: Central coordination
|
||||
- 👔 **Project Manager**: Planning and coordination
|
||||
- ðŸ—ï¸ **Architect**: Technical design
|
||||
- 🎨 **UX/UI Designer**: User experience
|
||||
- 💻 **Developer**: Implementation
|
||||
- 📊 **Analyst**: Data and requirements
|
||||
- ✅ **Completed**: Finished tasks
|
||||
- 🔄 **In Progress**: Active work
|
||||
- â³ **Pending**: Waiting to start
|
||||
- â **Decision Point**: Key choices
|
||||
- 🔴 **Pain Point**: Challenges
|
||||
- 💡 **Solution**: Problem resolution
|
||||
|
||||
## Screenshot Standards
|
||||
|
||||
### Consistent Screenshot Styling
|
||||
|
||||
All screenshots should follow these guidelines:
|
||||
|
||||
1. **Resolution**: Minimum 1920x1080 for desktop, 375x812 for mobile
|
||||
2. **Browser**: Use Chrome with clean profile (no extensions visible)
|
||||
3. **Zoom Level**: 100% browser zoom
|
||||
4. **Annotations**: Use consistent callout styling
|
||||
5. **File Format**: PNG for UI screenshots, JPG for photos
|
||||
6. **Naming Convention**: `section-subsection-description.png`
|
||||
|
||||
### Annotation Guidelines
|
||||
|
||||
\```html
|
||||
<div class="screenshot-container">
|
||||
<img src="/images/bmad-setup-example.png" alt="BMAD Method setup interface" />
|
||||
<div class="screenshot-annotations">
|
||||
<div class="callout" data-position="top-left">
|
||||
<div class="callout-number">1</div>
|
||||
<div class="callout-text">Select your environment</div>
|
||||
</div>
|
||||
<div class="callout" data-position="center-right">
|
||||
<div class="callout-number">2</div>
|
||||
<div class="callout-text">Configure persona settings</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
\```
|
||||
|
||||
## Accessibility Standards
|
||||
|
||||
### Color Contrast Requirements
|
||||
|
||||
All text must meet WCAG AA standards:
|
||||
- Normal text: 4.5:1 contrast ratio minimum
|
||||
- Large text (18pt+): 3:1 contrast ratio minimum
|
||||
- Interactive elements: 3:1 contrast ratio for focus states
|
||||
|
||||
### Alternative Text Guidelines
|
||||
|
||||
\```html
|
||||
<!-- Good: Descriptive alt text -->
|
||||
<img src="workflow-diagram.png" alt="BMAD workflow showing progression from requirements through architecture, design, and implementation phases" />
|
||||
|
||||
<!-- Bad: Generic alt text -->
|
||||
<img src="workflow-diagram.png" alt="Diagram" />
|
||||
|
||||
<!-- Decorative images -->
|
||||
<img src="decorative-pattern.png" alt="" role="presentation" />
|
||||
\```
|
||||
|
||||
### Keyboard Navigation
|
||||
|
||||
All interactive elements must be keyboard accessible:
|
||||
- Tab order follows logical reading sequence
|
||||
- Focus indicators are clearly visible
|
||||
- All functionality available via keyboard
|
||||
- Skip links provided for long content
|
||||
|
||||
## Responsive Design Guidelines
|
||||
|
||||
### Breakpoint System
|
||||
|
||||
\```css
|
||||
/* Mobile first approach */
|
||||
@media (min-width: 640px) { /* sm */ }
|
||||
@media (min-width: 768px) { /* md */ }
|
||||
@media (min-width: 1024px) { /* lg */ }
|
||||
@media (min-width: 1280px) { /* xl */ }
|
||||
@media (min-width: 1536px) { /* 2xl */ }
|
||||
\```
|
||||
|
||||
### Mobile Optimization
|
||||
|
||||
- Touch targets minimum 44px
|
||||
- Readable text without zooming
|
||||
- Horizontal scrolling avoided
|
||||
- Content reflows appropriately
|
||||
|
||||
## Implementation Guidelines
|
||||
|
||||
### CSS Custom Properties
|
||||
|
||||
\```css
|
||||
:root {
|
||||
/* Brand colors */
|
||||
--bmad-brand-primary: #2563eb;
|
||||
--bmad-brand-secondary: #7c3aed;
|
||||
|
||||
/* Semantic colors */
|
||||
--bmad-success: #10b981;
|
||||
--bmad-warning: #f59e0b;
|
||||
--bmad-error: #ef4444;
|
||||
--bmad-info: #3b82f6;
|
||||
|
||||
/* Typography */
|
||||
--bmad-font-family: 'Inter', -apple-system, BlinkMacSystemFont, sans-serif;
|
||||
--bmad-font-mono: 'JetBrains Mono', 'Fira Code', monospace;
|
||||
|
||||
/* Spacing */
|
||||
--bmad-space-unit: 0.25rem;
|
||||
|
||||
/* Shadows */
|
||||
--bmad-shadow-sm: 0 1px 2px 0 rgb(0 0 0 / 0.05);
|
||||
--bmad-shadow-md: 0 4px 6px -1px rgb(0 0 0 / 0.1);
|
||||
--bmad-shadow-lg: 0 10px 15px -3px rgb(0 0 0 / 0.1);
|
||||
}
|
||||
\```
|
||||
|
||||
### Component Classes
|
||||
|
||||
\```css
|
||||
/* Base component styling */
|
||||
.bmad-card {
|
||||
background: white;
|
||||
border-radius: 8px;
|
||||
box-shadow: var(--bmad-shadow-md);
|
||||
padding: var(--space-6);
|
||||
border: 1px solid var(--bmad-gray-200);
|
||||
}
|
||||
|
||||
.bmad-button {
|
||||
background: var(--bmad-brand-primary);
|
||||
color: white;
|
||||
border: none;
|
||||
border-radius: 6px;
|
||||
padding: var(--space-3) var(--space-6);
|
||||
font-weight: 500;
|
||||
cursor: pointer;
|
||||
transition: all 0.2s ease;
|
||||
}
|
||||
|
||||
.bmad-button:hover {
|
||||
background: var(--bmad-brand-primary-dark);
|
||||
transform: translateY(-1px);
|
||||
}
|
||||
|
||||
.bmad-button:focus {
|
||||
outline: 2px solid var(--bmad-brand-primary);
|
||||
outline-offset: 2px;
|
||||
}
|
||||
\```
|
||||
|
||||
## Quality Assurance Checklist
|
||||
|
||||
### Visual Review Checklist
|
||||
|
||||
- [ ] Color contrast meets WCAG AA standards
|
||||
- [ ] Typography hierarchy is consistent
|
||||
- [ ] Spacing follows the defined scale
|
||||
- [ ] Interactive elements have clear focus states
|
||||
- [ ] Images have appropriate alt text
|
||||
- [ ] Responsive design works across breakpoints
|
||||
- [ ] Brand consistency maintained throughout
|
||||
- [ ] Loading states are handled gracefully
|
||||
- [ ] Error states are clearly communicated
|
||||
- [ ] Success states provide positive feedback
|
||||
|
||||
### Accessibility Audit
|
||||
|
||||
- [ ] Screen reader compatibility tested
|
||||
- [ ] Keyboard navigation verified
|
||||
- [ ] Color is not the only means of conveying information
|
||||
- [ ] Text can be resized to 200% without horizontal scrolling
|
||||
- [ ] Motion can be disabled for users with vestibular disorders
|
||||
- [ ] Form labels are properly associated
|
||||
- [ ] Headings create a logical document outline
|
||||
- [ ] Links have descriptive text
|
||||
|
||||
---
|
||||
|
||||
*These visual documentation standards ensure a consistent, accessible, and professional experience across all BMAD Method materials.*
|
||||
|
|
@ -0,0 +1,536 @@
|
|||
# BMAD Method Accessibility Guide
|
||||
|
||||
This guide ensures that all BMAD Method documentation and visual elements are accessible to users with diverse abilities and needs.
|
||||
|
||||
## Accessibility Principles
|
||||
|
||||
### 1. Perceivable
|
||||
Information and user interface components must be presentable to users in ways they can perceive.
|
||||
|
||||
### 2. Operable
|
||||
User interface components and navigation must be operable by all users.
|
||||
|
||||
### 3. Understandable
|
||||
Information and the operation of user interface must be understandable.
|
||||
|
||||
### 4. Robust
|
||||
Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.
|
||||
|
||||
## Color and Contrast Standards
|
||||
|
||||
### WCAG AA Compliance
|
||||
|
||||
All text and interactive elements meet or exceed WCAG AA standards:
|
||||
|
||||
\```css
|
||||
/* High contrast color combinations */
|
||||
.high-contrast-text {
|
||||
color: #000000; /* Black text */
|
||||
background: #ffffff; /* White background */
|
||||
/* Contrast ratio: 21:1 */
|
||||
}
|
||||
|
||||
.primary-text {
|
||||
color: #1a365d; /* Dark blue text */
|
||||
background: #ffffff; /* White background */
|
||||
/* Contrast ratio: 12.6:1 */
|
||||
}
|
||||
|
||||
.secondary-text {
|
||||
color: #4a5568; /* Gray text */
|
||||
background: #ffffff; /* White background */
|
||||
/* Contrast ratio: 7.2:1 */
|
||||
}
|
||||
|
||||
/* Interactive elements */
|
||||
.interactive-element {
|
||||
color: #ffffff; /* White text */
|
||||
background: #2563eb; /* Blue background */
|
||||
/* Contrast ratio: 8.6:1 */
|
||||
}
|
||||
|
||||
.interactive-element:focus {
|
||||
outline: 2px solid #1d4ed8;
|
||||
outline-offset: 2px;
|
||||
/* Focus indicator clearly visible */
|
||||
}
|
||||
\```
|
||||
|
||||
### Color-Blind Friendly Palette
|
||||
|
||||
Our color system works for users with various types of color vision deficiency:
|
||||
|
||||
\```css
|
||||
/* Color-blind friendly palette */
|
||||
:root {
|
||||
--accessible-blue: #0066cc; /* Distinguishable blue */
|
||||
--accessible-green: #228b22; /* Forest green */
|
||||
--accessible-red: #cc0000; /* Clear red */
|
||||
--accessible-orange: #ff8c00; /* Dark orange */
|
||||
--accessible-purple: #6a0dad; /* Blue violet */
|
||||
--accessible-gray: #666666; /* Medium gray */
|
||||
}
|
||||
|
||||
/* Never rely on color alone */
|
||||
.status-indicator {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
gap: 0.5rem;
|
||||
}
|
||||
|
||||
.status-success {
|
||||
color: var(--accessible-green);
|
||||
}
|
||||
|
||||
.status-success::before {
|
||||
content: "✓";
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.status-error {
|
||||
color: var(--accessible-red);
|
||||
}
|
||||
|
||||
.status-error::before {
|
||||
content: "✗";
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.status-warning {
|
||||
color: var(--accessible-orange);
|
||||
}
|
||||
|
||||
.status-warning::before {
|
||||
content: "âš ";
|
||||
font-weight: bold;
|
||||
}
|
||||
\```
|
||||
|
||||
## Typography and Readability
|
||||
|
||||
### Font Selection and Sizing
|
||||
|
||||
\```css
|
||||
/* Accessible typography */
|
||||
body {
|
||||
font-family: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;
|
||||
font-size: 16px; /* Minimum 16px for body text */
|
||||
line-height: 1.6; /* Adequate line spacing */
|
||||
letter-spacing: 0.01em; /* Slight letter spacing for clarity */
|
||||
}
|
||||
|
||||
h1, h2, h3, h4, h5, h6 {
|
||||
font-weight: 600;
|
||||
line-height: 1.3;
|
||||
margin-bottom: 0.5em;
|
||||
}
|
||||
|
||||
/* Large text for better readability */
|
||||
.large-text {
|
||||
font-size: 18px;
|
||||
line-height: 1.7;
|
||||
}
|
||||
|
||||
/* Ensure text can be zoomed to 200% */
|
||||
@media (min-resolution: 2dppx) {
|
||||
body {
|
||||
font-size: 18px;
|
||||
}
|
||||
}
|
||||
\```
|
||||
|
||||
### Reading Flow and Structure
|
||||
|
||||
\```html
|
||||
<!-- Proper heading hierarchy -->
|
||||
<main>
|
||||
<h1>BMAD Method Documentation</h1>
|
||||
|
||||
<section>
|
||||
<h2>Getting Started</h2>
|
||||
|
||||
<article>
|
||||
<h3>First-Time Setup</h3>
|
||||
<p>Clear, concise instructions...</p>
|
||||
|
||||
<h4>Environment Configuration</h4>
|
||||
<p>Step-by-step guidance...</p>
|
||||
</article>
|
||||
</section>
|
||||
</main>
|
||||
|
||||
<!-- Skip links for keyboard navigation -->
|
||||
<a href="#main-content" class="skip-link">Skip to main content</a>
|
||||
<a href="#navigation" class="skip-link">Skip to navigation</a>
|
||||
\```
|
||||
|
||||
## Keyboard Navigation
|
||||
|
||||
### Focus Management
|
||||
|
||||
\```css
|
||||
/* Visible focus indicators */
|
||||
*:focus {
|
||||
outline: 2px solid var(--bmad-primary);
|
||||
outline-offset: 2px;
|
||||
border-radius: 2px;
|
||||
}
|
||||
|
||||
/* Enhanced focus for interactive elements */
|
||||
button:focus,
|
||||
a:focus,
|
||||
input:focus,
|
||||
select:focus,
|
||||
textarea:focus {
|
||||
outline: 3px solid var(--bmad-primary);
|
||||
outline-offset: 2px;
|
||||
box-shadow: 0 0 0 1px rgba(37, 99, 235, 0.2);
|
||||
}
|
||||
|
||||
/* Skip links */
|
||||
.skip-link {
|
||||
position: absolute;
|
||||
top: -40px;
|
||||
left: 6px;
|
||||
background: var(--bmad-primary);
|
||||
color: white;
|
||||
padding: 8px;
|
||||
text-decoration: none;
|
||||
border-radius: 4px;
|
||||
z-index: 1000;
|
||||
}
|
||||
|
||||
.skip-link:focus {
|
||||
top: 6px;
|
||||
}
|
||||
\```
|
||||
|
||||
### Keyboard Interaction Patterns
|
||||
|
||||
\```javascript
|
||||
// Accessible dropdown menu
|
||||
class AccessibleDropdown {
|
||||
constructor(element) {
|
||||
this.dropdown = element;
|
||||
this.trigger = element.querySelector('.dropdown-trigger');
|
||||
this.menu = element.querySelector('.dropdown-menu');
|
||||
this.items = element.querySelectorAll('.dropdown-item');
|
||||
|
||||
this.init();
|
||||
}
|
||||
|
||||
init() {
|
||||
// Keyboard event handlers
|
||||
this.trigger.addEventListener('keydown', (e) => {
|
||||
switch(e.key) {
|
||||
case 'Enter':
|
||||
case ' ':
|
||||
case 'ArrowDown':
|
||||
e.preventDefault();
|
||||
this.openMenu();
|
||||
this.focusFirstItem();
|
||||
break;
|
||||
}
|
||||
});
|
||||
|
||||
this.items.forEach((item, index) => {
|
||||
item.addEventListener('keydown', (e) => {
|
||||
switch(e.key) {
|
||||
case 'ArrowDown':
|
||||
e.preventDefault();
|
||||
this.focusNextItem(index);
|
||||
break;
|
||||
case 'ArrowUp':
|
||||
e.preventDefault();
|
||||
this.focusPreviousItem(index);
|
||||
break;
|
||||
case 'Escape':
|
||||
e.preventDefault();
|
||||
this.closeMenu();
|
||||
this.trigger.focus();
|
||||
break;
|
||||
}
|
||||
});
|
||||
});
|
||||
}
|
||||
|
||||
openMenu() {
|
||||
this.menu.style.display = 'block';
|
||||
this.trigger.setAttribute('aria-expanded', 'true');
|
||||
}
|
||||
|
||||
closeMenu() {
|
||||
this.menu.style.display = 'none';
|
||||
this.trigger.setAttribute('aria-expanded', 'false');
|
||||
}
|
||||
|
||||
focusFirstItem() {
|
||||
this.items[0].focus();
|
||||
}
|
||||
|
||||
focusNextItem(currentIndex) {
|
||||
const nextIndex = (currentIndex + 1) % this.items.length;
|
||||
this.items[nextIndex].focus();
|
||||
}
|
||||
|
||||
focusPreviousItem(currentIndex) {
|
||||
const prevIndex = currentIndex === 0 ? this.items.length - 1 : currentIndex - 1;
|
||||
this.items[prevIndex].focus();
|
||||
}
|
||||
}
|
||||
\```
|
||||
|
||||
## Screen Reader Support
|
||||
|
||||
### Semantic HTML and ARIA
|
||||
|
||||
\```html
|
||||
<!-- Proper semantic structure -->
|
||||
<article role="main">
|
||||
<header>
|
||||
<h1>BMAD Method Overview</h1>
|
||||
<nav aria-label="Page contents">
|
||||
<ol>
|
||||
<li><a href="#introduction">Introduction</a></li>
|
||||
<li><a href="#personas">Personas</a></li>
|
||||
<li><a href="#workflow">Workflow</a></li>
|
||||
</ol>
|
||||
</nav>
|
||||
</header>
|
||||
|
||||
<main>
|
||||
<section id="introduction" aria-labelledby="intro-heading">
|
||||
<h2 id="intro-heading">Introduction</h2>
|
||||
<p>The BMAD Method is...</p>
|
||||
</section>
|
||||
|
||||
<!-- Interactive elements with proper ARIA -->
|
||||
<div class="persona-selector" role="tablist" aria-label="Select persona">
|
||||
<button role="tab"
|
||||
aria-selected="true"
|
||||
aria-controls="pm-panel"
|
||||
id="pm-tab">
|
||||
Project Manager
|
||||
</button>
|
||||
<button role="tab"
|
||||
aria-selected="false"
|
||||
aria-controls="architect-panel"
|
||||
id="architect-tab">
|
||||
System Architect
|
||||
</button>
|
||||
</div>
|
||||
|
||||
<div role="tabpanel"
|
||||
aria-labelledby="pm-tab"
|
||||
id="pm-panel">
|
||||
<h3>Project Manager Persona</h3>
|
||||
<p>Responsible for...</p>
|
||||
</div>
|
||||
</main>
|
||||
</article>
|
||||
|
||||
<!-- Form accessibility -->
|
||||
<form>
|
||||
<fieldset>
|
||||
<legend>Project Configuration</legend>
|
||||
|
||||
<label for="project-name">
|
||||
Project Name
|
||||
<span aria-label="required" class="required">*</span>
|
||||
</label>
|
||||
<input type="text"
|
||||
id="project-name"
|
||||
required
|
||||
aria-describedby="name-help">
|
||||
<div id="name-help" class="help-text">
|
||||
Enter a descriptive name for your project
|
||||
</div>
|
||||
|
||||
<label for="project-type">Project Type</label>
|
||||
<select id="project-type" aria-describedby="type-help">
|
||||
<option value="">Select project type</option>
|
||||
<option value="web">Web Application</option>
|
||||
<option value="mobile">Mobile Application</option>
|
||||
<option value="api">API Service</option>
|
||||
</select>
|
||||
<div id="type-help" class="help-text">
|
||||
Choose the primary type of project you're building
|
||||
</div>
|
||||
</fieldset>
|
||||
</form>
|
||||
\```
|
||||
|
||||
### Screen Reader Announcements
|
||||
|
||||
\```javascript
|
||||
// Live region for dynamic content updates
|
||||
class AccessibleNotifications {
|
||||
constructor() {
|
||||
this.createLiveRegion();
|
||||
}
|
||||
|
||||
createLiveRegion() {
|
||||
const liveRegion = document.createElement('div');
|
||||
liveRegion.setAttribute('aria-live', 'polite');
|
||||
liveRegion.setAttribute('aria-atomic', 'true');
|
||||
liveRegion.className = 'sr-only';
|
||||
liveRegion.id = 'live-region';
|
||||
document.body.appendChild(liveRegion);
|
||||
}
|
||||
|
||||
announce(message, priority = 'polite') {
|
||||
const liveRegion = document.getElementById('live-region');
|
||||
liveRegion.setAttribute('aria-live', priority);
|
||||
liveRegion.textContent = message;
|
||||
|
||||
// Clear after announcement
|
||||
setTimeout(() => {
|
||||
liveRegion.textContent = '';
|
||||
}, 1000);
|
||||
}
|
||||
}
|
||||
|
||||
// Usage examples
|
||||
const notifications = new AccessibleNotifications();
|
||||
|
||||
// Announce progress updates
|
||||
notifications.announce('Step 1 of 4 completed');
|
||||
|
||||
// Announce errors with assertive priority
|
||||
notifications.announce('Error: Please fill in all required fields', 'assertive');
|
||||
|
||||
// Announce success
|
||||
notifications.announce('Project created successfully');
|
||||
\```
|
||||
|
||||
## Image and Media Accessibility
|
||||
|
||||
### Alternative Text Guidelines
|
||||
|
||||
\```html
|
||||
<!-- Informative images -->
|
||||
<img src="bmad-workflow-diagram.png"
|
||||
alt="BMAD workflow diagram showing four connected steps: Requirements gathering by Product Owner, Architecture design by System Architect, UI/UX design by Designer, and Implementation by Developer">
|
||||
|
||||
<!-- Decorative images -->
|
||||
<img src="decorative-pattern.png"
|
||||
alt=""
|
||||
role="presentation">
|
||||
|
||||
<!-- Complex images with detailed descriptions -->
|
||||
<figure>
|
||||
<img src="system-architecture.png"
|
||||
alt="BMAD system architecture overview"
|
||||
aria-describedby="arch-description">
|
||||
<figcaption id="arch-description">
|
||||
The system architecture shows three main layers:
|
||||
Presentation layer with web and mobile interfaces,
|
||||
Application layer with orchestrator and persona management,
|
||||
and Data layer with knowledge base and templates.
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
<!-- Interactive images -->
|
||||
<div class="interactive-diagram" role="img" aria-label="Interactive BMAD workflow">
|
||||
<button aria-label="Requirements phase - click for details">
|
||||
<img src="requirements-icon.png" alt="">
|
||||
Requirements
|
||||
</button>
|
||||
<button aria-label="Architecture phase - click for details">
|
||||
<img src="architecture-icon.png" alt="">
|
||||
Architecture
|
||||
</button>
|
||||
</div>
|
||||
\```
|
||||
|
||||
### Video and Audio Accessibility
|
||||
|
||||
\```html
|
||||
<!-- Video with captions and transcripts -->
|
||||
<video controls aria-describedby="video-description">
|
||||
<source src="bmad-introduction.mp4" type="video/mp4">
|
||||
<track kind="captions"
|
||||
src="bmad-introduction-captions.vtt"
|
||||
srclang="en"
|
||||
label="English captions">
|
||||
<track kind="descriptions"
|
||||
src="bmad-introduction-descriptions.vtt"
|
||||
srclang="en"
|
||||
label="Audio descriptions">
|
||||
Your browser does not support the video tag.
|
||||
</video>
|
||||
|
||||
<div id="video-description">
|
||||
<h4>Video Description</h4>
|
||||
<p>This video introduces the BMAD Method, showing how different personas collaborate...</p>
|
||||
<details>
|
||||
<summary>Full Transcript</summary>
|
||||
<p>Welcome to the BMAD Method introduction...</p>
|
||||
</details>
|
||||
</div>
|
||||
\```
|
||||
|
||||
## Testing and Validation
|
||||
|
||||
### Accessibility Testing Checklist
|
||||
|
||||
- [ ] **Keyboard Navigation**
|
||||
- [ ] All interactive elements are keyboard accessible
|
||||
- [ ] Tab order is logical and intuitive
|
||||
- [ ] Focus indicators are clearly visible
|
||||
- [ ] No keyboard traps exist
|
||||
|
||||
- [ ] **Screen Reader Compatibility**
|
||||
- [ ] Content is properly structured with headings
|
||||
- [ ] Images have appropriate alt text
|
||||
- [ ] Form labels are properly associated
|
||||
- [ ] ARIA attributes are used correctly
|
||||
|
||||
- [ ] **Color and Contrast**
|
||||
- [ ] Text meets WCAG AA contrast requirements
|
||||
- [ ] Color is not the only means of conveying information
|
||||
- [ ] Interactive elements have sufficient contrast
|
||||
|
||||
- [ ] **Responsive Design**
|
||||
- [ ] Content is readable at 200% zoom
|
||||
- [ ] No horizontal scrolling at standard zoom levels
|
||||
- [ ] Touch targets are at least 44px
|
||||
|
||||
- [ ] **Motion and Animation**
|
||||
- [ ] Animations can be disabled via prefers-reduced-motion
|
||||
- [ ] No content flashes more than 3 times per second
|
||||
- [ ] Auto-playing media can be paused
|
||||
|
||||
### Automated Testing Tools
|
||||
|
||||
\```javascript
|
||||
// Example accessibility testing with axe-core
|
||||
import { axe, toHaveNoViolations } from 'jest-axe';
|
||||
|
||||
expect.extend(toHaveNoViolations);
|
||||
|
||||
test('BMAD documentation should be accessible', async () => {
|
||||
const { container } = render(<BMADDocumentation />);
|
||||
const results = await axe(container);
|
||||
expect(results).toHaveNoViolations();
|
||||
});
|
||||
|
||||
// Manual testing helpers
|
||||
function announceToScreenReader(message) {
|
||||
const announcement = document.createElement('div');
|
||||
announcement.setAttribute('aria-live', 'polite');
|
||||
announcement.setAttribute('aria-atomic', 'true');
|
||||
announcement.className = 'sr-only';
|
||||
announcement.textContent = message;
|
||||
|
||||
document.body.appendChild(announcement);
|
||||
|
||||
setTimeout(() => {
|
||||
document.body.removeChild(announcement);
|
||||
}, 1000);
|
||||
}
|
||||
\```
|
||||
|
||||
---
|
||||
|
||||
*Following these accessibility guidelines ensures that BMAD Method documentation is usable by everyone, regardless of their abilities or the assistive technologies they use.*
|
||||
|
|
@ -0,0 +1,622 @@
|
|||
# Interactive Documentation Examples
|
||||
|
||||
This document provides interactive examples and components that enhance the BMAD Method documentation experience.
|
||||
|
||||
## Interactive Workflow Visualizer
|
||||
|
||||
<div class="workflow-visualizer">
|
||||
<div class="workflow-header">
|
||||
<h3>BMAD Method Workflow</h3>
|
||||
<div class="workflow-controls">
|
||||
<button class="btn-play" onclick="startWorkflow()">▶️ Start</button>
|
||||
<button class="btn-reset" onclick="resetWorkflow()">🔄 Reset</button>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="workflow-canvas">
|
||||
<div class="workflow-step" id="step-1" data-step="requirements">
|
||||
<div class="step-icon">📋</div>
|
||||
<div class="step-title">Requirements</div>
|
||||
<div class="step-persona">Product Owner</div>
|
||||
</div>
|
||||
|
||||
<div class="workflow-arrow" id="arrow-1"></div>
|
||||
|
||||
<div class="workflow-step" id="step-2" data-step="architecture">
|
||||
<div class="step-icon">🏗️</div>
|
||||
<div class="step-title">Architecture</div>
|
||||
<div class="step-persona">System Architect</div>
|
||||
</div>
|
||||
|
||||
<div class="workflow-arrow" id="arrow-2"></div>
|
||||
|
||||
<div class="workflow-step" id="step-3" data-step="design">
|
||||
<div class="step-icon">🎨</div>
|
||||
<div class="step-title">Design</div>
|
||||
<div class="step-persona">UX/UI Designer</div>
|
||||
</div>
|
||||
|
||||
<div class="workflow-arrow" id="arrow-3"></div>
|
||||
|
||||
<div class="workflow-step" id="step-4" data-step="implementation">
|
||||
<div class="step-icon">💻</div>
|
||||
<div class="step-title">Implementation</div>
|
||||
<div class="step-persona">Developer</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="workflow-details" id="workflow-details">
|
||||
<div class="detail-panel" id="detail-requirements">
|
||||
<h4>Requirements Phase</h4>
|
||||
<p>Product Owner defines project scope, user stories, and acceptance criteria.</p>
|
||||
<ul>
|
||||
<li>Stakeholder interviews</li>
|
||||
<li>User story creation</li>
|
||||
<li>Acceptance criteria definition</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="detail-panel" id="detail-architecture">
|
||||
<h4>Architecture Phase</h4>
|
||||
<p>System Architect designs technical approach and system structure.</p>
|
||||
<ul>
|
||||
<li>Technology selection</li>
|
||||
<li>System design</li>
|
||||
<li>Integration planning</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="detail-panel" id="detail-design">
|
||||
<h4>Design Phase</h4>
|
||||
<p>UX/UI Designer creates user experience and interface specifications.</p>
|
||||
<ul>
|
||||
<li>User experience design</li>
|
||||
<li>Interface mockups</li>
|
||||
<li>Design system components</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="detail-panel" id="detail-implementation">
|
||||
<h4>Implementation Phase</h4>
|
||||
<p>Developer builds the solution according to specifications.</p>
|
||||
<ul>
|
||||
<li>Code implementation</li>
|
||||
<li>Testing and validation</li>
|
||||
<li>Documentation</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script>
|
||||
function startWorkflow() {
|
||||
const steps = document.querySelectorAll('.workflow-step');
|
||||
const arrows = document.querySelectorAll('.workflow-arrow');
|
||||
|
||||
steps.forEach(step => step.classList.remove('active', 'completed'));
|
||||
arrows.forEach(arrow => arrow.classList.remove('active'));
|
||||
|
||||
let currentStep = 0;
|
||||
const interval = setInterval(() => {
|
||||
if (currentStep > 0) {
|
||||
steps[currentStep - 1].classList.remove('active');
|
||||
steps[currentStep - 1].classList.add('completed');
|
||||
arrows[currentStep - 1].classList.add('active');
|
||||
}
|
||||
|
||||
if (currentStep < steps.length) {
|
||||
steps[currentStep].classList.add('active');
|
||||
showStepDetails(steps[currentStep].dataset.step);
|
||||
currentStep++;
|
||||
} else {
|
||||
clearInterval(interval);
|
||||
}
|
||||
}, 2000);
|
||||
}
|
||||
|
||||
function resetWorkflow() {
|
||||
const steps = document.querySelectorAll('.workflow-step');
|
||||
const arrows = document.querySelectorAll('.workflow-arrow');
|
||||
|
||||
steps.forEach(step => step.classList.remove('active', 'completed'));
|
||||
arrows.forEach(arrow => arrow.classList.remove('active'));
|
||||
|
||||
document.getElementById('workflow-details').style.display = 'none';
|
||||
}
|
||||
|
||||
function showStepDetails(stepName) {
|
||||
const detailsContainer = document.getElementById('workflow-details');
|
||||
const panels = document.querySelectorAll('.detail-panel');
|
||||
|
||||
panels.forEach(panel => panel.style.display = 'none');
|
||||
document.getElementById(`detail-${stepName}`).style.display = 'block';
|
||||
detailsContainer.style.display = 'block';
|
||||
}
|
||||
</script>
|
||||
|
||||
<style>
|
||||
.workflow-visualizer {
|
||||
border: 1px solid var(--bmad-gray-200);
|
||||
border-radius: 8px;
|
||||
padding: var(--space-6);
|
||||
margin: var(--space-6) 0;
|
||||
background: white;
|
||||
}
|
||||
|
||||
.workflow-header {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
margin-bottom: var(--space-6);
|
||||
}
|
||||
|
||||
.workflow-controls button {
|
||||
margin-left: var(--space-2);
|
||||
padding: var(--space-2) var(--space-4);
|
||||
border: none;
|
||||
border-radius: 4px;
|
||||
background: var(--bmad-primary);
|
||||
color: white;
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
.workflow-canvas {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: space-between;
|
||||
margin-bottom: var(--space-6);
|
||||
}
|
||||
|
||||
.workflow-step {
|
||||
text-align: center;
|
||||
padding: var(--space-4);
|
||||
border: 2px solid var(--bmad-gray-300);
|
||||
border-radius: 8px;
|
||||
background: var(--bmad-gray-50);
|
||||
transition: all 0.3s ease;
|
||||
min-width: 120px;
|
||||
}
|
||||
|
||||
.workflow-step.active {
|
||||
border-color: var(--bmad-primary);
|
||||
background: var(--bmad-primary);
|
||||
color: white;
|
||||
transform: scale(1.05);
|
||||
}
|
||||
|
||||
.workflow-step.completed {
|
||||
border-color: var(--bmad-success);
|
||||
background: var(--bmad-success);
|
||||
color: white;
|
||||
}
|
||||
|
||||
.step-icon {
|
||||
font-size: 2rem;
|
||||
margin-bottom: var(--space-2);
|
||||
}
|
||||
|
||||
.step-title {
|
||||
font-weight: 600;
|
||||
margin-bottom: var(--space-1);
|
||||
}
|
||||
|
||||
.step-persona {
|
||||
font-size: 0.875rem;
|
||||
opacity: 0.8;
|
||||
}
|
||||
|
||||
.workflow-arrow {
|
||||
width: 40px;
|
||||
height: 2px;
|
||||
background: var(--bmad-gray-300);
|
||||
position: relative;
|
||||
transition: background-color 0.3s ease;
|
||||
}
|
||||
|
||||
.workflow-arrow.active {
|
||||
background: var(--bmad-success);
|
||||
}
|
||||
|
||||
.workflow-arrow::after {
|
||||
content: '';
|
||||
position: absolute;
|
||||
right: -6px;
|
||||
top: -4px;
|
||||
width: 0;
|
||||
height: 0;
|
||||
border-left: 8px solid var(--bmad-gray-300);
|
||||
border-top: 5px solid transparent;
|
||||
border-bottom: 5px solid transparent;
|
||||
transition: border-left-color 0.3s ease;
|
||||
}
|
||||
|
||||
.workflow-arrow.active::after {
|
||||
border-left-color: var(--bmad-success);
|
||||
}
|
||||
|
||||
.workflow-details {
|
||||
display: none;
|
||||
background: var(--bmad-gray-50);
|
||||
border-radius: 6px;
|
||||
padding: var(--space-4);
|
||||
}
|
||||
|
||||
.detail-panel {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.detail-panel h4 {
|
||||
color: var(--bmad-primary);
|
||||
margin-bottom: var(--space-2);
|
||||
}
|
||||
|
||||
.detail-panel ul {
|
||||
margin-left: var(--space-4);
|
||||
}
|
||||
</style>
|
||||
|
||||
## Persona Comparison Tool
|
||||
|
||||
<div class="persona-comparison">
|
||||
<div class="comparison-header">
|
||||
<h3>Compare BMAD Personas</h3>
|
||||
<p>Select personas to compare their roles, expertise, and deliverables</p>
|
||||
</div>
|
||||
|
||||
<div class="persona-selector-grid">
|
||||
<label class="persona-checkbox">
|
||||
<input type="checkbox" value="pm" onchange="updateComparison()">
|
||||
<div class="persona-card">
|
||||
<div class="persona-icon">👔</div>
|
||||
<div class="persona-name">Project Manager</div>
|
||||
</div>
|
||||
</label>
|
||||
|
||||
<label class="persona-checkbox">
|
||||
<input type="checkbox" value="architect" onchange="updateComparison()">
|
||||
<div class="persona-card">
|
||||
<div class="persona-icon">🏗️</div>
|
||||
<div class="persona-name">System Architect</div>
|
||||
</div>
|
||||
</label>
|
||||
|
||||
<label class="persona-checkbox">
|
||||
<input type="checkbox" value="ux-ui" onchange="updateComparison()">
|
||||
<div class="persona-card">
|
||||
<div class="persona-icon">🎨</div>
|
||||
<div class="persona-name">UX/UI Designer</div>
|
||||
</div>
|
||||
</label>
|
||||
|
||||
<label class="persona-checkbox">
|
||||
<input type="checkbox" value="developer" onchange="updateComparison()">
|
||||
<div class="persona-card">
|
||||
<div class="persona-icon">💻</div>
|
||||
<div class="persona-name">Developer</div>
|
||||
</div>
|
||||
</label>
|
||||
</div>
|
||||
|
||||
<div class="comparison-table" id="comparison-table" style="display: none;">
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Aspect</th>
|
||||
<th class="persona-column" data-persona="pm">Project Manager</th>
|
||||
<th class="persona-column" data-persona="architect">System Architect</th>
|
||||
<th class="persona-column" data-persona="ux-ui">UX/UI Designer</th>
|
||||
<th class="persona-column" data-persona="developer">Developer</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><strong>Primary Focus</strong></td>
|
||||
<td class="persona-cell" data-persona="pm">Project coordination and delivery</td>
|
||||
<td class="persona-cell" data-persona="architect">Technical architecture and design</td>
|
||||
<td class="persona-cell" data-persona="ux-ui">User experience and interface</td>
|
||||
<td class="persona-cell" data-persona="developer">Code implementation and quality</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Key Deliverables</strong></td>
|
||||
<td class="persona-cell" data-persona="pm">PRDs, project plans, status reports</td>
|
||||
<td class="persona-cell" data-persona="architect">Architecture docs, technical specs</td>
|
||||
<td class="persona-cell" data-persona="ux-ui">Wireframes, prototypes, design systems</td>
|
||||
<td class="persona-cell" data-persona="developer">Code, tests, documentation</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Expertise Areas</strong></td>
|
||||
<td class="persona-cell" data-persona="pm">Planning, stakeholder management</td>
|
||||
<td class="persona-cell" data-persona="architect">System design, technology selection</td>
|
||||
<td class="persona-cell" data-persona="ux-ui">User research, visual design</td>
|
||||
<td class="persona-cell" data-persona="developer">Programming, testing, optimization</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>Typical Timeline</strong></td>
|
||||
<td class="persona-cell" data-persona="pm">Throughout project lifecycle</td>
|
||||
<td class="persona-cell" data-persona="architect">Early planning and design phases</td>
|
||||
<td class="persona-cell" data-persona="ux-ui">Design and early development</td>
|
||||
<td class="persona-cell" data-persona="developer">Implementation and testing phases</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<script>
|
||||
const personaData = {
|
||||
pm: { name: 'Project Manager', icon: '👔' },
|
||||
architect: { name: 'System Architect', icon: '🏗️' },
|
||||
'ux-ui': { name: 'UX/UI Designer', icon: '🎨' },
|
||||
developer: { name: 'Developer', icon: '💻' }
|
||||
};
|
||||
|
||||
function updateComparison() {
|
||||
const checkboxes = document.querySelectorAll('.persona-checkbox input[type="checkbox"]');
|
||||
const selectedPersonas = Array.from(checkboxes)
|
||||
.filter(cb => cb.checked)
|
||||
.map(cb => cb.value);
|
||||
|
||||
const table = document.getElementById('comparison-table');
|
||||
const columns = document.querySelectorAll('.persona-column');
|
||||
const cells = document.querySelectorAll('.persona-cell');
|
||||
|
||||
if (selectedPersonas.length === 0) {
|
||||
table.style.display = 'none';
|
||||
return;
|
||||
}
|
||||
|
||||
table.style.display = 'block';
|
||||
|
||||
// Show/hide columns based on selection
|
||||
columns.forEach(column => {
|
||||
const persona = column.dataset.persona;
|
||||
column.style.display = selectedPersonas.includes(persona) ? 'table-cell' : 'none';
|
||||
});
|
||||
|
||||
cells.forEach(cell => {
|
||||
const persona = cell.dataset.persona;
|
||||
cell.style.display = selectedPersonas.includes(persona) ? 'table-cell' : 'none';
|
||||
});
|
||||
}
|
||||
</script>
|
||||
|
||||
<style>
|
||||
.persona-comparison {
|
||||
border: 1px solid var(--bmad-gray-200);
|
||||
border-radius: 8px;
|
||||
padding: var(--space-6);
|
||||
margin: var(--space-6) 0;
|
||||
background: white;
|
||||
}
|
||||
|
||||
.comparison-header {
|
||||
text-align: center;
|
||||
margin-bottom: var(--space-6);
|
||||
}
|
||||
|
||||
.persona-selector-grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
|
||||
gap: var(--space-4);
|
||||
margin-bottom: var(--space-6);
|
||||
}
|
||||
|
||||
.persona-checkbox {
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
.persona-checkbox input[type="checkbox"] {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.persona-card {
|
||||
border: 2px solid var(--bmad-gray-300);
|
||||
border-radius: 8px;
|
||||
padding: var(--space-4);
|
||||
text-align: center;
|
||||
transition: all 0.2s ease;
|
||||
background: white;
|
||||
}
|
||||
|
||||
.persona-checkbox input[type="checkbox"]:checked + .persona-card {
|
||||
border-color: var(--bmad-primary);
|
||||
background: var(--bmad-primary);
|
||||
color: white;
|
||||
}
|
||||
|
||||
.persona-icon {
|
||||
font-size: 2rem;
|
||||
margin-bottom: var(--space-2);
|
||||
}
|
||||
|
||||
.persona-name {
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.comparison-table {
|
||||
overflow-x: auto;
|
||||
}
|
||||
|
||||
.comparison-table table {
|
||||
width: 100%;
|
||||
border-collapse: collapse;
|
||||
background: white;
|
||||
border-radius: 6px;
|
||||
overflow: hidden;
|
||||
box-shadow: 0 1px 3px rgba(0, 0, 0, 0.1);
|
||||
}
|
||||
|
||||
.comparison-table th,
|
||||
.comparison-table td {
|
||||
padding: var(--space-3);
|
||||
text-align: left;
|
||||
border-bottom: 1px solid var(--bmad-gray-200);
|
||||
}
|
||||
|
||||
.comparison-table th {
|
||||
background: var(--bmad-gray-50);
|
||||
font-weight: 600;
|
||||
color: var(--bmad-gray-900);
|
||||
}
|
||||
|
||||
.comparison-table tr:hover {
|
||||
background: var(--bmad-gray-50);
|
||||
}
|
||||
</style>
|
||||
|
||||
## Progress Tracking Component
|
||||
|
||||
<div class="progress-tracker">
|
||||
<div class="tracker-header">
|
||||
<h3>Sprint Progress Tracker</h3>
|
||||
<div class="progress-summary">
|
||||
<span class="progress-text">Sprint 2 Progress</span>
|
||||
<span class="progress-percentage">85%</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="progress-bar">
|
||||
<div class="progress-fill" style="width: 85%"></div>
|
||||
</div>
|
||||
|
||||
<div class="story-list">
|
||||
<div class="story-item completed">
|
||||
<div class="story-status">✅</div>
|
||||
<div class="story-content">
|
||||
<div class="story-title">Story 2.1: "How It Works" Documentation</div>
|
||||
<div class="story-points">13 points</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="story-item completed">
|
||||
<div class="story-status">✅</div>
|
||||
<div class="story-content">
|
||||
<div class="story-title">Story 2.2: System Architecture Diagrams</div>
|
||||
<div class="story-points">8 points</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="story-item completed">
|
||||
<div class="story-status">✅</div>
|
||||
<div class="story-content">
|
||||
<div class="story-title">Story 2.3: User Journey Documentation</div>
|
||||
<div class="story-points">8 points</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="story-item in-progress">
|
||||
<div class="story-status">🔄</div>
|
||||
<div class="story-content">
|
||||
<div class="story-title">Story 2.4: Visual Documentation Elements</div>
|
||||
<div class="story-points">5 points</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div class="tracker-footer">
|
||||
<div class="velocity-info">
|
||||
<span>Team Velocity: 34 points/sprint</span>
|
||||
<span>Completed: 29/34 points</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<style>
|
||||
.progress-tracker {
|
||||
border: 1px solid var(--bmad-gray-200);
|
||||
border-radius: 8px;
|
||||
padding: var(--space-6);
|
||||
margin: var(--space-6) 0;
|
||||
background: white;
|
||||
}
|
||||
|
||||
.tracker-header {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: center;
|
||||
margin-bottom: var(--space-4);
|
||||
}
|
||||
|
||||
.progress-summary {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: var(--space-2);
|
||||
}
|
||||
|
||||
.progress-percentage {
|
||||
font-size: 1.5rem;
|
||||
font-weight: 700;
|
||||
color: var(--bmad-primary);
|
||||
}
|
||||
|
||||
.progress-bar {
|
||||
width: 100%;
|
||||
height: 8px;
|
||||
background: var(--bmad-gray-200);
|
||||
border-radius: 4px;
|
||||
overflow: hidden;
|
||||
margin-bottom: var(--space-6);
|
||||
}
|
||||
|
||||
.progress-fill {
|
||||
height: 100%;
|
||||
background: linear-gradient(90deg, var(--bmad-primary), var(--bmad-success));
|
||||
transition: width 0.3s ease;
|
||||
}
|
||||
|
||||
.story-list {
|
||||
space-y: var(--space-3);
|
||||
}
|
||||
|
||||
.story-item {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
padding: var(--space-3);
|
||||
border-radius: 6px;
|
||||
margin-bottom: var(--space-2);
|
||||
}
|
||||
|
||||
.story-item.completed {
|
||||
background: var(--bmad-gray-50);
|
||||
border-left: 4px solid var(--bmad-success);
|
||||
}
|
||||
|
||||
.story-item.in-progress {
|
||||
background: var(--bmad-gray-50);
|
||||
border-left: 4px solid var(--bmad-primary);
|
||||
}
|
||||
|
||||
.story-status {
|
||||
font-size: 1.25rem;
|
||||
margin-right: var(--space-3);
|
||||
}
|
||||
|
||||
.story-content {
|
||||
flex: 1;
|
||||
}
|
||||
|
||||
.story-title {
|
||||
font-weight: 600;
|
||||
margin-bottom: var(--space-1);
|
||||
}
|
||||
|
||||
.story-points {
|
||||
font-size: 0.875rem;
|
||||
color: var(--bmad-gray-600);
|
||||
}
|
||||
|
||||
.tracker-footer {
|
||||
margin-top: var(--space-4);
|
||||
padding-top: var(--space-4);
|
||||
border-top: 1px solid var(--bmad-gray-200);
|
||||
}
|
||||
|
||||
.velocity-info {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
font-size: 0.875rem;
|
||||
color: var(--bmad-gray-600);
|
||||
}
|
||||
</style>
|
||||
|
||||
*These interactive examples demonstrate how visual elements can enhance understanding and engagement with BMAD Method documentation.*
|
||||
|
|
@ -22,8 +22,20 @@ flowchart TD
|
|||
PM_C --> PM_PRD
|
||||
end
|
||||
|
||||
%% Phase 2: Architect
|
||||
subgraph ARCH["Phase 2: Architect"]
|
||||
%% Phase 2: UX/UI Design (NEW)
|
||||
subgraph UXUI["Phase 2: v0 UX/UI Architect"]
|
||||
UXUI_S["UX/UI Specification Creation"]
|
||||
UXUI_P["Rapid Prototyping"]
|
||||
UXUI_C["Component Design"]
|
||||
UXUI_V["Design Validation"]
|
||||
|
||||
UXUI_S --> UXUI_P
|
||||
UXUI_P --> UXUI_C
|
||||
UXUI_C --> UXUI_V
|
||||
end
|
||||
|
||||
%% Phase 3: Architect
|
||||
subgraph ARCH["Phase 3: System Architect"]
|
||||
ARCH_P["Architecture Package Creation"]
|
||||
ARCH_C["Architect Checklist Verification"]
|
||||
ARCH_D["PRD+Architecture and Artifacts"]
|
||||
|
|
@ -32,20 +44,30 @@ flowchart TD
|
|||
ARCH_C --> ARCH_D
|
||||
end
|
||||
|
||||
%% Phase 3: PO
|
||||
subgraph PO["Phase 3: Product Owner"]
|
||||
%% Phase 4: Design Architect (Frontend)
|
||||
subgraph DESIGN["Phase 4: Design Architect"]
|
||||
DESIGN_FE["Frontend Architecture"]
|
||||
DESIGN_AI["AI UI Generation Prompts"]
|
||||
DESIGN_C["Design System Integration"]
|
||||
|
||||
DESIGN_FE --> DESIGN_AI
|
||||
DESIGN_AI --> DESIGN_C
|
||||
end
|
||||
|
||||
%% Phase 5: PO
|
||||
subgraph PO["Phase 5: Product Owner"]
|
||||
PO_C["PO Checklist Verification"]
|
||||
PO_A["Approval"]
|
||||
end
|
||||
|
||||
%% Phase 4: SM
|
||||
subgraph SM["Phase 4: Scrum Master"]
|
||||
%% Phase 6: SM
|
||||
subgraph SM["Phase 6: Scrum Master"]
|
||||
SM_S["Draft Next Story"]
|
||||
SM_A["User Story Approval"]
|
||||
end
|
||||
|
||||
%% Phase 5: Developer
|
||||
subgraph DEV["Phase 5: Developer"]
|
||||
%% Phase 7: Developer
|
||||
subgraph DEV["Phase 7: Developer"]
|
||||
DEV_I["Implement Story"]
|
||||
DEV_T["Test"]
|
||||
DEV_D["Deploy"]
|
||||
|
|
@ -59,25 +81,38 @@ flowchart TD
|
|||
%% Connections between phases
|
||||
BA_P --> PM_M
|
||||
User_Input[/"User Direct Input"/] --> PM_M
|
||||
PM_PRD --> ARCH_P
|
||||
ARCH_D --> PO_C
|
||||
PM_PRD --> UXUI_S
|
||||
UXUI_V --> ARCH_P
|
||||
ARCH_D --> DESIGN_FE
|
||||
DESIGN_C --> PO_C
|
||||
PO_C --> PO_A
|
||||
PO_A --> SM_S
|
||||
SM_S --> SM_A
|
||||
SM_A --> DEV_I
|
||||
DEV_A --> SM_S
|
||||
|
||||
%% Optional paths
|
||||
PM_PRD -.-> ARCH_P
|
||||
UXUI_V -.-> DESIGN_FE
|
||||
|
||||
%% Completion condition
|
||||
DEV_A -- "All stories complete" --> DONE["Project Complete"]
|
||||
|
||||
%% Styling
|
||||
%% Styling - Split into manageable chunks
|
||||
classDef phase fill:#1a73e8,stroke:#0d47a1,stroke-width:2px,color:white,font-size:14px
|
||||
classDef artifact fill:#43a047,stroke:#1b5e20,stroke-width:1px,color:white,font-size:14px
|
||||
classDef process fill:#ff9800,stroke:#e65100,stroke-width:1px,color:white,font-size:14px
|
||||
classDef approval fill:#d81b60,stroke:#880e4f,stroke-width:1px,color:white,font-size:14px
|
||||
|
||||
class BA,PM,ARCH,PO,SM,DEV phase
|
||||
class BA_P,PM_PRD,ARCH_D artifact
|
||||
class BA_B,BA_R,PM_D,PM_M,ARCH_P,SM_S,DEV_I,DEV_T,DEV_D process
|
||||
%% Apply phase styling
|
||||
class BA,PM,UXUI,ARCH,DESIGN,PO,SM,DEV phase
|
||||
|
||||
%% Apply artifact styling
|
||||
class BA_P,PM_PRD,UXUI_V,ARCH_D,DESIGN_C artifact
|
||||
|
||||
%% Apply process styling
|
||||
class BA_B,BA_R,PM_D,PM_M,UXUI_S,UXUI_P,UXUI_C process
|
||||
class ARCH_P,DESIGN_FE,DESIGN_AI,SM_S,DEV_I,DEV_T,DEV_D process
|
||||
|
||||
%% Apply approval styling
|
||||
class PM_C,ARCH_C,PO_C,PO_A,SM_A,DEV_A approval
|
||||
```
|
||||
|
|
|
|||
|
|
@ -0,0 +1,639 @@
|
|||
# Dashboard Component Code Implementation
|
||||
|
||||
This file contains the complete code implementation for the dashboard component example.
|
||||
|
||||
## Initial Implementation
|
||||
|
||||
```tsx
|
||||
import React from 'react';
|
||||
import { Card, CardContent, CardHeader, CardTitle } from '@/components/ui/card';
|
||||
import { Avatar, AvatarFallback, AvatarImage } from '@/components/ui/avatar';
|
||||
import { Users, Activity, DollarSign, BarChart, ArrowUp, ArrowDown, Bell, Settings } from 'lucide-react';
|
||||
|
||||
interface DashboardProps {
|
||||
metrics: {
|
||||
totalUsers: number;
|
||||
activeUsers: number;
|
||||
revenue: number;
|
||||
conversionRate: number;
|
||||
};
|
||||
recentActivity: Array<{
|
||||
id: string;
|
||||
user: {
|
||||
name: string;
|
||||
avatar?: string;
|
||||
};
|
||||
action: string;
|
||||
timestamp: string;
|
||||
}>;
|
||||
userData: {
|
||||
name: string;
|
||||
email: string;
|
||||
avatar?: string;
|
||||
role: string;
|
||||
};
|
||||
}
|
||||
|
||||
export function Dashboard({ metrics, recentActivity, userData }: DashboardProps) {
|
||||
return (
|
||||
<div className="flex flex-col gap-6">
|
||||
{/* Header */}
|
||||
<div className="flex flex-col sm:flex-row justify-between items-start sm:items-center gap-4">
|
||||
<div>
|
||||
<h1 className="text-2xl font-bold text-slate-900">Dashboard</h1>
|
||||
<p className="text-slate-500">Welcome back, {userData.name}</p>
|
||||
</div>
|
||||
<div className="flex items-center gap-2">
|
||||
<button className="p-2 rounded-full bg-white text-slate-700 hover:bg-slate-100">
|
||||
<Bell size={20} />
|
||||
</button>
|
||||
<button className="p-2 rounded-full bg-white text-slate-700 hover:bg-slate-100">
|
||||
<Settings size={20} />
|
||||
</button>
|
||||
<Avatar className="h-10 w-10">
|
||||
<AvatarImage src={userData.avatar || "/placeholder.svg"} alt={userData.name} />
|
||||
<AvatarFallback className="bg-blue-100 text-blue-600">
|
||||
{userData.name.split(' ').map(n => n[0]).join('')}
|
||||
</AvatarFallback>
|
||||
</Avatar>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
{/* Metrics */}
|
||||
<div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4">
|
||||
<MetricCard
|
||||
title="Total Users"
|
||||
value={metrics.totalUsers.toLocaleString()}
|
||||
icon={<Users className="h-5 w-5" />}
|
||||
trend={5.2}
|
||||
color="blue"
|
||||
/>
|
||||
<MetricCard
|
||||
title="Active Users"
|
||||
value={metrics.activeUsers.toLocaleString()}
|
||||
icon={<Activity className="h-5 w-5" />}
|
||||
trend={2.4}
|
||||
color="emerald"
|
||||
/>
|
||||
<MetricCard
|
||||
title="Revenue"
|
||||
value={`$${metrics.revenue.toLocaleString()}`}
|
||||
icon={<DollarSign className="h-5 w-5" />}
|
||||
trend={8.7}
|
||||
color="blue"
|
||||
/>
|
||||
<MetricCard
|
||||
title="Conversion Rate"
|
||||
value={`${metrics.conversionRate}%`}
|
||||
icon={<BarChart className="h-5 w-5" />}
|
||||
trend={-1.5}
|
||||
color="slate"
|
||||
/>
|
||||
</div>
|
||||
|
||||
{/* Content Area */}
|
||||
<div className="grid grid-cols-1 lg:grid-cols-3 gap-6">
|
||||
{/* Recent Activity */}
|
||||
<Card className="lg:col-span-2">
|
||||
<CardHeader>
|
||||
<CardTitle>Recent Activity</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent>
|
||||
<div className="space-y-4">
|
||||
{recentActivity.map((activity) => (
|
||||
<div key={activity.id} className="flex items-start gap-4">
|
||||
<Avatar className="h-8 w-8">
|
||||
<AvatarImage src={activity.user.avatar || "/placeholder.svg"} alt={activity.user.name} />
|
||||
<AvatarFallback className="bg-slate-100 text-slate-600">
|
||||
{activity.user.name.split(' ').map(n => n[0]).join('')}
|
||||
</AvatarFallback>
|
||||
</Avatar>
|
||||
<div className="flex-1">
|
||||
<p className="text-sm font-medium">{activity.user.name}</p>
|
||||
<p className="text-sm text-slate-500">{activity.action}</p>
|
||||
</div>
|
||||
<p className="text-xs text-slate-400">{activity.timestamp}</p>
|
||||
</div>
|
||||
))}
|
||||
</div>
|
||||
</CardContent>
|
||||
</Card>
|
||||
|
||||
{/* User Profile */}
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>Your Profile</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent>
|
||||
<div className="flex flex-col items-center gap-4">
|
||||
<Avatar className="h-20 w-20">
|
||||
<AvatarImage src={userData.avatar || "/placeholder.svg"} alt={userData.name} />
|
||||
<AvatarFallback className="bg-blue-100 text-blue-600 text-xl">
|
||||
{userData.name.split(' ').map(n => n[0]).join('')}
|
||||
</AvatarFallback>
|
||||
</Avatar>
|
||||
<div className="text-center">
|
||||
<h3 className="font-medium text-lg">{userData.name}</h3>
|
||||
<p className="text-slate-500">{userData.email}</p>
|
||||
<p className="text-xs bg-blue-100 text-blue-600 px-2 py-1 rounded-full mt-2 inline-block">
|
||||
{userData.role}
|
||||
</p>
|
||||
</div>
|
||||
<div className="w-full border-t border-slate-200 pt-4 mt-2">
|
||||
<button className="w-full bg-blue-600 hover:bg-blue-700 text-white py-2 rounded-md">
|
||||
Edit Profile
|
||||
</button>
|
||||
</div>
|
||||
</div>
|
||||
</CardContent>
|
||||
</Card>
|
||||
</div>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
interface MetricCardProps {
|
||||
title: string;
|
||||
value: string;
|
||||
icon: React.ReactNode;
|
||||
trend: number;
|
||||
color: 'blue' | 'emerald' | 'slate';
|
||||
}
|
||||
|
||||
function MetricCard({ title, value, icon, trend, color }: MetricCardProps) {
|
||||
const colorClasses = {
|
||||
blue: {
|
||||
bg: 'bg-blue-50',
|
||||
text: 'text-blue-600',
|
||||
icon: 'bg-blue-100 text-blue-600',
|
||||
},
|
||||
emerald: {
|
||||
bg: 'bg-emerald-50',
|
||||
text: 'text-emerald-600',
|
||||
icon: 'bg-emerald-100 text-emerald-600',
|
||||
},
|
||||
slate: {
|
||||
bg: 'bg-slate-50',
|
||||
text: 'text-slate-600',
|
||||
icon: 'bg-slate-100 text-slate-600',
|
||||
},
|
||||
};
|
||||
|
||||
return (
|
||||
<Card className={`${colorClasses[color].bg} border-none`}>
|
||||
<CardContent className="p-6">
|
||||
<div className="flex justify-between items-start">
|
||||
<div>
|
||||
<p className="text-sm font-medium text-slate-500">{title}</p>
|
||||
<p className={`text-2xl font-bold ${colorClasses[color].text} mt-1`}>{value}</p>
|
||||
</div>
|
||||
<div className={`p-2 rounded-full ${colorClasses[color].icon}`}>
|
||||
{icon}
|
||||
</div>
|
||||
</div>
|
||||
<div className="mt-4 flex items-center">
|
||||
{trend >= 0 ? (
|
||||
<ArrowUp className="h-4 w-4 text-emerald-500" />
|
||||
) : (
|
||||
<ArrowDown className="h-4 w-4 text-red-500" />
|
||||
)}
|
||||
<span className={trend >= 0 ? 'text-emerald-500' : 'text-red-500'}>
|
||||
{Math.abs(trend)}%
|
||||
</span>
|
||||
<span className="text-slate-400 text-xs ml-1">vs last month</span>
|
||||
</div>
|
||||
</CardContent>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## Final Refined Implementation
|
||||
|
||||
```tsx
|
||||
import React, { useState } from 'react';
|
||||
import { Card, CardContent, CardHeader, CardTitle } from '@/components/ui/card';
|
||||
import { Avatar, AvatarFallback, AvatarImage } from '@/components/ui/avatar';
|
||||
import { Users, Activity, DollarSign, BarChart, ArrowUp, ArrowDown, Bell, Settings, Calendar } from 'lucide-react';
|
||||
import { Select, SelectContent, SelectItem, SelectTrigger, SelectValue } from '@/components/ui/select';
|
||||
import { Skeleton } from '@/components/ui/skeleton';
|
||||
|
||||
interface DashboardProps {
|
||||
metrics: {
|
||||
totalUsers: number;
|
||||
activeUsers: number;
|
||||
revenue: number;
|
||||
conversionRate: number;
|
||||
};
|
||||
recentActivity: Array<{
|
||||
id: string;
|
||||
user: {
|
||||
name: string;
|
||||
avatar?: string;
|
||||
};
|
||||
action: string;
|
||||
timestamp: string;
|
||||
}>;
|
||||
userData: {
|
||||
name: string;
|
||||
email: string;
|
||||
avatar?: string;
|
||||
role: string;
|
||||
};
|
||||
isLoading?: boolean;
|
||||
}
|
||||
|
||||
export function Dashboard({
|
||||
metrics,
|
||||
recentActivity,
|
||||
userData,
|
||||
isLoading = false
|
||||
}: DashboardProps) {
|
||||
const [dateRange, setDateRange] = useState('last-30-days');
|
||||
|
||||
if (isLoading) {
|
||||
return <DashboardSkeleton />;
|
||||
}
|
||||
|
||||
return (
|
||||
<div className="flex flex-col gap-6">
|
||||
{/* Header */}
|
||||
<div className="flex flex-col sm:flex-row justify-between items-start sm:items-center gap-4">
|
||||
<div>
|
||||
<h1 className="text-2xl font-bold text-slate-900">Dashboard</h1>
|
||||
<p className="text-slate-500">Welcome back, {userData.name}</p>
|
||||
</div>
|
||||
<div className="flex items-center gap-2">
|
||||
<div className="flex items-center bg-white border border-slate-200 rounded-md px-3 py-1">
|
||||
<Calendar className="h-4 w-4 text-slate-500 mr-2" />
|
||||
<Select value={dateRange} onValueChange={setDateRange}>
|
||||
<SelectTrigger className="border-0 p-0 h-auto w-[140px] text-sm">
|
||||
<SelectValue placeholder="Select range" />
|
||||
</SelectTrigger>
|
||||
<SelectContent>
|
||||
<SelectItem value="today">Today</SelectItem>
|
||||
<SelectItem value="yesterday">Yesterday</SelectItem>
|
||||
<SelectItem value="last-7-days">Last 7 days</SelectItem>
|
||||
<SelectItem value="last-30-days">Last 30 days</SelectItem>
|
||||
<SelectItem value="this-month">This month</SelectItem>
|
||||
<SelectItem value="last-month">Last month</SelectItem>
|
||||
</SelectContent>
|
||||
</Select>
|
||||
</div>
|
||||
<button
|
||||
className="p-2 rounded-full bg-white text-slate-700 hover:bg-slate-100"
|
||||
aria-label="Notifications"
|
||||
>
|
||||
<Bell size={20} />
|
||||
</button>
|
||||
<button
|
||||
className="p-2 rounded-full bg-white text-slate-700 hover:bg-slate-100"
|
||||
aria-label="Settings"
|
||||
>
|
||||
<Settings size={20} />
|
||||
</button>
|
||||
<Avatar className="h-10 w-10">
|
||||
<AvatarImage src={userData.avatar || "/placeholder.svg"} alt={userData.name} />
|
||||
<AvatarFallback className="bg-blue-100 text-blue-600">
|
||||
{userData.name.split(' ').map(n => n[0]).join('')}
|
||||
</AvatarFallback>
|
||||
</Avatar>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
{/* Metrics */}
|
||||
<div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4" role="region" aria-label="Key metrics">
|
||||
<MetricCard
|
||||
title="Total Users"
|
||||
value={metrics.totalUsers.toLocaleString()}
|
||||
icon={<Users className="h-5 w-5" />}
|
||||
trend={5.2}
|
||||
color="blue"
|
||||
ariaLabel="Total users metric"
|
||||
/>
|
||||
<MetricCard
|
||||
title="Active Users"
|
||||
value={metrics.activeUsers.toLocaleString()}
|
||||
icon={<Activity className="h-5 w-5" />}
|
||||
trend={2.4}
|
||||
color="emerald"
|
||||
ariaLabel="Active users metric"
|
||||
/>
|
||||
<MetricCard
|
||||
title="Revenue"
|
||||
value={`$${metrics.revenue.toLocaleString()}`}
|
||||
icon={<DollarSign className="h-5 w-5" />}
|
||||
trend={8.7}
|
||||
color="blue"
|
||||
ariaLabel="Revenue metric"
|
||||
/>
|
||||
<MetricCard
|
||||
title="Conversion Rate"
|
||||
value={`${metrics.conversionRate}%`}
|
||||
icon={<BarChart className="h-5 w-5" />}
|
||||
trend={-1.5}
|
||||
color="slate"
|
||||
ariaLabel="Conversion rate metric"
|
||||
/>
|
||||
</div>
|
||||
|
||||
{/* Content Area */}
|
||||
<div className="grid grid-cols-1 lg:grid-cols-3 gap-6">
|
||||
{/* Recent Activity */}
|
||||
<Card className="lg:col-span-2">
|
||||
<CardHeader>
|
||||
<CardTitle>Recent Activity</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent>
|
||||
<div className="space-y-4 max-h-[400px] overflow-y-auto pr-2" role="log" aria-label="Recent activity log">
|
||||
{recentActivity.length > 0 ? (
|
||||
recentActivity.map((activity) => (
|
||||
<div key={activity.id} className="flex items-start gap-4">
|
||||
<Avatar className="h-8 w-8">
|
||||
<AvatarImage src={activity.user.avatar || "/placeholder.svg"} alt={activity.user.name} />
|
||||
<AvatarFallback className="bg-slate-100 text-slate-600">
|
||||
{activity.user.name.split(' ').map(n => n[0]).join('')}
|
||||
</AvatarFallback>
|
||||
</Avatar>
|
||||
<div className="flex-1">
|
||||
<p className="text-sm font-medium">{activity.user.name}</p>
|
||||
<p className="text-sm text-slate-500">{activity.action}</p>
|
||||
</div>
|
||||
<p className="text-xs text-slate-400">{activity.timestamp}</p>
|
||||
</div>
|
||||
))
|
||||
) : (
|
||||
<p className="text-center text-slate-500 py-6">No recent activity</p>
|
||||
)}
|
||||
</div>
|
||||
</CardContent>
|
||||
</Card>
|
||||
|
||||
{/* User Profile */}
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>Your Profile</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent>
|
||||
<div className="flex flex-col items-center gap-4">
|
||||
<Avatar className="h-20 w-20">
|
||||
<AvatarImage src={userData.avatar || "/placeholder.svg"} alt={userData.name} />
|
||||
<AvatarFallback className="bg-blue-100 text-blue-600 text-xl">
|
||||
{userData.name.split(' ').map(n => n[0]).join('')}
|
||||
</AvatarFallback>
|
||||
</Avatar>
|
||||
<div className="text-center">
|
||||
<h3 className="font-medium text-lg">{userData.name}</h3>
|
||||
<p className="text-slate-500">{userData.email}</p>
|
||||
<p className="text-xs bg-blue-100 text-blue-600 px-2 py-1 rounded-full mt-2 inline-block">
|
||||
{userData.role}
|
||||
</p>
|
||||
</div>
|
||||
<div className="w-full border-t border-slate-200 pt-4 mt-2">
|
||||
<button
|
||||
className="w-full bg-blue-600 hover:bg-blue-700 text-white py-2 rounded-md focus:ring-2 focus:ring-blue-500 focus:ring-offset-2"
|
||||
aria-label="Edit your profile"
|
||||
>
|
||||
Edit Profile
|
||||
</button>
|
||||
</div>
|
||||
</div>
|
||||
</CardContent>
|
||||
</Card>
|
||||
</div>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
interface MetricCardProps {
|
||||
title: string;
|
||||
value: string;
|
||||
icon: React.ReactNode;
|
||||
trend: number;
|
||||
color: 'blue' | 'emerald' | 'slate';
|
||||
ariaLabel: string;
|
||||
}
|
||||
|
||||
function MetricCard({ title, value, icon, trend, color, ariaLabel }: MetricCardProps) {
|
||||
const colorClasses = {
|
||||
blue: {
|
||||
bg: 'bg-blue-50',
|
||||
text: 'text-blue-600',
|
||||
icon: 'bg-blue-100 text-blue-600',
|
||||
},
|
||||
emerald: {
|
||||
bg: 'bg-emerald-50',
|
||||
text: 'text-emerald-600',
|
||||
icon: 'bg-emerald-100 text-emerald-600',
|
||||
},
|
||||
slate: {
|
||||
bg: 'bg-slate-50',
|
||||
text: 'text-slate-600',
|
||||
icon: 'bg-slate-100 text-slate-600',
|
||||
},
|
||||
};
|
||||
|
||||
const trendText = `${Math.abs(trend)}% ${trend >= 0 ? 'increase' : 'decrease'} compared to last month`;
|
||||
|
||||
return (
|
||||
<Card className={`${colorClasses[color].bg} border-none`} aria-label={ariaLabel}>
|
||||
<CardContent className="p-6">
|
||||
<div className="flex justify-between items-start">
|
||||
<div>
|
||||
<p className="text-sm font-medium text-slate-500">{title}</p>
|
||||
<p className={`text-2xl font-bold ${colorClasses[color].text} mt-1`}>{value}</p>
|
||||
</div>
|
||||
<div className={`p-2 rounded-full ${colorClasses[color].icon}`} aria-hidden="true">
|
||||
{icon}
|
||||
</div>
|
||||
</div>
|
||||
<div className="mt-4 flex items-center" aria-label={trendText}>
|
||||
{trend >= 0 ? (
|
||||
<ArrowUp className="h-4 w-4 text-emerald-500" aria-hidden="true" />
|
||||
) : (
|
||||
<ArrowDown className="h-4 w-4 text-red-500" aria-hidden="true" />
|
||||
)}
|
||||
<span className={trend >= 0 ? 'text-emerald-500' : 'text-red-500'}>
|
||||
{Math.abs(trend)}%
|
||||
</span>
|
||||
<span className="text-slate-400 text-xs ml-1">vs last month</span>
|
||||
</div>
|
||||
</CardContent>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
function DashboardSkeleton() {
|
||||
return (
|
||||
<div className="flex flex-col gap-6">
|
||||
{/* Header Skeleton */}
|
||||
<div className="flex flex-col sm:flex-row justify-between items-start sm:items-center gap-4">
|
||||
<div>
|
||||
<Skeleton className="h-8 w-48" />
|
||||
<Skeleton className="h-4 w-32 mt-2" />
|
||||
</div>
|
||||
<div className="flex items-center gap-2">
|
||||
<Skeleton className="h-10 w-32 rounded-md" />
|
||||
<Skeleton className="h-10 w-10 rounded-full" />
|
||||
<Skeleton className="h-10 w-10 rounded-full" />
|
||||
<Skeleton className="h-10 w-10 rounded-full" />
|
||||
</div>
|
||||
</div>
|
||||
|
||||
{/* Metrics Skeleton */}
|
||||
<div className="grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-4 gap-4">
|
||||
{[1, 2, 3, 4].map((i) => (
|
||||
<Card key={i} className="bg-slate-50 border-none">
|
||||
<CardContent className="p-6">
|
||||
<div className="flex justify-between items-start">
|
||||
<div className="w-full">
|
||||
<Skeleton className="h-4 w-24" />
|
||||
<Skeleton className="h-8 w-20 mt-2" />
|
||||
<Skeleton className="h-4 w-32 mt-4" />
|
||||
</div>
|
||||
<Skeleton className="h-10 w-10 rounded-full" />
|
||||
</div>
|
||||
</CardContent>
|
||||
</Card>
|
||||
))}
|
||||
</div>
|
||||
|
||||
{/* Content Area Skeleton */}
|
||||
<div className="grid grid-cols-1 lg:grid-cols-3 gap-6">
|
||||
<Card className="lg:col-span-2">
|
||||
<CardHeader>
|
||||
<Skeleton className="h-6 w-32" />
|
||||
</CardHeader>
|
||||
<CardContent>
|
||||
<div className="space-y-4">
|
||||
{[1, 2, 3, 4].map((i) => (
|
||||
<div key={i} className="flex items-start gap-4">
|
||||
<Skeleton className="h-8 w-8 rounded-full" />
|
||||
<div className="flex-1">
|
||||
<Skeleton className="h-4 w-24" />
|
||||
<Skeleton className="h-3 w-48 mt-2" />
|
||||
</div>
|
||||
<Skeleton className="h-3 w-16" />
|
||||
</div>
|
||||
))}
|
||||
</div>
|
||||
</CardContent>
|
||||
</Card>
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<Skeleton className="h-6 w-24" />
|
||||
</CardHeader>
|
||||
<CardContent>
|
||||
<div className="flex flex-col items-center gap-4">
|
||||
<Skeleton className="h-20 w-20 rounded-full" />
|
||||
<div className="text-center w-full">
|
||||
<Skeleton className="h-5 w-32 mx-auto" />
|
||||
<Skeleton className="h-4 w-48 mx-auto mt-2" />
|
||||
<Skeleton className="h-6 w-16 mx-auto mt-2 rounded-full" />
|
||||
</div>
|
||||
<div className="w-full border-t border-slate-200 pt-4 mt-2">
|
||||
<Skeleton className="h-10 w-full rounded-md" />
|
||||
</div>
|
||||
</div>
|
||||
</CardContent>
|
||||
</Card>
|
||||
</div>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## Example Usage
|
||||
|
||||
```tsx
|
||||
// Example usage
|
||||
import { Dashboard } from './components/Dashboard';
|
||||
|
||||
export default function DashboardPage() {
|
||||
const [isLoading, setIsLoading] = useState(true);
|
||||
const [dashboardData, setDashboardData] = useState({
|
||||
metrics: {
|
||||
totalUsers: 0,
|
||||
activeUsers: 0,
|
||||
revenue: 0,
|
||||
conversionRate: 0
|
||||
},
|
||||
recentActivity: [],
|
||||
userData: {
|
||||
name: '',
|
||||
email: '',
|
||||
role: ''
|
||||
}
|
||||
});
|
||||
|
||||
useEffect(() => {
|
||||
// Simulate API call
|
||||
setTimeout(() => {
|
||||
setDashboardData({
|
||||
metrics: {
|
||||
totalUsers: 12487,
|
||||
activeUsers: 8761,
|
||||
revenue: 48395,
|
||||
conversionRate: 12.8
|
||||
},
|
||||
recentActivity: [
|
||||
{
|
||||
id: '1',
|
||||
user: {
|
||||
name: 'John Smith',
|
||||
avatar: '/avatars/john.jpg'
|
||||
},
|
||||
action: 'Created a new project "Q4 Marketing Campaign"',
|
||||
timestamp: '2 minutes ago'
|
||||
},
|
||||
{
|
||||
id: '2',
|
||||
user: {
|
||||
name: 'Sarah Johnson',
|
||||
avatar: '/avatars/sarah.jpg'
|
||||
},
|
||||
action: 'Updated the analytics dashboard settings',
|
||||
timestamp: '1 hour ago'
|
||||
},
|
||||
{
|
||||
id: '3',
|
||||
user: {
|
||||
name: 'Michael Brown',
|
||||
avatar: '/avatars/michael.jpg'
|
||||
},
|
||||
action: 'Invited 3 new team members',
|
||||
timestamp: '3 hours ago'
|
||||
},
|
||||
{
|
||||
id: '4',
|
||||
user: {
|
||||
name: 'Emily Davis',
|
||||
avatar: '/avatars/emily.jpg'
|
||||
},
|
||||
action: 'Completed the quarterly report',
|
||||
timestamp: 'Yesterday'
|
||||
}
|
||||
],
|
||||
userData: {
|
||||
name: 'Alex Morgan',
|
||||
email: 'alex.morgan@example.com',
|
||||
avatar: '/avatars/alex.jpg',
|
||||
role: 'Admin'
|
||||
}
|
||||
});
|
||||
setIsLoading(false);
|
||||
}, 1500);
|
||||
}, []);
|
||||
|
||||
return (
|
||||
<div className="container mx-auto px-4 py-6">
|
||||
<Dashboard
|
||||
metrics={dashboardData.metrics}
|
||||
recentActivity={dashboardData.recentActivity}
|
||||
userData={dashboardData.userData}
|
||||
isLoading={isLoading}
|
||||
/>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
|
@ -0,0 +1,117 @@
|
|||
# v0 UX/UI Architect Example: Dashboard Component
|
||||
|
||||
This example demonstrates how to use the v0 UX/UI Architect persona to create a modern, responsive dashboard component for a SaaS application.
|
||||
|
||||
## Project Brief
|
||||
|
||||
**Requirement**: Create a dashboard component for a SaaS analytics platform that displays key metrics, recent activity, and user information.
|
||||
|
||||
**Brand Colors**:
|
||||
- Primary: #3b82f6 (Blue)
|
||||
- Secondary: #64748b (Slate)
|
||||
- Accent: #10b981 (Emerald)
|
||||
- Background: #f8fafc (Light Gray)
|
||||
|
||||
**Technical Requirements**:
|
||||
- React with TypeScript
|
||||
- Tailwind CSS for styling
|
||||
- Responsive design (mobile, tablet, desktop)
|
||||
- Accessibility compliance (WCAG AA)
|
||||
|
||||
## Step 1: Initial Prompt to v0 UX/UI Architect
|
||||
|
||||
```
|
||||
Veronica, I need you to design a dashboard component for our SaaS analytics platform.
|
||||
It should display key metrics (total users, active users, revenue, conversion rate),
|
||||
recent activity, and user information. Our brand colors are blue (#3b82f6),
|
||||
slate (#64748b), emerald (#10b981), and light gray (#f8fafc) for backgrounds.
|
||||
The design should be responsive and follow accessibility best practices.
|
||||
```
|
||||
|
||||
## Step 2: Initial Design Concept
|
||||
|
||||
The v0 UX/UI Architect generated an initial design concept with the following key features:
|
||||
|
||||
- Header with user profile and action buttons
|
||||
- Four metric cards showing key performance indicators
|
||||
- Recent activity feed with user avatars and timestamps
|
||||
- User profile card with role information and actions
|
||||
|
||||
## Step 3: Feedback and Iteration
|
||||
|
||||
After reviewing the initial design, we provided feedback to improve the component:
|
||||
|
||||
```
|
||||
The design looks good, but we need to make a few adjustments:
|
||||
1. Add a date range selector at the top
|
||||
2. Make the metrics more accessible with proper ARIA labels
|
||||
3. Ensure the activity list is scrollable when there are many items
|
||||
4. Add a loading state for when data is being fetched
|
||||
```
|
||||
|
||||
## Step 4: Refined Implementation
|
||||
|
||||
The v0 UX/UI Architect provided a refined implementation that included:
|
||||
|
||||
- Date range selector in the header
|
||||
- ARIA labels for all interactive elements
|
||||
- Scrollable activity feed with proper height constraints
|
||||
- Loading skeleton state for all components
|
||||
- Improved accessibility throughout
|
||||
|
||||
## Step 5: Quality Assurance
|
||||
|
||||
We ran the component through our quality assurance process:
|
||||
|
||||
### Accessibility Testing
|
||||
|
||||
- ✅ Semantic HTML structure
|
||||
- ✅ ARIA labels for interactive elements
|
||||
- ✅ Proper focus management
|
||||
- ✅ Color contrast meets WCAG AA standards
|
||||
- ✅ Screen reader compatibility
|
||||
|
||||
### Responsive Testing
|
||||
|
||||
- ✅ Mobile layout (320px+)
|
||||
- ✅ Tablet layout (768px+)
|
||||
- ✅ Desktop layout (1024px+)
|
||||
- ✅ Touch-friendly targets
|
||||
- ✅ Proper content reflow
|
||||
|
||||
### Performance Testing
|
||||
|
||||
- ✅ Optimized rendering
|
||||
- ✅ Proper loading states
|
||||
- ✅ Efficient state management
|
||||
- ✅ Minimal bundle size impact
|
||||
|
||||
## Step 6: Final Implementation
|
||||
|
||||
The final dashboard component was integrated into our application with sample data and includes:
|
||||
|
||||
- Fully responsive layout that works on all device sizes
|
||||
- Accessible design with proper ARIA attributes and keyboard navigation
|
||||
- Loading states for improved user experience
|
||||
- Date range selector for filtering data
|
||||
- Metric cards with trend indicators
|
||||
- Scrollable activity feed
|
||||
- User profile with role information
|
||||
|
||||
## Lessons Learned
|
||||
|
||||
1. **Clear Requirements**: Providing specific brand colors and technical requirements resulted in a more accurate initial design
|
||||
2. **Iterative Approach**: The feedback cycle improved the component significantly
|
||||
3. **Accessibility Focus**: Explicitly requesting accessibility features ensured they were properly implemented
|
||||
4. **Loading States**: Including loading states improved the user experience during data fetching
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. Add data visualization components (charts, graphs)
|
||||
2. Implement dark mode support
|
||||
3. Add customization options for different user roles
|
||||
4. Create additional dashboard layouts for different use cases
|
||||
|
||||
This example demonstrates the complete workflow of using the v0 UX/UI Architect persona to create a production-ready dashboard component, from initial requirements through final implementation.
|
||||
|
||||
> **Note**: For the complete code implementation, see the [Dashboard Component Code](./dashboard-component-code.md) file.
|
||||
|
|
@ -0,0 +1,312 @@
|
|||
# Persona Documentation Template
|
||||
|
||||
This template provides the standard structure for all BMAD Method persona documentation.
|
||||
|
||||
## File Structure
|
||||
|
||||
Each persona should have the following documentation files:
|
||||
|
||||
```
|
||||
docs/
|
||||
├── {persona-name}-comprehensive-guide.md
|
||||
├── {persona-name}-integration-guide.md
|
||||
├── {persona-name}-quality-assurance.md
|
||||
└── {persona-name}-quickstart.md
|
||||
|
||||
examples/
|
||||
├── {persona-name}-example-project.md
|
||||
└── {persona-name}-example-code.md (if applicable)
|
||||
|
||||
bmad-agent/personas/
|
||||
├── {persona-name}.md (Web version)
|
||||
└── {persona-name}.ide.md (IDE version)
|
||||
```
|
||||
|
||||
## Template: Comprehensive Guide
|
||||
|
||||
```markdown
|
||||
# {Persona Name} Comprehensive Guide
|
||||
|
||||
## Introduction
|
||||
|
||||
Brief introduction to the persona, their role in the BMAD Method, and their core capabilities.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Core Capabilities](#core-capabilities)
|
||||
2. [When to Use](#when-to-use)
|
||||
3. [Activation Methods](#activation-methods)
|
||||
4. [Working Process](#working-process)
|
||||
5. [Input Requirements](#input-requirements)
|
||||
6. [Output Expectations](#output-expectations)
|
||||
7. [Integration with Other Personas](#integration-with-other-personas)
|
||||
8. [Best Practices](#best-practices)
|
||||
9. [Troubleshooting](#troubleshooting)
|
||||
10. [Advanced Usage](#advanced-usage)
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
List the primary capabilities and strengths of this persona:
|
||||
|
||||
- **Capability 1**: Description of what the persona excels at
|
||||
- **Capability 2**: Another key strength
|
||||
- **Capability 3**: Additional capability
|
||||
|
||||
## When to Use
|
||||
|
||||
Describe the ideal scenarios for using this persona:
|
||||
|
||||
- **Scenario 1**: When you need X
|
||||
- **Scenario 2**: During Y phase of the project
|
||||
- **Scenario 3**: For Z type of tasks
|
||||
|
||||
## Activation Methods
|
||||
|
||||
### Web Environment ({Web Persona Name})
|
||||
|
||||
```
|
||||
"I need {Web Persona Name} to help with {task type}"
|
||||
"Activate the {persona role} for {specific task}"
|
||||
```
|
||||
|
||||
### IDE Environment ({IDE Persona Name})
|
||||
|
||||
```
|
||||
"{IDE Persona Name}, I need you to {action} using {tools/framework}"
|
||||
"Help me {task} that integrates with our existing {system}"
|
||||
```
|
||||
|
||||
## Working Process
|
||||
|
||||
Describe the typical workflow when using this persona:
|
||||
|
||||
1. **Step 1**: Initial setup or requirements gathering
|
||||
2. **Step 2**: Analysis or planning phase
|
||||
3. **Step 3**: Implementation or execution
|
||||
4. **Step 4**: Review and refinement
|
||||
5. **Step 5**: Delivery and documentation
|
||||
|
||||
## Input Requirements
|
||||
|
||||
For optimal results, provide:
|
||||
|
||||
- **Requirement 1**: What information is needed
|
||||
- **Requirement 2**: Context or constraints
|
||||
- **Requirement 3**: Technical specifications
|
||||
- **Requirement 4**: Success criteria
|
||||
|
||||
## Output Expectations
|
||||
|
||||
The persona produces:
|
||||
|
||||
- **Output 1**: Type of deliverable
|
||||
- **Output 2**: Documentation or artifacts
|
||||
- **Output 3**: Recommendations or guidance
|
||||
|
||||
## Integration with Other Personas
|
||||
|
||||
Describe how this persona works with others in the BMAD Method:
|
||||
|
||||
- **{Other Persona}**: How they collaborate
|
||||
- **{Another Persona}**: Handoff procedures
|
||||
- **{Third Persona}**: Shared responsibilities
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Effective Usage
|
||||
|
||||
1. **Practice 1**: How to get the best results
|
||||
2. **Practice 2**: Common optimization techniques
|
||||
3. **Practice 3**: Quality assurance approaches
|
||||
|
||||
### Quality Assurance
|
||||
|
||||
- Run the {Persona} Quality Checklist after completion
|
||||
- Validate outputs against requirements
|
||||
- Ensure integration with existing systems
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues and Solutions
|
||||
|
||||
| Issue | Solution |
|
||||
|-------|----------|
|
||||
| Problem 1 | How to resolve it |
|
||||
| Problem 2 | Step-by-step fix |
|
||||
| Problem 3 | Alternative approaches |
|
||||
|
||||
## Advanced Usage
|
||||
|
||||
### Advanced Techniques
|
||||
|
||||
Describe sophisticated use cases and techniques for experienced users.
|
||||
|
||||
### Integration Patterns
|
||||
|
||||
Explain complex integration scenarios and patterns.
|
||||
|
||||
---
|
||||
|
||||
This comprehensive guide provides everything you need to effectively use the {Persona Name} persona in your development workflow.
|
||||
```
|
||||
```
|
||||
|
||||
## Template: Integration Guide
|
||||
|
||||
```markdown
|
||||
# {Persona Name} Integration Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This guide explains how to integrate the {Persona Name} persona into your development workflow.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Web Environment Integration](#web-environment-integration)
|
||||
2. [IDE Environment Integration](#ide-environment-integration)
|
||||
3. [BMAD Method Workflow Integration](#bmad-method-workflow-integration)
|
||||
4. [Third-Party Tool Integration](#third-party-tool-integration)
|
||||
5. [Configuration Options](#configuration-options)
|
||||
|
||||
## Web Environment Integration
|
||||
|
||||
### Setup Instructions
|
||||
|
||||
1. **Access the Web Orchestrator**
|
||||
2. **Load the {Persona Name} Persona**
|
||||
3. **Activate the Persona**
|
||||
|
||||
### Usage Examples
|
||||
|
||||
Provide specific examples of how to use the persona in web environments.
|
||||
|
||||
## IDE Environment Integration
|
||||
|
||||
### Supported IDEs
|
||||
|
||||
List supported development environments and setup instructions for each.
|
||||
|
||||
### Usage Examples
|
||||
|
||||
Show how to use the persona within different IDE environments.
|
||||
|
||||
## BMAD Method Workflow Integration
|
||||
|
||||
### Integration Points
|
||||
|
||||
Describe where this persona fits in the overall BMAD workflow.
|
||||
|
||||
### Workflow Diagram
|
||||
|
||||
```
|
||||
Previous Persona → {Current Persona} → Next Persona
|
||||
```
|
||||
|
||||
## Third-Party Tool Integration
|
||||
|
||||
List and describe integrations with external tools and services.
|
||||
|
||||
## Configuration Options
|
||||
|
||||
Document available configuration options and their usage.
|
||||
|
||||
---
|
||||
|
||||
This integration guide provides comprehensive instructions for incorporating the {Persona Name} persona into your development workflow.
|
||||
```
|
||||
```
|
||||
|
||||
## Template: Quality Assurance Guide
|
||||
|
||||
```markdown
|
||||
# {Persona Name} Quality Assurance Guide
|
||||
|
||||
This document provides comprehensive quality assurance procedures for evaluating outputs from the {Persona Name} persona.
|
||||
|
||||
## Quality Assurance Process
|
||||
|
||||
### Overview
|
||||
|
||||
Describe the QA process specific to this persona's outputs.
|
||||
|
||||
## Quality Checklists
|
||||
|
||||
### Primary Quality Checklist
|
||||
|
||||
- [ ] **Criterion 1**: Description of what to check
|
||||
- [ ] **Criterion 2**: Another quality measure
|
||||
- [ ] **Criterion 3**: Additional validation point
|
||||
|
||||
### Secondary Quality Checklist
|
||||
|
||||
- [ ] **Integration**: Works with other system components
|
||||
- [ ] **Documentation**: Properly documented
|
||||
- [ ] **Standards**: Follows established standards
|
||||
|
||||
## Testing Procedures
|
||||
|
||||
Describe specific testing procedures for this persona's outputs.
|
||||
|
||||
## Success Metrics
|
||||
|
||||
Define measurable success criteria for this persona's work.
|
||||
|
||||
---
|
||||
|
||||
This quality assurance guide ensures high-quality outputs from the {Persona Name} persona.
|
||||
```
|
||||
```
|
||||
|
||||
## Template: Quick Start Guide
|
||||
|
||||
```markdown
|
||||
# {Persona Name} Quick Start Guide
|
||||
|
||||
Get up and running with the {Persona Name} persona in just 5 minutes.
|
||||
|
||||
## 1. Choose Your Environment
|
||||
|
||||
Brief description of environment options.
|
||||
|
||||
## 2. Activate the Persona
|
||||
|
||||
Simple activation instructions.
|
||||
|
||||
## 3. Provide Clear Requirements
|
||||
|
||||
What information to provide for best results.
|
||||
|
||||
## 4. Review and Iterate
|
||||
|
||||
How to refine and improve outputs.
|
||||
|
||||
## 5. Implement and Test
|
||||
|
||||
Final steps to complete the work.
|
||||
|
||||
## Example: {Simple Use Case}
|
||||
|
||||
Step-by-step example of a common use case.
|
||||
|
||||
## Next Steps
|
||||
|
||||
Links to comprehensive documentation and advanced guides.
|
||||
|
||||
---
|
||||
|
||||
Start using the {Persona Name} persona effectively today!
|
||||
```
|
||||
```
|
||||
|
||||
## Usage Instructions
|
||||
|
||||
1. **Copy the appropriate template**
|
||||
2. **Replace all {placeholder} text** with persona-specific information
|
||||
3. **Customize sections** based on the persona's unique capabilities
|
||||
4. **Add persona-specific examples** and use cases
|
||||
5. **Validate against the quality checklist**
|
||||
|
||||
This template ensures consistency across all persona documentation while allowing for persona-specific customization.
|
||||
```
|
||||
|
||||
Now let's begin standardizing the first persona - Product Manager (John):
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
==================== START: advanced-elicitation ====================
|
||||
==================== START: advanced-elicitation ====================
|
||||
# Advanced Elicitation Task
|
||||
|
||||
## Purpose
|
||||
|
|
@ -15,7 +15,7 @@
|
|||
|
||||
**Present the numbered list (0-9) with this exact format:**
|
||||
|
||||
```
|
||||
\`\`\`
|
||||
**Advanced Reflective, Elicitation & Brainstorming Actions**
|
||||
Choose an action (0-9 - 9 to bypass - HELP for explanation of these options):
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ Choose an action (0-9 - 9 to bypass - HELP for explanation of these options):
|
|||
7. Explore Diverse Alternatives (ToT-Inspired)
|
||||
8. Hindsight is 20/20: The 'If Only...' Reflection
|
||||
9. Proceed / No Further Actions
|
||||
```
|
||||
\`\`\`
|
||||
|
||||
### 2. Processing Guidelines
|
||||
|
||||
|
|
@ -199,9 +199,9 @@ The BMAD Method uses various checklists to ensure quality and completeness of di
|
|||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
- Mark items as:
|
||||
- ✅ PASS: Requirement clearly met
|
||||
- ⌠FAIL: Requirement not met or insufficient coverage
|
||||
- âš ï¸ PARTIAL: Some aspects covered but needs improvement
|
||||
- ✅ PASS: Requirement clearly met
|
||||
- ❌ FAIL: Requirement not met or insufficient coverage
|
||||
- ⚠️ PARTIAL: Some aspects covered but needs improvement
|
||||
- N/A: Not applicable to this case
|
||||
|
||||
5. **Section Analysis**
|
||||
|
|
@ -1006,7 +1006,7 @@ To design a comprehensive infrastructure architecture that defines all aspects o
|
|||
|
||||
### 5. Implementation Feasibility Review & Collaboration
|
||||
|
||||
- **Architect → DevOps/Platform Feedback Loop:**
|
||||
- **Architect → DevOps/Platform Feedback Loop:**
|
||||
- Present architectural blueprint summary to DevOps/Platform Engineering Agent for feasibility review
|
||||
- Request specific feedback on:
|
||||
- **Operational Complexity:** Are the proposed patterns implementable with current tooling and expertise?
|
||||
|
|
@ -1126,7 +1126,7 @@ To identify the next logical story based on project progress and epic definition
|
|||
- Verify its `Status` is 'Done' (or equivalent).
|
||||
- If not 'Done', present an alert to the user:
|
||||
|
||||
```plaintext
|
||||
\`\`\`plaintext
|
||||
ALERT: Found incomplete story:
|
||||
File: {lastEpicNum}.{lastStoryNum}.story.md
|
||||
Status: [current status]
|
||||
|
|
@ -1137,7 +1137,7 @@ To identify the next logical story based on project progress and epic definition
|
|||
3. Accept risk & Override to create the next story in draft
|
||||
|
||||
Please choose an option (1/2/3):
|
||||
```
|
||||
\`\`\`
|
||||
|
||||
- Proceed only if user selects option 3 (Override) or if the last story was 'Done'.
|
||||
- If proceeding: Check the Epic File for `{lastEpicNum}` for a story numbered `{lastStoryNum + 1}`. If it exists and its prerequisites (per Epic File) are met, this is the next story.
|
||||
|
|
@ -1215,7 +1215,7 @@ To implement a comprehensive platform infrastructure stack based on the Infrastr
|
|||
### 1. Confirm Interaction Mode
|
||||
|
||||
- Ask the user: "How would you like to proceed with platform infrastructure implementation? We can work:
|
||||
A. **Incrementally (Default & Recommended):** We'll implement each platform layer step-by-step (Foundation → Container Platform → GitOps → Service Mesh → Developer Experience), validating integration at each stage. This ensures thorough testing and operational readiness.
|
||||
A. **Incrementally (Default & Recommended):** We'll implement each platform layer step-by-step (Foundation → Container Platform → GitOps → Service Mesh → Developer Experience), validating integration at each stage. This ensures thorough testing and operational readiness.
|
||||
B. **"YOLO" Mode:** I'll implement the complete platform stack in logical groups, with validation at major integration milestones. This is faster but requires comprehensive end-to-end testing."
|
||||
- Request the user to select their preferred mode and proceed accordingly.
|
||||
|
||||
|
|
@ -1230,7 +1230,7 @@ To implement a comprehensive platform infrastructure stack based on the Infrastr
|
|||
|
||||
### 3. Joint Implementation Planning Session
|
||||
|
||||
- **Architect ↔ DevOps/Platform Collaborative Planning:**
|
||||
- **Architect ↔ DevOps/Platform Collaborative Planning:**
|
||||
- **Architecture Alignment Review:**
|
||||
- Confirm understanding of architectural decisions and rationale with Architect Agent
|
||||
- Validate interpretation of infrastructure architecture document
|
||||
|
|
@ -1736,11 +1736,11 @@ You are now operating as a Documentation Indexer. Your goal is to ensure all doc
|
|||
|
||||
Each entry in `docs/index.md` should follow this format:
|
||||
|
||||
```markdown
|
||||
\`\`\`markdown
|
||||
### [Document Title](relative/path/to/file.md)
|
||||
|
||||
Brief description of the document's purpose and contents.
|
||||
```
|
||||
\`\`\`
|
||||
|
||||
### Rules of Operation
|
||||
|
||||
|
|
@ -1772,7 +1772,7 @@ For each file referenced in the index but not found in the filesystem:
|
|||
|
||||
1. Present the entry:
|
||||
|
||||
```markdown
|
||||
\`\`\`markdown
|
||||
Missing file detected:
|
||||
Title: [Document Title]
|
||||
Path: relative/path/to/file.md
|
||||
|
|
@ -1785,7 +1785,7 @@ For each file referenced in the index but not found in the filesystem:
|
|||
3. Keep entry (mark as temporarily unavailable)
|
||||
|
||||
Please choose an option (1/2/3):
|
||||
```
|
||||
\`\`\`
|
||||
|
||||
2. Wait for user confirmation before taking any action
|
||||
3. Log the decision for the final report
|
||||
|
|
@ -1871,7 +1871,7 @@ To conduct a thorough review of existing infrastructure to identify improvement
|
|||
|
||||
### 6. Architectural Escalation Assessment
|
||||
|
||||
- **DevOps/Platform → Architect Escalation Review:**
|
||||
- **DevOps/Platform → Architect Escalation Review:**
|
||||
- Evaluate review findings for issues requiring architectural intervention:
|
||||
- **Technical Debt Escalation:**
|
||||
- Identify infrastructure technical debt that impacts system architecture
|
||||
|
|
@ -2003,7 +2003,7 @@ To comprehensively validate platform infrastructure changes against security, re
|
|||
|
||||
### 3. Architecture Design Review Gate
|
||||
|
||||
- **DevOps/Platform → Architect Design Review:**
|
||||
- **DevOps/Platform → Architect Design Review:**
|
||||
- Conduct systematic review of infrastructure architecture document for implementability
|
||||
- Evaluate architectural decisions against operational constraints and capabilities:
|
||||
- **Implementation Complexity:** Assess if proposed architecture can be implemented with available tools and expertise
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
==================== START: architecture-tmpl ====================
|
||||
==================== START: architecture-tmpl ====================
|
||||
# {Project Name} Architecture Document
|
||||
|
||||
## Introduction / Preamble
|
||||
|
|
@ -46,47 +46,47 @@ If the project includes a significant user interface, a separate Frontend Archit
|
|||
|
||||
{Provide an ASCII or Mermaid diagram representing the project's folder structure. The following is a general example. If a `front-end-architecture-tmpl.txt` (or equivalent) is in use, it will contain the detailed structure for the frontend portion (e.g., within `src/frontend/` or a dedicated `frontend/` root directory). Shared code structure (e.g., in a `packages/` directory for a monorepo) should also be detailed here.}
|
||||
|
||||
```plaintext
|
||||
\`\`\`plaintext
|
||||
{project-root}/
|
||||
├── .github/ # CI/CD workflows (e.g., GitHub Actions)
|
||||
│ └── workflows/
|
||||
│ └── main.yml
|
||||
├── .vscode/ # VSCode settings (optional)
|
||||
│ └── settings.json
|
||||
├── build/ # Compiled output (if applicable, often git-ignored)
|
||||
├── config/ # Static configuration files (if any)
|
||||
├── docs/ # Project documentation (PRD, Arch, etc.)
|
||||
│ ├── index.md
|
||||
│ └── ... (other .md files)
|
||||
├── infra/ # Infrastructure as Code (e.g., CDK, Terraform)
|
||||
│ └── lib/
|
||||
│ └── bin/
|
||||
├── node_modules/ / venv / target/ # Project dependencies (git-ignored)
|
||||
├── scripts/ # Utility scripts (build, deploy helpers, etc.)
|
||||
├── src/ # Application source code
|
||||
│ ├── backend/ # Backend-specific application code (if distinct frontend exists)
|
||||
│ │ ├── core/ # Core business logic, domain models
|
||||
│ │ ├── services/ # Business services, orchestrators
|
||||
│ │ ├── adapters/ # Adapters to external systems (DB, APIs)
|
||||
│ │ ├── controllers/ / routes/ # API endpoint handlers
|
||||
│ │ └── main.ts / app.py # Backend application entry point
|
||||
│ ├── frontend/ # Placeholder: See Frontend Architecture Doc for details if used
|
||||
│ ├── shared/ / common/ # Code shared (e.g., types, utils, domain models if applicable)
|
||||
│ │ └── types/
|
||||
│ └── main.ts / index.ts / app.ts # Main application entry point (if not using backend/frontend split above)
|
||||
├── stories/ # Generated story files for development (optional)
|
||||
│ └── epic1/
|
||||
├── test/ # Automated tests
|
||||
│ ├── unit/ # Unit tests (mirroring src structure)
|
||||
│ ├── integration/ # Integration tests
|
||||
│ └── e2e/ # End-to-end tests
|
||||
├── .env.example # Example environment variables
|
||||
├── .gitignore # Git ignore rules
|
||||
├── package.json / requirements.txt / pom.xml # Project manifest and dependencies
|
||||
├── tsconfig.json / pyproject.toml # Language-specific configuration (if applicable)
|
||||
├── Dockerfile # Docker build instructions (if applicable)
|
||||
└── README.md # Project overview and setup instructions
|
||||
```
|
||||
├── .github/ # CI/CD workflows (e.g., GitHub Actions)
|
||||
│ └── workflows/
|
||||
│ └── main.yml
|
||||
├── .vscode/ # VSCode settings (optional)
|
||||
│ └── settings.json
|
||||
├── build/ # Compiled output (if applicable, often git-ignored)
|
||||
├── config/ # Static configuration files (if any)
|
||||
├── docs/ # Project documentation (PRD, Arch, etc.)
|
||||
│ ├── index.md
|
||||
│ └── ... (other .md files)
|
||||
├── infra/ # Infrastructure as Code (e.g., CDK, Terraform)
|
||||
│ └── lib/
|
||||
│ └── bin/
|
||||
├── node_modules/ / venv / target/ # Project dependencies (git-ignored)
|
||||
├── scripts/ # Utility scripts (build, deploy helpers, etc.)
|
||||
├── src/ # Application source code
|
||||
│ ├── backend/ # Backend-specific application code (if distinct frontend exists)
|
||||
│ │ ├── core/ # Core business logic, domain models
|
||||
│ │ ├── services/ # Business services, orchestrators
|
||||
│ │ ├── adapters/ # Adapters to external systems (DB, APIs)
|
||||
│ │ ├── controllers/ / routes/ # API endpoint handlers
|
||||
│ │ └── main.ts / app.py # Backend application entry point
|
||||
│ ├── frontend/ # Placeholder: See Frontend Architecture Doc for details if used
|
||||
│ ├── shared/ / common/ # Code shared (e.g., types, utils, domain models if applicable)
|
||||
│ │ └── types/
|
||||
│ └── main.ts / index.ts / app.ts # Main application entry point (if not using backend/frontend split above)
|
||||
├── stories/ # Generated story files for development (optional)
|
||||
│ └── epic1/
|
||||
├── test/ # Automated tests
|
||||
│ ├── unit/ # Unit tests (mirroring src structure)
|
||||
│ ├── integration/ # Integration tests
|
||||
│ └── e2e/ # End-to-end tests
|
||||
├── .env.example # Example environment variables
|
||||
├── .gitignore # Git ignore rules
|
||||
├── package.json / requirements.txt / pom.xml # Project manifest and dependencies
|
||||
├── tsconfig.json / pyproject.toml # Language-specific configuration (if applicable)
|
||||
├── Dockerfile # Docker build instructions (if applicable)
|
||||
└── README.md # Project overview and setup instructions
|
||||
\`\`\`
|
||||
|
||||
(Adjust the example tree based on the actual project type - e.g., Python would have requirements.txt, etc. The structure above illustrates a potential separation for projects with distinct frontends; for simpler projects or APIs, the `src/` structure might be flatter.)
|
||||
|
||||
|
|
@ -158,7 +158,7 @@ If the project includes a significant user interface, a separate Frontend Archit
|
|||
|
||||
- **Description:** {What does this entity represent?}
|
||||
- **Schema / Interface Definition:**
|
||||
```typescript
|
||||
\`\`\`typescript
|
||||
// Example using TypeScript Interface
|
||||
export interface {EntityName} {
|
||||
id: string; // {Description, e.g., Unique identifier}
|
||||
|
|
@ -166,7 +166,7 @@ If the project includes a significant user interface, a separate Frontend Archit
|
|||
optionalProperty?: number; // {Description}
|
||||
// ... other properties
|
||||
}
|
||||
```
|
||||
\`\`\`
|
||||
- **Validation Rules:** {List any specific validation rules beyond basic types - e.g., max length, format, range.}
|
||||
|
||||
### API Payload Schemas (If distinct)
|
||||
|
|
@ -176,14 +176,14 @@ If the project includes a significant user interface, a separate Frontend Archit
|
|||
#### {API Endpoint / Purpose, e.g., Create Order Request, repeat the section as needed}
|
||||
|
||||
- **Schema / Interface Definition:**
|
||||
```typescript
|
||||
\`\`\`typescript
|
||||
// Example
|
||||
export interface CreateOrderRequest {
|
||||
customerId: string;
|
||||
items: { productId: string; quantity: number }[];
|
||||
// ...
|
||||
}
|
||||
```
|
||||
\`\`\`
|
||||
|
||||
### Database Schemas (If applicable)
|
||||
|
||||
|
|
@ -193,7 +193,7 @@ If the project includes a significant user interface, a separate Frontend Archit
|
|||
|
||||
- **Purpose:** {What data does this table store?}
|
||||
- **Schema Definition:**
|
||||
```sql
|
||||
\`\`\`sql
|
||||
-- Example SQL
|
||||
CREATE TABLE {TableName} (
|
||||
id VARCHAR(36) PRIMARY KEY,
|
||||
|
|
@ -201,7 +201,7 @@ If the project includes a significant user interface, a separate Frontend Archit
|
|||
numeric_column DECIMAL(10, 2),
|
||||
-- ... other columns, indexes, constraints
|
||||
);
|
||||
```
|
||||
\`\`\`
|
||||
_(Alternatively, use ORM model definitions, NoSQL document structure, etc.)_
|
||||
|
||||
## Core Workflow / Sequence Diagrams
|
||||
|
|
@ -538,7 +538,7 @@ CRITICAL: **Index Management:** After creating the files, update `docs/index.md`
|
|||
|
||||
- **Framework & Core Libraries:** {e.g., React 18.x with Next.js 13.x, Angular 16.x, Vue 3.x with Nuxt.js}. **These are derived from the 'Definitive Tech Stack Selections' in the main Architecture Document.** This section elaborates on *how* these choices are applied specifically to the frontend.
|
||||
- **Component Architecture:** {e.g., Atomic Design principles, Presentational vs. Container components, use of specific component libraries like Material UI, Tailwind CSS for styling approach. Specify chosen approach and any key libraries.}
|
||||
- **State Management Strategy:** {e.g., Redux Toolkit, Zustand, Vuex, NgRx. Briefly describe the overall approach – global store, feature stores, context API usage. **Referenced from main Architecture Document and detailed further in "State Management In-Depth" section.**}
|
||||
- **State Management Strategy:** {e.g., Redux Toolkit, Zustand, Vuex, NgRx. Briefly describe the overall approach – global store, feature stores, context API usage. **Referenced from main Architecture Document and detailed further in "State Management In-Depth" section.**}
|
||||
- **Data Flow:** {e.g., Unidirectional data flow (Flux/Redux pattern), React Query/SWR for server state. Describe how data is fetched, cached, passed to components, and updated.}
|
||||
- **Styling Approach:** **{Chosen Styling Solution, e.g., Tailwind CSS / CSS Modules / Styled Components}**. Configuration File(s): {e.g., `tailwind.config.js`, `postcss.config.js`}. Key conventions: {e.g., "Utility-first approach for Tailwind. Custom components defined in `src/styles/components.css`. Theme extensions in `tailwind.config.js` under `theme.extend`. For CSS Modules, files are co-located with components, e.g., `MyComponent.module.css`.}
|
||||
- **Key Design Patterns Used:** {e.g., Provider pattern, Hooks, Higher-Order Components, Service patterns for API calls, Container/Presentational. These patterns are to be consistently applied. Deviations require justification and documentation.}
|
||||
|
|
@ -549,46 +549,46 @@ CRITICAL: **Index Management:** After creating the files, update `docs/index.md`
|
|||
|
||||
### EXAMPLE - Not Prescriptive (for a React/Next.js app)
|
||||
|
||||
```plaintext
|
||||
\`\`\`plaintext
|
||||
src/
|
||||
├── app/ # Next.js App Router: Pages/Layouts/Routes. MUST contain route segments, layouts, and page components.
|
||||
│ ├── (features)/ # Feature-based routing groups. MUST group related routes for a specific feature.
|
||||
│ │ └── dashboard/
|
||||
│ │ ├── layout.tsx # Layout specific to the dashboard feature routes.
|
||||
│ │ └── page.tsx # Entry page component for a dashboard route.
|
||||
│ ├── api/ # API Routes (if using Next.js backend features). MUST contain backend handlers for client-side calls.
|
||||
│ ├── globals.css # Global styles. MUST contain base styles, CSS variable definitions, Tailwind base/components/utilities.
|
||||
│ └── layout.tsx # Root layout for the entire application.
|
||||
├── components/ # Shared/Reusable UI Components.
|
||||
│ ├── ui/ # Base UI elements (Button, Input, Card). MUST contain only generic, reusable, presentational UI elements, often mapped from a design system. MUST NOT contain business logic.
|
||||
│ │ ├── Button.tsx
|
||||
│ │ └── ...
|
||||
│ ├── layout/ # Layout components (Header, Footer, Sidebar). MUST contain components structuring page layouts, not specific page content.
|
||||
│ │ ├── Header.tsx
|
||||
│ │ └── ...
|
||||
│ └── (feature-specific)/ # Components specific to a feature but potentially reusable within it. This is an alternative to co-locating within features/ directory.
|
||||
│ └── user-profile/
|
||||
│ └── ProfileCard.tsx
|
||||
├── features/ # Feature-specific logic, hooks, non-global state, services, and components solely used by that feature.
|
||||
│ └── auth/
|
||||
│ ├── components/ # Components used exclusively by the auth feature. MUST NOT be imported by other features.
|
||||
│ ├── hooks/ # Custom React Hooks specific to the 'auth' feature. Hooks reusable across features belong in `src/hooks/`.
|
||||
│ ├── services/ # Feature-specific API interactions or orchestrations for the 'auth' feature.
|
||||
│ └── store.ts # Feature-specific state slice (e.g., Redux slice) if not part of a global store or if local state is complex.
|
||||
├── hooks/ # Global/sharable custom React Hooks. MUST be generic and usable by multiple features/components.
|
||||
│ └── useAuth.ts
|
||||
├── lib/ / utils/ # Utility functions, helpers, constants. MUST contain pure functions and constants, no side effects or framework-specific code unless clearly named (e.g., `react-helpers.ts`).
|
||||
│ └── utils.ts
|
||||
├── services/ # Global API service clients or SDK configurations. MUST define base API client instances and core data fetching/mutation services.
|
||||
│ └── apiClient.ts
|
||||
├── store/ # Global state management setup (e.g., Redux store, Zustand store).
|
||||
│ ├── index.ts # Main store configuration and export.
|
||||
│ ├── rootReducer.ts # Root reducer if using Redux.
|
||||
│ └── (slices)/ # Directory for global state slices (if not co-located in features).
|
||||
├── styles/ # Global styles, theme configurations (if not using `globals.css` or similar, or for specific styling systems like SCSS partials).
|
||||
└── types/ # Global TypeScript type definitions/interfaces. MUST contain types shared across multiple features/modules.
|
||||
└── index.ts
|
||||
```
|
||||
├── app/ # Next.js App Router: Pages/Layouts/Routes. MUST contain route segments, layouts, and page components.
|
||||
│ ├── (features)/ # Feature-based routing groups. MUST group related routes for a specific feature.
|
||||
│ │ └── dashboard/
|
||||
│ │ ├── layout.tsx # Layout specific to the dashboard feature routes.
|
||||
│ │ └── page.tsx # Entry page component for a dashboard route.
|
||||
│ ├── api/ # API Routes (if using Next.js backend features). MUST contain backend handlers for client-side calls.
|
||||
│ ├── globals.css # Global styles. MUST contain base styles, CSS variable definitions, Tailwind base/components/utilities.
|
||||
│ └── layout.tsx # Root layout for the entire application.
|
||||
├── components/ # Shared/Reusable UI Components.
|
||||
│ ├── ui/ # Base UI elements (Button, Input, Card). MUST contain only generic, reusable, presentational UI elements, often mapped from a design system. MUST NOT contain business logic.
|
||||
│ │ ├── Button.tsx
|
||||
│ │ └── ...
|
||||
│ ├── layout/ # Layout components (Header, Footer, Sidebar). MUST contain components structuring page layouts, not specific page content.
|
||||
│ │ ├── Header.tsx
|
||||
│ │ └── ...
|
||||
│ └── (feature-specific)/ # Components specific to a feature but potentially reusable within it. This is an alternative to co-locating within features/ directory.
|
||||
│ └── user-profile/
|
||||
│ └── ProfileCard.tsx
|
||||
├── features/ # Feature-specific logic, hooks, non-global state, services, and components solely used by that feature.
|
||||
│ └── auth/
|
||||
│ ├── components/ # Components used exclusively by the auth feature. MUST NOT be imported by other features.
|
||||
│ ├── hooks/ # Custom React Hooks specific to the 'auth' feature. Hooks reusable across features belong in `src/hooks/`.
|
||||
│ ├── services/ # Feature-specific API interactions or orchestrations for the 'auth' feature.
|
||||
│ └── store.ts # Feature-specific state slice (e.g., Redux slice) if not part of a global store or if local state is complex.
|
||||
├── hooks/ # Global/sharable custom React Hooks. MUST be generic and usable by multiple features/components.
|
||||
│ └── useAuth.ts
|
||||
├── lib/ / utils/ # Utility functions, helpers, constants. MUST contain pure functions and constants, no side effects or framework-specific code unless clearly named (e.g., `react-helpers.ts`).
|
||||
│ └── utils.ts
|
||||
├── services/ # Global API service clients or SDK configurations. MUST define base API client instances and core data fetching/mutation services.
|
||||
│ └── apiClient.ts
|
||||
├── store/ # Global state management setup (e.g., Redux store, Zustand store).
|
||||
│ ├── index.ts # Main store configuration and export.
|
||||
│ ├── rootReducer.ts # Root reducer if using Redux.
|
||||
│ └── (slices)/ # Directory for global state slices (if not co-located in features).
|
||||
├── styles/ # Global styles, theme configurations (if not using `globals.css` or similar, or for specific styling systems like SCSS partials).
|
||||
└── types/ # Global TypeScript type definitions/interfaces. MUST contain types shared across multiple features/modules.
|
||||
└── index.ts
|
||||
\`\`\`
|
||||
|
||||
### Notes on Frontend Structure:
|
||||
|
||||
|
|
@ -629,14 +629,14 @@ src/
|
|||
| `{anotherState}`| `{type}` | `{value}` | {Description of state variable and its purpose.} |
|
||||
- **Key UI Elements / Structure:**
|
||||
{ Provide a pseudo-HTML or JSX-like structure representing the component\'s DOM. Include key conditional rendering logic if applicable. **This structure dictates the primary output for the AI agent.** }
|
||||
```html
|
||||
\`\`\`html
|
||||
<div> <!-- Main card container with specific class e.g., styles.cardFull or styles.cardCompact based on variant prop -->
|
||||
<img src="{avatarUrl || defaultAvatar}" alt="User Avatar" class="{styles.avatar}" />
|
||||
<h2>{userName}</h2>
|
||||
<p class="{variant === 'full' ? styles.emailFull : styles.emailCompact}">{userEmail}</p>
|
||||
{variant === 'full' && onEdit && <button onClick={onEdit} class="{styles.editButton}">Edit</button>}
|
||||
</div>
|
||||
```
|
||||
\`\`\`
|
||||
- **Events Handled / Emitted:**
|
||||
- **Handles:** {e.g., `onClick` on the edit button (triggers `onEdit` prop).}
|
||||
- **Emits:** {If the component emits custom events/callbacks not covered by props, describe them with their exact signature. e.g., `onFollow: (payload: { userId: string; followed: boolean }) => void`}
|
||||
|
|
@ -671,7 +671,7 @@ _Repeat the above template for each significant component._
|
|||
- **Core Slice Example (e.g., `sessionSlice` in `src/store/slices/sessionSlice.ts`):**
|
||||
- **Purpose:** {Manages user session, authentication status, and basic user profile info accessible globally.}
|
||||
- **State Shape (Interface/Type):**
|
||||
```typescript
|
||||
\`\`\`typescript
|
||||
interface SessionState {
|
||||
currentUser: { id: string; name: string; email: string; roles: string[]; } | null;
|
||||
isAuthenticated: boolean;
|
||||
|
|
@ -679,7 +679,7 @@ _Repeat the above template for each significant component._
|
|||
status: "idle" | "loading" | "succeeded" | "failed";
|
||||
error: string | null;
|
||||
}
|
||||
```
|
||||
\`\`\`
|
||||
- **Key Reducers/Actions (within `createSlice`):** {Briefly list main synchronous actions, e.g., `setCurrentUser`, `clearSession`, `setAuthStatus`, `setAuthError`.}
|
||||
- **Async Thunks (if any):** {List key async thunks, e.g., `loginUserThunk`, `fetchUserProfileThunk`.}
|
||||
- **Selectors (memoized with `createSelector`):** {List key selectors, e.g., `selectCurrentUser`, `selectIsAuthenticated`.}
|
||||
|
|
@ -937,14 +937,14 @@ _Repeat the above template for each significant component._
|
|||
## Information Architecture (IA)
|
||||
|
||||
- **Site Map / Screen Inventory:**
|
||||
```mermaid
|
||||
\`\`\`mermaid
|
||||
graph TD
|
||||
A[Homepage] --> B(Dashboard);
|
||||
A --> C{Settings};
|
||||
B --> D[View Details];
|
||||
C --> E[Profile Settings];
|
||||
C --> F[Notification Settings];
|
||||
```
|
||||
\`\`\`
|
||||
_(Or provide a list of all screens/pages)_
|
||||
- **Navigation Structure:** {Describe primary navigation (e.g., top bar, sidebar), secondary navigation, breadcrumbs, etc.}
|
||||
|
||||
|
|
@ -956,7 +956,7 @@ _Repeat the above template for each significant component._
|
|||
|
||||
- **Goal:** {What the user wants to achieve.}
|
||||
- **Steps / Diagram:**
|
||||
```mermaid
|
||||
\`\`\`mermaid
|
||||
graph TD
|
||||
Start --> EnterCredentials[Enter Email/Password];
|
||||
EnterCredentials --> ClickLogin[Click Login Button];
|
||||
|
|
@ -964,7 +964,7 @@ _Repeat the above template for each significant component._
|
|||
CheckAuth -- Yes --> Dashboard;
|
||||
CheckAuth -- No --> ShowError[Show Error Message];
|
||||
ShowError --> EnterCredentials;
|
||||
```
|
||||
\`\`\`
|
||||
_(Or: Link to specific flow diagram in Figma/Miro)_
|
||||
|
||||
### {Another User Flow Name}
|
||||
|
|
|
|||
Loading…
Reference in New Issue