cri*_*nge 1 testing coding-style organization
好吧,我认为这个问题出在了错误的地方,我将前往https://softwareengineering.stackexchange.com/阅读/询问.谢谢大家到目前为止的答案.:)
道歉 ;)如果这个问题有点主观,我很抱歉,但我无法想出一个更好的头衔.如果你知道更好的事情,我会纠正它.
在我的组织中,关于整个自动化测试和持续集成的事情有很多嗡嗡声,但我经常听到的一个论点是:
如果截止日期已经设定且只是我估计的一半,我应该如何开发好的,干净的,易于维护的代码并编写单元测试？
我自己是开发人员,所以我能理解这一点.但我总是试图回应,不仅开发人员需要范式转变,而且管理层也需要.
如果你是一名开发人员并且你的估计减少了一半,无论你估计什么,你都不会去任何地方,无论你的问题多么复杂或微不足道.你需要管理人员的备份,即那个给钱的One Guy.
你能给我一些帮助,可能是一个很好的URL来阅读这个开发/管理冲突,一本书或一个个人见解？您是否正在一家现在正在进行精益开发的瀑布公司中经历这样的大规模流程转移？或者你知道这个论点并且有一个聪明的答案吗？
请帮助我重命名或移动这个问题.:-)
谢谢你们所有的答案!:)我想我必须明确表示,我的观点不是来自管理层的" 做两倍快 "的声明.这是关于开发人员发表此声明的负面观点.
我能做些什么来帮助人们理解这不是软件开发的默认设置吗？该PM不积极防范编写好的代码,也许双方都需要了解的干净的代码基础,良好的覆盖和大量的自动化测试的利弊/反政府多一点的教育？
技术债务就是一个很好的例子.这是经理友好的.想象一下你的信用卡.如果您累积几周的债务可能会有所帮助.您不需要为每日购买随身携带现金,而是在月底付清.
这就像发布之前的紧缩.你承担了一些债务,然后很快偿还.如果你继续收取费用并且从未偿还债务,它就会开始复杂化.你想要的新功能更难,因为你正在建立的基础是不健全的.你积累的债务使你无法迅速采取行动.如果您超出限额,即使是典型的小额购买也无法通过.
您可能还想了解软件工程的事实和谬误.它讨论了在项目发展过程中未对其进行审核时可能导致的估算和问题.