Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

I spend a lot of time working on projects in which I am the sole developer, project manager, designer, QT person (Yes, I know... Bad!), and sometimes I'm even the client.

I've tried just about everything for planning projects and managing myself, from just sitting and working freestyle until the project is done however long it takes, to a single-person version of scrum in which I held a progress meeting with myself over a one-man burn down chart every morning (not kidding).

For those of you who spend much time working alone, what is the best way to organize yourself, manage large (for one person) projects, and keep productivity as high as possible?

share|improve this question
    
I re-opened it. Duplicates are allowed in StackOverflow, and Eli may prefer a different answer than the one you did. –  torial Oct 21 '08 at 1:08
    
Thanks torial - I didn't know about the other Q, but am interested in seeing a few more answers. –  Eli Oct 21 '08 at 22:47
    
add comment

migrated from stackoverflow.com Mar 19 '11 at 2:19

This question came from our site for professional and enthusiast programmers.

marked as duplicate by gnat, MichaelT, Joris Timmermans, Jimmy Hoffa, Jalayn May 6 '13 at 15:24

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

7 Answers

Keeping a clear list of your goals is vital. It's easy for feature creep to take over a self-managed project. The TDD "it's done when it works" approach is helpful as well. This prevents you from becoming a perfectionist.

One thing that really helps me is to imagine what another engineer or a project manager would say in any given situation. Often I'm able to "shame myself" out of bad code, or get back on track if the schedule is slipping.

share|improve this answer
add comment

Here you go... http://xp.c2.com/ExtremeProgrammingForOne.html

XP scales down nicely since it is optimal for small focussed teams..

  • You can create a spreadsheet of feature requests, prioritize them & pick the top-most one.
  • define the acceptance criteria (what done looks like) and code it up into a executable test
  • Next define engineering tasks to get to done
  • Write unit tests, do the simplest thing (YAGNI) and refactor all the time. The goal is to make the outer acceptance test pass
  • Timebox each session. For effective time-management, you could also look at the Pomodoro technique.
  • Use version control & Setup a CI server / a batch file to create a install or zip of your software
  • Demo frequently. Route the feedback into the original spreadsheet and reprioritize

The only thing that you couldn't do in a team of one is PairProgramming.

share|improve this answer
add comment

I've rolled my own version of agile that relies on stories, heavy customer interaction, frequent releases, and test-driven development. I use a wiki to track stories, get the customer involved as much as possible in writing them, and have the customer work with me to prioritize and organize into releases. I use TDD to drive the design and implement. I set up a QA server where the customer can try out frequent releases (sometimes daily as new features are developed) so that I get feedback quickly. I rarely go more than 3 iterations without a release to QA. Customer gets to decide when the QA version has enough features to go live -- and if no more features off the list need to be developed.

share|improve this answer
add comment

i wish i could say i was able to practice what i preach 100% of the time, but BDD seems to be a good approach to take in your situation:

Here's a link with more info: http://en.wikipedia.org/wiki/Behavior_driven_development

share|improve this answer
add comment

I'm in a very similar boat. I try to follow agile principles (as well as I understand them) as much as possible. I'm probably not doing things "correctly", but I've had great success on my projects by trying to follow agile principles. It takes an enormous amount of discipline, since there's no team to make sure you don't just start taking shortcuts.

share|improve this answer
add comment

I suggest you the following:

  1. Test-Driven development
  2. Eavy use of "TODO: note here" in your code when you see something you are not able to do immediately, and come back to them when you have time instead to stay on facebook waiting for your client to call back
  3. Write your code as your client will buy it looking at the code not at only the result, imagine your client as the chairman for a code review.
  4. Fill your code of asserts
share|improve this answer
add comment

If it's throw away code might be able to be a little loosey-goosey with methodologies, but anything important and I'd say your way of treating it as team project with one person is very nice and disciplined.

Write your code for the next guy to read, not you...be nice to him/her. Even the "throw away" code stays around forever.

share|improve this answer
add comment