Sprint 3 Retrospective

At the end of last week, we finally conclude our third sprint in our development process of the LibreFoodPantry, aiming at a deloyable environments so that they all are isolated in their own space. This is also our last sprint so we tried our best to wrap it up as much as possible, so that the team after us can easily pick up from where we left off. We were able to work together more this time, comparing to us having to separately work on our own stuff in the previous sprint. We finally got a working, operational and deployable user interface as well as a fully implemented, buildable and deployable backend system with REST API and mySQL database. We were also able to adapt with the online communication and worked more effectively with each other.

List of what we accomplished during the last sprint:

       - Successfully integrate Docker into frontend UI and the REST API, allows them to communicate with the existing mySQL container with configurable parameter in config.json file (REST API DockerApproveGuestWebUI Docker)

-         -  Having an operational admin page user interface or ApproveGuestWebUI, although without actually data fed from backend systems, but mocked with data points (ApproveGuestWebUI Epic)

-         Having a mocked or stubbed backend for the frontend to test connections establishing mechanics (Registration Stub)

It seems that we did not do a lot for this sprint, but it was actually much more challenging for us because of more advanced technologies that we have to research on and a lot of new barriers that we have, such as us having more things to do for our career and other classes, voice and video communications became harder as the internet becomes unstable, for me at least, etc. Despite all of that, I think we did a very good job wrapping up all the work we have done from the sprint and even make it deployable, so the next group can just skip the hard part of Docker and focus more on the part of developing operational products for the food pantry. We think that is much more important than to waste time on getting them to be able to run on an actual server, so I heavily prioritized to get it done, both on Docker Desktop and Docker Toolbox. I would say that out of all the sprints, this one is pretty boring since I personally had to read a lot comparing to the two last one that all I do is setting up systems, coding, and a whole lot of checking on people if they can run the same system and if they need some help.

For future improvement, if we have a chance to work more on the project, I think it is better to centralize our work source into either backend or frontend, then move on to another. I believe it is better that way so all the team member can know what other members are doing and learn both the backend and frontend stuff. Another improvement that our team can use is more official communication and well documenting our steps of implementing. It is the same problem that persists from the last run, but we did make sure to have more transparency in what we do this sprint, which I think is a major effort from us.


Popular posts from this blog

Path testing

Software Quality Assurance Introduction

Reflect as you work