有人在一起使用Fogbugz和Scrum吗?
我们广泛使用Fogbugz,我正在寻找任何可能将其作为Scrum一部分使用的人的想法.我找到了这两个项目,但它们已存档,无法进一步讨论.我对将Scrum概念映射到Fogbugz的想法特别感兴趣.
有些事情是相当明显的.发布和冲刺相互映射得很好.但是Scrum的其他部分并不适合.
http://support.fogcreek.com/default.asp?fogbugz.4.12143.4
http://support.fogcreek.com/default.asp?fogbugz.4.19971.3
我也认为创建一些轻量级的自定义东西来包装Fogbugz可能并不太难,因此我们不必放弃我们最喜欢的工具之一来改进我们的软件流程集成.
编辑:
我正在添加一些更具体的问题.对这些项目的任何建议都会有所帮助:
编辑#2:
克里斯在下面的回复提醒我,我们确实升级到了Fogbugz v7.它具有许多强大功能,可以与Agile,Scrum和Lean更紧密地协调,包括:
有关详细信息,请参阅以下链接:
http://www.fogcreek.com/FogBugz/WhatsNew.html
http://www.fogcreek.com/FogBugz/Plugins/default.aspx?ixCategory=-3
编辑#3 添加Perhentian在他的回答中提到的链接以及我发现的另一个链接:
http://www.danielroot.info/2009/08/how-to-apply-scrum-using-fogbugz-7.html
http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features的.aspx
我的组织一直在尝试引入更多"敏捷"方法.我们一直在尝试Scrum方法,大多数团队或多或少都适应了它.我喜欢它作为一个整体,但我担心该方法的一个潜在的严重影响:由于团队一直专注于功能和积压项目,并且测试人员与整个开发过程更加整合,似乎技能组合正在变得模糊不清,人们对自己的个人能力缺乏尊重.
我们的一些开发人员在服务器端技术和优化重量级数据配置方面表现出色.其他人已经投入了大量的职业学习GUI技术,并在应用程序中对用户和可用性有了基本的了解.技能组合都不比另一组技术好,但它们肯定是不同的.
这是Scrum流程的必然结果吗?由于团队中的每个人(据我所知)都有助于满足下一个功能/要求,积压项目或测试目标,因此基本理念似乎是"任何人都可以做到".根据我的经验,这根本不是真的.大多数工程师(开发人员,测试人员等)都拥有他们多年来磨练的特定技能,而在我看来,Scrum方法往往会贬低他们之前所尊重的那些能力.
这是一个澄清的例子:
如果服务器端数据配置发生突然的技术更改,并且sprint的待办事项列表中的每个项目都基于这一新变化,那么GUI开发人员(可能没有时间适应新技术)可能无法为冲刺做出贡献.至少,他们需要投入时间来加强,然后他们的代码将因为缺乏经验而受到怀疑.
我理解快速发展的必要性,以阻止"角色孤岛",但这并没有打折一个基本现实:人们根据必要性,兴趣或经验发展技能.当人们认为他们的位置是"插件能力"之一时,他们似乎没有那么积极性(例如,我们可以"插入"任何人来执行这项特定任务).Scrum如何解决这个问题?如果没有,有人在采用Scrum方法时解决了这个问题吗?
Visual Studio Scrum 1.0和MSF对Agile Software Development v5.0流程模板的区别有多大?
有人用过一个吗?
我们目前正在使用外部工具(TRAC)在我们的开发过程中实施Scrum,因为MS在TFS2010中提出了额外的过程指导,这两件事使我对核心感到困惑!
不确定,哪一个采用!
我们正在使用VS 2010和TFS 2010以及Microsoft Scrum模板.
我们使用当前Sprint的团队查询,如Sprint Backlog查询.
问题是当我们转向冲刺2时,"当前冲刺"仍然指向冲刺1.
有没有办法告诉TFS我们现在正处于sprint 2并且让查询使用变量来运行而不是硬编码sprint?
例如:如果您查看下面的屏幕截图,您会注意到查询的定义使用了一个名为"@Project"的变量作为团队项目.有没有办法为sprint提供变量?
我在读这本书"软件架构师的职业",由马克和劳拉·休厄尔(亚马逊链接),它让我想一个软件架构师是否是旧的非敏捷BDUF方法的一部分.
软件架构师是否有灵活处理的地方?我对Scrum特别感兴趣.
BTW我目前是一家大公司的Unix应用程序架构师.
干杯,
抢
我正在使用Visual Studio Team Services(以前是Team Foundation Service,而不是Team Foundation Server),我需要将团队项目流程模板从Agile迁移到Scrum.
Doe有谁知道怎么做?
我们正在使用Jira/GreenHopper在Scrum团队中运行我们的冲刺.事实上,Jira是一个bug跟踪工具,而GreenHopper是一个Scrum-ish附加组件,这一事实变得非常痛苦.
我们希望我们的产品负责人在Jira/GreenHopper中输入用户故事,并让团队将技术任务挂在用户故事上.怎么做到这一点?Jira/GreenHopper似乎没有关于任务的用户故事的概念.这是正确的还是我错过了什么?
此外,我们希望Jira/GreenHopper中的任务板跟踪用户故事和任务,从"待办事宜"到"完成".再一次,似乎没有办法做到这一点.用户故事在完成所有任务后即完成.用户故事正在进行时,任务应该能够从待办事宜移动到完成.我们认为Jira/GreenHopper任务板不能这样做是否正确?
我一般对如何使用Jira/GreenHopper来解决上述问题的想法,书籍,教程等感兴趣.
最近和我的同事一起讨论了如何在Scrum项目中组织版本控制.更具体地说,分支创建的标准(每个开发人员,每个任务,每个故事,每个Sprint?)和集成方法.
我的意见是组织它的一个有用的方法是为每个用户故事创建一个分支,这样你就可以在完成后将每个Story集成到可释放的trunk中,并且它还允许你总是拥有应用程序的"可交付版本"任何时候.
因此,如果一个故事无法完成,它可能会被排除在外,并且不会影响sprint版本.(考虑到集中式工具,如果使用分布式工具,则考虑因素会有所不同)
我想知道你自己的方法,你喜欢哪种工具,以及你从经验和所吸取的教训中看到的利弊.
我很好奇社区是否认为在我们停止开发的情况下使用"Code Freeze"一词是可以接受的,除了测试和修复bug.
发展情况
我们刚刚完成了我们的第三次也是最后一次冲刺,之后将进行"代码冻结"和2周的Q/A测试.这是一个很大的发布,一些组件开发超越了所有3个sprint.从历史上看,即使我们将其称为"代码冻结",我们仍然会提交代码来修复错误.
问题
每一个版本我都会尝试并纠正我的经理和同事,我们应该将其称为"功能冻结",因为很明显我们会在我们开始大量测试后立即找到错误并提交代码来修复它们.但是他们仍然坚持称其为"Code Freeze".有时我们仍然知道错误并声明"代码冻结".
维基百科的定义在这里似乎与我一致
分析
我怀疑将这些情况称为"代码冻结"是某种故意的双重思考,为利益相关者提供虚假的信心.或者我们假装处于"Code Freeze"状态,因为根据Scrum的说法,在每个sprint之后我们都应该有一个可发送的软件,这是我们对Scrum的期望.所以我们必须把它称之为Scrum所期望的而不是它真正的本质.
结论
我在分析这个吗?我只是发现忽视情况的现实是不健康的,应该放弃它,称之为不是或者解决根本问题.还有其他人有过与Code Freezes类似的经历吗?
Microsoft Visual Studio Scrum 2.0与MSF for Agile Software Development 6.0之间的区别是什么?
我希望获得有关Visual Studio和TFS用于敏捷开发的最佳模板的反馈.我很想知道是否有人能告诉我Visual Studio中两个最新模板之间的区别.
scrum ×10
agile ×5
tfs ×3
tfs2010 ×2
architecture ×1
azure-devops ×1
code-freeze ×1
fogbugz ×1
jira ×1
jira-agile ×1
msf ×1
process ×1
testing ×1