Questions tagged «team»

免责声明：我是新来者（这是我工作的第三天），我的大多数队友比我更有经验。 查看代码时，我会看到一些代码气味和不良的工程实践，例如： 命名准则有些不一致 可能时属性未标记为只读 大型类-我注意到一个实用程序类，其中包含数百个扩展方法（对于许多类型）。它超过2500行！ 大型方法-我正在尝试重构一种150行长的方法。 后两者似乎是一个真正的问题。我想说服队友使用较小的类和方法。但是我应该这样做吗？如果是，那怎么办？ 我的团队从主要团队（我们是卫星团队）中获得了导师。我应该先去找他吗？ 更新：由于一些答复询问该项目，因此请知道这是一个有效的项目。恕我直言，这么大的类/方法总是不好的。 无论如何，我永远不想惹恼我的团队。这就是为什么我问-我应该这样做，如果是的话，那么我该如何轻轻地做到这一点？ 更新：我决定根据公认的答案做某事：因为我是新来者，所以我以“新鲜的眼睛”看到一切，我会记下我发现的所有代码气味（位置，为什么不好，我们怎么做）更好，...），但此刻，我只是努力争取团队的尊重：写出“更好的代码”，认识人们，知道我们为什么这样做...在适当的时候，我会尝试向我的团队询问一些新的代码策略（命名准则，较小的类，较小的方法等），并在可能的情况下重构一些旧代码。它应该工作，恕我直言。 谢谢。

27 .net  code-quality  team  refactoring 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 已锁定。该问题及其答案被锁定，因为该问题是题外话，但具有历史意义。它目前不接受新的答案或互动。 每个团队都在发生这种情况。 由于某些原因，团队中会发生冲突，它们会影响总体动力和生产力。 您建议采用什么方法解决该常见问题？ 例子： 团队的一部分希望实施依赖注入，另一部分则认为这是浪费时间。 一些开发人员认为团队的其余成员正在减慢开发速度（这说明了为什么他们按计划迟到了） 一个或多个开发人员之间的个人不兼容性 一位开发人员拒绝与另一位开发人员交谈（无明显原因）

26 team  problem-solving 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 四年来，我一直是一家小型公司的独立开发人员。我们在利基行业中拥有一些完善的产品。我们将很快雇用1-2名开发人员，这很可能会改变这里的运作方式。 虽然我没有“真正的”头衔，但我将“负责”这支球队。我要做的是为我的公司建立一个组织严密且富有成效的编程部门。我刚从大学毕业就获得了这份单独工作，因此，尽管我已经精通该行业的程序员，但我却缺乏很多团队编程经验。我觉得从右脚开始将是关键。 现在只有我，几台计算机和一台SVN服务器。我正在寻找有关从头开始建立团队的任何一般指导。

25 teamwork  team  solo-development  knowledge-transfer 

在“ 处理我过时的同事”问题中，许多人讨论了与不愿将工作流与团队的工作流程整合在一起的同事打交道的策略。 我想，如果可能的话，学习一些策略来“教”一位不了解现代技术和工具的同事，并且可能有些冷漠。 我已经开始与一位程序员合作，直到最近，他一直在公司的不同部门进行相对隔离的工作。他具有丰富的领域知识，最重要的是，他展示出了很好的解决问题的能力，而这是许多候选人似乎所缺乏的。 但是，我看到的实际（C＃）代码是对VB6天的回顾。程序结构，匈牙利符号，全局变量（的滥用static），没有接口，没有测试，不使用泛型，抛出System.Exception...您就会明白。 这个程序员比我年龄大一点，至少从第一印象来看，他并没有积极寻求积极的改变。我不会说要抗拒变革，因为我认为这很大程度上是有关如何提出主题的问题，我想做好准备。 程序员往往是固执的人，大肆宣传，建立撕碎的代码审查和严格执行的政策很可能不会产生我想要的最终结果。如果这是一个新员工，一个初级程序员，那么我不会三思而后行地采取“导师”的立场，但是我非常谨慎地将有经验的员工视为无知的新手（他不是-他只是没有与该领域的某些进步保持同步）。 我如何通过柔和的说服力和非实质性的激励措施以Dale Carnegie的方式提高开发人员的代码质量标准？在不造成对抗性情况的情况下，进行细微，渐进式变化的最佳策略是什么？ 之前是否有其他人（尤其是首席开发人员）遇到过这种情况？哪些策略成功地激发了兴趣并创造了积极的群体动力？哪些策略没有成功，会更好地避免？ 说明： 我真的觉得有些人是根据个人的感觉来回答的，而没有真正阅读问题的所有细节。请注意以下内容，这些内容本应暗示，但我现在要明确指出： 由于年龄的原因，这个同事只是我的“高级”。我从未说过他的头衔，势力范围或在该组织的任职年限超过我，而实际上，这些都不是真的。他是一名LOB程序员，已经被主要开发部门所吸引。而已。 我不是新员工，也​​不是初级程序员，也不是其他幼稚的白痴，他们都计划在一夜之间将公司转型。我基本上负责软件过程，但是正如许多作为“潜在客户”工作过的人所知道的那样，职责并不总是与组织结构图完全相关。 我不是在问别人如何走我的路，来死还是要高水。如果我愿意，我可以这样做，最终结果是这个人会变得不满和/或辞职。请尝试了解我正在寻找一种社交，合作的方式来推动变革。 提到“ ...全局变量...没有测试...抛出System.Exception”是为了证明问题不仅是表面的或美学的。可能适用于相对较小的CRUD应用程序的做法不一定适用于大型企业应用程序，实际上，到目前为止，没有代码实际通过了集成测试。 请尝试从表面上看待这个问题，接受我实际上知道我在说什么，然后回答我实际提出的问题或继续前进。 PS对那些提供建设性建议而不是与前提争论的人，我表示由衷的感谢。我希望将其保留一段时间，因为我希望能从现实生活中听到更多。

24 programming-practices  project-management  team  team-building 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 我一直在想为我的团队将要开发的新开源产品做出贡献。我们鼓励我们尽可能地从更广泛的社区中获得支持，但是我也可以看到这花费了大量的时间，以确保位于办公室外的第三方能够按计划处理诸如代码质量之类的事情。同样在项目开始时，我们可能会在核心团队中进行许多有关系统设计，峰值等的非正式讨论，将这些在线获取以允许社区参与将非常耗时，我可以想象可以使讨论效果较差。 这可能需要考虑更多的人性化方面：允许社区参与设计过程也可以从感知到的项目所有权方面受益，并且总是有可能早期参与可以解决核心问题。团队没有注意到。 那么问题来了：您应该在开源项目的哪个阶段邀请社区的贡献？

23 project-management  open-source  team  contribution  planning 

最近，在我公司中，有人建议一位开发人员应该（仅一位）专注于一项功能。这意味着要像将开发人员置于正常的团队常规工作之外，再将其承担其他职责（会议等），而此人将是负责该功能（技术上明智）的“唯一”人员。 作为记录，我们在SAFe中使用SCRUM，并且每个团队都有专职开发人员，在我们两个团队（Android和iOS）之间共享质量检查和产品所有者。 尽管我同意这会在短期内提高生产率，但我有一种感觉（我认为我是在大学里学到的），这是一个不好的做法，原因有很多： 代码审查失去价值。 最少的知识共享。 风险增加。 失去团队灵活性。 我说的对吗，或者这不是一个坏习惯？

22 agile  team  code-ownership 

我是一个由11位软件开发人员组成的团队的经理，他们负责管理我公司的网站/ Web应用程序，并随时运行多达4个并发项目以及日常支持。在11位开发人员中，技术技能，职称和经验混合在一起，尽管团队结构是平坦的，所有11位开发人员都直接向我报告。 整个团队只有一名经理，现在开始证明扩展性不是很好。我的传播范围太窄了，因此想减少直接报告的数量。我认为实现此目标的所有方式都有很大的缺点： 让初级开发人员向高级开发人员报告。这样可以减少最佳技术人员在开发上花费的时间。 按软件产品划分团队，例如，开发人员1-6在Intranet上工作，而7-11在外部站点上工作，每个部分都有新的团队负责人（可能是新职位描述，与当前的高级开发人员相比，具有更多的管理/指导/指导职责） ）。这增加了人为的孤岛，并且如果我希望他们这样做的话，可能会很难使“内部网开发人员”在外部网站上工作。 保持结构平坦，以项目经理/团队管理员的身份添加管理支持，以减轻压力。这不能解决问题，因为团队无法永远这样成长。 有没有解决我所缺少的这个问题的标准方法？ 如果没有，你们中的其他人如何解决了这个问题？

22 management  team 

我在职业生涯中遇到的一个反复出现的主题是成为新的开发人员加入团队，并很快对现有的单元和集成测试套件产生内在的不信任。 在面试过程中，管理层告诉您，他们“大力支持单元测试”，并公开鼓励他们进行测试。他们可以，但是关于测试本身的一切都是错误的。就像他们声称拥有100％集成测试覆盖率但少于10％可重复单元测试覆盖率时声称100％覆盖率这一事实。我发现了一些其他问题： 在什么是单元测试和什么是集成测试之间没有明确的指示。单元测试和集成测试在同一个类别中混合在一起。 尚未声明对特定环境的数据库中非常特定的动态数据有明确依赖关系的集成测试。 非事务集成测试，基本上是可能会或可能不会麻烦自行清理的测试，有时需要手动数据库“清理”以使测试可重复。 绝不进行任何模拟，而应用程序代码则需要进行大修，以使模拟成为可能。换句话说，设计时不要考虑测试。 没有明确的命名约定可以快速查看测试名称并大致确定要进行的测试。 这并不是说所有测试都是无用的或不好的，很多测试都相当好并且值得保留，但是有时候感觉就像淘金。我故意避免运行测试，只是因为我担心为黑箱测试用例搞砸数据库。 从本质上讲，这使我对单元和集成测试产生了固有的不信任感，而我个人没有以某种方式编写或审查这些测试。在某种程度上，如果您对测试套件的质量不抱有信心，那么它实际上对团队或项目毫无价值。 当您发现自己处于这种情况时该怎么办？您认为最佳的攻击计划是应对此类问题？ 是否应该在跨发行版的巨大努力下重构所有测试？您是否应该放弃这个旧项目可能会有一天可靠的单元测试范围的想法？

21 unit-testing  team  refactoring  bad-code  integration-tests 

此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 我的团队负责人有着糟透的习惯，那就是想弄乱数据库架构，并进行会导致代码库严重破坏的更改（没有真正咨询过我这些更改如何影响代码库）。 通常，我会接受它，但是我们有两个星期的截止日期，而且自从我在一个半月前开始工作以来，这种情况一直在发生。我被带进来，以加快项目的开发。 由于截止日期，我已经每周投入60多个小时，而实际上没有足够的精力来解决这个问题（我已经尝试过一些方法）。我们只有两个人组成的团队，除了每天更改数据库外，他在实际开发（编码）方面的贡献不大。 目前，我感觉自己正在完成所有工作，而且还必须“修复”他所做的更改所导致的问题。 如何处理呢？我已经与我们的经理谈过他在开发部门缺乏工作的情况。他到那里的时间比我多了6个月，但是当您排除他“贡献”的第5个正常形式数据库异常时，我已经写了95％的代码。 有什么建议么？ 验尸： 星期五我们与经理进行了讨论，我的忧虑已广为人知。这导致了一些对抗，但是总的来说，我觉得经理正在陪伴我。因此，至少现在我们已经冻结了数据，让我们看看它是如何发展的。

21 communication  team 

我们是一群定期打地板球的人。每节课都是从划分团队的艰巨任务开始的。 那么，有什么比自动选择团队更好的选择呢？ 因此，鉴于团队组合和结果的历史记录，以及参加此特定会议的人员列表，找到最佳团队的最佳策略是什么？最佳来说，我指的是尽可能多的团队。 有任何想法吗？ 编辑：为了清楚起见，我必须根据其选择的数据将是这样的： [{ team1: ["playerA", "playerB", "playerC"], team2: ["playerD", "playerE", "playerF"], goals_team1: 10, goals_team2: 8 }, { team1: ["playerD", "playerB", "playerC"], team2: ["playerA", "playerE", "playerG"], goals_team1: 2, goals_team2: 5 }, { team1: ["playerD", "playerB", "playerF"], team2: ["playerA", "playerE", "playerC"], goals_team1: 4, goals_team2: 2 }]

20 algorithms  strategy  team 

尽管我在个人项目中使用并喜欢DVCS，并且可以完全看出它如何使其他人对项目的贡献进行管理（例如，典型的Github方案），但对于“传统”团队而言，似乎存在一些问题。 TFS，Perforce等解决方案采用的集中式方法。（“传统”是指办公室中的一组开发人员在一个项目上工作，没有一个人“拥有”，可能每个人都在使用相同的代码。） 我已经预见了其中的几个问题，但请考虑其他因素。 在传统系统中，当您尝试将更改签入服务器时，如果以前有人签入了冲突的更改，则您将被迫合并，然后才能签入。在DVCS模型中，每个开发人员都会签入他们的证书。本地更改，并在某个时候推送到其他回购。然后，该仓库中有一个由2个人更改的文件分支。看来现在必须由某人负责处理这种情况。团队中的指定人员可能没有足够的整个代码库知识，无法处理所有冲突。因此，现在增加了一个额外的步骤，即有人必须与这些开发人员之一联系，告诉他进行合并并再次推送（或者您必须构建一个自动化该任务的基础结构）。 此外，由于DVCS倾向于使本地工作变得如此便捷，因此开发人员很可能会在推送之前在其本地存储库中积累一些更改，从而使此类冲突更加常见和更加复杂。 显然，如果团队中的每个人都只在代码的不同区域工作，这不是问题。但是我很好奇每个人都在使用相同代码的情况。集中式模型似乎迫使人们快速而频繁地处理冲突，从而最大程度地减少了进行大型痛苦合并或让任何人“警惕”主仓库的需求。 因此，对于与办公室中的团队一起使用DVCS的那些人，您将如何处理此类情况？您是否发现您的日常（或更可能是每周）工作流程受到负面影响？在工作场所推荐DVCS之前，我还有其他注意事项吗？

20 version-control  dvcs  team 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我从12岁起就开始（一直在痴迷）编程，从汇编，C ++，Javascript，Haskell，Lisp和Qi的各种语言中我都非常了解。但是我所有的项目都是我一个人做的。 我获得了化学工程专业的学位，而不是计算机科学或计算机工程专业的学位，但是今年秋天我第一次与其他人一起从事大型编程项目，而且我不知道如何准备。我一生都在使用Windows，但是这个项目将非常适合Unix，因此我最近购买了一台Mac，希望自己熟悉环境。 去年，我很幸运地与一些朋友（包括CS专业）一起参加了黑客马拉松，令人兴奋的是，我们赢了。但是当我与他们一起工作时，我意识到他们的工作流程与我的非常不同。他们使用Git进行版本控制。当时我从未使用过它，但是从那以后我就学会了所有关于它的知识。他们还使用了很多框架和库。我必须了解Rails在黑客马拉松比赛中几乎是一夜之间（另一方面，他们不知道什么是词法作用域或闭包）。我们所有的代码都运行良好，但是他们不了解我的代码，而我也不了解他们的代码。 我听到了真正的程序员每天做的事情的引用–单元测试，代码审查，但我对这些内容的含糊不清的感觉。我通常在我的小项目中没有很多错误，因此我从来不需要错误跟踪系统或对其进行测试。 最后一件事是，我花了很长时间才能理解其他人的代码。变量命名约定（随每种新语言而异）很困难（__mzkwpSomRidicAbbrev），我发现松散耦合很困难。这并不是说我不会松散地做一些事情-我认为我对自己的工作很擅长，但是当我下载Linux内核或Chromium源代码之类的东西来查看它时，我花了数小时来尝试找出所有这些奇怪命名的目录和文件如何连接。重新发明轮子是编程上的罪过，但是我经常发现，自己写功能要比花费数小时来剖析某些库更快。 显然，以此为生的人没有这些问题，我需要自己解决这一问题。 问题：我可以采取什么步骤与其他人开始“整合”？ 谢谢！

19 programming-practices  development-process  team  solo-development 

在我从事的较传统的项目中，项目经理（在较大的项目中，如果没有人，则可能会有副/副/助理项目经理）是负责与客户沟通，接收项目的人运行状况和状态更新，确定计划和预算，管理流程，确保团队拥有完成任务所需的东西，等等。 但是，在Scrum中，这些责任在产品负责人和ScrumMaster之间分配。产品负责人是客户的声音。他们直接与客户互动，创建用户案例，组织积压的产品并确定优先级，以及其他面对用户/客户的问题。ScrumMaster处理流程，监督会议（包括评估和计划），消除障碍并监视项目的整体运行状况，并根据需要进行调整。 我已经阅读了包括Wikipedia在内的多个来源，ScrumMaster和产品负责人的角色应该由两个不同的人担任。我不仅阅读了有关内容，而且还参与了成功的“传统”风格项目，其中两个项目的活动都由一个人来处理。实际上，由一到三个人来负责项目（包括人力资源/人员）和流程级任务是更有意义的，因为它们经常是并行的。流程更改会影响计划，预算，质量和其他项目级别的目标，而项目更改也会影响流程。 为什么Scrum要求将这些活动分为两个角色？这实际上提供了什么优势？有没有人在一个成功的Scrum项目中，产品负责人和ScrumMaster是同一个人？

19 project-management  scrum  team  roles 

我们的10名开发人员团队每周开会。这些会议很无聊，并不是特别有用。您使用什么格式/议程召开会议？ 我们每周在会议室开会，提供比萨饼。格式是我们在会议室四处走动，并列出我们正在处理的各种任务的状态，并讨论下周的任务。经理将概述未来几个月和来年的即将到来的项目和优先事项。 更新资料 这些会议的目标或多或少是-建立总体团队，分享每个人正在做的事情的知识以及使每个人都知道公司的计划正在改变。并非要正式“分发”工作分配（通过其他方式完成）。

19 management  communication  meetings  team-building  team 

在任何团队中，您都将需要更多灰白色的开发人员和一些幼崽。一些原因包括： 钱。通常，有些任务不需要相同水平的经验即可交付，因此不要为完成这些任务付出高昂的代价。 能源。新人们可以带给团队充满活力和热情，以阻止其变得过时和过时。更高级的人可以带来平静和智慧。 知识转移和职业发展。无论是在项目还是在技能上，教人和学习新知识都是有用的，而且常常很有趣。帮助“培养”新的团队成员感到很满意。 我意识到有一些最前沿的项目，对于其中的高级人员要比初级人员要多，这可能很重要，但是总的来说，团队中是否有理想的经验组合，还是完全取决于项目？

19 team  organization