Reflections

Many tools/technologies were used throughout the development process. The first major technology was GitHub, which was very effective for hosting our code repository and version control. We also found its wiki more effective than Google Docs for keeping the rest of our documents together and up to date. Our team used Flowdock, a team collaboration app, as our primary communication tool. It was extremely effective as it allowed conversation threading and tagging, private chat amongst team members, and group chat. Jira was used to track and organize tasks through the use of scrum boards and workflows for each sprint. It had the ability to assign team members to tasks and automatically generated burn-down charts. A multitude of technologies were used in the end product (website). The first technology we chose to use was the Django web framework as it is based in Python, a language the whole team knows. The presentation of addresses in our complaints database as well as validation of user-inputted addresses were handled by the Google Maps API, which was very easy to work with and implement. Allowing commenting on pages for buildings with complaints became a non-issue as we chose to use Disqus. Foundation, a CSS framework, made it easy to quickly implement simple UI elements to style the interface of the website. While there were many technologies at our disposal, we did not get to everything in the project we had planned for.

The biggest thing that we chose not to do early on in this project was include SMS parsing capabilities. There are quite a few services that we could have implemented to take care of this task, but all were deemed too expensive for the client’s budget. Other issues left in the backlog had a lower priority than other tasks that were finished. In the interest of getting a working foundation for the website so that we could get more tasks done, we created a simple user interface with plans to update to a more advanced interface later. The collection and exporting of user contact information, website analytics, the ability to search by address, and various map filters were not implemented due to time constraints.

The first problem our team ran into at the beginning of the project was the use of too many technologies for communication: Google Hangouts, Whatsapp, texting, and email. This caused some confusion when trying to keep track of conversation threads and forced us to constantly check every service for updates. We learned that it was much better to stick to one primary technology for team communication: Flowdock. We left texting/calling for urgent issues that required more immediate contact and email for communication with the client. We also tried switching between different team/product management services (Pivotal Tracker and Trello) to keep track of our sprints and scrum boards, trying to find the best one. Trello had a structure that was too general for our purposes, while Pivotal Tracker forced constraints on us, such us not allowing us to choose sprint start and end dates. Jira was flexible and gave us enough tools to focus our sprint workflow. Once we had settled on Jira, we did not originally take advantage of setting a custom workflows, keeping it general as we moved from sprint to sprint. In the end, formalizing our test and review phases in a workflow helped to keep everyone more focused on test driven development and created a more rigorous structure for collaboration. We were over-optimistic in our first sprint projection, planning to finish many tasks later on. We worked hard, but were unable to finish everything, and we learned more about how much we could actually handle as a team, improving our planning for later sprints. Our first server we deployed our website on was Microsoft Azure, which was fine until we realized that we were spending too much time troubleshooting the server when it was much better to find and replace anything complicated with a simpler technology.