2012-01-18 11:26:37 dyllove90 阅读数 98

欢迎大家访问我的个人网站 萌萌的IT人,后续所有的文章都会在此发布

--------------------------------------------------------------------------------------------

 

本文主要是为了检测你对SCRUM 评审会议的了解和使用程度,
通过本文你可以检测一下
    1、你们的SCRUM 评审会议的过程和步骤
    2、SCRUM 评审会议的输出结果

一、会议目的

    1. 团队的成果得到认可。他们会感觉很好。
    2. 其他人可以了解你的团队在做些什么。
    3. 演示可以吸引相关干系人的注意,并得到重要反馈。
    4. 演示是(或者说应该是)一种社会活动,不同的团队可以在这里相互交流,讨论各自的工作。这很有意义。
    5. 做演示会迫使团队真正完成一些工作,进行发布(即使是只在测试环境中)。如果没有演示,我们就会总是得到些99%完成的工作。有了演示以后,也许我们完成的事情会变少,但它们是真正完成的。这(在我们的案例中)比得到一堆貌似完成的工作要好得多,而且后者还会污染下一个 sprint。
    6. 根据团队这次 Sprint 所发布的版本,评审相关的 Backlog 中的问题,检查是否已达到 Sprint 的目标。
    7. Scrum 团队在会议中向最终用户展示工作成果。团队成员希望得到反馈,并以之创建或变更 Backlog条目
二、会议时间

    1. 该会议时间限制为不超过 90分钟。
三、会议准备

    1. 邀请与会者:
          产品负责人
          Scrum Master
          团队所有成员 
    2. 对于每个人来说 Sprint 目标都是公开的
    3. 对每个人来说既定产品 Backlog 是公开的,可获取的
    4. 小组准备好工作站和设备等等,用以展示产品的新功能 
四、会议进程

    1. Product Owner欢迎大家来参加Sprint 复审会议。
    2. Product Owner提醒大家关于本次 Sprint的目的:Sprint目标、Scrum团队在
    3. 本次Sprint中选定要开发的故事。
    4. 产品开发团队展示新功能,并让最终用户尝试新功能。
    5. Scrum Master 推进会议进程。  
    6. 最终用户的反馈将会由 Product Owner和/或Scrum Master记录 
       (1). 如果产品负责人想要改变功能:添加一个新问题到产品 Backlog 中
       (2). 如果对功能有一个新的想法:添加一个新问题到产品 Backlog 中
       (3). 如果小组报告项目遇到阻碍现在还没能解决:把该障碍加入到障碍 Backlog   
    7. 注意事项:
       (1). 确保清晰阐述了 sprint 目标。 如果在演示上有些人对产品一无所知,那就花上几分钟来进行描述。
       (2). 不要花太多时间准备演示,尤其是不要做花里胡哨的演讲。把那些玩意儿扔一边去,集中精力演示可以实际工作的代码。
       (3). 节奏要快,也就是说要把准备的精力放在保持演示的快节奏上,而不是让它看上去好看。
       (4). 让演示关注于业务层次,不要管技术细节。注意力放在“我们做了什么”,而不是“我们怎么做的”。 可能的话,让观众自己试一下产品。
       (5). 不要演示一大堆细碎的 bug 修复和微不足道的特性。你可以提到一些,但是不要演示,因为它们通常会花很长时间,而且会分散大家的注意力,让他们不能关注更加重要的故事。 
      
五、会议结果

    1. 对这次 Sprint 的结果和整个产品的开发状态的共识  
    2. 来自最终用户的反馈
    3. 障碍backlog输入  
    4. 团队backlog输入
    5. 来自团队的product backlog输入

    

 

2014-10-22 12:00:53 quding0308 阅读数 775

Sprint

Sprint是敏捷开发中的一个开发周期,时间应在一个月以内,最终应有完成的、可发布的产品。
Sprint包含计划会议、每日例会、开发工作、评审会议、回顾会议。
在一个Sprint中,开发团队成员、Sprint目标不应该改变。
一个Sprint的时间应控制在两周左右。合适的时间可以确保Sprint目标不随便变化,把风险限制在一个月的成本上。
如果某个Sprint目标过时了,产品负责人可以提前取消Sprint。

Sprint计划会议:
计划会议确定Sprint中要完成的工作,有整个Scrum团队一起完成。

会议输入:产品待办事项列表、团队对这个Sprint的接受程度以及以往的表现
     注意事项:首先需要明确回答两个问题:1、这个Sprint最终完成后要交付的结果 2、为此需要做的具体工作

会议结果:根据产品待办事项,开发团队对每个待办事项预估工作量,并开发团队成员认领待办事项。
    注意事项:产品负责人需要对待办事项做出说明,协助开发团队做出取舍;开发团队需要明确sprint最初几天的工作内容,分解为少于一天的量。

每日例会:
目标:评估Sprint进度。同步成员的活动,并创建一天的计划。提前暴露问题,降低风险。
开发团队中的每个成员应说明:已完成的工作,准备完成的工作,遇到的障碍、可能的风险
     注意事项:Scrum Master确保会议正常举行,控制时间以;应该确保每个成员都了解目前的进度以及每个成员各自的工作;应该强调交流沟通,提前暴露可能的问题,

Sprint评审会议
会议内容:

  1. 产品负责人确定哪些已完成,哪些未完成
  2. 开发团队讨论在Sprint中哪些进度顺利、遇到了什么问题,如何解决的
  3. 开发团队演示完成的工作
  4. 整个团队就下一步的工作进行探讨,根据完成的事项,最终输出一份修订的产品代办列表


Sprint回顾会议
Scrum团队检验自身,并列出要改进的点
对前一个Sprint周期中的人、过程、工具进行检验,列出 better 和 to be better,列出要改进的点

2010-02-26 10:22:00 ljinddlj 阅读数 5589

敏捷开发Scrum——Sprint Retrospective

Moakap总结

Scrum中,每个Sprint结束的时候会有两个会议(Sprint Review/DemoSprint Retrospective回顾)。这两个会议是对过去的一个Sprint的一个总结,其中Review/Demo是检查过去一个Sprint的产出(What),主要是PO根据先前的计划来检查Team在过去一个Sprint的工作成果,包括一些Demo,以及未完成部分的总结和分析;而Retrospective则是回顾过去一个Sprint整个Team的运作模式,有什么好的和不好的实践,怎样在未来的Sprint做的更好,强调How

Sprint Retrospective(回顾)

Sprint Retrospective会议主要是整个Team讨论过去的一个Sprint的运作,如何改进使Team更良好的运作。讨论的内容可以是任何有关Team建设的问题,包括工作流程、团队实践、团队内部/外部沟通、团队气氛以及相关工具的使用等等。

Scrum并不是一种方法,而是给软件开发流程提供了一种框架,在整个框架下,不同的项目、团队需要根据具体条件,适时调整实践方法。而Retrospective会议正是一个Scrum团队自我调整的机会。

会议的参加者包括整个Scrum团队、Scrum MasterProduct Owner。会议由Scrum Master主持,一般以下边两个问题开始:

1.       过去的一个Sprint里,我们有哪些好的方面?

2.       过去一个Sprint存在哪些问题?

整个Team就这两个问题进行公开讨论,方式也可以是多样的。可以大家一起讨论,Scrum Master在讨论过程中将大家的观点记录在白板上;也可以让Team每个成员在便签纸上写下自己的答案,可以要求每个问题至少写三点,然后每个人把自己的答案贴在白板上,并给出相关解释。

讨论完毕后,对讨论结果进行分类。对于好的方便,在下个Sprint继续保持并发扬;对于存在的问题,列出Action Point去解决问题。列出的Action Point也会在下个Sprintbacklog中体现出来,并且是高优先级的项目。

注意:不引起任何变化的Retrospective只是浪费时间。

Watch Ken Schwaber's guidance on the Sprint Retrospective Meeting.

 

2014-02-27 20:57:18 liu765023051 阅读数 8445

接触Scrum时间不长,开发中遇到的问题比预想的要多很多。

Scrum上面说了,每一个Sprint的时间设置在2——6周是比较合理的。我认为一般的项目一个Sprint4周比较合理。由于我们的pj项目不是很大,真正开发起来一月个差不错项目就哦了。所以第一个Sprint采用的是一周时间,这样能动性强了,但是暴露出了更多问题:


1、由于第一个迭代过程中,涉及到开发环境的配置及搭建,这些如果分别算是一个story,那么时间怎么评估怎么算呢?其实这些东西挺花费时间的。算的话,时间怎么计算合理?不算就肯定得让团队加班加点儿。结果我们采取的方式比较折中。以大家每天的工作时间*0.6为有效编码时间,以拍扑克的方式去平均数,估算每个story时间,留出足够的时间空余;


2、传统开发方式的影响。评估过程中,每个story的颗粒过细,建立story应该是站在用户的角度去考虑需求,然后一会儿就又去建立一个story:这个xx项目调试的调试工作。我认为:既然敏捷开发是每个人在开发的过程中再确定系统具体的需求,那么就应该综合考虑某一条线功能的复杂性与粒度问题。不用每个功能都分得特别细;


3、由于第一个迭代时间非常短,可以说,完成的都是一些准备工作与已知的技术攻坚,直接导致第一个迭代没有出任何可视的项目成果。这里是有悖于敏捷精神的。第一个迭代中,最好出一些可视的项目成果,领导查问起来,尽管团队成员都做了很多,但是不至于拿不出可视的东西。


另外,尽管我们第一个Sprint没有出项目成果,但是出色的完成了准备工作,使我们过分乐观了客观现实,导致我们第二个sprint的开发大大受阻。

年前因为赶时间,由于与jc系统交互的webservice中的方法,并不是全部通过了单元测试,也就是说,有些实现方法编码还是有问题的。由于系统之间彼此交互的东西很多,做假数据继续进行开发不是没有可能,但是非常浪费开发人员的时间,不然就得等jc那边调试好相应方法;如果仅仅是这样还算是幸福的,如果修改方法名或者参数,那么不仅jc系统那边对应的方法重新改、重新部署,我们这边所有开发人员都得跟着重新换接口。


4、彼此依赖,无法进行。由于我们pj系统的现有需实现的功能,都需要与jc系统做交互。之前的实现是将我们pj系统中需要的数据,从jc拷贝到我们系统中来,这样设置,我们前期工作比较好开展。而现在是jc系统那边维护唯一一份数据,而我们这边与jc做沟通调试webservice的人员没有完成,我们组其他成员就无法正常进行开发。影响项目进程。


5、会议太频繁。尽管我们第一个Sprint只有一周时间,但是由于出现了上面依赖问题,我还是召开了Sprint实施中召开了迭代计划会议。商讨其他story以及时间。每日的站立会议以及后期的评审会议、反思会议……


6、照猫画猫、生搬硬套之嫌。第一个Sprint,由于大家对Scrum还不是很熟悉,实施起来有些呆板有些生硬,这也是刚开始实施敏捷开发过程时,很容易犯的问题。


7、开发过程中,好多人都在看别人写的代码,时不时就会传来抱怨声一片片~~~这里只想说两句话:一、快速看懂别人代码的思路,是一种能力;二、写单元测试,从我做起。


目前项目中亟待解决的问题:

项目组成员应坐一起开发,沟通不及时会浪费更多的时间;

jc那边webservice方法的单元测试;

查询效率问题以及连带产生的hibernate优化、代码优化、思路优化问题。


敏捷团队之所以敏捷,是因为项目组中有:具有大局观令人敬服的组长、各有专攻沟通能力强的组员以及和谐的团队。然后坚持“以人为本”的方针,实现有限时间内的最大价值。提高团队成员的主观能动性,这是敏捷开发最基础的。不能做到这一点,就又回到了之前的呆板的开发模式中,敏捷开发就无法敏捷。

2018-10-21 23:36:35 zhaoenweiex 阅读数 686

前言

本文将探讨一个所有软件开发者都头疼的问题,那就是项目计划和其中涉及到的估算。任何一个项目都离不开项目计划,但绝大多数项目计划都不怎么靠谱。以前已经有一篇文章讲了计划会议的实践,这里是传送门。但项目计划并不是简单的计划会议,而是一整套的活动才能确定的。接下来就结合经典的敏捷开发方法论以及我们团队的实践来看看在敏捷开发里项目计划和估算的实践方式是否能够给你带来一点启示。

内容

敏捷计划的特点

首先敏捷开发中的计划也不是很靠谱的,但相对于传统的计划,良好的敏捷团队给出的计划和估算能够在团队变化不大的条件下做到短期内靠谱。你要是让敏捷团队提供一个超过一年的靠谱开发计划估计是难为他们了。
其次他们给出的估算只适用于他们这个团队,而且都是相对值,对于人天的估算并不是很理想。
最后一般来说敏捷开发的计划都是会滚动动态调整的,不是静态不变的。

Sprint-0计划

有不少介绍敏捷方法的书一上来就会说要进行迭代开发,大家真正着手这么干的时候往往会懵逼不知道该如何开始,其实一般敏捷团队在新项目开始的时候都会有一个Sprint-0的周期,这个周期主要是准备环境,资源以及进行需求调研等等,这些事往往都比较虚,但都是极为重要的,如果做不好就会一团糟。下面我们就逐步介绍跟计划有关的部分。
注意:计划相关的活动应该全部的团队成员都参加,无论是测试,开发,项目负责人,UI等等,如果团队太大的话应该各个方面派出代表,但这往往意味着你需要进行团队的拆分。

场景构建

第一步是场景构建,场景这个词出现的频率是越来越高,而且正在从互联网行业向传统行业转移,以前一听到场景这个词就觉得一定是个高手,但现在用户都能说先讨论场景,可见其普及程度和重要性。
构建场景属于需求分析中的关键一步,而需求分析应该是贯穿整个敏捷开发流程的,之所以要在Sprint-0进行场景构建就是因为场景是展示需求的舞台,使后期的讨论能够具象化,让参与者能够更快的达成一致。
场景构建可以采用模拟法,通过白板或画纸来快速的勾勒出简化的有高度代表性的业务情景。一般可以通过模拟整个产品或系统的使用过程来逐步进行演示,然后将大家关注的一小段作为一个场景进行切分,确定系统或产品的典型场景即可,有点像拍电影的感觉。
什么时候构建完了呢,就是找一个没有参加讨论的人,来给他演示确定经典场景,他一次就明白过程,而且对于场景有画面感就基本算是完成了。
这一阶段的成果最好通过照片或画纸记录下来,后面将经常用到。

用户故事梳理

第二步就是梳理用户故事了,用户故事的形式大家都知道:作为XXX,我希望能做到XXX,以便我XXX。
针对刚刚的每一个场景分别进行用户故事梳理,就直接把照片或画纸贴到白板上,对着场景即可。大家通过头脑风暴的形式提出这个场景的用户故事,用户故事就写成卡片的形式直接贴到场景上,直到确认用户故事完全的覆盖了场景。
别忘了最后保留场景外的用户故事,来确保没有遗漏。
这个阶段你应该收获一堆卡片,并且是对着不同的场景的。

用户故事估算

接下来该是开发团队的重头戏了。
开发团队(实际上是所有参与开发的团队,包括但不限于测试,UI等等)需要逐一对着用户故事进行估算,来确定完成用户故事所需要的时间。一般采用故事点来衡量。注意故事点是一个相对的大小单位,并不一定代表着一个固定的人天数。
采用的具体方法可以考虑使用敏捷扑克法,这将是个漫长的过程,准备好足够的零食和水。仅仅一个规模不大的项目估算用户故事就能消耗3~4个小时。具体的敏捷扑克法我就不在这里说明了,百度一下大概情况应该能了解。
这个阶段最后你应该能得到一堆估算完的用户故事,我们习惯于把估算值写到故事右下角。

故事地图来确定发布计划

一般来说估算完了的总和是很吓人的,可能好几百了故事点,根据之前的经验也许一个故事点需要大概5人天,这可能需要好几年的时候才能全部完成。这时候项目负责人该变为主角了,将这些卡片分别排在对应的场景下,项目负责人根据优先级对用户故事进行排序。
成果如下图所示
排序后的地图
然后再根据估算的周期进行划分,不断的权衡周期和内容,最终确定如下图所示的内容。
在这里插入图片描述
这里的发布1,2,3就可以算是大体靠谱的里程碑了,如果更科学一点的应该让团队进行三个迭代周期的开发,再来正式确定发布日期。

总结

良好的Spint-0是一个项目成功的基石,是不是已经厌倦了拍脑袋的日子了呢?敏捷模式将是一个不错的选择。

没有更多推荐了,返回首页