During Sprint Retrospective 2, I learned more about the OpenMRS REST endpoints that Ampath uses for it’s core services. I learned more about what the Ampath team is looking for in terms of an encryption service if we are using open source code. In general they are looking for stability: i.e. number of contributors, number of commits, recent activity, any big name (Google, Microsoft, etc), and adaptability. I learned there is a standard Webcrypto that most browsers use as a standard and that we should stick to that standard. I learned more about time planning, and the need to do a better job documenting what we are doing, and splitting up tasks for individuals to work on.

The team worked well, I’m more productive when we are all together going through the code on the projector. It’s nice to have others looking at the same material you are, sometimes they notice things you don’t and it helps everyone on the team learn. I try to participate and offer any tips or advice I might have. I try being prepared for the sprint by trying to understand what is going on and how the services on the application work. I think we need to do a better job documenting everything we do and making sure to share it with those who it might help, with the addition of the documentation thread on slack, it will make sharing that information easier. Next sprint I am going to keep a log of what I am doing, or ideas I have as a personal log to help me organize and write my sprint retrospectives. Now that we have more of an idea what our team should be focusing on, we can start getting into the details of implementing the encryption service and how that ties in with the other functions being added by other teams.

During Sprint Retrospective 2, our team organized our trello board and began to add tasks we thought we could complete during the sprint. We planned on walking through some of the ng2-amrs services, looking into the REST endpoints (with the postman app), checking out Balsamiq, and to coming up with design ideas for implementing an offline service for ng2-amrs. We started our work by walking through some of the services in the openmrs-api folder. We went through some of the endpoint in the OpenMRS Rest Web Services API wiki. We looked into the service that sets a users location, the patient search function, the offline / online indicator, and we began to see how those services work with the front end, and the OpenMRS api that performs a lot of the functions on ng2-amrs. We began to turn our attention to finding out how to implement a service that encrypts and decrypts data. We did some research online for possible solutions and found a few options that we shared with the Ampath team asking for their input: bcryptjs, forge, crypto-js. We are going to look more into forge because it seems to have the most activity.

The post Sprint Retrospective 2 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.

Overall I feel that this sprint could have gone better, but as a silver lining, it gave us an opportunity to see what we need to improve on moving forward.  Luckily this happened early on in the project and wasn’t an issue that went unnoticed until the semester was almost over.  The important part is to reflect on the faults of this sprint in order to improve and avoid the same mistakes moving forward.  I do believe that we did start to come together as a team and work well together.  I feel that everyone on the team is willing to listen to everyone else’s opinions without passing judgment or shutting each other down even when disagreeing.

One important piece that we did not do is documenting.  We should have documented what we figured out to help us navigate what we were learning.  Looking forward I plan on taking personal notes recapping the team meetings just to keep a personal track on what we talk about.  I feel that we also need to encourage each other to start documenting what we find when working outside of team meetings, or even what we may come up with during the class time.  This will help reinforce what we learn and also allow us to more effectively share it with the rest of the team.

Another problem area was assigning tasks.  There’s an old saying that I learned years ago that if a job is assigned to everyone than it is assigned to no one.  Meaning that if it is kept general and said that “this is a team task” without specifying a role for every member, even if it is explicit for each member to complete the same task, then there is a strong chance that no one will do it and expect a different team member to do it.  There needs to be direct ownership of tasks to ensure they at least get worked on.  When there is no ownership that also means that no one can be held accountable for failing to do it.

The sprint wasn’t a complete failure though.  We read through the user stories to get a better understanding of what was going to be expected of us.  This also helped start team discussions as to which service and task we wanted to take on for the majority of the semester.  This also helped get us started on mapping out the program and services that the class will be working on improving.  We started to look at the ng2-amrs code both on our own and during the last few class periods.  We started to look at where we login to the site and walked through the code starting from the login to try and map out how the program runs and works with the REST API.  Again this would have been better to write some kind of documentation to reinforce our understanding of this mapping.

While not the most successful sprint I do believe that it was productive from the point that we learned what not to do moving forward.  My hope is that we can build on our failures and become more successful for the rest of the semester.  While it’s important not to dismiss this sprint entirely we can’t let it bring us down and lower the team’s morale.

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

This was our first sprint as a team and was anything but normal.  I would like to say that I believe that having a sprint where the main objective to set up our personal and team environments was a great starting point.  It allowed everyone on the team to help each other get ready for the project and not feel like we had to rush.  It also gave us to sit together as a team and go through the same steps that we will in future sprints.  There was definitely a lot of experience to gain with very little risk if we did not complete the sprint the correct way.  That’s not to say there was no risk, because if we did not set up our environment or study Angular we will be in trouble next sprint.  We did not start contributing to the project though so it was less stressful than a trial by fire and risk falling behind at the beginning of the project and put the team in a bad mood and kill morale for the rest of the semester.  The other side of this sprint though was that most of the activities were personal and did not contribute to a group whole at the end of the sprint so for times in the middle of the sprint it was hard to be able to talk during the working classes to the rest of the team about our progress and work as a team.  I am fully aware though that that will not be the case moving forward though and even though we will be working individually I think since they will be pieces of a whole it will be easier to collaborate during class and reach out when we run into roadblocks.

This made the rating difficult for the first sprint as well.  It quickly became hard to rate the rest of the team on their contributions to the team during the sprint when there was not much of a team effort needed, with the main exception being if someone needed assistance setting up the environment or asked a specific question on one of the user stories.

I feel like this sprint got our team ready to go though and I look forward to helping improve this application throughout the semester and working with my team.  We are set up in a good place and we have a solid foundation to start working on our portion of this project.  I also like that we will be working on a real world application that we can put on our resume, but also one that is doing good throughout the world and be able to point to it in the future and say “I helped make that better.”  I’ve talked to a few people about it, but I think that as a whole everyone is excited to start working on this application and feel that even though we are on separate teams we are all willing to help other teams.  This really has the feeling of a project that is bigger than us and no one is competing against anyone else the way that some may feel if we were all completing the same assignment or taking tests.  We are all taking on this task together and ready to do it to the best of our ability.

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