forked from jsnbuchanan/crowd-funder-for-time-pwa
Merge branch 'master' into android-safe-area-insets
This commit is contained in:
128
.cursor/rules/development/realistic_time_estimation.mdc
Normal file
128
.cursor/rules/development/realistic_time_estimation.mdc
Normal file
@@ -0,0 +1,128 @@
|
||||
# Realistic Time Estimation — Development Guidelines
|
||||
|
||||
> **Agent role**: **DO NOT MAKE TIME ESTIMATES**. Instead, use phases,
|
||||
> milestones, and complexity levels. Time estimates are consistently wrong
|
||||
> and create unrealistic expectations.
|
||||
|
||||
## Purpose
|
||||
|
||||
Development time estimates are consistently wrong and create unrealistic
|
||||
expectations. This rule ensures we focus on phases, milestones, and
|
||||
complexity rather than trying to predict specific timeframes.
|
||||
|
||||
## Critical Rule
|
||||
|
||||
**NEVER provide specific time estimates** (hours, days, weeks) for
|
||||
development tasks. Instead, use:
|
||||
|
||||
- **Complexity levels** (Low, Medium, High, Critical)
|
||||
|
||||
- **Phases and milestones** with clear acceptance criteria
|
||||
|
||||
- **Platform-specific considerations** (Web, Mobile, Desktop)
|
||||
|
||||
- **Testing requirements** and validation steps
|
||||
|
||||
## Planning Framework
|
||||
|
||||
### Complexity Assessment
|
||||
|
||||
- **Low**: Simple changes, existing patterns, minimal testing
|
||||
|
||||
- **Medium**: New features, moderate testing, some integration
|
||||
|
||||
- **High**: Complex features, extensive testing, multiple platforms
|
||||
|
||||
- **Critical**: Core architecture changes, full regression testing
|
||||
|
||||
### Platform Categories
|
||||
|
||||
- **Web**: Browser compatibility, responsive design, accessibility
|
||||
|
||||
- **Mobile**: Native APIs, platform-specific testing, deployment
|
||||
|
||||
- **Desktop**: Electron integration, system APIs, distribution
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
- **Unit tests**: Core functionality validation
|
||||
|
||||
- **Integration tests**: Component interaction testing
|
||||
|
||||
- **E2E tests**: User workflow validation
|
||||
|
||||
- **Platform tests**: Cross-platform compatibility
|
||||
|
||||
## Process Guidelines
|
||||
|
||||
### Planning Phase
|
||||
|
||||
1. **Scope Definition**: Clear requirements and acceptance criteria
|
||||
|
||||
2. **Complexity Assessment**: Evaluate technical and business complexity
|
||||
|
||||
3. **Phase Breakdown**: Divide into logical, testable phases
|
||||
|
||||
4. **Milestone Definition**: Define success criteria for each phase
|
||||
|
||||
### Execution Phase
|
||||
|
||||
1. **Phase 1**: Foundation and core implementation
|
||||
|
||||
2. **Phase 2**: Feature completion and integration
|
||||
|
||||
3. **Phase 3**: Testing, refinement, and documentation
|
||||
|
||||
4. **Phase 4**: Deployment and validation
|
||||
|
||||
### Validation Phase
|
||||
|
||||
1. **Acceptance Testing**: Verify against defined criteria
|
||||
|
||||
2. **Platform Testing**: Validate across target platforms
|
||||
|
||||
3. **Performance Testing**: Ensure performance requirements met
|
||||
|
||||
4. **Documentation**: Update relevant documentation
|
||||
|
||||
## Remember
|
||||
|
||||
**Your first estimate is wrong. Your second estimate is probably still
|
||||
wrong. Focus on progress, not deadlines.**
|
||||
|
||||
---
|
||||
|
||||
**See also**:
|
||||
|
||||
- `.cursor/rules/development/planning_examples.mdc` for detailed planning examples
|
||||
|
||||
- `.cursor/rules/development/complexity_assessment.mdc` for complexity evaluation
|
||||
|
||||
**Status**: Active development guidelines
|
||||
**Priority**: High
|
||||
**Estimated Effort**: Ongoing reference
|
||||
**Dependencies**: None
|
||||
**Stakeholders**: Development team, Project managers
|
||||
|
||||
## Model Implementation Checklist
|
||||
|
||||
### Before Time Estimation
|
||||
|
||||
- [ ] **Requirements Analysis**: Understand all requirements and acceptance criteria
|
||||
- [ ] **Complexity Assessment**: Evaluate technical and business complexity
|
||||
- [ ] **Platform Review**: Identify requirements across all target platforms
|
||||
- [ ] **Stakeholder Input**: Gather input from all affected parties
|
||||
|
||||
### During Time Estimation
|
||||
|
||||
- [ ] **Phase Breakdown**: Divide work into logical, testable phases
|
||||
- [ ] **Complexity Classification**: Assign complexity levels (Low/Medium/High/Critical)
|
||||
- [ ] **Platform Considerations**: Account for platform-specific requirements
|
||||
- [ ] **Testing Strategy**: Plan comprehensive testing approach
|
||||
|
||||
### After Time Estimation
|
||||
|
||||
- [ ] **Milestone Definition**: Define success criteria for each phase
|
||||
- [ ] **Progress Tracking**: Set up monitoring and tracking mechanisms
|
||||
- [ ] **Documentation**: Document estimation process and assumptions
|
||||
- [ ] **Stakeholder Communication**: Share estimation approach and progress focus
|
||||
Reference in New Issue
Block a user