【发布时间】：2009-06-12 17:58:25
【问题描述】：
在了解了源代码控制之后，我做的第一件事就是用 svn 做一个项目。在了解了 git 之后，我在个人项目中使用了它。在了解了 UML/设计模式/设计原则/TDD 之后，我将它们应用到了个人项目中。我怎样才能对敏捷开发做同样的事情？敏捷仅适用于团队和大型项目吗？我如何设置这些迭代的东西？
【问题讨论】：
标签： agile
【发布时间】：2009-06-12 17:58:25
【问题描述】：
我认为敏捷绝对不仅仅适用于团队项目。敏捷倡导一套价值观，这些价值观同样适用于许多类型的项目，甚至是个人项目。前段时间我也遇到了你的情况，尝试将敏捷开发应用到个人大学项目中，并在此过程中学到了很多东西。敏捷思维方式可以为您提供的一些有用的东西包括：
致力于为最终产品增加价值的东西。让自己成为积压的功能，并像客户一样对它们进行优先级排序。然后根据功能对产品的价值而不是您现在想要做的事情来训练自己去处理功能。这可能会使您免于使用许多您不会使用的不必要的、过度设计的代码。如果你有最后期限，那就更重要了。
进行渐进式设计：从可能工作的最简单的事情开始，并无情地重构。
将决定推迟到最后负责任的时刻。
将自己的时间限制在冲刺或迭代中（在大学项目中非常重要）。
...
如果您再次回顾一些敏捷方法，我想您会发现很多可以自己应用的价值观和实践。
在撰写此答案时，至少有 3 个其他答案出现并击败了我。我同意所有这些。 :)
【讨论】：
-
你用什么大学项目试过这个。我想在我的第 4 年项目中执行此操作，可以在（8 到 16 个月）之间。
-
我的要小很多，只有几个月。我认为对于更长的项目，它实际上会更有价值。您可以做的一件好事是让某人扮演客户，并每两个月为他们提供一个“发布演示”；这会迫使你进入一种严肃的、客户价值的心态，你会及早得到反馈。也许你可以让另一个学生为你扮演客户，并回报你的青睐——最终你们都会从中受益。
-
好主意！还有将决定推迟到最后一个合理的时刻是什么意思。直到冲刺结束吗？
-
不一定。最后一个负责任的时刻是最后一次未能做出决定，从而消除了重要的替代方案。基本上，它的意思是“在不影响您的选择的情况下尽可能晚地做出决定”。见这里：codinghorror.com/blog/archives/000705.html
列出您希望在应用程序中使用的任务和功能。完成这些任务并将它们发送到card wall。
你不能一个人开会，但在早上决定你今天要做什么以及你昨天成功做了什么。接受这些任务，完成它们，然后进行下一个。确保在每一点交付持续集成的工作软件，并更新积压工作。你可能有“bug bash days”，你只是修复错误。那将是一个人的scrum。 :)
【讨论】：
-
是一种为故事制作卡片的方法吗？ TDD？设计和架构是在哪里完成的？
-
对于单人项目，我会说功能驱动。在您知道要构建什么功能后，设计就完成了。
很难将敏捷编码真正应用到单人项目中，因为它的许多好处都针对小型团队，您可以在这些团队中快速在重点领域进行协作。
也就是说，您可以采用一些技巧：
- 经常发布
- 关注用户需求
- 随意偏离主要版本计划 - 您可以随时改变方向
- 花更少的时间设置主要框架并尽快工作。然后返回并重构以满足您最初的需求（如果它们仍然适用）
【讨论】：
-
许多独立开发人员可能无论如何都遵循敏捷技术，因为他们没有其他人的负担，这取决于他们的代码结构每天看起来都一样。最大的区别是在项目开始时。您仍然需要计划事情，但让某事尽快工作比其他方法（即瀑布）更关注
除了结对开发之外，如果您愿意扮演多个角色，您可以进行其余的练习。如果你有愿意和你一起工作的人，你也可以做结对开发。
首先，您将构建产品待办列表。这将是您希望开发的功能或故事卡的优先列表。任何卡片都不应该比您在一次迭代或冲刺中可以完成的工作大。如果您的 sprint 是一两个星期，这将决定您的优先产品 backlog 中功能或故事卡的大小。作为产品负责人，您可以更改每次迭代的产品待办事项的优先级。从产品待办列表中，您可以构建您的迭代和发布计划。
由于您要扮演多个角色，因此您需要留出时间来创作故事卡。故事卡应该勾勒出 GUI，描述主要和次要工作流程，最重要的是要有验收标准。
一旦您签署书面故事卡，您就可以开始在卡上进行开发。您将使用 TDD（测试驱动开发）先编写测试，然后再编写代码。你会重复，直到卡片完成。验收标准将帮助您决定要编写哪些单元测试。
卡的开发完成后，您将编写自动化功能测试。您可以使用 Quick Test Pro、FIT、Cucumber 或其他一些喜欢的自动化单元测试工具。我会远离任何播放和录制功能，因为这会在您重构时推动未来的返工。
一旦单元测试完成并且卡通过，它可以添加到所有其他自动化功能测试中，并且可以至少每天运行一次，如果不是每次签到。
在迭代结束和将工作软件投入生产之前，您可以执行用户验收测试。
作为开发人员，您应该使用持续集成，每次频繁签入源代码控制系统都会启动自动化构建。
在编写故事卡之后，在为迭代开发卡片之前，您可以将它们分配出去（即，为开发卡片所需的每项任务提供估计）。您可以确定是否可以在您的估计范围内完成任何所需的重构，或者您是否需要创建一个新的故事卡来捕获您确定的技术债务。
如您所见，您可以将单个成员的敏捷团队带到很远的地方。鉴于敏捷管理实践有助于协作并确定什么是重要的，您也可以从这些实践中受益。鉴于工程 (XP) 实践使代码能够保持健康，从而支持可持续发展速度，您的代码将保持灵活性，包含强大的单元和功能自动化测试工具，并允许您无限期地以可持续发展速度继续开发。
【讨论】：
可以将 Scrum 用于单人项目。
- 创建积压工作
- 一个冲刺的最佳时间是半天
周五制定下周计划，每半天更新每个项目的燃尽图。
【讨论】：
例如，不要害怕重构自己的代码，即使它有效，只要结果更灵活和健壮。
【讨论】：
-
所以我在迭代中重构？还是我先开发一些功能然后对其进行迭代然后继续？
-
对您的代码进行单元测试。 然后接受 kmarsh 的建议并重构。对特定卡的估算通常会考虑到重构新功能所涉及的代码区域所需的时间。
对此的一些想法：
- 迭代只要您愿意就可以了
- IPM 仍然可以让您在这段时间内选择您想做的事情
- 最后的演示仍然有助于以某种专业的方式查看工作功能，而不是您自己的小调试区域可能不那么干净或有序
- 回顾仍然有助于了解什么对自己有用，什么对自己没有用，在某种意义上，你可以看到森林中的树木
IMO 很有可能在个人单人项目中实现敏捷。
【讨论】：
这里的所有建议都很好，但是敏捷的一个重要方面通常没有被提及：监控。
Agile 要求您查看您已完成的工作、正在做的工作、要去的地方，并在需要时进行适当的路线修正。
我认为 Big Visible 图表和 Burndown/Burnup 图表非常有用，我编写了一个程序 Task Analytics 来轻松制作这些图表。它非常适合小型或单人项目。
祝你好运。
【讨论】：
-
不错的项目。 ...我不使用前景...对不起。看起来不错，不过我会构建类似的东西并希望将其开源给其他人。