The glossary serves as a compilation of terms used throughout a given project's requirements, so there's no room for ambiguity, here I'll be using it to clear some terms.
Ticket/Issue/Task/Bug
These terms are used interchangeably to refer to tasks that need to be completed within a specified timeframe. They are submitted through the ticket system and they mostly fall down into two main categories.
- - Features: Refers to a functionality that needs to be implemented, specified as a User Story, then broken down into smaller and measurable tasks to implement.
- - Bugs: Refers to various issues within a project. Such as: design flaws, unclear documentation, coding inconsistencies (maintainability issues), deviation from best practices, general errors, security vulnerabilities, performance issues, scalability issues and more.
A ticket serves as a link between two key individuals: the problem reporter and the problem resolver, they can be the same person, but never more than two, this is how we know who delivered what (in case of working within a team), and how much money they deserve, since billing is based upon deliverables, not time spent.
Ticket System
Tickets are submitted as GitHub issues, they form the basis for all actions within the project, including communication.
Issues are:
- - Measurable: If it's a large piece of work, then it will be broken down to small and easy measurable tasks, each not surpassing 1 hour of work.
- - Templated: Have a template: Feature Request, Bug, Documentation, Research, and other available templates.
- - Labeled: With a priority level and estimated time for completion, additional labels may be present too.
- - Basically S.M.A.R.T
User Stories
User Stories are expressed through Gherkin files. These files double as acceptance tests, to ensure a clear understanding while providing a means of verification for the software's functionality. Learn more.
Team
I manage a group of expert professionals in my network whom I outsource work to. Each member has their own hourly rate, and their primary goal is to efficiently resolve as many tickets as possible to earn compensation. All completed work undergoes thorough review and approval by me. The team is flexible, capable of scaling up or down according to workload fluctuations. Members operate autonomously and have the freedom to leave at any time without project disruption, and here's why. Additionally, our transparent working model allows clients to monitor progress and contributions in real-time.
Stack
Refers to the technology being used, You can check mine here.
Methodology
Blend of various methodologies, including Scrum, XP, XDSD, and no bullshittery. Pragmatism always trumps dogma. Nothing in software is perfect. No single methodology is flawless, each having its own trade-offs. Therefore, the best parts are taken, and the crap is ditched.