过去3年我一直在做TDD.我们是一家小公司,我们对管理层敏捷流程的大多数方面提供了非常可靠的支持.开发团队中的每个人都在流程中被出售.因此,建造固定装置通常需要的前期投资被接受,因为它知道它会在整个过程中获得回报.(启动http服务器的代码,在测试之前填充sql数据库的代码等).文档主要发生在测试中,帮助请求通常以失败测试的形式呈现.
现在我搬到了一家更大的公司,虽然管理层支持敏捷流程,但团队成员却很混乱,他们中的一些人认为它很有用,其中一些人因管理而做,有些人看不到价值.如果他花时间编写一个失败的测试,说服人们花一些时间来建立装置或说服团队成员帮助他的最佳方式是一个挑战.
那么你认为向一个犹豫不决的队友出售TDD的最佳方式是什么？反对意见通常是:'这是一个不必要的成本','我们总是可以在事后为重要的部分编写测试','这是一个流行词,团队捡起它然后随着沉重的研磨开始它落到一边'等
S.L*_*ott 21
"向一个犹豫不决的队友出售TDD的最佳方式"
你不能.不要浪费时间"卖".
相反,投入时间"证明".
去做就对了.成功的.当人们问你成功的秘诀是什么,然后揭示TDD.不是之前.