Category Archives: Sprint-1

Sprint Retrospective 1


For this sprint retrospective there isn’t much to talk about because we were just going over the basics of how we are going to work together and setting up the server for our team to work on. During the sprint meeting we talked about the little things that we would like to change. Such as how we can change how our trello board works such as we put up all of the things we need to do and then put our names on the corresponding things we had done and did. Next, we talked about how we are going to push any of the code that we will be doing ourselves onto the git hub and when we should do it. We all decided to push it whenever we meet at least for now since we are still getting to know how each other works as a team. Finally, we went onto the google doc at the end of the meeting and just talked a reviewed the stories for ng-amrs. Just trying to keep ourselves ahead of the curve and started talking about how we can do this project. Throughout the week I just worked on the assignment leading up to setting up the server and getting to know my team more. Some of the things that did help me out throughout the sprints are the slack board and my teammates. For now I don’t see any issues working  with my team they are all great people and we are testing the waters of how we should be coordinating how we work and what we should do.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – 14 February 2018

Over the past two weeks, I experienced my first sprint with my fellow teammates. Although it was introductory in nature (as were the tasks we actually completed), I feel that it gave me a solid understanding of what to expect in the upcoming months, and in my eventual career.

The first sprint consisted almost entirely of setup tasks; each member of the team installed Webstorm, connected to AMPATH’s test server, familiarized ourselves with JIRA, set up a Trello board, among several other things. The bulk of our communication throughout each of these tasks consisted of troubleshooting, particularly when trying to get the ng-amrs build working properly on our machines. There were a few different fixes we came to, but in general, it seemed that each of us was having the issue of a file not being found. We each worked out with each other how to find that specific file, and the build worked fine once we’d each done so. As a result of the fact that we each found different methods of resolution to this, however, we have also agreed as a group that we should exclude these files (which, thankfully, were only styles) from our commits to the project.

A teammate and I each forgot to submit responses for one of the scheduled standup meetings. Fortunately, the reason for this was that it had been such an insignificant period of time due to the prior completion of tasks, and nothing of value was left out of any report.

In future sprints, I believe that the familiarity that this preliminary sprint provided our team as a whole will serve us well. Having already discussed the user stories provided by AMPATH with the others, I am excited to get to work on this application. For me, and for the other members of the group to my knowledge, this is the first product I’ll be putting into the real world. Although the idea of this being my first work to have real consequence is daunting, I believe that we as a team will be able to deliver not only a satisfactory final product, but one which exceeds expectation. If we can keep up the kind of groove we had going for these two weeks, it might even be a smooth project – imagine that.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

During the first sprint, I learned more about the node modules and dependencies needed for the AMPATH application to load properly, mainly the angular2-ladda module. I learned more about angular and angular testing, including framworks such as Jasmine and Karma. I learned about test debugging right from the browser. I learned how to create a Github organization, a useful tool for any team of developers.

Our team worked well together, I believe we all have the skills needed to take on the task of adding offline functionality for the AMPATH providers. I created the Github organization for our team, and made sure that my team members were on the same page. We organized how the team should manage pull requests and for now will be approving requests when we meet. I think we will have more communication when we actually start writing code and making changes.

The first week, I forked the ng2-amrs repository from the class organization to our team organization. All team members were added so they were able to fork their own copies to work on. From then, my team members and I worked on installing the needed dependencies for the application to compile. From the start everyone had compilation errors because some files were missing or in a different directory. While browsing the Slack channel we discovered that a different team member(Matt) posted a fix to the issue we were all having. The issue was with the angular2-ladda module, the errors showed that we had some missing files. Our team followed the instructions on what changes needed to be made and successfully fixed the errors. Once we had the application compiling properly, we set up our browsers with the help of the AMPATH team’s youtube video showing us how to add the CORS plugin. Once logged in we realized there was no data being shown as the AMPATH team is still working on getting dummy patient data on the test severs.

The post Sprint Retrospective 1 appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

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

First Sprint Retrospective

My first sprint experience was interesting. The experience was more of a sprint-lite, a streamlined version of the process. The tasks we had to accomplish did not have to be split up between team members and there was no real roadblocks that had to be overcome except minor issues which were solved with out too much hair pulling.

This weeks sprint was a learning experience in that it was my first time with sprinting on a software project. It allowed me to get some of the basics down and get used to the experience. Not much would change with the knowledge I have now, other than issues would be fixed sooner. Though they were fixed quite quickly to begin with.

I feel like most of our progress was made during the in class meetings, as we could share a large amount of our findings with each other and have long discussions on them. In the future, I feel as if more discussion should be had remotely, to increase productivity overall. Though this time it did not really matter. Helpful links and tips were still posted to slack. The Trello board was set up quite quickly, and the stand ups were finished by everyone pretty consistently. Barring two very minor misses. Overall, the team worked really well together. Everyone was helpful and made contributions to aid others. I brought up a fix for an issue I will describe in a few moments, and was helped in resolving an error by a fellow team member.

During the week everyone had to setup their teams repositories which had forked versions of the n2-amrs app. They then had to get the application working on their machines. The steps to take were basic, but they did not end up being as simple as they should have. Npm install should have installed all dependencies and npm run should started the application running. However, many people, including me, received errors when trying to install dependencies. The errors mention files that do not exist in the application. I searched the issue and online and was able to come upon a page on git about the specific issue with many suggestions for fixing it. Here’s a link to the page in question:

The method that ended up working for me was to delete package-lock.json, which would be reinstalled along with the other dependencies after running npm install.

Running the application came with an issue in the styles guide file, where it could not find another file called ladda.min.css . There were suggested fixes on the general slack channel, and suggestions made by my team mates. I ultimately fixed it by moving the ladd.min.css file and then rewriting the path in the styles guide file to its new location.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

Software Capstone Sprint #1 Retrospective

During the first sprint of my software development capstone, it mainly consisted of setup tasks which would aid into the upcoming sprints that are later to come. What I’ve learned was how to adapt to the team that I’ve been set up with, using Angular through the webstorm IDE, accessing the AMPATH server, briefly using trello, using git commands, communicating on the Slack channel, managing the Team’s git repository, and experiencing of what it’s like to work in a software development environment. Looking back on how I’ve learned all of these things, what I would’ve done differently is that I would communicate to my teammates a little bit more through the slack channel because there would be times where my teammates would often lose sight on what I was doing. They could only know through the standups that we do every Monday, Wednesday and Friday during the sprints. That would be one of the main areas that I could’ve improved on and would’ve done differently.

Out of these things that I’ve learned through this first sprint, they could all be applied in upcoming situations. Communication will always be an ongoing action to take especially working in a team since everyone needs to be up to date on each others work. Angular will probably be in constant use as well as the Slack channel and possibly trello. Acessing the AMPATH server will probably be a must in all sprints as well because the team and I will be submitting code to the server.

On a scale of one to ten, where ten is the highest, the team’s effectiveness throughout this sprint would be an eight and a half. There were some instances where my team members Rick, Jason, Jeremiah, and myself all had trouble getting access to the AMPATH server. Some of us had to install some dependencies, whereas some of us had to update the webstorm IDE. There was a case where Rick had inputted the wrong command into the terminal in the webstorm IDE to connect to the AMPATH server. At first we thought there could be something wrong with his code, which led to spending an entire class on figuring out what went wrong. That’s when we knew at the end that he had entered the wrong command. After all of the team members had successfully accessed the server’s login menu, it was smooth sailing from there.

As an individual throughout working in this team, I felt I was competent enough to do the work that was assigned to me. Besides going through some trouble with accessing the server, the process of trial and error helped me learn new things, which led me to teach my teammates things that I encountered along the way. Besides delivering quality work, I tried to be the individual within the group that made the atmosphere more enjoyable, especially in group discussions about our current tasks. What we will be doing differently moving forward is that we would organize our tasks a lot better through the concepts of the trello board by organizing and assigning tasks to each individual team member. That way, it allows everyone to keep track on who is doing what.

What was done during the week was we established a connection to the AMPATH server, created a trello board for the team, practiced some angular tutorials, and managed a github repository. As said earlier we tried many things to fix and gain access to the AMPATH server login screen through using different commands, updating webstorm and installing dependencies. We tried the command “npm run server” or “npm start” in the terminal in webstorm, and that worked. The command that failed back in Rick’s situation was “ng serve”. There were also some instances where Jeremiah and I had to uninstall node.js and install it again, which was one of the course of actions we took when nothing else worked.

Overall, the first sprint was a learning experience for myself and the others. Currently, we are trying to figure out a better way to manage our github repository that allows an easier way to do pull requests. My teammates and will come up with something later on.

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

Sprint Retrospective 1

The focus of the first sprint was cloning and building AMPATH’s existing code on our own systems in order to get us in a position to begin adding the desired functionality. Additionally, we set up our team’s Trello scrum board and our team GitHub organization, and we began learning about both Angular testing and the JIRA project tracker. We ran into problems most significantly when we couldn’t build ng2-amrs due to compiler errors, but by the end of the sprint we were all in a position to successfully build it.

I downloaded Visual Studio Code and an add-on for TypeScript to use as my editor for this project, since WebStorm so slowly it’s impossible to use on my laptop. This is the first editor listed in the recommendations in AMPATH’s readme file, and so far it runs smoothly for me.

To start off the sprint, I created our GitHub organization and invited all team members and Professor Wurst. George forked the repository from AMPATH. Everyone cloned the repository, and we began going through the readme file. We installed the required dependencies and began attempting to build ng2-amrs, at which point we began encountering errors. Matt figured out that some references to ladda.min.css and ladda.directive.js were producing the errors and implemented a fix that resolved the errors. He created a list of instructions for fixing the errors and shared it. Members of other teams (Oren and Rick) made corrections to these instructions. I and others on my team made the outlined changes, after which we were able to successfully build ng2-amrs.

After this, we learned about doing scrum on JIRA, and some of us went on to learn how tests work in Angular. Matt and George were able to connect ng2-amrs to the server.

For JIRA, I consulted Atlassian: To learn about Angular testing, I began reading the official Angular testing guide:

Our team worked closely in the beginning, but then began to work more independently when installing the required dependencies took varying amounts of time for all of us. We shared Matt’s fix to the ladda compilation errors and aided each other in implementing the changes as team members became ready. Our team had difficulty showing up in full to the stand-ups. We haven’t yet decided as a team any specifics as to how we will proceed differently, but I hope to get from everybody a reliable way of contacting them so we can increase our team’s communication and so I can provide reminders if that’s something other team members would appreciate. I think our team will do better if we can close the gaps in the progress we’re making as individuals.

As this sprint consisted mostly of set-up tasks, I didn’t learn much that could be applied to future situations apart from the way our team functions. In light of this, I would strive to keep us on the same page and updating each other on our progress.

To do the same work we did, someone could fork and clone ng2-amrs and follow the most recent set of instructions to fix the ladda errors. Better yet, they might be able to proceed without having to fix anything, as the pull request containing the necessary changes was approved and merged into the course repository’s master branch.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective

This sprint session was really an exciting one and it start with individual student taking the CATME survey which enables the professor to place students in the appropriate group based on the students’ availability. Teams of five were formed initially and we named ours the gung of five. One of our team members could not make with us and our team ended up with four members. We again deliberated on changing the name from the Gung of Five and we settled on the Abstract Class. The team decided Rick Phillips should be our leader and since then Rick have been leading the team in all our discussions. Rick created a repository and cloned the class repository to it and the rest of the team members fork our own copy to our repository.

At the beginning, we tasked ourselves to have the environment setup for everyone. As we are all using web storm, I had it install on my laptop from the previous semester and the only thing I was to do hen was just to upload the ng2-amrs cloned to the desktop.  I had so many challenges as I tried to compile to project. Almost everybody in the team faces similar problems. We had errors coming from many difference angles including ladda.min.css file and styles.scss file. With the help of Rick Phillips and Jason, I was able to resolve all the compilation issues. After this stage of our setup task, I was at the login screen where almost all the team members were. Just before our next meeting, I encounter another problem that we spent the entire class time trying to resolve it. Among the step taken to resolve it was to delete the entire work and clone it again from the repository to the desktop.  At some point in trying to fix it, Rick Phillips also had the same problem then we tried to check our step and command because that seems unusual. We checked our step and realized we were using a wrong command for compiling the app; we were using ng serve to start the server instead of npm start.  We figure this out when Rick Phillips faces the same problem. I have learnt a lesson and I don’t think we will repeat that anytime.

Besides the setup task, we also tasked ourselves to do the things in the trello board.  By then we already have our github accounts setup and as directed by the team, I went through the tasks in the trello board one after the other.

One last thing I did was to watch that video posted on ampath slack channel which explains the instructions of connecting to the server built for this project. The steps in the instruction video were pretty much simple and straight forward so I did not have any difficulties in getting connected to the server.

So many things were leant including how we have to go into the app module and change some line to have the app working and how our own negligence causes us a whole meeting trying to figure out how to resolve issues. In the future, I will be paying attention to instructions done just trying to fix problems as they come.


From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective – Getting Started

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

Sprint 1 Retrospective

This was our first sprint as a team and was anything but normal.  I would like to say that I believe that having a sprint where the main objective to set up our personal and team environments was a great starting point.  It allowed everyone on the team to help each other get ready for the project and not feel like we had to rush.  It also gave us to sit together as a team and go through the same steps that we will in future sprints.  There was definitely a lot of experience to gain with very little risk if we did not complete the sprint the correct way.  That’s not to say there was no risk, because if we did not set up our environment or study Angular we will be in trouble next sprint.  We did not start contributing to the project though so it was less stressful than a trial by fire and risk falling behind at the beginning of the project and put the team in a bad mood and kill morale for the rest of the semester.  The other side of this sprint though was that most of the activities were personal and did not contribute to a group whole at the end of the sprint so for times in the middle of the sprint it was hard to be able to talk during the working classes to the rest of the team about our progress and work as a team.  I am fully aware though that that will not be the case moving forward though and even though we will be working individually I think since they will be pieces of a whole it will be easier to collaborate during class and reach out when we run into roadblocks.

This made the rating difficult for the first sprint as well.  It quickly became hard to rate the rest of the team on their contributions to the team during the sprint when there was not much of a team effort needed, with the main exception being if someone needed assistance setting up the environment or asked a specific question on one of the user stories.

I feel like this sprint got our team ready to go though and I look forward to helping improve this application throughout the semester and working with my team.  We are set up in a good place and we have a solid foundation to start working on our portion of this project.  I also like that we will be working on a real world application that we can put on our resume, but also one that is doing good throughout the world and be able to point to it in the future and say “I helped make that better.”  I’ve talked to a few people about it, but I think that as a whole everyone is excited to start working on this application and feel that even though we are on separate teams we are all willing to help other teams.  This really has the feeling of a project that is bigger than us and no one is competing against anyone else the way that some may feel if we were all completing the same assignment or taking tests.  We are all taking on this task together and ready to do it to the best of our ability.

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