敏捷开发sprint_敏捷开发sprint总结 - CSDN
  • 什么是Sprint规划? Sprint规划是scrum中用来启动Sprint的事件。迭代规划的目标是定义Sprint可以交付的内容,以及如何完成各项工作。迭代规划需要整个scrum团队合作完成。 与体育概念中的最后冲刺不同,scrum中的...

    什么是Sprint规划?

    Sprint规划是scrum中用来启动Sprint的事件。迭代规划的目标是定义Sprint可以交付的内容,以及如何完成各项工作。迭代规划需要整个scrum团队合作完成。

    与体育概念中的最后冲刺不同,scrum中的‘冲刺’(sprint)要求团队一直保持极速状态以提供可工作的软件,与此同时还需要不断学习和提高。

    在scrum中,Sprint是所有工作都得以完成的一段时间。只是在开始行动前,需要设置Sprint的相关条件:例如要决定时间周期的长度、Sprint目标以及从何处开始行动。Sprint规划会围绕Sprint中的应办事项和工作重点展开。如果组织得当,Sprint规划会还能够为团队营造一个充满激情和挑战并指引团队走向成功的环境。糟糕的Sprint规划可能会因为设定不切实际的目标,而导致团队的失败。

    做什么——Product Owner阐述Sprint目标以及对实现目标有益的PBI。Scrum团队据此决定在即将开始的Sprint中需要做什么,以及要做哪些才能实现Sprint目标。

    怎样做——开发团队根据需要交付的Sprint目标来规划具体工作。经开发团队和Product Owner协商一致后,最终得到一个基于价值和工作量的Sprint计划。

    谁来做——Sprint规划必须要有Product Owner和开发团队的参与。Product Owner根据产品的价值取向来制定Sprint目标。而开发团队则需要弄清楚能否实现该目标。二者都必须参与,缺一不可,任何一方的缺席都将导致Sprint计划无法进行。

    输入——Product Backlog是Sprint计划中非常重要的一个出发点,因为它提供了可能会成为当前Sprint一部分的“基本特征”表。除此之外,团队还需要查看增量中已完成的工作,以了解进度和剩余工作量。

    输出——Sprint规划会议最重要的目的是让团队阐述Sprint目标,以及如何实现这个目标。这些内容将体现在Sprint的Backlog中。

    Sprint规划会的前期准备

    要举办一场精彩的Sprint规划会需要满足一些基本要求。Product Owner要做好充足的准备,结合前一次的Sprint Review会议中总结的经验教训、利益相关者的反馈以及他们对产品的愿景,奠定Sprint的基础背景。透明度方面,Product Backlog应是更新后的版本,确保清晰精准。Backlog Refinement是scrum中一个可选事件,因为有些backlog不需要进行梳理优化的。但对大多数团队而言,最好在sprint规划会前将团队聚在一起对backlog进行review并做出优化。

    专家提示:

    周期为2周的Sprint,要在中期举行一次backlog梳理会议。跳出当前的Sprint来思考下一个对团队来说大有裨益。这样不仅能够为Sprint规划做准备,还可以为评估当前的工作提供不同的视角。

    限制Sprint规划的时间

    Sprint规划的时长应限制在每周两小时以内。所以,一个为期两周的Sprint,其规划会议将不会超过两个小时。这叫做“timeboxing”,即设定团队完成一项任务所需的最长时间,在这个前提下,进行Sprint规划。Scrum Master负责确保会议在规定时间内完成。如果团队在限定时间内达到了满意的效果,就可以认为会议顺利完成。时间限制仅强调最长时间,对最短时间没有限制。

    专家提示:

    将Sprint目标作为Sprint规划的重点,不要将过多的精力放在Backlog的细节上。 聚焦目标而非具体的工作,才能让团队有更多的精力找到实现目标的最佳方案。

    聚焦结果而非具体工作

    在做Sprint规划时,团队很容易陷入“细节困境”,纠结于哪个任务应该先做,由谁做,以及完成这项任务需要多少时间等。对于比较复杂的工作,初期掌握的信息有限,且大部分判断都是基于假设。Scrum是一个完全根据经验的过程,这就意味着很多工作没办法提前规划,而是要通过实践来学习,然后将学习到的信息反馈到整个开发流程中。

    Sprint目标以一个比较高的水平对Sprint的目标进行阐述,而backlog列表也可以用结果导向的思维来编写。用户故事是一种从用户角度描述工作的非常好的方式。如下图所示,用户故事应该将焦点放在客户最终想要实现的效果的缺陷、问题和改进上,而非观察到的问题。

    通过在用户故事中添加清晰、可测量的结果,团队可以清楚地衡量输出结果,知道什么时候才算完成。尽可能提前了解团队聚焦的工作,这样团队中每个人在启动工作时就不至于一无所知。例如,团队可以将无法确定的事情定为需要在Sprint期间回答的问题,也好过让其保持不清不楚的状态。

    专家提示:

    无法确定某事和让其保持不清不楚的状态是两回事。不要忽视未知事件,因为它们就是团队必须脚踏实地完成的艰苦工作。但也不要使用含糊不清的描述来掩盖或隐藏它们。相反,当你不了解某些事情时,要认清自己的无知,并将其列为需要进一步了解的工作。

    预估是必要的,但不代表要假装了解未知事项

    Sprint规划需要一定程度的预估。团队需要明确Sprint中能或者不能完成的任务,即:预估工作量和实际工作量。工作量的预估经常与承诺相混淆。预估本质上是团队根据当前掌握的知识做出的预测。衡量工作量大小的方法如故事点(story points)和T恤尺码分类法(t-shirt sizing)分别为团队提供了不同的视角来分析和看待问题。而它们并非神器,不能帮助团队在尚未掌握足够信息的前提下发现真相。因此,未知因素越多,预估的正确性就越低。

    良好的预估要基于相互信任的环境,在这种环境下,团队可以自由交换信息,在不断的学习和改进中对假设进行论证。如果工作完成后证明前期的预估是错误的,那么以后的预估要么变得大很多,以确保不再出错;要么花更长的时间来进行预估,以避免再次出错。

    专家提示

    团队可以尝试用不同的预估方法,如T恤尺码分类法(t-shirt sizing)或故事点(story points)。因为不同的方法分析问题的角度不同。

    Sprint规划最佳实践

    Sprint规划期间,团队很容易陷入“细节困境”,导致他们忘了Sprint规划的重点是为接下来的Sprint制定一个“恰到好处”的计划。规划不应成为团队的负担,而应该帮团队专注于有价值的结果,并确保团队保持正常的运行轨迹。好的Sprint规划通过定义输出的结果和清晰的计划来获得成功。但也要小心过犹不及,Sprint规划中,要聚焦目标和恰到好处的Sprint Backlog,而不是面面俱到的规定Sprint中每一分钟的工作计划。接下来,就是确定Product Backlog的顺序,以便团队提前完成Sprint目标时能接着进入后续的工作中。

    Scrum是一个旨在解决复杂问题的流程框架,而复杂问题的解决需要一个经验积累的过程(即边做边学)。经验积累的过程很难预先计划,所以不要自欺欺人——要承认我们不可能制定完美的计划。相反,可以专注于结果并投入到实际的工作中去,哪怕我们正在尝试解决非常困难的问题,启动工作仍可以是一件易事。

    展开全文
  • 什么是Sprint规划? Sprint规划是scrum中用来启动Sprint的事件。迭代规划的目标是定义Sprint可以交付的内容,以及如何完成各项工作。迭代规划需要整个scrum团队合作完成。 与体育概念中的最后冲刺不同,scrum中的...

    什么是Sprint规划?

    Sprint规划是scrum中用来启动Sprint的事件。迭代规划的目标是定义Sprint可以交付的内容,以及如何完成各项工作。迭代规划需要整个scrum团队合作完成。


    与体育概念中的最后冲刺不同,scrum中的‘冲刺’(sprint)要求团队一直保持极速状态以提供可工作的软件,与此同时还需要不断学习和提高。


    在scrum中,Sprint是所有工作都得以完成的一段时间。只是在开始行动前,需要设置Sprint的相关条件:例如要决定时间周期的长度、Sprint目标以及从何处开始行动。Sprint规划会围绕Sprint中的应办事项和工作重点展开。如果组织得当,Sprint规划会还能够为团队营造一个充满激情和挑战并指引团队走向成功的环境。糟糕的Sprint规划可能会因为设定不切实际的目标,而导致团队的失败。

    • 做什么——Product Owner阐述Sprint目标以及对实现目标有益的PBI。Scrum团队据此决定在即将开始的Sprint中需要做什么,以及要做哪些才能实现Sprint目标。
    • 怎样做——开发团队根据需要交付的Sprint目标来规划具体工作。经开发团队和Product Owner协商一致后,最终得到一个基于价值和工作量的Sprint计划。
    • 谁来做——Sprint规划必须要有Product Owner和开发团队的参与。Product Owner根据产品的价值取向来制定Sprint目标。而开发团队则需要弄清楚能否实现该目标。二者都必须参与,缺一不可,任何一方的缺席都将导致Sprint计划无法进行。
    • 输入——Product Backlog是Sprint计划中非常重要的一个出发点,因为它提供了可能会成为当前Sprint一部分的“基本特征”表。除此之外,团队还需要查看增量中已完成的工作,以了解进度和剩余工作量。
    • 输出——Sprint规划会议最重要的目的是让团队阐述Sprint目标,以及如何实现这个目标。这些内容将体现在Sprint的Backlog中。

    Sprint规划会的前期准备

    要举办一场精彩的Sprint规划会需要满足一些基本要求。Product Owner要做好充足的准备,结合前一次的Sprint Review会议中总结的经验教训、利益相关者的反馈以及他们对产品的愿景,奠定Sprint的基础背景。透明度方面,Product Backlog应是更新后的版本,确保清晰精准。Backlog Refinement是scrum中一个可选事件,因为有些backlog不需要进行梳理优化的。但对大多数团队而言,最好在sprint规划会前将团队聚在一起对backlog进行review并做出优化。

    专家提示:
    周期为2周的Sprint,要在中期举行一次backlog梳理会议。跳出当前的Sprint来思考下一个对团队来说大有裨益。这样不仅能够为Sprint规划做准备,还可以为评估当前的工作提供不同的视角。

    限制Sprint规划的时间

    Sprint规划的时长应限制在每周两小时以内。所以,一个为期两周的Sprint,其规划会议将不会超过两个小时。这叫做“timeboxing”,即设定团队完成一项任务所需的最长时间,在这个前提下,进行Sprint规划。Scrum Master负责确保会议在规定时间内完成。如果团队在限定时间内达到了满意的效果,就可以认为会议顺利完成。时间限制仅强调最长时间,对最短时间没有限制。

    专家提示:
    将Sprint目标作为Sprint规划的重点,不要将过多的精力放在Backlog的细节上。 聚焦目标而非具体的工作,才能让团队有更多的精力找到实现目标的最佳方案。

    聚焦结果而非具体工作

    在做Sprint规划时,团队很容易陷入“细节困境”,纠结于哪个任务应该先做,由谁做,以及完成这项任务需要多少时间等。对于比较复杂的工作,初期掌握的信息有限,且大部分判断都是基于假设。Scrum是一个完全根据经验的过程,这就意味着很多工作没办法提前规划,而是要通过实践来学习,然后将学习到的信息反馈到整个开发流程中。
    Sprint目标以一个比较高的水平对Sprint的目标进行阐述,而backlog列表也可以用结果导向的思维来编写。用户故事是一种从用户角度描述工作的非常好的方式。如下图所示,用户故事应该将焦点放在客户最终想要实现的效果的缺陷、问题和改进上,而非观察到的问题。

    image.png


    通过在用户故事中添加清晰、可测量的结果,团队可以清楚地衡量输出结果,知道什么时候才算完成。尽可能提前了解团队聚焦的工作,这样团队中每个人在启动工作时就不至于一无所知。例如,团队可以将无法确定的事情定为需要在Sprint期间回答的问题,也好过让其保持不清不楚的状态。

     

    专家提示:
    无法确定某事和让其保持不清不楚的状态是两回事。不要忽视未知事件,因为它们就是团队必须脚踏实地完成的艰苦工作。但也不要使用含糊不清的描述来掩盖或隐藏它们。相反,当你不了解某些事情时,要认清自己的无知,并将其列为需要进一步了解的工作。

    预估是必要的,但不代表要假装了解未知事项

    Sprint规划需要一定程度的预估。团队需要明确Sprint中能或者不能完成的任务,即:预估工作量和实际工作量。工作量的预估经常与承诺相混淆。预估本质上是团队根据当前掌握的知识做出的预测。衡量工作量大小的方法如故事点(story points)和T恤尺码分类法(t-shirt sizing)分别为团队提供了不同的视角来分析和看待问题。而它们并非神器,不能帮助团队在尚未掌握足够信息的前提下发现真相。因此,未知因素越多,预估的正确性就越低。
    良好的预估要基于相互信任的环境,在这种环境下,团队可以自由交换信息,在不断的学习和改进中对假设进行论证。如果工作完成后证明前期的预估是错误的,那么以后的预估要么变得大很多,以确保不再出错;要么花更长的时间来进行预估,以避免再次出错。

    专家提示
    团队可以尝试用不同的预估方法,如T恤尺码分类法(t-shirt sizing)或故事点(story points)。因为不同的方法分析问题的角度不同。

    Sprint规划最佳实践

    Sprint规划期间,团队很容易陷入“细节困境”,导致他们忘了Sprint规划的重点是为接下来的Sprint制定一个“恰到好处”的计划。规划不应成为团队的负担,而应该帮团队专注于有价值的结果,并确保团队保持正常的运行轨迹。好的Sprint规划通过定义输出的结果和清晰的计划来获得成功。但也要小心过犹不及,Sprint规划中,要聚焦目标和恰到好处的Sprint Backlog,而不是面面俱到的规定Sprint中每一分钟的工作计划。接下来,就是确定Product Backlog的顺序,以便团队提前完成Sprint目标时能接着进入后续的工作中。
    Scrum是一个旨在解决复杂问题的流程框架,而复杂问题的解决需要一个经验积累的过程(即边做边学)。经验积累的过程很难预先计划,所以不要自欺欺人——要承认我们不可能制定完美的计划。相反,可以专注于结果并投入到实际的工作中去,哪怕我们正在尝试解决非常困难的问题,启动工作仍可以是一件易事。

     

    文章来源:Worktile敏捷博客

    欢迎访问交流更多关于技术及协作的问题。

    文章转载请注明出处。

    转载于:https://www.cnblogs.com/worktile/p/11090690.html

    展开全文
  • sprint敏捷开发

    2017-09-01 09:18:34
    2. 沟通的效率高了,尤其是开发和测试,因为很多问题开发和测试可以先沟通,这样很多问题也就可以提前解决了。 3. 测试要更早的介入开发中,可以尝试用测试驱动的方法,这一点尤其对自动化来

    1。开会的效率,作为组织会议的人要考虑一个问题,你的会议要花费5分钟,有5个人参加,那就是25分钟了,所以会议要尽可能的短,尽可能的解决多一点问题,不是公共的问题尽量安排在会后解决,以节省其它人的时间。

    2. 沟通的效率高了,尤其是开发和测试,因为很多问题开发和测试可以先沟通,这样很多问题也就可以提前解决了。

    3. 测试要更早的介入开发中,可以尝试用测试驱动的方法,这一点尤其对自动化来说更重要,但要知道,并不是每个开发任务都能这么做,这个主要是测试要多和开发的人进行沟通。

    4. knowledge的sharing很重要,所以可以考虑把这个作为考核的一部分来做,以让大家养成这个习惯,每个sprint结束后应该至少有一些sharing,前期需要scrum mater的push,后期应该是大家都养成良好的习惯了。

    5. 开发和测试是一个team,开发如果有时间就要考虑帮忙做一些测试的东西,而测试这边就要考虑如何让开发来帮忙更有效率。是否需要提供test case还是ad hoctest,前期测试可以发出这样的request来让他们帮忙,后期主要靠自觉

    6. 交叉熟悉对于开发和测试同样重要

    7. 对于新东西,可以考虑尝试pair learning的方法

    8.应该有自己的群,这样别人有问题可以在上面问,其他知道的人也可以在上面问问题.


    转载于:

    http://blog.csdn.net/cattle26/article/details/8127337

    展开全文
  • 这个是我们的迭代看板,分享一起学习: https://www.leangoo.com/kanban/board/go/2825051# 欢迎分享你的看板

    这个是我们的迭代看板,分享一起学习:

    https://www.leangoo.com/kanban/board/go/2825051#

    欢迎分享你的看板

    展开全文
  • 敏捷开发Sprint流程

    千次阅读 2014-10-22 14:05:03
    SprintSprint是敏捷开发中的一个开发周期,时间应在一个月以内,最终应有完成的、可发布的产品。Sprint包含计划会议、每日例会、开发工作、评审会议、回顾会议。在一个Sprint中,开发团队成员、Sprint目标不应该改变...
  • 敏捷开发中的sprint是什么意思_百度知道 敏捷开发中的sprint是什么意思_百度知道 敏捷开发中的sprint是什么意思 未成年RB21 | 浏览 4208 次 推荐于2016-02-27 15:19:02 最佳答案 敏捷开发模式...
  • 敏捷开发之Scrum扫盲篇

    千次阅读 2016-06-14 07:34:52
    敏捷开发之Scrum扫盲篇 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...   为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述...
  • 八分钟敏捷开发(scrum)扫盲

    千次阅读 2018-08-20 16:54:42
    敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。 Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。 敏捷开发的特点就是...
  • 接触Scrum时间不长,开发中遇到的问题比预想的要多很多。 Scrum上面说了,每一个Sprint的时间设置在2——6周是比较合理的。我认为一般的项目一个Sprint4周比较合理。由于我们的pj项目不是很大,真正开发起来一月个差...
  • 项目管理之敏捷开发总结

    千次阅读 2018-04-13 01:15:16
    瀑布模型:简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速...
  • 如何编写敏捷开发中的user story 分类: 程序的性格2009-11-03 14:34 2704人阅读 评论(0) 收藏 举报 user敏捷开发测试junit任务框架   对于敏捷开发来说,User Story是开发的基础,它不同于传统...
  • [转帖]敏捷开发,Use Case 还是 User Story2009-9-24敏捷开发,Use Case 还是 User StoryMurali Krishna告诉我们:未能彻底明白用户故事的性质往往都是未能有效地转变到敏捷开发的重大问题。用户故事最重要的特点在...
  • 敏捷Sprint-0计划的实践方式

    千次阅读 2018-10-21 23:36:35
    前言 本文将探讨一个所有软件开发者都头疼的问题,那就是...接下来就结合经典的敏捷开发方法论以及我们团队的实践来看看在敏捷开发里项目计划和估算的实践方式是否能够给你带来一点启示。 内容 敏捷计划的特点 首...
  • sprint应该多长才好? 嗯,时间短就好。公司会因此而变得“敏捷”,有利于随机应变。短的sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错误方向上花的时间更少=学习和改进的速度更快,众多好处接踵而来。 ...
  • 创业公司如何实施敏捷开发

    千次阅读 2014-01-22 16:03:40
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷开发Scrum——Sprint Retrospective

    千次阅读 2010-02-26 10:24:00
    敏捷开发Scrum——Sprint RetrospectiveMoakap总结在Scrum中,每个Sprint结束的时候会有两个会议(Sprint Review/Demo和Sprint Retrospective回顾)。这两个会议是对过去的一个Sprint的一个总结,其中Review/Demo是...
  • 白话SCRUM 之三:sprint backlog

    万次阅读 2013-08-23 14:59:47
    Sprint Backlog就是任务列表,如果映射到传统的项目管理理论中就是WBS(work breakdown structure),而且是典型的采用面向交付物的任务分解方法得到的WBS。比如有一个Product backlog 条目为: 作为系统的合法用户...
  • 敏捷开发和迭代开发

    千次阅读 2018-07-10 17:20:56
    敏捷开发与迭代式开发是整体与局部的关系   敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过...
  • 什么是敏捷开发

    万次阅读 多人点赞 2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
1 2 3 4 5 ... 20
收藏数 7,582
精华内容 3,032
关键字:

敏捷开发sprint