From d2af5a87327fab03d39d81d08a59159284d6a820 Mon Sep 17 00:00:00 2001 From: Frie Date: Wed, 8 Dec 2021 15:52:08 +0100 Subject: [PATCH] first few notes about agility in projects --- .../project-team/definition-of-done.md | 14 +++++++ .../project-team/roles-mindset-values.md | 37 +++++++++++++++++++ project-manual/project-team/tools-methods.md | 24 ++++++++++++ 3 files changed, 75 insertions(+) create mode 100644 project-manual/project-team/definition-of-done.md create mode 100644 project-manual/project-team/roles-mindset-values.md create mode 100644 project-manual/project-team/tools-methods.md diff --git a/project-manual/project-team/definition-of-done.md b/project-manual/project-team/definition-of-done.md new file mode 100644 index 0000000..820cfeb --- /dev/null +++ b/project-manual/project-team/definition-of-done.md @@ -0,0 +1,14 @@ +> When a Product Backlog item or an Increment is described as “Done”, one must understand what ‘Done’ means. Although this may vary significantly for every Scrum Team, members must have a shared understanding of what it means for work to be completed and to ensure transparency. This is the definition of ‘Done’ for the Scrum Team and it is used to assess when work is complete on the product Increment +> In short, DoD is a shared understanding within the Scrum Team on what it takes to make your Product Increment releasable. + +A definition of done makes more sense in a software development context where things like testing are much more relevant. However, even for data projects that rely on code, a definition of done can be useful to agree on certain best practices that also apply to data science. Here are some suggestions that could be part of your team's definition of done: + +- the code runs / has no defects +- the code is documented / documentation such as README/wiki is updated +- someone else has had a look at the code (peer review) +- the code is in the main branch + +in addition, for more software-oriented projects: +- unit tests pass +- unit test coverage >xx% +- no errors on coding standards (e.g. lintr) \ No newline at end of file diff --git a/project-manual/project-team/roles-mindset-values.md b/project-manual/project-team/roles-mindset-values.md new file mode 100644 index 0000000..5436dd0 --- /dev/null +++ b/project-manual/project-team/roles-mindset-values.md @@ -0,0 +1,37 @@ +# Values, Mindset, and Roles + +# Values and Mindset +tbd by Ethics Committee +- CorrelAid values: https://correlaid.org/en/about/codeofconduct/ +- Scrum values: https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/ + +rename/reframing some of the CorrelAid values (diversity -> respect, knowledge management -> openness/transparency) +add: Courage , Focus, Commitment + + +## CorrelAid projects are... +... impactful: What we do helps the NPO with its mission and amplifies its impact +... useful and sustainable: The NPO is able to use the results of the project. The project has impact beyond its time frame. +... feasible: The project is realistic to do with a skilled volunteering approach while also ensuring that everyone has a good learning experience. +If you ever have the impression that any of them do not hold anymore during the project, please talk to your project coordinator. + +# Roles +[insert what scrum is and why it is useful in IT] + +It is not realistic to implement Scrum in a volunteering setting. Hence, we instead focus on proposing roles and accountability that fit for our context. + +## Recommendations: +### Small teams (up to 3) +make sure that the following things are equally distributed: +- maintain a prioritized backlog (i.e. what you would like to get done) and facilitate/organize regular discussions/updates with the NPO about it +- organize/facilitate a regular retrospective + +### Regular teams +- 1 person: NPO spokesperson/"product owner" + - maintain contact with NPO + - update NPO contact person about progress (if they can't join the sprint review regularly) + - maintain product backlog in discussion with NPO and team +- 1 person: Scrum Master + - organize internal meetings + - keep team organized + - bi-weekly (ca. 2h): sprint review (with NPO if possible), sprint planning, retrospective \ No newline at end of file diff --git a/project-manual/project-team/tools-methods.md b/project-manual/project-team/tools-methods.md new file mode 100644 index 0000000..601e9d5 --- /dev/null +++ b/project-manual/project-team/tools-methods.md @@ -0,0 +1,24 @@ +# Tools and Methods + +TODO: templates + + +## Sprint Review +### Goals: + + +### Methods + +## Sprint Planning +### goals: +- discuss what you as a team can commit to for the next sprint (2-3 weeks). +- distribute tasks +### Methods + + +## Retrospective +### Goals + + +### Methods +