Sprint Retrospective Blog – First Sprint

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.

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.

Starting out by Sweeping the Floor

As I will soon be starting out in a new position at an unfamiliar company, I was more than happy to look to Apprenticeship Patterns for help in making the most of my apprenticeship. While the position may not be exactly what Hoover and Oshineye had in mind when they wrote the pattern, I found the Sweep the Floor pattern to be almost universally applicable to any entry-level position. When you are just starting out, you may not feel comfortable taking on some of the more complex tasks. You may be unsure of where you fit in as part of the team, and the team may be unsure of you. The Sweep the Floor pattern offers advice on how to contribute to and earn the team’s trust as well as growing professionally when you are just starting out as an apprentice.

I found the inclusion of the story from Paul Pagal to be comical and also informative. As mentioned, there are certain less glamorous tasks that simply need to get done in order for the team to be able to function. While they may not be glamorous, they provide an opportunity to make yourself useful and appear motivated. This most certainly will not go unnoticed, and should lead to progressively more interesting and complex tasks. As your skill level as well as comfort level increases, you will begin to take on riskier tasks.

Hoover and Oshineye follow the story by saying that having to do less glamorous work to get your foot in the door may be tough to swallow for some apprentices who feel they’ve already paid their dues. While I’m not trying to discount the value that I feel my formal education has, I’m not sure that I agree that this counts as paying your dues. Until you’re part of an actual team facing real-world problems, you haven’t paid your dues. This is part of the reason that I feel completely content starting off with more menial tasks. I am more than happy to begin proving my worth and showing my team that I am ready for bigger challenges by starting off with some of the less glamorous tasks. After all, somebody has to do it.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew 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.

The Abstract Class – Sprint Retrospective #1

The Abstract Class – Sprint Retrospective #1

Our team, named The Abstract Class, reached the end of its first Agile Sprint today and this is my retrospective. This week, I learned about building and running my first Angular application cloned from a shared repository. This was part of a larger group of accounts and applications that had to be processed mentally. There is Trello, Jira, CatME, Slack Channels, and GitHub groups. As a team and individually, we each had to navigate the many new interfaces and learn the intended uses for these new tools. I feel out team effectively grasp and started using the tools as intended.

The most technical feat our entire team accomplished this week was cloning of the AMPATH application and connecting to our test server. We ran into a situation where we attempted to build the application with ng serve and not npm start. This caused errors. Once we realized our mistake, entering the correct command got us up and running.

Our team handled AMPATH application ladda build errors using the class Slack channel. We shared screenshots, log files, and advice when one of us was having trouble. We accomplished getting a teammate up and running strictly through this Slack channel conversation. This provided other class members the ability to view our conversation and avoid the same issues, potentially. We could continue to publicly resolve future issues in hopes that this inclusive feedback will help resolve issues quicker.

Our team worked very well together on this sprint. We used Slack appropriately and resolved issues on that platform efficiently. We could have used Trello more effectively during the sprint, as we were moving the boards around during the end of spring class. Our stand-ups were a little spotty in the beginning but we, as a team, finished strong.  

We created our GitHub team group and began discussion on the best way to manage changes and pull requests. We are unsure of which of the following approaches is best:

  • Create individual branches for each developer on the group’s fork of the Master branch. We would create an additional branch called merge_changes which would act as the buffer between our branch changes and the Master branch. Pull requests would be merged as a group.

  • Create individual forks for the group’s fork of the Master. Then each individual form would create a branch on their fork. Merge requests would still be handled by anyone who did not create the pull request.

We have yet to determine which of these is best. Our next Sprint planning meeting will have to include discussion on this point.

We also discussed the best way to handle our group’s Trello board. During this spring, most of the tasks were required to be done by each member. This caused some confusion on the boards. We were not sure of the best method to have some of us done a particular task while other were not. There were some suggestions about checkboxes, multiple cards, or color coding. In the end, we determine that the future tasks should be more individualized. This makes the requirement for us to find a better way less important.

Here is a list of things I would recommend for a better and more productive sprint:

  • Log into Slack everyday of your sprint. Your teammates may have left you messages.

  • Get Slack on your mobile device. It is a seamless transition between the desktop and mobile versions.

  • Ask for help. Your teammates are usually more than willing to give a hand.

Looking towards the next sprint, I expect to get much more technical and in-depth. I will also be looking for opportunities to find retrospective material to include.

CS-448
CS@Worcester
Sprint-1

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Reflect As You Work

Summary

Self reflection is not always easy. Still, we must find a way to look at our work as objectively as possible. Using a Personal Practices Map and a feedback loop, we can gain a better understanding of the current state of our practices and methods.

My Reaction

The Personal Practice Map is the first thing that was be to me. I am not sure if I can remember back well enough to create one from my previous experience. But I can make one for today and begin to map my methods moving forward.

An approach I could use with the map would be to note the things I did not know back then. Some of these legacy items could include, “I did not use proper testing for my code,” or “I was not coding to an interface.”  These are some of the items that could be included on an earlier version of my personal practice map.

I agree with the concept of mindful and unobtrusive observation.  Watching and learning from those who have the skills that you would like to obtain is an excellent way of absorbing those skills. I look forward to engaging in group programming in my career and think that I would try the write a test then code to the tests patterns. This seems to be an interesting and efficient way to get fast results.

In conclusion, the Reflect as You Work pattern makes a lot of sense to me. It reminds us to be mindful and observant for opportunities to learn from ourselves and others. It makes the claim that watchful introspection is key to real personal growth. I agree with the sentiment wholeheartedly.

CS-448
CS@Worcester
Week-5

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.