Questions tagged «agile»

敏捷软件开发是基于迭代和增量开发的一组软件开发方法,其中需求和解决方案通过自组织,跨职能团队之间的协作来发展。

7
谁在S​​crum项目上使用UX?
好。假设您正在从事教科书Scrum项目。您有一个Scrum主管与产品负责人合作。接下来的冲刺是UI重-你的程序员开始构建屏幕的时候,你真的想有一些想法,他们打算什么样子。 谁来做线框图,何时做?产品负责人?有人支持产品负责人吗?Scrum高手?如果您有UX专家,他们是在冲刺开始后与编码人员一起工作,还是他们在故事卡和约束条件旁边预先提供了线框和模型,以指导和告知开发人员正在进行的工作? 我很确定我们需要一些UX帮助,但是我真的不确定在哪里应用它。 编辑:让我改一下这个问题。 您如何在敏捷项目中提供一致的高质量用户体验?

2
估计Scrum故事点的最佳方法是什么?
我喜欢计划扑克在任何项目开始时的工作方式,让您相互比较和讨论每个故事的细节。 我注意到的一个问题是,随着时间的流逝,随着您对问题领域的了解越来越多,您倾向于为每个故事投票更少的分数,即,一开始的故事价值为5或8该项目的价值现在可能值得3。 您如何以最佳方式避免或解决此问题?有更好的估算方法吗?故事应该始终保持不变,还是故事点减少?

3
如何向专注于瀑布的人们展示敏捷项目[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 我们的团队被要求在项目计划中代表我们的开发工作。没有人会对我们的工作感到不满意,也没有人质疑我们的交付能力,我们只是参加了IT牛呼唤项目计划。麻烦的是我们是一个敏捷的团队,还没有考虑正式的项目计划来考虑我们的工作。 虽然我们对下一步的工作有一个大致的了解,但在计划迭代之前,我们尚不确定100%。到目前为止,我们的团队基本上是在真空中运作的,不需要向外部各方介绍我们的方法或指标。我们遵循极限编程中所倡导的大多数实践。 我们每季度举行一次计划会议,以大致了解我们将要开展的季度的故事。就是说,我们的故事记录在3x5卡上,并且仅在将要使用它们的迭代开始时进行估算。经过估算,我们将故事记录在Team Foundation Sever中。在迭代过程中,我们将代码附加到故事并在完成后将故事标记为完成。根据这些数据,我们可以生成燃尽图和速度图。最重要的是,我们知道一次迭代的平均速度,可以防止我们咬下去而无法咀嚼。 我不想改变我们的开发方式,而是希望在报告中介绍我们的开发活动,只有熟悉瀑布的人才能理解。在肯特·麦当劳(Kent McDonald)的《敏捷项目计划的外观》中,他很好地阐明了敏捷项目计划和瀑布式项目计划之间的区别。他指定了消耗性子弹的区别: 敏捷项目计划基于功能 敏捷项目计划被组织为迭代 敏捷项目计划的详细程度取决于时间范围 团队拥有一个敏捷项目计划 能够解释差异很棒,但是如何最好地呈现数据呢?

3
在非常短的项目上混乱?
我正在使用Scrum并非常喜欢它。但是,我的商店发现自己处于开发工作持续时间为两到四个星期的项目中。我们已经将冲刺时间修改为两周,这里的每个人都说:“它将是Scrum,只有一个半冲刺。” 我认为我们无法从一个半冲刺中获得很多价值。我们如何仅通过一次,两次或一年半的迭代就能获得迭代开发过程的收益?

4
敏捷开发的办公室设计和布局
(从stackoverflow移开) 我在这里找到了很多关于哪种键盘,书桌,浅色或彩色背景最合适的讨论-但我找不到能解决整个办公室布局的问题。 我们是一家拥有约20名员工的公司,搬到一个更大的地方。这里有两种主要的开发实践,有规律地结合在一起,后端人员经常需要与移动人员合作来安排Web服务。后端人员大约是移动人员的两倍。大约有一半的后端开发人员可以随时在现场工作,而几乎从来没有一次在办公室中工作,因此至少需要提供5-10个空间-因此,在大多数情况下,这两组人差不多。 我们有机会安排桌子,隔断甚至可能是墙壁,以增加空间。餐饮或按摩之类的互联网装饰将不会有现金,但现在是时候计划避免最终排成一排的桌子了。 我曾经在软件的Bionic Office上撰写过Joel 的文章,它有一些不错的主意,但在我们应该合作的环境中,我*(更重要的是公司的所有者)并没有完全将隐私主意卖掉。这是另一个很好的链接- 终极软件开发办公室布局 -直到读完这篇文章,我什至不记得封闭的会议室。 私人办公室会阻碍敏捷发展吗?Scrum是否足够强迫接触,如果您需要打扰某人,您应该起床并敲门吗? 您可以指向哪些设计布局,为什么要推荐它们? *我完全不反对封闭式办公室,但如果其他解决方案也能做到这一点,我会很高兴。如果不能...好,那就是这个问题的全部内容。 两次更新-2013年4月。 第一步是到一个“简陋”的办公室。基本上是开放的,但具有怪异的特征,例如一面墙铺着地毯,一半铺着地板,一半铺着抛光混凝土。每个坐在混凝土上的人都想坐在地毯上。看起来还不错,但实际上我不建议只给办公室里的一半铺地毯,那些感到寒冷的人真的很讨厌它。对于单口来说很好-巨大的白板占据了一堵墙,有足够的空间进行交谈和分组讨论。 然后,我搬到了一个非常拥挤的地方,与另一家公司(同一所有者)混合在一起,该公司的功能主要是协作,设计,通话,维护和安装物理设备。糟透了。然后我们搬到新的场所,有人认为仓库/工业区很酷。到处都有坚硬的表面,玻璃和抛光的混凝土。开发人员在交通最繁忙的区域中间共享一张大桌子,就在小厨房和洗碗机旁边,甚至在壁in里也没有。整天花在电话上的人旁边。尽管像吸音板这样的创可贴,它还是会继续吮吸。它之所以吸引人,是因为没有足够的空间来放置板子或站立,并且该地方的声学特性使人很难听到拍子上方的任何人-以及那种感觉,在安静的时刻,在大教堂里大喊大叫。没有人听过这些抱怨。我辞职了,其他人也辞职了。哦,坚持要成为“产品负责人”的人从来没有出现过,这无济于事。

5
您的敏捷/ Scrum团队的错误工作流程是什么?
您的敏捷/ Scrum团队的错误工作流程是什么? 这是我们的:-如果该错误与当前sprint中的一个故事有关,我们将对其进行修复。-如果错误与当前sprint中的故事无关,并且不重要,则将其发送给产品所有者以进行优先级排序。-如果该错误与sprint中的故事无关,并且非常重要,则我们将其修复。
9 agile  bug  scrum  workflows 


7
在Scrum中,如何在冲刺结束时处理争用/工作量
我的团队几年前开始使用Scrum。我们的项目涉及构建与物理设备(例如机器人和传感器)接口的软件,而我们典型的产品积压订单通常表示向整个系统添加控制设备。 我们将任务分解为接近此处的示例。每个设备集成功能都分为代码,测试,集成测试,同行评审等。显然,每个产品待办事项都有固有的顺序。通常,我们的冲刺持续2周,团队中有4至6名成员。 在冲刺结束时遇到了两个问题: 首先是在冲刺结束时让每个人都忙。 第二个(相关的)是系统争用。在冲刺的最后几天,我们几乎完成了集成。我们只有一个集成系统,因此人们通常无法继续工作,因为他们无法访问该系统。由于这是sprint的结尾,因此sprint积压工作中没有太多工作要做。这些人应该做什么工作?由于当前项目尚未完成,因此产品所有者无法很好地从产品待办事项列表的顶部提取项目。处理技术债务将对整个项目有所帮助,但不会帮助完成冲刺。 是否有任何最佳实践可用于构建sprint以避免这些问题?与产品负责人进行谈判的技巧?
8 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.