Questions tagged «planning»

我们是一家只有一种产品的小型软件公司。 我们使用scrum，我们的开发人员选择他们想要包含在每个sprint中的功能。不幸的是，在过去的18个月中，该团队从未交付过他们致力于冲刺的功能。 我已经读过很多帖子/答案，它们都说“软件完成后立即完成工作，这无助于……给团队施加压力，让更多人参与其中， ……”我已经收到一位开发人员针对如何提高冲刺成功率提出的类似反馈。哦，是的，我们确实使用回顾。 我的问题基本上是： 寻找开发人员质量问题的公平时间是什么时候？ 我开始认为，如果您选择自己的工作/功能并且仍然无法使每个冲刺都失败，则-您将无法监督自己代码的复杂性；-或代码是如此复杂，以至于没有人能够监督复杂性。 我想念什么吗？

124 scrum  planning 

我是计算机科学专业的大一学生，我们刚刚开始用Python做一些实际的项目。我发现使用教授在课堂上建议的笔和纸的方法时，我的效率很高。但是当我无法写下问题并在纸上解决算法时，我真的很慢。在实验期间，我似乎总是不得不将作业带回我的宿舍。当我到达那里并把它写出来时，我解决了让我全班学习仅5分钟的问题。 也许是因为我感到压力重重，看到人们在我之前解决了实验室。也许这是笔和纸的方法。 我在论坛上浏览，有人写道，如果您必须在纸上编写程序，那么您不应该是程序员。我真的很担心，因为当我看到程序在做什么并且在键入实际代码之前跟踪程序运行的过程时，我会好得多。难道我做错了什么？ 编辑：很抱歉，不清楚，但是当我说在纸上写时，我的意思是我的问题解决方法（例如，编写示例，使用值创建表等）不是我的实际代码。我只是用纸来表达我的想法。

54 algorithms  planning 

我们正在使用Scrum，偶尔发现我们无法在计划的sprint中完成用户故事。无论如何，我们都会以真正的Scrum风格交付软件，并考虑在下一个Sprint计划会议期间的下一个Sprint中包括用户故事。鉴于我们要继续执行的用户故事已部分完成，我们如何在下一个Sprint计划会话中对其进行正确估算？我们考虑过： a）向下调整故事点的数量以仅反映完成用户故事所需的工作。不幸的是，这会使报告产品积压工作变得混乱。 b）关闭部分完成的用户故事，然后提出一个新故事来实施该功能的其余部分，这将减少故事点。这将影响我们回顾性地查看在该冲刺中未完成的工作的能力，这似乎很耗时。 c）不用理会a或b，并在Sprint Planning期间继续猜测，诸如“用户故事可能是X故事点，但我知道它已经完成了95％，所以我确定我们可以适应它”。

50 agile  scrum  estimation  planning 

这一周的工作中，我又变得敏捷了。经历了标准的敏捷，TDD，共享所有权，临时开发方法，从未计划过一张卡片上的几个用户故事，口头上嚼了一个第三方集成广告恶心的技术，却从未真正做过思考或应尽的努力，并将所有生产代码与过去几个月来遇到的第一个测试在体系结构上耦合起来，我们到达了发布周期的结尾，并且发现我们一直在开发的主要外部可见功能太慢而无法使用，越野车，迷宫般变得复杂而完全不灵活。 在此过程中，“尖刺”完成了，但从未记录下来，也没有生产出任何单一的建筑设计（没有FS，所以，如果您不知道自己在开发什么，该如何计划或研究它？ ？）-项目是成对进行的，每个人一次只专注于一个用户故事，结果是不可避免的。 为了解决这个问题，我放弃了雷达，去了（可怕的）瀑布，进行了计划，编码，基本上并没有放弃这一对，并尝试了我一个人尽可能多的工作-专注于坚实的体系结构和规范，而不是单元测试。一切确定后，我们将在以后发布。该代码现在更好，并且实际上完全可用，灵活且快速。某些人似乎真的很讨厌我这样做，并且竭尽全力破坏我的努力（可能是无意识地），因为这违背了敏捷的神圣过程。 因此，作为开发人员，您如何向团队解释计划他们的工作并非“不敏捷”，您如何使计划适合敏捷过程？（我不是在谈论IPM；我是在谈论坐着一个问题，并草拟一个端到端设计，该设计说出应该如何充分详细地解决问题，以便从事该问题的任何人都知道他们应该使用的架构和模式，以及新代码应集成到​​现有代码中的位置）

50 agile  planning 

我们在这里开始使用Story Points进行敏捷开发，但是我很难解释，也找不到任何明确的答案。我能做的最好的事情是指向其他站点（例如http://blog.mountaingoatsoftware.com/tag/story-points），并对它们的含义进行一些模糊的概括。我正在寻找一些使用示例的良好解释，这些示例将对其他使用示例有所帮助。有没有很好的资源可以解释故事要点？

36 agile  estimation  planning 

我已经看到多篇关于应用程序重写的文章，这些都是不好的，人们在Programmers上的经历，以及Joel Spolsky编写的关于该主题的文章，但没有确凿的证据或案例研究。除了Joel给出的两个示例以及此处的其他一些帖子外，您如何处理不好的代码库，以及如何根据实际研究决定如何处理它？ 就目前的情况而言，我知道有两个客户端都具有旧的遗留代码。他们一直之以鼻，因为正如其中之一发现的那样，重写是一场灾难，这很昂贵，而且实际上并不能有效地改善代码。随着重写者迅速发现，该客户具有一些非常复杂的业务逻辑。 在这两种情况下，这些都是关键任务应用程序，可为公司带来大量收入。试图重写的人认为，如果将来某个时候不对旧版软件进行升级，它们将陷入困境。对我来说，这种风险需要进行研究和分析，以确保成功的道路。 是否有实际的案例研究对此进行了调查？我不希望尝试大量重写，而无需根据实际研究了解一些最佳实践，陷阱和成功。 后果： 好的，经过更多搜索，我确实找到了三篇有关案例研究的有趣文章： 重写或重用。他们对转换为Java的Cobol应用程序进行了研究。 另一个是关于软件重用：开发人员的经验和看法。 重用或重写关于维护与重写成本的另一项研究。 我最近找到了另一篇有关该主题的文章：The Great Rewrite。在那儿，作者似乎遇到了一些主要问题。随之而来的是通过使用建议的新技术堆栈并测量开发人员将其拿起的速度来进行原型制作的想法。这全都是重写的序幕，我认为这是个好主意！

36 source-code  planning  code-reuse  rewrite 

Scrum团队如何在计划会议中解决开发/基础架构任务？ 乍一看，它们似乎不像用户故事，因为它们无法传递最终用户价值。 但是，将它们作为任务附加到特定用户故事有时也没有意义。例如，说任务是：“安装竹子”。不需要完成该任务即可完成任何用户案例，因为团队可以手动构建和部署。因此，将其附加到用户故事没有意义，因为不需要完成此任务即可完成用户故事。 因此，这表明这些任务成为了用户故事。但是，如果团队故事指向他们，那么这将改变速度，这是奇怪的，因为产品负责人想知道积压的速度，而不是积压了大量技术用户故事的积压速度。

33 scrum  planning 

与许多公司一样，我工作的公司正在过渡到基于SMART目标的绩效评估系统。我的团队是一个高效的敏捷开发团队，采用了Extreme Programming的实践。为了使我们受益匪浅，我们在敏捷实践中的使用得到了直接和高层管理人员的全面支持。 为了完成工作，我们的团队利用了三周的迭代时间。除了立即迭代之外，我们还制定了一个总体计划。这意味着我们从现在开始的几个季度将要完成的工作比我们在最近一个季度将要完成的工作要模糊得多。我们当然对项目的发展方向有一个大致的了解，但是这里的关键字是general。 考虑到我们对团队中项目规划人员的态度，包括我自己在内，发现很难写出具体，可测量，可实现，相关且有时限的目标（SMART）。 关于SoftwareEngineering.se的两个现有问题很好地解决了我们的一些担忧： 对程序员来说，一个好的SMART目标的例子是什么？ SMART目标对程序员有用吗？ 但是，在敏捷开发团队中工作时，这些问题在处理SMART目标方面引起了比具体问题更多的一般回答。作为敏捷开发人员，您如何编写五到七个长达一年的目标，这些目标是特定的，可测量的，可实现的，相关的且有时间限制的？

29 agile  management  planning  review 

在办公室，我们刚遇到一个视力障碍的新同事。 我负责组织计划扑克会议，新同事必须作为团队成员参加。我们有这些漂亮的扑克牌集，上面有计划的扑克号码，但这对我们的新同事当然没有帮助。 到现在为止，我们仅通过命名估算值来解决此问题，让新同事在其余人放下他们的卡后立即说出他们的估算，然后其余人翻转他​​们的卡，我将其连续命名。 我的问题：是否有人在这种情况下有经验并有更好的解决方案？有盲文扑克牌吗？ 当前的解决方案确实有效，但是我认为可以通过例如盲文扑克牌为我们所有人改善这一点。

24 agile  scrum  planning  project-planning 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 我一直在想为我的团队将要开发的新开源产品做出贡献。我们鼓励我们尽可能地从更广泛的社区中获得支持，但是我也可以看到这花费了大量的时间，以确保位于办公室外的第三方能够按计划处理诸如代码质量之类的事情。同样在项目开始时，我们可能会在核心团队中进行许多有关系统设计，峰值等的非正式讨论，将这些在线获取以允许社区参与将非常耗时，我可以想象可以使讨论效果较差。 这可能需要考虑更多的人性化方面：允许社区参与设计过程也可以从感知到的项目所有权方面受益，并且总是有可能早期参与可以解决核心问题。团队没有注意到。 那么问题来了：您应该在开源项目的哪个阶段邀请社区的贡献？

23 project-management  open-source  team  contribution  planning 

尽管人们普遍认为计划扑克可以提高项目估计的准确性（在这个问题上证明了其中的一小部分），但是是否对此主题进行了明确的研究？ 更具体地说，我正在寻找非偶然的信息，以表明计划扑克将是对传统估算技术的一种改进。

20 agile  estimation  planning  research 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 我是一家小型创业公司的总监。当前，我们有两名正在构建Web应用程序平台的程序员（一名经验丰富，一名经验较少）。 迄今为止最大的挑战之一是规划过程。程序员通常负责计划自己的工作，但我们不断超出自己设定的期限。例如，他们估计一项任务需要2天，而最终需要8天。 对我而言，很难为他们提供计划支持，因为我缺乏准确估算某个任务将持续多长时间的技术知识。 你有什么主意吗： 这是什么原因，对于程序员来说这很常见吗？ 我可以做些什么来支持他们的计划？有没有对小型团队的程序员有用的方法或工具？

18 php  planning 

在团队中首次实施Scrum时，如果不了解团队的速度，应该如何确定初始冲刺中的故事点数量？ 您是否应该基于估计的小时数，而仅在以后使用积分？

18 scrum  planning 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 假设我已经从客户那里收到了一个项目的规范，现在是时候开始开发它了。通常，我只是从第一个模块开始（通常是用户注册），然后从一个模块进入下一个模块。我只是在即将开始模块工作之前就在脑海中计划，但在此之前没有任何计划。 但是，我认为最好在编写代码之前仔细阅读规格并计划系统的工作方式，例如主要组件是什么，它们将如何交互等。我只是不确定我应该怎么计划。 为了更好地了解我的要求，我应该如何- a）将项目分为几个部分， b）计划他们的交互，例如我应该做类图，编写单元测试等吗？ 有任何想法吗？

17 project-management  design  self-improvement  planning  specifications 

根据您的经验，Sprint计划会议（Scrum）应该持续多长时间？8小时？还是应该缩短（简洁），并计划将更多讨论作为冲刺的一部分？我们的Sprint为期10天。

16 agile  scrum  planning