在团队环境中工作,您如何处理拒绝遵循团队定义标准的开发人员?
1)开发人员处于初级水平
2)开发人员处于同行水平
3)开发人员处于高级
我知道这是有启发性的,但我觉得通过让它们变得更专业,它将有利于开发人员。谢谢!
答案 0 :(得分:6)
1)开发人员处于初级水平 - 导师;善良和善良温和。解释一般标准的必要性,然后解释对未遵循的特定标准的需求。以开放的心态做到这一点;如果你不能证明标准的合理性那么也许它不应该成为一个标准?
2)开发人员处于同级别 - 这应该很容易 - 如果你能保持技术性而不是让它溶解成个性冲突。再说一次,如果你可以证明它,它可能应该是一个标准,但如果他有一个同样令人信服的论据反对,那么也许不是。但是,不接受应该没有标准。问他一个建议的标准,以取代他不喜欢的标准。如果他不遵守,那就升级。如果你不喜欢它,那就把它投票/升级。尽量避免升级,但要尽量确保是标准。
3)开发人员处于高级别 试着推理。仔细听,他可能是对的。如有疑问,请将其投票/升级。
警告:标准很好(imo,绝对需要,但是ymmv),但除非达成共识,否则很难“强制执行”。例外:“牛仔编码员”需要打击 hard ;没有期望。
不要对老板“喋喋不休”感到难过。谈到一个牛仔编码器,然后遵循牛仔的座右铭“这个团队对我们两个人来说都不够大”;要么他停止牛仔,要么你们其中一人必须得到道奇的地狱。
答案 1 :(得分:2)
结对编程可能是我最好的建议,因为这可以帮助确保每个人达到同一水平并帮助培养团队内的社区意识。这确实在一定程度上转移了责任,但这个想法是让某人试图让别人按照别人的方式做事。 How to Win Friends and Influence People有以下几点可以适用,尽管这些是一般性的:
处理人员的基本技巧
- 不要批评,谴责或抱怨。
- 诚实和真诚的感谢。
- 激起另一个人的渴望。
醇>让人们喜欢你的六种方式
- 真正对其他人感兴趣。
- 微笑。
- 请记住,男人的名字对他来说是最甜蜜最重要的 任何语言的声音。
- 做个好听众。鼓励他人谈论自己。
- 谈谈另一个人的兴趣。
- 让对方感到重要并真诚地做到。
醇>赢得人们思维方式的十二种方式
- 避免争论。
- 尊重他人的意见。永远不要告诉某人 他们错了。
- 如果你错了,请尽快并坚决地承认。
- 以友好的方式开始。
- 从问题开始,其他人将回答是。
- 让对方说话。
- 让对方觉得这个想法是他/她的。
- 诚实地从对方的角度来看问题。
- 同情另一个人。
- 呼吁崇高的动机。
- 戏剧化你的想法。
- 放下挑战&这个人不要说否定 缺席,只谈正面。
醇>成为领导者:如何改变 没有进攻或者进攻的人 引起怨恨
- 从赞美和诚实的赞赏开始。
- 间接注意别人的错误。
- 首先谈谈你自己的错误。
- 提出问题而不是直接下订单。
- 让对方挽回面子。
- 赞美每一项改进。
- 给他们一个良好的声誉,以实现。
- 通过使他们的错误看起来容易纠正来鼓励他们。
- 让对方高兴做你的建议。
醇>
答案 2 :(得分:1)
如果有标准文件,那么只需指向文档并告诉他们需要遵守标准。如果没有文档,并且它是一种特殊的“这事实上这个团队是如何编码的”,那么组织一次会议就团队标准应该是什么达成共识并创建标准文档。我认为为了可读性和维护性而需要一致的风格是相当困难的,并且当存在规则“以这种方式做”时,与它相比,它要比它更难以分离。只是建立了实践。
答案 3 :(得分:0)
我们使用TFS和代码签入策略来强制执行代码标准。我同意的其他回应完全是为了人民的一部分。对于某些编码标准,如变量命名标准,您可以花一点时间(可能有问题的开发人员可以写这些)并编写这些标准。如果将它们合并到构建过程中,那么构建验证的一部分涉及检查源是否有正确的代码标准。我们在Visual Studio 2008中使用MSBuild,效果很好。当系统被开发用于执行标准时,这将有所帮助,因为有时候更难与构建系统争论。此外,有助于让构建将这些违规视为视觉工作室中的错误,而不仅仅是警告进一步执行。最重要的是,标准的“为什么”部分对于任何级别的开发人员来说都是最重要的。如果他们理解为什么标准是有用的并且理解正确的论坛/机会(每月开发会议?),他们可以根据特定标准发声推理,希望他们可以开始跟随他们与成功的团队一起。