Questions tagged «project-management»

作为程序员，我们经常被问到“需要多长时间”？ 而且，情况几乎总是这样： 要求不清楚。没有人对所有含义进行深入分析。 新功能可能会破坏您在代码中所做的一些假设，并且您立即开始考虑可能需要重构的所有内容。 您从过去的工作中还有其他事情要做，您将不得不做出一个将其他工作考虑在内的估算。 “完成”的定义可能尚不清楚：何时完成？就像刚刚完成编码一样是“完成”，还是像“用户正在使用它”那样是“完成”？ 无论您对所有这些事情有多有意识，有时您的“程序员的自尊心”都会使您付出/接受的时间比您最初预期的要短。特别是当您感受到截止日期和管理层期望的压力时。 其中许多是组织上或文化上的问题，这些问题不容易解决，但最终，现实是您被要求提供估计，他们希望您给出合理的答案。这是你工作的一部分。你不能简单地说：我不知道。 结果，我总是最终给出估计，后来我意识到自己无法实现。它发生了无数次，我始终保证不会再发生。但是确实如此。 您确定和提供估算的个人流程是什么？您发现哪些技术有用？

652 project-management  development-process  estimation  time-management 

看完《国家地理》的MegaStructures系列影片后，令我感到惊讶的是大型项目的完成速度如此之快。在纸上完成了初步工作（设计，规格等）后，大型项目的实现本身仅需要数年甚至数月的时间。 例如，空中客车A380 “于2000年12月19日正式发射”，以及“于2005年3月上旬”已经对飞机进行了测试。大型油轮，摩天大楼等也是如此。 将此与软件行业的延迟进行比较，我不禁要问为什么大多数IT项目如此之慢，或更准确地说，如果有足够的人员，为什么它们不能在相同的规模下同样快速，无故障？ 诸如空中客车A380之类的项目都具有以下两个特点： 重大的不可预见的风险：虽然这不是首架飞机，但它仍然推动了技术的极限，对于小型客机而言，运转良好的事物可能由于物理限制而不适用于大型客机；以同样的方式，使用了尚未使用的新技术，例如，当波音747于1969年制造时，它们就不可用了。 总体而言，与人力资源和管理相关的风险：项目中途退出的人们，因休假而无法联系到某个人，常见的人为错误等。 有了这些风险，人们仍然可以在很短的时间内完成像大型客机这样的项目，尽管交付延迟，但这些项目仍然取得了巨大的成功，而且质量很高。 在软件开发方面，这些项目几乎不如客机那么大和复杂（从技术和管理角度而言），而来自现实世界的不可预见的风险则要少一些。 不过，大多数IT项目进展缓慢且迟到，并且向项目中添加更多开发人员并不是解决方案（从十人的开发团队到2000个开发人员的团队有时可以更快地交付项目，有时不能，但是有时只会损害项目，并增加根本无法完成的风险）。 仍交付的那些可能通常包含很多错误，需要连续的服务包和定期更新（想象一下，每周在每架空客A380上两次“安装更新”，以修补原始产品中的错误并防止飞机坠毁）。 如何解释这种差异？是否仅由于软件开发行业还太年轻而无法在一个项目中管理成千上万的人，以便快速交付大规模，几乎无故障的产品？

509 project-management  development-process  time-management  industry 

我希望这不是一个普遍的问题。我真的可以使用一些经验丰富的建议。 我刚刚在一家规模很小的科学家商店中担任唯一的“软件工程师”，他们在过去的10到20年中花了很多时间编写了庞大的代码库。（它是用一种几乎过时的语言编写的：G2-用图形来思考Pascal）。该程序本身是复杂的化学加工厂的物理模型。编写该程序的团队具有难以置信的深厚知识，但是很少或没有正式的编程基础培训。他们最近学到了一些关于不存在的配置管理的后果的艰难教训。代码本身中大量未记录的“污泥”的积累也极大地阻碍了他们的维护工作。我会避免给您这种情况的“政治”（总是 政治！），但足以说，就未来的道路需要什么没有达成共识。 他们要求我开始向团队介绍现代软件开发的一些原理。他们希望我介绍一些有关编码约定，生命周期管理，高级设计模式和源代码控制的行业标准实践和策略。坦白地说，这是一项艰巨的任务，我不确定从哪里开始。 最初，我倾向于在The Pragmatic Programmer或Fowler's Refactoring（“代码气味”等）的一些中心概念中对它们进行辅导。我也希望介绍一些敏捷方法。但最终，要想发挥作用，我认为我需要磨练5-7个核心基础知识。换句话说，他们可以实际开始实施的最重要的原则或实践是什么，这将使他们获得最大的“收益”。 因此，这就是我的问题：您将在最有效的策略列表中包括哪些内容，以帮助理顺意大利面（并在以后防止出现这种情况）？

470 project-management  agile  development-process  maintenance  sdlc 

我是一个由5人组成的团队的开发人员，我相信我们的项目将要走向灾难。我稍后将描述原因，但我的问题是：我应该如何表现？ 截止日期为1.5个月，我觉得无论我们做什么，这个项目都会失败。我认为我们应该只是终止项目并停止浪费我们的时间，但是从政治上我认为我们的经理不可能做到这一点。 在这种情况下我该怎么办？我应该付出额外的努力，还是应该轻松些？我该对经理说些什么？ 该项目失败的原因： 随着截止日期的临近，许多必备功能尚未完成 应用程序不稳定且很难使用 系统非常复杂，代码很难理解，很难更改-数据模型太受复杂的关系数据库（100多个表）驱动 领导不清；经理对新信息做出重大更改 几乎没有自动化测试或单元测试 严重依赖于其他系统，但尚未进行集成测试 实际上，我们实际上是在1-2个月前从同一个经理下的另一个开发团队继承了这个项目（以及混乱），该团队已经工作了几个月。

335 project-management  team  project  failure  legacy-code 

我正在一个网站上工作，该网站将允许用户使用来自Twitter，Google等的OAuth凭据登录。为此，我必须在这些提供商处注册并获得我拥有的超级秘密API密钥用誓言保护身体的各个部位。如果我的钥匙结了，那部分就被拉了。 API密钥必须随我的源一起传送，因为它在运行时用于执行身份验证请求。就我而言，密钥必须存在于应用程序中的配置文件中或代码本身中。当我在一台计算机上进行构建和发布时，这不是问题。但是，当我们将源代码管理混为一谈时，事情就会变得更加复杂。 因为我是个贱人，所以我更喜欢在云或GitHub中使用免费的源代码控制服务，例如TFS。这给我带来了一个小难题： 当我的API密钥在代码中并且我的代码可在公共存储库中使用时，如何保持身体完整？ 我可以想到许多方法来解决此问题，但是没有一种方法令人满意。 我可以从代码中删除所有私人信息，并在部署后重新编辑。实施起来会很痛苦（我不会在很多方面详述），并且不是一种选择。 我可以加密它。但是，由于我必须解密它，因此任何有消息来源的人都可以弄清楚该怎么做。无意义。 我可以支付私人来源控制的费用。哈哈j / k花钱了吗？请。 我可以使用语言功能将敏感信息与我的其余源代码隔离开，从而使它不受源代码控制。这就是我现在正在做的事情，但是如果错误地检查机密文件，很容易搞砸。 我真的在寻找一种有保证的方式，以确保我不会与世界共享我的私人信息（除了在手套上），这将通过开发，调试和部署而流畅地运行，并且也非常安全。这是完全不现实的。 那我该怎么办呢？ 技术细节：VS2012，C＃4.5，源代码管理将是TF服务或GitHub。当前使用分部类将敏感键拆分到一个单独的.cs文件中，该文件不会添加到源代码管理中。我认为GitHub可能具有优势，因为.gitignore可以用于确保不检入部分类文件，但是我之前已经搞砸了。我希望有一个“哦，常见的问题，这就是你的做法”，但我可能不得不满足于“没有那么多的吸引力”，：/

216 project-management  version-control  development-process  api 

我发现自己不时地反复思考这个问题。我想以正确的方式做事：编写易于维护的干净，可理解和正确的代码。但是，我最终要做的是在一个补丁上写一个补丁。仅仅因为没有时间，客户在等待，应该一夜之间解决错误，公司在这个问题上赔钱，经理在努力争取等等，等等。 我完全清楚，从长远来看，我在这些补丁上浪费了更多时间，但是由于这段时间要花几个月的时间，所以没人在乎。而且，正如我的一位经理曾经说过的那样：“如果我们现在不解决这个问题，我们不知道是否会长期存在。” 我确信我不是唯一一个陷入无尽的真实/理想选择周期的人。那么，我的程序员同伴如何应对呢？ 更新：谢谢大家的有趣的讨论。令人遗憾的是，如此之多的人每天不得不在代码的数量和质量之间进行选择。仍然令人惊讶的是，许多人仍然认为有可能赢得这场战斗，所以谢谢大家的鼓励。

180 project-management  programming-practices  management  workflows  software-schedules 

我已经从事软件开发工作多年了。我的经验是，随着越来越多的开发人员参与产品开发，项目变得更加复杂和难以维护。 似乎在开发的某个阶段，软件趋向于变得“骇客”和“骇客”，尤其是当没有一个定义架构的团队成员在公司工作时。 我感到沮丧的是，必须更改某些内容的开发人员很难了解架构的概况。因此，存在解决问题或以与原始体系结构相适应的方式进行更改的趋势。结果是代码变得越来越复杂，甚至变得难以理解。 关于如何保持源代码多年来的可维护性，是否有任何有用的建议？

156 project-management  maintainability 

这并不是一个真正的技术问题，但是这里还有一些其他有关源代码控制和最佳实践的问题。 我工作的公司（将保持匿名）使用网络共享来托管其源代码和发布的代码。开发人员或管理人员的责任是根据源代码是否已发布以及版本和内容将其手动移动到正确的文件夹中。我们围绕着记录文件名和版本以及更改内容的地方散布着各种电子表格，并且一些团队还在每个文件的顶部放置了不同版本的详细信息。每个团队（2-3个团队）在公司内部的做法似乎有所不同。可以想象，这是一个有组织的混乱-有组织，因为“正确的人”知道他们的东西在哪里，但是却一团糟，因为它们完全不同，并且依赖于人们随时记住要做的事情。 一段时间以来，我一直在努力寻求某种托管源代码控制，但在公司内部似乎无法获得足够的支持。我的主要论据是： 我们目前很脆弱；在任何时候，任何人都可能忘记执行我们必须执行的许多发布操作之一，这可能意味着未正确存储整个版本。如有必要，可能需要数小时甚至数天的时间才能将版本拼凑在一起 我们正在开发新功能以及错误修复，并且由于某些工作尚未完成，因此常常不得不延迟发布其中一个。我们还必须强迫客户采用包含新功能的版本，即使他们只想修复错误也是如此，因为我们实际上只在开发一个版本。 我们遇到了Visual Studio问题，因为多个开发人员正在同时使用相同的项目（不是相同的文件，但是仍然会引起问题） 只有15个开发人员，但我们的工作方式有所不同。我们都必须遵循一种标准的全公司范围的方法，这会更好吗？ 我的问题是： 如此规模的小组没有源代码管理是正常的吗？ 到目前为止，我仅获得了没有源代码控制的模糊原因- 考虑到上述信息，您认为哪些原因对于不实施源代码控制可能是有效的？ 我可以将更多的源代码控制理由添加到我的武器库中吗？ 我主要是想了解为什么我受到如此多的抵制，所以请诚实地回答。 我将给我相信采用最平衡方法并回答了所有三个问题的人的答案。 提前致谢

152 version-control  project-management  management  release-management 

在软件行业中，最普遍的虚假经济状况是最糟糕的（即节省金钱的方法最终花费的成本要大于储蓄所造成的费用），您如何与之抗衡？

126 programming-practices  project-management 

我从不知道什么时候项目足够远，可以首先提交到源代码管理。我倾向于推迟提交，直到项目“框架完成”为止，然后我主要提交功能。（我还没有做过足够大的个人项目，以至于没有一个太大的核心框架。）我觉得这不是最佳实践，尽管我不确定会出什么问题。 例如，假设我有一个包含单个代码文件的项目。要使该项目具有极其基本的功能（1个或2个功能），将需要大约10行样板代码和100行。我应该首先签入： 空文件？ 样板代码？ 第一个功能？ 在其他时候？ 另外，在特定地点办理登机手续的原因是什么？

118 project-management  version-control  development-process 

我的朋友是一家软件公司的项目经理。对他来说，最令人沮丧的是他的工程师经常离职。该公司努力招募新工程师，转移项目并保持稳定的高质量产品。人们离开时，这使我的朋友发疯。 这些工程师还很年轻，有野心，他们想要更高的薪水和更好的职位。大老板只是从财务角度考虑问题，他的理论是“ 三个新手总是比一个老手好 ”（作为一名经验丰富的工程师，我知道这是错误的）。我的朋友讨厌那个理论。 对他有什么建议吗？

114 project-management  quality 

在以前的工作中，项目经理（PM）对我所在的项目中的代码交付时间不满意。项目负责人告诉我，项目经理正在考虑让我签署一份合同，以锁定我为任务和交付日期提供的时间估计。 该项目的情况是我们正在使用新技术，代码库，编码标准以及非常容易更改的要求。我正在学习新事物，并根据不断变化的需求尽最大可能应用它们。整个迭代过程中的需求增长了2-3倍，而我估计要完成的需求增长了约5-8倍。唯一不变的是估算和交货日期。 是的，我确实错过了大多数截止日期。我正在研究一些非常新的技术，整个开发团队中没有其他人可以真正提供帮助，因为他们对此并不熟悉。至少不容易。 在我看来，项目经理希望将他的数字加起来，因此希望我签署一份合同以“确保”我将始终按时交付工作代码。我想如果我不能按时交货，PM可以通过签订的合同对我不利。 我相信接下来发生的事情是其他项目经理和/或项目负责人为我辩护，并且没有让这种情况发生。 我的问题是，这是否应该引起经理的危险信号？经理通过签署的合同锁定软件开发人员的时间估计是否是惯例？或者在这种情况下，请尝试。 请注意，我是全职员工，而不是独立顾问。 更新：我想补充一下，我确实每周都会提供新的估算值，但是看来原始的估算值和交货日期正是PM所确定的。

113 project-management  contract  estimation 

我是一名初级开发人员，如果我可以证明更改的合理性，并且可以帮助团队完成工作，则可以帮助调整团队的流程。这对我来说是新的，因为我过去的公司或多或少都严格定义了来自管理层的流程。 我的团队很小，有些新（不到3岁）。他们缺乏： 定义明确的软件开发/工作管理框架（如Scrum） 强大的产品所有权 定义明确的角色（例如，业务人员将进行手动测试） 定期站立会议 合并的问题跟踪流程（我们有一个工具，该流程仍在开发中） 单元，系统，回归或手动测试套件或列表 有关业务逻辑和流程的文档 知识库以记录内部和面向客户的提示 而这样的例子不胜枚举。只要价值是合理的，管理人员就可以实施改进措施，并且可以帮助完成最重要的工作（即开发）。但是，基本假设是您必须在实现中拥有所有权，因为没有人会为您做这件事。毋庸置疑，上述某些项目是不平凡的，无疑是耗时的，并且显然不是开发工作。 随着时间的流逝，（初级）开发人员尝试实现上述目标是否值得？还是最好“随心所欲”并专注于开发，将大部分流程定义和优化留给管理人员？

108 project-management  scrum  development-process  process  product-owner 

不同的版本命名约定是否适合不同的项目？您使用什么，为什么？ 就我个人而言，我更喜欢以十六进制表示的内部版本号（例如11BCF），该数目应该定期增加。然后为客户提供一个简单的3位数版本号，即1.1.3。 1.2.3 (11BCF) <- Build number, should correspond with a revision in source control ^ ^ ^ | | | | | +--- Minor bugs, spelling mistakes, etc. | +----- Minor features, major bug fixes, etc. +------- Major version, UX changes, file format changes, etc.

107 project-management  development-process  naming  versioning 

我一直在工作中严格遵循DRY原则；每次我由于懒惰而重复编写代码时，都会在以后需要在两个地方维护该代码时再次出现。 但是我经常写一些小的方法（可能是10到15行代码），这些方法需要在两个不能互相引用的项目中重用。该方法可能与网络/字符串/ MVVM等有关，并且是一种通用的有用方法，并不特定于它最初所在的项目。 重用此代码的标准方法是为可重用代码创建一个独立的项目，并在需要时引用该项目。问题在于，我们最终遇到了两种不理想的情况之一： 我们最终得到了数以百计的小项目-每个小项目都包含我们需要重用的小类/方法。.DLL仅需少量代码就可以创建一个全新的应用程序吗？ 我们最终完成了一个项目，其中包含越来越多的不相关方法和类。这种方法是我曾经工作过的公司所做的。他们有一个名为的项目base.common，其中包含用于我上面提到的事情的文件夹：联网，字符串处理，MVVM等。它非常方便，但是不必要地将其与所有不需要的无关代码一起拖到它。 所以我的问题是： 软件团队如何最好地在项目之间重用少量代码？ 我特别感兴趣的是，如果有人在一家在这方面有政策的公司工作，或者像我本人那样亲自遇到了这个难题。 注意：我对“项目”，“解决方案”和“参考”一词的使用来自Visual Studio .NET开发的背景。但是我敢肯定，这个问题与语言和平台无关。

102 project-management  code-reuse  projects-and-solutions  dry