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.