My reflection of a semester long project with 7 of my peers. For this project we were tasked with created a bill management system for the Department of Education, to track all current bills and hearings. Their current system is outdated and was described as tedious and not user friendly. Some requirements for this include: create a user friendly application, make it newer and easier to navigate, load a list of bills for the current year from the database, create an inbox within the application to send bills to employees, ability to create testimonies for bills assigned to hearings. And some nice to haves include: mobile application compatibility, syncronization with a 3rd party calendar, a live countdown for bills assigned to hearings, and an archive of testimonies with the ability to view all edits made to the document.
Throughout the duration of the semester, something my group struggled with was the understanding of the application we needed to replicate. We had a total of 4 meetings with the customer and each time our project took a 180 turn. What we lacked was an assigned product manager which would’ve cleared a lot of questions and concerns that we had. Most meetings in the beginning and middle of the project duration comprised of us asking each other questions which were just answered with guesses. In a sense we had to come together and be our own project managers, which taught us all how important coordination is. The team seemed to lose direction at a certain point, where only a few of us knew what was going on. This was resolved by having stand ups at the beginning of every meeting where each member said what they were working on, any issues or concerns they had, and what they will try to do until the next meeting. This proved to be effective as everyone was brought on the same page after hearing what their peers were working on in a different part of the application.
Because we had to divide tasks among 8 people, communication was crutial to the progress of the project. The most notable conflicts arose when two or more members were working on the same part of the application and didn’t want to overwrite each other’s code. As well as when the group didn’t know how to approach a requirement or engineer a create solution to the customer’s problem. As the semester went on we were able to communicate properly by doing stand ups and messaging each other in the group chat. Merge conflicts were avoided by sending a mass message that informed the group of a merge to the main branch of theh project, which included the branch that was merging to main and if any installs were necessary.
This project was a positive learning experience for me because I was able to not only apply my software engineering skills to a real customer’s application, but also to learn how to communicate and put together a functioning team. This was an intimidating project just by hearing the pitch from our customers on the first meeting, but through some long nights with my team we were able to pull it off and get closer to each other as well. The bottom line of this essay is that there is more to software engineering than just software.