标签: scrum

引用维基百科:

Scrum由ScrumMaster提供便利,ScrumMaster的主要工作是消除团队实现冲刺目标的障碍.ScrumMaster不是团队的领导者(因为他们是自我组织的),但作为团队和任何分散注意力的影响之间的缓冲.ScrumMaster确保Scrum过程按预期使用.ScrumMaster是规则的执行者."

在这个基础上工作,以及大多数企业一次运行2-3个项目的事实,SM为填补全职工作做了哪些实际的工作任务？或者,这不是一份全职工作,而是个人做其他事情,如开发,销售等？

有没有什么SM可以分享？

从这个链接我断言一个功能是一组积压项目,但什么是史诗应该是什么？

Redmine中对Scrum的最佳支持是什么？

• 最佳做法？
• 插件支持？

我尝试的所有插件要么不再那么活跃和/或不能完成使用Scrum管理一个主要项目的任务.

我用Google搜索无济于事......

我从头开始创建一个新项目并编写用户商店来描述给定用户如何与系统交互.但是,我无法理解如何在没有第一个成为史诗的任务中打破第一个用户故事.

例如,如果我正在制造汽车,并且第一个用户故事说"作为司机,我希望能够改变运动的方向,这样我就不会碰到东西.",这意味着用户接口(方向盘),还有运动(车轮)和将它们连接在一起所需的一切(车轴,车架,连杆等......).最后,第一个用户故事似乎总是代表项目的大约40%,因为它对底层架构意味着很多.

你如何打破新项目的用户故事,使第一个不成为代表整个底层架构的史诗？

我在办公室工作,现在已经做了一段时间的敏捷.我们使用Scrum进行项目管理,并混合使用XP的工程实践.它运作良好,我们不断学习课程和完善我们的过程.

我想告诉您我们通常的测试实践,并获得有关如何改进的反馈:

TDD:第一道防线 我们对单元测试非常虔诚,我会说我们的开发人员也经验丰富,可以编写全面的测试,并始终将SUT与模拟隔离开来.

集成测试 对于我们的使用,集成测试基本上与不使用模拟的单元测试相同.这往往会抓住一些问题,这些问题在单元测试中滑落.这些测试往往是难以阅读,因为它们通常涉及在大量或工作before_each和after_each规范框架的部分作为系统,以便为测试是有意义的经常达到一定的状态.

功能测试 我们通常以结构化但手动的方式执行此操作.我们玩过Selenium和Windmill很酷,但对我们来说至少还没有.

我想知道其他人是怎么做的.你是否认为如果集成测试或功能测试做得好,另一个可以被忽视？

要执行敏捷项目,首先需要一份合同.没有合同 - 没有项目!没有项目 - 没有敏捷,SCRUM或任何东西!

如果我们谈论大中型项目,合同必须有明确的安全触发器.即客户希望非常肯定,如果我们同意在时间上结束项目= T,预算= B和范围= S,我们最终不会以时间= T×2,预算= B×3或范围= S/2.

另一方面,作为提供产品的公司,我们不希望项目意外结束.即如果经过一番迭代,客户说"现在我发现这实际上就是我们所需要的.我们现在停下来." 这个项目计划再过2个月,而不是没有计划工作的人.如果3-6人不是一个大问题,15-25可能是一个真正的问题!

然而,我没有找到任何具有安全功能的合同的真实示例,这将允许项目以完全敏捷的方式执行(声明或未向客户声明).我在许多论坛上找到的标准说法 - 与客户交谈,向他解释这是一种更有成效的工作方式等,并不能说服我和我的管理层.并不是说我们不相信敏捷实际上是一种更好的方式.只是安全触发器中的差距是如此明显,以至于我们的客户都没有买它而且我们不喜欢它们(差距,而不是客户;)).

请不要"它可能会以这种方式工作......" - 我已经阅读了大量的内容.只对"为我们这样工作"感兴趣.毫无疑问,跳过所有自信的信息.

PS据我所知,标准迭代,特征驱动的方法建议客户在每次迭代(迭代次数)后付款,并且能够在任何迭代之后由客户和项目执行者停止项目而不会过多地说明后果,而不是说"无论如何都会失败,所以越早越好"(这是正确的,但在签订合同时并不是很有帮助).

我想和我的团队一起尝试scrum.在这里研究了很多关于scrum工具的帖子,但我认为这些都是多余的,excel文件适用于产品和sprint积压.但这是一个很好的模板的问题.也许有人可以分享他用于scrum积压的excel模板？谢谢.

我们使用Trac作为我们的bug跟踪/开发/ wiki系统,我想知道是否有人有经验并使用一些Trac Agile/Scrum插件或功能？你推荐什么？

或者将Trac票证复制为死树用户故事索引卡和手绘燃尽图表会更好吗？

请注意,我在这里发现了类似的问题.虽然它特别关于Scrum.他们推荐Agilo.有人试过Agilo吗？

我在一个一直在做传统瀑布式开发方法的团队工作多年.最近,我们被告知未来的项目将朝着敏捷(特别是Scrum)方法发展.事实上,我的项目将成为第一个项目之一,因此我们将在接下来的几个月内成为几内亚猪,以确定实现转型所需的条件.

该项目本身处于非常早期阶段,我们通常需要几个月的时间才能向测试团队发布任何内容,但现在我们将直接与他们合作.因此,我担心测试人员在这个阶段在这样一个项目中的作用.我有几个问题/疑虑,希望一些经验丰富的敏捷开发人员可以回答:

1. 当开发人员编写任务时,测试人员无法对其进行测试(它还不存在).那么测试人员在这一点上的作用是什么
2. 测试人员现在参与单元测试了吗？这是否与黑匣子测试并行完成？
3. 在主要进行基础设施变更的冲刺期间,测试人员做了什么,这可能只能在单元测试中测试？

传统测试团队成员如何在敏捷项目中运行？

敏捷有哪些神话或误解？

有一些与敏捷有关的误解可能会导致普通新人陷入困境.敏捷世界有什么误解,你如何证明这是一种误解呢？

更新:敏捷神话总结

• 敏捷不允许文档
• 敏捷方法无法扩展
• 敏捷意味着没有计划
• TDD涵盖了所有单元测试需求
• 结对编程总能产生更好的代码
• 敏捷是解决软件工程问题的银弹解决方案(有一个银弹解决方案)
• 敏捷不需要预先设计
• 我们正在做scrum所以我们不需要做TDD,重构结对编程等.
• 人们可以从一本书中学习敏捷
• 敏捷只适用于琐碎的项目
• 敏捷总是使用"用户故事"

阅读以下答案,了解有关上述神话和更多神话的更多信息.