# 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. --- ## The Product 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](./Personas) * [Use Cases](./Use-Cases) * Concept Inventory → Concept Model → [Data Model](./Data-Model) * Wireframes, sketches, user flows * Screen designs * [Working, tested software](https://touchpoints-demo.app.cloud.gov) * and repeat ➰ --- ## Kanban Board 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. ### Columns * 📥 **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 ### How Cards Flow * 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 ### References * [Kanban for Government](https://digital.gov/2016/09/13/kanban-for-government/) * [Intro to Kanban](https://digital.gov/event/2019/11/13/intro-kanban-i/) * [Kanban (development) — Wikipedia](https://en.wikipedia.org/wiki/Kanban_(development)) * [Agile Manifesto](https://agilemanifesto.org/) --- ## Story Lifecycle ### Starting a Story Assumes a well-formed [User Story + Acceptance Criteria](https://tech.gsa.gov/guides/user_story_example/). Stories are tracked in Trello. ### Development Cycle 1. Write the feature locally 2. Add tests as necessary/valuable — TDD is highly encouraged 3. Ensure tests pass locally 4. Push to a `feature branch` for work in progress 5. Push to `develop` when the story is ready for Acceptance on Staging ### Definition of Done 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-branch` when WIP * Code is pushed to `develop` when 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](./Release-Notes) * System changes are reflected in [system documentation & diagrams](./Data-Model) * Migration steps are documented in the Pull Request description * Code is pushed to `production` when ready to deploy * Story card is moved to ✅ **Done** in Trello --- ## Releases With each commit to `production`, changes are documented in [Release Notes](./Release-Notes). See that page for the full changelog. See the [Developer Guide](./Developer-Guide) for the full deployment process.