Every good app starts with an idea. Here are a few things that should be included in you proposal
- Project Description
- What problem does your project solve?
- Who has this problem?
- How will your project solve this problem?
- What inputs does it need?
- What outputs does it produce?
- What technologies do you plan to use?
- Prioritized Feature list (Label stretch features with STRETCH)
Before you even begin writing code, you first layout the foundation of your application using these tools
- Create user stories
- Create a board where those stories live
- Wire-Frame your app
- Create an ERD
- Map out the whole user experience, for each type of user you expect to have...(with in reason)
MVP stands for Minimal Viable Product. Essentially it is the one feature this app needs, at minimum, to exist. Your idea of what MVP is and what it takes to get there, will grow and shift as your understanding of your application does. This is not a question you ask yourself only once at the inception of the app, but something you should ask yourself at the beginning and end of every development day.
Go back to your board of user stories and ask yourself, 'what is the most important feature in this app?' Grab that/those cards and put them at the top of your board and begin to create the various tasks necessary to the completion of the story. Continue to do this until you have tasks and order of importance for each story on the board. With all the work you have to do looking back at you, flag those stories which aren't necessary but are still `nice to have' in a away that makes sense to you. I like to give them the 'stretch goal' tag or even create a 'stretch' column where these stories live. Your focus should be those stories at the top of the board and nothing else.
EXTRA PRO TIP: MVP should be a thin, vertical slice of your app. Meaning, it can stand alone on its own. That means that feature is, pushed to master, deployed, appropriately styled, and also consumes the api. If it is not ALL OF THESE THINGS then you should NOT move that card to done, which means it still deserves your time and attention. Finish it. If you make a decision to pivot away from that idea of MVP you should already have the new story at the top of your board and you should have notes on that card as to why you aren't focusing on it any more.
You will be successful if you create a plan and routine that makes sense based on the way you develop. Assuming you have completed the steps above here is an example of what you dev cycle might look like.
- Set goals before you even start writing your first line of code every day:
- Within the next hour I want to have a repo for my server created that is pushed to github
- Within the next hour I want to have a repo for my client created that is pushed to github
- Within the next hour I want to have a database created and stored locally
- Within the next hour I want to have a boilerplate react app that is pushed to my client repo etc etc etc etc
- Ask yourself 'what is MVP'
- Then start coding in the time constraints of those goals.
- You should be pushing early and often.
- For the most part you should only be working on one story at a time.
- Let the tasks in the story shape your workflow
- Set a timer so you remember to take breaks.
- Create a plan for what you will do if you get stuck.
At the end of everyday you should be asking yourself at plethora of questions. Did I achieve my goals? If yes or no, why? What can I do better tomorrow? What did I do well today? What is MVP?
By asking yourself questions similar to the questions above, you are mimicking a very powerful tool in the agile development processes called retroing. In retros we ask ourselves, what went well and what didn't go well. The point of a retro is not to assign blame but instead pick out the tools or processes that worked, find out why they worked, and ask if they are good enough to keep using. By setting goals every day and then reviewing those goals you are actively challenging yourself to find the gaps in your knowledge about how your app works, which will in turn change the scope of your work. You also should look at the things you did well and ask yourself, what is different here... How can I use that moving forward?
In the end these are things you will need to figure out for yourself. We learn by doing. This is meant to be a guide to help you along your way. Not bind you to my way of thinking. One of the most beautiful things about development is the opportunity to create something from nothing. Find your process, take risks, have fun, and if you pay attention you will things along the way. At the bottom I have attached a list of supplemental resources to help with some of the steps above. Happy coding 🤗 🤗 🤗.
- Story Board
- Example Board Tasks
- ERD Tool
- Pomodoro Timer Extension for Chrome