| There's a few different approaches to this: 1. Set a deadline and go for it. This can take up a lot of your time and make you feel burned out. I'm assuming you want to avoid this. 2. Assume it will take longer to release than you would like, but incrementally make progress each week. I am currently #2 after trying #1 with a completely new stack. I eventually decided that it's better to workout with my significant other a day of the week to work on the project. We decided Sunday would work best for us. If this is your case I really recommend you keep your time flexible and be willing to "swap" days or switch to 1 hr each day after work. Now that you established a schedule, you will need to maintain two lists. A short list is what you need to work on next. A long list is what you want to accomplish and release in the big scheme of things. With your two lists, you will prioritize. If you get hung up on something, is it really that necessary? Can you live without it until after your "release". Keep a rough estimate going, it will give you an ok timeline and help you further prioritize. This strategy has helped me a lot, I hope to release my side project at the end of this year. :) |
The simplest thing is to focus on scope, and make a checklist for when the project is "ready to ship". Add things as they come up, remove them, edit them, etc.
That kind of checklist is related to the "procedural" sort of checklist which is important also.
On top of that you can add practices such as "grouping projects into milestones", "estimating the effort involved in tasks", "forming a dependency tree between the tasks", "setting delivery dates for milestones", etc.
Checklisting is the basic practice. I was on the project from hell that we rescied where a real bully of a manager got us all, developers, testers, UX, ops, on a checklist -- I think estimates are a good thing but key people on the team would not play along so we did not do them.
It was not easy but we shipped.