Questions tagged «scheduling»

所以我已经从事这项工作了几个月。我有些沮丧，因为我从2到7做最好的工作。在以前的工作中，我9：30-10：00进来，然后7离开。有些公司对此还可以，有些则没有。 但是我目前的公司坚持要我在8:30到那里。任何偏离都很大。这是典型的吗？我有一些同事，他们都是9:30到6：30、10：00-7：00的家伙...但是也许这只是创业文化？ 考虑到我没有见到客户等原因，我不明白为什么会如此僵化。我也看不出为什么有时会有15到20分钟的变化，为什么人们不只是假设我离开时会做出调整... 作为开发人员，这些期望是不合理的还是我缺少什么？

65 time-tracking  scheduling 

我如何鼓励我的同事追踪他们花费在解决问题和实现功能上的时间？我们有执行此操作的软件，但他们只是不输入数字。 我希望团队将我们过去的估算与实际花费的时间进行比较，从而更好地提供项目估算。我怀疑我的同事没有看到个人利益，因为他们不经常参与项目计划。

24 project-management  time-management  time-tracking  estimation  scheduling 

我是一个小型团队的技术主管。我的主要任务之一就是与客户沟通。我发现特别困难的一件事是处理截止日期，因为截止时间是客户委托的，而我却经常没有得到咨询。 通常，交互遵循以下模式。客户端提供了他们想要添加的功能，功能X。功能X在下周的应用程序发布中（大约6个工作日后）看起来不错。此时，功能请求需要经过批准，并且经常需要处理其他依赖项。最终，在N天后，功能请求被滴落到我的团队中。即使原始的最后期限（由非开发人员设置的期限）可以实现，也不再可行。我的团队受到责备，感到灰心，并且总体上有失败的气氛，我感到灰心和失败。 显然，整个过程被打破了。不幸的是，我无能为力，因为我在这里没有权力。我目前的做法是向客户温和地提醒我们开始日期，截止日期，功能的范围等。这感觉很像我在找借口。 你们遇到过类似情况吗？有什么/没有为您服务？

15 client-relations  deadlines  scheduling 

这是我的问题的一个小例子： 假设一个构建作业包含名为AD的4个独立任务。总而言之，D花费的时间比AC花费的时间更长。 无法包含相对任务时间的构建系统可能会安排如下任务： --------------------------------------- CPU1: A | C | --------------------------------------- CPU2: B | D | --------------------------------------- 相反，如果调度程序知道任务时间差异，则可以提出以下更短的调度： --------------------------------------- CPU1: A | B | C | --------------------------------------- CPU2: D | --------------------------------------- 我的问题： 是否有任何将相对预期任务时间纳入计划的构建系统？ 对于这种构建系统有哪些学术研究？ 这些构建系统（如果存在）从哪里获取时间信息？试探法，以前的构建过程中收集的时间？ 如果不存在这样的构建系统，为什么？是否有一个陷阱使他们不如乍一看看上去那么有价值？

13 scheduling  research  build-system 

想要改善这篇文章吗？提供此问题的详细答案，包括引文和为什么您的答案正确的解释。答案不够详细的答案可能会被编辑或删除。 一个团队决定每天早上有人应给每个人带羊角面包。每次都不应该是同一个人，因此应该有一个系统来确定下一个轮到谁。这个问题的目的是确定一种算法，以确定明天将把羊角面包带给谁。 约束，假设和目标： 谁来带羊角面包将在前一天下午确定。 在任何一天，都会有人不在。该算法必须选择当天要出席的人。假设所有缺勤都是提前一天知道的，因此可以在前一个下午确定新月形面包的购买者。 总体而言，大多数人都在大多数时间都在场。 为了公平起见，每个人都应该购买羊角面包，其次数应与其他人一样多。（基本上，假设每个团队成员都有相同数量的钱用于羊角面包。） 为了减轻花名册的无聊感，最好具有一些随机性或至少感知到的随机性。这不是一个硬性约束：它更多是一种审美判断。但是，同一个人不应连续两次被选中。 带羊角面包的人应该事先知道。因此，如果人P在D日带上羊角面包，那么应该在人P出现的前一天确定这一事实。例如，如果总是在前一天确定了羊角面包的携带者，那么应该是前一天在场的人之一。 团队成员的数量足够少，以至于存储和计算资源实际上是无限的。例如，该算法可以依靠过去曾带谁羊角面包的完整历史记录。每天在快速PC上进行几分钟的计算就可以了。 这是一个现实问题的模型，因此，如果您认为这些假设可以更好地模拟场景，则可以自由挑战或完善这些假设。 起源1：找出谁要购买 Florian Margaine 的羊角面包。 起源2：找出谁打算购买 Gilles 的羊角面包。 这个问题与Gilles的版本相同，已作为实验重新发布在Programmers上，以查看不同社区如何应对编程挑战。

13 algorithms  scheduling  random 

如果您有一项任务只想在服务器群集上仅运行一次，那么定期执行此操作的最佳方法是什么？在这种情况下，群集的定义是2台或更多台具有负载均衡器后面的分布式会话的相同服务器。 用例：您有一项运行成本很高的任务，该任务每X小时只能运行一次。例如，此作业可以遍历一堆记录并更新其状态。 最糟糕的情况是，两次运行作业会使您的数据无效。 最好的情况是该作业利用了所有服务器上的资源。 要求摘要： 即使节点之一关闭，该作业仍必须运行。 每个计划只能运行一次作业。 如果在同一时间或重叠时间安排了多个作业，则正在运行的作业数将在服务器之间平均分配。 机器必须具有相同的代码库，并且必须通过NTP进行同步。 根据环境变量，节点之间的配置可能有所不同。 作业必须按时开始或在指定时间的给定间隔内开始。（例如说5分钟） 可能的解决方案 将一个节点设置为主节点，这违反了上面的1，因此无效。 要求负载均衡器平衡以启动该作业。不幸的是，这具有副作用，如果您同时运行多个作业，则它们可能都由同一台机器运行。 这必须在Java的servlet容器中运行。但是，它不是我正在寻找的工作的编码。 当然，这是已知最佳解决方案可以解决的问题。 相关问题。 /programming/5949038/schedule-job-executes-twice-on-cluster 这不是重复的，因为根据上述5个要求，解决方案还不够。最高支持的解决方案存在种族问题，第二种解决方案违反了要求3

13 language-agnostic  architecture  scheduling 

最近，我越来越被描述为我在该行业中最令人沮丧和士气低落的经历之一困扰：必须坐在经过测试，重新测试，上演的发行版上，并且出于所有目的并且已经准备好装运/部署目的。 作为一个全方位解决方案的人，而不仅仅是一个顽固的编码人员，我确实理解甚至提倡适当的变更控制。但是最近，在覆盖我们的基地和按时运输之间的微妙平衡已经变得不平衡了，在恢复到理智的状态上，我几乎没有成功。 我正在寻找有说服力的论据来帮助说服规避风险的管理人员： 开发团队应该（或必须）能够设置自己的发布时间表-在一定的范围内（除了最大的财富500强公司，对于所有其他公司，1-3个月应该足够保守）； 软件版本是重要的里程碑，不应轻率地对待。换句话说，不必要的延误/停工是极具破坏性的，应仅将其作为解决某些关键业务问题的最后手段；和 希望（或要求）作为利益相关者参与的外部（非dev / non-IT）实体有责任与开发团队合作，以达到发布时间表，尤其是在计划船交付前的最后一周左右日期（即用户测试/分期）。 以上是根据经验对我而言正确的断言，但看来我现在必须证明这一点-因此，如果存在这样的问题，我想在这里提出一些建议。 谁必须向管理层“出售”固定（或半柔性）发布周期的想法，才能指出一些论点/策略有效或有说服力，哪些无效？除了明显的时间表争用和沉没成本之外，即使在“公司”环境下，是否有任何硬数据/证据可用于证明运输实际上很重要？ 另外，我也乐于听取建设性的争论，即为什么时间表灵活性（即使在数周/数月的时间内）比按期交付更重要；我现在很难相信，但也许他们知道我不知道的东西。 请注意，我们已经分阶段发布了产品，除了生产之外，它经历了每个阶段。使用商业错误跟踪器跟踪问题，并且分配给此版本的每个问题（其中100％）均已解决。我意识到这很难让人相信，这才是真正的重点-出于无法解释的原因，管理层会延迟100％，功能完善，经过全面测试并且获得了利益相关者的批准，这是没有道理的，但这就是事实，这就是正在发生的事情，这是要解决的问题。

12 release  release-management  scheduling 

这来自对另一个问题（这个问题）的一些答案和评论。 我主要从事瀑布项目，虽然我从事过一些采用敏捷行为并且对敏捷有一定了解的特设项目，但我会说我从未从事过“适当的”敏捷项目。 。 我的问题是“后期”的概念在敏捷中是否有任何意义，如果是的话，那又是什么？ 我的理由是，有了敏捷，您就没有前期计划，一开始就没有详细的要求。您可能有一个高水平的目标，并附带了一个概念上的日期，但两者都可能发生变化（可能会发生巨大变化），而且不确定。 因此，如果您直到交付和用户接受之前都不知道要交付什么，并且如果您没有下一个冲刺之外的时间表，那么您怎么会迟到呢？真的有意义吗？ （显然，我知道冲刺可能会超车，但我所谈论的是超出此范围。） 只是要清楚一点，我（个人）对以下假设的假设感到满意：基于我已经看过并参与其中的事实，准时瀑布项目（甚至是相对较大的项目）是可能的，即使这些项目也不容易，也不常见但是它们是可能的。 这不是敲门敏捷，而是关于我的理解。我一直认为敏捷的好处与截止日期或预算无关（或者只是间接地），与范围无关-敏捷在交付之前更接近真正重要的内容，而不是项目团队认为重要的东西。看过任何东西。

10 agile  scheduling 

我正在尝试创建体育联赛调度程序。我无法确定一种算法来帮助我有效地填写每个位置。 建立时间表的样本数据为： 10支 每个团队互相比赛1次（总共需要45场比赛） 每队每天最多玩1次 在我的测试中，我使用9天，每天5个广告位。 组合表（包含45个连击） ID Team1ID Team2ID位已 分配 时间表表（包含45个时隙） scheduleID homeTeamID awayTeamID GameDate GameTime 现在，我现有的过程将填补约90％的插槽，而剩下10％的插槽将留空，以免基于上述规则发生调度冲突。 我以递增的日期/时间顺序遍历我的计划表。 我的第一个时段可能是星期六上午8点。 我查询尚未安排的球队名单。然后，我对这些团队进行了一系列可能的组合。然后，我使用该数组从我的组合表中从尚未安排的组合中提取1条随机记录，然后将这些团队放在计划中。然后，我将该组合设置为使用状态。 我一遍又一遍地重复循环，每次我的可用团队列表变小，结果数组也变小。 我发现有些日子过得很好，而在另一些日子里，我最后剩下的最后两支球队已经在前一周打过球，因此不再被添加到日程表中。 我还没有尝试过的唯一方法就是“重置”冲突天数，然后再试一次以查看我是否能获得更好的排名。 有没有人有什么建议？

9 algorithms  scheduling 

一位朋友的父亲是软件工程经理，他强调说：“造成计划超支的首要原因是计划压力。” 研究站在哪里？是适度的调度压力在鼓舞人心，还是我提到的经理是对还是错，还是“您的调度压力越大，交货时间越长，总拥有成本越多”的问题？理想情况下，软件工程可以在没有调度压力的情况下工作，但实际上我们必须在现实情况的约束下工作，这是其中之一吗？ 与软件工程文献的任何链接将不胜感激。

9 management  scheduling  engineering