-
Notifications
You must be signed in to change notification settings - Fork 2
project:workflow
Johannes Lötzsch edited this page Mar 14, 2024
·
2 revisions
We use an adaption of Scrum with 2-week sprints. Pair programming is encouraged.
Other methods of extreme programming are welcome.
Hint Johannes recommends this podcast about XP
The Kanban board is created from the repositories issues and can be found at the project page.
The board consists of the following columns. Every issue/card should traverse all of the columns, without skipping any of them.
stateDiagram-v2
Next: Next (agreed to be worked on soon)
Todo: Todo (assigned for this sprint)
Progress: In Progress
Review: In Review
Ideas --> Next : Meeting
Next --> Todo : Sprint meeting
Todo --> Progress
Progress --> Review
Review --> Done : Sprint meeting
- Everyones ideas/proposals are welcome
- Feel free to create an new Issue, it should automatically be sorted into the
ìdeas
column - For exanations/notes/links related to the idea: When it's more complex please create a wiki page and link it in the issue.
- Please don't start working on new ideas (when expecting to get paid for it), before consulting the team
- Once you proposed and discussed your idea in a meeting with the other teammates, we decide together if we want implement the suggestion and how it is prioritized.
- Every issue should be assigned to a (or multiple) developer(s) and it's effort in hours should be estimated
- Approval should be given with the consent of the whole team within a sprint planning meeting
- When urgent (e.g. unexpected new dependency which is blocking other planed tasks), approval can be given by the project manager. Other team members should still be informed. This case should stay an exception.
- During a sprint, every developer is free to work independent (when not agreed otherwise) on their assigned Todos.
- If new knowledge reveals that a task requires substantially more time than estimated, a reapproval should be requested from the project manager or the entire team. When considered helpful, other team members should be consulted for finding pragmatic solutions.
- Once you finished a task, please move it to
In Review
. - When you are sure about what you are doing, feel free to push directly to the main branch of the official repo. Please
Rebase and Fast forward
whenever appropriate to prevent unnecessary merge commits. - Whenever not sure if your changes might interact with another developers code, better open a pull request and ask for a review.
- Reviewing is very welcome to:
- learning from each other,
- getting up to date what others are implementing
- improving the code quality
- Tasks will be moved to
done
during sprint meeting, after the feature was presented to the other team members