I think Agile is definitely not just for team projects. Agile advocates a set of values that apply equally well to many types of projects, even personal ones. I was in exactly your situation a while ago, trying to apply agile development to a personal university project, and learned a lot in the process. Some useful things that the agile mindset can give you include:
Work on stuff that adds value to the final product. Make yourself a backlog of features and prioritize them as though you were the customer. Then discipline yourself to work on features based on their value to the product rather than what you want to do right now. This might save you from a lot of unnecessary, over-designed code that you won't use. If you have a deadline, it's even more important.
Have an evolutionary design: start with The Simplest Thing That Could Possibly Work and Refactor Mercilessly.
Postpone decisions until the Last Responsible Moment.
Timebox yourself into sprints or iterations (VERY important on university projects).
...
If you go over some of the agile methodologies again, I think you'll find plenty of values and practices that you could apply by yourself.
While writing this answer, at least 3 other answers came up and beat me to it. I agree with all of them. :)
Make list of tasks and features that you want in your application. Take those tasks and put them on a card wall.
You can't really have a meeting by yourself, but in the morning decide what you will do for the day and what you successfully did yesterday. Take those tasks, do them and then move to the next. Make sure at every point you are delivering continuously integrated, working software and you update your backlog. You might have "bug bash days" where you just fix bugs. That would be a one man scrum. :)
It's hard to truly apply agile coding to one-man projects because many of its benefits are aimed at small teams where you can quickly collaborate on focussed areas.
That said, you can adopt some of the techniques:
Release often
Focus on your users' needs
Feel free to deviate from major version plans - you can change direction whenever you feel the need
Spend less time in setting up major frameworks and get something working as soon as possible. Then go back and refactor to accomplish your original needs (if they still apply)
Other than pair developing, you can do the remainder of the practices if you are willing to play multiple roles. If you have someone who is willing to work with you, you can also do pair developing.
First you would build a product backlog. This would be a prioritized list of features or story cards you wish to develop. No card should be bigger than the work you can complete in a single iteration or sprint. If your sprints are a week or two, that will determine the size of the features or story cards on your prioritized product backlog. As the product owner, you can change the priority of the product backlog for each iteration. From the product backlog, you could build your iteration and release plans.
Since you are playing multiple roles, you will need to allow time for you to author the story card. The story card should sketch the GUI, describe the primary and secondary workflows and most importantly have acceptance criteria.
Once you sign off the written story card, you can begin development on the card. You would use TDD (test driven development) to write the test first, then the code. You would repeat until the card is done. The acceptance criteria would help you decide what unit tests to write.
Once the developed of the card is done, you would write the automated functional tests. You could use Quick Test Pro, FIT, Cucumber or some other favorite automated unit test tool. I would stay away from any play and record features as that can drive up rework in the future as you refactor.
Once the unit test is completed and the card passes, it can be added to all other automated functional test and can be run at least daily if not at every check in.
At the end of the iteration and prior to moving your working software to production, you can perform the User Acceptance Testing.
As the developer you should use continuous integration, automated builds kicked off with each of the frequent check in to your source code control system.
After the story card has been written and prior to developing the cards for the iteration, you can task them out (i.e,. provide estimates for each of the tasks required to develop the card). You can determine if any refactoring needed can be completed within your estimate or if you need to create a new story card that captures the technical debt you identified.
As you can see, you can take a single member agile team very far. Given that the agile management practices help collaboration and identify what is important, you can benefit from those practices also. Given that the engineering (XP) practices enable the code to remain healthy thus supports sustainable pace, you code will remain flexible, contain a strong unit and functional automated test harness and allow you to continue development at a sustainable pace indefinitely.
IPMs are still possible where you pick what you want to do over that length of time
Demos at the end are still useful to see working functionality in a somewhat professional manner rather than your own little debugging area that may not be as clean or orderly
Retrospectives are still useful to see what is and isn't working for yourself at a point where you can see the forest for the trees in a sense
It is quite possible to be Agile in a personal one-man project, IMO.
All of the advice here is good, but there is one important aspects of Agile that usually goes unmentioned: monitoring.
Agile asks you to take a look at what you have done, what you are doing, where you are going, and make appropriate course corrections if needed.
I think Big Visible charts and Burndown/Burnup charts are so useful, I wrote a program, Task Analytics, to make these charts easily. It's perfect for small or one man projects.
发布评论
评论（8）
我认为敏捷绝对不仅仅适用于团队项目。 敏捷倡导一套同样适用于多种类型项目（甚至个人项目）的价值观。 前段时间我也遇到了你的情况，尝试将敏捷开发应用到个人大学项目中，并在这个过程中学到了很多东西。 敏捷思维可以为您提供一些有用的东西，包括：
致力于为最终产品增加价值的事情。 为自己创建一个待办事项列表，并像客户一样对它们进行优先排序。 然后训练自己根据功能对产品的价值而不是你现在想做的事情来开发功能。 这可能会让您避免使用许多不必要的、过度设计的代码。 如果您有截止日期，那就更重要了。
采用渐进式设计：从可能有效的最简单的事情开始，然后毫不留情地进行重构。
将决策推迟到最后的责任时刻。
为自己安排冲刺或迭代的时间（对于大学项目非常重要）。
为
...
如果您再次回顾一些敏捷方法，我认为您会发现大量可以自己应用的价值观和实践。
在写这个答案时，至少有 3 个其他答案出现了，让我无法回答。 我同意他们所有人的观点。 :)
I think Agile is definitely not just for team projects. Agile advocates a set of values that apply equally well to many types of projects, even personal ones. I was in exactly your situation a while ago, trying to apply agile development to a personal university project, and learned a lot in the process. Some useful things that the agile mindset can give you include:
Work on stuff that adds value to the final product. Make yourself a backlog of features and prioritize them as though you were the customer. Then discipline yourself to work on features based on their value to the product rather than what you want to do right now. This might save you from a lot of unnecessary, over-designed code that you won't use. If you have a deadline, it's even more important.
Have an evolutionary design: start with The Simplest Thing That Could Possibly Work and Refactor Mercilessly.
Postpone decisions until the Last Responsible Moment.
Timebox yourself into sprints or iterations (VERY important on university projects).
...
If you go over some of the agile methodologies again, I think you'll find plenty of values and practices that you could apply by yourself.
While writing this answer, at least 3 other answers came up and beat me to it. I agree with all of them. :)
列出您希望在应用程序中使用的任务和功能。 将这些任务放在卡片墙上。
你不可能真正独自开会，但在早上决定你今天要做什么以及你昨天成功完成的事情。 接受这些任务，完成它们，然后继续下一个任务。 确保您在每个时刻都提供持续集成的、可工作的软件，并更新您的积压工作。 您可能会有“bug bash days”，您只是修复错误。 那将是一场单人争吵。 :)
Make list of tasks and features that you want in your application. Take those tasks and put them on a card wall.
You can't really have a meeting by yourself, but in the morning decide what you will do for the day and what you successfully did yesterday. Take those tasks, do them and then move to the next. Make sure at every point you are delivering continuously integrated, working software and you update your backlog. You might have "bug bash days" where you just fix bugs. That would be a one man scrum. :)
很难真正将敏捷编码应用于单人项目，因为它的许多好处都是针对小型团队的，在这些团队中，您可以在重点领域快速协作。
也就是说，您可以采用一些技术：
It's hard to truly apply agile coding to one-man projects because many of its benefits are aimed at small teams where you can quickly collaborate on focussed areas.
That said, you can adopt some of the techniques:
除了结对开发之外，如果您愿意扮演多个角色，您可以完成其余的练习。 如果有人愿意和你一起工作，你也可以进行结对发展。
首先，您将建立一个产品待办事项列表。 这将是您希望开发的功能或故事卡的优先列表。 任何卡片都不应该大于您在单次迭代或冲刺中可以完成的工作。 如果您的冲刺是一两周，这将决定优先产品待办事项中的功能或故事卡的大小。 作为产品负责人，您可以更改每次迭代的产品待办事项的优先级。 根据产品待办事项列表，您可以制定迭代和发布计划。
由于您扮演多个角色，因此您需要留出时间来创作故事卡。 故事卡应勾画 GUI，描述主要和次要工作流程，最重要的是具有验收标准。
一旦您签署了书面故事卡，您就可以开始在卡上进行开发。 您将使用 TDD（测试驱动开发）首先编写测试，然后编写代码。 你会重复直到卡片完成。 验收标准将帮助您决定要编写哪些单元测试。
卡的开发完成后，您将编写自动化功能测试。 您可以使用 Quick Test Pro、FIT、Cucumber 或其他一些喜欢的自动化单元测试工具。 我会远离任何播放和录制功能，因为这可能会在将来重构时增加返工。
一旦单元测试完成并且卡通过，它就可以添加到所有其他自动化功能测试中，并且可以至少每天运行（如果不是每次签入）。
在迭代结束时和将工作软件转移到生产之前，您可以执行用户验收测试。
作为开发人员，您应该使用持续集成，自动构建随着每次频繁签入源代码控制系统而启动。
在编写故事卡之后，在为迭代开发卡片之前，您可以为它们分配任务（即，为开发卡片所需的每项任务提供估计）。 您可以确定是否可以在您的估计范围内完成所需的任何重构，或者是否需要创建一个新的故事卡来捕获您确定的技术债务。
正如您所看到的，您可以让单个成员敏捷团队走得很远。 鉴于敏捷管理实践有助于协作并确定重要内容，您也可以从这些实践中受益。 鉴于工程 (XP) 实践使代码能够保持健康，从而支持可持续的步伐，您的代码将保持灵活性，包含强大的单元和功能性自动化测试工具，并允许您无限期地以可持续的步伐继续开发。
Other than pair developing, you can do the remainder of the practices if you are willing to play multiple roles. If you have someone who is willing to work with you, you can also do pair developing.
First you would build a product backlog. This would be a prioritized list of features or story cards you wish to develop. No card should be bigger than the work you can complete in a single iteration or sprint. If your sprints are a week or two, that will determine the size of the features or story cards on your prioritized product backlog. As the product owner, you can change the priority of the product backlog for each iteration. From the product backlog, you could build your iteration and release plans.
Since you are playing multiple roles, you will need to allow time for you to author the story card. The story card should sketch the GUI, describe the primary and secondary workflows and most importantly have acceptance criteria.
Once you sign off the written story card, you can begin development on the card. You would use TDD (test driven development) to write the test first, then the code. You would repeat until the card is done. The acceptance criteria would help you decide what unit tests to write.
Once the developed of the card is done, you would write the automated functional tests. You could use Quick Test Pro, FIT, Cucumber or some other favorite automated unit test tool. I would stay away from any play and record features as that can drive up rework in the future as you refactor.
Once the unit test is completed and the card passes, it can be added to all other automated functional test and can be run at least daily if not at every check in.
At the end of the iteration and prior to moving your working software to production, you can perform the User Acceptance Testing.
As the developer you should use continuous integration, automated builds kicked off with each of the frequent check in to your source code control system.
After the story card has been written and prior to developing the cards for the iteration, you can task them out (i.e,. provide estimates for each of the tasks required to develop the card). You can determine if any refactoring needed can be completed within your estimate or if you need to create a new story card that captures the technical debt you identified.
As you can see, you can take a single member agile team very far. Given that the agile management practices help collaboration and identify what is important, you can benefit from those practices also. Given that the engineering (XP) practices enable the code to remain healthy thus supports sustainable pace, you code will remain flexible, contain a strong unit and functional automated test harness and allow you to continue development at a sustainable pace indefinitely.
可以将 Scrum 用于单人项目。
在周五创建下周的计划，每半天更新每个项目的燃尽图。
Is possible to use Scrum for one man projects.
At Friday create plan for next week and every half day update burndowns for each projects.
例如，如果结果更加灵活和健壮，不要害怕重构自己的代码，即使它有效。
For example, don't be afraid to refactor your own code, even if it works, if the result is more flexible and robust.
对此有一些想法：
这是很有可能的。在个人单人项目中保持敏捷，IMO。
A few thoughts on this:
It is quite possible to be Agile in a personal one-man project, IMO.
这里的所有建议都很好，但是敏捷的一个重要方面通常被忽视：监控。
敏捷要求你看看你已经做了什么、正在做什么、要去哪里，并在需要时进行适当的修正。
我认为大可见图表和燃尽图/燃尽图非常有用，我编写了一个程序，任务分析 ，轻松制作这些图表。 它非常适合小型或单人项目。
祝你好运。
All of the advice here is good, but there is one important aspects of Agile that usually goes unmentioned: monitoring.
Agile asks you to take a look at what you have done, what you are doing, where you are going, and make appropriate course corrections if needed.
I think Big Visible charts and Burndown/Burnup charts are so useful, I wrote a program, Task Analytics, to make these charts easily. It's perfect for small or one man projects.
Good luck.