Notably, this section of the course was being used to usher learners from the typical waterfall methodology, into the scrum platform. To a larger extent, these two approaches are very different and call for different points of focus. I have to admit that I experience numerous challenges while switching into the scrum mode. In the beginning, it was clear that the task was not going to be easy. The initial stages in the process seemed to be endless, but with each and every new step, one could not help but further their appreciation for the projects. It stood out to be unique, confirming to everyone that coding deserves more attention than what most people pictures it to deserve. In this first stages, it almost felt as if all students across the board were new in the program. Nobody was able to rise above the rest, showing any prowess in scrum. This was later used as a unifying factor, bringing people together, motivating themselves to work even harder and stand out. This was also my personal experience.
The use of user stories made it easier to develop heightened focus being that one had an idea of what needed to be achieved. This was a very different case being that most participants were already accustomed to working on their capabilities, rather than specific goals. The idea of having goals made it much easier to perform as a group, being that everyone was able to forge clear visions in regards to their contributions towards the ultimate goal. The sprint burn chart emerged as a key tool when it came to polishing out timing skills. Through this, we were able to incorporate timeliness as a virtue in our process. Both planning and structuring of the entire process was made easier, especially being that scrumming was being done in a group setting.
The software architecture in our case was among the most intriguing bits of the project. The idea of using hand held UI, as well as 3_teir structures that are handheld was very interesting. This went against the typical grounds where the database was automatically responsible to making calculations. In this case, the server had the sole duty of keeping track of information received.
It was challenging to mark any area as done, being that it almost seemed like participants were reluctantly moving around the projects. This was only made easier when the team developed a checklist, ensuring that all angles are covered before moving to the next step. In the long run, documentation of achievements stood out as a key ingredient in the completion of the process.
The Git hub was the anonymous choice by the team, owing to its simplistic nature. Most of the team members opted for it, stating that they had at least an idea of what they were expected to achieve. To a larger extent, its centralized nature was tapped into, being that it also allowed for an easier evaluation and tracking of the information that goes through the servers. The choice of using a public server was reach without much of a fight being that the team had a higher chance of using a server that was always online.
My experience of working as a team in this project allowed me to gain crucial skills, including the process of further breaking down user stories. This was done in a bid to have team members avoid overloading a single person. The tutorials came in handy while working at a personal level. The use of the MOSCOW method was very important when it came to helping me and the team, better evaluate our general perspective. The team was compelled to move from a developer standpoint, into a customer, or end user platform. In the long run, the teamwork, as well as the user stories ended up being the highlights of the project.
