自从我两年前开始做专业软件开发工作以来，我阅读了很多关于软件公司中通常接受的方法论(例如Scrum、XP)、技术(EJB、Spring)、技巧(TDD、代码审查)、工具(缺陷跟踪、维基)等方面的文章。
其中许多内容我们在公司并没有使用，我想知道为什么。我们是做错了吗，还是说这些文章中描述的并不是真实世界中的情况？这些文章更多的是学术性的吗？
因此，请告诉我你们公司的情况。谈谈与软件开发有关的一切。以下是我的一些建议(按照我的思路顺序列出)。请至少告诉我你是否在使用这些，或者简单评论一下：
请注意：我想知道你们真正做了什么，而不是你们想做什么或认为应该做什么。
顺便说一句，我意识到我并没有直接回答你的问题，但是“大泥球”在许多开发情况下仍然占主导地位。你可以问关于测试驱动开发、缺陷跟踪等其他类型的问题，但如果从我所见的情况来看，我会说“大泥球”基本上是人们工作的事实标准——无论他们是否应该这样做。
注意：
最重要的是...
然而，工资相对较低，因为很多人都想在这家公司工作。不能拥有一切！
我的部门还在不断进步中。过去几个月，我致力于推动持续改进。有些事情确实很难谈论。然而，回顾过去，它们已经得到了改善。
我是一家小型软件公司的两个程序员之一，老板们非常不懂技术（“什么是浏览器”——上周真的有人这样问）。
优点是我可以自己选择大部分的工作方式。
测试驱动开发(TDD)——我们的老板有过不好的经历或者别的什么事情。只要提到测试，她就像在表演创伤后应激障碍症一样。
领域驱动设计(DDD)——是的。
模型驱动设计/架构(MDA)——是的。
你们会测试吗？——不会。测试工作需要由销售和支持人员以及老板来做。所以一旦离开我的开发机器，几乎没有什么被测试过。
单元测试(Unit Testing)——如果我做了，可能会被解雇。而且这也是唯一会让我被解雇的东西。
集成测试(Integration Testing)——参见“你们会测试吗？”
验收测试(Acceptance Testing)——好吧，总得有一天把它部署出去吧？
代码审查(Code Reviews)——其他人都看不懂。我看过所有人的代码。但真希望我没看过。
创新技术（Spring，Hibernate，Wicket，JSF，WS，REST，...）- 是的。但我因此受到了批评。我是那个“孩子”，不知道任何在过去十年中没有发明的东西（尽管我已经30岁，并且在我的桌子上有“数据库系统阅读”）。
敏捷 - 我不瀑布流。但我也不真正敏捷。
配对编程 - 你不想试着与我们公司的另一个“程序员”交谈。
UML - 不。但我有时会在白板上画带有标识符的框。老板们喜欢这个。幸好他们不太懂技术，否则我可能会看到更多的框。
特定领域语言 - 不。
需求规格（如何？） - 不。
持续集成 - 不。
代码覆盖工具 - 不。
贫血领域模型 - 是的。尝试过。在大多数情况下，我不喜欢它并且不使用它。
沟通（Wiki，邮件，即时消息，邮件列表，其他文档） - 尝试过，但无法获得同事的支持。我们的MediaWiki安装仍然具有默认的徽标图形。
工作量估计 - 我们必须估计每个任务需要多长时间完成。这就是客户要付费的。而且这也是我们预期在项目上花费的时间。即使是在开发新应用程序和修复错误（是的，我们会向客户收费）以及添加功能等方面，我们也会这样做。
团队规模 - 1。让我说一下，这不是一个好的工作方式。能够实时与其他有能力的程序员交流想法要好得多。
会议 - 每周几个小时，有时会加倍，很少少于这个时间。我参加的一半会议是与客户会面的，另一半则完全是内部会议。
代码指标 - 没有。
静态代码分析 - 没有。
缺陷跟踪 - 没有像我应该做的那样多。
我在澳大利亚布里斯班的一家Ruby on Rails咨询公司工作。
测试驱动开发：在我们的办公室里，这个非常重要。不进行测试被视为“极其愚蠢”。你写了代码，如何通过自动化流程（例如CI）确保它仍然有效？测试。
你测试吗？：见第一点。
单元测试：一直使用RSpec。我也熟练掌握Test::Unit和Shoulda。
集成测试：同样，一直使用Cucumber。
验收测试：对于我们的工作票，我们会附上验收标准。然后客户必须按照指示“接受”或“拒绝”它们。验收标准还有一个额外的好处，就是我们的Cucumber功能也是按照这些标准编写的。
代码审查和配对编程：我们进行配对编程。这是即时版本的代码审查。这很棒，因为你可以坐下来看别人工作，他们编写测试，然后你编写代码使该测试通过。如果你生病了，那么另一个人知道你在做什么，并且可以与其他人配对。
创新技术：因为我们使用Rails，我们非常喜欢REST。
敏捷开发：我们使用Pivotal Tracker进行2周迭代。
需求规格说明（如何？）：使用Pivotal Tracker中的功能，客户可以指定他们的要求，然后我们将它们具体化（通常是通过与他们交谈），最终成为真实世界的功能。
持续集成：我们使用我开发的CI服务器construct。这是建立在Integrity基础上的，但具有后台作业和更好的分支支持的想法。现在Integrity已经具备了后台构建功能，但我们仍然保持着分支支持的领先地位。
代码覆盖工具：有时会使用RCov。我们并不太关心代码覆盖率，因为在编写代码之前我们会对所有内容进行测试。如果它存在，就有一些东西可以进行测试。
沟通（Wiki、邮件、即时消息、邮件列表、其他文档）：我们主要使用电子邮件与客户沟通，但我们也会使用Skype进行“站立会议”。我们也曾经使用Basecamp。我想在我们的下一个项目中使用Google Wave，只是作为一个小实验。我认为这会非常有帮助。
团队规模：我们的团队有4个人，通常是2个配对，除非有人生病了。
我在南非的Chillisoft.co.za工作。
测试驱动开发：自从Kent Beck的第一本书以来，我们一直在使用测试驱动开发实践，并且这是强制性的。我们使用NUnit和R#作为测试运行器。
你做测试吗？：除了TDD之外，我们还进行手动测试（可视化），并在必要时进行自动化。用于自动化的技术取决于UI技术。
单元测试：参见TDD。
集成测试：是的，但我们尚未广泛使用。
验收测试：我们为外部客户定制软件开发，只有在他们接受后才会付款，因此是的。
代码审查：每个项目定期进行双月代码审查，即使是那些已经进行了配对/同行编程的项目也是如此。
配对编程：我们大部分的编码都是成对进行的，但在某些任务和项目阶段中，这种方式效率会降低。因此，在项目启动阶段（每个阶段的前几周）我们会进行配对编程。在完成阶段，我们则不再采用这种方式。此外，我们还有特定的时间（每位开发人员每周8小时）用于开源项目，这些项目都是成对编程的。我们所有的机器都设置了多个键盘和鼠标，以便于开发人员之间的顺畅交互。 创新技术：我们在Habanero上做了大量的工作，并使用了该框架以及DI容器Unity和RhinoMocks。 敏捷开发：我们已经使用敏捷哲学8年了，并且在继续沿着这条道路前进时，我们仍在尝试各种工具和哲学。 需求规格说明（如何实现？）：我们在MSWord中捕获下一次迭代的用户故事（用例）。然后我们在Jeera中捕获这些故事的摘要，包括工作量估计等，这可以管理绘制下降图等。 持续集成：我们目前正在使用Hudson，它可以在SVN之上工作。代码覆盖率工具：我们每晚都会运行代码覆盖率作为项目的一部分。我们已将生成的报告集成到Hudson报告中，以便我们可以每天跟踪每个项目。
沟通（Wiki、邮件、即时消息、邮件列表、其他文档）：显然，我们以许多不同的方式进行沟通，我们有一个内部Wiki等。
团队规模：我们有15名软件开发人员。
会议：我们每天早上都有一个大约持续10分钟的“Scrum”会议。
缺陷跟踪：我们使用不同的系统进行内部缺陷跟踪（即在开发和内部测试期间）和外部缺陷跟踪，即来自客户的缺陷。在内部跟踪（即在内部测试和开发期间），我们使用Redmine。在外部跟踪（即针对我们的客户），我们使用Mantis。
