标签: agile-processes

我们使用JIRA进行错误跟踪和发布管理,我们已经开始在JIRA中使用greenhopper进行项目管理,但缺少的一点是用户故事与这些用户故事中的任务的概念.有没有人推荐其他任务板,如敏捷项目管理工具,完全支持用户的故事和任务,以及快速和简单的用户.我开始关注targetprocess,所以如果有人对此有反馈,那么它也会很棒.

在我看来,敏捷方法鼓励我们保持简单,精益,而不是在需要之前增加复杂性和复杂性.但是,技术变革的速度和数量鼓励使用越来越抽象,复杂和复杂的工具和模式,以复杂的方式解决我们可能尚未(并且可能永远不会遇到)的问题,这些问题包括重要的学习曲线和大量的投入.

我在一个敏捷的小型开发团队工作,该团队是一家大型非敏捷思维公司的一部分.目前,我们实践Scrum,偶尔也会超出我们的冲刺承诺.

我的问题是,当你超过你的冲刺承诺时,你如何处理烧毁图表？我可以想到两个选择:

• 沿负方向延伸y轴并继续倒计时
• 添加更多卡片/故事/工作,并使烧毁值增加该量,并在完成该工作时烧毁.

我的团队的最终解决方案是业务清晰,为开发人员增加真正价值的解决方案.到目前为止,这些解决方案都没有完美解决.

这个帖子是我之前的一个跟进.这实际上是2个问题,所以我希望没有人介意,因为他们互相依赖.

我们正在开始一个新项目,我们认为这是一个尝试敏捷技术的好机会.我们对几本书和文章中的想法进行了头脑风暴,并提出了最适合我们的概念:2周迭代,然后与客户打电话,他们将在下一次迭代中选择他们想要的东西.我只有几个问题,我们无法弄清楚自己.

在第一次迭代中该做什么？

如果我们从头开始,通常在前几次迭代中做什么？只需对应用程序的代码核心进行一个月的开发,或者从具有有限预编码功能的简单线框开始？通常客户想看到什么？闪亮的东西不起作用或丑陋的东西有效吗？

如何与客户沟通？

我们最初认为将过程设置为这样的过程:

alt text http://img690.imageshack.us/img690/2553/communication.png

在客户端有一个联络点是一个好主意,还是最好直接与所有客户沟通以防止误传？

欢迎任何想法!提前致谢.

这些天听到很多关于DevOps(操作中的敏捷技术)的信息.有人能否对实际开发人员在此过程中的参与程度有所了解？

假设您正在编写一段遗留代码,该代码是在您的公司开始使用像Scrum这样的敏捷方法之前编写的.

现在让我们说你发现了一个需要修复的字段中的错误,并且从来没有写过该功能的故事.团队中的每个人都知道这个特殊功能是什么以及它应该如何表现但只是没有与之相关的故事.

现在,在当前的冲刺中,您将处理该缺陷,因为市场营销和支持部门已经厌倦了处理该问题.

你是否回想起要链接到的缺陷？您是否将您的缺陷重新标记为故事并修改格式以使其看起来像故事？如果你没有创建一个故事,你会得到缺陷的分数吗？如果您确实创建了一个故事,那么您是否可以获得修复缺陷的要点(通过故事的要点)？

处理这种情况的最佳方法是什么？

更新:假设安装过程突然在Windows 7 64位上开始蓝屏系统,并且始终要求应用程序安装在所有Windows平台上.由于Service Pack 1或类似的东西,新问题可能已经出现.

我已经阅读了scrum,我工作的公司已经开始使用它了.我发现布置任务确实有助于每个人看到需要做什么以及要做什么.我们遇到的一个问题是,我们只是通过我们的一个项目"试用"scrum.我们为客户提供了许多自定义应用程序.其中一些客户优先于其他客户.如果他们打电话请求报告,我们提供.

是否有一个过程(Scrum或其他)可以用来帮助我们满足这些需求？目前看来,由于我们没有时间做故事时间和每天计划扑克,因此我们的冲刺中并没有计算每日需求.

有什么想法吗？

我确实找到了这个问题,讨论如何整合多个项目,而不是日常需求.

有没有办法从TFS 2012中的MSF Agile 6.0迁移到Scrum流程模板？我们最近从TFS 2010迁移到2012年,并希望在不丢失历史记录的情况下更改流程模板.

我听说过http://witsynchronizer.codeplex.com/但是有人试过TFS 2012吗？

任何人都可以用简单的术语向我解释螺旋和敏捷模型之间的差异,因为我是初学者？你能给我一些真实的世界吗？螺旋比敏捷更有用,反之亦然...我知道互联网上有很多链接,但是我很难理解,因为我是初学者.所以如果用简单的术语解释会有很大的帮助吗？ ？提前完成了...

我是一个致力于软件产品发布的敏捷Scrum团队的一员.冲刺持续时间为2周(约10天).

这里使用了一种特殊的度量标准,称为" 中间冲刺接受 ".从本质上讲,期望是sprint团队在sprint中承诺和计划的用户故事点数的一半需要在sprint的中间完成.他们说,这会导致点线性燃烧,这是冲刺进展良好的一个强有力的指标.

作为一个团队,我们的中期冲刺接受通常很糟糕,但我们知道在冲刺结束时完成所有承诺的用户故事点.

我有以下问题:

1)中等冲刺接受是否是有效的敏捷/ SCRUM练习？是否在其他地方使用？

2)期望在一半时间内完成的工作的一半类似于将其视为"工厂底层"工作,其中手头工作的性质和复杂性是完全确定的.由于软件开发是一个"创造性"过程,因此像Agile这样高度灵活的方法中的这种严格的度量标准是无关紧要的.你怎么看？

3)虽然我的Scrum团队及时完成了所有我们的承诺,但是我们正在质疑我们糟糕的中期冲刺接受指标.在其他地方的scrum团队中,只有在他们的短跑结束时才能履行他们的承诺,这是完全正常的吗？

非常感谢提前.