Category Archives: Sprint 6

Sprint 6 Retrospective

For the last sprint of the semester, I spent most of my time working on my part for our groups final presentation. There was one minor bug fix that I made involving an incorrect mapping for one of the product endpoints found from a user reported issue, but otherwise the rest of my time was spent on the presentation. This bug in particular could have easily been avoided if the project contained tests for each of the endpoints maybe by using a mock database. If, for example, we had a test that tested what would be an expected successful response, then the test would have failed for the given endpoint because it gave a 404 not found response instead.

For the presentation, since my task was separate from the main project for the food pantry, my section felt like it was a short, stand-alone presentation contained in a longer one. Looking back on what I did for the project, I definitely feel like it wasn’t too complicated and if I needed to do something similar now it wouldn’t take me nearly as long.

That being said, I think there are several major things that I should take away from this project. First of all, although the resources that I followed through were helpful in its creation, I wish that I had started from the ground up to understand how everything actually worked. It’s very easy to get something to do what you want from making minor changes to resources you’ve already found, but being able to actually understand how everything is working together and also being able to explain it well are much harder and take time. Another big takeaway is to make sure to have good tests and to make sure everything is still working properly by running through those tests after making any changes. The fact that the bug with the typo in one of the get mappings exists is proof that I hadn’t properly tested the code to make sure that everything was still working as intended when I pushed my code and created a pull request. I was very fortunate to have run into this issue at the end of the project because if I hadn’t then I might have gone on to make the same mistake in the future.

If anyone happens to work on the project in the future, the first thing they should definitely do is implement the automated semantic versioning that I neglected to do myself. It’ll save them a lot of headache if they make any changes because they won’t have to remember to update the version in multiple locations. Without a doubt, when I saw that issue, it was clear that it was poorly designed. There’s no reason for the current version of the project to be hard coded in multiple locations. Actually, when I pushed the changes for the endpoint bug fix, I ended up forgetting to update the version number and the pull request had already been merged, so definitely fix that first.

Link to project GitHub repository:

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Sprint 6

This week wraps up sprint number six, as well as the semester. This is our last sprint before the semester ends. Some of us, this is out last semester in undergraduate. Many of us will be graduating after this sprint ends. This sprint for our team was nothing entirely too fancy, it was more of a wrap up. Since we realized we were running short on time, and with a presentation of our final project looming just around the corner, we decided it would be best to stop the pipeline of taking in new tasks to work on. I was able to take on one small task in the end, just before we put a halt on work. This task was to add an optional field for gender into the intake form. This was a rather simple addition as I was able to reuse most of the HTML from another part of the form. The majority of the scratch work was done in the Customer.ts and the Customer-form.component.ts classes. In the customer class I had to add gender as an instance variable so that our customer constructor would know that it needs gender as an argument (needing it is specifically for testing purposes, the actual prompt is optional, per request of the food pantry owners). I then had to go to the customer.form.component class and add an array of options for gender, as this prompt would be a pulldown menu option. I was able to create an array of gender options called gender which had the values of male, female, other, or prefer not to say. This way there are enough options to cover the spectrum while also being able to keep the question entirely optional. Once I did this I had to add the gender paramaters into the Customer objects so that it would build the customer correctly. This was the easy part! The hard part comes next. Branches, and pull requests. I was easily able to check out a branch in our repository to get my issues and commits tracked on github. The hard part is the pull request. With the initial pull request, there are many conflicts to be resolved. This is expected, because you’re comparing an old file to a new file that has deletions and insertions, and code moved around. This is typically an easy fix as you can just go in text editor in github and remove the conflicts by hand and recommit the changes right on github. I have done the old fashioned way of running git commands in terminal to fix conflicts, and I find the in-browser option to be the more efficient and easier solution (if it allows, sometimes it isn’t as simple as removing a few lines of erroneous content on github). What happened next is the funny part. In the time I opened my pull request, notified my professor, and resolved conflicts, my professor merged another open request on our repository. Now I was getting no errors (because I had not refreshed the page) but my pull request would not merge. My professor and I were looking specifically at the customer constructor and were wondering why his master version had 18 variables and mine only had 14. After thinking about it for a while, I decided to pull from the master branch then recommit my branch, again fixing all the conflict resolutions. This appeared to do the trick, because I was missing the information from the merge that occurred while I was trying to get my branch merged. This goes to show you that communication is imperative on github and in teams of multiple developers working in the same place. Knowing this would have turned my 5 minutes of code and 45 minutes of trying to merge onto github into 5 minutes of code, a simple merge, and a new task. In the period of time between putting a stop to work and our final presentation, we as a team worked on our final presentation slideshow. We did this as a requirement from our professor, but also as a way to recap all that we have accomplished this semester. Looking back, it has been a fun semester getting to work on a project from scratch and seeing how far we could get. I hope the next food pantry teams have a good starting point, and will continue to do great things with the software.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.


Hello everyone and welcome to another and last sprint retrospective blog post for CS 448. Today I’m going to talk about what went on during our last sprint which is sprint 6. First, what I work on was finishing up the presentation. The steps I took during my steps to finishing up the presentation is that I reverted to the old commit of my original Ampath template because my slides would be about the beginning phases of the project. I made demo clips of both the old left navigation bar and the new left navigation bar to show how it would function. I also created a slide on how to create a blank angular project. I wanted to show I took stuff from the previous class 348 and implement them in this class 448. I also made a slide for the HTML code and the CSS code and I’m planning to explain them during the presentation on Wednesday the 15th. Our group has been working hard to get the presentation finished and we decided that each of us would do 5 slides each. The 5 slides would be about which member work during this semester. I think that we are about done, and the project looks great. During this sprint we didn’t plan much because we were approaching the deadline, so we wanted to just focus our full attention on the polish version of our Ampath project. Mike is going to be presenting the dropdown box during the presentation day and Tim is going to talk about the conversion from GitLab to GitHub. Kat is going to go over the Angular imports and the features that she added. Yensia is going to go over the rest of the Ampath project that she was working on during this semester. All in all, I think I learned a lot during this semester because I felt like this was a good simulation of what a job would be like. I feel way more comfortable in scrum than before. I think the weekly meetings help get used to always working and making sure I stay involve and keep the members of my group updated. I believe that our group works great together and we got many kinds of stuff done during this semester. I think that the left navigation bar was exactly what Greg was asking for at the beginning of the semester. Also, I learned more about Angular while working with this Ampath project. I don’t think there should be any improvements as I thought that the semester went very smoothly, and everything works out. In conclusion, this is the last sprint and the end to a very successful semester and my group was great and I enjoy this experience.

From the blog CS@Worcester – Phan's CS by phancs and used with permission of the author. All other rights reserved by the author.

This Is It, The Final Sprint

Hello, once again my fellow readers! I say this with some sadness as it is my last retrospective for the semester. The final sprint has ended and the team is now in full presentation mode. For the sprint, some of the team decided to keep working on the product and some of the team, including myself, decided to start work on the presentation.

The part of the team that decided to continue work on the presentation worked on small improvements to the product. Small improvements to features we have already implemented and making aesthetic changes.

The rest of the team, including myself, started our presentation work by making a presentation. From here, we decided to break and each of us would start working on our own portion of the presentation. My part of the presentation consists of what happened a few weeks ago with the GitLab to GitHub transfer. You may remember that series of events from my sprint retrospective blog a couple of blogs ago. The main part of this presentation is not just to recount everything we’ve done over the semester, however.

The big part is to recount everything we have learned over the semester. To do this, I needed to go back and reread all of my blog posts. Boy, it has been an interesting ride this semester. Looking back, I have to say that I like Scrum. It took a little set-up but by the end of it all, Scrum worked out pretty well for our team. Everyone in our team was able to step up and take lead when they wanted to and no one person was ever the leader all the time. It definitely led to great teamwork and helped each and every one of us to achieve our individual and team goals. What I find interesting about Scrum, and if anyone wants to replicate Scrum successfully is that I find that Scrum works best as a team that self regulates itself. What I mean by that is, the team is able to find team members that are slacking or behind due to other reasons, and help them get back on the horse. If the team self regulates itself, the team can keep itself on track and make up for momentary weaknesses.

Another thing I learned was quite a bit about Git. When the git repository transfer had to happen as you may remember, I had to transfer our project from our GitLab repository to the min GitHub repository. This process that I went through taught me two things. The first was that we should have planned a bit further in advance when we first created our part of the project. We created our part in GitLab, without a thought. Thinking ahead, we would have definitely chosen to make it in the main GitHub branch we had created. The second thing I learned was about Git itself. During the process of moving, I thought that I could just simply copy paste our files in. That was not the case, and I had to enter in lines of code in some files, to preserve the work that other groups had done. I also had to deal with numerous merge conflicts that I had to deal with as well. I learned from that process how to better deal with those merge conflicts, and with moving files and things into a git repository.

Well, this is it, readers. That’s all I have to say on this semester and I definitely I can say that I got something out of it. This will be the last farewell as not just the semester is ending but I am graduating as well. No more blog posts for me… for now. I may return to writing blogs as they did help me reflect but we will have to see in the future whether I return. I must end sometime, so for the final time farewell my dear readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Sprint-6 Retrospective Blog

The time for the final sprint retrospective blog is here. It is time for Sprint-6 Retrospective Blog Post. As you are probably aware by now, during this semester I was working on a AMPATH project with a team I was assigned to by my Software Development Capstone professor. As part of our assignment we are assigned to complete a Sprint Retrospective blog post at the end of each sprint. As of May 6th, 2019, we have completed Sprint-6. During this sixth and final sprint we were able to complete a minimal viable product to show case in our final presentation.  For this final sprint our task was different from the previous ones. For sprint-6 our task involved the following:

  1. Pulling all final changes from team members and integrating new updates.
  2. try to integrate the other teams work with our own.
  3. Divide the work needed to be done by our team for the final presentation of this project.

During this sprint my team and I focus mainly on trying to get the minimal viable product for the project. That way we can have something ready to show for our final presentation. At the beginning of this sprint we decided to use this sprint to focus on wrapping up our project, and working on getting our final presentation ready. We decided to do this approach by first finding out what we should discuss in our presentation and what each of us in the team should and will be talking about. For the final presentation, I will be talking about building the left navigation bar using Angular Material and how I got the buttons to work and on a new page when clicked by using an app routing module.

Beside working on the final presentation I also, spent a lot of time trying to integrate the other team tabs bar with our left navigation bar. I found this process pretty complicated because I ran into a lot of problems. It sadden me to say but trying to integrate the other team tabs with our left navigation bar was an epic fail. I tried many different approaches and nothing works. I also believe that I would have found a solution to this problem if I wasn’t working on a sensitive time frame.

During sprint-6, I’ve learned a little more about Angular Material, and a different approach we could have done in creating the left navigation bar. If there was time I would have tried the different approach and probably would have found a solution to our integration problem. For this sprint I also spent a lot of time working on the final presentation and trying to make sure that the project looks good and it looks like it contains the minimal viable product. From everything done in this sprint I have learned how we should set up and divide the work we have to cover in the final presentation. I can honestly say that everything done in this sprint has been an interesting and worth learning process from how to work with a team and applying everything we have learnt those far in our software development journey. In light of everything I learnt there are a few things that went on during the integration process that requires details explanations or strategies that would be required for handling the integration step differently for next time. For instance integration should have been done earlier on and the approach we were to use in this project should have been something covered earlier on or in either of the third or fourth sprint. That being said this project has proven to be, fun and interesting.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Sprint 6 Retrospective

After what feels to me as almost an eternity and an extremely short time all rolled up into one, we finally reached the end of our final sprint and are ready for our demonstration of our component and by extension work thus far. For me personally, this sprint was pretty chaotic, not because of the work itself but because of my personal situation. However, I have managed to overcome the adversity of my personal situation and am fully prepared to pull my weight at our final presentation. I am also confident with the plan of attack we formulated in the beginning of the sprint, and I have the utmost confidence in my team members as well. Even given my personal setbacks this last week, I would not proceed much differently as far as planning and preparation.

The first thing we did in the beginning of our sixth sprint was to begin preparations for our final presentation to the entire class. It took almost no time at all for Sam and I to decide on an approximate layout for how we are going to present our semesters’ worth of work, struggles, and achievements. Sam was adept at further refining our general topics until we were able to make rough estimations of how much time we should discuss all the topics we decided on.

After we had our foundation for the concepts we are going to cover, we had a full group discussion about who should and / or would prefer to discuss which sections. We divided the work among ourselves almost effortlessly, and then we began the process of fleshing out our skeleton presentation and decided which topics needed to be discussed with more attention to detail and time dedicated, and which topics we would not need the full standard allotted amount of time according to our original timetable. We did hit a bit of a snag trying to fill the criteria that every person in the group should discuss an even level of technical detail. This minor setback was just a consequence of the nature of presenting; somebody has to do the introduction and the wrap up. On top of that, we definitely didn’t want one person stuck with all the hard parts to discuss. Thankfully, we fleshed out a solid means of distributing the complicated parts of our project evenly among us. This part of the sprint I feel confidently that our group excelled at, as the plan came from a basic concept to an actual solid foundation in little time, expending little energy, and having no disagreements.

This point of the sprint however was when I became once more acquainted with Murphy’s law. Between having car troubles and blowing out a tire (twice in a 24 hour period), and having more personal issues to attend to with my family, I was not able to physically attend a few of our sessions. I made sure to let the group know about my absences, and they were of course very supportive. The silver lining was that we were done with the software developing at that point, so at least I could practice on my own and not leave any slack behind me.

Regardless of any personal or vehicular setbacks of mine this sprint, the work we did to prepare our presentation was spot on and efficient. I would definitely plan all future presentations in this way if possible, and I am excited to see tomorrow once and for all how our semester’s worth of planning, struggling, and ultimately our achievements have worked out.

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

Sprint 6 Retrospective

Since the last sprint retrospective, our group has been working to finalize everything that we have managed to get done so far. Most everything we do have to show for actually was created since the last sprint retrospective. Just about everything before then has been all about fixing errors, trying to understand Google’s material design and how to use it, setting up the development environment and fixing lots of errors. Another team had a working version of their component already, and our team was stuck on an error trying to get the styling to work correctly. The problem was that we were opening the component directly in the browser, just by opening the html file that has the component in it. There’s no connection between the styling code and the HTML code, so there’s no reason it would be properly formatted just from opening it directly, and that was the thing we were having a problem with. It turned out we had to use ng serve to start up the local amrs server, and then the component would show up correctly formatted after visiting localhost:4200. There were of course some more errors in the process of getting to this point, though, which I figured out through a series of Google searches and copying and pasting commands from stackoverflow answers from other people who had a similar problem. Since we got that working and were able to finally see our component correctly, we finished figuring out how to get Google’s material design template code integrated into the component, and then spent the last class officially adding our component to the main branch. The rest of the work we have been doing since then has been about preparing for the final presentation, recalling everything we have done so far and trying to allocate the material among all five of us to discuss when presenting. Most of the presentation is going to be talking about errors and the solutions to the errors and how the solutions to the errors were found. That is because most of this project has been about having errors, looking for the solution to the errors, having more errors with the solution, and then finding the right way to do things. Another portion of the presentation will be about setting up the development environment, which was a pretty big focus in this project. We spent the first couple of weeks setting up a development environment we never used, and then had to set up another development environment once we started working on the angular component. The rest of the presentation will be mostly about the actual programming of the component; what it is, what it is supposed to be for, and what further problems were had in developing it.

This class is very different from any other class I have had before, mainly because the whole time there was never a clear idea of what anyone is supposed to be doing or how anything is supposed to be done. It all seems to have worked out in the end, though.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – Final Round

A reflection on what I learned from this week’s sprint is
that when proper systems have been setup and the team synergy has reached proficient
levels, the completion rate of tasks increase during the sprint and
communication within the group is significantly better.

On the topic of proper systems, this includes repository
management, branch management, issue tracking, and issue discussions. These
five systems are currently being utilized between the two groups assigned to
this project. It took several months of trial and error to effectively plan out
guidelines and familiarize ourselves with them. This effectively allowed the
groups to communicate clear intentions towards a certain issue, reduce
duplications of tasks, and complete significantly more tasks this sprint than
all previous sprints.

Furthermore, improvements towards team synergy allowed us to
communicate more frequently during our sprint planning. This resulted in less
confusing discussions as we can express our concerns towards specific tasks or directly
question certain decisions without fear.

Our main focus for this week’s sprint was to finish the remaining
tasks that would be carried over to this week’s sprint, clean up any mess made
during the development cycle and create an appropriate presentation detailing
our experience working on the project. Finishing up the remaining assigned tasks
will allow us to close up loose ends. This will also create an opportunity to remove
all active and past branches on git before another group takes on the project.

The remaining tasks consisted of several input fields for
the intake form. We chose to continue these tasks because they are relatively
simple to implement. Other tasks that were too large of a job were postponed
indefinitely and were not considered. An example of this would be designing a
database schema for the backend. The reason for abandoning this task for this
sprint is that there would not be enough time between discussing and creating
new iterations of the schema to clear up problems. Time invested towards
designing the database where the implementation will probably be done by a
future group would deem efforts wasted. The effort redistributed towards
working on the presentation was deemed more useful.

Our group contained five members, of which four worked on
the Food Pantry Web Application and one was dedicated to the FoodKeeper API. For
our presentation, we each contributed as much information about what was done throughout
this project’s development process. In the end, it is clearly divided into a
section for the Thea’s Food Pantry Web Application and FoodKeeper API.

What I worked on during this week’s sprint is providing
appropriate code snippets for the backend. This also includes providing any
missing content based on the requirements provided for the presentation.
Lastly, I made an effort to ensure a smooth delivery of the presentation by suggesting
a system for delivery. The system is quite simple as we marked down exactly
which slides, we would like to cover, exchange ideas on how the information
will be presented, and made sure that if changes needed to be made, the group
will be notified. As our chapter for this project comes to a close, the
experiences thus far was impactful and I enjoyed working with my team for the
past month on this project as a whole.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Sprint Review Blog # 6

            The final sprint review of the semester was very successful with our component finally being completed. We ironed out some bugs before finally completing our form component. We worked on the dialogue box that needed to popup after the submit button was clicked. We imported a new module and created a new component for this solution. The module was called MatDialogBox and it was imported from the angular library, but we needed to create a new component to implement it correctly according to the documentation. We had multiple issues with formatting the popup box with buttons that said done and cancel because the default dialog box comes with a text field instead. Once finished, we pushed the changes and asked our instructor to finalize the merge. We realized that there were issues with multiple similar imports from various projects which lead to complications as I had mentioned in my previous sprint reviews. This stage was the stage that I worried about the most throughout the project and reflected on. The merging of our code with other teams’ components turned out to be much more complicated than I initially thought. We needed to remove any imports for angular modules that were repeated within every component that was made in the final project. We had to sift through various groups code to make sure there were the correct imports while also making sure it would compile correctly. We ran into issues very quickly when we ran the program since it wasn’t properly styled. The components that we made overlapped each other when we served it. This meant that the visual details in the html and css files needed to be further modified. We looked into moving the tab component around and the homepage to make sure our component was underneath which proved fruitful. However, formatting the entire project to be visually appealing turned into a nightmare. The branches that we initially pulled to piece the components together turned out to be a branch that held broken code. There was a different branch that held the compatible code with other components which led to confusion in the beginning when we tried to serv the project. We were suggested to leave this task to the integration team, but we still wanted to persevere and try to find some way to make things easier for them. Finally finishing the Q-Form component was a very interesting experience as was this entire project. We went from using real Ampath code to making our simple app that would run off pre-determined data that we would feed ourselves. It was a great learning experience as to how to communicate with a team and understanding a groups workflow to enhance communication between each other. This allowed us to debug together and solve issues much faster in person compared to over our communication channels. I realized that we really crunched through any questions or troubleshooting very efficiently when in person compared to online. This sprint really taught me to understand other people’s point of view when debugging. I learned to be patient and try to understand another mindset even if it takes me longer than necessary. The final presentation really showed me how patience and teamwork can prove to be useful in the grand scheme of things.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Sprint 6 Retrospective

At the very beginning of this sprint, on April 25, Mia was able to push the portion Dan worked on (“Tabs2”) so that we could all see it. Up until this point, the rest of us were not on the same page. We were looking at a previous one we had come up with. We were instructed by Mia to hang tight until she was able to push it.

Ryan and I were both unsure whether she would be able to, so we talked about doing it from scratch. That night, I started the process, but I didn’t get far before Mia let us all know that she was able to get it pushed. At that point, the majority of the component was done. I noticed that the button to create new slides was broken. It was a small fix, but I was able to fix the bug.

Most of this past week was preparing for the presentation. I feel somewhat that I was under utilized and that I could have done more. It is not that I did not want to do the work. I offered often to do more. Once I was able to see the component, most of it was done.

I suggested starting development for another component both before the first was completely complete and after. I was discouraged by my team from doing so. I feel like if we had, we could do at least one more component. I feel that even if we got a start and was unable to finish on another, it wouldn’t be much of a loss.

In the last retrospective, I felt different and that we should just focus on one thing and do it well. I did not realize how far along we were. (Again, I was not able to see it.) I feel that we could have easily done another component in this last sprint and a half. However, hindsight is 20-20, and I didn’t know then what I know now. This was the first time any of us had done something like this, so none of us knew what to expect.

Despite my regrets for not being able to do more, I feel this overall has been a positive experience for this entire capstone. I will be able to take what I have learned here and apply it to the next scrum team I work with. We have not been perfect in communicating, but we have done a pretty good job overall in keeping each other updated. I think we all have seen where we have fallen short, and I think we can use our failures as learning experiences.

Some of our problems came when one of us would run into a problem and the rest of us could not see what they were dealing with and, at the same time, be relying on that work. It would create a bottleneck. It was very frustrating for me to not be able to help in any way when it came to this. I am not the kind of person who likes to sit idly by when I feel I could be of some help.

What I can say about my team is that none of them are slackers. It isn’t often when I feel that I am not the one shouldering most of the work in a group project. This was a welcome change of pace, even if I wanted to contribute more. I found that in a group like this, I should have taken initiative sooner and more often. That lesson will be crucial to success in my next venture.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.