Sprint 6 Retrospective

Sprint 6 lasted from April 24th to May 6th. This sprint, my group and I had a main goal to focus on completing a powerpoint of our final project to present to the class on May 15th. Unknowingly, we instead spent most of our class time trying to merge and integrate our project with everybody else’s, which in turn broke some of our features and we never fully completed this integration.

While my teammates worked through those issues, I spent a lot of time trying to merge my completed dropdown button feature on to the main branch. This was also unsuccessful, partly due to merge conflicts since minor fixes and contributions were being pushed at the same time I was trying to push my own changes. My feature has been working on my own local branch for quite some time, in fact it was easier to develop the dropdown button than it was to merge it with everybody else’s project.

Working with professor wurst, I created a new branch that included my feature since attempting to push to the main branch wasn’t working. I tried creating a new folder, pulling the most up to date branch on a clean slate, then rewriting my changes in class which only took me about an hour. This plan was also unfortunately unsuccessful. Ultimately, as the deadline for the end of the sprint drew closer, we had to compromise on some of our more ambitious goals in order to start work on the presentation, which was meant to be the focus of the entire sprint.

I was still able to write about the ins and outs of my dropdown button, and I included screenshots from my local running branch. Thankfully, I believe I will have much to talk about. I will explain in depth some of the code lines and how they tie together with the modules and components necessary to make the whole thing work. I also want to include references to where I got the idea for the dropdown, since I stumbled upon a very helpful website that included HTML sample code for me to modify and trim down to fit our projects needs. I lastly will talk about how our work can be improved in the future. Our project contains a lot of filler text and our buttons don’t do much besides display text on the screen. To fit more specific needs, the text can easily be changed and more functions in the HTML can be added without necessarily changing the buttons around. Some ideas would be displaying various messages, videos, or information otherwise that would fit a more specific need depending on who will actually be using the app. Ill include a link to the presentation below this paragraph.

https://docs.google.com/presentation/d/1mJS7XpGuvMmKmI_LZyf-CLtPi8Xi8Ft_8yVu3f09ewk/edit?ts=5cc73c24#slide=id.g59df31ee4a_1_27

Overall I think we will get a good grade on the project, on our presentation, and on the class as a whole. I enjoyed this class more so than some of the others I took this semester, and I feel that I had more motivation to put in more effort into this class than some of the others.

Sprint 5 Retrospective

Sprint five lasted from April 8th to April 22nd. This sprint, we were focused on completing any big steps left that the project required in preparation for the upcoming sprint, where we will focus on our presentation. For the next sprint, we also have allocated enough time to polish minor details if necessary or finish any uncompleted project features.

My role this sprint was to implement a button that offered more buttons when pressed. This is useful in cases where we have multiple links or related content that can be categorized under a common theme.

To start, I created a new routing module and component for the new button. Yesenia helped me a lot with this task, since she set up the components for the existing buttons. She provided me with the correct commands, ng generate module file-name –routing and ng generate component file-name/sub-file-name. We worked together by bouncing ideas off as we pieced together the HTML and related programming for the new button. By the end of class, we successfully created a new button named dropdown that would rout to a new page, indicating the linked connection was successful.

This was not the full intention however, instead of bringing the user to a new page, the button should display three more options, each of which could have the capabilities to send the user to a new page. I created the three links, but I couldn’t figure out how to hide/show them upon triggering the dropdown button. I deduced that I would mostly have to play with the component.html file, I used the following link as a model of what I wanted to do.

https://material.angular.io/components/sidenav/overview

In that link, scrolling down to the section titled “Drawer with explicit backdrop setting” I was able to look at the existing HTML and trim it down to fit the needs of the project. Mat-form-field and mat-option was specifically what I needed and what I used. With few modifications, and again some bouncing ideas from yesenia, I currently have the feature up and running. Some small things that I would like to get done if possible would be changing the color of the dropdown text to match the other buttons, as right now it is very distinguished looking. Also the manner in which the new options appear is not what I originally thought of, instead of creating a pop out list, I was thinking the buttons would appear on the sidebar beneath the dropdown button and would shift all other buttons below it down. The link below shows what I was originally thinking, but I couldn’t make that work as easily.

https://www.w3schools.com/howto/howto_js_dropdown_sidenav.asp

The reason why I decided to use the other link directly over this one is because I didn’t understand how the provided javascript worked enough to implement it in our project. I’m sure if I dedicated to it, I would be able to get the feature exactly how I want it, but this is not necessary and Ill only change the existing feature if we have extra time.

The focus for our next sprint will be coming up with our presentation and trying to merge our project with some of the other groups projects. We want to be able to combine our side bar with the team working on the search bar without stepping on toes. Tim is currently working on that, I may need to copy and paste some of my work in order to make sure its implemented in the current master branch.

Individual Apprenticeship Patterns – Concrete Skills

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02s04.html

This pattern works with the situation that an upcoming software engineer has some knowledge, but not much experience applying that to practical situations. This is also under the assumption that the learning engineer is seeking out work with a suitable team of coworkers, or applying to a new job.

Following this, the pattern advises becoming proficient at skills that every team needs. This typically means executing simple manual tasks, allowing the apprentice to contribute before moving to a more direct role in the group. It is important to get to the point where work can be done without supervision or help from the rest of the team, so they can focus their time on other work. This type of work includes “writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice.”

On the other side of the coin, hiring managers are taking a risk by hiring a student or apprentice since they might require more help early on. To help combat this, concrete skills are an immediate and significant answer. Being prepared before getting hired allows instant benefit and payoff to the group that decided to take that chance, proving the worth and capability of the applicant.

This also helps when constructing a resume beforehand. Highlighting the areas that offer those quick benefits will help make the resume stand out, resulting in a higher chance to be contacted. Following this point, it makes sense to do extra research on the position first in order to train for the concrete skills that will be necessary once hired.

Although I feel that this can be challenging, they are very good practices. It can be¬†frustrating if things don’t turn out perfectly, and an application is denied, but especially in cases where a dream job is on the line, the extra effort is very worth it. Even if the applicant is not hired, they likely can use or relate the concrete skills they’ve learned in at a different company.

Sprint 4 Retrospective

Sprint four lasted from March 27th to April 8th. I was sick for the first class, but it wasnt hard to catch up on what the rest of the team was planning for the rest of the sprint. By the end of it, we’ve made a lot of progress, our group currently has a working prototype for our final presentation. After this sprint, or the next, we should be able to focus more on putting our presentation together since our project will likely be working and polished by then.

Recently we’ve brainstormed a list of improvement ideas to work on, polishing the project while we still have time. Some of the improvements include changing the header colors around, making the words bigger and easier to read, adding more buttons, and doing more with the title on the page. Many of these features are quick fixes, typically each one will take less than an hour. This sprint is likely going to change dynamically as we think of good ideas or quick changes.

We decided not to implement a login feature, or rather, it has a low priority and we will do it last if we have extra time on our hands. Additionally, the way we divide up work will be different than described in my last retrospective. Each button in the navbar is more of a placeholder, not exactly designed to perform a specific task other than change the text in the middle of the screen. Instead, each member will be given minor to moderate tasks to complete like the ones we planned out in our last class.

First we made sure to download the required angular material, our group member quoc took the liberty of creating a skeleton project and pushing it to gitlab. We all downloaded the skeleton, and have since made improvements on the style and layout of our navigation bar. Of the features we brainstormed, in class we quickly completed centering the text, which makes it much easier to read. Currently, we are also quickly working on changing the color values, which will also be completed soon.

My role in the group is to figure out how to have a nested button within one or multiple side bar buttons. The idea is that we could have a category named button that also works as a drop down bar, offering a few different buttons based on the category. My assignment seems not difficult, but also not as easy as changing color values, which is why some group members have multiple low effort tasks while I only have one moderate effort task.

Completing this by the end of the next sprint, along with everybody else’s contributions, results in a very usable product for our final presentation. To accomplish this, two tutorial videos were posted to the team backlog on github which each group member is assigned to complete as homework, though ideally the videos will help shorten the amount of time our contributions will take. I’ve linked both tutorial videos below:

Apprenticeship Pattern – Create Feedback Loops

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s08.html

This pattern encourages the reader to pay close attention to minor details along the way when evaluating a success or failure. Apprentices commonly find themselves in complacent situations in an average team, so naturally improvement stagnates and it becomes hard to keep yourself on track. The problem is, “the less skilled you are, the worse you are at assessing the skills of yourself and others.” This indicates that it is especially hard to get started again once caught at the bottom of the barrel.

The pattern advises seeking out feedback and constantly adjusting yourself accordingly. This will help you more accurately predict success or failure and help you more efficiently improve. Being open with your work is the focus of other patterns, all apprentices should strive to be as “teachable” as possible.

The chapter classifies feedback under two categories; reinforcing and balancing. Reinforcing feedback encourages more of something, while balancing feedback encourages less of something.

In my personal case at work, I can apply feedback to the pitch I give to the average customer. For the most part, my pitch is designed to be friendly and get the customer the product they are looking for quickly. In that time, I work to fit in other deals or offers I think the customer might be suited for. This could mean higher quality products, the benefits of the best buy credit card, or becoming a member of our total tech subscription service.

At the end of the month, we are provided feedback on how much we sold and how many cards or subscriptions we put out. Some months are luckier than others, but certainly every associate starts to get better and better over time. If an associate doesn’t raise enough revenue after a few months, they receive coaching on their style of pitch. Reinforcing feedback in this case would encourage an associate to mention the subscription service to more customers, thus increasing the chances of closing one. Balancing feedback would prevent swearing and acting rowdy with coworkers in front of the customers, in an attempt to be more approachable.

Sprint 3 Retrospective

Sprint three lasted a week longer than the other sprints due to spring break, resulting in a lot more work getting done compared to other sprints. Starting on March 6 until March 26, in our sprint backlog we planned on covering some posted videos and coming up with things to do as we went along.

The videos were posted in a slack channel by the owner of the AMPATH project, Gregory Schmidt. Greg commentated a walk through of what the app should look like, helping us get familiar with the various stages of the user interface. This also helped us understand what was being done on the backend when searching for patients or clicking on a patient profile. Greg also posted a shell of the project using a site called zeplin, which we all signed up for to view gregs content.

Once our research was done, we decided to clean up the backlog process a bit by moving everything we had on trello to a github project. The layout of both sites is similar and easy to transition to, we just copied and pasted the relevant planning information. Each team in the class picked a certain feature of the app to work on, we chose to tackle the navbar functions.

Since each member watched the youtube videos, we added a few things to our ongoing tasks while we moved them to github. Since our project is a mobile angular program, we found a link (provided below) with a lot of useful information. The site includes examples of how to get started on our navbar, we added that task to our planning board and aim to make a lot of progress towards a built prototype during the next sprint.

http://mobileangularui.com/docs/

In our last meeting, our group brainstormed some ideas of what our navbar would look like, what it will do, and who will be using it. Currently we only have a few sketches, but it seems like we’ve decided for sure that we are going to include a home button and a sign in button. We discussed each group member working on at least one button, therefore we would have 5-10 buttons and the work is evenly distributed. One concern of mine is thinking of that many buttons to develop, the project seems not complicated enough to warrant that much work.

The home button is a simple starting point, it simply takes the user to the upper most page. The sign in button idea is still a work in progress, but hypothetically it should prompt the user for some information and filter a list with data pertaining to that user. In the hands of doctors or clinicians, this would display patients names with an appointment date and the condition of the patient.

Further ideas revolve around the concept of filtering down a patient list based on specified parameters, however this idea is still foggy and might not come to fruition. The same function could be done by searching for a patients name in the search bar, a component taken by another team. We still have time though, and we are fairly ahead of schedule considering the remaining work load of the project. By the end of the semester, the 15th of may, we should have a working navbar with multiple useful buttons on it.

Sprint 2 Retrospective

This reflection is based on the work done from 2/20 to now, 3/5. In this time, our team has only met two times and I missed one of those meetings, so not a whole lot actually got done together during sprint two. We met in class and made progress on 2/20, I was absent from the meeting on 2/25. On 2/27, class was expectedly canceled with the optional choice to meet in class anyway, which we decided against. We figured we could wrap up anything that we needed to work on in the upcoming Monday’s class. Yesterday, on 3/4, Worcester State canceled all classes and events due to inclement weather, and the end of the sprint is next class at 3/5.

Our workload was fairly light anyway, we only had two sprint backlog tasks; make sure every team member could build and run the project, and learn more about angular testing. We could independently conduct research into testing, and we are encouraged to branch out to find potentially helpful content, so the snow day didn’t slow us down significantly.

To study angular testing, our group particularly focused on the two programs karma and protractor. Using the trello project management board we set up in the last sprint, two links were shared for the group to look over. For karma, I used the following link:

https://karma-runner.github.io/3.0/intro/how-it-works.html

This website explains in general terms how karma works. It loads multiple browsers and tests given code on each one, displaying the results conveniently to the developer. We will have to practice hands on with karma once we get some code and tests. For protractor, we used the following link:

http://www.protractortest.org/#/tutorial

All the information on protractors site is very hands on and literal. It explains steps and shows exact commands and lines for example, it should be easily set up and modified to our project. Since we downloaded the latest version of node.js in the last sprint, and have experience using npm, protractor will be a useful resource.

Our more major goal for sprint two was to have every member a working build of the AMPATH project in an IDE of choice. Right now, everybody besides me has a running project since I missed the last meeting. I will need to communicate with them for help troubleshooting and follow the same steps they took the next time we are all in class together.

At the same time, during our next meeting we will be planning for sprint three. We don’t have much on our plate currently since we’ve been making pretty good progress so far, so I’m not sure what to expect for sprint three. I think Professor Wurst will be giving us more concrete things to do, which we can add to our trello board.

We’ve also been keeping up to date on slack, every group member answers automatic check-ins two times a week. This keeps us all updated on what we’ve done since the last check in, what we are planning to do before the next check in, and state any obstacles blocking our progress.