You haven't told us how much time you have for this, or the language you're working in (I would say a single class is very small, but perhaps in your language it's a good deal more).
First of all, have a working product at any cost.
If the project lasts two weeks or less, assume you will be the only one doing anything and be very happy about any help you get. Try to schedule things for everyone, but make sure that if nobody does anything, you'll still have a working product. Even if someone does something, don't rely on them continuing: be prepared for anyone to drop out at any point.
If you have more than one week, consider scheduling a day of the week when the product should be marked as a milestone and stick to that as much as possible. Make sure you have something you can kick around and check the deficiencies of: if worst comes to worst, this will be what you hand in. Each one you create, you will see how much you could improve things, which will motivate you to go on. Don't plan too far forwards: sure, you need to have an idea of what you'll end up with, but keep your most specific plans short-term.
Notice that those two overlap a little: this is intentional, as two weeks is in my opinion a bit of a grey area where getting two iterations done is hard, but only working in one iteration is risky.
I'm assuming the worst case, where you'll be working with people very new to programming. My general advice would be:
- Keep a list of features you want to implement soon, and who will work on them. Jarrod suggested Trello, and I entirely support that: if your teammates aren't very experienced, it'll help a lot. You could try keeping the bugs there, too.
- In a team of four, you need version control. It may make others more reluctant to contribute if they don't know how to work it, but it's worth it.
- Any external dependencies may scare away newbies. If you write unit tests, tell people that they shouldn't worry about breaking them. Tell people that they shouldn't worry about breaking the build, especially at first. It's much harder to correct people who don't commit any code than those who commit buggy code.
- Check whether things suggested here really apply to you. "Continuous integration" is a fancy term -- for a small program, that might mean "this program runs and all features can be used". Do you even have sites? Does splitting into teams help you?
- YAGNI, a hundred times over. If you really have to, write things in advance for features you'll be making yourself. Make it work, then refactor, or you won't get around to making it work.
- Refactor. Once it's working, spend some time fixing it. Don't forget your teammates will have to read your code, too: a day spent fixing ugly pieces and replacing simple solutions with better-performing ones is not a day wasted.
- Keep an eye on all parts. Skimming changelogs and occasionally reading others' code helps make sure that everything is up to the quality standards you feel you should enforce and makes sure it isn't as hard to dive in if the person drops out.
- Don't hesitate to work on the most important thing, as opposed to your designated thing. If someone is falling behind schedule, make a written note of that somewhere and do it yourself. Ask them first, but go ahead if they don't answer, or if you ask once or twice and then feel like they still won't do it.
- Focus on making something you're proud of. Even if it deviates from the assignment. Even if you have to cut big features in favour of making what you have more smooth. Every iteration think "Am I proud of this?", and in the next iteration, try to fix those things.
I had a project that failed horribly recently; you can read my thoughts on why it failed if you want to, but this summarises how I'd do something like this if I had another chance to.