Development Process
Our development process is a flavor of agile software development, that organizes design, implementation, and communication through tickets (or “issues” in GitHub lingo). The general rules are that every desired software capability should be documented as a feature in a ticket, that work on features should be refined into task tickets assigned to iterative sprints of four weeks length, and that every commit should correspond to a task.
A feature is a capability or property of a software system that can be experienced by a user. For instance, a library function used by a developer working with that library, or a error message provided to the user of a software tool.
The development of our software is driven by a prioritized list of features that we want to implement. Features are decomposed into tasks. Tasks describe implementation work that a single developer can finish in a managable amount of time. In our case, tasks should prefereably be estimated to require 4 hours of work at most.
The development process is organized into iterative sprints of a given length of time. Sprints begin with a sprint meeting that decides the work scheduled for the next sprint. During a sprint meeting, all developers asses the current state of development, reflect on insights, difficulties, and delays they encountered during the last sprint, and use that information to plan the next sprint. In our case, a sprint takes four weeks.
The key purpose of a sprint meeting is to discuss new feature requests and to select the features to be tackled in the next sprint. Features are selected, ordered by priority, and decomposed into tasks with estimates of the necessary effort for each task. A subset of these tasks is assigned to the next sprint such that the estimated total work matches with the available development resources. Unassigned features are kept in a backlog and postponed for future sprints.
A user story is a short prosaic description of a function or property of a system from the viewpoint of the system’s user, such as a developer using a library or a user interfacing with a graphical interface. A user story describes who wants what from the system, as well as why he wants it. For example:
As a researcher running simulations with Tool X based on experiment results, I want to be able to import experimental data via Python, in order to automate the integration between experiment and simulation with small scripts.
As mentioned before, user stories should be assigned with a priority to guide the selection of stories and tasks for the next sprint.
Features and tasks are represented by issues with respective labels, and the connection between a feature and a tasks is indicated by a reference from task to feature. Sprints and the backlog are represented by milestones. Bugreports are a special category of tasks that can be reported without a corresponding feature.
In case a feature can be adequately implemented by a single tasks, feature and task can be represented by the same ticket.