@@ -52,7 +52,7 @@ The program is a so-called "Standalone application", meaning that the applicatio
### Agile Development Process
kanban is a development methodology centered around tracking progress and minimizing bottlenecks. Agile development methods focuses on frequent, but smaller deliveries to ensure the developers get enough feedback from both user-tests and the stakeholders / clients. Agile methods like: iterative, incremental and evolutionary development-methods minimizes risk by allowing the product to be more easily adaptive to changes, and even though the feature-set or functionality of the program does not increase by a substantial amount for every iteration, it ensures that a working product is available throughout the process.
Kanban is a development methodology centered around tracking progress and minimizing bottlenecks. Agile development methods focuses on frequent, but smaller deliveries to ensure the developers get enough feedback from both user-test's and the stakeholders / clients. Agile methods like: iterative, incremental and evolutionary development-methods minimizes risk by allowing the product to be more easily adaptive to changes, and even though the feature-set or functionality of the program does not increase by a substantial amount for every iteration, it ensures that a working product is available throughout the process.
### Human Computer Interaction
...
...
@@ -109,7 +109,7 @@ _This section will discuss the methods used in the program and how the theories
### Development process and iterations:
in this project we wanted to go for an agile development method as this made the most sense in regards to the workflow we wanted to achieve. Our development process was heavily inspired by the kanban system to quantize the tasks that was currently active, being worked on, or done for every iteration. As the next iteration begins, all the tasks should be in the "Completed" tab, these tasks were moved into the "Closed" tab of our Issue Board, and new issues would be added to the "To Do" tab. Since we wanted to focus on the kanban method, we adapted that method to our issue-board on Gitlab to be functioning as our kanban board. We did this to have control over what tasks was relevant to the current iteration, what tasks are currently assigned to a developer, and how far we have come in the iteration.
in this project we wanted to go for an agile development method as this made the most sense in regards to the workflow we wanted to achieve. Our development process was heavily inspired by the Kanban system to quantize the tasks that was currently active, being worked on, or done for every iteration. As the next iteration begins, all the tasks should be in the "Completed" tab, these tasks were moved into the "Closed" tab of our Issue Board, and new issues would be added to the "To Do" tab. Since we wanted to focus on the Kanban method, we adapted that method to our issue-board on Gitlab to be functioning as our Kanban board. We did this to have control over what tasks was relevant to the current iteration, what tasks are currently assigned to a developer, and how far we've come in the iteration.
<br>
...
...
@@ -156,7 +156,7 @@ After completing user tests for the different iterations, we would write a summa
### Documentation
Our method for documentation was making sure that any work we did had to be found in one way or another on the wiki or in our repository. we had some problems with the gantt chart, along with the time-sheets, given that these are spreadsheets, and git cannot manage version control or merging two versions of a spreadsheet into one, to solve this problem we put the spreadsheets in a personal teams-chanel so that all of us had access to the latest version, at the same time. This introduced the problem of the lack of version control, and not being able to see what or when something has been committed, but we concluded that the best way to handle it was still to have it in the teams channel.
Our method for documentation was making sure that any work we did had to be found in one way or another on the wiki or in our repository. we had some problems with the Gantt chart, along with the time-sheets, given that these are spreadsheets, and git cannot manage version control or merging two versions of a spreadsheet into one, to solve this problem we put the spreadsheets in a personal teams-chanel so that all of us had access to the latest version, at the same time. This introduced the problem of the lack of version control, and not being able to see what or when something has been committed, but we concluded that the best way to handle it was still to have it in the teams channel.
### Work and Role Distribution
We started of the project with a role distribution that ended up working poorly due to a lack of clear tasks for each member, we ended up revising the roles the week before the second iteration was turned it (18.Mar).
...
...
@@ -261,15 +261,15 @@ For more in depth explaining of hourly accounts and week-for-week status rapport
As mentioned in the previous chapter, the end results of projects, including this one, often strays significantly from the original plans. You do not often get by, maneuvering extensive projects and developments, without encountering certain issues which could not easily have been predicted. This chapter contains several discussion points and analytic evaluations of these kinds of issues, that has been encountered during working on this project.
The end product, and the main result goal of this project, was of course the program "EasyPut". More accurately the main goal was to create an application meant for a mini-golf tournament organizer, as an easier solution to the aspect of organizing tournaments. Keeping this in mind, the development part of this project have certainly gone according to plan. We have a fully, ready to use program to present to our client, and that of course is a reason for satisfaction. Most features requiered from the client, have been implemented and the foundation is set for further, future expansions and updates. Some of these features include: a CLI interface, the set-up of - and also being able to log - tournaments, the "Stroke Play" scoring format, and the management of active tournaments such as updating strokes and scores. These are also some of the most crucial features needed.
The end product, and the main result goal of this project, was of course the program "EasyPut". More accurately the main goal was to create an application meant for a mini-golf tournament organizer, as an easier solution to the aspect of organizing tournaments. Keeping this in mind, the development part of this project have certainly gone according to plan. We have a fully, ready to use program to present to our client, and that of course is a reason for satisfaction. Most features required from the client, have been implemented and the foundation is set for further, future expansions and updates. Some of these features include: a CLI interface, the set-up of - and also being able to log - tournaments, the "Stroke Play" scoring format, and the management of active tournaments such as updating strokes and scores. These are also some of the most crucial features needed.
Some features however, had to be excluded from this version. The main reason being the timespan given to develop the program. Some of these features include: being able to register teams, the seeding of players, and two different scoring formats; "Stableford" and "Match play". These are features that are dispensable, considering how they are not essential for the overall functionality, and could easily be added in the future. Another limitation to the system though, is that if you were to register a wrong score, for a particular hole, there is not a way to change this without manually manipulating the save-file. This also goes for deleting a completed tournament. Lastly, there is presently only one way to update the number of strokes, namely in order of player number and holes.
The process for developing the program seemed to work quite well, especially in the beginning of the project, and for some time it looked to be possible to include all features given by the client. A reason for not including these at the present time, was all the documentation that was expected to be delivered aswell. We realised at some point, that the coding had to be deprioritized. Our role distribution problem, as aforementioned, was a main factor in regards to this. Our effectiveness and productivity was significantly staggered, and while we got a good headstart in phase 1 of our progress plan, in phase 2 we had to do some reorganizing. While the situation in itself was not optimal, the fact that we relatively quickly recognized the problem was exemplary. Besides, as for the technology and collaborative tools used, mainly "GitLab", the group was easily able to collaborate with the coding.
The process for developing the program seemed to work quite well, especially in the beginning of the project, and for some time it looked to be possible to include all features given by the client. A reason for not including these at the present time, was all the documentation that was expected to be delivered aswell. We realized at some point, that the coding had to be deprioritized. Our role distribution problem, as aforementioned, was a main factor in regards to this. Our effectiveness and productivity was significantly staggered, and while we got a good headstart in phase 1 of our progress plan, in phase 2 we had to do some reorganizing. While the situation in itself was not optimal, the fact that we relatively quickly recognized the problem was exemplary. Besides, as for the technology and collaborative tools used, mainly "GitLab", the group was easily able to collaborate with the coding.
There were several problems occuring when working on the documentation, including the collaborative features of GitLab, which, unlike when coding, we found to be more bothersome than helpful. At all times, we had to be careful not to cause merge conflicts, by pushing updates on a document while others were working on it. We initially started the writing process using other tools, such as Microsoft Teams, and unlike GitLab it was much easier to get constant updates on what the other group members were doing. We did gradually make it work though, by separating what each members tasks were, and also by using the issue boards to ensure we each knew our individual responsibilities.
There were several problems occurring when working on the documentation, including the collaborative features of GitLab, which, unlike when coding, we found to be more bothersome than helpful. At all times, we had to be careful not to cause merge conflicts, by pushing updates on a document while others were working on it. We initially started the writing process using other tools, such as Microsoft Teams, and unlike GitLab it was much easier to get constant updates on what the other group members were doing. We did gradually make it work though, by separating what each members tasks were, and also by using the issue boards to ensure we each knew our individual responsibilities.
When it comes to the actual achievements concerning the documentation, and the different phases of the Gantt diagram, you can easily see the results of our struggles. As mentioned in chapter 4, our Gantt diagram is sequenced into four main phases, each essetially describing the three iterations, aswell as a coding phase. While phase 1 in the progress plan went according to our ambition, the coming weeks were characterized by some struggles. Our effectiveness suffered at the hands of, among other things, quite poorly distributed roles, and confusion regarding our individual responsibilities. Luckily we were ahead of schedule in regards to the coding part of this project, so we could afford for it to be deprioritized, while we sorted out how to better the documenting situation. The documentation in question were mainly concerning the Vision document and the project manual. For phase 3 (and 4) the labour was extensively intensified, mostly beacuse of the problems from phase 2. The program, «EasyPut», was coming along nicely, but again, we were behind on most of the documentation. This included the vision document, the main rapport, and the weekly rapports. This certainly, was not according to plan, and had to be effectively dealt with for us to deliver an acceptable end product, with all documentation requiered.
When it comes to the actual achievements concerning the documentation, and the different phases of the Gantt diagram, you can easily see the results of our struggles. As mentioned in chapter 4, our Gantt diagram is sequenced into four main phases, each essentially describing the three iterations, aswell as a coding phase. While phase 1 in the progress plan went according to our ambition, the coming weeks were characterized by some struggles. Our effectiveness suffered at the hands of, among other things, quite poorly distributed roles, and confusion regarding our individual responsibilities. Luckily we were ahead of schedule in regards to the coding part of this project, so we could afford for it to be deprioritized, while we sorted out how to better the documenting situation. The documentation in question were mainly concerning the Vision document and the project manual. For phase 3 (and 4) the labour was extensively intensified, mostly because of the problems from phase 2. The program, «EasyPut», was coming along nicely, but again, we were behind on most of the documentation. This included the vision document, the main rapport, and the weekly rapports. This certainly, was not according to plan, and had to be effectively dealt with for us to deliver an acceptable end product, with all documentation required.
**Reflection on the team process**
...
...
@@ -285,6 +285,11 @@ If we were to give some recommendations for others who may read this rapport, wh
## Chapter 6: Conclusion and Further Work
In this document we have presented for you our product, an application for mini-golf tournament organizing, namely “EasyPut”. We have presented the relevant theory and literature we have used for the duration of this project and chosen processes that fit our needs. Similarly, we have presented our earliest goals and requirements regarding this project, both when it comes to system requirements and features at the time of delivery, but also the status of our process-, impact-, and result goals. We have seen, while working over this 10-week period, how different problems have occurred and how we have attempted to solve them without the time usage suffering too much.
Even though we have had problems throughout, our main goal was indeed reached, and a fully functional program has been made. We have analyzed what could have gone differently, and we have all certainly learned a lot. This will be good to keep in mind for future, similar projects.
