00: Development Schedule - team-photo-app/photo-app GitHub Wiki
Class 45 (Project Planning)
- Create your github organization
- Back-End Repo
- Front-End Repo
- Other Repo’s for supporting services
- Deploy a simple “Hello World” server through your full pipeline
- Stage and Production of all servers
- Tests hooked up and passing
- Get your project board setup with your initial stories
- At this stage, its’s probably just stories to write more stories…
- Get your Wiki setup for documentation
Class 46 (Project Start)
- Wireframes Complete
- User workflows finalized
- Initial design planned
- Code
Class 47 (Core MVP)
- First MVP should be completed by EOD
- Your core functionality should be working end to end.
- Databases Hooked up and saving
- User workflow works (navigation, actions)
Class 48 (Final MVP)
- Adding Non-Breaking Features
- Layering on the Styles
- Final “MVP” should be complete
- Whatever you have by EOD should be presentation ready
- Anything you add from this point on is purely additive.
Class 49
- Final Polish
- Presentation Practice
Class 50 (Graduation Day)
- Eat.
- Drink.
- Present.
- Graduate.
- Win.
Presentations
Prepare a Powerpoint Style “deck” to present your project Slide 1: Team Name and Logo Slide 2: Summary of the project One slide for each team member. Picture, 2-3 bullet points about you Introduce yourself, touch on your role in the team, and present your personal pitch. Slide: Describe your problem domain in more bullet points Slide: Sell your solution Move to a stellar demo of the working application Show Your Tests Slide: Detail your workflow and process Slide: Highlight your wins Slide: Highlight areas for growth
Questions and Answers
Why a deck? It’s a helpful tool to keep you on time and on focus. Also, you will spend a lot of time in dev jobs speaking in front of a deck, so this is good practice for that. Know what’s on screen behind you and prepare to speak in what appears to be an ‘ad-hoc’ fashion in front of it.
Tips and Tricks
- Solve a real business or community problem
- Deliver something deliverable (make it rock!)
- Don’t over-complicate. Sometimes, the simplest solution can be the most scalable and stable. Favor stability and tightness over wizardry