maker-jws
commented
1 year ago @mgballou @ant07hony @kearmododragon
These comments stand out:
"It seemed like we were all very excited about the project itself and the subject matter, and that led us to having the push to get a lot of things done early on."
This point is critical, in order to produce quality work passion and desire to build/grow your product must take top priority. Without the passion to the do the work and meet your goals the code quality and feature list would have suffered. You are all passionate about your topic and the product reflects that enthusiasm with an extensive feature list and very impressive styling.
"Our plan was good but it could have been better. Sitting down and talking about the plan as we went along would have been a huge benefit and something I will put value in, in the future."
Question: how could the planning have been better? More details, more discussion? More 'high-fidelity?" It is important to recognize the need for more planning, but the team's accountability to the plan and assessing before moving too far will prevent having to rebuild a feature several times. Having clear, detailed 'acceptance criteria' before the first line of code is written is a must. Typically a project manager/team lead will be responsible for getting all members of the team included in that discussion.
"We also created new wireframes as we went along and discovered changes that needed to be made to our views. This approach really centered the UX of the app and encouraged us to build with that at the forefront."
Recognizing when you have to expand/adapt an existing work flow to a change in the application demonstrates agility and flexibility of approach - kudos!
"Having to deal with merge conflicts outside of group time when trying to update the current working branch. If the merge was not done correctly then the css had to be redone for what was lost"
A potential solution re: merge conflicts is to limit your code base changes to working hours, or configure your project repos so that any one individual cannot commit their own code / cannot commit changes which introduce a merge conflict.
There are also extensions/linters for node that can tie commit / push commands to a test suite so that all code will automatically be tested before your code is sent to a development branch.
Other Instructor notes: FE/Design - Love the retro styling/ poke theming! Code Quality - Code is clean and organized. Features / BE - Great job integrating a third party api into the application. UI - Overflow behavior was a nice QOL decision to prevent unnecessary scroll height for your team pages. A slider / flex overflow container for horizontal panning would also work well for the app.
Reflections -
a.What went well in building the project? What lessons will you take away from the experience?
Ciaran - collaboration aspect. I came away feeling that although I'd not written as much code myself, the collaboration aspect meant I didn't feel like I was dragging the team. Constantly navigating to offer ideas on the direction and wording of codes as well as suggesting ideas on the direction.
Anthony - Everyone having specific input and once collaboration was done we had a clear direction to be able to go away and work on the code ourselves.
Matthew - I really enjoyed the energy we all had and the velocity that brought into the project at the beginning. It seemed like we were all very excited about the project itself and the subject matter, and that led us to having the push to get a lot of things done early on. We pushed to MVP and started incorporating ice box features before the end of the week, and we all had a lot of ideas to contribute to the overall plan of the app.
b.Is there anything about your efforts/workflow you want to reproduce in future projects?
Ciaran - Very open and honest conversation about what we're doing. We had a very clear plan moving forward into the project with our trello board and figma sheet. We were able to stick to those and stay focused. I ensured that I had both up at all times so that if we started to go off track I was able to bring us back towards that goal of MVP.
Anthony- team worked together beautifully. Was able to come up with different ideas and combine them into one project keeping everybody on the same page with planning
Matthew -I enjoyed how we continually referenced Figma and our wireframes as we discussed the user’s flow through the app. We also created new wireframes as we went along and discovered changes that needed to be made to our views. This approach really centered the UX of the app and encouraged us to build with that at the forefront.
c.What did not go so well? Were there any events/obstacles that blocked you or impeded your team’s progress?
Ciaran - Due to my time restraints, I wasn't able to dedicate as much time to the project as my colleagues were. It's something that made me feel very guilty about falling behind. On top of this, there were times we seemed more focussed on stretch goals rather than hitting MVP so ultimately ended up covering some of them before we made it.
Anthony - Having to deal with merge conflicts outside of group time when trying to update the current working branch. If the merge was not done correctly then the css had to be redone for what was lost
Matthew - At one point during the project, we started in the morning to find we weren’t exactly on the same page about how the different portions we were all building were set to come together. We realized there was some difference of opinion & differences in vision as it related to the app’s architecture and page structure. Because of this, we took time to go back to the Figma docs and look at things from stage one. We stepped away from coding for a few hours to really explore the architecture and design, to understand everyone’s vision of the user’s flow through the app, and it led us to restructuring our data models and moving features from our icebox section to being necessary for MVP.
d.What will you do to prevent that from occurring in a future project/collaboration.
Ciaran- Allocate more specific time to the work. While now that's not possible I truly feel that in the future that will not be as much of an issue.
Anthony - as mentioned in the grow section, do more planning. Our plan was good but it could have been better. Sitting down and talking about the plan as we went along would have been a huge benefit and something I will put value in, in the future.
Matthew - Going into future projects, additional clarity and more specifics included in our planning documents may have helped prevent this issue. We all were working quickly, building this project in the span of a week, and didn’t exactly have the luxury of time to fully explain the structure of what one of us was building to the other. We also had different features we would have liked to implement. We could have taken more time at the beginning to outline what each of us envisioned the app to be at the end, and hashed out those differences before we started building.