Category Archives: Sprint 2

Second Sprint Retrospective

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/25 got familiar with NGINX

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/41 Made program read MySQL login info for rest api

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/21 Implement Endpoint /needsApprove/between

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/46 Design /approveUpdate

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/22 Implement Endpoint /Approve/all

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/37 Implement guest-info Component ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/20 Implement Endpoint /getGuestInfo/{id}

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/30 Create connection between database and Rest API

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/40 Create and Link Epics

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/5 Create mock database in mySQL

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/19 Implement Endpoint /isApproved/{id}

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/47 implement /approveUpdate

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/51 Install Angular Material in ApproveGuestWebUI Project

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/32 Create UI Design for ApproveGuestWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/45 Implementing CI/CD for IsApprovedWebUI

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/44 Implementing CI/CD for ApproveGuestService

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/49 Questions to ask Joanne from Thea’s Pantry

I believe the thing that worked well for us in this sprint was constant communication and trying to help each other with issues that we were facing or that were related to one another. I think our team did a good job on staying on task and completing things at a good pace and each member was actively involved with each person’s code since we needed another person to review our code and approve it for it to be merged with the master branch. Due to the situation going on in the world around us the sprint was hindered due to the extra week of spring break and our group got a little too comfortable during the break and neglected our work. I think we had a lot of great things that we should have weighted a little differently and we had no idea that the weight of an issue can be changed during the sprint as well, so had we known that we would have readjusted a few of the weights to be more reasonable for the amount of work that was required to complete the issue. As a team we could benefit from meeting at least once more outside of the regularly schedule class period during the week to be able to complete more work and have more opportunities to figure out what works and what doesn’t. I feel that I got too complacent during the break and neglected this sprint’s work toward the end, so in the future I hope to be more focused and on task even during things like a two week spring break. I should have also spoken up more when I felt that an issue was not the correct weight, but I wasn’t fully sure since the last sprint we had, we finished all of the issues way before the end of the sprint.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

Sprint Two Retrospective

If the first sprint was crawling, then this sprint we moved straight to running. When considering the shorter length of the first sprint we appropriately stuck to smaller “set-up” or preparatory goals. This time, we began actually building our site in earnest. My focus, as evident from the list above, is web design and development for the UI/UX. At the beginning of this sprint, while planning, I was at a loss to quantify what exactly needed to be done. One may notice that many of these issues were posted within the last few days of this sprint. Considering I haven’t built that many websites, and none with so specific of a purpose, my thought was that I didn’t know what I needed until I had it: I would simply figure things out as I built them. This flies in the face of any good practice, and I will of course avoid such practices moving forward, but given my inexperience I had to lay the tracks in front of us as we steamed on. This manifested as an incredibly broad task, “Implement the UI from the wireframe”, with us then filling in the gaps after.

This worked, but not terribly well. It has given us a working front, albeit with some missing or broken features, but a code base desperate for refactoring. As with last semester, I often would end up learning about a useful feature after I had already beat my head against the problem and found a roundabout way of solving it. For instance, despite implementing a new directive, I did not know that services could be split off as well and shared by all components. The list of all Guest IDs, for example, would be best shared by all components instead of how it currently is implemented, which is a hodgepodge of emitters with no “real” persistence between components. It can currently pass guest IDs effectively between them, but this could be done, presumably, much easier using a service. I’m not completely certain either, it will be another instance of a new technique we’ll have to learn as we implement it, but I would have liked to have started here rather than arrive here after what will become somewhat wasted effort.

I say somewhat wasted, but in reality, it doesn’t hurt to know how to approach problems in many different ways. I believe using emitters is a valuable skill to have. Additionally, I now know at least three different ways to embed svg into a web page, with each successive one being more effective than the last but with all having their uses. I feel that I am certainly improving as a web developer, with each new misstep putting me in the direction of a better solution. However, I have a lot to learn in regard to version control systems. I caused a few headaches for poor James, who kindly walked me through all my poor practices. I know now never to push directly to the master branch for a new feature and utilize merge requests effectively. Also, never copy paste anything, because they are treated as new files even if they have the same exact content and will cause innumerable conflicts. In addition, Pawel and I ended up both independently working on the same issues, but we have discussed ways to avoid these situations moving forward. Even with all the growing pains mentioned and those involved in moving everything online, I believe we have found ways to be an effective team as well.

For this next sprint, our tasks already look much better, each containing the fine detail of work that needs to be done in order to reach our next project iteration. There are considerably more tasks, and none that are as horribly broad as many of those in this sprint. We possess a better sense of what needs to be done, and we can act upon it. By applying all the lessons learned thus far I believe we are closer and closer to something that can actually be used by the food pantry and should all be proud of that fact.

From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.

Capstone Sprint 2 Retrospective

This second sprint brought with it some challenges in moving to online classes for the ongoing epidemic, but with it a stronger grasp on communication and documentation using GitLab and Discord, both out of necessity and intentional effort. We have learned to better work with LibreFoodPantry workflow and are ready to go into our next sprint with our REST API, Database, and Frontend all working in isolation.

My contributions

Create file with definition of done.

Change to default .gitignore file for Spring and remove unnecessary tracked files from before we added the .gitignore,

Research internationalization support and decide that it is better to be saved once a more-final version of the front-end is complete.

Research Angular Testing and create a Spike project that covers most cases we will encounter.

Integrate ID scanner to get Student ID with an Angular component and create tests to have 100% code coverage.

Retrospective

For the first half of the sprint, we were still having weekly meetings to work together. One of our troubles last sprint was that we were discussing things in person and not doing well documenting the reasons for decisions we made. We improved on this even while having in-person meetings. By the second half, although we were all coping with changes brought on by moving to online classes, we did well in keeping each other updated and communicating through GitLab. In hindsight, it’s probably a good experience to be forced to do this. Especially if this epidemic inspires more software companies to promote working from home.

The biggest issue we had as a team was working with merge requests. There were a couple cases where code on a feature branch was not kept up to date with the master branch. As a result, there were a lot of merge conflicts to work together on resolving as a team. Overall, working through these together as a team was a good experience, because this is bound to happen when working in tandem with version control. However, now we will be reminding ourselves to pull changes from origin/master as we are working on our local branches.

We also improved with creating merge requests for each individual features, although this took a few weeks for us to all do efficiently. GitLab has a great feature where you can tightly-bind an issue to a merge request, but this caused a couple of problems for me. When the merge request is accepted, the issue is automatically closed. This messes with our workflow, because we want the issues in the “done” column, only to be closed by the product owner. Moving forward, the issues should be linked with their merge request but we will have to take care that the description doesn’t include a “Closes issue” tag.

Furthermore, when a branch is automatically made in GitLab, it creates a very verbose branch name, which is simply annoying if your Git isn’t configured to autocomplete branch names when pressing “tab”. In the future, I will create a new merge request and manually select my already-created branch. Then I will manually link the issue.

The team’s willingness to quickly meet over Discord about an issue we were having was the best thing about this sprint. In the few cases where something occurred outside of class time that required all of us, we were able to set up a time the same day or the next day and resolve the problem. This flexibility to schedule work within the sprint is what helped us get as much work done as we did.

The next sprint will involve combining our individual pieces into a working product that is capable of storing actual checkout transactions. There is a still a lot to learn and to do, but we are well on our way to finishing a viable product that we are proud of, albeit with much room to grow in the future. We will have to pay close attention in the next sprint to creating well-written documentation as we combine our API, database, and front end so that future developers can easily recreate what we’ve done and get it running.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/-/issues/38

This is the guest-approval component that I have been working on with Angular material.

In the beginning of the Spring before moving entirely remote, I believe we had a good plan set in place in order to be able to accomplish all that we wanted to do. Originally, we were going to have John and I work on the WebUI together while Khoa and Tyler would be finishing up with the database and API. We were making good progress until we had to move to remote.

Once I moved to remote, I ran into many problems along the way. The transition into all online classes caused me to lose time towards all of my classes collectively. I had still been working for a majority of the time off and needed to put more time towards my classes outside of school than I had before. From there I ended up becoming overwhelmed by the work. I had to have been doing other schoolwork trying to catch up on everything I had fallen behind on. Once I started working on the approve-guest component I ran into a lot of problems. I had a functioning component before the time of going remote but once I started working on the component again, I ran into a bunch of problems. I was able to get my code to run and load in any HTML editor but once I moved it into WebStorm, there was almost always a blank page. I went through all of the dependencies, created new projects and consulted online with many different resources.  I seemed to be incapable of providing what I needed to for my team at the time.

The only improvement I can say for our team is that we need to be able to discuss more of what is going on throughout the project. We will have to find a way to be able to piece together all of the pieces that we have on GitLab into one project.

I need to put all my effort into this next Sprint because it has not been fair for what I have contributed during this time. I was not as available as I should have been with my team. I also needed to be able to better communicate that I could use some help to get my component back to functional. During the next spring I plan on going above and beyond for my team as they have all been doing an incredible job with this project. I will try to have daily discussions with my team in order to ensure that I stay on track. I will also try to be more active on GitLab with such things as moving the issues to done, approving merge requests or creating new issues. Hopefully this next sprint, I will be able to better estimate how long each problem will require so I can set more time aside for each one. I look forward to making this next Spring into a fully functioning GuestApproval.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Retrospective Sprint-2

This issue was to create a Backend Rest Api that could communicate with both our database and Front End UI.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/11

This issue was done early in the sprint to see if MongoDb was a viable option to use for our project.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/8

This issue was to create a definition of done for our issues so that the team had a better structure to follow when working.
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/-/issues/23

In sprint two our team excelled in taking on the correct work load. Sprint one left us with too little work and we had to add things while we were working and even did some work without creating issues. However, in sprint two we proposed our work with proper weight classification and so we had just enough work. Our workload reflected our Sprint length well and we were able to split up the workload well between team members. This time around we took large tasks that had several parts and instead of weighting them higher we broke the issue down into several smaller issues. This way we were able to spread the workload out throughout the team and didn’t leave anyone working on one large portion of work for too long. I think this worked to our advantage because it was easier to formulate a plan and track our progress this way. As we completed more smaller issues we could see how far along we were with progress and dictate work to team members better. 

We didn’t have much of a problem at the beginning of the Sprint, although, towards the end when school was moved to online classes only we began to have some issues. It may not be within our power to control but the move to online classes was a detriment to our work ethic and communication as a team. Having a second week of spring break that otherwise would have been a week of working was a blow to motivation and the team’s communication was lacking. Now that we have returned to classes online we have gathered ourselves well and are ready to work. However, the removal from our work for twice as long as we had originally planned deemed to be a detriment to our momentum. We still completed the work load we had planned but we felt rather scattered.

Moving forward we need to work on our communication as a team. Before the national crisis we would meet in person as a group weekly and work for three or more hours together. This synchronous work ethic proved to be our most productive environment. Now that we cannot meet in person I think we could plan for synchronous online meetings to help aid our disconnect. Even if we are not collaborating on issues I believe it could help morale and productivity to know we are all working simultaneously.

As an individual I believe I just need to get back in the groove. Hopefully, with the help of my team we can create a schedule to add some structure to our workflow and get back into a forward momentum.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

LibreFoodPantry Sprint 2 Retrospective: Controllable and Uncontrollable Variables

Here is what I worked on during this sprint:

Sprint Reflection:

It has been so long since the onset of this sprint that it is somewhat hard to remember how it even started. What I do remember is that coming into this sprint, my team and I were determined to get more work done than in the previous sprint. It looked like it would have been relatively easy since we had a longer sprint this time and our collaboration had improved greatly since the start of sprint 1. The start of the sprint proceeded smoothly and I took some intro to UI design courses to get the mock UI done within the first couple days of the sprint. We acknowledged that more work had been proposed for this sprint, but we had more time to get it done and I was confident that I would have the time over spring break to get both frontends completed. I think up to the point where all residents on campus had to move out because of the danger of COVID-19, I think my team’s communication between each other and planning was much better than the previous sprint. Issues on our board were much more granular and detailed and all of them were linked to the proper Epics and had the proper tags. I think all members of the team started to take the Scrum practices more seriously and it showed in our organization and communication.

This is when all of the uncontrollable variables of life hit us like a truck. All of the stress and changes in dealing with a worldwide pandemic definitely took a toll on my productivity. Rather than spend this whole retrospective talking about how COVID-19 ruined my plans for getting the frontends completed, I’ll talk about how we could have better prepared for this situation. Spring break was extended by two weeks and there was nearly a month without communication between our team. Over this time I felt uncomfortable asking for help or clarification about issues I was having with my team since I had no idea what anyone was going through. I decided it would be best to hold off on development until classes started up to give all members of the team time to adapt to the fully remote life that we are now living. While this is an extreme case, I think this is a good lesson in accurately weighing tasks as well as not adding too much work to a sprint. While creating issues I think my team and I fell victim to weighing everything using a “best-case scenario” approach. All of the weights created reflected the time it would take for us to complete a task if nearly nothing went wrong. As a software developer, I should have known that failure is expected and every task will almost always take longer than you think. Next time weights will reflect the reality that things go wrong so we can more accurately fill up our sprint with tasks. When determining what we would put in the sprint we were taking into account the time we’d have over spring break. This meant to get all of the work done for the sprint we’d have to put in a good amount of effort over the break. The misjudging of weights combined with this meant that an event as serious as coronavirus caused us to miss our sprint deadline for a lot of the frontend work.

Going Forward:

As an individual, I will be more responsible and truthful when weighing tasks. I will also communicate with my team and other teams as soon as problems arise so we can resolve any issues I am having as soon as possible. As a team, I think the place we could improve the most in is reviewing completed work. Allowing merge requests to pile up on GitLab causes development to slow down until those get merged. We decided to try and keep our “Needs Review” column to two issues at all times, but this was not enforced as much as it should be.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

AMPATH-WSU Sprint 2 Retrospective

And the issues continue… ?

Hello dear readers, welcome to my second retrospective blog post. I don’t know why did I decide to switch to using MAC laptop on the last semester of school. As I mentioned on the first spring blog, I was able to fork and clone the code but was having issues in the terminal when trying to build the code. We figured out that the build environment was not fully set up and there was also something else wrong. To be honest I got pretty mad at MAC as I was having issues in another class for installing a virtual machine. I had an old windows laptop at home so I just started to install everything form beginning on that laptop. Sam, my other teammate which is also a MAC user had issues but different ones.

I would like to mention that I really like the way our team works. Kristi was able to help me and Sam with the issue of building the project locally. We always help each other and we don’t leave any of us behind. In my opinion this is a very important behavior to have in a team because that makes a team more productive and brings the teammates closer to each other. StackOverflow and Google helped a lot as well. Realized other people had had similar issues in the past as well. I would strongly suggest to research about the environments and tools you are going to use before you start installing them.

After we made sure that everyone was in the same page and each of us had everything set up we went and checked our to do tasks. I mentioned in the first sprint that that spring felt like a research sprint, I would say that this sprint wasn’t that different either. Actually I was not expecting  to start development right away as we were exposed to new tools. I would like to say that even though we haven’t started with development yet I am very happy about all the material that we are learning as its very useful and gives us a great experience.

Before the end of the second sprint we were notified that the developers in Kenya gave some additional information to our professor about what do they want the app to look like and what are some of their requirements. I also know that they send us videos of the wire-frames. This will allow  us to analyze the requirements and apply all the knowledge we are learning in the CS-448 (Software Process Management) class. We are all very excited to get started on watching the videos and start working on this project.

I would say that we did a lot of learning during this sprint and I would like to assume that the next sprint will be the same as we are going to study, analyze the requirements given, and separate out duties within the teams and within each other. I opened a few of the videos that Greg had posted for us and I am really excited about this. I can’t wait to let you guys know where’re we at by the end of next sprint.

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

Another Sprint, Another Retrospective

Hello, again my dear readers! Another sprint has passed and as such, it is time for another sprint retrospective. These couple sprint weeks has left my group and me with a slightly lower than average workload. From the first two sprint weeks, not much has been added to the Trello sprint work board. The bulk of this sprint’s work was funneled into two major setup tasks.

The first of these major setup tasks was ensuring that each member of the team had the ng2-amrs software on our individual development environment. We also had to ensure that each person had it set up so that ng2-amrs could be built and run on each individual development environment. This proved to be a task that would throw more unexpected errors our way than I think any of us could have expected. Of the few in class meetings we did have, many were spent debugging and troubleshooting many of the varied npm errors that rose up to bother each and every one of us. My personal experience with installing ng2-amrs and getting it running was not the worst of all the ones in our group but it was not without its issues. I myself encountered three separate errors that stopped me in my tracks. However, thanks to the knowledge of my fellow peers both in and out of my group, they were solved. The rest of my fellow peers had similar troubles with the same bugs that I experienced and in addition, some new ones as well.

The second of the major setup tasks for ng2-amrs was for each team member to study and get familiar with Protractor and Karma. Protractor and Karma are both testing frameworks for Angular. Thankfully, there were easily accessible, available, and easily understood tutorials that were available right from the web sites of the two respective home pages of Karma and Protractor.

While not much happened these two sprint weeks, I can not say that it was spent lazing around or that it was quite unproductive or fruitless. Setting up the ng2-amrs was a good introduction back in to working with npm and was more than just learn the two basic commands of ng build and ng serve. In addition, I can now say that I am much more in tune when it comes to solving errors that might pop up when building an npm server. I have also learned what to search for on Google when a specific problem does crop up and wherein the error code to look to actually find the error that has actually occurred. Learning both Protractor and Karma was a nice change of pace as well. I remember learning how to test in my 443 class last semester and I remember that it was an interesting and enjoyable experience. Thus, this week two sprint retrospective comes to a close. Hopefully, in the next sprint, we will receive more messages from the project representative and be able to dive into something a little more relevant than just setup.

Until next time 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 2

This week finishes up sprint 2 of our senior software development capstone project. In this sprint we accomplished quite a bit. The most important advancement that we made in this sprint is getting specifications from our product owner as to what we need to do for them. At the begining of this sprint cycle we were able to meet with a representative from the food pantry, Serena. Serena was able to tell us more about the food pantry and what they are doing as well as what they would like to see as a product from us. One of the biggest takeaways from this meeting was to realize that the main objective for us is to assist the food pantry in their quest to transfer all their business and business operations from paper to digital. One of the largest problems we realized off the bat is that the food pantry does everything from data storage to daily operation by paper. We know as software developers that this physical paper way of doing things is very inefficient and can be vulnerable to human error (totaling numbers in wrong columns, incorrect data input, etc). Our thought was to help them by making software to help them transfer to digital and also do some automation for them so that they can avoid any possible human error. However, we as the software development team are not here to tell the food pantry owners what they should be asking for. There is a fine line that a software developer working with a product owner where you should suggest what you think you should develop for them that may be helpful while also staying within their guidelines. The biggest issue here is that the food pantry representatives do not have a definitive set of product guidelines and rather are open to any ideas we may have for them, as they currently are 100% paper and are looking for any help to go digital in a way that is useful to them. I enjoyed this part of the sprint because I got to interact with the people on the other end where we can talk about what we need to do and what we would like to do. After our meeting with the product owners we were able to start on our project. One of the group members started working on back-end development and was able to deploy a gitlab project for it. I started working on a front end HTML mockup of our worker client screen. Another member of the group worked on finding out how to parse a json file using gson. After our most recent sprint meeting we decided on tasks that we’ll start doing for the new sprint. More front end development will be done this sprint. This will be taken on by myself and another few team members. I specifically will be working on CSS stylesheets for our project. The other members will begin writing a Java program to connect our project to a database. In sprint 2 I learned a lot about project management and working with product owners.

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.

Sprint 2 Retrospective

Not a lot has happened in the last two weeks. There has not been a clear assignment given to be accomplished individually or as a team. On the first class meeting of this sprint, I helped Matt get through the final errors to get the ng2-amrs, since he was seeing the same errors that I had seen and figured out how to get through myself. After installing the right version of node, and then following the determined steps to fix the series of error messages that come up after trying to run npm start, it says compiled with warnings and does not error and the AMPATH login page comes up when visiting localhost:3000 in a browser.

Once he got it running, everyone on the team was able to run it without errors, so we had nothing left to do but vaguely review some miscellaneous information about JavaScript and angular. After that, our team did not meet in class for a couple of days or class had been canceled. It was not until Thursday during the sprint review that we started to get something to do, but that was the last meeting before spring break, so we did not get a chance to actually start anything, only to look at the new information that has been given and begin to process it.

From watching the first of the six AMPATH videos that we were sent, it looks like we are being given an existing user interface and it is up to us to implement the desired logic and behavior to have it interact with the medical records back end. The videos walk through some of the buttons and elements that were already placed together on the front end, and some specifics are described about what the elements are supposed to be for and how they should interact with the medical records data. From here on, we will finish watching the rest of the videos to better understand what they explain and what is expected of us, and we will have to decide among the other teams who is doing what, and figure out what it is we are actually going to be doing and how to do it. From what I have understood so far, I think that we are going to need to read a lot of the code that has been written so far, and then while we are writing more code to implement the new front end features, we will be referring to the existing code in order to find out how to access or manipulate certain data and objects. Depending on the amount of documentation that exists, it is possible that we may need to come up with our own documentation just to keep track of how everything works. I think that our previous experience programming in typescript during the last semester should be helpful while writing the code for this, although this does seem like it is going to be significantly more in-depth in certain areas.

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