标签: scrum

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

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

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

我有以下问题:

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

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

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

非常感谢提前.

在我们公司,我们在每个Sprint结束时进行可用性测试.很多时候我们发现用户不喜欢已实现的功能,因此我们要么完全更改它,要么在下一个Sprint中将其废弃.

但是,如果我们开始做可能的可交付产品,从而修复所有错误,运行大量测试,为FDA和用户准备文档,修复很少的UI问题 - 如果用户不喜欢这个功能,所有这些工作将会浪费.在我们确定用户真的喜欢这个功能之前,不是最好不要做所有这些额外的可能发送的东西吗？

我们一直在尝试Scrum,但现在正试图将其正式化为我们自己的敏捷应用程序开发版本.以下是我们当前流程的工作原理.它现在有两个主要缺点.想要了解你是否有类似的方法,以及社区是否有任何关于我们目前遇到的障碍的实用技巧.

• Scrum团队= 4名开发人员,2名QA,1名技术作家,1名PO(PM),1名Scrum Master(Engg Dir)
• 发布= 3 Sprint
• 冲刺= 2周

PO和客户创建产品积压的用户故事和相关的验收标准.
在每次迭代开始时进行1周的Sprint计划

• 第1天#估计Sprint积压并同意优先权
• 第2-5天#Scrum团队在Sprint积压中讨论故事并处理每个故事的细节(获取故事的详细信息,流程流(如果有),确定要应用的UE准则,UI项目/字段/小部件的详细信息及其如果需要任何特定的行为,了解验收标准并创建测试)
• 2周冲刺,每天15分钟的scrum
• 重复3周循环

我们在这方面遇到的两个主要缺点是:

1. 春季计划周中讨论的细节无法有效捕获并在维基上注明.由于在Scrum中没有用于捕获此类详细信息的标准格式,因此通常会在每日Scrum中浪费时间,或者需要后续会议来进一步了解故事详细信息.什么是在sprint计划中捕获功能相当复杂的产品的故事细节的最佳方法？大多数问题似乎是围绕用户界面和开发人员无法决定如何在没有详细模拟的情况下布置屏幕/字段.
2. 当团队处于冲刺周期时,您如何预测从客户那里回来的关键showstopper错误.目前,开发人员不得不被用于支持这些红色帐户问题,从而破坏冲刺.

关于我们如何改进这一点的任何意见？

我使用scrum工作大约2个月,并没有我想要的所有经验,所以我想听听一些有关它的意见.

我担心的是人们从未说过双方的弊端; 公司和工人.我知道跨职能团队的好处,但哪些是缺点？隐藏在令人惊叹的伊甸园旁边的是什么？

我很困惑,因为作为一个公司的可替换人员的好处,因为团队是好的,因为有机会获得知识和分享经验(除了所有团队合作的好处).

再一次,我知道所有的好处,但我想探索缺点只是因为在中间有普通人.通常这些人致力于获取知识.他们购买书籍,课程,参加研讨会等.

在每个公司,当有人比其他人都知道的更多时,人们和经理会绝望地希望甚至要求这些普通人分享他们所有的知识.

这很奇怪..因为这些是共产主义思想,我们生活在资本主义社会中,自从我出生以来,一切都如此竞争,现在人们都在谈论合作.

Scrum和精益原则能否破坏(或努力)专业人士的生活？

我一直在学习Scrum并尝试使用一种叫做Acunote的工具.我的问题是关于每个任务我在那里的两个领域.他们是"估计"和"剩下的".我应该用哪些单位？我使用故事点吗？剩下的呢？例如,我有一个任务需要10个单位,比方说.我在剩下的一天结束时填写了多少"单位",我相信它会让我完成？

谢谢!

有没有人知道一个很好的网络服务,我可以在那里与其他人一起编写和修改用户故事？我用过Google的Wave.但截至2012年,谷歌确实关闭了这个项目.

我在我的电脑上安装了Microsoft Visual Studio Scrum 1.0,我将把它上传到我的TFS.我应该在连接到此TFS的每个Visual Studio副本上安装吗？

在我的Scrum工作流程中,当故事的开发完成后,故事将被转移到已解决状态,并且只有在完成QA之后,故事才会关闭.

由于QA团队与开发团队分开工作,当我跟踪开发团队进度时,我希望烧毁图表反映团队进度,因此任务应该被视为已在已解决状态下完成,而不仅仅是在已关闭状态.

PSP是增量，我在冲刺结束时。对客户有价值的东西。MMF不一样吗？不过，我对客户也很有价值......

请帮我理解PSP和MMF之间的区别

谢谢

Scrum 中的产品负责人应该如何处理团队提出的关于他们正在实施的功能的非常详细的问题，而他自己却无法立即回答？什么时候开发人员直接与客户本人交谈显然是更快的解决方案？

我想知道团队和客户之间的直接沟通是否会破坏产品负责人的角色。我觉得 PO 应该专门代表客户，因此回答有关要求的所有问题 - 即使这需要更长的时间。绕过他似乎削弱了他，最终让他变得多余……

Scrum 中是否有最佳实践？

你把什么定义为障碍？我知道Scrum说这个并且阻碍了团队阻止团队尽力而为.基本上它可以是一切吗？但是它成为什么样的神奇线和内部改进？

例如.我们希望在我们的数据库中拥有更真实的测试数据,这是内部改进还是障碍？我们作为一个团队可以尝试直接在sprint中解决它,或者我们可以说这是一个内部改进,需要成为一个故事并进入产品积压.

在我看来,我们有三个选择:1.将所有内部改进作为待办事项中的故事处理,并使PO优先考虑它们.2.在冲刺中的常规故事中与他们一起工作.3.重要的事情是我们可以直接在冲刺中做的故事和小事情,而不会影响速度.

你怎么处理这个？我们需要有关如何做到这一点的提示和想法:)

我猜想有很多情况下估计在某些时候是错误的.因为只要深入了解积压项目的细节,您就可能几乎总能找到在规划期间没有考虑过的事情.这可以在任务级别sprint估计期间或在实际sprint期间发生.

在任务级别估计期间,您可能会发现故事/积压项目的许多任务,因此需要调整初始估算. 你现在做什么？您是否回到产品所有者并告诉他他可能想要重新确定其积压物品的优先顺序,现在需要更长时间(甚至更少)？基本上它可能意味着整个团队需要回到故事级别的估计并重新调整故事？

在sprint期间,您可能会发现实现需要比最初想象的更多的努力. 你现在做什么？知道你无法按计划完成它,你是否默默地继续冲刺？从现在开始,您将为所有估算添加"安全缓冲区"？

一般来说,SCRUM如何解决整体估算精度问题？

如果我理解正确,那么SCRUM开发团队就会"承诺"产品所有者将按计划交付.但只有准确估计才能做到这一点.所以估计似乎对SCRUM的成功非常关键,但也非常困难.

现在我正在学习敏捷流程。我正在学习所有敏捷的东西。我正在和我的一位朋友聊天，他问我，我们可以一起进行冲刺评审和计划吗？当他问我的时候，我无语了。谁能告诉我他们在一起好不好？