敏捷开发者

有人将如何作为单独开发人员实施敏捷流程概念？敏捷似乎有助于加快应用程序的开发速度，但似乎也非常面向团队。

• 通过测试驱动的开发
• 通过小冲刺发展
• 通过与客户的大量联系

我记得读过一篇关于Cowboy Development的论文，这对于单手开发人员来说必不可少，但是我不记得在哪里找到它。

除了klez的答案（所有好的建议），我建议以下几点：

• 保留产品积压
  产品积压基本上是您打算在此产品某个阶段完成的所有项目的列表。
• 维护sprint消耗和产品消耗
  sprint消耗开始于您已决定在此sprint中完成的所有任务的列表（产品积压的子集将在设定的时间段内（例如2周）完成）以及所需工作的估算。标记完成后，将它们标记为完成。从而减少（或消耗）该冲刺的剩余工作。
  同样，产品燃尽跟踪整个产品待办事项的剩余工作
• 采用相对估计和速度的概念
  相对估计是一种以其他任务（或故事）为指导的估计技术。例如，如果您知道任务A比任务B容易，并且任务B的复杂度是任务C的两倍，则可以确保任务A的“要点”相对于这些期望是正确的。
  重点不是正确地猜测所需的工作量，而是使估算彼此一致。
  速度是衡量您在冲刺中完成多少“点”的度量。如果您的相对估计可以确保一致性，那么可以使用此速度来估计您在即将完成的sprint中可能完成的任务。请注意，尽管应该不断修改速度。

• 限制进行中的工作（除了装箱外）。即使您使用迭代方法（而不是看板），也可以说您的速度是每次迭代8点。不要一次开始处理全部8个。通过故事数或故事点数限制WIP很好。
• 对您所有的用户案例进行自动验收测试。一般而言，要尽可能地自动化。
• 错误在于使用户故事过小。根据经验，最大故事与最小故事的比率应为3：1。如果您低估了Scrum中的一个故事并且发现它太大，则多个开发人员可以将其聚集起来以使其恢复正常。但是您没有足够的人。
• 如果在常规规模的团队环境中，您是否想从用户故事中拆分峰值，则在单独或小型团队环境中，毫不犹豫地执行峰值。这有助于使故事更小，更可预测。
• 一般而言，回顾在敏捷中很重要，因此看板（也就是“个人看板”）在这里得分较高，因为看板的回顾过程更受数据驱动。当您没有足够的人时，很难打三重镍。

这些事情可能适用于单独和小型团队（2或3个开发人员）的情况。

添加：在我写完此答案后的某个时候，我发现了这次会议演讲，并给人留下了深刻的印象：个人看板：优化个人编码器

• 要么进行明确定义的冲刺，要么故意选择看板方法。不要意外地结束在看板中
• 首先是错误，其次是功能。
• 仍然要关注“价值与功能”膨胀。（YAGNI镀金）
• 回顾同样有价值。同样重要的是，对流程进行小块更改。除非您确实没有提供ATM的外部功能，否则不要决定今天您将一口气开始使用TDD，Mock和IoC。一次带一个。

最终，我将Agile真正定义为“做对您的团队和客户有意义的事情，而不遵循旧的做法，因为它们恰好看起来像过去那样。”

敏捷对于个人和团队都同样有效。这是关于找到一个适合您的流程，并让您的项目一旦开始就可以适应不断变化的情况。这也与定期为您的客户提供价值有关，无论该软件是否真正“完成”。

敏捷过程是高度迭代的。工作在简短的TimeBoxes / sprints / cycles / iterations中完成。可能需要先进行一些设计工作，但是当您了解有关系统需要做什么的更多信息时，可以进行重构。单元测试是几乎所有敏捷开发方法的基础，它可以指示您的软件是否正常运行，以及对软件的添加/更改是否会破坏现有的代码库。

如果您坚持使用BDD / TDD，则可以随风变化您的要求，并可以相应地调整功能优先级，如果您构建了整个系统并经常运行所有测试，并且在每个sprint的末尾提供了工作代码， ，您已经很敏捷。

哇。我会尽量让遇到麻烦的朋友打电话给我-讨论编码问题。您知道我的意思...大声地解释问题的举动会在90％的时间内为我带来解决方案。