Week 6 – Teamwork

We’ve come halfway through our capstone journey as a team and it has crossed my mind that I’m lucky to have come this far as a group of 3 strangers working together on one project without having any crash and burn episodes.

Thinking about it, I think what made us a good team was that everyone had professional towards the project. In the past there have been some group project nightmares I’ve went through where one thing led to the other and 5 person workload has been put on 3 people. One person was too sensitive about other team members’ thoughts of ideas and project, and eventually left the group, and another one has been barely contributing anything. I think it was a miserable experience for everyone, well maybe except for the person without doing much. In this team, everyone has been doing their share of work and actually doing quality work. The project is big that it cannot be done by one person, and everyone is aware of the timelines and own expertise, so the project has been split reasonably and everyone in the team has been contributing honest work.

It also somewhat ties into being on time and prepared. Being professional also means being responsible for own actions. This includes delivering on time and actually bringing things to the table for meetings. We held weekly meetings and no one has ever been late or missing. Everyone came prepared with the material that they had promised to deliver from the week before or ideas that needed to be implemented the following week. Thus we were never behind on timeline until now.

Being a good team member also means being respectful and considerate. There has been multiple times where we came across decision making, whether it is the tech stack, design, or timeline. Obviously we are all different people with different thoughts, and sometimes some ideas are disagreeable. Most of the time, we were able to either go with the majority vote or just respect someone else’s idea and compromise as long as it did not affect the integrity and quality. Since there was no one person yelling I want to do it my way, it was easy to cooperate and make decision logically.

One thing I like about our team was that we all had diverse background and expertise. One person prefers backend, the other prefers frontend and design, and I like like to do both. In that sense, it was easy to split the work. Also, it was great that since we have overlapping knowledge, when one person has difficulties another member can come into rescue and solve the problem.

The most important thing though, is the willingness to communicate and tackle problems together. We have encountered times where one person can’t resolve an issue and asks for help of others. Everyone in the team is willing to help and actually stepped in to resolve problems. It is easy to ignore since it’s extra work on top of my own but everyone was willing to help and work things out as team. Everyone is making honest effort and I am grateful to be in such an efficient and hardworking team and I hope that we can carry this to the end of the project with satisfactory result.

Week 3 – Software Project Planning

It’s week 3. After choosing the tech stack, Team QuizBanana went straight into project planning. Luckily there was a very extensive plan template provided for us to refer to, it was not too hard to break it down. The plan in my mind was jumbled up and maybe < 50% formed, but as we worked on this together, I feel a lot of ideas got organized. I have much more clear view of the project and smaller task goals I need to achieve.

I think the key to having a successful and complete project regardless of the project type (software, culinary, medical, etc.) is to have a robust and thorough project plan. It is very crucial in shaping the project and becoming the base of the architecture. It is the time where the base structure and shape are constructed. Without a good plan, it would be more time consuming and risky to restructure or start from scratch. Think of a construction site. If a building was designed without thorough consideration of safety, material, and design, it would be really costly in time and money to either tear it down or make it bigger once the walls are put in. Even if has finished with poor structure, it may be weak to disasters like earthquake and tornadoes, which is also not we want.

In order to create a thorough project plan, we have approached this in multiple angles. We had client and client’s requirements, initial plan of codebase structure, software and libraries, flowcharts, wireframes, database schema, and breakdown of tasks with assignments and hours. Client and requirements is where we started, and also what is the most important part of the project. The goal is to satisfy the client’s needs. Therefore we lined up all the requirements and made sure our plan covers all of client’s needs. Having the main tech stack settled last week made it easier to figure out software and libraries to use, since there are related packages we can use for the project. Codebase structure plan came naturally since there are standard ways of setting up the folders based on the stack we are using. For flowcharts, we have created web page flow, login/sign up logic, and actual quiz logic. These help guide the order things should happen and also prioritize which parts need to be done first. Wireframing and designing database schema reinforces and puts together everything from above, that somewhat works as a check. By going through the wireframe, we get a good sense of design layout and fill in the missing parts in database schema or the logic. Then we divided up the tasks by features and pages to assign to everyone based on their specialty.

Personally, I dread doing planning despite it being one of the most crucial parts on project. However, having it broken down into pieces and being able to work on it in a collaborative team setting, I think the plan came out well covered and detailed enough for us to move along to the next step. Good team effort brought us a long way and I’m quite satisfied with the end result overall.