Questions tagged «teamwork»

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 7年前关闭。 我们可能都遇到过这样的人，那个开发人员只知道他的语言是一种真正的语言，并且不会为之闭嘴。你怎么像这样的人？我不想得罪任何人（尤其是因为我工作场所的狂热者是高级开发人员）。但是，当我不得不编写一个永远不会扔到存储库中的一次性脚本并且没有其他人需要知道的脚本时，我希望能够使用自己选择的脚本语言。 我必须处理的想法： 笑吧-“哈哈，是的，也许X语言要容易一些，我想我是受虐狂！” 顺其自然-我真的更喜欢避免这种情况，因为我承受不起与选择新语言有关的生产力下降。 隐藏我的语言-每当我编写脚本或自动执行某些操作时，请成为壁橱程序员并隐藏我的监视器。 您对此情况有何建议？

14 programming-languages  teamwork  language-choice 

奇怪的标题，是的，但是我认为我有足够的基础要掩饰。 我们在github上有一个带有专用存储库的组织帐户。我们要使用github的本机问题/拉动请求功能（就代码审查和功能讨论而言，拉动请求基本上正是我们想要的）。我们通过defunkt找到了工具中心，它具有一个很酷的小功能，它能够将现有问题转换为请求请求，并自动将当前分支与其关联。 我想知道是否最好的办法是让组织中的每个开发人员都分叉组织的存储库来完成其功能工作/错误修复等。这似乎是一个相当可靠的工作流程（基本上，这是github上每个开源项目所做的工作），但是我们希望确保我们可以跟踪问题并从组织存储库ONE来源提取请求。 所以我有几个问题： 在这种情况下，按开发人员分叉的方法是否合适？看来这可能有点过大。我不确定我们是否需要为每个开发人员准备一个分支，除非我们介绍没有直接推送访问权限并且需要审查其所有代码的开发人员。在这种情况下，我们只想针对那些开发人员制定这样的政策。那么，哪个更好？所有开发人员都在一个存储库中，还是每个人的叉子？ 是否有人对集线器工具（特别是拉动请求功能）有经验？如果我们按开发人员分叉（甚至针对特权较低的开发人员），那么集线器的请求请求功能将对上游主存储库（组织的存储库？）的拉取请求进行操作，还是有不同的行为？ 编辑 我对问题，分支和请求请求进行了一些测试，发现了这一点。如果在组织的存储库上创建问题，则将存储库从组织存储到您自己的github帐户，进行一些更改，并合并到存储库的master分支。尝试运行hub -i <issue #>时，出现错误User is not authorized to modify the issue。因此，显然，工作流程将行不通。

14 version-control  git  teamwork  github  workflows 

我面临的问题： 我的团队成员在没有准备好功能/技术文档的情况下就开始进行项目工作-即使我们公司的流程要求这些内容在开始之前也应存在。 我的团队成员接受便宜的，非结构化的解决方案，并且会在软件中实施真正的恶意入侵，而在项目管理人员指出他们“时间有限”时不会三思而后行。 我的团队成员开始进行与另一个团队的未完成项目一起工作的项目，该项目尚未经过测试和未完成。（造成大量额外工作）。 软件的改进和整个阶段没有得到适当的计划，当后端开发人员必须开始工作时，通常会导致前端/设计没有完成。 自从我在这里开始工作以来，这些问题已被无休止地讨论了多次。每个人都同意，最重要的是我们必须执行该流程，这意味着后端开发人员只有在处理完所有事情后才能开始。 这些问题一直在发生-直到我对工作本身和我的一些同事感到非常恼火，我才真正变得消极。 我的团队成员抱怨很多-但只能互相抱怨。They keep on going - whatever the situation is。结果？ 我变得不安全，也许是我吗？ 这就是应该发生的事情吗？ 我的问题？How can I say no against work ignoring the process if everyone else seems to mindlessly accept?。 这看起来并不像一些烦人的开发人员那样，他们一直都在寻找东西。

14 project-management  teamwork 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 我们的团队正在考虑进行“一周内的项目”（训练营），我想知道是否还有其他人有这样做的经验或任何建议？ 其背后的想法是摆脱办公室的干扰，相互激励，并在团队中建立我们的纽带，以便在短时间内提出创新和有利可图的产品。 计划是让整个开发团队（大约5个开发人员），设计师，项目经理，几个销售和市场营销人员在会议中心/酒店呆上一个完整的工作周。我们将完全专注于构建一个Web应用程序（预先计划）并在一周之内将其发布并投放市场。我们将工作很长的一天，但在晚上，我们将作为团队一起玩乐。为了确保我们不会因日常客户支持而分心，将有几个团队成员留在办公室。诸如Firebrand这样的培训公司也使用了类似的“沉浸式”方法。 好主意？糟糕的主意？我们应该如何激励团队？ 任何想法/经验/建议将不胜感激。 干杯

14 project-management  project  motivation  teamwork  team-building 

我的情况简介 我在一家小型Web开发公司工作。我们有一个由四个ASP.NET开发人员组成的团队，其中包括我。我们几乎所有项目（> 98％）都是一个人的项目，大约需要1-4周才能完成。我们不使用源代码或版本控制。我们唯一拥有的是本地服务器上的共享文件夹，其中包含所有项目的最新源（==实时应用程序的源）。 在极少数情况下，我们确实需要与一个以上的人一起从事同一个项目，我们使用...超越比较。开发人员每天一两次询问彼此是否有可编译的版本，然后使用Beyond Compare同步其代码。当只有两个人在一个项目上工作时，这“相当好”，但是一旦第三个开发人员进入流程，它就变成了难以处理的垃圾。尤其是当每个人都开始对数据库进行更改时。 我（和我的一两个开发人员）已经多次告诉我的老板，我们应该开始使用某种形式的源代码和版本控制，例如Git，Mercurial或TFS（我们的老板非常注重Microsoft）。不幸的是，我的老板没有看到切换到源代码和版本控制系统的优势，因为在他看来，现在一切都很好，并且他不想花费时间和金钱来建立新系统并确保每个人都知道如何使用它。即使在我向他解释了优点（例如简化的协作，应用程序的不同版本，更安全的代码更改方式……）之后，他仍然不认为这是我们所需要的。 在这四个开发人员中，只有两个（包括我在内）具有源代码控制（Git）的经验。而且这种经验非常有限。我知道如何将Github存储库克隆到我的计算机上，进行一些更改，提交它们并将其推回到Github。而已。 我的问题/担忧的解释 几周后，我们将开始为我们的标准开展一个相当大的项目。可能需要2-3个开发人员几个月才能完成。我将担任项目负责人（项目经理和首席开发人员），我将负责所有工作。我在使用“超越比较”方法时遇到了很多问题，并且我不想走这个大项目，这是我的责任。 由于我怀疑我们是否能够 设置我们自己的Git服务器， 教大家与Git合作 在这个大项目中成功雇用了Git， 我很感兴趣，如果你们中有人知道一些允许多人在不使用源代码或版本控制的情况下就同一项目进行协作的好方法。 更新资料 我要感谢大家的回答和评论。这是计划： 与开发人员举行会议，以确保所有技术人员对实现源代码控制的感觉相同。当所有人都支持时，我们会提出一个更强的观点。 向老板介绍这个想法，并告诉他我们确实需要源代码控制。 尽快实施。

13 development-process  version-control  teamwork 

使团队参与开发，Web开发或其他过程中使用版本控制的一些主要方法是什么？ 我拒绝没有它的工作，这意味着参与该项目的任何人也必须使用它。这只是个好习惯。 像Tower这样的GUI有所帮助，但是它的概念要么激怒（“不是我的工作！”，有点怯，），要么胆怯，或者直接不使用它（改用FTP，绕开了诸如开发，部署之类的版本控制） ）。 编辑：我应该澄清一点，我不仅仅是指图像/ PSD。

13 version-control  teamwork 

我目前有4个月的实习期，在查看我的代码时，我的老板不喜欢我在一个程序集中几个单独的类中的多个方法中保留了一个特定的对象。他不喜欢每次都创建一个新对象，而是告诉我创建一个可以从任何地方访问的对象。因此，我不得不将其创建为静态类中的静态对象，并从此处引用它以使用它！ 我只从事4个月的专业编程，您将如何处理呢？

13 teamwork  coding-standards  singleton 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 我刚刚开始从事一个包含30个开发人员的开源项目。我正在修复一些错误，以使其进入“循环”并成为项目的常规提交者。问题是我认为我发现了一个基本的设计缺陷，该缺陷导致了我正在研究的错误之一。但是我觉得，如果我在邮件列表上放开这个标签，我会觉得很自大，而我对此问题的一些讨论正在与某些人打交道。我应该怎么做？

13 open-source  teamwork  collaboration 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我领导一个开发团队，我想尽可能多地发布我们的产品（连续交付）。 在许多情况下，我们必须实施比发布之间的时间花费更长的时间才能实现的功能。我仍然希望人们每天提交他们的代码（持续集成）。 很多时候，实现新功能需要更改现有功能，并且即使新功能尚未完成，现有功能当然仍然需要工作。 如果开发人员使用正确的方法，则他们可以仔细调整现有功能，而上述所有都不是问题。 但是，正确的方法实际上是什么？我自己的编程知识告诉我如何处理每个案例，但是我需要了解更多信息，还需要一些阅读材料，我可以阅读并推荐团队成员阅读。或任何其他学习正确方法的方法都可以。 这就是问题所在。如何确保团队成员学习实现一半功能的正确方法？ 我搜寻了自称对此有策略的人，但还没有找到，只是人们对此主题写了一些随机的想法。也许我没有使用正确的搜索词，或者也许没有人对此做出任何权威性的指导。

12 teamwork  continuous-integration  knowledge-transfer  continuous-delivery 

首先让我创造一个名词： 代码目标：早上检查代码，然后静静地检查其他开发人员前一天在文件中所做的所有更改（尤其是您最初开发的代码文件），并修复格式，逻辑，重命名变量，重构长方法等），然后将更改提交给VCS。 我已经确定了这种做法的优点和缺点： Pro：经常保持代码质量/可读性/一致性 Pro：由于其他开发人员对原始代码不太熟悉，因此已修复了一些错误。 缺点：经常是那些追求目标的开发人员的时间浪费。 缺点：偶尔会引入一些错误，这些错误会引起开发人员的愤怒，他们以为他们前一天编写了没有错误的代码。 骗局：其他开发人员对过多挑剔的行为感到恼火，并开始不喜欢为目标投标人的代码做出贡献。 免责声明：公平地说，我实际上不是开发经理，而是实际上正在执行“目标管理”的开发人员。 在我的辩护中，我认为这样做是有充分理由的（为了使我们的超大型代码库保持良好运转），但我非常担心它还会带来负面气氛。我也绝对担心我的经理将需要解决这个问题。 那么，如果您是经理，您将如何解决这个问题？ 更新：我并不是说这个问题太过本地化，但是有人问过，所以也许会有一些启发性的背景。三年前，我被分配了一个巨大的项目（200K LoC），直到最近（一年之前），该项目中才添加了其他开发人员，其中一些人不熟悉体系结构，其他人仍在学习该语言（C＃）。我通常必须回答产品的整体稳定性问题，当对代码库的核心体系结构部分进行令人惊讶的更改时，我尤其紧张。养成这种习惯的原因是，起初我对其他开发人员的贡献感到乐观，但是他们犯了太多错误，这些错误导致了严重的问题，直到几周后才发现。通常这些“

12 version-control  code-quality  management  teamwork  team 

作为Web开发人员，我有将近5年的经验，并且觉得自己现在应该是中级人员，但是当我走路时，我觉得我仍然很“初级”。 我想这就是问题所在：在我的职业生涯的大部分时间里，我很少得到更高级的开发人员的任何实际指导，并且对开发团队的经验为零，所以我不得不通过许多解决方案来破解自己的道路，并尽一切努力切段，晒干。实际上，作为唯一负责编写或维护代码的人，没有时间可以浪费。因此，我对实际的软件开发过程没有正式的了解，最终意识到编码只是过程的一小部分。 我非常喜欢与具有丰富经验的开发人员团队一起工作，但恐怕要尝试调整开发过程所需的知识库会非常艰难。作为一个程序员，大部分时间都是自己的职业生涯，我该怎么做才能“融入”与更大（至少5个）经验丰富的团队合作的工作？ 编辑：为此，我还没有通过“大人物”公司给出的许多技术测试，这些公司在其软件和开发人员上蒸蒸日上。总的来说，我并不是说要像Google那样，而是在地理区域内相当成功。

12 teamwork 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 7年前关闭。 目前，作为多学科团队中的唯一开发人员，我在研究实验室中梦想中的工作。我有点担心，因为我忘记了在团队中进行编码（我没有遗留代码，我维护自己的代码，处理自己的议程，等等）。尽管我只是尝试遵循一些最佳实践，例如持续交付，TDD和SCRUM，但我认为我正在失去在一组开发人员团队中工作的能力。 我加入了一个开源项目，并开始研究代码katas和代码golf。但是这些不会完善我的团队成员的资料。 您对提高我的团队合作者技能有什么建议？ 更新：是的，我的沟通能力现在提高了，我可以前所未有地与博士交谈。就像@Nicholas和@Erick所说，总有一天，我将面对一个开发团队（也许正在我的工作中，也许没有），我想跟上那些使一个好的开发人员成为更好的团队成员的实践，例如结对编程或代码。评论。

12 teamwork  collaboration 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 5年前关闭。 在过去的8年中，我一直是一家小型初创公司的.NET程序员。我已经组装了一些相当不错的软件，并且我一直在努力改善自己，并遵循最佳实践，包括源代码控制（SVN / TFS）。我与其他学科的工程师团队紧密合作，但是当涉及到软件时，我是唯一的编程人员。我喜欢编程的技巧，也喜欢学习新知识以增强工具。 两周后，我将开始一个由20位.NET开发人员组成的团队的新工作。我的职位将是中级，并且我将在一些具有令人印象深刻的背景的程序员的带领下工作。同样，团队开发对我来说是新的，所以我正在寻找一些通用的“新手”技巧，这些技巧将帮助我尽可能高效，轻松地与一开始相处。 任何事情，包括高级技巧，以及与沟通有关的日常琐事。

12 team  teamwork 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 我们正在尝试对每次提交进行强制性代码审查-对于几个冲刺，没有任何东西被未经过至少1个人（而不是作者）验证的主人掌握。我们从开发人员和管理层那里都买进了（这是一个令人惊奇的情况），我们希望获得一些众所周知的好处： 明显减少错误 更加了解项目周围发生的变化 “我知道有人会看这个的，所以我不会偷懒” /反牛仔效应 增加项目内/项目间的一致性 但是我们正在引入一种已知的降低速度的方法，如果做错了，可能会在提交管道中创建一个愚蠢的官僚主义步骤，除了占用时间外什么也不做。我担心的事情： 评论只涉及尼特采摘 （大作）人们在两行提交审查中提出了巨大的架构问题。 我不想在其他事情上偏answers答案。 虽然我们都是有理智的人，并且会进行大量的自我分析，但我们可以肯定地使用一些赢得战争的见识，以了解我们应该在审查会议中尝试完成哪些事情才能真正使评论对我们有用。您发现可以使用的一些准则和政策是什么？

11 teamwork  code-reviews 

我正在制作一个git工作流程，以在一个小型团队中实施。工作流程中的核心思想： 有一个共享的项目主管，所有团队成员都可以写 所有开发仅在功能分支上完成 功能分支由分支作者以外的团队成员审阅的代码 功能分支最终合并到共享母版中，并且循环再次开始 本文详细解释了此循环中的步骤： https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md 这有意义还是我错过了什么？

11 version-control  git  teamwork  workflows