We’ve just completed our final working sprint, consisting of six primary objectives.
1. Maintain communication and collaboration with all other teams.
2. Create a mock diagram demonstrating our implementation ideas.
3. Capture the specific data requested by the AMPATH team.
4. Store this specific data into the PouchDB database.
5. Write tests for our existing code.
6. Develop an offline GUI to display specific offline data.
Continue reading “Sprint 6 Retrospective: Capturing and Displaying Specific Categories”
As Sprint 5 comes to a close, I believe we are making great progress. Our team’s primary goal is to have a completely functional data capturing service for offline purposes. With the achievements made during this sprint, it seems very realistic that we will have a working module by the end of this semester.
Our main objectives for Sprint 5 were the following:
1. Decide what would be the most useful data to capture.
2. Capture raw data to be stored into PouchDB.
3. Construct ideas presenting captured data in a meaningful way.
4. Improve cross-team communication.
Continue reading “Sprint 5 Retrospective: Capturing Patient Data”
It seems that as each sprint goes by, we tend to achieve a substantial amount more than the preceding one. This sprint is no exception. I feel it has a lot to do with us becoming more familiar with the project, as well as the Angular framework.
Our main objectives for Sprint 4 were the following:
1. Finish refactoring online-tracker to include a service.
2. Successfully install PouchDB within the AMPATH app.
3. Research and attempt using the PouchDB API to:
(a) perform REST calls.
(b) deal with synchronization.
(c) encrypt the data within the database.
Continue reading “Sprint 4 Retrospective: Online Tracker and PouchDB”
We started off this sprint with two primary objectives in mind. Soon I will discuss a bit about our sub-tasks to complement these objectives; i.e. Collaboration, research, complete tutorials, research some more, rinse and repeat…
But first, I want to elaborate on our primary objectives:
1. Refactor online-tracker component to include a service.
2. Begin the implementation of an offline capture data service.
Our first goal, refactoring the online tracker component, proved to be a lot more simplistic than the second. For the most part, it only took moving around code from one file to another. The end result is the online-tracker-component now calls functions from the new online-tracker-service to determine whether there is an internet connection. Though a simple refactoring modification, this change should be beneficial to all teams in the near future. We can now use our new online tracker service to call functions to check for connectivity status. Since all teams are working towards an offline module for AMRS, we feel this is essential for any of us to go forward. Continue reading “Sprint 3 Retrospective: Offline Services Development Stage”
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. Continue reading “Sprint 2 Retrospective: Deliberating and Conceptualizing”
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. Continue reading “Sprint 1 Retrospective: Getting up and Running”