Category Archives: Sprint 2

Sprint-2 Retrospective

This sprint session was really tough for me at the beginning. I was confused as to what exactly was expected from us and was stressed for some time. Not having a sense of direction regarding which specific file to look at was a big issue. Thanks to the team members especially Rick Phillips who came out with an outline of what the team at that point need to focus on.

First and foremost, we started the sprint by deciding how we want to manage the gitHub repository. We came out with the decision that Rick Phillips should make a copy and give every team member the right to pull and edit. We also had to read the user story by the AMPATH which was quit straight forward. I did not know all these at the beginning.

Also, one most important among our task was to come up with design ideas to implement the ng2-amrs offline module and I think it is a good idea to have such a system. If my memory is right, I think we concluded with an idea that there should be a front server, intermediate and the remote server. Even though we are not sure if that will work for AMPATH, I believed we had a good idea. The intermediate server will act in between the remote server and the front server. The offline service would then be pending within the intermediate servers and anytime service is restored the front and the remote server would be updated.

Rick Phillips again draws our attention to the router component which helped us dig more to see how components are in connection with each other. With regards, we try to understand the AMPATH node paths on mapping the routes of the code in connection with AMPATH server; we together experimented some search by checking the URLs to see what component get invoked when a particular call is made. Even though things were not quit clear, I still have little ideas as to how some of the component got called. This was really helpful in understanding some of the parts in the ng2-amrs code that I do not understand earlier. Digging to the router component too has caused us as a team to do more outside the project search and tutorials to understand better how routing in angular work. Though, at this point, I cannot strongly say I understand how it works, I still had little knowledge which help me understands things to the point the team discussion has been. I will continue to explore the router component to improve on the little knowledge I had from this sprint.

Besides, per the recommendation by Jason, I had also learned a couple of angular tutorials which help in figuring out of what is going on in the app. Though it has been time consuming trying to figure out things by ourselves, the sprint has actually challenge me to learn more stuffs on angular and above all routing which I have never thought of. I believed if the team keeps up with the enthusiasm that it put into work in this sprint period, we would have more work accomplished in our future sprints.

 

 

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective: Deliberating and Conceptualizing

This sprint was an interesting one. It seemed to offer insight for what we should expect going forward in our professional careers. In college we can become overly accustomed to expecting and working with concrete tasks. I feel this sprint was a great reminder that out in the world of software development, tasks can often be anything but concrete.

As time has progressed, in terms of scrum, I’ve been thinking of the AMPATH app’s consumers as the customer, Jonathan from the AMPATH development team as the Project Manager, and our professor as the Scrum Master. The project manager gives us as team members direction on what we should be focusing on. This is based on his knowledge of what the customer needs. The scrum master offers guidance in best optimizing these tasks. If we hit a road block, the project manager and/or the scrum master help “clear the way.” They are available for general questions and direct us to the answers of these questions. But virtually nothing has been concrete, and I realize we should not expect it to be. Ultimately it is our jobs as scrum team members to figure out how we’re going to tackle each “story” in our sprint backlog. And that is why I feel this sprint has closely emulated a real-life scenario of working in the field of software development. I am grateful for the experience.

We’ve spent this sprint with the primary goal of conceptualizing ideas to implement offline capabilities for the AMPATH project. From there, it seems to have led each team on interesting paths. For instance, our team quickly realized it was initially near impossible to conceptualize any practical implementation of an offline module. In order to proceed, we thought it was imperative to understand the complexities of the AMPATH app. While scrutinizing the code, our team noticed a pattern of repeated references to routing, HTTP calls and REST APIs. These are all subjects we had limited to no knowledge about prior to this sprint. Thus we dedicated the majority of our time becoming more familiar with these processes.

Based on the collaboration between the AMPATH development team, my teammates and my professor, here’s my brief understanding of the project so far:

  • The AMPATH app communicates to servers primarily by REST (Representational State Transfer) API.
    • REST is an approach that uses HTTP requests to GET, PUT, POST and DELETE data.
  • The app is dependent on not one, but TWO servers, OpenMRS and ETL.
    • OpenMRS seems to handle the majority of the resources, such as user accounts, locations, visits and encounter types.’
    • The responsibility of ETL seems to focus on what the acronym suggests, i.e. Extract, Transform, Load. Based on my research, it seems that the job of the ETL server is to optimize the data retrieved from OpenMRS server, such as extracting data from one database to another.
      • As of this writing, the ETL server seems to be down, and the AMPATH development team is working to resolve this.
  • Many of the AMPATH components seem to consume the OpenMRS LocationResourceService. The service seems to provide a gateway allowing other components to call HTTP requests. It is located in the openmrs-api folder within the project, i.e. 
    './src/app/openmrs-api/location-resource.service.ts';

I would like to give a special recognition to Felix (fmaiko) from the AMPATH development team for providing me with much of this information. These findings seem to indicate that we should be focusing on understanding the OpenMRS functionality. Further, the LocationResourceService seems to be a pivotal factor in making REST calls to the OpenMRS server. Felix provided me with a link to the OpenMRS wiki; I suggest anyone working on the AMPATH project to check this out going forward. It outlines pivotal information such as obtaining sever resources, as well as the format for sending each request.

For a sprint initially focused on conceptualizing ideas for offline implementation, it definitely seemed to branch off in all sorts of different areas of research. That’s what I enjoyed the most about this sprint. We started off thinking we would be primarily designing offline implementation mock diagrams. But the learning process involved turned out to make it a very informative and eventful sprint. As for our original hopes for coming up with an offline module idea… based on the information we’ve gathered during this sprint, we were able to conjure up a very abstract idea using Balsamiq:

Client-Server Check if OnlineWe are hoping to improve on these ideas in the sprints ahead.

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

Sprint Retrospective 2

On Thursday February 15th, Everyone Else (our team) sat down together to talk about what we would be going over for this sprint. We came up with a plan for this sprint to be our research and designing sprint We wanted to figure out what options we had available to us and what kind of design we were expected to create. We didn’t really get too much physical work done that affects our goal to the actual project, however I did get a chance to learn about some things that I hadn’t studied before.

To start, we had a slack message from our friends at AMPath who suggested we looked into PouchDB. PouchDB is an open-source JavaScript database inspired by Apache that is designed to run quickly within the browser. This is exactly the type of thing that we were looking for. Since our overall goal for the class is to be able to have the ability of an “Offline” mode for the medical records app from Ampath, PouchDB would be the perfect way to store data and then sync with the server once you are connected to the internet.

I followed the guide on their website to get the feel of the tool and be able to implement it into code that is already written. You can find the tutorial here: https://pouchdb.com/getting-started.html

The first step I had to take to be able to go through the getting started guide was downloading python from https://www.python.org/ . This guide used a python Simple HTTP Server to get the application running but I am sure that it can be implemented into the AMPath application anyways. After installing python (and PouchDB), I downloaded and unzipped the pouchdb-getting-started-todo.zip files that setup your “todo list” application (with missing features that you add yourself.) This tutorial helped me figure out how to create a database, write information to the database, show data from the database and manage a user interface. The last step in the tutorial shows you how to set up a two way sync with CouchDB which is the server tool used for this tutorial.

Another resource i used to get more familiar with the framework of Angular2 was Youtube. This video which is 1 hour and 18 minutes long really helped me work through the basics of the Angular2 framework and how to work with the three language (HTML, CSS, and Typescript) together. https://www.youtube.com/watch?v=bJKejcQJqHE

In this video, the narrator has you go through steps to set up your own personal website using the Angular2 framework. While it isn’t progress to the actual goal of our sprint, it was an essential part of me understanding the languages and taking some steps to practice writing in the language we will be using for the project.

The team is doing well communicating our ideas. We set up a group chat over texting to remind each other of deadlines and to talk about our progress. Everyone is encouraging each other to get work done. One thing that I think we will be doing differently this week is putting time into the project code and working together more to write code and get some progress done. Since the planning phase is over, we can finally take some steps towards the true goal of this project, an offline module.

Our team has also already accepted the task of working on an offline data storage service, so the information I learned about PouchDB should be very useful in the coming sprints.

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 2 Retrospective

I think I learned more this sprint about the necessity of good sprint planning than I did about anything else.  We started the sprint by laying out goals, and by going over the user stories in the doc that AMPATH sent us.  This was useful work, but after that we hadn’t planned for any real actionable items.  Broad goals are nice for setting a larger scope, and less so for getting concrete work done.

I did, however, learn some concrete things; I think it’s also important to note that most of my learning took place in a group setting both within my team and with another team meeting in an adjacent space.  I learned how the AMPATH app strings its services together to go from button press to REST API query, and how that information is propogated through the layers of services and onto the user interface.  I also learned how they check the online status, which may be more important going forward for other groups that are focused on smooth offline/online transitions (my team, for now, is taking on data encryption).

Other than team planning process (which I will get to later), the most important thing that I learned was that, at least for me, it’s far easier and better to go through code in a group setting than individually.  I tend to get lost or distracted when I’m looking through it on my own, where in a group I can focus and bounce ideas off of my peers.  We ended up using a projector to throw the code up on the wall.  We then started with a form that logically must request server access (we looked at the patient search form).  From there, we looked at the service invoked by the actual search function(s), which is set up to generate a table of search results.  In order to do that it makes use of another service, which actually builds the REST request from a URL stored elsewhere and the string passed along from the search bar.  I think a similar tracing of services could be useful in the future to other groups interested in different parts of the UI.  We also received some help from the AMPATH team, directing us to the openmrs-api folder which appears to contain all of the services that interact with the server.

The most important team-related learning that came out of this sprint is the now-clear necessity for specific, concrete tasks rather than more abstract ones.  We came to this conclusion during our team sprint retrospective, and we agreed to spend more time breaking down tasks and assigning them during sprint planning moving forward.

In addition, during the class time where we met for our retrospective, we started researching already-made encryption services that we could use to encrypt records pulled from the AMPATH servers.  We found three so far that may be promising; one way we can add specific, focused tasks for next sprint could be to assign one of these services to each team member so they can research it and prepare a brief report.  This way we will be able to present what we’ve found to AMPATH for feedback on which might be the most suitable (they’ve already given us a few guidelines).

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

Looking Back on Sprint 2

The second sprint was a bit more open ended, with far fewer discrete tasks to complete than during the first sprint. This meant that rather than working independently during class to complete individual environment set up tasks, we worked as a team during class to discuss the user stories contained in the Google Doc. I feel that once again the team worked well together and everyone contributed to achieving the goals for this sprint. There are a few places where I see room for improvement, and this was discussed during our in class retrospective meeting.

One of the first tasks that I personally completed this sprint was looking at the mockup tool, Balsamiq. While I was a little unsure about this at first, seeing some of the mockups that other teams did later on in the sprint helped me to better understand the tool. I think that for the next sprint, using Balsamiq as a team to visualize our ideas will be extremely helpful.

Although I had already completed the build ng2-amrs and connect your ng2-amrs to the server tasks, these tasks remained on the sprint backlog because not everyone on the team completed them during the first sprint. By the end of sprint 2, however, all members of the team had completed both of these tasks and they were moved to the completed board. This was important because these tasks are essential to beginning actual development, which will likely occur as early as the next sprint.

Another task that was left over after the first sprint was learning how tests work in Angular. Although we were told at the end of last sprint that this task was probably not essential, we decided as a team to include it in the second sprint because the majority of the team had already completed it. Members of the team who had already looked at resources on Angular testing shared their sources with those who had not yet completed the task.

The most significant tasks for this sprint had to do with generating design ideas from the user stories shared by the AMPATH team through the Google Doc. We met as a team during class time and began by reading the user stories together as a group. Although much of the team had already read the user stories independently before class, I feel that talking them out was helpful in providing clarification. Members of the team shared their individual understanding of different parts of the document, and asked questions where understanding was lacking.

After we felt we had a general understanding of the user stories, we looked as a team to the tasks that were listed further in the document. We then brainstormed ideas in a document for the first task on the list. This is the task that addresses offline login and offline data storage. We collaborated with the group directly behind us to share our thoughts and also get a better idea of how they were planning on going about development.

I think that we as a team are becoming more comfortable collaborating with one another, and also with sharing our ideas with among the other teams. I think that in future sprints we need to continue to attempt to clearly communicate our intentions with other teams so as not to do overlapping work. Although the effects of duplicated work were not very severe during this sprint, it could result in a lot of wasted effort in the future. I am looking forward to continuing to work with my team in the third sprint and using what we have learned to work effectively and efficiently.

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

Sprint 2 Retrospective

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.

Sprint 2 Retrospective

Overall, I felt that Sprint 2 went pretty well. It was the first time going through a full planning session rather than having it set up for us. I felt the planning session went pretty smoothly considering it was the first time all of us were going through it as a team. The team also continues to work well together. I can feel we are getting to know each other better day by day, including both some common personal interests to keep conversations going as well as getting a better idea for what each team member is good at/capable of. I feel that knowing these kinds of things is important for the team to work well as a whole unit rather than a bunch of individual pieces. People are getting better about attending the standups as well, which is good to see as they are important in helping keep each other informed on what is going on in between classes. This also helps prevent duplicating work. We all seem to be on the same page more and more.

We accomplished pretty much everything we wanted to accomplish this sprint. Everyone had a chance to check out Balsamiq. To me it seems like a useful, easy to use, intuitive tool. Hopefully we will get a chance to actually put it to good use at some point later on down the line. We also continued to research angular testing. There is a lot of information out there on it, so I feel this will be a continual activity throughout the semester whenever we have some spare time. Overall, the tests don’t seem overly challenging to write. There was also a continued effort to get eveyone’s ng2-amrs running and connecting to their servers. I believe everyone is up and running on that front.

The big task this week was coming up with design ideas based off of AMPATH’s Google Doc. The document was a bit overwhelming at first as it was a bit of an information overload. There are a lot of good goals/ideas in there, so we decided that it would be best if we focused on one of the goals they had. Otherwise we felt we would be spreading ourselves too thin. The goal of choice was to add the capability to login offline and store data offline. We chose this one because it seems to use that it would be the most useful feature considering the environment/places they work in at times. We ended up making a document with some basic things that we know need to be done in order to accomplish this goal. Some of these included finding a way to encrypt patient data and user passwords. We will have to coordinate with other teams on this as we are aware that another team has already started to look at this. We also know we will need a way to communicate with the main platform and have a way to automatically update their database once the tablet is back online. Those were just a few of them. The whole document can be found on our team’s slack page if you are interested in seeing all of them.

I feel if we continue to work together like we did this sprint we will be in a good place come the end of the semester. I don’t see any major changes that need to be made to the team at this point in time. I look forward to continue to work with my teammates come sprint 3.

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

Sprint 2 Reflections

This second sprint went very well, I’ve learned a lot about how useful Trello can be. I’ve also realized how communication is a huge part of completing a project, even if it’s just setting things up. Everyone in our group was able to get ng2-amrs up and running, with the help of all of our group. I wouldn’t proceed any differently than how I have been, we finally have everything up and running successfully and I’m excited to start working on some bug fixes and coding.

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