Category Archives: Retrospective

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.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

This past week was the end of our third and final Sprint for the Capstone class. It all went well, and in the end, we got a deployable project and we have completed most of our tasks successfully. I will write about my tasks and my overall impressions of this Sprint. In this particular sprint most of our teams efforts were focused on getting the Docker containers working together and because of that some of our task will overlap more than other times.

Tasks:                                                                                                                                                                

  1. Issue #35: Create REST API Docker container
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/35
    Just like the title says, creating a working Docker container for the REST API.
  2. Issue #47: Create MongoDb Docker Container
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/47
    Same as before, creating a working container with a MongoDB schema.
  3. Issue #37: Establish communication between All Docker Containers
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/37
    Probably the hardest part of this whole project, getting all the separately working Docker containers to talk to each other.

What worked well?
In my opinion pretty much everything our group (BZPJ’s) planned on doing ended up fine and on time, even though we were cutting it a little bit close this time. When it comes to my tasks some of them were somewhat easy and did not require a lot of time, but some were very time consuming and research heavy as well as required cooperation of the whole team to solve (yes issue 37, I am looking at you). What I am also very grateful and happy about is the way our team was able to find time and “place” to be able to work on these tasks. My busy schedule was as always, a challenge to work on things as a team, but in the end we were able to do it.

What didn’t work well?

As always: comments. Due to the difficulty of this particular sprint our team was meeting online a lot to brain storm things together, we were in constant communication and in my opinion this made us ovewrlook the need for leaving comments on this project for future teams and the work that they will be performing.

What changes could be made to improve as a team?

As I have mentioned before, as a team we should work more on our comments and notes when it comes to working on GitLab and making sure that future participants will be able to trace our decisions and thought process, I believe we are simply not there yet but with some minor adjustments it will be ok. As I have mentioned before I think we should work on our problem descriptions, we need to be more specific and detail oriented as well as maybe splitting the problems into smaller subtasks with less of a weight assigned to them so they can be worked on at a faster pace with the feeling of “getting things done”.

What changes could be made to improve as an individual?

The only thing that I can think of after this Sprint is, I would say, my lack of time to spent on the project compared to my classmates but that is something beyond my control. Overall, I am very satisfied with what I have done this time. I have done things that were useful for the group and the state of our project. OK, maybe as I have said earlier, Comments, I should have made more of those.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

At the beginning of this week, we finally reached the end of our second sprint, once a again, completing the back end for the LibreFoodPantry Approve module. My thought on this sprint is that our team did fall behind quite a bit on the goals we set out to finish at the beginning of the sprint due to the fact that we ran into much more problem than we expected and we don’t really have much time to meet up with each other like the last one. Nevertheless, we were still able to achieve a decent amount of goal and almost reach the point to be deployable as a product for just the back end.

List of what I accomplished during the last sprint:

– Successfully implemented CI/CD in every main repositories and get it up and running to check for merge requests build

– Adding all the required endpoints for the REST API system and set it out as a base for the front end to access data

– Successfully established connection between REST API and mySQL database on each member’s machine with a customizable config file to fit with multiple server setup

– Completely overhaul and clean up code for REST API to be more optimized and modular

– Front end wise, John and Kevin was able to make a few basic component to display guest information, made a lot of effort to learn about Material design, and experimenting with communication with the REST API

With a lot of work putting in developing the back end, I learned a lot about how to make connection between REST API system and mySQL. There are a few small things that I can pick up through this run too, like the differences between Docker Desktop and Docker Toolbox, making CI/CD script with different images, and so on.

During this run, it went really smoothly and we only ran into multiple communication issue, and small things during the development process like the date and time is behind when data point is fetched from the database because of timezone differences for some reason, or having to deal with numerous bugs that the default date object in Java caused. Other than those, I think we’ve done it pretty well. 

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

This past week was the end of our second Sprint for the Capstone class. It all went well, and I think we completed all out tasks successfully. I will write about my tasks and my overall impressions of this Sprint.

Tasks:                                                                                                                                                                

  1. Issue #25: Connection between Database and Rest API Backend
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/25
    Creating a Rest API backend that talks to the Mongo Database with specified queries and retrieves total weight.
  2. Issue #2: Fix CI Setup
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/CheckoutService/-/issues/2
    As the name implies, fixing the CI/CD setup for GitLab pipelines, after copying from master it no longer worked.

What worked well?
This time around the Sprint and our lives in general were drastically changed due to ongoing COVID-19 outbreak and the implementations of federal emergency and stay at home orders. It all began normally we started this Sprint like we have before with everyone working on our tasks and meeting once a week for a group session to tackle the problems together. After the outbreak what worked well was very little. In my case finding time and just organizing anything due to my work switching to a “work from home” situation was extremely challenging. One thing that might be working in our favor is that due to most people not working we can call in an online meeting a lot easier since we are all at home. There will still be some time constraints of course.

What didn’t work well?

The social distancing order is a little challenging to work as a small group like this on a project. Before we were able to meet and collectively challenge some of the problems we were having. Scheduling some of the meetings got easier but the actual work time got drastically reduced and in my case just being able to perform some tasks is rather challenging.

What changes could be made to improve as a team?

As I have mentioned before, as a team we should work more on our comments and notes when it comes to working on GitLab and making sure that future participants will be able to trace our decisions and thought process, I believe we are simply not there yet and Corona Virus outbreak made that so much more challenging than before. We also should work on our problem descriptions, we need to be more specific and detail oriented, in my opinion we have only used more generic wording. We probably should have broken the bigger tasks into smaller sub-tasks to make them more approachable as a whole.

What changes could be made to improve as an individual?

During this sprint I have again felt that I have not contributed enough to the team, the tasks I have performed were not as hard as they seemed originally, only working on the API connection to the database took a significant time. As an individual I also think that I should work on my free time management and schedule conflicts. I work full time and often I have only certain time frames to work on school projects and homework and with the temporary adjustments to our living conditions that has gotten even worse. This time will be a real test for all of us, test of our self-control and patience.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

At the middle of last week, our team finally concluded our first sprint, working on user approving system for the LibreFoodPantry. Overall, I think our team did pretty good on doing a lot of initial setups and communicating with other teams to make sure we can have a consistency on data across databases. For me personally, I did quite a lot of work on setting up repositories, researching on making the back-end database, and helping my teammate, as well as people from other teams on the problems that they have that are related to our module.

List of what I accomplished during the last sprint:

– Setting up repositories, including ApproveGuestWebUIApproveGuestService, and isApprovedWebUI, which regarding to tasks like forking from templates, enforcing rules for making changes to the source code, and informing the team about that policy.

– Researching about how mySQL database can be initialized on Docker containers, import – export existing mySQL container for future usage, and communicating to it from outside of the container (wiki page is available at link)

– As I am more interested in getting the back-end to finish in the early stage of development, I helped one of my teammate, Tyler, to make documentation about REST API endpoints and further getting feedback and making suggestion with other teams on those endpoints (wiki page is available at link).

– With all that endpoints in place, I setup the schema to potentially be what the mock and the actual database looks like and getting appropriate changes to it to match with the Register Guest module (wiki page is available at link).

– Finally, I had a lot more time towards the end of the sprint than I expected, so I dug deeper in setting up Spring Boot for the REST API and making a few objects within the program to lighten the amount of work for the next sprint.

With a lot of work that is put into initializing the project, I also learned a lot. While I did have a chance to experience SCRUM on my last internship, this time we use Gitlab as a tool to log all of our work, which I really the simplicity but professional and effective, rather than Jira and Confluence, which are more corporate driven software. I also learn to operate Docker, which I delay on getting to know it for a while as I though to myself that virtualization is a most optimal way to go, and after the last sprint, both are now under my consideration for future projects. And lastly, I learn that communication is really important, especially in the early stage of development, as a lot of data structures have to be defined and unified among the teams.

There is also the excitement, and at the same time,  frustration, of planning what to do to optimize the time and the work needed to get the job done as we had a list of questions without a clear answer on where we should head to. Although on Gitlab, we got really few comments put up, the teams had a lot of face to face conversations to make decisions on problems, and that I think is a problem that we need to record more of our conversation during the next sprint. At the end of the sprint, we are able to finish every issue tickets that we put up initially and we got quite some spare time afterward so I think we did a really great job on what we set out to do and I think the more sprint that goes on, we would be able to take a much heavier workload.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

This past week was the end of our first Sprint for the Capstone class. It all went well, and I think we completed all out tasks successfully. I will write about my tasks and my overall impressions of this Sprint.

Tasks:                                                                                                                                                                

  1. Issue #21: Define Database Schema
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/21#
    Creating a small UML diagram of possible database schema, open for further revisions later.
  2. Issue #6: Create UML Diagram for REST API Structure
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/6
    As the name implies, creating a UML diagram for REST API structure for our project, open for further revisions later.
  3. Setup production Database
    https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/11
    After deciding what our team will use as a database for the project we have made some preparations to make sure it is working correctly and we can do necessary operations with it.

What worked well?
In my opinion pretty much everything our group (BZPJ’s) planned on doing ended up fine and on time, when it comes to my tasks they were somewhat easy for now and not necessarily required a lot of time, in my opinion being able to use some of the knowledge from previously taken classes was a very good example that what we learn is useful in the “field” application. What I am also very grateful and happy about is the way our team was able to find time and place to meet regularly to be able to work on these tasks. With my busy schedule it was always challenging to have a team able to work within my time constraints.

What didn’t work well?

Comments. I think as a team we were not quite there yet when it came to work on this big group project that others will take over eventually. I also believe that some of my contributions to the team could be more, after this Sprint I’m not sure I have done enough.

What changes could be made to improve as a team?

As I have mentioned before, as a team we should work more on our comments and notes when it comes to working on GitLab and making sure that future participants will be able to trace our decisions and thought process, I believe we are simply not there yet but with some minor adjustments it will be ok. We also should work on our problem descriptions, we need to be more specific and detail oriented, in my opinion we have only used more generic wording.

What changes could be made to improve as an individual?

During this sprint I have felt that I have not contributed enough to the team, what I had to make were some diagrams, only the work on the database was somewhat challenging, even though most of it was handled by my teammate and I only helped with some of the parts. As an individual I also think that I should work on my free time management and schedule conflicts. I work full time and often I have only certain time frames to work on school projects and homework, but to be honest I also waste some of that time. Another thing I should probably work on more is to do more research on topics assigned to me, not only finding enough to get my portion completed. As my previous post said I need to Dig Deeper.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint Retrospective 6

Sams ShipsHey guys, it’s a weird feeling to be wrapping up my last semester in my undergraduate career in computer science (and sociology). For this final installment of my AMPATH sprint series, I will just go over the general overview of what went on for my team.

Most of our updates went onto our PowerPoint presentation, which is going to be presented on May 15th, 2019. My team and I are looking forward to presenting the overall process of our group’s learning and working process, the many lessons we learned, our advice for future students, the work we tried to implement, and various other technical aspects of our project.

We decided that on top of the search bar work, it is also a priority to organize the git repository so it can be better organized and an open work environment for other classes. I think this is important especially when new people come in and cannot efficiently locate and access the files they need. As someone who was once new to an organization that had a lot of different projects and files to sort through, I believe that this is very considerate of the team to go with this.

With some limitations my team had to face, we worked around it to determine how we should move forward. The end result is pretty much a search bar that is attached to the toolbar. It cannot currently be live tested due to there being no backend but it can definitely be done in the future under certain circumstances.

It was interesting being able to observe how much planning you can start with but still end up having to take detours, starting new paths completely, or sometimes even needing to take U-turns.

I thought it would be important to pull some of the advice for future students from our PowerPoint and include them in this wrap-up:

  • Point out and address problems with technology right away because others around you might have the same problem(s) so you can solve them collectively
  • Do all team implementations in a separate component based on what you will be working on
  • Merge your work constantly to the master branch so each team can have the updated changes

A pattern I am noticing in a lot of teams or group projects is that not everything is going to work out in ways that you expected or were hoping for but you learn to move as a shifting team to make progress and continue growth.

Overall, I’d say I learned an important life lesson from this: if I am to contribute extra time on top of my technology career in the future to work on side projects, it will be a challenge to allocate time if it is a group initiative. I also learned that even when we try to communicate everything there is still more room for miscommunication, so there may be no such thing as over-communicating. I am happy to say that we always tried our best to move forward in all ways!

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint 4 Retrospective

Sams Ships (12)For this sprint wrap-up, we discussed how we are trying to move on based on our team planning meeting. One of my teammates, Kristi, along with Professor Wurst, tried to check out an idea they had and continued to bounce ideas back and forth with one another until they came to a conclusion.

Overall, I’d say we are continuing to plan out our next steps and work on something new. A new development was a suggestion by one of my teammates based on what we already have to work with. The suggestion was that we should wait for the other group to push what they need and then we can seamlessly build upon it. If the other group (who are working on the sidebar and navigation bar) add their work, it would help us have a better base.

We have to carefully analyze how the components are going to go together and get through to make sure that they are not just getting thrown in. If we plan things out more, it will make the process more efficient. I think taking a step back to look through angular was helpful because it allowed us to learn something new at our own pace. It’s nice to not have to rush on what we are doing; especially when the concepts are newer. This will help us deliver something even greater for our client, who is Greg from AMPATH.

There is also the approaching team presentation that we are going to be focusing on to explain our work and what is happening. I think it will mainly be focused on the search bar and our experience with learning angular or the concepts that introduced us to it.

On top of what we have been doing, I have been continuing looking up resources to learn more for our project. I think Codecademy is a good reference for learning AngularJS, https://www.codecademy.com/learn/learn-angularjs. It is actually one of my preferred sites for reviewing programming languages to sharpen up on things I may have forgotten or for learning new ones in general.

It has been a great experience being able to work with a solid team so far this semester. I wonder how much we will accomplish by the end of it! I think learning about communicating within a team is so important, especially since we will all be graduating very soon and entering roles that require consistent communication.

Overall, the only thing I would say I would have proceeded to do differently is come up with another way to “work smarter not harder” when it came to figuring out the process for the search bar. There were not necessarily any fails because our continued work dealt more with the planning behind the work instead of testing to see what worked for us. I am very excited to continue moving forward with this project in the few weeks we have left!

Some advice for others who are going to work on things includes:

  • Having an open mind on what they would like to do because things are always changing
  • Understanding what the client wants is important because at the end of the day, they will be the ones who need to use this software
  • Try to make sure teammates are on the same page with you on what is happening that week

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

SPRINT 6 RETROSPECTIVE

Summary

This sprint was a very important one considering what we had sought out to accomplish. In this sprint, we wanted to add many functionalities and since it was the last full sprint before the end of the semester, we wanted to address all the major functionalities we felt needed to be added before we called it a semester. Some of these tasks that was being addressed this sprint was : 

  1. Updating Offline Track Refresh Time.
  2. Documentation of work that was completed 
  3. Test Cases – UI Checkbox Test 
  4. Backend Functionalities. 

Most of the documentation was done by our team captain, since he had the most understanding of all the moving parts that was involved in the program.

What was Accomplished 

Of the tasks that was set out to be completed, we were able to complete the offline track refresh time and also the backend functionalities of the program. To make things more clear, we also documented a list of classes and files that we touched / edited and also draw a diagram of how we envisioned our additions and modifications to function within the application. Backend functionalities was tricky but we were able to write modify existing methods and function and also wrote new methods that would aid in completing the requested task. All this work was again documented and revised.  I believe the most challenging tasks through out the sprint was coming up with test cases that would evaluated and affirm the functioning of the proposed written code. I was personally in charge of this testing. From deciding to address testing, i was able to dig through many codes and files that we later had to review and revise. Every code we wrote needed some sort of testing module that would verify its status and would be used to troubleshoot should we find have any issues in the future. 

Reflections 

After this sprint, i conclude that testing although may not seem like it, is one of the tedious tasks of writing code. In order to write efficient and proper test, you need to be able to understand the logic thats already being implemented in the code then reverse the thought process and develop a new way that you can verify that the task got accomplished.  I realized that not only do you need to be able to read and understand code efficiently, you also need a creative edge that would be used in coming up with test cases and scenarios. This is because unlike coding, often test cases and implementations are unique and does not already have a laid out methods to get this accomplished. Coding requires pose and originality but i believe testing adds a touch of creativity to this paradigm. Overall it was a good sprint and i think we were able to communicate better and get a lot done. 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective

Summary

Once again, i think we had a successful sprint this round. Once again we increased team communications and continued to form better team bonds. This is specifically because this sprints task required us to consult each other for things we have expertise in so we could build together what we needed to build. I this sprint we took upon quite a few tasks to get accomplished. Some of these tasks included taking the offline checking of the current ampath build and moving it to the outside of error checking and by doing that, figure out a way to fix the OnlineTrackerComponent bug we found in the program. Another that that needed to be done was establishing communication mediums with the AMPATH group and addressing some development issues we wanted to discuss with them. We needed to know if we had to worry about storing secondary and additional user login credentials offline. Knowing this would prove pivotal to our developmental Sprint. We were also able to create a backend of the new UI we were implementing using Balsamiq. Another task that was sought out this sprint was to update the HLD with local storage approach and add a checkbox to the user settings page to give option to store credentials locally. This task was taken by one of our teammate and although they were working on it alone, collaboration between the individual groups was needed because there were a lot of dependency issues. 

Reflections 

From this sprint i learnt that sometimes not all the task we seek out to accomplish during the sprint planing is able to make it through the entire sprint. During the initial sprint planning, we had a talk about implementing a local database that would store and keep user credentials so for the few days into the sprint i began building the database base but as the sprint progressed and our team was able to communicate with the Ampath people, we realized that that extraneous part of building the database was not necessary needed. Instead understanding the encryption method of the user credentials would better suit us in our task of creating an offline login. Needless to say, i had to clear the drawing board and start again.

Lesson Learnt

Overall i felt like this was the biggest lesson i could take from this sprint because i started building and spending time on it but since it was ruled out as not necessary, it almost seemed like i had wasted that sprint time. IT made me realize that in this software development industry, the product owner and the businessman have the keys and unless you ask them for it often you will develop and code in a backdoor without even realizing that your design grew old in the specifications. Establish a good and frequent communication method with the people overseeing the demands and design of the project serves as key in become a good program develop. It makes no sense to design and solve a problem with no longer exists in your scope of work. 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.