How do you plan and manage YOUR projects?

Discussion in 'The Common Room' started by Bemoliph, Aug 20, 2015.

  1. Bemoliph

    Bemoliph High Priest Staff Member

    Messages:
    35
    Likes Received:
    14
    For those who have worked on non-trivial projects, what processes and tools have you actually used and would recommend? This is mostly regarding small (online) team projects, but huge or solo projects would be fun to hear from too. I'm less interested in theoreticals or impractical ideals and more asking about stuff you have experience with that works for you.

    @Tigers and I are thinking of promoting our casual game project from Prototype to Game You Can Play, but I'm worried we'll end up with messy code again for lack of sufficient planning and maintenance. The particulars I worry about are:
    • How can we cleanly plan the concept and where should we keep those designs? Is just writing ideas on GitHub wiki good enough, or are there better ways?
    • What can we do to avoid writing the dreaded Mega Design Document? We don't want to waste time or "lose" features in swaths of prose.
    • What's a good way to plan the basic architecture? I kinda want to commit key stubs as part of the planning, but how can we get to that point confidently?
    • How far ahead/detailed should we plan? I realize wholly upfront plans are bad since things change, but I don't want to constantly shoehorn or rewrite the whole project either.
    • How often should we do code reviews or mass cleanup efforts?
    • What common "gotchas" have you seen that we should watch out for?
    I know this is a very vague, open-ended question, but most things I've read go full underpants gnome when it comes to actual process. Even a few small tricks to keep us on track would be awesome.
     
    Last edited: Aug 20, 2015
  2. Elf

    Elf Immortal Staff Member

    Messages:
    105
    Likes Received:
    6
    Location:
    Clark County, WA
    I find for teams working on only one or two projects Agile methodology works okay and answers a lot of those questions for you. I am sure you have heard about it before. Sprint cycles, goal setting, etc. Your planning duration would be the sprint.

    The one place it can be sort of deficient is in having a well planned architecture that can accommodate features that might be a few sprints down the road. Generally I will have an architecture in mind for a project well before development gets underway, though.

    For concept and architectural planning generally I just have stuff free form in a wiki and with system diagrams. I have seen a lot of process based stuff like having everything in user stories, etc. Maybe that helps on larger teams, but I have always found it kind of silly. ("After a hard day's work, the user wants to exit the application [...]")

    I would have basic project management tools in place to resource people and track high level tasks. You could also use something like Jira in accordance with various Agile methodologies depending on how deeply you want to get into that.

    I doubt anyone could come up with a set interval for refactoring code. That really depends on the point in time quality of the codebase and how well your planning worked out; right?

    I think for your project which is rather small, you are getting too heavy on the process side. I would agree on an overall architecture, on interfaces between the parts, divvy up the work and then peer review each others' code.
     
    Last edited: Aug 20, 2015
  3. Bemoliph

    Bemoliph High Priest Staff Member

    Messages:
    35
    Likes Received:
    14
    Thanks for the reply.

    We were (and are) also worried about getting too process-heavy, which was part of how we ended up this way. I don't want to massively bureaucratize, just tighten up some areas we can improve.

    I've heard of Agile before. We even tried the stories thing, but didn't really stick with it. I could definitely do with more reading, but maybe we should just run with select basics like "here's the big list of stuff we want eventually, pick a thing", "talk about what you're doing and ask for help", etc?

    What I'm thinking we can try is:
    1. Summarize/expand IRC sessions about what we want for the game on GitHub wiki.
    2. Draw some diagrams and write some notes about architecture also on GitHub wiki.
    3. Extract a "task list" as issues on GitHub issue tracker.
    4. Tag a bunch of related issues as part of a milestone and hack away.
    5. Release awesome and start over!
     
  4. Elf

    Elf Immortal Staff Member

    Messages:
    105
    Likes Received:
    6
    Location:
    Clark County, WA
    This is sort of the electronic equivalent of the "daily stand-up meetings" common in Agile-type processes, which is definitely one part of the process that I do find works well. Main highlights are: meet and set your goals at the start of the sprint, do a stand-up meeting / check-in every day work is performed listing done/next/blocking, and then mark the goals as complete/failed/moved by the end of the sprint.