Category Archives: Sprint-1

Sprint Retrospective 1

For the first sprint we did a lot of setup tasks as well as the designing of the architecture. In addition to some of the programming. The first thing we did was talk about the architectural design of the service. Once that was settled a group member created the wireframe for the “register” user interface. A group member also created the wireframe for the “is registered” user interface. The next thing we did was create the blank projects on gitlab. After this we initialized two blank angular apps in the user interface projects. We also created the blank rest server. While this one going on a group member was working the database understanding it and creating one that the architectural design specified. At the same time we created the class the design specified in the rest api and created the endpoints. We also connected the endpoints to a run-time database to test the rest server. In Addition we put in a template to learn how to make scheduled calls in a rest server. At the same time we also started coding the wireframe designs in HTML pages. That basically all we did for the sprint.

For the sprint I personally first created the main documentation issue and kept  it updated. I did this after the meetings or after consulting with the rest of the team and coming to a consensus with them. I also did several of the issues. First I did the issues for creating the 4 projects and initializing them. I also did the issue for designing the endpoints. I also did the issue for creating the object classes for the rest server. In addition i did the issues for creating the endpoints and finishing the rest server with a fakes database implementation. The last issue I did was researching how to make a scheduled method call in a rest server.

For the sprint I personally first created the main documentation issue and kept  it updated. I did this after the meetings or after consulting with the rest of the team and coming to a consensus with them. I also did several of the issues. First I did the issues for creating the 4 projects and initializing them. I also did the issue for designing the endpoints. I also did the issue for creating the object classes for the rest server. In addition i did the issues for creating the endpoints and finishing the rest server with a fakes database implementation. The last issue I did was researching how to make a scheduled method call in a rest server.

I thought the sprint went mostly well. I thought we did using the issue to break the work of the project up into smaller pieces for us to do. I also thought we did a good job of assigning issues to different people to make sure everyone had something to do. Lastly, I thought the documation issue worked well to keep the whole team on the same page as far as what the current plan was.

    Even though the sprint went well there were still some things we needed to improve on. I feel like there should have been more time spent planning before we started. Since a lot of  the first half of the sprint was spent changing our mind on the design and having to start over and this was inefficient. In addition before the working documentation issue was made we were not really telling each other what the plan was or when we changed it. We also could have had better communication overall especially at the start. We got much better later on though.

There are a few we could do better for the next sprint. I don’t think there is much however as we fixed most of the problems by the end of this sprint. The most important thing is to have a better planning meeting. We could be more communicative with each other on what we are doing. Lastly i guess the communication we do have could be better quality and more informative.

I could do a better job individually too. For the next sprint I need to do a better job of explaining why I am making the decisions i am making. I could also do a better job keeping the team updated on what I am doing and my progress. Lastly I could do a better job with the overall documentation of my issues. That being said, I don’t think me or anyone else in the team really needs to be better individually to much.  I think the biggest problem was the poor planning meeting at the beginning.

GITLAB LINKS:

  1. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest
    1. This is the whole project.
  2. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/register-guest-service
    1. This is the rest server project i was working on.
  3. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/-/boards
    1. This is the issue board for all our issues.
  4. https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/registerguest/Plan/issues/16
    1. This is the working documentation issue that has the current plan for the project.

From the blog CS@Worcester – Tim's WebSite by therbsty 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/9

Here I am finding out about docker, posted resources to videos for the team.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/Docker-Documentation

Created a document that highlighted the key commands that would be used for docker containers and images.

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

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

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

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

These are the endpoints that I reviewed and moved to done.

From the very beginning of the spring we had assigned everyone an issue of what they needed to start on. From there each respective person worked individually on their assigned task until moving onto the next one. This was working well for our team in the beginning and for me, because I had a higher weight task, because everyone had something to work on. However, once I thought I was done researching docker and creating the wiki for the docker commands, I had run short of things to do with docker. My main task was familiarizing myself with docker but since we were not going to be using docker until at least the next sprint, there was little to do with everything I had just learned.

Another tough issue was the actual design of our endpoints. Our teams had not yet gotten the documentation of what would be stored for information on each person. For our initial design we made simple variables that could be replaced once the correct information was present. Eventually we were able to change into the correct variables with proper documentation.

Our team was very good at coordinating with the others when it came to work on our endpoints. We had originally designed them each with base variables as described before. After the documentation was given, the main problem that arose was the communication between other teams. We needed to understand what we were pulling from other teams and what they would be pulling from us. Our team did well to communicate and document the interaction and solutions on GitLab.

I think something that our team could do better in the division of tasks. For next sprint, as mentioned in class, we will be waiting to assign the next task once someone has completed theirs. I believe this will allow for a smoother distribution of work. Another team improvement, we could have better documentation when working through GitLab. When different people were working on different task, it was easy for the work completed to be missed. It can also cause a lack of understanding through the team if there is not much to go off of.

An improvement I could make would to be to take on a greater responsibility. I need to communicate to my teammates that I need to take on more work than previously because I felt a lot of time was wasted. I have to be better at involving myself in the ongoing process of something new in order to immerse myself, even if it is just to help push someone to the end of their goal. Another change I will make going into the next spring will be better documentation. I posted a document in the wiki for reference, but should be in markdown on the page for everyone to see easily.

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

Sprint 1 Retrospective: Trial by Fire

Last week our team concluded our first sprint working on the Approve Guest module for the LibreFoodPantry project. This project is part of my Software Development Capstone and has us working on an open source project using Agile principles and the Scrum framework for software development. While I think the project has been going well, there are definitely aspects of our workflow that can be refactored in order to increase our productivity.

What I Completed This Sprint:


For this sprint I took the role of Scrum Master for my team of four. I felt like this would be a great way to put my knowledge of the Scrum framework into practice. While I tried to make sure I was available to the team to answer any questions about Scrum, I feel like I didn’t emphasize the importance of following the scrum framework as well as I could have. I facilitated the stand-ups at the beginning of each class period as well as planning and review meetings. Our team did a good job of explaining what they had done prior to the stand-up and what they were going to work on, but the stand-ups were never used to raise questions about logistics or talk about progress towards meeting our Sprint goal. I feel this is because much of the Sprint was used for getting adjusted to the slightly more structured workflow that we are working with. If I continue to be Scrum Master for our team I will make sure that we utilize class time to the fullest in order to have open discussion about what we need to complete and how we can deliver working software as fast as possible while doing only the minimal amount of work necessary.

I think its important that, as a group, we start to utilize GitLab and our issue board to a greater extant than we did this Sprint. In the beginning of the Sprint we were having trouble coming up with what issues to work on because we didn’t have much information about exactly what it was we are building. I feel like not only our team, but all teams were very concerned with granular aspects of the project such as, what attributes should we be storing in our databases and what style guidelines should our applications use. All of the information that was up in the air was making it difficult for us to feel like we can start developing since everything is subject to change, but it is important for us to remember the Agile principle, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage”. We should be building this expecting requirements to change, rather than feeling the need to wait until requirements are finalized to start working. Also, I feel like even though our communication with each other and the other teams improved greatly from the start of the Sprint, we should be communicating as much as possible in order to maximize our productivity. We had good discussion with other teams but left minimal evidence of this on GitLab, which is something that we will need to be more vigilant about in the future.

We were able to finish all issues in the Sprint before the end, which is a sign that we gave ourselves too little to work on. I think as a team we made an acceptable amount of progress this Sprint as it was our first ever sprint working as a team. Going forward we can more accurately gauge how long each issue will take us to complete and make sure each member of the team delivers a reasonable amount of work by the end of the Sprint. Reflecting on what I delivered this Sprint I know for a fact that next Sprint I will need to give myself more issues to work on. I wanted to start working on our actual web applications, but the fact that our requirements were vague made me decide maybe we could leave that for the next sprint. I think my own fear of the unknown had me making many spike issues, when we could have made greater progress on the application itself.

“Working software is the primary measure of progress.”

 

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

Sprint 1 Retrospective

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

Tasks:                                                                                                                                                                

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

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

What didn’t work well?

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

What changes could be made to improve as a team?

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

What changes could be made to improve as an individual?

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

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

Retrospective: Sprint-1

Links below for my work on Sprint 1 of the LibreFoodPantry project.
MongoDB spike:
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/11
The goal of this task was to preview MongoDb and determine whether or not it will be useful for the project.

Production DB:
https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/checkout/Plan/issues/8
The goal of this task was to create a working Database to match our schema and work with our Rest API.

My favorite part of the scrum framework was actually the integration of kanban. The mixture of the two frameworks really made the work environment productive, predictable, and understandable. My team members and I assigned roles respectively to the scrum framework guidelines, at least two members of the team would know how something is done so that only one member would not have sole knowledge of the task. This way it made it easy to spread the knowledge throughout the team without holding up productivity. If one team member was busy then often the other would be available, or would be in the near future. This team plan also made development quicker in a way that if you were stuck on a task, your fellow task member may have another way of figuring out the issue. Together you can overcome obstacles easier than on your own. A great example of this is when I was developing a Production Database that could be used with our Rest API. I was having trouble figuring out the java code for MongoDb queries. Setting up the connection wasn’t the main goal of the task but it was necessary to have an understanding of it to be sure that MongoDb was the database application we would use. The issue was querying dates and one team member and myself were using CalenderDate which worked, but it ended up being eight lines of code to set up. My other team member on the task figured out LocalDate can achieve the same success with only two lines of code. If I had been left to the task myself the code would be less clean and bulkier, but thanks to my team members different approach we have clean and concise code.

The only things that didn’t work so well was our activity on planning and taking notes on Gitlab. We did not plan in the best way that we could have for the sprint and were constantly editing our backlog and to do lists. We also scarcely posted notes and updates on Gitlab. We did complete our task frameworks in order to move them into the done board. However, we did not thoroughly record our progress on Gitlab. In this way it could be hard for a newcomer to understand the evolution of our issues and how we solved them. They would only see the beginning and end product which is not clear and understandable.

To improve as a team we need to break down our planning technique and make sure our issues are concise and weighted correctly. I think our only problem with this was that we planned last minute because we were unclear of what was expected. However, now that we know we should be able to plan better and make sure our to-do list is concise.

To improve as an individual I need to record my progress, mistakes and achievements on Gitlab more often. Frequent updates on Gitlab would allow a newcomer to see my process and avoid failures that I may have already attempted so that they don’t waste time on something that already is proven to not work. Perhaps they actually solve a failure that I had attempted but was not able to make functional. Without notes to address these topics then a newcomer would not be able to interact and understand our work.

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

Capstone Sprint 1 Retrospective

With our first sprint under our belts, our team is excited to dive into more advanced features. A majority of this sprint was spent learning some new technology, getting our heads around the project’s documentation and workflow, as well as learning to work as a team. However, we also made some strides in implementing our final product.

My contributions

Discussion about whether an issue was a duplicate or if it was a typo, and subsequent editing of the issue.

Commenting with documentation for date format for future reference, which occurred during an in-person discussion.

Request to take care of an issue that was already assigned, in an attempt to complete the tasks at the top of the board first.

Opening an issue that was discovered while committing with a new .gitignore file.

Reviewing and marking an issue to find approved colors and logos as done after completion.

Implementing a stub and merging after approval.

Discussing issues during approval of another feature and merging manually.

Retrospective

As a team and individuals, we are all excited about this project. We all bring our own interests, skills and knowledge, which come with our own quirks and blind spots. This occurs on any team, but it is nice to acknowledge this in ourselves and in our teammates so that we can become more willing to spot them in each other. This allows us to delegate work that we need, ask for help when we need it, and call each other out when we are going down a rabbit hole that is a dead end. I may be the worst offender in this, because I would sometimes slow myself down getting caught up in unnecessary details. I wouldn’t resent my team for telling me I’m worrying too much. I personally feel I could also be better at describing what I’m worrying about.

This experience during this sprint opened up a possibility for improvement for our next sprint planning: more detailed descriptions of “done”. Being new to the format, we tried to shoehorn our issues into a standard template that we were provided. Using only the “given, when, then” Gherkin format, we didn’t get a chance to fully express what we wanted done. Elaborating more in the initial issue will help our focus and prevent worrying about adjacent, unrelated issues, solely due to thinking about each problem in more detail. For example, our stubs didn’t include any testing as part of the definition of done, but luckily we felt that this was reasonable and included them, rather than creating a new issue. I am of the opinion that for software to be complete, some testing should be associated with it. We will create a nightmare down the line if we aren’t careful with this, and should be more clear when defining our issues.

Much of our work was also done as a team, together in the same room. This forced us to remember to document our discussions and decisions in GitLab after the fact. We could have been more diligent in this regard. Although many of the solutions seemed obvious to us, documentation on our reasoning could be important for future developers. I enjoy working in person with a team because it facilitates quick discussion, but I feel we should either discuss more over GitLab or hold each other accountable for documentation after a decision is made as a team.

We are all feeling pressure to finish something we are proud of by the end of the semester. I think this contributed to some of the worrying and long discussions we had on features.

Making matters worse, was that other teams were likely having the same issues we were in adjusting to the new project. I think we handled this rather well and had some good back-and-forth about API design and the features we were planning on finishing. Again, this could have been better documented on GitLab for future reference. Some of this occurred in Discord, and will be lost in a sea of other messages. The less-obvious decisions were luckily documented in GitLab, such as the design of the ApproveGuest Module API. I would have liked to see more back-and-forth between our two groups in the discussion, instead of an abrupt approval of the feature.

This was a short sprint with an emphasis on learning, so thankfully we will be able to improve on these issues and focus on our strengths in the next longer sprint, which should get us close to a working product.

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.

AMPATH-WSU Sprint 1 Retrospective

Hello my readers. So as I mentioned in the very first blog for this semester, all the blog posts will be related to that class. This is a Capstone class and we are working in groups in a project that I am really looking forward to give my contribution.

But what is AMPATH? AMPATH stands for Academic Model Providing Access to Healthcare and is a healthcare partnership based in Kenya and created from different organizations. As far as I understood from my professor, there are multiple universities working on the AMPATH project. What we will be doing this semester is to help developers in Kenya as they are rebuilding the system. Excitingggg!!

Before the second sprint kicks in, here I am thinking about how did this last sprint go. Overall good I would say! My biggest disadvantage was that I had to be away for a week from the country and I kinda missed a few meetings but was able to recover in time without missing much information.

Starting working with AMPATH felt to me just like starting a new job. During sprint one we mostly got familiar with tools, the program we were going to use, our teammates, the systems we were going to use. We were assigned to different teams based on our availability. Fortunately I knew half of my team as I had worked with them in the past in other projects and was looking forward to work with the other developers as well.

In all this new process, I would like to point out one of the systems that i really liked and had not used before: Trello. It was very convenient to have all the stages of the First Sprint lined up in front of you (Product Backlog, Sprint Backlog, In Progress an Done). We started to organize our work and what needed to be done to increase our productivity.

Another step we took was pulling, cloning and getting familiar with the code of the project we were going to use. As a new MAC users (pointing this as I don’t know Mac too much) I had a few issues with running the code in my computer. Kristi though, was able to help me figure out the issue and solve it. .

Unfortunately our semester is a bit short for us to have big development getting done. However I am very excited for the new learning that I am and will be getting out of this project. I choose this project because I thought this way I could assist in an application that was real and had a good purpose.

I would consider this sprint as a research sprint where we researched and tried to learn ans study a lot about Karma ( a test runner for JavaScript), and JavaScript itself. Personally I hadn’t worked with it a lot and needed a few more blogs/chapters to read about it. I am really looking forward to the next sprints and to see what we will be achieving. I didn’t lie when I said it felt like starting a new job :).

 

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

The IncreEdibles Sprint 1 Retrospective

For our project Software Development Capstone course, we got assign to working on food pantry. After we got to know our group members, we started to research about food pantry. We looked at how the data stored, what kind of software there are and what steps we need to take. At first, we meet our first problem, our project still in the early stage we didn’t know what customer are looking for. We took one by one step to set up our operation. We set up slack for our communication, we also have channel to communicate to other schools and food pantry owner. For planning and assign job to team members, we use Trello. We set up different stage of development “Product Backlog”, “Sprint Backlog”, “To Do”, “Doing”, “Review” and “Done”. We agreed on this setup is best for our operation, this way we know how doing what job and what been done and coming up. Next, we looked at what software and technique that require for this task. We know that we are using JSON file from USDA’s website as data base. We need to set up API able to read and get the information we need from JSON file. In order to get specific information as customer want such as what type of food, their expiration date and create report. We agreed using java for this project. Since most of us comfortable with it. That is most of back-end data that we are working with. ( https://catalog.data.gov/dataset/fsis-foodkeeper-data )

We need to host API where can be access online, there are a few options with paid and free. We chose Heroku since it is free, and we feel comfortable with it. To setup Heroku we need an account and set up app on our computer. They have good information on their Documentation Page. ( https://devcenter.heroku.com/ ) We are planning to set up mock-up test for JSON parsing and front end, where we can test and see how our project work. We figure since we still at early stage, we don’t know how other set up their front end. We can set up our own and make sure it would work.

Although at the beginning we didn’t know where we supposed to do, we weren’t used to project in early stage. I feel much better now that we got more ideas about what to do. This has been interesting, we learned about how the team set up in software development. We have good members that take on the job, I am still learning and trying to help. It is excited and fun to figure it out, next at the food pantry meeting with customers. We will have better idea of what they are looking for.

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

Sprint 1 Blog Post

For this week, I have finished up Sprint 1 and I would glad to be talking about it.

What I wish I could done throughout this sprint was to know what was figuring out my laptop

 

 

 

 

 

 

 

 

Link:

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Sprint-1 Retrospective Blog Posts

Hello everyone and welcome to the first sprint retrospective blog posts. Today I’m going to go over what had happened during the first sprint. During the first sprint, we first got familiar with each other because we just had form groups. We then decided on a team name which was 3m2g which stands for 3 mud kips and 2 goats. This team name was combined with two of the most voted names that were considered. We made a list of what had to be done in the product backlog and discussed with each other on what can be done in a certain amount of time. Here were the objectives that we had to complete. First, as a team developing software for AMPATH, we need a GitHub group so we can fork the AMPATH/ng2-amrs repository. Second, as a developer working on AMPATH/ng2-amrs, I need to clone ng2-amrs to my computer (every team member). Third, as a developer working on ng2-amrs, I need to set up my development environment so I can build/run ng2-amrs. Fourth, as a developer working on ng2-amrs, I need to learn about testing in Angular so I can write tests for our new code. When setting up the environment, it was easy because most of the needed software so already installed from the previous CS course. I had the following software and applications was already installed like Insomnia, Gradle, and some sort of Typescript IDE which I had Visual Studio Code installed. Some of the members of my group didn’t have some the development environment installed so the members that finished help provide information when needed. We also had to learn more about these testing tools which are karma and protractor. During the process, the of cloning the AMPATH/ng2-amrs project, Me and my fellow’s group members didn’t come across an issue. The only problem we had to was attempting to run the project which was unsuccessful. I then decided to follow one of the apprentice patterns which had to advise me to ask the help when needed. So, I call my friend Khoa which I and he went over the error and then figure out the solution. I then posted the solution into slack and notify my group of my fix. I learn more about understand certain errors and how to fix them on the day. Some of the software and application that I had installed on my previous class work fine but just need to be updated. When working on the first sprint I became more familiar with SCRUM and really understanding the importance of it. Also, when looking for information about testing in angular I came across many informative sites when inputting angular test on google. I missed the last day of the sprint, but the members of my team were very helpful in informing me of the information that I missed during that day. All in all, this first sprint was simply because the product backlog was a familiar assignment that was accomplished before and I enjoy working with the members of my group.

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