Questions tagged «project-management»

好吧，问题本身就说明了。在我的工作场所中，会发生这些情况，而且，许多敏捷著作都提倡在同一工作场所工作，并专注于当前项目，以加快工作速度。 也许我对这个话题的了解不够，也许不是那么严格，但这就是为什么我想知道敏捷在此类情况下的建议。 有人吗

13 project-management  agile  team  scrum 

我的团队只是试图与code.google.com上一个旧的开源项目中的一些人联系。我们告诉他们，我们希望加入他们的项目并致力于该项目（至少是该项目的某个分支），但是没人响应我们。我们尝试了所有人，所有者和提交者；没有人以任何方式活跃，也没有人回答。 但是我们有一些代码要提交，我们真的很想继续该项目的工作。因此，我们需要创建一个新项目。我们为它想出了一个名称，该名称与我们要继承的项目的名称接近但不重复。我们应该如何进行第一次提交，提交消息应该是什么？我们是否应该仅将其代码复制到我们的存储库中，并加上诸如“我们继承了此代码，我们在某类许可下就在这里找到了它……现在我们将其升级为此严格程度更高的许可...”？还是我们应该只使用他们的代码作为第一次提交，并进行更新，说“我们继承自……我们进行了如此多的更改……”？

13 project-management  open-source 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 我说的不是固定价格的工作，他们是相当简单的。但是我正在进行一个按小时收费的项目，我的问题特别涉及到收费。 如果我遇到IE / CSS问题，需要花费一个小时的时间来解决CSS问题，这是否收费？如果我决定在他们的网站上使用非常酷的jQuery动画，但是我需要掌握使用它的方法，那么我会为使用该动画进行的实验收取费用吗？ 您是否向客户收取他们不知道的东西，因此需要花一些时间来学习？ 就我而言，这是一个灰色区域，引号中没有明确概述（可能是因为没有多少客户愿意为您的精打细算/学习付出代价）。 这有什么共识？

13 project-management  client-relations 

我正在尝试找出您决定何时进行操作的决定依据。我很乐意提供更多背景信息，但现在我想使其更笼统。

13 project-management 

我想知道哪些选项可用于记录已开发的项目，因为从事该项目的开发人员甚至没有编写任何页面的文档。 该项目没有其他细节，只有许多页面的脚本具有过去两年来从事该项目的开发人员编写和修改的功能。我所拥有的只是数据库架构和项目文件。我想知道是否有任何方法可以组织这个项目并将其记录下来，从而对将来将从事此项目的开发人员有所帮助。 该项目是使用PHP和MySQL开发的。这些函数的注释很差，所以用doxygen运行时无法获得良好的结果。

13 project-management  documentation 

关于敏捷的大多数文献似乎偏向于CRUD类型的业务应用程序，在该应用程序中，用户非常了解幕后情况。（这很好，因为所编写的大多数代码可能都属于此类。） 对于这种类型的应用程序，用户故事（需求）和开发任务之间的关系通常很简单：只需将用户故事分成几个任务即可。 但是还有另一种类型的应用程序，其中大多数代码必须处理用户不直接可见的复杂处理。例如： 编译器 自动驾驶汽车图像分析系统 流体模拟系统 在这里，将任务和用户案例联系起来确实非常困难。是否有克服这一问题的技术，或者仅仅是我们必须接受并充分利用的技术？

12 agile  project-management  user-story  task 

昨天，我在一个Rails 5 API项目上工作，该项目正在使用“ 行为可标记”库来使事物具有标记（例如SE上的问题）。Rails 5目前处于alpha支持状态。当前有一个PR，用于修复等待合并到master中的错误；该错误导致我的功能分支在完成过程中停顿了-由于加载已中断，我无法实现该库的任何功能。 作为快速解决方案，我只是克隆了存储库，用PR所具有的相同代码修复了该问题，然后将我的Gemfile（依赖版本控制文件）指向了我自己的Github分支，直到该错误修复最终合并回master。 我很幸运，修复很简单（并且已经有人完成了此修复程序），因此我能够解决这个问题。但是，如果该库对我的应用程序开发至关重要的话，该怎么办？如果停止我的开发的错误修正对于其他人来说不是一个普遍存在的问题，那么该修正没有像这次一样迅速出现吗？ 想象一下，在开发其他依赖功能之前需要先完成此功能 -在这种情况下您会做什么？如果对我来说，标记对接下来的开发工作绝对至关重要，那一切都要依靠它-但对于我的配置来说，标记依赖是错误的呢？当依赖项的关键功能阻碍了一个或多个功能部件的开发时，该怎么办？ 而且，当然不能在办公椅上进行数小时或数天的剑战了……

12 project-management  dependencies  time-management 

标题说明了一切。我们公司的一些员工认为，自动化测试“容易”，编写COM和UI测试套件“需要一天”。有什么可以应对的呢？ 注意：我不是在问如何促进自动化。那不是问题。一直以来，自动化的测试和流程都得到了推广和要求。问题是有些人不了解自动化不是“容易”或“快速”。

12 project-management  quality  automation 

基本上，我们有三个主要项目，其中两个是Web服务，另一个是Web应用程序。尽管我对使用功能测试覆盖尽可能多的Web服务感到满意（所有三个项目都有其适当的单元测试），但针对Web应用程序的功能测试却需要花费大量开发人员的时间来实现。我所说的很多意思是实现包含单元测试的功能所花费的时间是两倍，有时甚至更多。 经理的政策是测试我们添加的每个功能，即使对业务不重要（即新的CRUD）也是如此。 我确实同意测试所有Web服务功能，因为很难对其进行手动测试，而且此测试运行速度很快，并且不需要太多的实现。 那么，花更多的时间编写功能测试，而不是编写系统代码，单元测试和修复QA标签，有什么价值？这正常吗？我们不应该只为关键功能编写功能测试，而让质量检查人员在没有关键功能的情况下进行回归测试吗？ 注意：我们不是在开发医疗软件或NASA软件，或没有那么重要的工具。

12 project-management  testing  functional-testing 

在我的部门中，我们正在为某些统一通信服务器开发几个较小的插件。对于版本控制和分布式开发，我们使用Team Foundation Server 2012。 但是：对于我们所有的应用程序和库，只有一个大型TFS解决方案： 主要解决方案 应用领域 应用程式1 应用程式2 应用程式3 外在 图书馆 库1 库2 工具类 “应用程序”路径包含所有主要应用程序。它们并不相互依赖，但是取决于库和外部项目。 “外部”路径包含一些在我们的应用程序和库中引用的外部DLL。 库路径包含常用的库（UI模板，Helper类等）。它们彼此不依赖，并且在“库”和“工具”项目中被引用。 工具路径包含一些帮助程序，例如设置帮助程序，更新Web服务等。 现在，有一些要点为什么我想更改这种结构： 我们不能使用服务器版本。 用这样的解决方案结构来管理带有冲刺，障碍等的TFS Scrum管理是不舒服的。 每个开发人员始终可以访问解决方案中的所有项目。 如果在Visual Studio中意外击中[F6]，则完整的构建会持续太长时间。 您将在此解决方案中进行哪些更改？您如何将这些项目分解为较小的解决方案，应如何构建这些解决方案。 我的第一种方法是为每个应用程序，库和工具创建一个TFS项目。但是，如何确保例如App 2始终包含Lib 1的最新版本？我需要监视库1的更改并在库更改后立即手动更新App 2吗？还是可以以某种方式强制Visual Studio始终以某种方式使用外部项目的最新版本？ 编辑：在TFS上，只有一个TFS团队项目集合，其中包含一个TFS团队项目。团队项目包含一个大型的Visual Studio解决方案，其中包含几个包含（请参见上面的结构）的文件夹，每个文件夹都包含多个VS项目。 我的问题是，现在您将如何重组： TFS团队项目 VS项目

12 project-management  team-foundation-server  projects-and-solutions 

我是一家嵌入式系统公司的软件开发人员。我们有一个项目经理，他负责整个项目进度表（包括电气，质量，软件和制造），因此他的软件进度表非常简短。 我们还有一个软件经理，我的老板。他让我编写和维护软件进度表，设计文档（高低级设计），SRS，变更管理，验证计划和报告，发布管理，审阅，当然还有软件。 我们整个软件团队只有一名测试工程师（十名成员），并且在任何给定时间，都有几个项目正在进行。 我花了80％的时间制作这些文档。我的老板来自流程方面，并且认为我们需要更好的文档来改进软件： 他认为设计是最重要的，编码是“只是将设计写下来”，时间不要太长，并且“所有代码都应在硬件准备好之前编写”。 即使我们告诉他与分布式模型的协作更轻松，也不了解中央版本控制和分布式版本控制之间的区别。 不懂代码，想了解每个错误及其建议的解决方案。 认为验证应由开发人员完成，测试人员应进行验证。事实是，我们的验证仅检查实现是否正确（我们不编写单元测试，在计划中从未考虑过），而验证是黑盒测试，因此缺少单元测试。 我真的很困惑 我负责维护所有这些文件吗？本质上，这让我感到自己正在执行软件项目管理。我可以接受技术文档，但我相信开发人员不应该进行计划/计划。 我不太喜欢创建文档，我想解决问题并编写代码。以我的经验，创建设计文档只会在一定程度上有所帮助，而对于更好或更快速的代码来说却无济于事。 我觉得老板并不真的在乎制造更好的产品，而只是在管理层眼中成为一名好经理。 我能做什么？整整一年，我已经完成了3个月的实际编码，其余时间仅用于制作文档和等待来自客户的错误报告。

12 design  project-management  development-process  documentation 

我正在尝试提出一个个人工作流程。我整理了一个发行版的假设生命周期的流程图：一个开发人员推向公开的github repo +一个帮助提供某些功能并修复bug的朋友。 这是版本控制的合理方法吗？ 主要思想是保持公共仓库整洁： 每个新版本都会进入自己的分支，直到完成后最终在master分支中对其进行标记。 为了防止异常，所有工作都在“功能”或“修补程序”分支上进行，而不是在实际的发行分支上进行。 合并到更高级别的分支总是要重新设置基础或进行压缩（以避免混乱）。 如果这太过猛烈，我不介意，因为对我而言，重点就在于学习大型项目可能需要的技能。唯一的问题是，如果我在做完全错误或不必要的事情。 编辑2：修正原始流程图中的错误主意，并使它更易于浏览。

12 project-management  programming-practices  version-control  git  workflows 

重要提示：我们有没有问题，有任何的源代码文件。这属于常规代码审核，并且是最新的。我们的问题是开发人员文档（如果愿意，也可以是“外部”），从程序员到程序员的类似博客的小技巧，这些技巧往往一经编写，经常被抛在后面。 我们使用类似Wiki的系统来生成程序员文档 - 程序员为程序员编写的文章，详细描述了特定代码的工作方式。这些维基页面通常包括： API部分设计决策背后的动机（例如；我们做这件丑陋的事是因为这个特定的第三方库希望以这种方式完成工作，因为另一个库...是因为...） 解释我们如何处理特定的常见任务（例如，显示琐碎的弹出窗口，该弹出窗口需要引用适当的应用程序样式，在注册表组件中注册自己，并实现一些接口以便被其他组件自动“扫描”） 良好做法（实际上是主观的，我们确实将这些内容记下来了） 环境配置，所需的工具及其设置 通常，主要与编写代码有关的内容由于其大小和博客文章/类文章的性质而与常规代码文档不符。 问题 就几个月前引入这个系统而言，似乎是个好主意，如今，我觉得它引起的问题比解决的问题多。例如： 人们确实写文章...但是一旦代码更改，Wiki更新就很少跟进 很多草稿文章，是某人匆忙写的，像这样离开 即使文章请求通常来自项目负责人，也几乎从未对其正确性/组成进行过验证-有时会导致质量不佳 通常降解。代码已更改，Wiki保持不变。下次有人寻找信息时，他通常会发现一堆过时，质量低下的东西-并且想知道正在发生什么，他发现的东西是准确的还是（甚至更糟）其中的哪些部分。而本该提供帮助的结果却相反。 目前看来，人们已经意识到了这个问题，包括项目负责人，但是显然没有人愿意为此做任何事情（或者要做更多有趣的事情）。 我最初的想法是将其全部遗忘（在我连续几次被过时的“小费”咬伤之后），但是我想那可能太极端了。一些信息值得注意，有时会读得很好，但是问题仍然存在：如何处理其“最新信息”？它是否以某种方式链接到源代码（因此，当检入文件的更新版本时，文章作者会收到通知，他可能需要修改代码/文章）？有指定人员在日常基础上“监视”它吗？定期清理吗？

12 project-management  agile  documentation 

我正在阅读彼得·塞贝尔（Peter Seibel）写的这本很棒的书，叫做《编码员在工作：对编程技巧的思考》，而我正在与约书亚·布洛赫（Joshua Bloch）进行对话，我找到了这个答案，这对程序员来说很重要。该段是这样的。 这里有一个问题，那就是编程是一种智力精英，而这些人往往是组织中最聪明的人。因此，他们认为应该允许他们做出所有决定。但是，仅仅是他们是组织中最聪明的人这一事实并不意味着他们应该做出所有决策，因为智能不是标量。这是一个向量数量。 在最后一句话，我没有得到他试图分享的见识。有人可以进一步解释它对向量量的含义，可能试图提供相同的见解。 再往下看，我要说的是，他并不是要建立一个非技术人员（有时很笨拙）可以成为技术人员的经理的组织，原因是他们可以花更多的时间写好电子邮件，因为下一个原因以上段落之后的声明是。 而且，如果您缺乏同理心或情感智慧，那么您就不应该设计API，GUI或语言。 我了解他说的是，在软件工程中，程序员应该知道用户如何看待他们的产品和设计。 我觉得上一段非常有趣。

12 design  project-management  customer-relations 

当开始一个新项目时，我的老板总是避免做出固定的决定。他通常在说：好吧，就开始写点东西，并尽可能通用。当您完成后，我们将看看我们如何继续。他的论点基本上是您永远不知道和“敏捷开发”。 为了使问题尽可能笼统：如果老板不喜欢做决定，您会怎么做？ 只是坚持并编写可能在几周后进行大量重构和部分重写的代码？还是继续讨论直到老板做出至少一些决定？这或多或少是我目前的策略。因为这就像物理定律，所以在某些时候需要交付一些东西。要么是因为老板的老板想看到结果，要么是因为某些时候东西变得荒谬。 我还发现老板几乎批评了所有事情。甚至是基于他自己的建议...

12 design  project-management  requirements  decisions