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.

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.

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.

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.

            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.

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.