问您将如何改进一个小型开发团队的工作？

EN

对于你的小团队来说，你的想法似乎太宏大了，但我建议你从小到慢，逐步提高效率。

例如，虽然像持续集成这样的东西可以帮助大家提高构建的速度，希望能够提高版本的质量，但这只是因为每个团队成员一次单独工作在一个项目上。实现它只为提高构建的标准化和速度而花费的时间是值得的，而不是因为任何其他原因，考虑到您的团队设置。

然而，从一个简单的bug跟踪器转移到一个完整的任务管理解决方案将不会对任何人有帮助。如果每个团队成员单独工作，并有一个错误分配给他，这真的帮助他升级一个错误，通过状态和更新所有者和其他字段？这对那些不看他的代码的人有帮助吗？

你需要考虑什么改进才能带来真正的改变，而不是仅仅因为它们是要做的，你就想做哪些改进。

我会放弃所有的.net工作，让一个单独的团队成员使用不同的系统是没有意义的。我可能会使用一些VM来复制客户环境，这样测试或开发就可以更快地建立起来。我还想以某种方式管理每个客户的配置集。

在其他答案中有一些好的想法，特别是@gbjbaanb。然而，我不禁认为问题中缺少了一些东西。该团队目前有哪些问题？是什么阻止了团队对业务的成功做出充分贡献？

不进行持续集成并不是一个问题，除非它阻止了团队以高质量的方式交付。缺少任务管理系统并不是一个问题，除非团队正在失去任务的跟踪或在沟通状态上有困难。这些都是很好的实践，可能不会有什么坏处，但是如果它们没有解决那些阻碍团队直接成功的问题，那么管理层就不会感兴趣了。

你的出发点应该是诊断出交货中的问题在哪里，哪里有机会为公司的成功做出更好的贡献。问自己以下几个问题：

1. 团队能帮助企业成长吗？管理团队试图通过做软件开发的业务部分来完成什么？他们想扩大团队吗？他们在试图销售更复杂、更大的项目吗？是否有一些由于开发团队的成熟而无法实现的总体目标？
2. 目前是否存在影响业务成功的交付问题？从送货的角度看，你遇到的最大问题是什么？团队会错过最后期限吗？他们会理解错误的要求吗？你的客户对交付的工作质量有什么看法？团队是否能够对不断变化的客户需求作出反应？

根据这些问题的答案，你会明白哪些问题是最重要的首先解决，哪里有机会为公司的成长作出贡献。这有几种不同的方式可以发挥作用。下面是一些示例：

1. 一个常见的问题是缺乏透明度--即客户不知道系统是如何形成的，直到系统几乎完成，然后他们才对结果感到失望。对此的解决方案可能是在整个开发周期内更频繁地部署，并向客户公开正在进行的工作。CI可以通过确保构建的工作版本和将这些部署之间的集成问题最小化而有所帮助，但在这种情况下，关键是经常和尽早地将软件摆在客户面前。
2. 很可能是，这个团队只是在编写很难维护和很难修复的糟糕代码。例如，在这种情况下，CI和任务跟踪并没有多大帮助。您可能确实需要跨团队协作，或者需要代码评审，以确保质量。在这种情况下，对团队进行关于编写质量代码的最佳实践的教育也会有所帮助。
3. 你提到人们对他们自己的质量保证负责。这似乎是一个潜在的危险信号。测试是否自动化？这能帮助减少人工QA的工作量吗？在代码到达客户之前，请一个专门的QA人员负责集成测试，这样会更好吗？

所有这些问题都可能存在于您的环境中，或者根本不存在。关键是，在任何和所有的环境中，都没有一组有意义的改进。你需要被公司中存在的具体挑战所驱使。上面提到的任何所谓的“最佳”实践都可能有所帮助，但如果您正在解决不存在的问题，也可能会浪费精力和金钱。

我现在或多或少在你申请的职位上。现在还不到六个月，所以我缺乏经验来给你一个真正明智的建议，但以下是我到目前为止学到的东西。

首先也是最重要的，

你需要耐心

总有很多破碎的东西我们想马上修好。但是你只能给它分配这么多的资源，改变事物意味着需要时间去适应它，同时改变很多事情可能会疏远你的团队。

话虽如此，

您想要持续集成

你们，你们的团队，你们的阶层，你们的客户，你们都想要持续的整合。即使你们中的一些人不这么认为。设置一个具有增量构建、夜间构建、文档生成、自动测试、直接访问最新稳定包的构建服务器，您将为他们创造美好的一天。

你想摆脱任何浪费时间的东西

你的团队应该把时间花在做好事情上。但最有可能的是，他们花了相当多的钱去做一些完全没有成效的事情。找出所有偷他们时间的事情，他们不应该做的事，机器能做的事，不应该做的事情，并修正它们。你是他们中的一员，你知道哪里浪费时间，他们真正想做什么，对吗？

这个构建过程采取了十几个步骤，你只是“必须知道”？用一个脚本一劳永逸地完成它。由于某些原因，它不能完全自动化(还)，记录它！

要花两个小时才能完成的编译？尽一切努力把它减少到一个可以接受的时间:砍下它，剖析它，把任务分配给某人，但是不要让你的团队盯着编译屏幕。

这个问题每隔一个月就会回来，每次都要花半天时间才能弄清楚？修复它，真正修复它，为它编写测试，并确保测试是在每一个新构建时自动运行的(我这里甚至不讨论TDD，简单地说回归检验和自动化测试)。

你正在做的那个需要5分钟才能启动的项目？花上几个小时找出瓶颈，并让它在一瞬间启动。当你在做的时候，当你可以简单的重新加载数据时，为什么要重新启动呢？

早上需要十分钟才能启动的工作站？给它RAM，给它一个SSD，付出一切代价，这样它就不会浪费工程师的时间，当一百美元会削减它。

那台服务器花了那么多时间来处理你的请求，你真的想知道是不是测序DNA？找人来找出问题所在。

那些一天来几次的人，他们的要求还不完整，甚至还没有得到验证？告诉他们来找你或者特别找一个人，但不要让他们打断你团队的工作。让他们远离这些烦人的干扰，远离无关的细节，并给他们经过良好处理的信息，他们可以工作。

那一堆文件散布在intranet上，没有人知道该在哪里找到或使用哪个版本？把它放在同一个地方(或至少在同一个地方引用)，注明日期，并附上版本和联系人。

您的层次结构将不赞成其中的一些想法，但这里您最好的论点之一是技术债务隐喻。同时也要认识到不需要改变的地方：“如果它没有坏，就不要修复它。”或者换个说法，“值得花时间吗？”

另见：我怎样才能说服管理层处理技术债务？

你不想变得太疯狂

您的团队很小，所以不需要用过于复杂的过程来处理它们。嘿，重点是把东西从他们的路上拿出来！再一次，耐心点，一次换一次，让它沉进去，微调轮子，直到它平稳运行。

因为你的团队很小，你也可以做实验。一旦您确定了一个你想解决的具体问题 (例如，bug跟踪器太麻烦了)，看看有哪些解决方案可供您使用(bugzilla、Redmine、Trac、Atlassian、Trello、老式白板.)，然后尝试一种，也许只针对自己，也许只针对另一位团队成员，看看它是如何工作的，如何被接受，以及如何适应。解决办法却是不舒服的？试试别的吧。好点了吗？好好坚持下去。

这是我在这个话题上的两分钱。就像我说的，我对此也很陌生，所以我们非常欢迎对此了解更多的人发表评论。:)