Questions tagged «project-management»

在目前的工作中，我有两个项目需要处理。第一个是非常庞大的系统，第二个较小，但规模也很大（第一个项目的开发时间为12年，第二个项目的开发时间为4年）。 起初，我只从事第一个项目，并试图适应它。然后我被转移到第二个项目并在那里尝试，所以我对第一个项目的了解变得阴暗。现在，我必须同时处理两个项目。 这对我来说很难，因为尽管它们都使用Java，但是它们使用不同的框架，并且要理解的代码和业务逻辑的数量非常大，所以我真的无法将这两个项目都掌握在心中。 这是正常的，我应该习惯了，尽管我的专长变得非常谦虚，但是如果我只从事单个项目，那怎么办？还是我应该引起关注或更换雇主？

40 project-management  time-management 

我正在一个小型团队中工作，该团队将开始与另一个小型团队一起进行一个新的大型项目。另一个团队目前正在研究他们已经使用了多年的遗留系统。 经理已决定，我们团队中的开发人员将每隔几个月轮换一次，以替换在旧系统上工作的开发人员。这样，其他团队将有机会从事新项目并更好地理解新系统。 我想知道每2-3个月从项目中轮换开发人员的利弊（如果有）。 我知道这与“轮换首席开发人员是个好主意还是坏主意？”类似的问题。，但是这个问题集中在主要开发人员上。这个问题是关于整个团队轮流上线和下线的（新项目的技术负责人可能会也可能不会轮换-我还不知道）。

38 project-management  teamwork  team 

我是一名初级开发人员，发现很难估算完成一个较大的软件项目需要多少时间。我知道一般如何构造体系结构，但是我很难知道我必须做哪些细节以及必须解决什么问题。因此，很难估计完成一个较大的项目将花费多少时间，因为我不知道我需要解决什么问题以及解决它们需要多长时间。 我如何向非软件开发人员解释？

37 project-management  estimation  project 

当我开始一个新项目时，我经常会立即开始考虑实现的细节。“我要在哪里放置DataBaseHandler？我应该如何使用它？要使用它的类应该从某些Abstract超类中扩展。发送请求和解析数据的方法？” 我最终停滞了很长时间，因为我想为可扩展性和可重用性编写代码。但是我觉得几乎不可能过去思考如何实现完美。 然后，如果我只想说“拧紧它，就完成它！”，我很快就会碰壁，因为我的代码没有组织好，混合了抽象级别，等等。 您有什么技术/方法来启动一个新项目，同时建立一个可以很好地扩展的逻辑/模块化结构？ - -编辑- - 好吧，这已经是很难接受答案的问题类型了，但是希望获得更多反馈，看看是否有共识。TDD听起来真的很酷，坦率地说，我一直在意欲加快使用JUnit等的速度。与此同时，TDD的拥护者如何看待这一事实，即与TDD有关的合理点解决了我的问题？特别的问题是，TDD似乎并没有真正解决设计问题。当然，我同意TDD将帮助我定义我想做什么，然后我可以逐步研究如何做，但是有许多不同的总体设计模式/结构可以全部通过单元测试。就是这样：它测试单个UNITS。我想我有点困惑...我不知道。也许我' 谢谢！

37 project-management  design-patterns  code-quality  paradigms  code-reuse 

我曾经指责客户更改规范会导致代码腐烂，而没有意识到业务模型确实会发生变化，而我的工作就是以适应性方式进行开发。现在，我认为这表明开发人员表现不佳（我已更改！）。 但是现在我自己身上看到了其他“ whi”。最近几次，我发现自己说“这就像试图将一个方形的钉子插入一个圆孔中”，而且我发现自己将客户的犹豫不决归咎于项目没有进展。 有迹象表明我应该寻找可以改变态度的地方吗？客户总是对的，还是有时候我感到沮丧？

36 project-management 

从很高的角度来看，在我看来，通常有两种类型的项目管理工具： 传统问题跟踪工具，例如Fogbugz，JIRA，BugZilla，Trac，Redmine等。 虚拟卡板 /敏捷项目管理工具，例如Pivotal Tracker，GreenHopper，AgileZen，Trello等。 当然，它们以一种或多种方式重叠，例如，可以将Pivotal Tracker任务导入JIRA，GreenHopper本身是在JIRA问题基础之上实现的，但是我认为仍然可以看到这两种工具在方向上的差异。 甚至在进行敏捷项目管理的公司中也使用传统的问题跟踪器。我的问题是，为什么他们要这样做？我也觉得我们应该在公司中使用问题跟踪器，但是当我考虑它时，我实际上不确定我们为什么需要它。 例如，Trello开发似乎是通过使用Trello本身来管理的（请参见此虚拟墙），即使他们可以访问Fogbugz（周围最好的问题跟踪者之一）也是如此。因此，当我们使用一种敏捷的PM工具以一种敏捷的方式完成100％的工作时，也许我们不需要传统的问题跟踪器？

35 project-management  issue-tracking  kanban 

我总是读到完全或几乎完全是灾难的大规模改造或集成项目。即使他们以某种方式成功地取得了成功，成本和进度也非常巨大。大型项目更容易失败的真正原因是什么。可以在此类项目中使用敏捷还是传统方法仍然是最好的。 澳大利亚的一个例子是昆士兰薪资项目，他们改变了测试成功标准来交付该项目。 在此SO问题中查看更多失败的项目（在Wayback Machine上） 您有什么个人经验要分享吗？

34 project-management  project 

在我们公司中，我们需要做许多看似并不复杂的事情，例如开发Mobile UI。 假设经验丰富的程序员花费我们的费用是初学者的4倍。 两者基本上都可以在相同的时间内完成看似简单的事情。 不同之处在于，经验丰富的程序员产生的bug更少，代码更稳定等。初学者程序员浪费了很多其他人（PM，客户端等）的时间。但是它们便宜得多。 counter参数是，有经验的初学者用相同的时间来制作HTML表。因此，聘请有经验的程序员来做是奢侈的，初学者也可以做到。 考虑到我们领域经验丰富的程序员与新程序员之间的差异可能是4倍，我们应该投资更多，更好的程序员，还是更多，更好的PM。

33 project-management 

我在网上阅读了几篇文章，以了解敏捷，XP，Scrum，结对编程之间的区别/彼此之间的相互关系，并得出以下结论： Scrum和XP几乎相同。XP的发布时间比Scrum短 敏捷和XP方法中都采用了结对编程 但是我无法确定敏捷与XP有何不同。 除了提供URL，我将很高兴阅读您对此的经验和想法。

32 project-management  agile  scrum  pair-programming  extreme-programming 

在公司和工作中，我一直都在努力让人们更新他们的问题。我曾有几次案例，人们实际上是出于内心的善意而这样做的，但是大约70％的时间我必须追赶人们。 作为通常执行某种或其他形式的管理（我首先是一名开发人员）的人，我尝试给出的主要原因是我不想追赶人们并打扰询问进度，但是我不愿意最终人们不会认为有很多问题要问。在某些罕见和极端的情况下，我最终会更新票证（当我需要创建报告时）。 那么，您是否遇到过这个问题？您如何鼓励开发人员经常更新问题跟踪器？您取得了多少成功？

31 project-management  issue-tracking 

自从几个月前成立以来，我在一个团队中一直处于扁平状态的团队工作。我的经理是非技术人员，这意味着我们整个团队都要负责决策。 我的经理开始意识到，拥有一名首席开发人员有很多好处，无论是出于他的利益（一个任务的单一联系点和一个责任方），还是出于我们的利益（纠纷解决，有组织的技术指导等）。 因为团队很平淡，所以一个担心是选择一名主要开发人员可能会阻碍其他开发人员。一个非开发人员向我的经理建议，轮换首席开发人员是避免此问题的一种可能方法。一位开发人员将领导一个月，另一位领导下一个，依此类推。 这是一个好主意吗？为什么或者为什么不？ 请记住，这意味着所有开发人员-所有开发人员都是好人，但不一定同样适合担任领导职务。 如果不是这样，我如何建议我们避免这种方法，而似乎仅仅是出于自私的原因？

31 project-management  team  team-leader 

在网络启动时，让工程师处理功能的前端和后端（主要负责整个功能）是否更常见？还是让工程师在后端和前端分开？ 哪些更有益，哪些情况适合？ 我已经注意到，由一位工程师来负责整个功能的缺点是，该人可能只在前端或后端开发方面特别强大，但不能同时兼顾两者，因此有时速度和质量都会下降。 前端和后端开发人员使用一项功能可以提高功能的速度和质量，并鼓励协作。但是我担心要有2位工程师在一个功能上工作，这可能会浪费资源，因为1位工程师可以放在另一个功能上进行工作。 在小型早期启动阶段分配后端/前端工程资源的常用/最佳实践是什么？然后随着它的增长它将如何变化？

31 web-development  project-management  team 

我想知道将我正在处理的项目分成两个存储库而不是一个存储库是否有意义。 从我可以说： 前端将用html + js编写 .net后端 后端不依赖于前端，前端不依赖于后端 前端将使用后端实现的一个宁静的api。 前端可以托管在任何静态http服务器上。 到目前为止，存储库具有以下结构： 根： 前端/* 后端/ * 我认为将两个项目都放在同一个存储库中是一个错误。由于两个项目之间没有相互依赖关系，因此它们应属于单独的存储库，并且如果需要，则应具有包含子模块的父存储库。 有人告诉我这是没有意义的，这样做不会给我们带来任何好处。 这是我的一些论点： 我们有两个互不依赖的模块。 长期拥有两个项目的源历史记录可能会使事情复杂化（尝试在历史记录中搜索前端中的某些内容，而您有一半的提交与所寻找的bug完全无关） 冲突和合并（这不应该发生，但是让某人推送到后端将迫使其他开发人员提取后端更改以推送前端更改。） 一个开发人员可能只在后端工作，但总是不得不拉扯前端或反过来。 从长远来看，将是时候进行部署。以某种方式，前端可以在拥有一个后端服务器的同时部署到多个静态服务器。在每种情况下，人们都将不得不要么克隆整个后端，要么创建自定义脚本以仅将所有前端推送到所有服务器或删除后端。如果只需要一个，则仅推/拉前端或后端比两个都容易。 反驳论点（一个人可能同时在两个项目上工作），使用子模块创建第三个存储库并进行开发。历史记录保存在各个模块中，您始终可以创建标签，在这些标签中，后端/前端的版本确实可以同步工作。将两个前端/后端放在一个仓库中并不意味着它们可以一起工作。它只是将两个历史合并到一个大型仓库中。 如果要将自由职业者添加到项目中，将前端/后端作为子模块将使事情变得更容易。在某些情况下，您实际上并不想授予对代码库的完全访问权限。如果您想限制“局外人”可以看到/编辑的内容，拥有一个大模块将使工作变得更加困难。 错误介绍和修复错误，我在前端插入了一个新错误。然后有人修复了后端的错误。对于一个存储库，在新错误之前回滚也将回滚后端，这可能使其难以修复。我必须将后端克隆到另一个文件夹中，以使后端工作，同时修复前端中的错误……然后尝试重新合并东西……拥有两个存储库将很轻松，因为移动了一个回购的HEAD不会改变另一个。并且针对不同版本的后端进行测试将是轻而易举的。 有人可以给我更多的论据来说服他们，或者至少告诉我为什么将项目分为两个子模块是没有意义的（更复杂的）。该项目是新项目，代码库已有两天的历史，因此修复还为时不晚。

30 project-management  version-control  git  mercurial  organization 

几个月前，我的公司发现自己手忙脚乱地遇到了一个项目的紧急情况，而我的整个6人团队基本上都花了5周的“紧缩周”。在上线之前的48个小时里，我工作了41个，其中两个背靠背通宵营业。在这之中，我发表了迄今为止我最成功的问题。 在这段时间里，从来没有任何关于“失败”的言论。它始终是“不管痛苦如何都完成它”。 现在事情已经过去了，作为一个组织的我们已经有一段时间坐下来对我们学到的知识进行评估，我想到了一个问题。我不能说我曾经参加过一个我说“失败”的项目。大量延迟或超出预算，有些灾难性地如此，但我总是最终提供一些东西。 但是我一直都在听到“失败的IT项目”的消息。我想知道人们对此的经验。定义“失败”的参数是什么？背景是什么？就我们而言，我们是一家拥有外部客户的软件商店。大型公司内部的项目是否有更多的“失败”空间？你什么时候打那个电话？当您这样做时会发生什么？ 我根本不相信做我们做的事情是明智的业务举动。这不是我的电话（我只是一个代码猴子），但我想知道减少损失，说我们没有交付并继续前进可能更好。我不只是说，由于长时间的辛苦工作，公司在该项目上损失了很多钱，加上公司在员工士气和忠诚度方面的无形成本很大。反对未能交付像这样的高知名度项目的公关打击的因素是……我不知道正确的答案是什么。

30 project-management  failure 

我正在阅读Gunther Verheyen撰写的Scrum-A Pocket Guide，它说： Standish Group的2011年混乱报告标志着一个转折点。在比较传统项目和使用敏捷方法的项目时，进行了广泛的研究。该报告表明，即使以前认为软件必须按时，按预算并在所有承诺范围内交付的旧期望，采用敏捷方法进行软件开发也会带来更高的收益。该报告显示，敏捷项目的成功率是传统项目的三倍，失败的敏捷项目则少三倍。 因此，我与一位同事争论，他说对于某些项目（例如要求不变的医学/军事），敏捷（尤其是Scrum）在所有会议中都是开销，等等，这更合乎逻辑。例如使用瀑布。 我的观点是，应该在此类项目中采用Scrum，因为这将使过程更加透明并提高团队的生产力。我还认为，如果不需要Scrum事件，将不会花费很多时间，因为我们不需要在Sprint Planning中花整个8个小时来进行1个月的冲刺。我们可以抽出5分钟的时间来确保我们都在同一页面上并开始工作。 那么，Scrum会为需求不变的项目增加额外的开销吗？

29 agile  project-management  scrum  methodology