Questions tagged «scrum»

一个敏捷的框架,其中的产品所有者(PO),3-9个开发人员的开发团队(DT)和Scrum Master(SM)充当Scrum团队(ST)来构建和维持具有最高价值的复杂产品。他们在称为Sprint的时间范围内完成这项工作;冲刺可能会缩短,但可能不会超过30天。事件,角色和工件在官方的Scrum指南中有明确描述:http://scrumguides.org/scrum-guide.html

6
时间估计是否等于Scrum中的承诺?
如果估算不是一个保证,那么作为产品所有者,我如何在不知道需要多长时间的情况下交付项目? 如果我们将时间估算视为诺言,Scrum团队会更有效地工作吗? 故事中需要进行多少研究(准备工作,理解问题的努力)才能得出正确的估计? 估算工作后出现的意外技术问题(可能会严重干扰您的初始估算)会如何?


7
Scrum高估和重新计划
我们正处在第一个Sprint的中间,而我们的曙光已经来临:我们估计过高! 我们为这2周的迭代计划了114个理想小时,在第一周结束时,我们完成了整个Sprint。我们现在干什么?《书》说,我们应该而且我们将从积压中得到下一个优先事项。但是,如何将它们添加到燃尽图中?我们是否重新编写它来说明这些故事,就好像它们从一开始就在那儿一样?还是在我们开始研究它们的那天简单地将它们的估计值添加到y轴(显示90o角跳)? 欢迎任何反馈!
10 scrum  planning 

4
领域驱动设计中的重构
已关闭。这个问题需要细节或说明。它当前不接受答案。 想改善这个问题吗?添加细节并通过编辑此帖子来澄清问题。 6年前关闭。 我刚刚开始从事一个项目,我们正在使用领域驱动的设计(由Eric Evans在“ 领域驱动的设计:解决软件核心中的复杂性”中定义。我相信我们的项目肯定是该设计的候选人就像埃文斯在书中描述的那样。 我在不断重构的想法中挣扎。 我知道在任何项目中重构都是必不可少的,随着软件的改变,重构将不可避免地发生。但是,根据我的经验,重构是在开发团队的需求发生变化时发生的,而不是对领域变化的理解(Evans称之为“重构以获得更大的洞察力”)。我最关心的是对领域模型的理解方面的突破。我知道进行小的更改,但是如果需要对模型进行较大的更改怎么办? 在说服更清晰的域模型之后,应该说服自己(和其他人)重构的有效方法是什么?毕竟,为了改善代码的组织或性能而进行的重构可能与无处不在的语言代码的表达方式完全不同。有时似乎没有足够的时间进行重构。 幸运的是,SCRUM使它可以进行重构。SCRUM的迭代性质使其易于构建一小块并进行更改。但是随着时间的流逝,该片段会变大,如果您在该片段太大而又难以更改时又取得突破,该怎么办? 是否有人从事采用领域驱动设计的项目?如果是这样,那么对此有所了解将是很棒的。我特别想听听一些成功的故事,因为DDD似乎很难解决。 谢谢!

4
后端开发者被用户故事所压倒
我计划将后端开发垂直切入用户故事。但是我们团队的一个后端家伙开始抱怨这使他们的工作变得无形。 我的答案是 在冲刺计划和审查会议上,我们在利益相关者面前讨论了后端任务,以便使其可见,并且 在项目过程中保持高质量将导致启动速度比其他团队慢,但是在项目过程中我们的速度将保持稳定。利益相关者非常清楚地看到速度。 他仍然坚持有这样的故事:“作为开发人员,我需要一个域层,以便我可以封装业务逻辑。” 在污染团队之前,我该如何解决? 问题的根源在于,我们的管理人员系统地将后端工作视为无形的工作,并召集了受支持的开发人员矿工或其他贬义术语。
10 agile  scrum  team  user-story 

6
我们应该开始进行敏捷测试的哪个阶段(SCRUM)?
我的一些背景知识-在敏捷环境中,我使用SCRUM(1-2周冲刺)是手动测试人员将近2年。因此,我想在使用Selenium WebDriver(带有Java)的工作中引入自动化测试。 我的问题是在什么时候应该手动测试功能以及什么时候应该转换它们以进行自动化测试? 我一直在阅读并获得不同的方法,例如: 当开始新的Sprint时,将用户故事转换为上一个Sprint的自动化脚本,或者; 在相同的Sprint中转换用户故事。 任何建议将不胜感激。先感谢您。

7
在Scrum每日站立会议中进行与非签到相关的讨论是否可以接受?
我希望人们会给我一个潜在的明显问题。我曾在许多每天召开Scrum会议的组织中工作。一些组织确实严格只使用Scrum进行签入(“三个问题” –您昨天做了什么,您今天在做什么,您是否有任何阻止者?),而另一些组织则倾向于使用其他常规服务。公告或详细的技术讨论。 我已经听到过这样的争论,例如在本文中,允许像这样与非签到相关的讨论是一个错误-Scrum会议不应用于Scrum Master的一般公告,技术讨论等。 我从中看到的主要危害是会议的持续时间可能超过必要的时间(被迫参加与我无关的细节讨论很烦人)。 显然,与整个团队无关,不属于“三个问题”的讨论不应该成为直言不讳的一部分。但是,如果还有其他与整个小组相关的公告,无论如何都需要进行讨论,那么在那时(而不是在单独的会议或电子邮件中)进行讨论是否有害?

6
边缘案例的验收标准
我是敏捷团队的产品负责人。我在进行PO验收测试时,通常会记下一些极端情况的注释。对于我来说,发现一些东西然后将其传回给开发人员并不罕见。当我拒绝他的故事时,我正从一位开发人员那里退缩。他说这是不公平的,因为我没有详细说明极端情况以及程序在接受标准中应如何回应,因为他倾向于仅针对我在故事中描述的内容进行编码。我鼓励他问我,因为他在编写代码时碰到了任何极端情况,但是他认为思考极端情况,我的事不是我的工作,我应该为下一个冲刺创造新的故事。 在我的辩护中,直到故事实现后,我才知道他的故事设计,因此很难遍历所有可能性(配置将存储在数据库还是属性文件中?)。为了简单起见,可以说我们有一个故事要为计算器应用添加除法。在理想的SCRUM世界中,我是否有责任在接受标准上添加“零分手处理”,还是他应该在开发过程中认真研究这些情况,以使应用程序不会在5/0上崩溃?需要明确的是,在这种情况下,如果应用程序在5/0时硬崩溃,我将不接受,但如果它记录日志,打印DIV0或其他任何方式来处理错误,则我将通过。不会崩溃

8
在Scrum评估中讨价还价和失败的尝试是否合法?
我在Scrum会议中注意到,开发人员通常会对故事进行现实的估计。但是,即使是相当简单的故事,也需要大量的精力进行配置,设置第三方组件,测试和最终构建,并且系统积累了相当多的技术债务,因此对于产品所有者或管理层来说,估算值通常显得过高。 PO经常尝试降低此类估计,例如:“什么,您想要这个故事要13个故事点(4天),这不可能!我无法向管理层解释,有人应该可以对此进行编码3 SP [在4小时内!!”。结果,开发人员不得不屈服于做出5或8个故事点(1.5至2天)的估计值(Scrum估计值仍被视为承诺,而不仅仅是预测)。 当然,如果没有任何降低期望的计划(主要是在测试和质量方面),则这些冲刺经常会失败。开发人员的估算是诚实,现实的估算,击败估算并不会降低实际的工作量。 可以说:“您不应该做出不可能的承诺,只是因为有人逼着您去做!” 但是我认为,开发人员的工作是软件设计和编码,而不是讨价还价或承受压力!可能有各种各样的交易,通常是直接与外部客户打交道的交易,但这并不是大多数Office开发人员! 对我而言,这种做法只会使程序员看起来像个混蛋,会导致不断出现的sprint故障,并阻止了实际的估算,同时也寻求了实际的改进。 Scrum准则对此主题有何看法,或者他们对此有何表述? 编辑:用故事点代替时间。我指的是规划扑克和故事点的初始估算阶段,而不是任务详细计划。我只是把日期/时间放在这里,因为有时是典型的对话,有时是用时间而不是时间。抱歉给您带来任何混乱!故事点示例比时间示例代表更长的时间段。 编辑2当前没有专门的Scrum主持人,而PO在评估会议时扮演着这个角色。因此,可能是角色冲突使这种不适当的讨价还价变得更糟,因为他是作为权威而不是中立或开发者的混乱大师出现的。也许,只要没有候选人,就可以将他作为有偏见的参与者而不是“大师”来解决。

5
Scrum:用户故事的设计/ UX是否可以在与实现相同的冲刺中发生?
我目前处于冲刺阶段(两个星期),设计师负责定义特定用户故事的需求和用户体验。 在同一个Sprint中,我要实现此设计。在sprint计划期间,我不得不对这个不确定的用户故事需要花费多长时间进行大胆猜测。 今天,我终于收到了设计。不幸的是,设计是不完整/模糊的,比设计更类似于客户的要求。但是,从这一点上,我仍然可以看出,我的估计还不够。 更糟的是,这不是第一次。在最后的冲刺中,发生了完全相同的事情。我在回顾中标记了它,Scrum主管没有解决该问题的答案,而是说“这只是您的发展”。具有讽刺意味的是,如果烧毁没有达到目标,他会感到恼火。 现在,我将不得不咨询/与设计师合作才能完成工作。当我完成所有其他任务时,这将使我受挫。 所以我的问题是 A)您如何处理Sprint计划中的依存关系?编辑:可以在与实现相同的冲刺中进行用户故事的设计/ UX吗 B)我现在应该如何处理冲刺?重新估计当前的用户情况,并观察燃尽状态变成燃尽状态并被视为不称职/无效?或按照“帮助设计人员创建合适的设计”的方式向当前的sprint添加新任务
9 agile  scrum  planning 

5
Scrum每日会议:守时超过团队的全部成员?
我的理解是,每日Scrum会议应该非常迅速,以友好的方式召开,并且需要所有团队成员在场。因为这样做的目的是使每个人都了解其他人在做什么。 我喜欢这样举行的Scrum每日会议。 在我最新的项目中,我们的每日Scrums更像是状态更新会议。尽管我们的立场是持有Scrums并练习适当的敏捷。 我们是一个分散的团队,在2个不同的国家中,并且同一国家/地区的人不在同一办公室。结果,我们有了虚拟Scrum。 问题在于我们的会议总是按时开始,很多人在实际开始时间之前打电话,所以他们实际上是在会议的第一秒开始。对小延迟没有任何容忍度。 例如,上次我们打通电话时,协调会议的人员检查了每个人的出席情况,而我们说团队中的一位成员尚未出席,但他正在打电话。有人告诉我不用等待我的团队成员就可以开始共享。 另外,每个人都有很多会议,有时他们在Scrum会议中背靠背,因此,如果他们在会议的第一或第二分钟到达,这是可以理解的。 这对于练习每日Scrum的团队来说是正常的吗?这是我第一次发生。 我找不到直接的参考书目。尽管强调了所有团队成员的出席,但也强调会议应始终同时开始。但是我想可能会有小的延迟容限。 我什至在博客上读到有人建议,如果有人迟到“ 5秒”,Scrum Master可以判罚。我以为Scrums应该很友善,而那样的罚款似乎适得其反。 在这种情况下,推荐的方法是什么?
9 agile  scrum 

4
在不希望所有者参与的小型项目上使用Scrum
最近,我一直在阅读和学习有关Scrum的很多知识,我非常喜欢它。但是,我确实有一些我不知道解决方案的可能情况。假设我想组织一个由(例如)四个Web开发人员(其中一个是UI / UX设计人员)组成的敏捷团队。该团队将按照Scrum原则运作。 最初,我们可能会开展一些项目,例如为普通百姓的小型企业提供登陆页面,例如出租公寓,出售Cookie……这类客户根本无法设置为“产品所有者”角色(IMHO),因为他们通常希望雇用一家公司,向他们提供总体项目目标的详细信息,然后期望工作尽可能少地完成(包括大量决策)(在他们看来,他们有更多重要的事情要做)。假设我想让自己参与开发人员/ Scrum主管的角色(我知道即使是一次小组成员和Scrum主管也值得商)),所以我根本不应该担任产品所有者的角色好。 关于我的问题:如果我是公司的企业主,我是否也需要简单地成为产品所有者(这些角色是否彼此包含)?我可以雇用可能担任产品负责人的销售人员吗?如果它是经验丰富的开发人员而不是销售人员,会更好吗?这甚至是明智之举吗?最后,还有另一种更适合我职位的敏捷方法吗? 编辑:谢谢大家的良好投入。我添加了一些评论,任何附加信息将不胜感激。
9 agile  scrum 

5
在项目开始时分解一个复杂的故事
我正在尝试与敏捷项目管理(使用Pivotal Tracker)打交道,但是在尝试定义项目的前几个故事时,总是发现自己陷入困境。以这个非常简单的故事为例: “用户应该能够标记产品” 假设我已经在其他地方定义了“产品”,那么这个故事可能涉及在幕后编写一个多态标记系统,该系统ID完成后就可以最终添加标记产品的功能。 我的问题是这个故事中隐藏的工作量很大。我可以定义任务来完成故事,但整个故事应该工作1-2天?我只为揭示冰山一角而感到不对,但那是与用户有关的唯一部分。 您如何克服这种事情?最佳做法是什么? 更新25/08感谢所有人的指导,我已采纳了有关如何定义故事的所有建议。我现在切换到Jira Grasshopper,它对故事中的任务(分配,估计等)和冲刺开始后的开发任务有更好的支持。
9 scrum 

4
狗食时何时开始使用该工具的下一个修订版?
具体来说,我正在开发一个将DVCS和构建系统集成在一起的工具,但是我想像一下,如果开发任何“元”工具(编译器,VCS,构建系统,测试运行器等)的人都将面临挑战。希望通过“狗食”发展。 我的问题是:在使用分支工作流的Scrum风格发布过程中,从什么时候开始在工具的开发周期中使用该工具的较新版本? 我正在寻找一种在以下两者之间建立平衡的过程: 不断使用该develop工具的版本:随着变更的合并,我正在打破自己的开发。 不断使用该master工具的版本:我通过狗食发现的所有问题都是已经发布的问题。

5
多个Scrum团队转移到单个待办事项列表
目前,我们有5个Scrum团队在过去一年中处理自己的产品积压。每个团队都在各自的专用系统上工作,但基础技术是相同的.Net。 关于转移到基于功能的团队进行单个积压工作的讨论很多。原因是我们的主要系统之一有大量工作要做,而它们的能力不足以完成一年中的所有工作。我认为重要的另一个原因是,它可以提供更大的灵活性来快速调整投资组合的变化。 已决定更改两个团队以处理一个积压订单,但开发人员在其他系统上没有经验。我们正在做的一件事是通过将经验系统开发人员移交给团队来进行交叉技能培训。 我的问题是,您是否经历过将两个或多个不同系统转移到单个积压工作。您面临什么挑战?您需要做什么才能使其正常工作?
9 agile  scrum 

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.