Set up a home source code repository (I use perforce), and check in changes frequently. It's tempting not to do this when you work alone, but even when you aren't worried about contention for source files, having a record of where you have been can be valuable.
Having the goal of getting to a checkin point every day will also help you to create micro-goals, which in turn will help you think about how you break the problem up into bite sized pieces.
For me the most important thing to do is remain disciplined. So if you plan to do TDD, do it and don't get tempted to cut corners. Always try and imagine a future for your project where you will have more than just you developing the code - so make it readable and logical. Name variables appropriately, comment (if that's your thing) where necessary. Use source control and check-in as you would on a team project.
Also, keep business value in mind - don't waste your time on stuff that won't add overall value to your system. Assuming you are also the business owner, try and put on your different hats and see the project from both standpoints. I wouldn't go as far as suggesting you talk to yourself, but do keep in mind your techical and business goals.
moleskin because its portable and I can read it on the go. i also use it as a diary.
microsoft excel because I can use it to track my project completion. i simply create a table listing all the TODOs and then add a column with project status (Not Started, In progress, completed, Deferred To next Iteration) and simply run totals on this field.
So far that has helped me stay on track. I can overcome my natural pride and let the data guide the development process.
On windows, i also use MS robocopy scripts to archive my code folders at regular intervals. (I have not fully mastered Subversion), there are tutorials for that online.
I work module by module too. i dont take the project as a whole but work with each section as a mini-application and use the above practices too.
As one facet of your process I don't think you can go wrong with writing user stories. I speak from experience, very recent experience; in fact, just this week. I had written a bit of code for my first serious Ruby/Rails effort, a personal project: see how to make my first Ruby effort more idiomatic
After digesting the answers I got, and before writing any more code, I found myself writing little paragraphs of maybe a sentence or two. And in some cases a few bullet points, but interestingly, I didn't set out to write user stories. I just thought that by writing down various things I wanted to do with the project, I'd further clarify things brought to light by my initial coding, and feedback received.
After a few paragraphs, I realized I was creating user stories. Now that I have them, I've written some more code, and have checked a few things off my list.
Never give up. Don't quit. Even when you think you can't do it by your self - don't quit. I built a 10 person company and for the first 18 months I worked all by my self. 3/4 of the code that was in the final product I had developed in that first 18 months. We got to our first 10 customers on that code. Don't quit.
Being a one-man web-design studio I use a Basecamp free account to organize to-do lists (a nice thing their tasks have comments, so when you solve some task you can comment it step by step for further reference). Messages and milestones are useful also. To keep track of the code (php, html, etc) I use Eclipse and its built-in CVS.
Note: I tried various project managers and version control systems, but all of them seem to be too functional for a single developer.
我发现遵循 TDD（测试驱动开发）并始终以几次失败的测试结束开发会话很有用。当我返回该项目时（可能只是几天后），我就有了一个合乎逻辑的起点。这可以帮助我更快地进入状态，而不是盯着 IDE 两个小时。
I find it useful to follow TDD (Test Driven Development) and always end a development session with a couple of failed tests. When I return to the project (which might only be after a couple of days) I have a logical starting point. This helps me get into the groove quicker rather than staring at my IDE for 2 hours.
发布评论
评论（9）
设置一个家庭源代码存储库（我使用perforce），并经常检查更改。当您独自工作时，很容易不这样做，但即使您不担心源文件的争用，记录您去过的地方也很有价值。
每天到达检查点的目标也将帮助您制定微观目标，这反过来又会帮助您思考如何将问题分解为小块。
Set up a home source code repository (I use perforce), and check in changes frequently. It's tempting not to do this when you work alone, but even when you aren't worried about contention for source files, having a record of where you have been can be valuable.
Having the goal of getting to a checkin point every day will also help you to create micro-goals, which in turn will help you think about how you break the problem up into bite sized pieces.
对我来说，最重要的事情就是保持纪律。因此，如果您打算进行 TDD，那就去做吧，不要试图走捷径。始终尝试想象您的项目的未来，您将不仅仅是开发代码 - 因此请使其具有可读性和逻辑性。适当地命名变量，必要时进行注释（如果这是你的事）。像在团队项目中一样使用源代码控制和签入。
另外，请牢记商业价值 - 不要将时间浪费在不会为系统增加整体价值的事情上。假设您也是企业主，请尝试扮演不同的角色，从两个角度看待该项目。我不会建议您自言自语，但请记住您的技术和业务目标。
所以基本上，做 XP 但不配对:-)
For me the most important thing to do is remain disciplined. So if you plan to do TDD, do it and don't get tempted to cut corners. Always try and imagine a future for your project where you will have more than just you developing the code - so make it readable and logical. Name variables appropriately, comment (if that's your thing) where necessary. Use source control and check-in as you would on a team project.
Also, keep business value in mind - don't waste your time on stuff that won't add overall value to your system. Assuming you are also the business owner, try and put on your different hats and see the project from both standpoints. I wouldn't go as far as suggesting you talk to yourself, but do keep in mind your techical and business goals.
So basically, do XP but without pairing :-)
我使用 Moleskin 和 Microsoft Excel。
Moleskin 因为它便于携带，我可以在旅途中阅读。我也用它作为日记。
microsoft excel，因为我可以用它来跟踪我的项目完成情况。我只是创建一个列出所有 TODO 的表，然后添加一个包含项目状态的列（未开始、进行中、已完成、推迟到下一次迭代），然后简单地在此字段上运行总计。
到目前为止，这帮助我保持在正轨上。我可以克服我天生的骄傲，让数据指导开发过程。
在 Windows 上，我还使用 MS robocopy 脚本定期归档我的代码文件夹。 （我还没有完全掌握 Subversion），网上有相关教程。
我也逐个模块地工作。我不会将项目视为一个整体，而是将每个部分作为一个小型应用程序进行工作，并使用上述实践。
I use my Moleskin and Microsoft excel.
moleskin because its portable and I can read it on the go. i also use it as a diary.
microsoft excel because I can use it to track my project completion. i simply create a table listing all the TODOs and then add a column with project status (Not Started, In progress, completed, Deferred To next Iteration) and simply run totals on this field.
So far that has helped me stay on track. I can overcome my natural pride and let the data guide the development process.
On windows, i also use MS robocopy scripts to archive my code folders at regular intervals. (I have not fully mastered Subversion), there are tutorials for that online.
I work module by module too. i dont take the project as a whole but work with each section as a mini-application and use the above practices too.
既然你正在修改你的项目，那么也要修改组织和方法。
通过尝试一切来找出最适合您的方法。实验。
Since you're tinkering on your project, tinker with organization and methodologies as well.
Find out what works best for you by trying everything. Experiment.
作为流程的一方面，我认为编写用户故事不会出错。我是根据经验说话的，是最近的经验；事实上，就在本周。我为我的第一个认真的 Ruby/Rails 工作（一个个人项目）编写了一些代码：请参阅 如何让我的第一个 Ruby 工作更加惯用
在消化了我得到的答案之后，在编写更多代码之前，我发现自己写了一些小段落，可能是一两句话。在某些情况下，有一些要点，但有趣的是，我并没有打算编写用户故事。我只是想，通过写下我想在该项目中做的各种事情，我可以进一步澄清我最初的编码和收到的反馈所揭示的事情。
几段之后，我意识到我正在创建用户故事。现在我已经有了它们，我已经编写了更多代码，并检查了我列表中的一些内容。
As one facet of your process I don't think you can go wrong with writing user stories. I speak from experience, very recent experience; in fact, just this week. I had written a bit of code for my first serious Ruby/Rails effort, a personal project: see how to make my first Ruby effort more idiomatic
After digesting the answers I got, and before writing any more code, I found myself writing little paragraphs of maybe a sentence or two. And in some cases a few bullet points, but interestingly, I didn't set out to write user stories. I just thought that by writing down various things I wanted to do with the project, I'd further clarify things brought to light by my initial coding, and feedback received.
After a few paragraphs, I realized I was creating user stories. Now that I have them, I've written some more code, and have checked a few things off my list.
永不放弃。不要放弃。即使您认为自己无法做到这一点，也不要放弃。我建立了一家 10 人的公司，前 18 个月我都是一个人工作。最终产品中 3/4 的代码是我在前 18 个月内开发的。我们通过该代码吸引了前 10 位客户。
不要放弃。
Never give up. Don't quit. Even when you think you can't do it by your self - don't quit. I built a 10 person company and for the first 18 months I worked all by my self. 3/4 of the code that was in the final product I had developed in that first 18 months. We got to our first 10 customers on that code.
Don't quit.
计划一些，然后工作一些
总是知道下一步是什么，并专注于记录
你所做的事情和原因，包括设计决策，这样你就不会原地踏步
plan some, then work some
always know what the next step is, and focus on that
keep a log/journal of what you did and why, including design decisions, so you don't go 'round in circles
作为一个单人网页设计工作室，我使用 Basecamp 免费帐户来组织待办事项列表（他们的任务有评论是件好事，所以当你解决某个任务时您可以逐步评论以供进一步参考）。消息和里程碑也很有用。为了跟踪代码（php、html 等），我使用 Eclipse 及其内置 CVS。
注意：我尝试了各种项目管理器和版本控制系统，但它们对于单个开发人员来说似乎都太实用了。
Being a one-man web-design studio I use a Basecamp free account to organize to-do lists (a nice thing their tasks have comments, so when you solve some task you can comment it step by step for further reference). Messages and milestones are useful also. To keep track of the code (php, html, etc) I use Eclipse and its built-in CVS.
Note: I tried various project managers and version control systems, but all of them seem to be too functional for a single developer.
我发现遵循 TDD（测试驱动开发）并始终以几次失败的测试结束开发会话很有用。当我返回该项目时（可能只是几天后），我就有了一个合乎逻辑的起点。这可以帮助我更快地进入状态，而不是盯着 IDE 两个小时。
I find it useful to follow TDD (Test Driven Development) and always end a development session with a couple of failed tests. When I return to the project (which might only be after a couple of days) I have a logical starting point. This helps me get into the groove quicker rather than staring at my IDE for 2 hours.