Questions tagged «teamwork»

为您提供一些背景知识：我在一家大约有十二名Ruby on Rails开发人员（+/-实习生）的公司工作。远程工作很普遍。我们的产品由两部分组成：一个相当肥大的核心，然后精简到以此为基础的大客户项目。客户项目通常会扩展核心。不会覆盖关键功能。我可能还会补充说，核心中有一些非常糟糕的部分，这些部分迫切需要重构。有规格，但主要针对客户项目。核心的最差部分未经测试（不是应该的……）。 开发人员分为两个团队，每个sprint使用一个或两个PO。通常，一个客户项目严格与团队和PO之一相关联。 现在我们的问题是：我们经常破坏彼此的东西。A团队的某人扩展或重构了核心功能Y，从而为B团队的一个客户项目造成了意外错误。通常，更改不会在团队中宣布，因此这些错误几乎总是无法预料的。包括PO在内的B团队认为功能Y是稳定的，并且在发布之前未对其进行测试，并且没有意识到更改。 如何摆脱那些问题？您可以推荐我什么样的“公告技术”？

20 teamwork  communication  customer-relations  errors 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我是猫王，努力学习成为爱因斯坦。我为Mort工作。 这个疯子白痴在说什么！？！？（您只需要阅读前几段） 如果您不想阅读该链接，那么基本上，我是一名专业程序员，而我的老板是（这非常准确）： 缺乏计算机科学学位但对Office和VBA十分熟悉的专业业务线程序员，通常编写在同事之间共享的生产力应用程序 话虽这么说，我的大部分工作是将他拼凑的代码准备好并投入生产。但是，非常差的风格和杂货主义使这变得困难。他不愿意阅读编程书籍或不愿意让我帮助他重构代码，这使情况更加复杂。 还有其他一些策略可以帮助不是专业程序员的人，也永远不会成为专业程序员编写对我而言更易读和易用的代码吗？

20 development-environment  teamwork  maintenance 

我们正在开发一个应用程序；它包括由另一个编码器开发的库，该库通过多个网络连接与服务器通信，并且涉及多个线程一起工作。服务器端代码非常复杂，我们无法访问源代码。 最近，我发现了一个Mandelbug有时会使应用程序崩溃。我可以重现一次并获得堆栈跟踪，因此打开了一个错误报告。该错误本身易于修复（后台线程之一中未捕获的Web异常，这使CLR终止程序）。 问题是开发人员拒绝修复该错误，因为“他不相信它的存在”。不幸的是，老板对我表示支持，并说除非我创建一个“可靠的测试用例”以证明该错误的存在并进行单元测试以确认该错误已消失，否则无法修复该错误。由于bug的性质，基本上是不可能的。 有什么建议吗？

20 project-management  teamwork  requirements  collaboration 

拥有许多敏捷Scrum团队的组织也只有一小部分人被任命为“企业架构师”。EA小组充当质量和对决策的坚持和控制者。这导致团队决策和EA决策之间出现重叠。 例如，团队可能要使用库X或要使用REST而不是SOAP，但是EA对此不赞成。 现在，当团队决策被否决时，这可能会导致挫败感。言归正传，它有可能导致EA人员“抢夺”所有权力，并且团队最终感到动力不足，甚至一点也不敏捷。 在Scrum的导游有这样一段话吧： 自组织：没有人（甚至不是Scrum Master）告诉开发团队如何将产品待办事项转换为潜在可发布功能的增量。 那合理吗？EA团队应该解散吗？车队应该拒绝还是仅仅遵守？

20 agile  scrum  teamwork  architect 

很难说出这里的要求。这个问题是模棱两可，含糊，不完整，过于宽泛或夸张的，不能以当前的形式合理地回答。如需帮助澄清此问题以便可以重新打开， 请访问帮助中心。 8年前关闭。 此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 我开发了当前的项目架构，并开始自行开发（达到revision 40）。 我们正在开发一个简单的地铁路线框架，我的设计似乎做得非常好- 几个主要模型，相应的视图，主要逻辑和数据结构均按“应有的方式”建模，并且与渲染完全分离，并且还实现了算法部分除了主要模型之外，交叉点数量很少。 我将这种设计称为可扩展，可定制，易于实现的设计，它主要基于“黑匣子交互”进行交互，而且很好。 现在，完成了什么： 我开始了相应接口的一些实现，移植了一些方便的库，并为一些应用程序部分编写了实现存根。 我有描述编码风格的文档以及该编码风格用法的示例（我自己的书面代码）。 我强迫使用或多或少的现代C++开发技术，包括no-delete代码（通过智能指针包装）等。 我记录了具体接口实现的目的以及应如何使用它们。 单元测试（大多数情况下是集成测试，因为没有很多“实际”代码）和所有核心抽象的一组模拟。 我缺席了12天。 我们现在拥有什么（该项目是由团队的其他4位成员开发的）： 3个不同的编码风格遍布项目（我猜，他们两个人同意使用相同的样式:)，同样适用于我们的抽象的命名（例如CommonPathData.h，SubwaySchemeStructures.h），它们基本上头宣布了一些数据结构。 绝对缺乏有关最近实施的零件的文档。 我最近称之为“ single-purpose-abstraction现在”的事件至少可以处理2种不同类型的事件，与其他部分的关系紧密等等。 现在，一半的已使用接口包含成员变量(sic!)。 原始指针的用法几乎无处不在。 单元测试已禁用，因为“ (Rev.57) They are unnecessary for this project”。 ... （可能不是全部）。 提交历史记录表明，我的设计被认为是一种过大的技巧，人们开始将其与个人自行车和重新实现的车轮结合起来，然后在集成代码块时遇到了问题。 现在-该项目仍然只执行其少量工作，我们存在严重的集成问题，我假设有一些内存泄漏。 在这种情况下有什么办法可以做？ 我确实意识到我的所有努力都没有任何好处，但是截止日期很快就到了，我们必须做些事情。有人有类似情况吗？ 基本上，我认为为该项目做好一个良好的开端（好吧，我已尽力）可能会带来一些好处，但是，我知道我错了。

20 c++  project-management  refactoring  teamwork 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 ……新员工应该具备的最重要的功能之一就是与已经在那里工作的人们的精神相适应。 {...} 我深信，深入了解开发人员的真实个性与检查专业能力同等重要，因为一个不合适的人选会破坏整个团队。 从招聘开发商-你就错了 这是真的？而且，如果是这样，对经理来说也是如此吗？

20 teamwork 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我们目前正在面试几名应聘者，这对于我们公司和团队领导/经理来说都是一种全新的体验。 对于双方来说，什么是最有效，最有用但又有趣的方法？我们如何将实习生“集成”到我们的开发团队和工作流程中，而又不会造成太多干扰，以使他或她可以学习却又很有帮助？

19 teamwork  internship 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 6年前关闭。 免责声明：标题没有夸张，但仍然让我感到不舒服。我只是要诚实地表达，所以要加一点盐。只是假装我谈论的是编码标准，你不喜欢的工作。 编辑：我不喜欢它的事实，并不意味着我不使用它或不执行它。 我决定本着如何超越您不喜欢的标准的精神来问这个问题，而不是寻求有关如何更好地争论如何进行更改的帮助（尽管对最后一部分的任何评论都值得赞赏）。此外，我在一家大公司工作，这种改变已经存在了很长时间，而且影响很小的事情是不可能的。 该标准是专用线路上的开口弯括号标准： somefunction() { //... } 代替*明显优越*（注意开玩笑/沮丧的语气）： somefunction() { //... } 我个人反对该标准： 它使代码膨胀：多余的多余行 很难键入：尽管这可能只是我在标准方面的苦苦挣扎，但我知道额外的一次击键并没有那么糟糕。 不容易阅读：我开始阅读函数声明，if语句或任何其他范围堆叠语句，而我不必寻找左括号。嵌套块与此标准只是出于某种原因使我生气。 由具有Microsoft IDE背景的人使用：我认为标准背后应该有一个有争议的理由（或更多理由），而不仅仅是范式。 他们的论点（以及我内部反驳他们的方式）： 易于阅读，因为您可以立即看到块的开始和结束位置：我不明白这一点，如果您不知道块的所有权，那么块有什么用，所以您必须向后阅读。 我在Microsoft IDE中使用它，然后我喜欢它：呃...好吗？ 在标准中：*压脚* 我是唯一一个对特定标准持固执己见的人吗？您如何克服这些标准？您对此特殊标准应该是什么持保留意见（只是为了好玩）？

18 coding-style  coding-standards  teamwork 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 我最近问过要离开一个职位，并得到了很多很好的答案。共同的思路之一是，可以训练新人，并且可以走很长一段路。 现在考虑到（我认为）大多数人在接到通知后不会在公司呆很长时间，而且公司面试/雇用一个人会花费一些时间-剩下的时间很短加快步伐。 我也从未训练过任何人。我曾在大学和学院里做过很多补习，但是教授语言/技术与培训某人以代替您代替您的工作有很大不同。 因此，问题是：您将如何训练某人在短时间内替换您？

18 teamwork  knowledge-transfer 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 8年前关闭。 因此，我确定每个人都在某个方面碰到了这个人，有人抓住了您的项目或想法，并开始表现出一些兴趣。您将讨论一些方法，通常在这个时候左右，它们插在一起说明您应如何使用方法X代替，或者仅使用库Y。但这不是一个友好的建议，而是与一条诫命接壤的。经常像狂热的鹦鹉一样一遍又一遍地重复同样的建议。 就个人而言，即使事实证明比以前做的还要糟糕，我还是喜欢在学习时重新发明轮子，甚至只是为了娱乐。但是，这个人显然无法为这种目的而重新创建任何实用程序，或者可能尝试不严格遵循传统OOP做法的东西，除了他们的完美意识之外，什么也不会解决，因此自然而然地将他们的批评淤泥压在我的耳朵上。最重要的是，他们最终通过列出所有他们一手编写的难以置信的复杂代码（通常遵循“相信我，我已经/使用了很长时间的程序X”的思路）来证明自己的建议（延迟）。 ， 等等等等等等”）。 现在，我还远不是编程专家，我可能还不够好，因此我很重视建议和评论，但是我认为建议/评论有时间和地点。有帮助和自恋之间也有很大的不同。过去，我可能会采用某种程度更强的乔治·卡林（George Carlin）风格解雇，但我认为燃烧桥梁不再是最好的方法。 您对如何处理这种口头鞭log有任何建议吗？

18 teamwork  communication 

我在一个项目中担任前端角色。是否应该为我的后端团队成员指定他们的PHP返回我的JavaScript的JSON确切格式？ 例如，我应该告诉他们，他们应该使用类似于此处所述的格式： 构造JSON以便前端使用的正确方法 还是应该尽可能地保持角色的无菌，只用文字描述我从后端接口需要的输入和输出？（当然，如果发生这种情况，就我而言，处理它们的不同数据结构格式可能会更加困难）

17 development-process  teamwork  interfaces  json  front-end 

在我的公司中，我们成功地采用了敏捷实践，但没有使用迭代。主要原因是我们找不到在迭代周期中适合QA的干净方法。 我们认为质量检查是对特定版本（候选版本）进行额外验证的一部分，然后再将其部署到客户。关键是要避免单个恶意提交会损坏整个发行版。由于您永远都不知道它是哪一个，因此质量检查人员必须等到该版本的所有功能/提交都在构建中。（不允许使用著名的最后一句话“这只是微小的变化”。） 如果质量检查人员在候选发行版中发现错误，则开发人员会在相应的发行分支中修复这些错误（并将其合并到主干中）。修复所有错误后，将部署新版本以进行质量检查以进行重新测试。仅当在某个发行候选版本中未发现错误时，才将其提供给客户进行验证。 每次发布通常需要大约2-3个候选人，大约一周。编写修补程序的时间通常比测试工作要少得多。因此，为了让开发人员忙，他们在版本N + 1上工作，而质量检查则在N上工作。 不使用迭代，这没问题，因为我们可以将版本N和N + 1的工作重叠。但是，据我了解，这与Scrum或XP等基于迭代的方法不兼容。他们要求在迭代结束时发布一个迭代，并将所有测试工作都包含在迭代中。 我发现这必然导致以下不良结果之一： （A）开发人员在迭代结束时处于闲置状态，因为质量检查需要时间来验证发布候选版本，并且错误修复工作并未完全使开发人员处于忙碌状态。 （B）质量保证在准备好第一个候选版本之前就已经开始工作。这是Stack Exchange上最推荐的方法。但这不是我公司所理解的质量检查，因为没有经过测试的特定候选发布版本。破坏一切的“微小变化”仍然可以被忽略。 （C）错误将继续进行下一次迭代。在Stack Exchange上也建议这样做。我认为这根本不是解决方案。从根本上讲，这意味着我们永远不会获得经过验证的内部版本，因​​为只要进行了错误修复，就会将未经验证的新提交也添加到同一分支中。 有没有办法摆脱这种困境？

17 agile  teamwork  qa  sdlc 

我正在寻找一种有效的方法来向现有团队成员介绍OOP概念，但这并不是侮辱。我的队友对OO语言并不陌生。我们从事C ++ / C＃已有很长时间了，因此对技术本身很熟悉。 但是，我环顾四周，并且没有付出很大的努力（主要是以代码审查的形式），似乎我们正在生成的是恰巧在类内部的C代码。仅举几例，几乎没有使用单一责任原则，抽象或试图最小化耦合的尝试。我见过没有构造函数的类，但每次实例化时将memset设置为0。 但是每次我提起OOP时，每个人都会点头并让他们看起来好像完全知道我在说什么。知道这些概念是件好事，但在交付实际工作时，我们（比其他人更多）似乎很难应用它们。 代码审查非常有帮助，但是代码审查的问题在于它们仅在事实发生之后发生，因此对于某些人来说，我们似乎最终重写了刚刚编写的代码（它大部分是重构的，但仍然要花费很多时间）。另外，代码审查仅提供反馈给单个工程师，而不是整个团队。 我正在做一个演示文稿（或一系列）的想法，然后尝试再次提出OOP以及一些本来可以编写得更好并且可以重构的现有代码示例。我可以使用一些没有人拥有的非常老的项目，因此至少那部分不应该是一个敏感的问题。但是，这行得通吗？正如我所说的，大多数人已经做过C ++很久了，所以我的猜测是：a）他们会坐在那里思考为什么我要告诉他们他们已经知道的东西； b）他们实际上可能会将它当作侮辱，因为我告诉他们他们不知道如何做他们已经从事多年甚至数十年的工作。 是否有另一种方法可以比代码审查更广泛地吸引读者，但同时又不会像惩罚性演讲那样？ 我不是一个刚大学毕业的孩子，他对理想的代码设计有着乌托邦式的理想，我不希望任何人都能做到。我之所以写这本书，是因为我只是对一个实际上在纸上有不错的高级设计的人进行了评论。但是，如果您描绘类：A-> B-> C-> D，则在代码B，C和D中都实现几乎相同的公共接口，并且B / C具有一个内联函数，因此最高级的A类绝对在做所有工作（包括内存管理，字符串解析，设置协商...）主要以4种mongo方法进行，并且出于所有目的和目的，几乎都直接调用了D。 更新：我是一名技术负责人（担任该职位六个月），并得到了小组经理的全力支持。我们正在开发非常成熟的产品，并且维护成本绝对是众所周知的。

17 object-oriented  teamwork 

有时，通过方法和彻底的搜索可以发现软件性能的窍门。有时，需要疯狂的思维和勇气尝试疯狂的想法。有时，一个想法只是开始，需要大量的努力。 如何营造一个每个人都可以尝试不同想法以改善我们正在开发的软件性能的时间？团队中的每个人都有至少几个月的软件使用经验，并且非常擅长该软件。 您是否同意不同的想法将有助于找到提高软件性能的方法？为什么？为什么不？ 哪些技术可以使我们快速尝试优化想法？为了从试用中获得良好的结果，是否需要快速的编码速度？ 最后，应分配多少“时间”以确保良好的结果而又不会造成懈怠？ 是否有必要进行实验以证明存在“做某事的更快方法”？（添加2011-06-07） 有关： 您有什么策略巧妙地提高团队水平？ 什么时候代码黑客会变得糟糕？ （仅出于赏金目的， -2011 / 06/07团队规模为2-4个开发人员，无专门的质量检查人员。所有代码，单元测试和性能测试均由开发人员完成。由于项目的性质，探查器结果可用于显示比例执行时间，即使它没有显示出单个瓶颈。）

17 performance  teamwork 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 我还在上学，我知道我在与其他人打交道时遇到问题。 我不是生气，害羞或与众不同，我只是喜欢以自己的方式和意见去尊重他人，我有很大的好奇心和知识的渴望，但是我缺乏练习，我想人们不想工作和我在一起，因为他们可能担心我会说出某种士气。（例如，即使我经常使用Windows，我也开始学习使用Linux而不是Windows进行编程。并且我有Mac）。 缺乏团队合作的程序员会怎样？问题从哪里开始？成为一名优秀的程序员至少能获得一点补偿吗？程序员对自己的工作有远见而不是仅仅按照所告诉的做是正常的吗？

17 teamwork