如果您是团队领导者、项目经理或开发人员，您可能会遇到以下问题。以下是我们解决这些问题的方法方法。
时间估计错误
在软件开发中最常见的困难之一是任务估计。我们可以找到许多原因，但是，在我们看来，主要的原因是每个人都在说谎。不管它听起来多么荒谬。开发人员将估计值(在他们看来是真实的)乘以3。然后经理们将其加倍。之后，他们的领导将会增加三倍的估计，同时老板也怀疑这样是否能在最后期限前完成任务。
有很多人试图将这一过程正式化，排除人为因素，但总的来说，没有什么好的办法，仅仅通过跟开发者直接打交道的有经验的人自行判断。目前最有效的方案使用条件度量单位，也称为故事点(story point)。
但即使在这种方法中也存在缺陷——相互欺骗也在继续。老前辈们告诉新来者的第一件事是，他们的假定的计量鹦鹉(或一个故事点)包含了大约5个小时的开发，你应该这样评估——通过将时间估计除以5。这就是谎言的开始。
每个人都在头脑中按小时对任务进行评估，然后通过简单的数学运算，把它变成故事点。在那之后，每个人都聚精会神地盯着同事们，心里想，到底是计量鹦鹉的数量太少了(还是反过来说，太大了)。然后改变它以满足同事和经理的期望。一遍一遍这样的重复。
代码评估标准
您对团队中的代码审查有什么感觉?您是否支持定期的代码评审，或者只是走走形式就可以了?总结软件开发中的最佳实践，我们注意到人们都非常关注代码的清洁度。但是如何理解这个程序是否足够好呢?
在日常的开发过程中，确定当前正在编写的代码有多好成为一个巨大的挑战。这并不是因为开发人员不够聪明。简单的事实是，可想而知，当前开发人员创建的代码已经是最好的代码，否则他不会这样编写。通常，他们会这样狡辩，“代码中可能有一些不太漂亮的部分，但是当时没有别的办法”，我们都很熟悉的这样争论的后果。
有一种自检代码的技术，在这种技术中，仍然不可能检测到您的代码中的所有缺陷，但是，可以将它们中的大多数都捕获。它们是一组“石蕊试纸”(如果你愿意的话，可以是认作是“触发器”)，在编写代码时，你应该记住它们。以下是其中的一些:
是否能容易的测试你的代码?如果在编写测试时遇到问题，那么这里的某些东西就像是糟糕的代码。
这段代码容易纵向扩展吗?我们不是要同时运行几个应用程序，而是要将实体添加到上面的级别。像“company_id”或其他。
很容易为某个方法或变量想出一个名字吗?如果命名有困难，要经过深思熟虑，那么很可能它的代码也不是很清晰。
你需要重新定义多少种方法?有很多边界条件需要处理吗?或者，在一般情况下:规则是怎样的，你的功能是建立在什么基础上的，你有多少例外的规则?这里讲的不是有太多的业务逻辑，而是一个正确选择的体系结构和代码结构。如果在系统中发现了一个bug，并且您可以通过添加一个有条件的分支来修复它，那么这个bug并不是从头开始出现的，而是从组织不正确的代码结构中出现的。
有很多这样的标准，但有些不能像这样公式化，而且在每个特定的项目中，要求可能会有所不同。此外，一个优秀的开发人员在他的潜意识中已经有了一套这样的标准，并通过它们能精确地嗅一段有异味的代码。试着在工作中为自己制定这些标准，并不断完善它。除了能够要准确的归纳烂代码特征外，我们还需要一个很棒的自测试工具，因为在编写代码6个月之后，您的代码就会开始腐败，而新标准和规则能够发现这些问题。
对临时解决方案说不
由于不同的原因，当前有一些解决方案可能比正确的方案更可取:所需的时间更少、代码更简单、设计更简化等等。有些开发人员倾向于使用这样的技巧来搞定特定的任务完成实现或赶上最后期限。但是，这种临时解决方案可能会使用很多年，不需要更改，它会与应用程序的其他部分紧密地交织在一起，因此很难替换它。事实证明，这种临时方案是推迟了一个不确定的未来的任务，而最终忘记了它。这种债务的数量随着时间的增加而增加。
当然，有时妥协是必要的，我们也一直都这样做，但不要认为这样的解决方案是暂时的，就可以暂时放弃你的原则。
记住:不存在临时代码。当检查并添加部分代码到应用程序中，要想到它将永远留在那里。坚守这个底线，你会发现临时代码的数量会骤然减少，这将使您的代码对其他团队成员来说更加清晰易懂。
招聘好的团队球员
当你召集一个团队在一个项目上共同工作时，你应该确定一个人是否是一个好的团队成员，他的技能和个人素质是否适合于开发工作。知道如何从候选人中挑出一个不合适的人，这对你的项目管理成功至关重要。每个公司的人力资源都有自己的方法和技巧来实现这个目标，但是有没有统一的算法来避免在招聘员工时出错呢?
在我们看来，军队中有一个很好的标准，用这个标准来区分好士兵和坏士兵并不难。你可以想象这样一句话:“我不会和他一起去探险的”。
实际上，当被问及战斗伙伴如何组队时，标准可能会有很大的不同，而这些标准的不同取决于所获得的优势和经验。对某些人来说，重要的是他的搭档是否是好的射手，跑得快。而另一些人要的是寻找一个沉默寡言，烹饪美味的人。还有人是需要一个不怕蛇并且能够控制战斗直升机的人。我们试图创建一个通用的战士所需品质和属性列表，但很快就落入了一些RPG的特性俗套，比
如“Fallout”或“Skyrim”。事实上，要区分一个好的战士和一个坏的战士是极其困难的。
但是，使用下面的一些判断方法，可以很容易的判断一个个javascript开发人员是好还是不好。问自己两个问题:
你会同意在一个他是团队领导的项目里工作吗?
你能把你负责的任务托付给他吗?
如果两个答案都是“不”，那么这样的士兵就需要紧急送往建筑营，远离战场。
来自：程序师
英文原文：The Most Common Mistakes of the Software Development Team
