Category Archives: Sprint1

Sprint 1 Retrospective Blog

Being the first sprint of the Capstone class, there was a lot for me to learn working as a team and also as an individual.

As a team, we all worked very well together in all stages of the sprint. There was good communication which helped us coordinate meeting times both online and in-person. Evidence of our synergy would be through the fact that we were able to meet our estimated 20 weight completion by the end of the sprint. I would attribute the large success of our sprint to our commitment to meeting at least once in person every week throughout the duration of Sprint 1. This allowed us to really work together as team to figure out the issues and workflow, which was brand new to us all.

However, it was not all sunshine and daisies. The team made multiple mistake along the way which had slowed us down on occasion. Two big problems for all of us was navigating GitLab and getting used to the workflow. Aside from getting lost and figuring out the UI, we were unsure at first how to post our issues and how to create branches for our changes. It was also confusing how and when to approve merge requests. We had waited for all our issues to be completed before doing the review, which created merging conflicts and caused certain pipelines that were dependent on the other issues to fail.

For the next sprint, we plan to have a “Workflow tips” shared document that includes all our mistakes from Sprint 1 and their solutions so that we do not make the same mistake again. For example, instead of waiting to review everything at the end, the team will review issues as they are completed. We also know to create merge requests directly from the issue, and to edit the merge request properly so that it meets all workflow requirements.

As for me, an individual member of the team, I acted as SCRUM master and worked to communicate with the professor for the team during meetings, preparing notes and organizing the thoughts of the team. However, I had failed in some parts to organize tasks for myself, missing one stand-up post due to negligence. Now that I have a better understanding of how the workflow and meeting dates work, I will be more prepared in the next sprint.

Activity links:

GitPod Dev Environments: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/issues/23
Description: Moved Settings and Extensions from VSCode to GitPod Dev Environments.

Add AlexJS Linter: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/issues/6
Description: Added AlexJS Linter to pipeline check.

Move `commands` to `bin`: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/documentation/-/issues/5
Description: Changed command folders to bin to avoid naming convention conflicts.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint #1 Retrospective

Regardless of this being our first sprint I believe we were successful at laying out the groundwork and finding each other’s rhythm and perspective. I do think that our team could mature from the information we generated while working on processing what we needed to do. It was interesting to work with gathering the information we needed and not jump into the work itself. At times I as well as others started on tasks that were not planned or even required out of eagerness to see concrete completion. I am a big fan of lists and found it refreshing that the solution to an organized workflow was just to stick with it. Software development is most definitely not work for the anxious and it offers some lively wrestling with the meaning of the word done.

Issues I was Assigned to:

Building a container, was an issue that I assigned myself to because I thought that I could use the experience I had researching it for software architecture as well as other tasks that were closely related. I used the docker files from previous projects of similar scopes to produce development environments suitable to each of the tasks we needed them for.

Contact the I AM team to determine security key format, in this issue we had to gather information on a fellow team’s project. After communicating with them we reiterated what we thought would be the case. Their project required acquiring knowledge on a technology they had no previous experience with, so we thought it would be best to wait until their second sprint when our fellow team would mature the use of this new technology so they could give us an educated use guideline.     

List dev environment tools, this issue was a collaboration by all. It required us to think about certain tools that we like working with and decide whether to set them as default tools to the docker containers in all projects. I personally think this issue was important to have us feel each other’s work antics and to have a hands-on direct collaborative first encounter and produce a list that we were all invited to read, change, discuss and concretize its idea by cross-referencing this issue with the building a container issue.

Clone the API project we constructed last semester into the new API repository, this issue required us to search on previous work and define the scaffold by which we would build our design. APIs are something new to me and I believe to most members of the team, but I think this can also be an advantage because it hasn’t been that long since we looked at it. The sample API is for reference only and should be removed as the actual API is written.

Determine .yaml files for methods; break down into smaller issues, this issue started with a different name and is a good example on how we evolved as work started getting under way. Some of the issues we had with naming issues was that we did not have matured the idea of the project’s purpose enough to be more succinct in setting our actions. Some issues had very broad names which the lack of description rendered their completion troublesome. We decided that a study should be done to break this issue into tasks with a set definition of done. I believe this issue helped us forecasting work for the coming sprint and gave us enough space to now have a much less crowded sprint planning. Another thing I think would have helped would have been having backlog refinement meetings to come up with new issues or being less abstract about the issues we already have.  

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

Sprint 1 Retrospective

As we just completed our first sprint, my overall thought is that we did very well, and we have learned from our mistakes. One of the things we did well was that we spit up the work evenly. Everybody had an issue they were working on at all times. And as a group, we agreed that we each did a fair amount of the workload. Another thing that went well is that we completed all of the issues we set out to, from the beginning. Another thing that went well was the merging workflow. With the exception of the first week of development, we were able to complete issues, and merge to main with minimal merge conflicts. How we were able to do this, was making sure we had the most current version of main, before commiting, and making sure to stay within the scope of the issue while coding. Overall I am pleased with our performace, but there are some things that did not go as well, and could be improved upon.

One thing that did not go as well was our communication in GitLab. We were mostly discussing our issue in person. So the discussion within the issue descriptions were not showing the entire story of an issue’s development. We were also relying too heavily on discord, instead of using GitLab comments. On a related note, many of our issues in GitLab were not named clearly. We also had issues that were created in the wrong project. Our naming conventions in general need to be standardized moving forward. We can also improve on only having one person working on an issue at a time. There are a few things we can improve on outside of GitLab communication.

One unrelated thing we can improve on is keeping our stand up meetings to the alloted 15 minutes. I know that this is very important in the real world. We can achieve this by staying on topic, and by not interrupting each other. As a group we have discussed how to improve moving forward. But in order to work effectively, I also need to consider how to improve as an individual.

One thing I can improve upon is staying on task when working on issues. In independent projects, or larger academic projects I did not use issue based Scrum development. So I could jump from one method, class, or subproject to the next, as I realized I would need them. This is not an effective strategy for large, group based development work. During our first week, I had to review a yaml schema, and I decided to validate the yaml, using node modules. I ended up spending an hour doing work that I was not assigned to, and made changes to the branch outside of the issue. This was an important lesson for me, and something I will avoid moving forward.

Issues completed:

Add Standard Files to API repository: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/3

Add Paths for CookingMethods and CookingTips: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/16

Test Class Template for Backend: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/19

The issue that stood out the most to me was creating the Test Class template for the Backend. It was really interesting to learn about Unit testing in node. We are using J Unit in CS443. So it helped me solidify that knowledge to see unit tests written in a different programming language.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Sprint Review I

As we started the capstone class, we got the teams set up and started to prepare ourselves to participate in the project. Each team got assigned to one of the two projects, and I and my team are going to work in the AmPath EMR project. The professor, who is going to play the Product … Continue reading Sprint Review I →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Sprint Review Blog #1

Hello and welcome back to benderson’s blog! This week I will discuss all the events that occurred through my teams first sprint in our Software Capstone. Our sprint started on February 7th and ends today February 19th. Since it is our first sprint, we were just working out the kinks and getting the basic things done for our food pantry project that we are working on for our school. This week we tried setting up basic slack channels, a trello board and a github group so our group could work together and get tasks done fast and efficiently. There are five members in my group all together and we all are going to give our best to this project. Besides the basics we weren’t able to really do anything this sprint since it is very early on and we don’t really have much to work off of. Actually today we got some specifications from the client that they want in the API of the software we are making so we will be able to proceed next sprint on those tasks. Something that we were asked to do that we weren’t able to finish was creating a REST API. We didn’t really know how to approach this, especially since we were notified that the REST API may become obsolete since the client may have something for us to use in the end.

A couple of sources that we used for the first sprint were: https://catalog.data.gov/dataset/fsis-foodkeeper-data      https://github.com/google/gson

The first link is a link to a food pantry type program that helps their users understand how to maximize the freshness and quality of the food items in their pantries. The reason we looked at this particular application was to get some ideas for our own food pantry software that we are going to have to make for the project and figure out what are the bear minimums we would need to have a successful application for the food pantry at school. Later on, after we have all the bear minimums for our food pantry application, we would add more features that are required by the client that we are working with. The second link is to a github project that will lead us to be able to parse a JSON file that we got from the food pantry client, this will allow us to separate the items and make the JSON file more readable and usable for our application.

This sprint provided both some easy tasks and some tasks that required some research and team communication and even though they weren’t all completed, I’m still happy with the progress that my group is making on our project. Getting the REST API and parsing the JSON file is next on the backlog to complete hopefully by the end of next sprint. Next sprint, my team and I will come out like the bulls in the bull run in Spain and try our best to get the next tasks on the next sprint done as fast and with the most quality as possible. Something I think we could approve on for the next sprint is to maybe stay on task a little more when working in class but other than that I think we did the best we could for this sprint. Something I found cool about this sprint and this project as a whole was the stand-ups that we have to do for our groups in slack which is a very interesting way to tell the members of our group how we are doing on the project and what could be impeding our progress. Thank you for joining me this week on benderson’s blog, I’ll see you next time.

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

Sprint 1

Team Retrospective – Sprint 1

 

I think this was a very important sprint because it introduced me to my teammates and it also showed me a little bit of what I can expect from my team during this project. During this sprint, we were to learn about angular tests and how to implement them, clone the project that was to be worked on, run the project and ensure that it built successfully and also make sure we were able to log into the program and kind of get a feel for the program’s UI ( User interface). Most of these tasks were accomplished and throughout the process, I was able to learn a bit more about my team. There were a few that reached out to us when we had issues and others even stepped up sent group messages text messages to ensure we were on track and slack messages when they came up with solutions and answers we didn’t have. Also I made sure to emphasize on creating a good working environment and a relaxed atmosphere for every one to feel comfortable and casual. I accomplished this by starting conversations and asking how everyone was doing whenever we had team meetings. Overall, I think we have a really good group and can get a lot accomplished this year because although there is some room for improvement, we already have pretty good team communication. As for actual work that was done, I think there was a very steep learning curve that had to be covered. I remember in previous classes, we did projects with angular and typescript but the tasks that were completed didn’t go into details as much as this project does. I think one of the issues that stands out the most is all the issues I had with the various angular dependencies. But luckily, one of our teammates was pretty comfortable with angular and was able to offer help when i needed. There were times we contemplated building the project on one system and making sure it was running there, then we were going to clone it into our team’s repository and get everyone to pull from that repository. This we hope was going to eliminate most of the error but we were wrong and after many research, we figured doing it independently on each machine would expose us all to many things that would be helpful to know. It would also add to our already limited angular knowledge.  Overall, it was a good sprint and I think most of what we set out to do was accomplished and I know lot more angular that I did a few weeks ago. Looking forward to the year!

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.