自从我大约两年前开始作为专业软件开发人员的第一份工作以来，我已经阅读了许多关于普遍接受的方法（例如 Scrum、XP）、技术（例如 EJB、Spring）、技术（例如 TDD、代码审查）的文章)、软件公司中的工具（错误跟踪、wiki）等。
对于其中许多，我发现我们公司不使用它们，我问自己为什么。我们做错了还是仅仅是我读过的这些文章并没有真正说明现实世界中的情况？这些文章更具学术性吗？
所以，请告诉我你们公司的情况。讲述有关软件开发的一切。这里有一些建议（按照我脑海中的顺序）。至少告诉您是否这样做，或发表简短评论：
请记住：我想知道你真正在做什么，而不是你想做什么或认为你应该做什么。
就大型企业开发而言，还有更糟糕的情况。考虑到我住的地方，以及该地区缺乏高科技工作，我真的很幸运能有一份演出。但这并不意味着我必须喜欢事情的现状。甚至试图影响已建立的企业文化也需要大量的时间和持续的压力。
但如果他们厌倦了我试图改变文化并解雇我的尝试，好吧，我想那天晚上我不会哭着入睡。
我认为著名的Big Ball of Mud模式描述了很多工作环境，并为您提供了一些关于如何与此类事情作斗争的好主意。
顺便说一句，我意识到我没有直接回答你的问题，但大泥球在令人沮丧的大部分开发情况中占主导地位。你可以询问测试驱动开发和缺陷跟踪以及其他类似的事情，但如果从我所看到的情况来看真相，我会说大泥球几乎是人们工作的事实上的方式——他们应该或不应该。
我的部门正在进行中。在过去的几个月里，我一直在努力实施持续改进。有些事情已经很难谈论了。然而，当回首往事时，他们已经有所改善。
而且最重要的是...
但是工资低很多，因为很多人想为这家公司工作。不能拥有一切！
笔记：
我为你感到难过 :) 这不是一个好的工作环境，因为你需要不断练习实践好的做法才能真正理解和使用它们。
我知道有几家（包括我的）公司能够在您的清单中勾选所有“好”的方框。
然而，魔鬼在细节中，即使在一些拥有良好 SDP 政策的公司中，也不是每个项目都遵循它们。
在我来这里的近 2 年里，该团队是我们的第三个团队领导。
CMS 项目是我们都在努力的大项目，尽管有其他人处理的各种支持请求。
在我们拥有 IS 副总裁的这一年发生了很多变化。生产更加锁定，还有更多的工作来完成发布，因为现在有一个检查列表程序和更多可能有用的箍。
我是一家小型软件公司的两名程序员之一，拥有非常非技术的所有者（“什么是'浏览器'” - 上周被认真问过）。
优点是我可以在大多数这些点上自己选择。
测试驱动开发 - 我们的所有者有一个糟糕的经历或其他东西。以错误的方式提及测试，我发誓她的行为是出于创伤后应激障碍。
领域驱动设计——是的。
模型驱动设计/架构 - 是的。
你测试吗？- 没有。测试落在销售和支持人员以及业主身上。因此，一旦它离开我的开发机器，就没有什么能得到太多测试。
单元测试——如果我被发现这样做我可能会被解雇。它真的是唯一可以让我被解雇的事情。
集成测试 - 请参阅“您进行测试吗？”
验收测试 - 好吧，我们必须在某个时候部署它，对吧？
代码审查 - 没有其他人会理解它。我见过其他人。希望我没有。
创新技术（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 服务器，称为构造。这是建立在像 Integrity 一样的想法的基础上，但有后台工作和对分支机构的更好支持。现在 Integrity 有了背景建设，仍然有分支支持让我们“领先”。
代码覆盖工具：有时是 RCov。我们并不真正关心代码覆盖率，因为我们在编写之前测试了所有内容。如果它存在，就会有一些东西可以测试它。
沟通（Wiki、邮件、IM、邮件列表、其他文档）：我们主要使用电子邮件与客户沟通，但我们也使用 Skype 与他们进行“站立”。我们也为此使用了 Basecamp。我想在我们的下一个项目中使用 Google Wave，就像一个小实验。我认为这真的很有帮助。
团队规模：我们团队有 4 人，通常是 2 对，除非有人生病。
我在南非的 Chillisoft.co.za 工作
测试驱动开发：自第一本 Kent Beck 书籍以来，我们一直在使用测试驱动开发实践，它一直在执行。我们使用 NUnit 和 R# 作为测试运行器。
你测试吗？：除了 TDD 之外，我们还进行手动测试（视觉），并在必要时自动进行。用于自动化的技术依赖于 UI 技术。
单元测试：见 TDD。
集成测试：是的，但我们还没有普遍使用。
验收测试：我们为外部客户进行定制软件开发，在他们接受之前您不会获得报酬，因此是的。
代码审查：为每个项目安排双月一次。即使是那些已经配对/对等编程的。
结对编程：我们的大部分编码都是结对进行的，但肯定有一些任务和项目的某些阶段效率较低。我们所做的是在项目启动期间（每个阶段的前几周），我们配对编程。在完成阶段，我们没有。当我们从事开源项目时，我们也有特定的时间（每个开发人员每周 8 小时），这些都是成对编程的。我们所有的机器都设置了多个键盘和鼠标，以促进开发人员之间的顺畅交互。
创新技术：我们在Habanero上做了大量工作，并将这个框架与 DI 容器 Unity 和 RhinoMocks 一起使用。
敏捷：我们使用敏捷哲学已经 8 年了，并且在我们继续沿着这条道路前进的过程中，我们将继续尝试使用工具和哲学。
需求规范（如何？）：我们为 MSWord 中的下一次迭代捕获用户故事（用例）。然后，我们在 Jeera 中通过工作量估计等捕获这些摘要，该工作量估计等管理绘制图表等。
持续集成：我们目前使用的是在 SVN 之上工作的 Hudson。
代码覆盖工具：我们为每个项目运行代码覆盖，作为我们夜间构建的一部分。我们已将生成的报告集成到 Hudson 报告中，以便我们可以每天跟踪每个项目的这些报告。
交流（Wiki、邮件、IM、邮件列表、其他文档）：显然我们以许多不同的方式进行交流，我们有一个内部 Wiki 等。
团队规模：我们有 15 名软件开发人员。
会议：我们每天早上都有一个“scrum”，持续约 10 分钟。
错误跟踪：我们使用不同的系统进行内部错误跟踪（即在开发和内部测试期间）和外部错误跟踪，即来自客户的错误。内部跟踪（即在内部测试和开发期间）我们使用 redmine。外部跟踪（即我们的客户）我们使用 Mantis。
•Test-Driven-Development - 刚刚开始接管，到目前为止非常满意
•你测试吗？- 当然，每个人都喜欢，谁想让QA嘲笑他们？
•单元测试 - 大约 2 年以来，帮助提高了稳定性，并且每次构建都运行测试
•代码审查 - 到处都是，尤其是任何后期更改
•Agile - 热爱敏捷及其响应性
•结对编程- 只是在几个地方尝试，早期回报很有希望
•持续集成——CruiseControl.NET 的胜利！！！如此巨大的帮助
•代码覆盖工具——总是在每次单元测试运行期间，CC.NET 都会向全世界发布这些信息
•通信（Wiki、邮件、IM、邮件列表、其他文档）- WIKI、IM、Campfire
•团队规模——小，当产品团队变大时，我们会分解成功能团队
• 会议 - 时间短且不经常，更有可能在走廊聚会
•代码度量——只有圈复杂度
•静态代码分析 - 真正尝试这个 更多使用 FxCop 和 VSTS 的自产
•错误跟踪 - Windows 的 TFS 和 Mac 的 Traq
测试：我做了很多系统测试，以及少量的单元测试。我尝试在有意义的时候使用测试驱动开发，但感觉大多数时候它对我正在做的事情的核心没有意义。
至于其余的，我不确定我是否正确地使用了“特定领域的语言”，但我确实使用了很多自动生成的代码来捕获我工作中的重复内容——我统计了 9 个 Perl 脚本几乎生成了100,000 行代码。
至于其余的，团队规模始终是一个。我大约每年使用一次 PC-Lint 进行静态代码分析。我大量使用 gprof 和 valgrind（您似乎没有提到这类工具）。多年来，我一直在寻找一个合适的错误跟踪系统，但目前仍在使用待办事项列表软件和电子邮件来处理它。
就是这样。我们有一些我觉得可以改进的地方。
更新：
在我发布此消息几周后（08 年 11 月上旬），我们的业务分析师因大规模裁员而失业。从那以后，我在现有应用程序中实现了 ELMAH，最近开发了一个来帮助跟踪错误（我们也登录到数据库），我喜欢它的易用性、特性和捕获异常的能力。 't catch (这在很大程度上是未使用的，但仍然有很好的覆盖范围)。我仍然在自己研究单元测试——我真的需要加快步伐（我也想学习 MVC，但我主要也是在研究这个）。
我们现在正在设计一个新的应用程序，我正在为 6 个模块中的 3 个（团队负责人正在研究另外 3 个）做一个模拟数据库模式（它将获得一些基本图表）。我不期待它，因为这将由我们三个人（每人 2 个模块）使用 IronSpeed Designer (6.1) 一起开发。IronSpeed 会为我做一些我喜欢的事情，但这并不是快速完成这些事情的唯一方法，它还会做一些我不关心的事情。
其他一切都没有改变。
我的公司已经采用了大多数“流行语”方法。单元测试、测试驱动开发、Scrum、敏捷、持续集成、代码覆盖分析等。我发现随着团队规模随着经济的变化而变化，我们正在从一个产品跳到另一个产品。经过大量裁员后，我们从 Rally Dev/Scrum 转移到了 Jira/Agile。我们正在使用 Selenium 进行自动化测试，但现在正在研究 Tellenium 和 Google 的 WebDriver。
我们发现了什么？通过了为其创建的所有测试（包括负载测试）的站点，在真正分析时可能会非常低效。经过代码性能分析，我们能够将其中一个站点的服务器资源减少 2/3，并且仍然具有更好的性能。它仍然通过了同样的测试。
前端自动化测试无法捕捉到人类会在几秒钟内注意到的定位问题。当然，我们可以花几个小时编写测试来检查定位。但是测试很脆弱，当页面布局发生变化时必须重写，即使只是一点点。测试通常只是表明代码有效，而不是它有多好。
我曾在使用许多不同技术的大公司和小公司工作过。包括简单的“牛仔编码”。当我们不采用计划和测试方法时，会有更多的错误，但我们移动得更快。我们在数小时内推出更改和修复，而不是几天和一周。
Facebook 每周（星期二）都会进行一次“推送”。最新的代码推送中经常有错误（没有足够的测试？），但他们经常在那个星期四或星期五再次推送以解决任何问题。我的猜测是 Facebook 更接近于“牛仔编码”方法并且它一直在为他们工作。
以下是我的观察：
测试驱动开发：否
领域驱动设计：是
模型驱动设计/架构：是
你测试吗？： 是的
单元测试：是的
集成测试：是
验收测试：是
代码审查：否
创新技术（Spring、Hibernate、Wicket、JSF、WS、REST，...）：是
敏捷结对编程：否
UML：是的
特定领域语言：是
需求规范（如何？） 是
持续集成：是
代码覆盖工具：否
贫血域模型：否（这是什么意思？）
通信（Wiki、Mail、IM、Mailinglists、其他文档）：Wiki、Mail、IM、Mailinglists
努力估计：是
团队规模：2-4人
会议：每周一固定会议，隔日浮动会议
代码指标：是
静态代码分析：否
错误跟踪：是的
你看过 NDepend 吗？该工具分析 C# 和 .NET 代码，并带有许多很酷的功能来浏览分析结果。使用 NDepend，您可以编写代码规则，可以比较代码库的 2 个版本，并且可以利用80 多个代码指标。
此外，该工具还具有几个出色的可视化功能，例如：
依赖图：
依赖矩阵：
通过树形映射实现代码度量可视化：
很高兴听到 MDA、DDD 和结对编程在任何地方都没有使用：D Martin Fowler 不是上帝，只是有一些奇怪想法的人。