我在很多项目上花费了大量时间，在这些项目中，我是唯一的开发人员，项目经理，设计师，QT人员（是的，我知道...很糟糕！），有时甚至是客户。

我已经尝试了几乎所有用于计划项目和管理自己的事情，从坐下来自由工作直到项目完成（无论花费多长时间），再到单人版的Scrum，我在其中与自己举行了一次进度会议。每天早上烧毁图表（不是在开玩笑）。

对于那些花费大量时间独自工作的人，什么是组织自己，管理大型（一个人）项目并保持尽可能高的生产率的最佳方法？

明确列出您的目标至关重要。特征爬取很容易接管一个自我管理的项目。TDD“在工作时完成”的方法也很有帮助。这样可以防止您成为完美主义者。

真正帮助我的一件事是想象在任何给定情况下其他工程师或项目经理会说些什么。通常，我可以摆脱不良代码而感到羞耻，如果日程安排不顺，我也可以回到正轨。

在这里，您可以... http://xp.c2.com/ExtremeProgrammingForOne.html

XP可以很好地缩小，因为它是针对小型团队的最佳选择。

• 您可以创建一个包含功能请求的电子表格，对其进行优先排序并选择最重要的一个。
• 定义验收标准（看起来像什么）并将其编码为可执行测试
• 接下来定义要完成的工程任务
• 编写单元测试，做最简单的事情（YAGNI）并一直重构。目的是使外部验收测试通过
• 每个会话都有时间框。为了有效地进行时间管理，您还可以查看Pomodoro技术。
• 使用版本控制和设置CI服务器/批处理文件来创建软件的安装或zip
• 经常演示。将反馈路由到原始电子表格中并重新确定优先级

在一个团队中，您唯一无法做的就是PairProgramming。

如果您是独自工作。以下是建议：

1. 尽可能少地做底层工作。使用尽可能多的库和工具，包括您认为可以轻松编写代码的内容（不要这样做，只需使用该库）。
2. 采用自上而下的方法。只编写您真正需要的东西。
3. 当您抽象地看到问题时，请在google上搜索并使用已经证明的学术界的研究论文。您只需要编码他们的算法。
4. 设计系统，以便您可以尽可能自由地进行更改。（包括从此处复制并粘贴一些代码）。目的是在您发现自己犯错时节省您的时间。尽量减少犯错时必须丢掉的工作量。必须丢掉的一段代码（而不是从此处到那里进行复制粘贴）等同于您失去编写该代码的时间。
5. 有很多自动化测试，因此您每次进行更改时都可以定期进行回归测试
6. 分开设计的职责（即减少耦合）。使事物尽可能模块化
7. 使用调试器进行调试，并使用二进制搜索来查找缺陷。
8. 不断重构代码，以减少（显式）耦合和公共方法暴露（隐式耦合）。
9. 真的没什么。这是为了防止我可以提出新的：P

代码审查。

这些功能特别有用，因为您将向没有在同一项目上工作过的人解释代码，这样他们就不会对您的工作方式有任何假设。

他们还将获得在公司范围内共享知识的额外好处，因此，当其他人不得不在项目上工作时（由于人们在其他地方很忙，生病，辞职或被解雇），他们不必从头开始。 。

我已经发布了自己的敏捷版本，该版本依赖于故事，大量的客户互动，频繁的发布以及测试驱动的开发。我使用Wiki跟踪故事，让客户尽可能多地参与编写故事，并让客户与我一起确定优先顺序并组织发布。我使用TDD来驱动设计和实现。我设置了一个质量检查服务器，客户可以在其中试用频繁发布的版本（有时会在开发新功能时每天进行试用），以便快速获得反馈。如果没有发布质量检查，我很少会进行3次以上的迭代。客户可以决定质量检查版本何时具有足够的功能以投入使用-以及是否需要开发列表中没有的其他功能。

在我公司，我们团队都在同一个项目上工作，但是工作相对独立。我们在这里要做的一件事是，当您在做某事时似乎有些棘手，或者您在前进的道路上有多种实现某件事的方式，您会抓住其他人，并在讨论正反之前你继续。如果您等到代码完成审查后再进行检查，通常就已经花了太多时间来考虑主要的体系结构更改，尽管在代码审查中肯定会发现很多缺陷。

另外，我意识到“测试驱动开发”最近有点流行，但是对于单独的开发人员来说可以提供很大的帮助，因为它可以在进行过程中提供质量检查，并且当测试变得难以编写时，您知道您可能需要对您的结构进行一些重组码。它还有助于以后的维护者不要以难以发现的方式意外破坏代码。

我建议您以下：

1. 测试驱动开发
2. 当您看到无法立即执行的操作时，在代码中大量使用“ TODO：在此处注释”，并在有时间的时候回到他们身边，而不是呆在Facebook上等待客户回电
3. 编写代码，因为客户会买代码，而不仅仅是看结果，想象您的客户是代码审查的主席。
4. 填写断言代码

我希望我可以说我能够100％地练习我讲的内容，但是BDD似乎是解决您情况的好方法：

这是更多信息的链接：http : //en.wikipedia.org/wiki/Behavior_driven_development

我在非常相似的船上。我尽可能地遵循敏捷原则（据我所知）。我可能没有“正确”地做事，但是通过遵循敏捷原则，我在项目上取得了巨大成功。这需要大量的纪律，因为没有团队可以确保您不只是开始采用捷径。

我发现使用代码格式化工具（例如ReSharper）可确保至少在视觉上易于为其他开发人员使用。

就实际方法而言，单个开发人员很难坚持使用任何特定的开发人员。我是一名通常独自工作的顾问，我发现对我自己和客户而言，使用敏捷过程都是最容易的。我通常会尝试让我的客户直接将他们的需求输入诸如Trac之类的工具中（或者我会代表他们）。这不仅可以帮助其他开发人员确定代码的用途，还可以帮助您自己3个月！

理念：XP / TDD + GTD

概述：

• 采访利益相关者
• 屏幕模型，演练，纸张原型（必要时）
• 功能/故事集思广益（有或没有利益相关者）
• 测试案例集思广益（有或没有利益相关者）
• 总体设计/架构思考时间（必要时）
• 迭代计划（与利益相关者）
• 迭代
• 流程审查，培训，维护计划等（必要时）

任何合适的方法都将有所帮助-不管项目中有多少人。因此，请一次选择一个，看看如何应用并映射到您的域，并衡量其成功。

也许更有趣的是问，因为只有一个人在从事该项目，所以不应该丢弃什么方法。

对我来说最关键的一个是Source Control（是的，它是一种工具，但这是您的工作流程的一部分，也是一个过程）。人们可能会想通过这种方式，因为他们“不需要支持多个人同时编辑代码”。

具有讽刺意味的是，我发现像GIT这样的分布式版本控制解决方案比SVN这样的个人更适合个人。

如果将其丢弃，那么使用方法论的代码可能会有些松懈，但是任何重要的事情，我想您将其作为一个团队项目来对待的方法非常好而且有纪律。

写你的代码给下一个要读的人，不是你...对他/她好。甚至“扔掉”的代码也永远存在。

敏捷

功能，故事和测试用例远比正式文档更具指导性，并且一组工作测试比任何数量的枯死树都更能证明如何使用某种东西或某种东西如何工作。

在迭代之间移交工作也更容易。

作为我自己的顾问，我建议您找到一种方法，在任何任务上始终至少有两个开发人员。

我同意保持敏捷，并留下其他人可以遵循的故事和测试的敏捷痕迹，但是我不相信人们在单独工作时，任何其他过程或方法都会坚持下去。

我认为代码审查是一个不错的开始，但是当它变得非正式且有趣时，我喜欢它，例如进行配对代码审查或配对编程以解决某些问题/问题或某些增强功能（例如，更改旧代码以满足新的编码标准） ）。有时候，两只眼睛比一只眼睛好，而且也很有趣，我觉得分享和讨论似乎更加开放。您也可能会喜欢正式/非正式的午餐，并讨论一些会话来谈论您个人或团体所做的事情，例如提及您使用的新模式或新技术如何解决问题？