it-swarm.cn

敏捷开发者

有人将如何以敏捷开发人员的身份实施敏捷流程概念?敏捷似乎有助于加快应用程序的开发速度,但似乎也非常面向团队。

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

我记得读过一篇有关Cowboy Development的论文,这对单开发人员来说是必不可少的敏捷,但是我不记得在哪里找到了。

66
Federico klez Culloca

除了klez的答案(所有好的建议),我建议以下几点:

  • 保留产品积压
    产品待办事项列表基本上是您打算在此产品某个阶段完成的所有项目的列表。
  • 维护冲刺消耗和产品消耗
    sprint消耗从您已决定在此sprint中完成的所有任务的列表开始(产品积压的子集将在设定的时间段内(例如2周)内完成)以及对所需的工作。标记完成后,将其标记为完成。从而减少(或消耗)该冲刺的剩余工作。
    类似地,产品燃尽情况会跟踪整个产品待办事项列表的剩余工作
  • 采用相对估计和速度的概念
    相对估算是一种将其他任务(或故事)用作指导的估算技术。例如,如果您知道任务A比任务B容易,并且任务B的复杂度是任务C的两倍,则可以确保任务A的“要点”相对于这些期望是正确的。
    重点不是正确地猜测所需的工作量,而是使估算彼此一致。
    速度是衡量您在冲刺中获得多少“点”的度量。如果您的相对估计可以确保一致性,那么可以使用此速度来估计您在即将完成的sprint中可能完成的任务。请注意,尽管应该不断修改速度。
39
Damovisa
  • 限制进行中的工作(除了装箱外)。即使您使用迭代方法(而不是看板),也可以说您的速度是每次迭代8点。不要一次开始处理全部8个。通过故事数或故事点数限制WIP很好。
  • 对您所有的用户案例进行自动验收测试。一般而言,要尽可能地自动化。
  • 错误在于使用户故事过小。根据经验,将最大故事层与最小故事层的比率设为3:1。如果您低估了Scrum中的一个故事并且发现故事太大,则多个开发人员可以将其聚集起来以使其恢复正常。但是您没有足够的人。
  • 如果在常规规模的团队环境中,您是否想从用户故事中拆分高峰,那么在单人或小团队的情况下,请毫不犹豫地执行高峰。这有助于使故事更小,更可预测。
  • 一般而言,回顾在敏捷中很重要,因此看板(也就是“个人看板”)在这里得分较高,因为其回顾过程更多是由数据驱动的。当您没有足够的人时,很难打三重镍。

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

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

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

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

9
MIA

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

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

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

3
S.Robins

哇。我会尽量让遇到麻烦的朋友打电话给我-讨论编码问题。您知道我的意思吗……只是大声地解释问题的举动才有90%的时间可以解决my头脑。

1
codeyoung