With now two full sprints under my belt, I think I’m beginning to grasp not only the aspects of team dynamics with which I have comfort, but also those aspects with which I have discomfort. I am glad to be encountering obstacles and pitfalls in an academic setting rather than in a much higher-stakes workplace environment.
Where last sprint was primarily concerned with setup tasks, this sprint was more geared toward design – be it the design of the user interface, the program structure, or the module as a whole. We determined as a team during our first meeting that we would take responsibility for developing the Offline Data Storage service. Much of the remaining class period was spent looking over user stories, and looking into the suggested service for offline storage: PouchDB. Over the next several meetings, we worked toward three goals in particular. Firstly, we wanted to figure out the best way to transition from the online state of the application to the offline state of the application. To this end, we drew up a few of our ideas, and posted a number of them to Balsamiq. In addition, we sought a better understanding of PouchDB, so many of us spent ample amounts of time doing online exercises from the PouchDB website and making small, basic offline applications for practice. Perhaps least importantly – but certainly still relevant – is that we spent time during each meeting reading through the code that Ampath has already written. We focused on their data storage service that is already in use for their online storage, and are looking to see if we can translate ideas from those sections of code to the ones we develop.
As far as my contributions to the team this week, I would say that the largest part I played was in the dissection of Ampath’s code, and in the assistance with PouchDB growing pains with the exercises. I would have liked to have spent more time working out a foundation of a plan for our service’s implementation. In the sprints to come, I hope to dedicate more resources toward the actual building of the service, so that we can get the ball rolling with the code.
The biggest takeaway I came to from this week is that self-management is a critical skill in the field of software development. Although we are not yet at the stage of writing the actual classes for the project, it is clear that each of us is not used to having a large task with no overseer. While Ampath is technically available via Slack, we haven’t had much success in getting additional information from them, such as a UML diagram for the existing project (which we were told does not exist). As a result, we have had to maintain a degree of discipline on our own without the extrinsically motivational forces we have grown used to. Going forward, I hope to develop a more productive and attentive attitude, and believe that such a change will greatly benefit the project.