Collaboration

Collaboration Contract

Managerial ruling

Decisions will be made in a centralized manner. Anybody attending should have the opportunity to speak up about a suggested resolution. The general concept is that there will be discussion until consensus is achieved. When this discussion risks taking up to much time the scrummaster will have the final say in the matter. It is the task of the other team members to abide by this decision.

Collaboration conflicts

Problems of a collaborative nature will always first be discussed between the conflicting parties before bringing it forward in a meeting. Based on the discussion during the meeting the team can decide to take up the matter with the teaching assistants (henceforth: TAs) and ultimately with the project coordinators.

Attendance

Everybody has the duty to be present (on time). In case of absence this is reported beforehand to at least one other team member, preferably as soon as possible. At the start of a (scrum) meeting we will check attendance. This is the moment for the informed member to notify the rest of the team about the absent member. In the case where the scrummaster is absent another team member will take over his tasks until the scrummaster returns. Being on time is everybodies own responsibility. We don’t use an entry period. When somebody is absent at the start of a meeting without notifying the team it is expected of the absent person to bring cake the next time we meet. The validity of the stated reason for absence will be discussed during the meeting. When no reason has been stated (or nobody on the team was notified) we will assume the member will be absent for the rest of the duration of the meeting. This is also trusts the responsibility of bringing cake to the next meeting upon the absentee.

Meeting frequentie, time & location

Every workday there will be a scrum meeting with a duration of at most 15 minutes. Meetings start at 9.30 unless theres a scheduling conflict (a lecture e.g.) In the latter case the meeting will be held directly following said scheduling conflict. At the start of an iteration there will be a sprint planning event of at most 120 minutes. (See also Division of tasks). At the end of an iteration there will be two events, namely a sprint review and a sprint reflection. Where the first one has a maximum duration of 60 minutes and the later a maximum duration of 45 minutes. The moment of these meetings will be chosen in agreement. . The location of the meetings will, in principle, be the room that has been assigned to us according to the schedule. If this is not a workable environment then we will divert to an workspace on campus and ultimately to an external location (somebodies house e.g.)

Division of tasks

Dividing the tasks is a process all team members will take place in. During the first half of the sprint planning the product owner will put forward open tasks from the backlog and the team members will discuss whether or not the task will be completed during the upcoming iteration. In the second half of the meeting the tasks will be distributed amongst the team members. The process for this distribution is an opt-in system where everybody can announce their interest in a task. The rest of the team come to a decision on whether a certain member will perform a task based on a number of aspects. For example but not limited to: how suitable a task is for a specific person (Is somebody more suitable for this task?), the diversity of tasks assigned the team member (Is this person not doing too much of the same kind of tasks?), the number of people working on a task and time management. (See also managerial ruling) At the end of a sprint planning there will always be a sprintplan available which will be used as a guideline for the upcoming iteration.

---

This contract has been agreed to by: Jasper Nieuwdorp, Jim Hommes, René Vennik, Gerben Oolbekkin, Jasper Boot

---

Workflow rules

1. Take a task from the issue section on the repository assigned to you.
2. If the tasks is a code task: Start a new branch and name it: <LABEL>/short-description. Examples of valid branch names are: task/sprintplan-2,enhancement/control-menu and feature/thee-graph
3. While working update the the issue section of the task you're working on regularly.
4. We use test driven development. First write tests and then implement the feature.
5. Commit regularly
6. Done implementing means:

• Test coverage > 75%
• Implements desired feature
• Maven builds without errors
• No severe issues reported by: FindBugs, CheckStyle, PMD, CPD and Travis
• Code is commented

7. When you believe to be done with a task, commit and create a pull request.
8. After 2 other persons reviewed your code and agreed to it, the last person of the 2 merges the branch.
9. The owner of the tasks is responsible for deleting the branch from Github & Closing the issue.
10. Before the end of each iteration there should be UML supporting the code