Questions tagged «kanban»

从很高的角度来看，在我看来，通常有两种类型的项目管理工具： 传统问题跟踪工具，例如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 

我在Pivotal Tracker板上添加了一些解决一些技术问题的用户案例。我应该将它们视为特征（保持速度水平）还是杂务/虫子（降低速度）？我知道，如果我坚持一贯做下去，从长远来看不会有任何区别，但是每次我添加技术债务的故事时，我都必须做出决定。 一些想法： 它们实际上不是错误，它们不会破坏任何东西 用户没有要求任何东西，因为它是不影响他们的低级实施，但是它将使长期开发变得更容易 如果您将功能定义为能够为用户增加价值的故事，那么a）他们不会，因为用户不会看到任何直接的利益，但是b）它们会这样做，因为它们使将来的开发/维护成为可能，从而确实可以增加价值，只是现在不行 我不决定是否真正进行这项工作，或何时安排它，我只是想知道我应该在项目管理工具中称其为技术债务的原因，以及原因。

19 project-management  agile  technical-debt  kanban 

我喜欢XP（极限编程），尤其是在同一屏幕上有2个程序员的部分，因为通常只有您解释自己在做什么，而结对编程会迫使您解释自己在做什么，这样才能更快地找到问题的解决方案在做。 在过去的10年左右的时间里，XP的工作方式似乎已经过时，倾向于使用工作方法：敏捷和/或看板。为什么？因为XP在我看来是一种很好的工作方式，并且与编程有关，而敏捷和看板则与过程有关。

15 agile  extreme-programming  kanban 

我的团队使用看板系统来跟踪日常进度，并且对于理解功能（捕获为用户故事）的进度非常有效。随着我们开发功能的发展，直到最近，我们在很大程度上允许我们的系统设计出现。在过去的两周中，我们就与性能和可修改性质量属性特别相关的架构取舍进行了多次讨论。 我认为正在发生的事情是在实现功能和设计系统时，我们在隐式地做出有关体系结构的决策，而不是根据我们已知的质量属性要求来考虑这些决策。如果我能够跟踪/捕获/直观地描述这些重要的设计决策是如何做的，那么团队成员将有更好的机会在实施系统时不给系统架构带来额外的压力，这真是太好了。当然，更复杂的是，我们板上的功能并非仅能发挥功能，有时会掩盖架构的复杂性！ 如何在团队看板上直观地跟踪质量属性（或其他与体系结构相关的决策）的进度？

13 agile  tracking  architecture  kanban  quality-attributes 

从看板开始，我不确定我的工作项目应该有多细。当您找到有关如何选择WIP的许多具体建议时，我阅读的大多数看板教程对工作项的大小（=板上的卡片）仍然含糊不清。 为了进行计划和估算，人们通常建议将商品的尺寸保持较小，例如2-16小时。看板也一样吗？从我的计划到董事会是否总是存在1：1的映射？ 如果没有最佳实践或一般建议，哪些因素会影响我对工作项粒度的选择？

11 kanban 

考虑一个典型的看板： 输入，分析，开发就绪，开发，构建就绪，测试，发布就绪 如何为每列指定在制品限制？有什么公式吗？

10 kanban