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.

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.

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

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:

https://github.com/npm/npm/issues/17444

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.

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.

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: https://www.atlassian.com/agile/tutorials/how-to-do-scrum-with-jira-software. To learn about Angular testing, I began reading the official Angular testing guide: https://angular.io/guide/testing.

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.

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.

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.

My team’s name for this project is “Everyone Else”. Everyone Else consists of myself (Shane Rookey), Caleb Pruitt, Ben Lagasse, Fuverion Ymeri, and Connor Virzi. The first sprint went pretty smoothly and we learned that we were capable of working through errors and fixing them to get our application running.  We all had issues getting the app running. Most of those issues came from missing dependencies that were supposed to be installed but weren’t (for whatever reason).  After trying “npm install” a couple of times I figured that something happened to get installed wrong because I was getting different errors that no one else was getting.

Specifically, when trying to run npm install  in the ng2-amrs directory i was getting an error that said something along the lines of “Missing package Dezalgo” which was supposed to be installed when I installed all of the dependencies. What I did to fix this problem was erase the entire repository on my computer. I then cloned the repository from GitHub again and installed all of the dependencies AGAIN. Before running npm install, I deleted the package-lock.json file in ng2-amrs directory. Once deleted, I ran npm install and it worked like a charm. After npm install, I was able to run npm start and get the test server up and running.

One other thing I needed to get the test server working was a Google Chrome extension called “Allow-Control-Allow-Origin”. This was required by AMPath to connect to the test server.

You can find instructions for the extension here:

https://www.useloom.com/share/97cab1199df843d4b04b41ec8cbd7582

This entire process so far has been an excellent learning (and refreshing) opportunity. I have been familiar with GitHub before, but I have never been a part of a project that is a REAL thing (if you know what I mean). These people we are working with have a REAL business and we are trying to help people make their programs better. It is truly encouraging and fun. Working remotely with GitHub will be good experience for the working world because almost everyone uses version control of some kind.

I have also never worked with 4 other people at once on a single computer science project where we are all trying to work towards the same goal. Its inspiring to have a team and also motivational because you don’t want to let them down. Two people on my team missed a standup for the first sprint but I don’t hold it against them, It is difficult to remember that you need to do something every single day to reach your goal, even if that is just some planning and communicating. I think my team will truly step up and begin to shine once we delve into the more technical work.

Besides getting the test server up and running, we looked over the user stories to see what we were going to be dealing with. For each one we quickly brainstormed what each story might entail regardless of what task we ended up with. I am excitted to continue on with this process and get planning for the next sprint on Thursday.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.