在了解源代码控制之后，我做的第一件事就是用svn做一个项目。在了解了git后，我在个人项目中使用了它。在了解了UML /设计模式/设计原则/ TDD之后，我将它们应用到了个人项目中。如何才能对敏捷开发做同样的事情？敏捷只针对团队和大项目吗？如何设置这些迭代的东西？
答案 0 :(得分：16)
我认为敏捷绝对不仅仅适用于团队项目。敏捷倡导的一系列价值观同样适用于许多类型的项目，甚至是个人项目。我不久前就是你的情况，试图将敏捷开发应用到个人大学项目中，并在此过程中学到了很多东西。敏捷思维可以为您提供的一些有用的东西包括：
处理能够为最终产品增加价值的东西。使自己成为积压的功能并优先考虑它们，就好像您是客户一样。然后根据自己对产品的价值而不是现在想要做的事情来训练自己处理功能。这可能会使您免于许多不必要的，过度设计的代码，而您将不会使用这些代码。如果你有截止日期，那就更重要了。
有一个进化设计：从可能可行的最简单的事情开始，并且无情地重构。
将决定推迟到最后一个负责任的时刻。
Timebox自己进入冲刺或迭代（在大学项目中非常重要）。
...
如果你再次讨论一些敏捷方法，我认为你会发现很多你可以自己应用的价值观和实践。
在写这个答案的时候，至少有3个答案出现了并且打败了我。我同意他们所有人的观点。 ：）
答案 1 :(得分：3)
列出您在应用程序中需要的任务和功能。完成这些任务并将它们放在card wall上。
你真的不能自己开会，但是在早上决定你将要做什么，以及你昨天成功做了什么。执行这些任务，执行它们然后转到下一个任务。确保在每个点上提供持续集成的工作软件，并更新您的待办事项。你可能有“bug bash days”，你只需要修复bug。这将是一个人的混乱。 ：）
答案 2 :(得分：2)
很难将敏捷编码真正应用于单人项目，因为它的许多好处都针对的是小型团队，您可以在这些团队中快速协作关注焦点区域。
那就是说，你可以采用一些技巧：
答案 3 :(得分：2)
除了成对开发之外，如果您愿意扮演多个角色，则可以执行其余的练习。如果您有愿意与您合作的人，您也可以进行配对开发。
首先，您要构建产品待办事项。这将是您希望开发的功能或故事卡的优先列表。没有卡应该比您在单次迭代或冲刺中完成的工作更大。如果您的冲刺是一周或两周，这将决定您的优先产品积压上的功能或故事卡的大小。作为产品所有者，您可以更改每次迭代的产品积压的优先级。从产品待办事项中，您可以构建迭代和发布计划。
由于您正在扮演多个角色，因此您需要有时间创作故事卡。故事卡应该绘制GUI，描述主要和次要工作流程，最重要的是具有验收标准。
一旦您签署书面故事卡，您就可以开始在卡片上进行开发。您将使用TDD（测试驱动开发）首先编写测试，然后编写代码。你会重复，直到卡完成。验收标准将帮助您确定要编写的单元测试。
完成卡的开发后，您将编写自动功能测试。您可以使用Quick Test Pro，FIT，Cucumber或其他一些喜爱的自动单元测试工具。我会远离任何播放和录制功能，因为在您重构时可能会在将来推动返工。
完成单元测试并且卡片通过后，可以将其添加到所有其他自动功能测试中，如果不是每次办理登机手续，都可以至少每天运行。
在迭代结束时以及将工作软件转移到生产环境之前，您可以执行用户验收测试。
作为开发人员，您应该使用持续集成，每次频繁检入源代码控制系统都会启动自动化构建。
在编写故事卡之后，在开发迭代卡之前，您可以将它们任务（即，提供开发卡所需的每个任务的估计值）。您可以确定是否可以在您的估算中完成所需的任何重构，或者您是否需要创建一个新的故事卡来捕获您确定的技术债务。
正如您所看到的，您可以将一个成员敏捷团队带到目前为止。鉴于敏捷管理实践有助于协作并确定重要内容，您也可以从这些实践中受益。鉴于工程（XP）实践使代码保持健康，从而支持可持续的步伐，您的代码将保持灵活性，包含强大的单元和功能自动化测试工具，并允许您无限期地以可持续的速度继续开发。
答案 4 :(得分：1)
可以将Scrum用于一个人项目。
周五创建下周和每半天的计划，为每个项目更新燃烧。
答案 5 :(得分：0)
例如，如果结果更灵活，更健壮，不要害怕重构自己的代码，即使它有效。
答案 6 :(得分：0)
对此有一些想法：
在IMO的个人独立项目中很有可能成为敏捷。
答案 7 :(得分：0)
这里的所有建议都很好，但敏捷的一个重要方面通常是未提及的：监控。
敏捷要求您查看您的工作，您在做什么，您要去哪里，并在必要时进行适当的课程更正。
我认为Big Visible图表和Burndown / Burnup图表非常有用，我编写了一个程序Task Analytics来轻松制作这些图表。它非常适合小型或单人项目。
祝你好运。