我们的团队使用 TDD 进行开发,并且在实现新功能时,有时会在所有卡片变为绿色时出现“集成卡片”,这意味着将已实现的组件放在一起以相互配合。我对这张卡感到难过,因为这意味着,没有人在现实生活中只在测试中尝试过代码,而集成卡意味着尝试它并使其工作。
在每个产生新功能的故事的结尾放置一张集成卡是一种很好的敏捷实践吗?或者当可以将它与现有代码集成在一起时,它是否应该成为每个任务卡的一部分?
我们的团队使用 TDD 进行开发,并且在实现新功能时,有时会在所有卡片变为绿色时出现“集成卡片”,这意味着将已实现的组件放在一起以相互配合。我对这张卡感到难过,因为这意味着,没有人在现实生活中只在测试中尝试过代码,而集成卡意味着尝试它并使其工作。
在每个产生新功能的故事的结尾放置一张集成卡是一种很好的敏捷实践吗?或者当可以将它与现有代码集成在一起时,它是否应该成为每个任务卡的一部分?
这里只是我的 2 美分:
TDD 本身与您在问题中描述的工作方式无关。我认为敏捷 / Scrum / 精益 / 看板会。
在实际编写代码之前编写单元测试是一种很好的做法,如果我理解正确的话,你们正在这样做。
我同意你的观点,将代码的实际集成推迟到 sprint 结束时有点奇怪。如果地狱破裂,您在冲刺结束时一无所获。换句话说,在最后一张有风险的卡片完成之前,您的潜在可发货产品将不存在。
如果你想突破这种工作方式,我会考虑谷歌搜索持续集成。在那里,您努力尽可能频繁地集成代码,以便尽快找到集成错误。
长话短说:
希望这可以帮助您迈向真正的敏捷/精益团队!相信你的直觉,你确实明白了:)。