-
Notifications
You must be signed in to change notification settings - Fork 35
Software Development Process
The Touchpoints team embraces the value of documentation as a shared design artifact. Software is never done, and managing product is a recurring cycle.
Software projects work through the following steps to greater or lesser degrees of explicitness. These common product design artifacts are kept as living artifacts, updated to reflect the evolution of thought, design, and system architecture.
- Personas
- Use Cases
- Concept Inventory → Concept Model → Data Model
- Wireframes, sketches, user flows
- Screen designs
- Working, tested software
- and repeat ➰
Touchpoints tracks work on a digital Kanban board. The board is designed to be adjusted to support the dynamic needs of the team. Additional ad-hoc columns may be added and removed as needed.
- 📥 Inbox — ideas, user feedback, new specifications that emerge as work is delivered
- ❄️ Icebox — valid work, but needs definition
- ✏ Needs Design — valid work, but needs design and definition
- 📋 Backlog — valid work, prioritized by 1) user value and 2) throughput
- 🎯 Current — valid work, prioritized and scoped for one iteration
-
Work In Progress (WIP) — work currently being worked on by a team member; if blocked, may be moved back and/or labeled
blocked - 👀 Acceptance — review to ensure work is delivered according to definition
- ✅ Done — accepted work; or work decided not to do
- New cards are added to Inbox — anybody can add a card
- Cards move left toward Done
- Team members add themselves to cards; don't assign someone without their knowledge — team members pull their own tasks
- Inbox is groomed by the team at least weekly
A card is ready to move forward when:
- It is clearly written as a well-formed user story
- It has acceptance criteria / a clear definition of done
- It has an owner
- If it has more than one member, a specific member is referenced in the checklist
- It has a checklist of bite-sized, objectively completable work items
Assumes a well-formed User Story + Acceptance Criteria. Stories are tracked in Trello.
- Write the feature locally
- Add tests as necessary/valuable — TDD is highly encouraged
- Ensure tests pass locally
- Push to a
feature branchfor work in progress - Push to
developwhen the story is ready for Acceptance on Staging
A story is complete when:
- Feature is implemented
- Automated test/spec is written exercising the behavior described in the Acceptance Criteria
- Code is pushed to a
feature-branchwhen WIP - Code is pushed to
developwhen ready for Acceptance on Staging - Story card is moved to 👀 Review/Acceptance in Trello
- After acceptance, the story card is moved to Deploy to Production in Trello
- Feature is noted in Release Notes
- System changes are reflected in system documentation & diagrams
- Migration steps are documented in the Pull Request description
- Code is pushed to
productionwhen ready to deploy - Story card is moved to ✅ Done in Trello
With each commit to production, changes are documented in Release Notes. See that page for the full changelog.
See the Developer Guide for the full deployment process.
- Form Elements
- Form Templates
- Form Markup
- Delivery Options
- Creating a Form Template
- Deploying via GTM
- Analytics Events
- Organization Form Approval
- Tagging Responses
- Reporting: Form Reports
- Data Collections
- CX Data Collection Format
- CX Performance Data
- Data Collection Rating
- A-11 PRA Guidance
- CSCRM Data Collection
- IDC Services Data Collection