Course and Miniproject Report - gotonode/ohtu GitHub Wiki

This is Return Zero's report on the course and it's miniproject. It's a project's post-mortem report.

Problems encountered in each sprint

These include problems in the process, teamwork and on the technical side. Due to the good exercises that were done prior to starting the miniproject, many technical issues faced weren't carried over to the actual miniproject.

Problems in sprint 1

  • Duplicate tabs were inserted by IntelliJ IDEA, which annoyed other members (Riku)
  • Getting Codecov to properly ignore the Main-class was a minor hurdle

Problems in sprint 2

  • In sprint 2 I (Vivianna) was in charge of making the necessary changes for our application to be able to communicate with our database when started from a jar file. I modified our jar file to be always created as a fat jar so as to have it contain all the necessary information. I struggled with getting the jar file to be capable of accessing the data of the SQL script file createstatements.sql, where the CREATE statements for our database are located. In the end I ran out of time and had to have the CREATE statements be executed temporarily via a method instead of the script. Riku finally managed to make our jar file access our SQL script file during the next sprint.
  • Burndown charts were done by Vivianna, and I had some minor problems with communicating my used hours to her (Riku). But by no means where these any major communication problems. I (Vivianna) just hoped for some minor changes having to do with the form in which the used hours where reported to me. Those changes saved me some time in the future sprints in regards to creating our sprint charts and checking their accuracy and consistency with our sprint backlogs.

Problems in sprint 3

  • The threshold of editing code that another team member had written was a small issue, which we talked through and agreed on the collective code ownership; that all code is free to be edited by anyone
  • Writing unified code (e.g. everyone either using spaces or tabs) wasn't enforced and perhaps we should have enabled more Checkstyle rules, after discussing and agreeing which rules everyone agrees to

Problems in sprint 4

  • The code refactoring of DAO classes and cucumber tests started a bit too late. The code refactoring should be started in the sprint 3, in other words, it should be started as early as possible when we realized that there were too many duplicates in our codes.(Yumo)
  • The using of Powermock in tests to test static methods caused a SQLException which is reported as no suitable driver found for the database.(Yumo)

What went well and what should be improved in future projects

Our team's synergy was optimal. We held regular meetings regarding to the project, where issues were discussed, thus we always had common understandings about our user stories, which improved our synergy. Furthermore, our division of work was clear. For example, Riku wrote most of the UI codes, Vivianna took care of the design of the database and DAO-classes and Yumo wrote most of the unit tests and all cucumber tests. We also held retrospectives, but those didn't turn out to be too useful since our communication during the sprints was so good, there often wasn't anything else to add at the end of the sprints.

Again, it can't be stressed enough how useful the weekly exercises were. Being able to put them into use almost immediately felt very rewarding. Actually considering how you could implement newly-learned feature X, Y or Z into an ongoing project helps cement the OOP model in the mind.

What we learned, what we would've liked to learn, and what felt useless

When working in a Scrum team, even a simple task that could be done in an evening can be stretched out to a week's worth of work. Software development in a team adds many layers of work in addition to the actual programming.

Being able to elevate and use what other people have learned will work in the benefit of the project, and of each individual in the long run. For a simple example, I (Riku) didn't know of Cucumber's Background-feature, but once I saw that it was used, I figured that of course there had to be such a feature. In essence, each member of the development team brings in their own expertise and special knowledge which can then be assimilated by the other members.

One of the most important things we've learned is that what items, such as sprint and product backlog and what processes, such as sprint planning, sprint review and sprint retrospective, are included in the Scrum framework. Doing the miniproject helps us understand the Scrum more profoundly as we went through the processes ourselves.

With the previous in mind, it would've been useful to see at least a tiny glimpse of other team's progress and work. But of course, that would take a lot of time. Perhaps an aggregated post-mortem from all teams? I mean like a simple bullet-point list which contains the top issues faced, top learning experiences etc.

In addition, our assistant who played the role of a product owner could be more "fastidious" in some cases. Our assistant was usually satisfied with our product while validating the requirements specification. In could be more challenging and closer to real software development if the assistant could show his unsatisfying in some cases, such as "The feature you implemented wasn't the one I wanted", or change his mind suddenly, "I wanted this user story before but I don't want it now".

Regarding agile methodologies, Scrum was gone through in depth but I would've liked to see some more comparisons to eXtreme Programming (XP). Perhaps a chart illustrating the differences? This would've explained what is basic agile and what is specific to Scrum/XP.

Signed and participated,
Vivianna, Yumo, Riku