Questions tagged «meetings»

我们的Sprint计划会议不仅不好玩，而且简直令人恐惧。 这些会议既乏味又无聊，而且要花很多时间（一天，但感觉要更长一些）。 开发人员对此表示抱怨，并担心即将到来的计划。 我们的例程非常标准（按优先级将用户故事插入到sprint待办事项中>>将故事分解为任务>>按小时数估算任务>>重复），我无法弄清楚我们在做什么错。 我们如何使会议变得更加愉快？ ... 应要求提供更多信息的更多详细信息： 为什么在sprint启动之前未插入待办事项并按优先级排序？ 用户故事确实是优先的；我们不知道他们会花多长时间，直到将他们分解成任务！从这里的（优秀）答案中，我看到也许我们根本不应该估计任务，而应该仅估计用户故事。我们估计任务（而不是故事）的原因是因为我们一直在错误地估计故事，但我想这是一个完全不同的问题。 开发人员为何抱怨？ 会议很长。 会议是单调的。一个接一个的故事，一个接一个的任务，奋斗（是的，奋斗）来估计需要多长时间和涉及什么。 估计任务使用户故事的估计显得毫无意义。 会议时间越长，会议室的焦点就越少。同事注意力越集中，会议花费的时间就越长。递归的仇恨螺旋发展。我们已经考虑将会议分成两天，以使人们集中注意力，但是开发人员对此一无所知。一天的计划已经够糟糕了；现在我们有两个？ 问题的一部分是我们进入了非常小的细节（以便获得更准确的估计）。但是，当我们粗略估算时，我们远远超出了预期！ 总结一下问题： 我们做错了什么？ 还有什么其他方法可以使会议更加愉快？

51 agile  scrum  sprint  meetings  process-improvement 

举行每日Scrum有很多优点，例如： 团队互相协调 每个人都知道完成了多少任务 燃尽图变得越来越完整 任务板已更新 它不会持续那么长时间，十五分钟不会杀死任何人 但是，最近（在实施和使用Scrum的6个月之后），我觉得我们的开发人员已经不再每天都喜欢Scrum。人们只是更新任务板，而没有解释足够，这似乎使他们感到无聊。我看到，无论出于什么原因，如果我们不坚持，他们就会变得特别高兴。 我只是不知道这可能是什么问题。有什么理由提到“每日混乱”可能给团队带来的不利吗？开发人员厌倦了日常混乱的原因可能是什么？

40 project-management  scrum  meetings 

您认为每日站立会议有多有价值（或没有）？ 如果您不熟悉它，则指的是Scrum拥护者（以及其他一些敏捷方法论）中的日常会议。这个想法是，您每天召开一次会议，时间限制为15分钟，每个人都必须参加会议（以鼓励人们直截了当）。 在会议上，您到处走走，每个人都说：-昨天您做了什么-您今天打算做什么-任何阻碍或阻碍您前进的障碍。 您认为这种做法有价值吗？有没有人在一个做过的地方工作，您觉得呢？

40 agile  scrum  meetings  development-methodologies 

我的老板目前正在尝试将一些开发标准应用到我们的团队中，因此昨天我们开会开会讨论了这些标准，在她提出之前，大部分进展顺利： 所有数据库表都将具有一个CreatedDate和LastUpdatedDate列，并通过触发器进行更新。 在这一点上，我们的团队意见分歧。我们中有一半的人认为，在所有工作台上执行此操作是一项大量工作，几乎没有收益（我们从事固定预算项目，因此任何成本均来自公司的利润）；下半年相信它将对项目的支持有所帮助。 我坚定地在前阵营。尽管我很欣赏某些外部情况会导致多余的列提高可支持性，但我认为，首先添加列所需的工作量以及维护工作将使我们花费更少的时间进行更多的工作重要的事情，例如单元测试或负载测试。另外，我相当确定这些额外的列会使使用ORM变得更尴尬-请记住，我们主要使用C＃和Oracle，但从一开始就对ORM不太满意。 因此，我的问题是双重的： 我在正确的营地吗？我并没有声称自己拥有享誉全球的数据库技能，因此这可能是一件容易的事，而且没有不利的副作用。 您将如何处理有关标准的会议演变为排渣比赛的情况？我如何才能真正卖出该标准不会长期帮助我们？

38 database  standards  meetings 

此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 在团队成员尝试承担责任的任务最初没有分配给他，而是分配给Scrum Master的情况下，您会怎么做？

22 scrum  collaboration  meetings 

我们有一个专业的Scrum Master顾问[*]，他最近加入了我们的项目。不幸的是，我们不知道她的名字（她从未向我们介绍自己，她只是一天之内就说“我们每天都站起来”），除了主持一个椅子，她似乎没有做太多其他事情。每日站立会议-当我半开玩笑地要求她也在会议中提供每日反馈时，她感到非常不满，说这是Scrum Master的“促进而不是参与”的工作。 这似乎是相当反敏捷的（已经在其他敏捷项目中工作过，这些项目是团队自我指导的），应该是平等的，但是我不确定它在Scrum方法论中如何工作。我怀疑她整天没有做很多事情，这就是她在这个问题上采取防御措施的原因。 Scrum Master是在站立会议期间参加“昨天，今天，障碍”活动，还是只是主持（“协助”）会议？ [*]我们实际上并没有告诉她她的工作，因为她自称为Scrum Master

21 agile  scrum  methodology  meetings 

我们的10名开发人员团队每周开会。这些会议很无聊，并不是特别有用。您使用什么格式/议程召开会议？ 我们每周在会议室开会，提供比萨饼。格式是我们在会议室四处走动，并列出我们正在处理的各种任务的状态，并讨论下周的任务。经理将概述未来几个月和来年的即将到来的项目和优先事项。 更新资料 这些会议的目标或多或少是-建立总体团队，分享每个人正在做的事情的知识以及使每个人都知道公司的计划正在改变。并非要正式“分发”工作分配（通过其他方式完成）。

19 management  communication  meetings  team-building  team 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 在另一个问题中，我问为什么开发人员可能不喜欢每天的混乱。我们与开发人员进行了交谈，我们决定暂时不举行每日Scrum（在我们的第一次尝试中尝试一下并定制化Scrum）。这是直接与开发人员进行协商的结果。 另一方面，我们不想失去日常工作的大部分内容，例如有机会每天与开发人员进行协调，或者像关键绩效指标那样观看工作进度，以便尽早采取行动。 作为每日混乱的替代方案，我们正在考虑要求开发人员提供以下条件的每日报告： 无需遵循任何特定格式。每种格式均被接受。 即使工作没有完成，我们也希望听到进展。 无需提及在每个任务上花费的时间。 应提及发展障碍和协调要求。 无需沉迷于每日报告。没有那么严格。 您认为这会降低他们的生产率吗？您有任何日常报告经验吗？您对我们有什么建议，以便我们可以确定自己没有进行微观管理吗？

18 productivity  management  scrum  meetings  reporting 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 我曾经在瀑布方法中工作，现在我在一个遵循敏捷方法的团队中工作。看来他们做错了。例如，我们每天进行25分钟以上的站立训练，这确实很烦人。此外，我觉得自己比起其他任何事情都可以向管理层证明自己的薪水。 我有这种感觉吗？这通常是站立式的吗？

13 agile  scrum  development-methodologies  meetings 

我知道Scrum在日常站立比赛中的规则说，团队应该只谈论他们昨天所做的事情，他们今天所做的事情以及任何阻碍他们前进的事情。没有其他的。但是问题是，有时开发人员会花费自己的时间从事与任务无关的工作，然后在独立讨论中谈论它。这就是他们昨天所做的！ 根据我的经验，我发现谈论董事会上的任务，保持站立状态，使每个人专注于他们的任务，复查他们的估计并每天跟踪他们的记录更为有效。 将讨论限制在董事会的任务上是否有效？

10 agile  scrum  meetings 

我正在研究一个项目，我们定期（通常每周一次）召开非正式会议，讨论该项目的状态及其GUI。 我是那里唯一的开发人员，其他4-5个人具有非IT背景。 这次会议花了比平常更长的时间，但是有一次，我的一位同事询问了计划中的某些领域以及如何填补这些领域。我回答并在讨论中发现，我完全错觉了这个过程。 但是由于我们已经讨论过并且事先发现了错误，所以我可以很快地对其进行更改。 在考虑这一点时，我问自己，在节省开发时间方面，在会议时间之间是否存在因素？ 例如，1分钟的会议时间可能节省X分钟的开发时间。 如果是这样，这将有助于定义我们的会议应该举行的频率和时间。 （只是为了澄清：我不想召开更好的会议，即使能够大致确定会议的时间也是可有可无的。如果会议时间和开发时间之间存在联系，我最感兴趣的就是我。我的理由是：好奇心！ ）

10 estimation  meetings 

我是一个由8位程序员组成的团队的团队负责人，该团队由大约20名技术人员组成。他们正在从事一系列项目，这些项目还涉及我无法控制的其他团队的人员。我的组织没有进行适当的敏捷开发，他们对变更有些抵触，但是我一直在团队内部举行每日站立会议，我们都发现它们很有用，并且每个人都参与其中，并且在10-15分钟。我还会每周与每个团队成员进行个别交流，我们在其中更详细地讨论各种常规主题（技术性和非技术性），以及各种临时主题会议。 但是，我一直在努力的是每周的团队会议。它正在失去动力，我无法使人们保持兴趣。 我仍然想召开一个更长的会议，即使必须每两周一次或每月一次。目的是讨论站立会议期间无法完成的各种主题，因为它们需要更多时间。我的最新消息包括他们正在进行的每个当前项目的摘要（是否如期进行，各种延误等），方向，未来项目的任何变更，开发过程的变更等。但是，最终我的一次讲座，显然至少有两个人被划出了区域，其余的人至多有兴趣。 我试图通过让人们谈论他们的一周来使人们更加参与，但是与8个人一起花费的时间很长（部分是因为他们的很多工作并没有那么多），其余的团队大多数不在乎他们的同事正在做些什么（他们在站立时会获得较高的概述）。 因此，在这些会议上，至少有些人很无聊，而让我继续举办这些会议几乎让我感到尴尬。与我们精力充沛的上午站立会议形成鲜明对比。 关于我可以做些什么来使人们更加参与和更感兴趣，有什么建议吗？我如何让他们介绍他们的事情或开始涉及所有人的讨论，而不是我的独白？

10 management  team-leader  meetings 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 8年前关闭。 根据我正在从事的项目，可能会要求我与内部利益相关者或客户公司的技术管理人员参加更多会议。 在这些会议的过程中，不可避免地会出现以下几个问题： 您没有答案。 您没有出于某种原因而考虑过。 您认为与本次会议无关或完全超出了本次会议的范围。 在每种情况下，您如何回答这些问题？关于保持权威同时保持诚实的任何提示或技巧？

10 management  meetings