Some tasks that we did during the week that helped lead us to establishing the offline data capture service interface were:
- Help ensure GUI code is compatible with any offline-capturing abilities we implement when the user is online and vice versa.
- Create balsamiq diagrams outlining current and anticipated implementations of offline-capturing the OpenMRS / ETL data.
- Ensure all new components, GUIs, etc comply with basic AMPATH CSS styles, overall look and coding convention.
- Code the offline GUI based on the help and input from Jerry and other teammates.
- Write/maintain tests for our implementations so they are always as current as possible.
- Seek help from the AMPATH development team if any of us hit a roadblock concerning implementation.
- Offer suggestions to other teams based on our overall process, so that all teams’ implementations can work together as smoothly as possible.
- Touch base with all teams (encryption, offline-storage, and login) regarding their overall progress.
- Develop high-level idea of a Doctor/Provider object so we can consider if it is worth implementation.
- Develop mock diagram where a “Doctor/Provider” can pick and choose what patients to sync.
The above tasks were what was tried and attempted. What was done and completed were the establishment of the Doctor/Provider object, and the mock diagram. For the GUI task, we had to communicate with JJ a lot. Due to the amount of time the team had, we had a feeling that there wouldn’t be enough time to create a perfect GUI, even though JJ wanted one. Midway through the sprint, we sent JJ our progress on what we did so far for the offline data capture service through a walk-through video that we shared on the slack channel. JJ then understood where were at with the progress and we concluded that it was okay to work towards establishing an interface where the user can clearly see if he is offline/online along with the data. That was one of the tasks that we had approach differently and adjusted to.
As a team, we learned to make a major adjustment to our task during this sprint. We knew that time was a concern, and what the people at AMPATH and JJ were expecting to get, which was the new offline GUI, seemed to be too much. We wanted to at least deliver something to them that at least worked, which is why we moved away from creating the new GUI. From this situation, this could be applied in real life software development environments because there will come times where I would have to adjust my tasks to deliver something that the customer wants, even if it isn’t 100% of what they want it to be, it will perform the same functions of what they want it to do.
The team’s performance during this sprint was above above average. Everyone contributed evenly or more than an adequate effort throughout this sprint. Communication was very effective between each member and between our team and AMPATH. As an individual, I performed average during this sprint. I mainly tried to talk to the other teams, trying to get some info on their status. The only team that we communicated to more than others was the offline data storage team, and we began to work alongside with them since our tasks were similar to theirs. I also tried to help find several components in the AMPATH code for which JJ wanted the interface to display such such as genral patient data, vitals, lab results, and HIV summaries.
Overall, the team worked diligently and we wouldn’t have proceeded in any other way. We will try to have our offline interface working, completed and delivered hopefully by the end of this next half sprint.