Developing Enterprise Software as a Team Effort

Cooperation Contract

During the development of our group project we made agreements to ensure that development of the project would go as smooth as possible. When things were not working out we would look at the problem as a group and make a decision together.

Together we setup a cooperation contract, agreed on programming conventions and set up a scrum board to keep track of tasks and things we have to do.

Click here to view the entire document (document written in Dutch)

Peer reviews

We also wrote peer reviews after the first and 4th sprint and made agreements where things fell short.

Document Spring 1

Document Sprint 4

(Both of these are in dutch)

According to feedback from others I have improved a lot over the course of the sprints. In the beginning I felt like I was slacking, I didn't get much done because I had little knowledge about the things we had to work on. Motivation was also pretty low. The first peerreview really made this clear to me but it also showed that others did notice I was actively trying to improve on this. Compared to the peer review at sprint 4 I improved a lot. I learnt more about the tools we worked with, the techniques we were using etc. I communicated more to the team and everyone knew what I was working on. The products I delivered were fine and the quality was good.

Standups

Halfway through sprint 2 we had to work from home because of the corona crisis. In order to better keep track of what everyone is doing, we had started doing daily stand ups to inform everyone what you have been doing, what you are going to do and what problems you are running into.

At moments where we had fewer but bigger tasks to do, we would employ pair programming to speed up development. This Worked out really well and we could learn a lot from each other as well.

DTAP

To make sure we only push working code, we set up a DTAP workflow. DTAP stands for Development, Testing, Acceptance and Production. The way this flow works is that we create a new feature branch for every new feature we develop. When that features is done it gets reviewed and merged into the Develop branch. This is to ensure only working code gets pushed. The new code is then tested, if it passes it can be pushed onto the release or acceptance branch. When enough features are added to this release/acceptance branch it can be pushed to the production/master branch as a new version of the application

An example of this flow is shown on the right

Page updated

Google Sites

Report abuse