Cheeseburger is a work-in-progress methodology that Futura IO deploys for Product Development.
Influenced by
- d.school DT
- failing at finishing many products
The name is derived from the idea that a product development process should help define longterm product vision but not constrict how the product gets there - Which is an idea inspired by a quote from the Swiss graphic designer, Karl Gerstner
The difficulty lies in finding the balance between maximum formality and maximum freedom, or in other words, the greatest number of constant factors combined with the greatest possible variability.
Table of Contents
The Cheeseburger Methodology arose out of a realization for a more tightly knit, yet loosely controlled system for organizing product development. We didn't want to get tied into heavy feature listing and see too many half-finished repos. Cheeseburger is meant to help steer product direction and keep accountability around finishing products entirely.
Addtionally, Cheeseburger is an entirely GitHub Issues managed product development system. It utilizes some customizations to the Issue tagging systema and transitioning information into the Wiki for "always on feature development conversations".
Organizing product development process with the Cheese is entirely predicated upon working solely out of GitHub issues for communication and management. All issues, milestones, labels and work are done alongside the main repository managing the codebase for the application.
Cheeseburger applies a slightly different methodology for Web Applicaitons than for iOS applications (the only two it's primarily being tested on). For the purposes of gathering empahty and getting to market with the right niche and speed, web applications are developed without any PSD or Static Image based starting point. All design is created in the browser with front-end development technologies and therefore futher implemented on and changed.
Cheeseburger is facilitated by moving product features through a labeling system. Every product feature is treated on an equal playing field and therefore organized by the same global system for product development. Features can have 3 stages; proposed, testing and active. At any point in development any feature can move forward or backward on this track. Additionally, within each stage - each feature must move along the micro track. Any feature in the proposed, testing or active stage can be in the micro understand, synthesize or prototype. Each feature is it's on GitHub Issue. Each feature has the proper label applied as it's in each stage.
Every cheeseburger managed project has a "Base" which gets tagged entirely as it's own issue. The main goal of the base issue is to transfer a working-state database schema into the Wiki. The Base Issue also helps define the initial views for development and moving into a design stage. Once the Base Issue is completed, the Database Schema moves into the Wiki and the appication get's a v0.0.1 tag.
- Proposed
- The propsed stage is just what it sounds.
- Testing
- The testing stage is when a feature is being actively *prototyped on end users.
- *with code, in the browser, maybe even in the product
- The testing stage is when a feature is being actively *prototyped on end users.
- Active
- An active feature is one that's currently implemented in the live product.
- Understand
- Features in the understand micro are gathering empathy for the people the feature will impact.
- Synthesize
- A stage in the synthesize micro is compiling the understand data in a current stage definition (CSD).
- Prototype
- A stage in the micro prototype is one being actively tested on users in low-reslution formats.
Formatting issues in a consice matter for clarity of communication is extremely important. Each product feature has it's own Issue. All communication regarding that issue happens underneath each Issue. As features move along the Feature Stages the