Category Archives: Sprint-1

Sprint 1 Retrospective

I have just finished the first sprint and there are a lot of things that I’ve learned from this experience so far. Before I talk about the experience I’ve had, I’d like to share my opinions about the task we will be performing down the line. I think that the work that we will be doing for Ampath is both really interesting and pretty important, it’s pretty nice to know that if this functionality can be completed it will be used to make a difference in other people’s lives. That being said, this week I’ve learned a bit about node, and javascript and some of the other components that Ampath uses, most of this knowledge so far on only top level but I am looking forward to diving deeper in the coming weeks. The components weren’t perfectly set up for us, there were a few bugs which members of the team took care of fairly quickly and this reminded me of how valuable teamwork is. If there is a lesson that I will take with me going forward from this week, (and this applies in most professions) is truly how valuable teamwork is.

On the topic of teamwork, my team worked very well together internally but even better still, we worked well as a class. I think that this ability to reach out to other groups will be extremely helpful down the line since we most likely be working on different components/modules.  I thought my participation was fair, but It could’ve been better. Moving forward I will try to spend more time trying to understand the code and most importantly improving my communication with the team. As a team we also are striving to improve our communication with each other.

During this week we mostly spent the entire time setting up. We had to set up all of the accounts that we needed including Jira, Trello, Git, Slack, Catme, etc. The setting up of the accounts was fairly straight forward, then we had to work on setting up the repositories at the class level, team level, and developer level. While setting up the repos we were also setting up our dev environments, this involved installing the NPM (Node Package Manager) and getting the Ampath application installed and successfully built. Successfully building the Ampath app required some extra work due to a bug that was quickly discovered. This bug was caused by a missing reference to a style resource, this bug was quickly fixed by (I believe) Oran Shoemaker and he shared it with the team to unblock the rest of us. The only other sizeable hiccup that we encountered was in connecting with the server, but the ampath team provided us with the instructions on how to do it correctly. During this time we were going through the Trello board and participating in scrum to share with the team our current status.

As a team, we were able to get through almost all of the Trello tasks for this sprint. There were a few that remained, but those tasks were either completed and not marked so or nearly finished. Personally I will make an effort to keep Trello up to date as much as possible. In conclusion, this sprint has done a great job giving me a general idea of what is to come and showed me that we as a team must work well to get it all accomplished.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In this sprint I learned how to set up a development environment for a fairly unfamiliar IDE and language, and I learned how to work with other people to work through issues in building a local copy of the AMPATH app.  I struggled most in the latter with actually understanding the error messages and how to resolve them.  I can take the difficulty I experienced with this process and use as a reminder in the future to more carefully pick through the error messages and try to resolve the conflicts myself.  I was concerned about making changes to files or folders, even though the worst outcome would just be reverting back a version.

I think the team worked pretty well together on this sprint, although it’s a little early to tell.  We were all working on the same thing (environment/app setup) which didn’t offer a lot of room for collaboration other than helping each other resolve problems.  I think that we’ll get a better feel for our team dynamic in this upcoming sprint when we have more “real” work to do.

This sprint was primarily focused on getting the AMPATH app up and running on my local systems.  I started by forking the repository from the group repo, then cloning it to my system.  I then looked through the README and tried to follow the instructions.  I must have done something incorrectly or in the wrong order, because I ran into missing dependencies (which should have been downloaded by npm).  I then tried a variety of solutions to resolve the problems.  I attempted to directly install the dependencies (didn’t work, due to a file/folder creation error).  I deleted and checked out the project again (didn’t work either, same issues as before).  I tried rolling back to older versions of Angular and npm, which was suggested by a couple of StackOverflow pages I found relating to similar errors  (did not work, bricked my Angular install, had to reinstall).  On the second or third try of just installing the dependencies (with a clean Angular install and project version), I managed to resolve the issue  but then ran into a problem with the ladda module — it wasn’t in the right place for Angular to find it.  I was stuck on that until Matt Foley found and posted a solution.

Once I had the solution to the ladda error, I reinstalled Angular again (just to be sure), worked in order through the steps outlined in the README, worked through Matt Foley’s fix, and wrote up the procedure I took as I went so that other people in my group and in the class could use it.

The prodecure boiled down to the following:

Run npm install, then install global dependencies, then npm install again to catch anything that might have been missed.  Create copies of one of the ladda files in the directory Angular wanted to look for it in, and modify one of the ladda files to point to the proper directory.

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

Sprint 1 Retrospective: Getting up and Running

We’ve just completed our first sprint in the Software Development Capstone course. I will be posting similar blogs biweekly for the next few months. The purpose is to periodically check in and reflect upon the overall progress of our team.

Many of us, such as myself, learned for the first time what a sprint refers to in the context of software development. The whole concept of “sprints” and scrum is brand new to me. In very simple terms, scrum is a framework where teams produce material in small “bursts” (i.e. sprints) where the intention is to increase overall productivity. I must say that I am enjoying the team based environment, especially because it seems to closely emulate what we should expect when we graduate and transition to our soon-to-be careers.

This first sprint was designed to help us become more familiar with working in development teams, setting up our environment for future sprints, and the whole concept of sprints in general. We are working with AMPATH this semester, contributing to a healthcare consortium software project that is primarily used in the Kenya area. We hope to provide the AMPATH application with feasible offline accessibility, where data can be submitted online once an internet connection is reestablished. Offline access would be a great asset to those using the software, as Kenya internet access is reportedly unreliable at best.

It is our team’s personal goal to contribute as much as possible, assisting our class in accomplishing everything the AMPATH team expects from us. So we spent this sprint getting everything up and running that will be required of us to contribute to the AMPATH project:

  • Slack – Our team has been (and will continue to be) using this platform for communication among ourselves and other teams. Personally I think Slack has certainly contributed to our team’s productivity. While our in-person collaboration is great, I feel it is equally important to have a means of communicating asynchronously; Slack provides this capability for us. We also use Slack to complete our stand-ups, which help periodically determine what each of us currently working on.
  • Trello – We are currently using Trello as a scrum board to manage tasks during each sprint. We’ve spent this first sprint becoming familiar with Trello, such as how to create and assign one or more of us to a “task card.”  For this sprint, we’ve typically either told each other personally or via slack if we completed a Trello card. I feel managing tasks could have been easier if we used Trello more productively; this is something we should work on in future sprints.
  • JIRA – This is a project management web app (similar to Trello) that the AMPATH development team uses. We’ve spent some time reading tutorials regarding the JIRA framework, because we will likely be using this soon.
  • Angular, etc – It was imperative to ensure we all had the required Angular stuff up and running. We’ve also read tutorials to familiarize ourselves with the framework, and how tests work for it. The AMPATH app is written in angular, so in turn we needed the node package manager installed in order to run the angular framework. For more experienced users looking for flexibility, I would recommend Node installation via the Node Version Manager (nvm) app. This is a great tool that allows the on-the-fly switching to different versions of node, something that is much less feasible with the proprietary version from the node.js website.
  • WebStorm – This IDE provides the TypeScript and Angular support we need when working on the AMPATH project. I recommend this to anyone who is a student looking for a good Angular/TypeScript IDE (it’s free for students, otherwise the price is a bit too pricey in my opinion).
  • GitHub – We ensured all of us as a team had GitHub accounts because this is the version control system that AMPATH uses. We then created and forked the project repository to our personal team’s organization. From here we all helped each other successfully clone and install the application to our personal computers.

I feel we collaborated well as a team; overall I would say we’ve had a successful first sprint. My only concern is that we had to change some code in the module files to get the application to run properly. We are not sure if this is a problem in our end, or an issue that AMPATH is experiencing as well. We are in the process of communicating with the AMPATH development team to figure out the best resolution.

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

Post #19 – Ampath Application Development – Sprint 1 Retrospective

Our first sprint was an introductory one where our team officially organized on GitHub and Slack, created local working copies of Ampath’s application, and began looking at Angular resources.

Our team worked well throughout this sprint, despite not having all members present for 1/2 of our in-person meetings.  The required tasks included in this sprint’s back-log were fairly easy to complete, but I did run in to some trouble during the installation of the application’s dependencies.   I was absent for the first meeting following our sprint-planning-meeting, but all of my teammates were extremely helpful in getting my application compiled and running at the following meeting; they each gave me a different piece of advice and the combination of those pieces of advice was instrumental in the completion of this task.  I also received some help from Shane R. who is on one of the other development teams.

We began the sprint by organizing on GitHub so that we could create a working copy of Ampath’s application that would be at our team’s disposal, that we could then clone into local working copies on our individual machines.  We then organized on Slack so that we had a direct means of communication between the members of our team and with our professor.  Finally, we organized on Trello so that we could set up product and sprint back-logs to keep track of what has been and needs to be done.

The next task we had to complete for the sprint was to install the application and its dependencies on each of our machines.  Everybody had a little trouble at first but my troubles persisted right up until the last day of the sprint.  After quite a bit of trial and error, I realized a couple mistakes I was making in the installation process.  Apparently, the package-lock.json file in the application’s main directory was having some effect on the success of its compilation, so I had to delete it.  The second mistake I made, was that I was doing all of the installation in Git Bash instead of WebStorm’s built-in terminal.  I had attempted installing the application’s dependencies using Git Bash for the first 4 or 5 attempts and got the same compilation error at the end of each attempt.  Finally, by using WebCharm’s built-in terminal to install the application’s dependencies, I was able to successfully compile the application and run it, thus completing all the tasks required of me on the sprint back-log.

My installation process summed up:
Clone application to PC
Delete the package-lock.json file
Open application in WebCharm
Using WebCharm’s terminal, follow directions to install dependencies and update software (found in README file)
Get Google Chrome extension for ability to log into the app (also mentioned in README file)

So, it was a fairly simple and straight-forward sprint, this time.  I think the main piece of knowledge that I took away was, kind of, how developers are able to contribute to open-source applications using GitHub and, overall, how a development team organizes to contribute to such a project of this size and magnitude.  I can now apply this knowledge if I am ever offered an opportunity to work on an open-source application that I am interested in, or if I ever want to form a development team that utilizes an Agile/DevOps style of development.

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

Looking Back on Sprint 1

The first sprint contained a lot of small tasks for setting up the environment and getting familiar with the ng2-amrs system. While some of these tasks were simple, others that originally seemed simple became difficult and took more time than the team and I originally expected. Overall, I feel that the team worked well together and that we were able to complete the bulk of the story items for this sprint. There were a few areas where I think we could improve for the next sprint, and these topics were discussed during our retrospective meeting in class.

One of the first tasks that was completed for the sprint was to Create a GitHub organization for your team. Dominique assigned herself to this task, and created the organization. She invited all of the other team members to the organization during a class work day and ensured that we were all able to access the organization.

Another task that was completed quickly due to its relative simplicity was the Choose a label color for your team. Matt assigned himself to this task and changed the label color on the appropriate card on the Class Scrum Board.

I assigned myself to the Fork ‘ng2-amrs’ from CS-Worcester-CS-448-SP-2018 to your organization task. I was able to complete this task only because Dominique had already created an organization for our team and gave me the necessary permissions.

The Read README.md and Read CONTRIBUTING.md tasks were relatively simple, and all members of the team completed these tasks early in the sprint.

The Decide how you want to manage your team’s GitHub repository was completed as a class rather than as a team, so little effort was required on the part of our team.

Everyone on the team was able to complete the Clone ng2-amrs to your computer task, as Dominique gave all of the members of the team access to the organization’s fork of the project.

Some of the tasks that gave the team a little more difficulty were the Learn how tests work for Angular, Build ng2-amrs on your computer, and Connect your ng2-amrs to the server. While the team members that had the project built and connected to the server attempted to help other team members get up and running, there were a few different and unique problems that gave people trouble in building and connecting ng2-amrs to the server.

Matt was able to fix one of the most severe of these problems, namely that of the ladda module complaining about missing files. Matt shared his solution with the team and the rest of the class, and was able to help many people in successfully building the project.

We were initially waiting on the Ampath Informatics team to provide us with a link to a server that we could connect to. When this link was provided midway through the sprint, we chose to add the task to our sprint backlog as some members of the team were ready to accept more tasks. For this reason, it was not a concern that the entire team was unable to complete this task.

The final task that was not completed by everyone in the team was to learn about tests in Angular. Once again, this task was not of critical concern because we likely won’t be using testing heavily early on in the development process.

I think that the team worked well together, and that members supported one another throughout the sprint. One thing that we may be able to improve upon is communicating when we are having difficulty so that others are able to offer assistance. Or, on the flip side, asking and offering assistance when another member of the team seems to be struggling. I am looking forward to working with my team and getting into some of the more technical parts of the Ampath project.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

CS448 Sprint 1 Retrospective

Overall, I felt that this sprint went pretty well. Being the first sprint, I understood that there was going to be a bit of a learning curve and I felt that the team took to the Agile process well. One of the best decisions we have made so far was to create our own task board for our team. By doing so, it made it much easier to keep track of what was done and what needed to be done. For the tasks that each team member had to do, we put a checklist with our names so it was easy to keep track of who still had work to do. The team did a good job for the most part keeping the board up to date. It is important to keep track of what has been done to prevent duplicate work from being done so I was happy that the board was updated regularly. Overall, I felt that our team communication could have been better and would have allow us to resolve some team member’s problems faster, but better communication is something I think will come in time. The team should discuss as a group what the standard for communication should be so we are all on the same page.

I feel that the biggest accomplishment this week was getting the ng2-amrs compiled and connected to the server. I know several teammates were able to do this and hopefully we will be able to get the others running shortly. The challenge behind getting ng2-amrs was it would not build in it’s “out of the box” state. The issue had to do with the ladda module, which was responsible for some of the styling I believe. It was looking for files in the wrong location and some directory paths in the files were formatted incorrectly. It was a bit of a process, but I was able to resolve these issues and get it to build. The solution to this issue can be found on the CS448 Slack page. Oren took my original instructions and improved upon them (so his instructions are the one’s you’ll want to use), which can also be found on the same Slack page.

Although getting ng2-amrs was the biggest accomplishment of the week, a lot of other things got done as well. Everyone on the team able to get to all of the readings done which were both essential and informative. All of the team tasks (as in the ones that the team had to complete as a unit rather than everyone individually) got done. Everyone was also able to clone ng2-amrs and start building. Those who were unable to get ng2-amrs built and running are well on their way to doing so.

I feel this team works well together and am looking forward to the continued work with this group throughout the semester. It will be nice to actually start digging into the real work next sprint rather than a lot of set-up type tasks we had to do this sprint. Hopefully we will be able to help out the folks at AMPATH in some way, shape, or form.

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.