Agile is a philosophy, not a prescription. You use the pieces that fit your development style, your project, and your business needs.
I think your "test often, write human-readable code" proposal is a perfectly suitable approach for making good software on a solo team for small projects.
You might want to look at c2.com's Solo Programming Xp Workarounds. Cardboard Programmer is one for some reason I found particularly amusing. You could perhaps code with a cardboard Jon Skeet next to you?
As for small personal projects, of course there are many things that would be overkill. Agile development, short iterations, frequent code review and self-documenting code is the way to go.
我目前正在独自开发一个 ASP.NET 项目（虽然不是一个小项目）。 我经常使用TDD，我发现使用TDD开发并不会花费更长的时间，事实上我还节省了时间。
这主要是因为拥有一套单元测试可以非常快速地测试和调试系统。 例如，当某个功能未按预期工作时，将调试器附加到 NUnit 进程比在调试模式下启动 Web 服务器、导航到正确的页面（首先通过登录屏幕）等要快得多因此，如果没有单元测试，我将花费更长的时间进行测试和调试。
单元测试还帮助我创建一个设计良好的系统，因为它迫使我创建一个更松散耦合的设计。
I'm currently working solo on an ASP.NET project (not a small one though). I use TDD quite a lot, and I find that it is not taking longer time to develop using TDD, in fact I save time.
This is primarily because having the suite of unit tests makes it very quick to both test and debug the system. E.g. when a feature is not working as intended, it is a lot quicker to attach the debugger to the NUnit process, than it is to start the web server in debug mode, navigating to the correct page (first passing the login screen), etc. So by not having the unit tests, I would spend a great deal longer testing and debugging.
And the unit tests also help me creating a well designed system, as it forces me to create a more loosely coupled design.
I would say the number of people working on the project isn't the only factor to consider. I think the reason you find the full Agile (documentation, refactoring, unit tests.......... these probably aren't really Agile though, they've been around for a long time) to be time-wasting is because solo projects tend to be small projects.
For larger projects that span across more than half a year, I would really expect proper process would really help yourself. You may visit some code you write 5 months earlier. Without documentation, it's the same as other people's work. Without tests, you are as scared to change it as changing other people's code.
发布评论
评论（5）
敏捷是一种哲学，而不是处方。您可以使用适合您的开发风格、项目和业务需求的部分。
我认为你的“经常测试，编写人类可读的代码”建议是一个非常适合在小型项目的独立团队中开发优秀软件的方法。
Agile is a philosophy, not a prescription. You use the pieces that fit your development style, your project, and your business needs.
I think your "test often, write human-readable code" proposal is a perfectly suitable approach for making good software on a solo team for small projects.
您可能需要查看 c2.com 的 Solo Programming Xp Workarounds。 Cardboard Programmer 出于某种原因我觉得特别有趣。 你也许可以用你旁边的纸板 Jon Skeet 来编码？
You might want to look at c2.com's Solo Programming Xp Workarounds. Cardboard Programmer is one for some reason I found particularly amusing. You could perhaps code with a cardboard Jon Skeet next to you?
牛仔编码和敏捷过程并不相同。
至于个人的小项目，当然有很多东西是大材小用的。 敏捷开发、短迭代、频繁的代码审查和自文档化代码是正确的出路。
Cowboy coding and agile process are not the same.
As for small personal projects, of course there are many things that would be overkill. Agile development, short iterations, frequent code review and self-documenting code is the way to go.
我目前正在独自开发一个 ASP.NET 项目（虽然不是一个小项目）。 我经常使用TDD，我发现使用TDD开发并不会花费更长的时间，事实上我还节省了时间。
这主要是因为拥有一套单元测试可以非常快速地测试和调试系统。 例如，当某个功能未按预期工作时，将调试器附加到 NUnit 进程比在调试模式下启动 Web 服务器、导航到正确的页面（首先通过登录屏幕）等要快得多因此，如果没有单元测试，我将花费更长的时间进行测试和调试。
单元测试还帮助我创建一个设计良好的系统，因为它迫使我创建一个更松散耦合的设计。
I'm currently working solo on an ASP.NET project (not a small one though). I use TDD quite a lot, and I find that it is not taking longer time to develop using TDD, in fact I save time.
This is primarily because having the suite of unit tests makes it very quick to both test and debug the system. E.g. when a feature is not working as intended, it is a lot quicker to attach the debugger to the NUnit process, than it is to start the web server in debug mode, navigating to the correct page (first passing the login screen), etc. So by not having the unit tests, I would spend a great deal longer testing and debugging.
And the unit tests also help me creating a well designed system, as it forces me to create a more loosely coupled design.
我想说，参与该项目的人数并不是唯一需要考虑的因素。 我认为您找到完整敏捷的原因（文档、重构、单元测试......这些可能并不是真正的敏捷，但它们已经存在很长时间了）时间）之所以浪费时间，是因为单独的项目往往都是小项目。
对于跨度超过半年的大型项目，我真的希望正确的流程能够真正帮助自己。 你可能会访问一些 5 个月前编写的代码。 没有文档，就和其他人的工作一样了。 如果没有测试，您就害怕更改它，就像更改其他人的代码一样。
I would say the number of people working on the project isn't the only factor to consider. I think the reason you find the full Agile (documentation, refactoring, unit tests.......... these probably aren't really Agile though, they've been around for a long time) to be time-wasting is because solo projects tend to be small projects.
For larger projects that span across more than half a year, I would really expect proper process would really help yourself. You may visit some code you write 5 months earlier. Without documentation, it's the same as other people's work. Without tests, you are as scared to change it as changing other people's code.