• 敏捷开发流程模型图当中可以看出,在敏捷实施过程当中,有四种会议,分别是计划会,每日站会,回顾会,评审会,其中数计划会最为重要。应该来说会议是有点多的,不是流传一种说法嘛,不开会的团队的一定不是一个好...

    从敏捷开发流程模型图当中可以看出,在敏捷实施过程当中,有四种会议,分别是计划会,每日站会,回顾会,评审会,其中数计划会最为重要。应该来说会议是有点多的,不是流传一种说法嘛,不开会的团队的一定不是一个好团队,好的团队一定经常开会。经常开会是需要时间的,因此有利有弊,如果会议时间和节奏控制的不好,就会占用掉团队很多的精力和工作时间,那就得不偿失了。在敏捷开发模式中,每种会议都有其特殊的职责和使命,不同的会议上所讨论的内容是不一致的,只要把握住会议的关键点,就可以为团队的敏捷模式服务。

    关于开会,日常工作当中各种会议、培训、沟通等都会占用掉大量的工作时间,因此会议贵精不贵多,在最短的时间内达成最有效的决议,这才是一个有成果的好会议。产品团队必然也会面临这样的问题,在敏捷团队内部,除了必要的全员培训外,尽量保持在团队内部只有敏捷的这四个会议,其余的沟通和会议都可以由PO和SM去参加,然后回来传达给团队成员即可,这样可以减少团队整体的时间消耗,保证团队的工作效率。

    Scrum-workflow

    Sprint Planning敏捷迭代计划会议

    在每个敏捷迭代开始之初,由产品负责人讲解需求,并由开发团队进行估算工时的计划会议。 在会议上需要:排列需求优先级;分析和评估产品Backlog并确定该迭代的目标;计划会议上还需要制定迭代计划,包括: 根据产品Backlog(功能点)创建Sprint Backlog(即迭代任务);然后为Sprint backlog中的任务做估算;团队成员从产品Backlog中挑选他们承诺完成的条目。

    敏捷的迭代实现始于计划会议,所以一个好的计划会议是每个迭代成功的基础,一般分两个阶段进行,两个阶段参与会议的人员会不一样;

    计划会议的目标:

    1、基于敏捷规划产生的Product Backlog以及优先级,通过计划会议,确定迭代的目标、团队成员、形成Sprint Backlog,明确评审会、回顾会时间;

    2、分解Sprint Backlog并确定相应的完成时间,并由团队成员共同挑选这些Sprint Backlog;

    阶段一参与人员:产品经理、Product Owner、Scrum Master、团队成员,有业务人员的话还可以邀请业务人员一起参加。

    会议时长:1-4小时

    一般参考进程安排如下:

    1、Scrum Master公开迭代时间表;

    2、产品经理和Product Owner讲述Product Backlog,对应的业务价值和优先级;

    3、团队针对Sprint Backlog和优先级达成一致;

    4、Scrum Master和团队成员共同确定Sprint Backlog;

    阶段二参与人员:Scrum Master、团队成员,其他人员选择性参加

    会议时长:1-4小时

    一般参考进程安排如下:

    1、团队成员针对Sprint Backlog共同分解任务;

    2、团队成员共同进行工作量评估(每个Task不超过2天),确定开始时间和完成时间;

    3、团队成员共同认领任务;

    4、共同确定DoD,团队达成一致;

    5、团队共同确认迭代目标和价值;

    如果单个迭代内安排的Product Backlog安排的比较多的话,一般迭代计划会议需要开一个整天,虽然时间有点长,但这个会议会确认整个迭代的详细计划和安排,因此也是值得的。

    Daily Stand-up Meeting每日站会

    团队每天进行沟通的内部短会,因一般只有15分钟且站立进行而得名,团队成员通常会在会议上讲述如下3点内容:

    1) 昨天我做了什么

    2) 今天我计划要做什么

    3) 我遇到了什么问题,妨碍了我尽可能有效地工作

    Scrum Master记录会议上提出的问题,但是不要在会议上讨论和解决问题,而是要会后在找相关人员进行讨论和解决。

    Sprint Review敏捷迭代评审会议

    在迭代结束前给产品负责人演示并接受评价的会议,并根据反馈结果,提出新的产品Backlog

    参与人员:产品经理、Product Owner、Scrum Master、团队所有成员

    会议时长:1-4小时,视演示内容而定

    主要是检验迭代成果,检查是否完成迭代计划中的迭代目标,有可能的话要求用户参与测试流程,并得到用户对产品的认可,鼓励用户自己进行测试设计和进行破坏性测试,充分暴露产品的设计和功能问题。

    由Scrum Master来推进会议进程,Product Owner记录用户反馈,根据结果维护产品 backlog,一般在迭代结束前做一次。

    Sprint Retrospective敏捷迭代回顾会议

    在每个迭代结束后召开的关于自我持续改进的会议,围绕如下三个问题进行讨论:

    1) 本次迭代有哪些做得好;

    2) 本次迭代我们在哪些方面还能做得更好;

    3) 我们在下次迭代准备在哪些方面改进;

    团队确定问题优先级,并根据优先级确定团队能够解决的Top问题;团队讨论Top问题的措施,并选择在下一个迭代可以完成措施,分配责任人进行跟踪。

    参与人员:Scrum Master,Product Owner,团队成员。

    会议时长:0.5-1.5小时

    主要针对当前迭代,团队成员自由讲述可以需要保持的做法,改进的点以及持续跟踪计划。

    Scrum Master将团队讨论以及行动计划形成会议纪要,并发送给整个团队和有关同事。需要按照回顾会议的结论,维护一份待办事项列表,在下次回顾会议上进行跟踪。

    案例分析

    案例一:某Team在每日站会中,Scrum master准时组织大家开始晨会,成员一个接着一个说,昨天做了什么事情,今天计划做什么事情,遇到什么问题,成员A说昨天遇到了一个问题未能解决,Scrum master问遇到的是什么问题,成员A详细说明了该问题,这时成员B说这个问题他也遇到过,他是通过XX方式解决的,讨论后成员A明白了,然后继续晨会,由于小组成员有10个人,整个会议开下来大概花费了30分钟。

    问题分析:Scrum master不应该在每日站会上询问详细的问题细节,而应该转移到会下询问,当团队成员之间进行讨论的时候,Scrum master需要及时拉回来,讨论应该转移到会下进行,晨会要在固定的时间固定的地方并且在固定的时间内完成。会议时间需要控制在15分钟之内。

    案例二:某Team在开回顾会议中,Scrum master详细总结了本次迭代中有哪些做不够好的,并指出了对应的事和人,接着对应的责任人开始述说哪些地方确实是做的不够好及其原因,最后给出改进措施然后结束会议。

    问题分析:回顾会不是批斗会,不应该只说做的不好的,做的好的也要说,Scrum master主要是鼓舞大家的士气,应该先从做的好的方面开始说起;并且做的不好的方面都只对事,不对人,做的不好是整个Team的责任,不仅仅是某几个人的责任;最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。

    在敏捷的迭代执行过程中,上述四种会议会随着每个迭代一直进行,基本上形成了一个闭环,可以让团队在每个迭代的执行过程当中去学习和总结,从而正确的按照敏捷的要求去做,使团队真正的敏捷起来。

    展开全文
  • Scrum敏捷开发流程主要包扩三个角色、会议和个三物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能的完整...

    Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。

    三个角色

    Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。

    Scrum 团队是自组织、跨职能的完整团队。自组织团队决定如何最好地完成他们的工作,而不是由团队外的其他人来指挥他 们。

    跨职能的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。Scrum 团队模式的目的是最大限度地优化适应性、创造性和生产力。

    Scrum 团队通过迭代和增量交付产品功能的方法最大化反馈的机会。增量交付潜在可交付的产品增量保证了 每个迭代都有潜在可发布的版本。

    Scrum角色之:产品负责人

    产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组 织、Scrum 团队以及单个团队成员的不同而不同。

    产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:

    ● 清晰地表达产品代办事项列表条目

    ● 对产品代办事项列表中的条目进行排序,最好地实现目标和使命

    ● 确保开发团队所执行工作的价值

    ● 确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作

    ● 确保开发团队对产品代办事项列表中的条目达到一定程度的理解

    产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是 负责任者。

    产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品代办事项列表中 体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。

    为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负 责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发 团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。

    Scrum角色之:开发团队

    开发团队包含了专业人员,负责在每个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量。

    开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效力。开发团队有以下几个特点:

    他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能。

    开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。

    Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。

    开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队

    开发团队不包含如测试或业务分析等负责特定领域的子团队。

    Scrum角色之:Scrum Master

    Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。

    Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值。

    Scrum Master 服务于产品负责人

    Scrum Master 以各种方式服务于产品负责人,包括:

    ● 找到有效管理产品代办事项列表的技巧

    ● 清晰地和开发团队沟通愿景、目标和产品代表事项列表条目

    ● 教导开发团队创建清晰简明的产品代表事项列表条目

    ● 在经验主义环境中理解长期的产品规划

    ● 理解并实践敏捷

    ● 按需推动Scrum活动

    Scrum Master 服务于开发团队

    Scrum Master 以各种方式服务于开发团队,包括:

    ● 指导开发团队自组织和跨职能

    ● 教导并领导开发团队创造高价值的产品

    ● 移除开发团队进展过程中的障碍

    ● 按需推动Scrum活动

    ● 在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队

    Scrum Master 服务于组织

    Scrum Master 以各种方式服务于组织,包括:

    ● 领导并指导组织采用 Scrum

    ● 在组织范围内计划 Scrum 的实施

    ● 帮助员工及干系人理解并实施 Scrum 和经验性产品开发

    ● 发起能提升Scrum 团队生产力的变革

    ● 与其他 Scrum Master 一起工作,帮助组织更有效的应用Scrum

    四个会议

    四个会议指的是Sprint计划会议、每日例会、Sprint评审会议和Sprint回顾会议。

    Sprint计划会议(Sprint Planning)

    在Scrum中,Sprint计划会议有两部分:

    1. 决定需要完成哪些工作?

    2. 决定这些工作如何完成?

    第一部分:需要完成哪些工作?

    参会人员:团队、项目负责人(Scrum Master)、产品负责人(Product Owner)

    第一部分的会议,产品负责人向开发团队介绍排好序的产品待办事项,由整个Scrum团队共同理解这些工作。

    Sprint中需要完成的产品待办事项数目完全由开发团队决定。做多少工作只能由开发团队决定,产品负责人或任何其它人都不能给开发团队强加更多的工作量。

    第二部分:如何完成工作?

    参会人员:Team 、Scrum Master

    第二部分的会议,开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量。他们进行足够的设计和计划,从而有信心可以在Sprint中完成所有工作。

    决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。

    Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。

    Sprint待办事项列表是一个需要在当前Sprint完成的且梳理过的产品待办事项,并包括了一个团队完成这些工作的计划。

    每日站会(Daily Scrum)

    开发团队是自组织的,通过每日站会来确认他们仍然可以实现Sprint的目标。

    每一个开发团队成员需要提供以下三点信息:

    ● 从昨天的站立会到现在,我完成了什么;

    ● 从现在到明天的站立会,我计划完成什么;

    ● 有什么阻碍了我的进展。

    每日Scrum通常不超过15分钟。

    每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。

    每日Scrum既不是向管理层汇报,也不是向产品负责人或者ScrumMaster汇报。它是一个开发团队内部的沟通会议,来保证他们对现状有一致的了解。

    只有Scrum团队的成员,包括ScrumMaster和产品负责人,可以在会议中发言。其他感兴趣的人可以来旁听。

    Sprint评审会议(Sprint Review)

    Sprint结束时,Scrum团队和相关人员一起评审Sprint的产出。所有Scrum会议都是限定时长的,Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时(比如,一个Sprint包含2个星期,则Sprint评审会议时长为2个小时)。

    每个人都可以在Sprint评审会议上发表意见。产品负责人会对未来做出最终的决定,并适当地调整产品待办事项列表(Product Backlog)。

    Sprint评审会议向每个人展示了当前产品增量的概况。通常都会在Sprint评审会议中调整产品待办事项列表。

    Sprint回顼会议(Sprint Retrospective)

    在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程、人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在的改进事项,为将来的改进制定计划。所有的Scrum会议都是限定时长的,Sprint回顾会议的推荐时长是Sprint中的每一周对应一个小时(译者注:比如,一个Sprint包含2个星期,则Sprint回顾会议时长为2个小时)。

    Scrum团队总是在Scrum的框架内,改进他们自己的流程。

    SCRUM的三个物件

    三个物件指的是产品待办事项列表(Product Backlog)、Sprint Backlog和燃尽图

    Product Backlog – 产品待办事项列表

    产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

    产品待办事项列表是一个持续完善的清单, 最初的版本只列出最初始的和众所周知的需求。 产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的,它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在,产品待办事项列表就存在。

    产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。

    产品待办事项列表通常以价值、风险、优先级和必须性排序。它是一个按照优先级由高到低排列的一个序列,每个条目有唯一的顺序。排在顶部的产品待办事项列表条目需要立即进行开发。排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。

    排序越高的产品待办事项列表条目比排序低的更清晰、更具体。根据更清晰的内容和 更详尽的信息就能做出更准确的估算。优先级越低,细节信息越少。开发团队在接下来的 Sprint 中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,因此,任何 一个条目在 Sprint 的时间盒内都可以被“完成”。开发团队在一个 Sprint 中可以“完 成”的产品待办事项列表条目被认为是“准备好的”或者“可执行的”,能在 Sprint 计 划会议中被选择。

    随着产品的使用、价值的获取以及市场的反馈,产品待办事项列表变成了更大、更详 尽的列表。因为需求永远不会停止改变,所以产品待办事项列表是个不断更新的工件。业 务需求、市场形势和技术的变化都会引起产品待办事项列表的变化。

    若干个 Scrum 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办事项列表只能有一个。那么这就需要使用对产品待办事项列表条目进行分组的属性。

    通过产品Backlog地梳理来增添细节、估算和排序。这是一个持续不断 的过程,产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表梳理的时候,条目会被评审和修改。然而, 产品负责人可以随时更新产品代办事项列表条目或酌情决定。

    梳理在 Sprint 中是一项兼职活动,在产品负责人和开发团队之间展开。通常,开发 团队有自行优化的领域知识。然而,何时如何完成优化是 Scrum 团队的决定。优化通常占用不超过开发团队 10%的时间。

    开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的 决定。但是,最后的估算是由执行工作的人来决定的。

    SPRINT BACKLOG

    Sprint 代办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划。Sprint 代办事项列表是开发团队对于哪些功能要包 含在下个增量中,以及交付那些功能所需工作的预计。

    Sprint 代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量 所需要执行的工作。Sprint 代办事项列表使开发团队确定的、达到 Sprint 目标所需的工 作清晰可见。

    Sprint 代办事项列表是一份足够具体的计划,使得进度上的改变能在每日例会中得到 理解。开发团队在整个 Sprint 中都会修改 Sprint 代办事项列表,Sprint 代办事项列表也 会在 Sprint 的进程中慢慢显现,比如开发团队按照计划工作并对完成 Sprint 目标所需的 工作有更多的了解。

    当出现新工作时,开发团队需要将其追加到 Sprint 待办事项列表中去。随着任务进 行或者被完成,需要更新每项任务的估算剩余工作量。如果计划中某个部分失去开发的意 义,就可以将其除去。在 Sprint 内只有开发团队可以对 Sprint 待办事项列表进行修改。 Sprint 待办事项列表是高度可见的,是对团队计划在当前 Sprint 内完成工作的实时反 映,并且,该列表只属于开发团队。

    Product Backlog 功能点被放到Sprint的固定周期中,Sprint Backlog 会因为如下原因发生变化:

    ❶随着时间的变化,开发团队对于需求有了更好的理解,有可能发现需要增加一些新的任务到Sprint Backlog中。

    ❷程序缺陷做为新的任务加进来,这个都做为承诺提交任务中未完成的工作。

    Product Owner也许会和Scrum team一起工作,以帮助team更好的理解Sprint的目标,ScrumMaster和team也许会觉得小的调整不会影响sprint的进度,但会给客户带来更多商业价值。

    燃尽图(BURN-DOWN CHART)

    Sprint燃尽图(Sprint Burn-down Chart)

    Sprint Burndown Chart 显示了Sprint中累积剩余的工作量,它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量,X轴代表的是Sprint的工作日。

    在Sprint开始的时候,Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成,但没有完成的任务的工作量是累积工作量,团队会根据进展情况每天更新累积工作量,如果在Sprint结束时,累积工作量降低到0,Sprint就成功结束。

    由于在Sprint的刚开始的时候,增加的任务工作量可能大于完成的任务工作量,所以燃尽图有可能略微呈上升趋势。

    发布燃尽图(Release Burn-down Chart)

    在Scrum项目中,团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期,以Sprint为单位, Y轴代表的是剩余工作量,通常以用户故事点、理想人天或者team-days为单位。

    展开全文
  • 敏捷开发-回顾会议

    2017-06-22 14:52:44
    保持透明性、检视与调整是Scrum的三大支柱, 以此作为支撑我们才可以对整个开发过程进行持续的改善。回顾会议是Scrum检视与调整的一个重要的环节,在这个会议上,ScrumMaster鼓励团队在Scrum过程框架和时间范围内,

    保持透明性、检视与调整是Scrum的三大支柱,
    以此作为支撑我们才可以对整个开发过程进行持续的改善。

    回顾会议是Scrum检视与调整的一个重要的环节,在这个会议上,ScrumMaster鼓励团队在Scrum过程框架和时间范围内,
    对自己的开发过程进行改进,并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。
    回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。
    检验要确定好的做法继续保持,以及需要摒弃或改善的做法。

    这些包括:Scrum团队构成、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。
    在Sprint回顾会议的最后,Scrum团队应该确定将要在下个Sprint中实现的有效改进方法,并在接下来的Sprint中付诸行动。

    然而,开好回顾会议,让其起到促进团队持续改善的效果并非易事。
    要开好回顾会议对会议的形式、主持人的协调能力都有很高的要求。

    如果回顾会议过于形式化和刻板则会使团队丧失参与的兴趣,
    不利于团队成员说出真实的想法,也不利于发掘更有效的改进建议。

    ScrumChina linkedin group(http://www.linkedin.com/groups?gid=3343227
    对此进行了热烈的讨论,也分享了不少有用的实践,许多参与者认为回顾会议应该保持轻松愉快的氛围,
    让大家畅所欲言,在这里挑出其中的一些供大家参考:

    Jingbin Liao:建议增加一个感谢环节,每个人都可以感谢其他人对我的帮助,感谢某某某对团队做出的贡献。

    Kai Wang :我们的实践一般会再加一个问题:对于not working的,
    我们要采取什么行动 如果这个sprint提的行动,到下一个sprint还没有执行,就加大一个字号,
    到下下一个sprint还没有执行,就再加大一个字号,以此类推。

    Hongquan Yin : 讨论什么不好,然后就要想出解决的方法。
    另外反思会另外一点就是增进团队成员之间的情感交流,因为我发现在做scrum task的时候,更多的是就事论事,比较干燥。

    Fred Liu :retrospective是对过程的反思,形式不固定,搞点活泼的也挺好,不过主题不要跑偏了。 说不定可以来点禅家的冥想
    Mike Li :制作一些表情符,用这种方式让大家表达一下对Sprint的感受,高兴?沮丧?激动?无所谓?

    Mark He : 个人觉得Retrospective最重要还是要能听到真话,Team和个人的Pain Point是什么,以便持续改进。
    所以除了什么方面做的好,什么不好之外,一般我会在回顾会议开始加小环节,
    总结通报上次会议定下来的行动列表,哪些做了,哪些还没有,没有做的联系人是谁,原因是什么,接下来会怎么做。
    回顾会议的结尾,也会做个小结,根据会议内容列出行动列表,便于后期检查。
    见过有Team开了会但是没有行动列表的,没有实实在在的解决问题,结果每次开讨论的问题都差不多,最后Team就皮掉了。
    当然这个方法未必就一定好,只是个人几次实践下来发现效果还可以,至少Team知道确确实实重视他们的意见,也在不断改进,就会更加愿意说真话,良性循环 。

    De Yi (Linda) Liu:我们的做法是(个人感觉很有效):每人发三张便签纸,
    分别写下: – What to Keep – What to Change – What to Try
    每张纸上不能超过三条。如果实在没有,也可以不写,或少于三条,但不能一张也不写。
    (可以记名,也可以不记名,由Team自己决定) 然后把所有的纸条收集到一起,贴到白板上,总结出每一项的Top 3。
    经过小组一致同意,确定下来。在新的Sprint中随时跟踪执行情况,并在下一个Retrospective的时候总结。
    这样做有很多好处: – 每个人都得以发言 – 大家不会受到某些比较“积极”发言的人的影响 我们在使用这种方法前,往往只是Scrum Master或少数几个活跃的成员发言,其他人”默许”。
    但是用了这种方法后,每个人都能提出很有建设性的建议。 另外,如果是记名的,还可以用来评选Sprint Champion。
    比如谁的“What to try”的建议被采用得最多。
    这又引出我们活跃团队气氛的一个方法:Sprint Champion。
    我们的Scrum Team在Sprint Review、Plan、Retrospective时,都会评选不同的Sprint Champion。
    经过实践,效果非常好。当然,Champion的内容要选择有利于Team work的项目,而不是突出个人贡献。

    展开全文
  • 敏捷开发之站立会议

    2015-04-19 15:37:26
    1) 在 Scrum 方法中,Scrum 会议非常重要,整个会议可能会比较混乱粗略,但推进进度的目标却非常清晰明确,并促使团队齐心协力朝共同目标迈进。  2) 团队应召开每日 Scrum 会议,以便确定下一天所需执行的...
    1) 在  Scrum  方法中,Scrum  会议非常重要,整个会议可能会比较混乱粗略,但推进进度的目标却非常清晰明确,并促使团队齐心协力朝共同目标迈进。  
    2) 团队应召开每日  Scrum  会议,以便确定下一天所需执行的工作,以最大可能地履行其承诺。   团队的每个成员都应该描述自上次会议以来所做的工作。  
    3)他们计划在当天完成的工作,以及可能对其他团队成员产生影响或需要获得其他团队成员帮助的任何问题或障碍。 
    4)Scrum  主管严格控制会议结构,确保会议准时开始并在  15  分钟或更短时间内结束。 
    在此会议中,每个团队成员都需要回答以下三个问题: 
      自上次  Scrum  以来我完成了哪些工作? 
      至下次  Scrum  之前我将完成哪些工作? 
      哪些阻碍性问题或障碍可能影响我的工作?

    SCRUM组严格遵守 timebox原则,每天的日站会准时开始,每次都严格的控制在十五分钟之内,会议的进展也严格围绕daily SCRUM的三个主题进行。

    项目的延期源之每天的延期,所以要每天实时跟踪进展,站立会议必须每天定时定地点召开,团队所有人员站立参加。

    每次会议不超过 15 分钟;如果要讨论技术问题,会后单独开会,少数人参与讨论。

    回答的形式与目的不是向领导汇报工作,而是团队成员之间相互交流,以共同了解项目情况和共同解决问题。

    成员在回答三个问题时目光要注视着大家,而不是 Scrum Master,否则就变成了向领导汇报工作。对每个人回答的问题有疑问,其他成员都可以提出,而不是只有Scrum Master 一个人在问。

    成员提出的问题或困难其他成员要认真倾听,确定相关的负责人和协作方式,但问题细节不在会议上讨论。

    站会结束后,ScrumMaster 一定要知道哪些问题需要帮助团队成员解决。  

    奉送一点建议:“产品项目经理为 Scrum Master”,以我个人认知不推崇这样做。这会使得这个人物在团队中过于“特殊”,而且实际上这两个角色各自的职责都已相当繁重。

    组织会议其实正是 Scrum Master 一项非常重要的技能;有效的开展会议,能够体现出组织者,也就是 Scrum  Master 在控制会场,协调问题的解决,积极推动项目进展和管理团队方面的综合实力了。并且,当敏捷项目分布在不同国家地区、时区时,这类会议的开展更有难度。使用以下推荐的方法和技巧能够帮助成功开展每日站立会议并且将使得 scrum master变得更加专业: 
    1)  给Scrum Master 的几点建议: 
      自信 
      声音洪亮 
      在会议室中适当走动 
      观察团队每个人   
      了解每个人的特点   
      不做无准备之发言   
      保持礼貌    
      前后一致

      别太幽默 
      避免情绪化   
      感激    
      平衡发言时间    
      请外向型的先发言,请内向型做总结    
      保持正常语速    
      提醒发言者如果发言时间很长,或是经常打断其他人 
      可定期改变发言顺序

      并非3 个问题都需要问  

    每日站立会议中团队成员轮流主动发言,主要就“昨天干了什么”,“今天计划干什么”,“遇到了什么障碍”三个问题进行讨论。团队外成员也可以参与,但没有发言权。通过每天面对面的沟通可以: 
    1)  快速同步进度,让组内成员相互了解彼此进展,从而了解本项目的整体进展。 
    2)  给团队成员一种精神压力,要对每日的工作目标信守承诺。 
    3)  培养团队文化,让每个人意识到我们是一个团队在战斗。

    展开全文
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...

    简介

    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢?

    目录

    1. 什么是敏捷开发?
    2. 传统的开发模式和敏捷开发模式的对比?
    3. 敏捷开发scrum的实施。

    什么是敏捷开发

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

    在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    传统的开发模式和敏捷开发模式的对比

    瀑布模型:
    这里写图片描述
    优点:
    1. 为项目提供了按阶段划分的检查点。
    2. 当前一阶段完成后,您只需要去关注后续阶段.
    3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

    缺点:
    1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
    2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
    3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    4. 瀑布模型的突出缺点是不适应用户需求的变化。

    敏捷模型:
    这里写图片描述
    优点:

    1. 敏捷开发的高适应性,以人为本的特性。
    2. 更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

    缺点:

    1. 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

    敏捷开发scrum的实施

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。

    Scrum开发流程中的三大角色
    – 产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    – 流程管理员(Scrum Master)

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    –开发团队(Scrum Team)

    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

    scrum开发流程图

    这里写图片描述

    1、我们首先需要确定一个Product Backlog(产品需求列表),这个是由PO负责的(如图(一));

    2、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    3、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)(如图(二)和如图(三));

    5、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。

    6、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

    7、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

    如图(一):
    这里写图片描述

    如图(二):
    这里写图片描述

    如图(三):
    这里写图片描述

    如图(四):
    这里写图片描述

    敏捷开发管理工具:teambition
    teambition

    参考

    敏捷开发之Scrum扫盲篇
    百度百科
    敏捷开发 模型讲解

    展开全文
  • 敏捷开发-站立会议要点: 1、站立会议全员都需要参与; 2、当值员必须提前准备,识别出问题和风险,做好协调; 3、每个组员汇报进展和当天的计划。对于承诺的任务,需要完全执行; 4、每日站会实践不能超过15...
  • 敏捷开发-迭代会议

    2016-04-19 00:33:42
    敏捷开发迭代会议,主要是挑出产品设计和功能问题,保证迭代版本的产品原型完整性、正确性、合理性。如果产品大致功能没有多大问题,留下些小问题,那么可以进行项目拆分、工时估算。(一个细节要提醒的,产品必须在...
  • 敏捷开发流程总结

    2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
  • 每日站立会议敏捷流程scrum中的很重要的一个制度之一。 功能: 1.快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展。 2.给每个人一精神压力,信守承诺。这是一面对面的精神...
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发(Agile)是一以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
  • 敏捷开发初步了解

    2019-09-02 10:34:44
    敏捷开发  敏捷开发,现在大多数团队都在推崇敏捷开发模式  笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?... 敏捷开发是一以人为核心、迭代、循序渐进的开发方法...
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发与迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...
  • 会议 用途 持续时间 举行次数 冲刺 (sprint) 计划会议 确定在下一冲刺 (sprint) 中要做的工作。 在冲刺 (sprint) 中,每周两个小时,最多个小时 每个冲刺 (sprint) 举行一...
  • 敏捷开发实践总结

    2018-11-25 23:46:06
    敏捷开发实践的认识什么是敏捷开发敏捷开发的原则多种敏捷开发的方法一个敏捷团队敏捷开发中常用的术语迭代的典型流程致谢 什么是敏捷开发 敏捷开发(Agile Development)是一以人为核心、迭代、循序渐进的开发...
  • 本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。 一、Scrum的定义和目的 Scrum是一个用于开发和维护复杂产品的框架,是一个...
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
1 2 3 4 5 ... 20
收藏数 20,890
精华内容 8,356