Questions tagged «planning»

我确信每个人都经历过这样的事情。您与有项目的客户开会。他们没有/很少有需求，对他们想要/需要的东西最模糊的理解。在这一点上，似乎有两个选择： 1）告诉用户，“好吧，如果您什至无法描述它，我也无法为您提供帮助。为什么您知道自己想要的东西后几个星期不回来呢”。 2）与用户会面几次，并通过良好的ole Socratic方法指导他们进行操作，帮助他们弄清他们想要的东西。“您需要跟踪X吗？”，“ Y怎么样？”，“是否需要功能Z？” 使用第一个选项，您不会被困于他人的工作或获得心理能力，但是，用户可能永远不会向您展示连贯的规范，或者随着期限的临近，他们可能会花很长时间。使用第二种方法时，您会浪费大量时间成为业务分析师，并且不得不将很多业务知识塞进脑海中，您可能永远不会再使用它，但是您更有可能提出一种规范，有道理。 对我来说，这是发展中最具挑战性的方面之一，我感到我并不孤单。根据您的经验，这些选项中的哪一个更有效？

16 requirements  planning  specifications 

我们的业务分析师和项目负责人告诉我们客户的故事要求。在每个Sprint计划中，我们（开发人员）都被要求玩计划扑克。 他们要求我们所有人考虑“复杂性”而不是“努力”。我们真的很困惑，我们在浪费时间开会。一位开发人员提出了一个问题：“我们真正要考虑什么？是关于我们在此需求（时间估计）中必须进行的代码/ DDL更改，还是关于我们是否已理解该需求？ 但是，他们（业务分析师和项目负责人）真正的含义是“了解需求”并“举起名片”？ 另外，我们为各个Scrum团队举行切片会议，每个开发人员都为每个Scrum团队估计完成给定任务的时间。那么，他们在计划扑克中真正谈论的是什么呢？ 谁能用一个例子解释一下？当他们说“复杂性”和“努力”时，尝试区分他们真正在谈论什么。

15 agile  scrum  planning 

我花了5个小时以上的冲刺计划来进行为期一周的冲刺。似乎太过分了。 由于大多数团队成员都不高级，因此我们将在sprint计划中详细讨论事情。如果我们不这样做，将会在实现过程中导致错误，并在sprint过程中进行重新设计。 我们该如何处理？ 我应该在计划期间讨论多少细节，以使其适合每周冲刺仅2小时的时间？

14 agile  scrum  planning  sprint 

如果您为冲刺计划了许多用户故事，而一个候选故事则取决于某个外部提供商向您的团队提供一些东西。例如，在线服务提供商向其系统添加新的API调用，或在其系统上启用您的测试帐户等。 您知道即将来临。 您是否继续将故事添加到sprint中，希望他们能及时提供您完成故事所需的内容，还是等到下一个sprint，当您知道故事已经准备好就可以立即开始就算这意味着不及早开始故事。 如果是前者，您如何处理由于依赖性而失去的“无知的”故事点？部分信用（eek！）或放在下巴上。

13 project-management  agile  scrum  planning 

我决定完全重写多年来一直在研究和开发的PHP框架（使用MVC）。到目前为止，我的问题是我只想出一些主意，将它们作为票证放入Trac中，然后在以后添加它们-而不必担心框架本身的设计。随着时间的推移，这会导致一些问题，我认为重写会有所帮助，但是我不确定从哪里开始进行规划-我知道我不想使用Trac，而且我知道不仅需要机票和里程碑-但是我还需要什么？ 我真的很想彻底计划这个重写，我想详细说明我想要的每个功能，它将去向何处以及如何将其连接到其他任何部分-但是我对此级别的规划没有经验。有什么建议吗？有什么程序可以帮上忙吗？我对Trac感到厌倦，我从未真正喜欢过它。 我知道我需要一份设计文档，但是我应该遵循某些布局吗？我还将需要错误跟踪，票证，里程碑等，但是除了Trac之外，我也不知道这有什么用。我确定还有更多需要，但我不知道要做什么，因此我们将不胜感激。

13 php  project-planning  planning 

请注意：我不想在这里进行编码帮助，Programmers原因是我在这里。我想提高我的程序计划/编写技能，而不仅仅是（对）我对Java的理解。 我正在根据此处针对LARP游戏列出的技能，试图找出如何制作具有任意类别系统的树。我先前的尝试对技能是否也是一类产品感到很失望。尝试对此进行编码很乱。画出我的树时，我注意到只有我的“叶子”才是技能，我将其他人标记为类别。 我所追求的是一种制作树的方法，该树尝试将模型和视图分开，并允许将任意类型的子节点（具有独立的编辑/渲染方式）添加到任意父节点。 注意：这里的所有东西都是作为技能购买的，即使看起来像是房产。最终用户会将其视为购买技能（他们在纸上atm上做的事情），因此应将其呈现在同一页面上。 树的解释：树是“出生的”，具有一组硬编码的最高级别类别（武器，身体和心理，医疗等）。由此，用户需要能够增加一项技能。最终，他们希望增加例如“单手剑专精” 技能（而非物品）。为此，理想情况下，请单击“添加”并Weapons选中，然后One-handed从出现在该子节点上的组合框节点中进行选择，然后再次单击“添加” ，然后在出现的该子节点上的文本字段中输入名称。然后再次单击添加以为该叶子添加/指定“级别”或“层”；首先是熟练程度，然后是专业化（例如）。 当然，如果您想购买其他技能，那是完全不同的途径。您可能不需要像使用武器示例那样在树下同一级别的组合框，也不需要其后的其他逻辑。这就是我难以理解的地方，更不用说编程了。如何制作一组类，而不指定将它们连接在一起的顺序，但是仍然使它们都适合。 用代码描述这种树的好的系统是什么？我见过的所有其他JTree示例都具有一些可预测的模式，而我的则没有。我不想在“文字”中编写全部代码，而在父级上应允许列出子节点的类型（组合框，文本字段等）的长列表。我应该使用抽象类吗？接口？ 当我添加上面未列出的其他行为不同的技能时，如何使这类对象集群可扩展？ 如果没有一个好的系统可以使用，那么是否有一个好的过程可以弄清楚该怎么做呢？ 我脑海中的齿轮正在转动： 我总是需要： 检查父母 提供基于父项的选项 由于这种共性，我开始思考，我需要某种抽象/接口skill类来定义/概述技能和类别的通用方法。我可以（希望）将规则和选项放入数据库中并从中读取。现在我想的问题是，在抽象或接口方法与如何实现该方法之间。

12 planning  trees  extensibility 

亲爱的程序员， 当涉及学术研究时，您如何进行“软件计划”？而且，在一个侧面说明，你如何说服你的老板，写软件是不是就像盖房子一样，它更像是写一本小说？ 血腥细节如下。 我负责一个在研究实验室工作的小型开发团队。我们开始开发一款软件，目的是有一天公开上市（即出售并从中赚钱）。除其他事项外，此类软件至少取决于两条独立的研究路线：也就是说，至少有两名博士学位。希望有一天能提出我们需要的工作的候选人。 主要软件还取决于我们作为开发人员可以处理的其他更具体的资源：图形渲染，软体变形等。 我的老板要我写整个项目的规格，要求和血腥的甘特图。面对事实，我对研究部分一无所知，而这种研究对于软件是基础的，他说“做个假设”。为了使论点清楚起见，他是一位教授，其博士学位是。学生应该提出我们需要的研究。他来自严格的工程背景：首先计划所有事情，写下规格，然后才写下“这是最后一部分”的代码。 我现在在做什么： 我按功能细分了产品；每个“功能” 实际上都是一个单独的产品； 每个功能都建立在前一个功能之上； 特征（A）具有可用的原型后，团队就可以开始研究下一个特征（B），同时对A进行质量检查（如果资金允许，可以招募更多人，等等）； 取决于研究的功能将排在最后：届时，希望研究部分将完成（当仍然是一个大问题时）； 另外，我设置了团队使用SCRUM来开发“ 1.0版”，这将在几个月内完成。可以根据合理的假设来设置截止日期：我们列出了所有必需的功能，计算了可用性，并给出了合理的估算值。 所以我的问题再次是： 我如何使老板开心，同时又让东西出去？ 我如何为开发人员写一些东西的规格说明，不知道是否可以做？（我们仍未决定要用于某些任务的库；我们将在需要时这样做） 鉴于现在还没有客户或投资者，只有很多利益和承诺，我如何获得要求？ 我如何获得世界和平？ 我确信至少我的一个问题会得到回答:) ps：我正在匿名写这篇文章，因为如果发现这一点，潜在的投资者可能适得其反。希望你能理解。但是，我必须说我不喜欢这种“隐藏真相”的心态：该计划可能会使许多人受益，并且无法公开谈论此事（附带我的名字和声誉）感觉就像是审查制度。但是，a，我现在更关心您的建议。

11 planning  research 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我的（非技术性）同事以甘特图威胁我，我们正在计划一个新项目。这可能为我们提供什么，这将是一个有用的工具吗？

11 project-management  planning  gantt-chart 

规划非常困难。我们天生不擅长估计自己的未来，许多认知偏见加剧了这个问题。小组计划更加困难。信息不完整，对情况的看法不一致以及沟通问题加剧了困难。 敏捷方法为组织小组计划提供了一个框架-使计划对所有人可见（用户故事），将计划分成较小的块（冲刺），并提供回顾性分析，以便您更好地进行计划。但是，找到支持这些做法的好的工具被证明是棘手的。 您使用什么软件工具来实现这些目标？您为什么要使用该工具？您使用特定工具取得了哪些成功？

11 tools  programming-practices  planning 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我的团队由4名开发人员组成；所有的经验丰富和熟练。其中一位是罗word的，精心设计的家伙，他坚持要为我们的故事定义技术解决方案，然后再使用Planning Poker降低估算值。他拒绝估计自己是否对约定的技术解决方案不了解（听起来很合理，对吧？）。 问题是我们的估算会话需要花费很多时间！！根据您的经验，在玩计划扑克时如何处理这种个性？

10 agile  planning 

我们正处在第一个Sprint的中间，而我们的曙光已经来临：我们估计过高！ 我们为这2周的迭代计划了114个理想小时，在第一周结束时，我们完成了整个Sprint。我们现在干什么？《书》说，我们应该而且我们将从积压中得到下一个优先事项。但是，如何将它们添加到燃尽图中？我们是否重新编写它来说明这些故事，就好像它们从一开始就在那儿一样？还是在我们开始研究它们的那天简单地将它们的估计值添加到y轴（显示90o角跳）？ 欢迎任何反馈！

10 scrum  planning 

在这里，我正在确定和估计一个相对较小的新软件开发项目。我已经遍历了客户建议的用户案例，并针对每个案例放置了任务，并提供了估算和一些简短的注释，说明如何完成任务。有验收标准。所有人都应该对世界有益。 在查看我计划的工作时，我意识到缺少一些东西。只需设置一些我们可以固定功能的东西，这是最初的支出。属于所有用户故事的事物，而不是一个特定的用户故事。 例如，此应用程序的一部分是解析XML的服务。从用户的角度来看，有一些特定的故事，根据XML的内容，需要做不同的事情。实际上，编写XML解析器（查找文件的位，读取文件并提取相关数据，然后再决定如何处理内容）是所有这些故事的一部分。就像使用安装程序等将其包装在Windows服务中一样。这是以开发人员为中心的任务，与用户没有直接关系。 该特定应用程序的另一个相关示例是获取并重写一段不良的旧代码，这对此应用程序的功能很有用。同样，这对用户没有立即的结果，但这是必要的工作。在针对用户故事的项目计划中，如何计划和执行这项工作？ 我已经看到人们通过写用户故事“作为开发人员，我想...”来解决这个问题，但是正如其他地方所讨论的，这不是用户故事。是开发人员。 我正在为此寻求一个具体的答案，以帮助我（和其他人）使用严格的管理框架（例如TFS在线）来计划项目。这些往往不具有编写“利益相关者故事”或其他模糊的元解决方案的功能，这些解决方案在Scrum团队如何在计划会议中解决基础架构任务的答案中提到。

9 agile  team-foundation-server  planning  user-story 

我在Scrum会议中注意到，开发人员通常会对故事进行现实的估计。但是，即使是相当简单的故事，也需要大量的精力进行配置，设置第三方组件，测试和最终构建，并且系统积累了相当多的技术债务，因此对于产品所有者或管理层来说，估算值通常显得过高。 PO经常尝试降低此类估计，例如：“什么，您想要这个故事要13个故事点（4天），这不可能！我无法向管理层解释，有人应该可以对此进行编码3 SP [在4小时内！！”。结果，开发人员不得不屈服于做出5或8个故事点（1.5至2天）的估计值（Scrum估计值仍被视为承诺，而不仅仅是预测）。 当然，如果没有任何降低期望的计划（主要是在测试和质量方面），则这些冲刺经常会失败。开发人员的估算是诚实，现实的估算，击败估算并不会降低实际的工作量。 可以说：“您不应该做出不可能的承诺，只是因为有人逼着您去做！” 但是我认为，开发人员的工作是软件设计和编码，而不是讨价还价或承受压力！可能有各种各样的交易，通常是直接与外部客户打交道的交易，但这并不是大多数Office开发人员！ 对我而言，这种做法只会使程序员看起来像个混蛋，会导致不断出现的sprint故障，并阻止了实际的估算，同时也寻求了实际的改进。 Scrum准则对此主题有何看法，或者他们对此有何表述？ 编辑：用故事点代替时间。我指的是规划扑克和故事点的初始估算阶段，而不是任务详细计划。我只是把日期/时间放在这里，因为有时是典型的对话，有时是用时间而不是时间。抱歉给您带来任何混乱！故事点示例比时间示例代表更长的时间段。 编辑2当前没有专门的Scrum主持人，而PO在评估会议时扮演着这个角色。因此，可能是角色冲突使这种不适当的讨价还价变得更糟，因为他是作为权威而不是中立或开发者的混乱大师出现的。也许，只要没有候选人，就可以将他作为有偏见的参与者而不是“大师”来解决。

9 scrum  estimation  planning  sprint 

我目前处于冲刺阶段（两个星期），设计师负责定义特定用户故事的需求和用户体验。 在同一个Sprint中，我要实现此设计。在sprint计划期间，我不得不对这个不确定的用户故事需要花费多长时间进行大胆猜测。 今天，我终于收到了设计。不幸的是，设计是不完整/模糊的，比设计更类似于客户的要求。但是，从这一点上，我仍然可以看出，我的估计还不够。 更糟的是，这不是第一次。在最后的冲刺中，发生了完全相同的事情。我在回顾中标记了它，Scrum主管没有解决该问题的答案，而是说“这只是您的发展”。具有讽刺意味的是，如果烧毁没有达到目标，他会感到恼火。 现在，我将不得不咨询/与设计师合作才能完成工作。当我完成所有其他任务时，这将使我受挫。 所以我的问题是 A）您如何处理Sprint计划中的依存关系？编辑：可以在与实现相同的冲刺中进行用户故事的设计/ UX吗 B）我现在应该如何处理冲刺？重新估计当前的用户情况，并观察燃尽状态变成燃尽状态并被视为不称职/无效？或按照“帮助设计人员创建合适的设计”的方式向当前的sprint添加新任务

9 agile  scrum  planning 

在过去的5个月中，我们已经非常成功地实施了Scrum。虽然，我们是从PROD3周远没有以往做任何终端到端到端的集成测试。哎哟！我需要帮助。在此之前（现在），无需解决造成这种情况的原因，我们需要计划当前的迭代，该迭代包括较小的改进和许多仍未知的错误修复。您如何考虑这种情况？您如何计划迭代以修复尚未发现的错误？

9 scrum  bug  planning