自由职业者可以使用敏捷开发吗？

我想改善我开发软件的方式。我想开发更快的代码！今天，我使用瀑布方法作为自由职业者，编写Web东西（站点，系统等）。有没有办法使用以这种方式工作的敏捷开发（XP，SCRUM等）？我对敏捷开发一无所知，应该从哪里开始？非常感谢你。

...当然，除了配对编程。;-)

认真地说，我也是自由职业者，并且我会尽可能地使用敏捷技术。它对我很好。我大量使用TDD，

没有人在任何地方使用XP或Scrum的100％，但每个人都使用其中的一部分，并尝试尽可能多地采用XP或Scrum。我认为，您采用的越多，您的生活就越好。

我最想念的是结对编程。您克服的方式是

1. 参加许多用户组会议。
2. 找到几个值得您尊敬的开发人员。
3. 要求他们喝咖啡或写一些东西来见你。如果您认为有必要，或者偶尔以他们的实物作为对他们的守则的回应，请偶尔给他们一部分小时工资。
4. 像这样参加或创建一个Hack Club：http : //www.DallasHackClub.org。

这是我使用的一些资源：

• 极限编程 -在线快速而详尽的XP指南。
• 很棒的Scrum概述。
• 很棒的书。最适合您！

因此，我想说将敏捷用作自由职业者的三个主要“妙点”：

1. 对于较大的客户，迭代工作/计费。在迭代结束时，客户可以继续进行该项目的工作，也可以结束该项目（即：它已实现其目标）。我知道（根据经验）我无法估计超过几个星期的时间，而且按次付费还可以保持现金流的流入。在一个3个月的项目的第6个月并等待很有趣完成项目，以便您可以...

2. 敏捷意味着发生变化。我已经做了大量的固定竞标项目（您认为您可以使用瀑布进行），这些项目由于周期中的客户要求而使我赔了钱。发生了变化：客户可以降低机票的优先级，以便更快地完成其他工作，或者您可能预测错了，没有完成您希望的工作。

3. 良好的客户协作工具。我的标准估计（对于某些事情而言，要小于迭代的工作量）实际上是从客户期望中得出的一系列行为驱动开发步骤。我将其发送给客户并说“这是正确的吗？”。确保每个人都在同一页面上。

4. 最简单的方法可能会起作用。您在工作时要牢记一点：不要害怕回到客户那里说：“如果我们这样做的话，这将变得简单得多（或功能更强大，或任何其他功能）…… ”

5. Scrum很重要。我喜欢每天在客户项目上向客户发送电子邮件。这就像我对他们的争执：“我今天从事的工作”，“下一步什么时候去做他们的项目？”，“有什么事吗？”和“总体而言，进展如何？” ？

6. 即使是单个程序员，测试驱动的开发也非常有用。我的“其中带有BDD故事的估计”可以帮助我完成此过程。

开始敏捷之旅的一种好方法是使用KANBAN系统设置工作流程。

我们只有3条泳道：

1. 我们的待办事项或待办事项
2. 我们正在或正在进行的工作
3. 我们完成或完成的事情。

这个简单的敏捷工作流程是一个很好的起点。

在编码方面，我建议使用测试驱动开发（TDD）。我们在文章中包含了许多描述TDD的出色链接，但将在此处重新复制它们：

有关更多信息，请查看以下资源：

• AgileData.org-用于测试驱动开发的重要资源。
• JamesShore.com -TDD的另一个重大故障
• Net Tuts-我喜欢的有趣的TDD介绍！
• Artima-马丁·福勒访谈
• 内部游戏-TDD的一个很好的案例研究
• DaniWeb-开发人员的TDD简介
• 马克·李维森 -有关TDD的文章

由于您是个人，因此最好采用敏捷方法，以帮助您找出最适合自己的方法。他们在那里可以帮助您实现“没有汤匙”的平稳状态，但是到底要发生什么到底完全取决于您，而最终的结果将与各个层次上的某些方法学大相径庭，这完全是你的。

由于您试图找到一种自己的做事方式来提高整体效率，因此以下一些指针可以帮助您至少避免犯下与我相同的错误：

尽可能长时间地放弃专门针对敏捷方法的所有软件解决方案。

它们更适合于促进团队协作，这一点已不重要。抵制诱惑。您不要以做事的方式来包装自己，然后希望采用它会取得最佳效果。不会，只会让您感到沮丧。您首先要找到做事的方式，然后找到合适的软件解决方案。我最终使用白板（从一个开始，但是现在我的房间里有两个）来跟踪/开发故事和番茄操作技巧。“今天要做的事情”列表将跟踪我的开发任务以及2011年的发展情况。坚持基础知识，直到获得一些界面，例如Iron Man 2或飞行汽车中出现的那些界面。

反射反射反射

这就是我所理解的对个人而言是任何方法论中最重要的部分。它是关于开发此工作流的，它使您可以全面了解项目，以便可以轻松地管理需要完成的工作以及何时进行跟踪，以及在哪些地方很少做出错误决定并脱颖而出，以便快速进行修改。在它们造成任何损害之前...但是您不能随便从架子上取下来。从任何地方开始。只要它有效，您就坚持使用它。投资跟踪好坏，马马虎虎。改善您的假设，然后相应地调整做事方式。那是您要改进的唯一方法。

担心最后期限，专注于完成工作的速度

当我开始约会时，我可能就像下一个家伙一样。倦怠图表？我曾经将它们视为在截止日期之前可视化我的开发轨迹的一种方式。这是一种性能，而不是估计模型。通过反思在一定时间范围内所做的工作，可以用时间来衡量您的工作效率，而不仅仅是一些愚蠢的值来代表在限制截止日期之前的距离。现实情况是，事情完成后就完成了，您的方法应该考虑到这一点。

相应地偏离

最后，谁说您必须使用用户故事或我们所知道的任何东西？不要这样想 如果您对功能的思考更满意，那么就一定要挑战全球开发社区，并按自己的方式去做，因为最终要做好所有工作。如果您最终感觉自己在做错事，那么恭喜您-您刚刚得出结论，该是时候跳到其他事情了。这是关于什么的，而不是如何的。

我会回答“您想如何改进软件开发方式？”。对于您的业务模型，使用瀑布式方法遇到的最大问题是什么？

您的目标是更快的开发，更健壮的代码，更大的重用性，满足/适应不断变化的需求等吗？存在克服不同问题的不同方法。

当然，采用瀑布式以外的设计方法对根据您的业务需求有效管理项目生命周期非常有用。对于敏捷开发，在线上有大量资源。我将研究结合了TDD（测试驱动开发）的AUP（敏捷统一过程）。当构建/管理大型可伸缩系统时，这可能非常有用。

没有“一刀切”的方法，这就是大量不同方法的主要原因。我将开始考虑您当前在开发过程中遇到的瓶颈，然后尝试采用一种新的方法来克服这一问题。

例如，您经常不能按时完成任务吗？新功能会引入大量错误吗？新要求会导致重大重建吗？企业是否需要提供常规的工作系统？签出：敏捷，迭代和敏捷入门。