A software development process
is a structure imposed
on the development of a software product
It's also known as an issue
It's an actionable description of a unit of work to be done
The process of turning tickets into software.
60 years of practice and research have produced dozens of methodologies
This is how NASA put astronauts on the moon.*
A collection of tickets that will be resolved and deployed to production as a group
Generally a release has a single focus on a specific functionality or fix
Comments, Descriptions, Notifications, Priorities, Status, and more!
|Bug||An error in the software, it does not work for intended use|
|Story (aka feature)||A new feature of the software, it did not do this before but we need it|
|Task||A unit of work that needs to be done, but does not materially alter a software system's behavior|
|Epic||A bunch of tickets masquerading as a single ticket|
"We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error." - Dijkstra
Is it a bug or a feature?
Different approaches, driven by underlying purpose and context
Common theory for both
It's OK to get it wrong.
Consider your audience, in the context of our process.
Create a bug issue everytime you encounter error, right away!
A new ticket is always the first step
There is always one, and only one, goal when fixing a bug:
More or less information should be included based on your judgment of what information would be necessary to reproduce the error
When new functionality is known to be needed and has been defined
When drafting a story ticket, the goal is always to make the ticket:
Remember the audience, what information would the developer need to actually build this.
|User Story||A narrative story describing who the user is, what their goals are, and what activities they will do with the software to reach those goals.|
|Visual Mock Ups||A sketch, wireframe, or image illustrating a possible interface solution.|
|Detailed Description||A flowchart or step by step narrative describing inputs and outputs of the software.|
|Story||The new functionality can be clearly defined, meaning that all information required for the ticket to be actionable is known.|
|Epic||The general idea behind the new functionality is known, but the details are not yet known.|
It's OK to create unactionable epics for features, for purposes of communication, brainstorming, and refinement.
Depending on the feature, this can be a lot of material: every detail.
Recall what happens to protein expression if DNA is missing essential codons.
In reality, the developer just fills in the gaps with to the best of their ability and common sense. Sometimes this works out great. And sometimes ...
Avoid assuming that the developer has common sense.
Developers will only know what you tell them about a specific problem domain.
Bug Tickets: Reproducible
Story Tickets: Actionable
This is a learning process, it's OK to make mistakes.