精华内容
下载资源
问答
  • Scrum站立会议

    2016-09-12 23:33:00
    Scrum是一个包括了一系列实践和预定义角色的过程骨架。 主要角色: 产品负责人: 负责维护产品订单的人,代表利益相关者的利益。...会议准时开始。对于迟到者团队常常会制定惩罚措施 欢迎所有...

    Scrum是一个包括了一系列实践和预定义角色的过程骨架。

    主要角色:

    产品负责人: 负责维护产品订单的人,代表利益相关者的利益。

    Scrum主管 :为Scrum过程负责的人,确保scrum的正确使用并使得Scrum的收益最大化。

    开发团队:一个跨职能的小团队,人数5-9人,团队拥有交付可用软件需要的各种技能。

    指导原则:

    • 会议准时开始。对于迟到者团队常常会制定惩罚措施 
    • 欢迎所有人参加,但只有在专案中承担实际工作的角色可以发言。
    • 不论团队规模大小,会议被限制在15分钟。
    • 所有出席者都应站立。(有助于保持会议简短)
    • 会议应在固定地点和每天的同一时间举行。

         会议上,每个团队成员需要回答三个问题: 

        1.昨天你完成了哪些工作

        2.今天你打算做什么?

        3.完成你的目标是否存在什么障碍?(Scrum主管需要记下这些障碍)

     

    每一个冲刺完成后,都会举行一次冲刺回顾会议,在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。

    Scrum提倡所有团队成员坐在一起工作,进行口头交流,以及强调项目有关的规范(disciplines),这些有助于创造自我组织的团队。

    Scrum的一个关键原则是承认客户可以在项目过程中改变主意,变更他们的需求,而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样,Scrum采用了经验方法– 承认问题无法完全理解或定义,而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。

    本人对站立会议这种团队交流模式很是赞同:首先站立会议得保持大家都不能迟到,因为再耽误的是团队中每个人的时间。其次,站立会议能将每个人昨天所做的事情作总结,明确今天所要做的是,不懂得或者有疑问的可以当面讨论,而且能在短时间内或得相对好的解决方案。Scrum主管负责协调团队各成员的工作,提高整体的工作效率,对于需求的改动能通过会议尽快传达到每个人。并且站立会议能增进团队成员之间的情感。

    不论团队规模大小,会议被限制在15分钟。

    点评:对会议时间的限制是为了节省时间,并且提高工作效率。因为对于一天的工作量的安排和总结在15分钟内是能解决的。

    所有出席者都应站立。

    点评:出席者在站立时有助于集中注意力,认真参与会议,方便交流。

    完成你的目标是否存在什么障碍?

    点评:在会议上将自己的将自己的困难讲出来,有利于提高自身的工作能力和团队的开发效率。

    补充:我自己写的字数占总字数的39%

    博客字数:1506字

    转载于:https://www.cnblogs.com/liquan/p/5866847.html

    展开全文
  • 每日站立会议SCRUM方法中的一条关键实践,整个会议可能会比较混乱粗略,但推进进度的目标却非常清晰明确,并促使团队齐心协力朝共同目标迈进。  站立会议的功能很简单,作为一个以简短为特点的项目会议,所有的...

      每日站立会议是SCRUM方法中的一条关键实践,整个会议可能会比较混乱粗略,但推进进度的目标却非常清晰明确,并促使团队齐心协力朝共同目标迈进。 

      站立会议的功能很简单,作为一个以简短为特点的项目会议,所有的问题重心都在如何推进整个项目的前进。

      站立会议的要点我认为有两个,一项是快,10分钟-15分钟,迅速开完,每个人都有发言,互相有所了解。

      另一项是明确,会议需要讨论的话题只有三个:昨天完成了什么,今天要做什么,有什么需要别人帮忙。

      通过一段时间的学习,渐渐感觉到软件工程中成员之间的独立性,先有个体再来组合整体,因此不太需要很多的时间来做一个集体的规划,也很多余。因此这种简洁明了的会议还是很符合我的胃口。因为团队合作想要得到1+1>2的结果,一是要有明确的目的,每个人的分工,到手的任务一定要明确。再一个是面对无法解决困难的协作,这样才能体现出一个成熟的团队所应该具有的多人化特色,每个人各司其职,又相互协作,从而更好地完成一个项目。

     

    转载于:https://www.cnblogs.com/shaloo/p/5873616.html

    展开全文
  • Scrum落地关键实践

    2020-03-09 17:38:03
    为什么你的Scrum总是难以落地?而大多数都是“形似而实非”的“敏捷Cosplay”。我们都知道,Scrum流程是简单的,那么落地的难点在哪里呢?其实是人,人是最难搞定的。所以,如何搞定形形色色的人呢?或许,你少了很...

    为什么你的Scrum总是难以落地?而大多数都是“形似而实非”的“敏捷Cosplay”。我们都知道,Scrum流程是简单的,那么落地的难点在哪里呢?其实是人,人是最难搞定的。所以,如何搞定形形色色的人呢?或许,你少了很多敏捷实践,帮你打通各个角色间的竖井,真正的实现价值的流动。


        1.为什么你觉得Scrum难以落地?

        每天都在讲Scrum,你可以徒手画出Scrum的框架图吗?那个经典的“3355”,还记得吗?不妨试试看。

        思考:

        1)Scrum流程本身有问题吗?

        2) 若流程没问题,那么到底哪里出了问题,没什么难以落地?

        3) 还记得《敏捷宣言》第一条吗?

        所以是个体和互动(人)出了问题!也就是人出了问题!

        很多人可能都看过甚至可以对《敏捷宣言》倒背如流。但是,你看过2001年在美国犹他州雪鸟山那次会议上,Andy Hunt 当时记录的《敏捷宣言》手稿吗?

        有发现吗?从手稿上来看,4条宣言的排序上,17位敏捷大师们有过多次纠结且一定伴随了多次的讨论,但是只有第一条“个体和互动高于流程和工具”是始终排在第一位没有变动过的。所以,Scrum难以落地的根源,一定是最根本的“个体和交互”出了问题。

        继续思考,如果每种角色间的交互都会形成一堵墙,Scrum会变成怎样?

        是的,会形成很明显的边界,或者你可以叫做“竖井”。业务如何变成需求,需求如何传递业务,研发如何实现业务价值等,这类问题就会变得很棘手,甚至形成角色对立。 


      2.如何打通各个域,让价值流动起来?

        上图是在IDCF训练营学习时,王立杰老师取自李涛老师原创的一个MoMoCo模型,为了更加便于理解,所以对命名进行了小小的修改。

        从宏观的角度的展示了,如何利用影响地图,用户故事地图,及看板,来打通业务域到需求域再到实现域的一个框架体系,下面我们来详细的看下。

        在这里不得不的提到一个非常牛X的法则——黄金圈法则!

        扩展一下:

        1)什么是黄金圈?

        很简单,三个同心圆,最里面的一个是Why,中间一层是How,最外面一层是What。

        2)什么是黄金圈法则?

        举个例子,比如一般的电脑公司的市场营销会这么做:我们做了最好的电脑(What),我们的产品设计很好,使用简单(How)。接着会问:怎么样,你想买一台吗?典型的从外向内的交流和沟通的方式,也是大多数市场推广的方式。上来先告诉你我们是干什么的,我们是怎么不一样,然后期待着别人的反应。但其实这种沟通的方式是很低效的。

        我们再来看一看,用黄金圈法则的苹果公司,他们是怎么做的?首先告诉你,我们做的每一件事都是为了创新和突破,我们坚信应该以不同的方式来思考(Why),接着我们挑战现状的方式是将产品设计的十分精美,使用简单并且界面友好(How)。最后再告诉你,我们顺便也就做出了一台最好的电脑、最好的Iphone(What)。你想来一台吗?

        其实这种逆向思维的真相在于:要想最大程度影响他人,最关键的不在于传递“是什么”的信息,而在于给出“为什么”的理由

        大量的事实已经证明,人们在决定购买的时候,买的并不是产品,而是在为你的信念和宗旨在买单因为认同,所以买单。不是你把产品卖给了需要产品的人,而是卖给了跟你有相同理念的人。你看看苹果出新品的时候,那些彻夜不眠排队的大军,就是认同的人。

        为什么要提到这个黄金圈法则呢,因为他和我们接下来提到的影响地图(Impact Mapping)很像,而且和OKR的原理也有像,都是从Why出发,聚焦目标价值

        再聊回我们在业务域上碰到的问题,看一看影响地图在其中是如何发挥作用的。

     

        如果你还不了解“影响地图”,那么你可以建议大家去看看上面推荐的那本书。这里不做赘述。或者你对它感兴趣,可以留言,如果感兴趣的人多,我会做个专题分享。

        总结下:有的产品,它还活着,其实已经死了;还有的产品,还没发布,就已经已经被判死刑。太多的产品失败的案例,源于方向性错误,基于错误的假设,功能与业务目标/价值之间缺乏必然的关联与一致性,在做的事与期望的目标南辕北辙。而影响地图(Impact Mapping)就是这样一种试图通过结构化、可视化、协作化的方式来从源头解决上述问题的工程实践。


        首选要弄清楚什么是需求?很多时候,我们从源头就搞错了,结果后面肯定是一错再错!

        需求就是客户想从你这里获得的 价值服务,但不一定是他说的那样

        所以,我们一定要避免把用户描述的他想要的功能或解决方案当作需求记录下来,这样很危险!

        其一,用户可能描述不清楚,掩盖了价值的本意;

        其二,用户不了解现有技术架构,所以可能提出了不适宜的解决方案,以至于实现成本很高。

        比如:用户说,我要一座桥。产品把这个当作需求记录下来,然后叫研发去做。过了N久,用户一催再催之下终于交付了,可是用户已经不需要了,因为他已经租了一条船,早早的过河去了。从这个例子中,我们可以看到,用户的需求到底是什么?其实就是——尽早的过河。   

        学会,多问几个Why,直到问到和用户切身利益相关为止想了解更多,访问《6 Success Questions You Must Ask》:https://www.slideshare.net/AndreasVonderHeydt/6-success-questions-you-must-ask

        

        

     

        关于,用户故事,用户故事地图,用户价值地图,用户体验地图,这具体怎么玩,我就不展开了,默认这些基础知识是大家都懂得,如果不懂的,同样可以看看上面推荐的书籍,或者对什么感兴趣,可以留言,留言多的话,我会做一个专题分享


        需求研发是一个很重要的环节,如何保证按需开发,内建质量,这里一定离不开—— XP 极限编程

        用户故事到行为驱动的链路打通:

        关于实现域,极限编程一定是不可轻视的,不然每天crud的堆烂代码,于公于私,意义何在?


        两个工坊会议参考,点击访问《探索工坊设计与实施实录》《年度团队回顾工坊实录》


    3.写在最后

        1)问题多不要怕,Scrum就是帮你暴漏问题;

        2)坚守,而不轻易裁剪,Shu-Ha-Ri;

        3)学会借助工程实践,打通全流程;

        4)Scrum做好的前提下,再考虑LeSS或SAFe等大规模框架。

      


     

    欢迎喜欢搞敏捷项目管理的同仁们,加微信多交流!

     

    展开全文
  • SCRUM 的三个角色 ...四种会议 SCRUM 的三个角色  在SCRUM方法中将项目的利益相关者分成两大类:Pigs角色与chickens角色, pigs即为项目组的实际参与人员,Pigs



    SCRUM 的三个角色


    product backlog


    sprint backlog


    燃尽图


    四种会议








    SCRUM 的三个角色

           在SCRUM方法中将项目的利益相关者分成两大类:Pigs角色与chickens角色

    pigs即为项目组的实际参与人员Pigs在scrum中细分为三个角色:Scrum master、Product owner、Team,这三个对等地位的角色构成一个平衡的铁三角推动整个项目的进展。

    chickens为项目组的外部人员,包括经理、最终用户等等。


    Scrum master不是项目经理,他没有分配任务的权力,没有考核的权力,没有下命令的权力,他在项目组承担了如下的细分角色:

    (1)会议主持人

           他负责主持四个主要的会议:策划会议、每日站立会议、迭代评审会议、迭代回顾会议。

    2)牧羊犬

           他负责屏蔽项目组外部的干扰。

    (3)雷锋

         他给product owner、team提供帮助,帮助product owner确定需求、排定优先级,帮助team做估算、分解任务、完成任务。

    (4)外交官

         当项目组外部有人不理解项目组的工作时,他负责去解释说明,负责对外发布项目组的信息。

    (5)教练

         他指导项目组的成员按照SCRUM的原则、方法做事情,当出现偏差时,他去纠正,可以说他是精神教父、他也是警察(QA)。如果有项目组的成员不熟悉SCRUM的方法,他要去提供相关的培训。

    6)清道夫

         他负责排除在项目进展中遇到的各种障碍,如果他没有能力或资源他可以协调项目组的其他成员一起来排除障碍。


         SCRUM master.并非固定的由一个人承担,可以在一个团队中,有能力的、熟悉SCRUM的成员都可以担当SCRUM master。



    Product owner产品的负责人,或者讲是需求的负责人, 他在项目组承担了如下细分角色:

    (1)领域专家

         他是需求方面的专家,熟悉需求。他知道客户、最终用户、以及其他利益相关者对项目的真正需求是是什么。他负责编写用户需求、维护用户需求。

    (2)需求决策人

              哪个需求重要,哪个需求不重要,需求的优先级如何排列,在某次发布中要发布哪些需求是他来拍板的。他负责来平衡需求、进度与资源的关系。

    (3)需求讲师

         他负责在项目进展过程中给项目组的其他成员讲解需求的含义,对需求进行答疑。

    (4)测试员

         他负责编写每个需求的验收标准,功能测试用例。

    (5)验收人

              当项目组成员完成某个需求后,是product owner进行功能测试,进行验收,他认可后才能认为某个需求完成了。


        Product owner可以来自于用户、客户、销售部、产品策划部门或者是开发部门的需求分析人员无论是来自哪,需要满足如下的要求:

    1)Collaborative:易于协作、易于沟通;

    2)Representative:有代表性的,能代表用户、客户、市场的利益;

    3)Authorized:有授权,得到了用户、客户、市场等的授权,有对需求的决策权;

    4)Committed:尽责,能够认真的、尽职尽责的工作;

    5)Knowledgeable:在行,明白,熟悉需求;

            以上的5项要求可以简写为CRACK,这是我们的理想,在现实中找这样的product owner有一定的难度。


        Product owner是一个角色,并非指是一个人,可以是多个人,但是如果是多个人,这多个人要协调一致,对需求的理解与解释是一致的。



    Team技术的责任人,他们负责实现这个系统,他们是自我管理的,不需要外部的管理者来管理他们。在一个SCRUM团队中,一般整个团队(包含product owner,scrum master)不超过10人,team应该是一专多能的全才型选手,而不是那种专业化分工的团队,这样才能保证团队的效率比较高,也易于沟通。团队的成员一般都应该是专职的人员,不能兼职同时做多个项目。team承担了如下的细分角色:

     (1)设计人员

          对系统进行简单设计。

     (2)实现人员

          负责实现整个系统,并对系统执行单元测试,构建整个系统。

      (3)管理人员

          大家一起来估算、一起来选择任务、一起来跟踪进展情况。



    Product owner定义了这个项目做什么,Scrum master从过程上保证了如何实现这个项目,Team从技术上保证了如何实现这个项目




    在SCRUM方法中明确要求了3个文档

              1 product backlog

              2 sprint backlog

              3 burn-down chart







    product backlog


            Product backlog 中列举了本项目应该实现的需求,需求采用了用户故事的方式进行描述,用户故事是一句简短的采用用户熟悉的术语表达的需求,是用户讲给开发人员的故事,不是开发人员讲给用户的故事。既然是故事,就要有人讲,谁讲呢,product owner来讲,每次讲时可能就有细节的不同,就要有变化,但是万变不离其宗,所以故事本身是有一定的弹性的。

           故事可以有标准的格式,我称之为三段论式故事,哪三段呢?

              1 用户角色

              2 需要的功能

              3 目的

            比如,有这样一个故事:

                作为一个家庭主妇,我需要一个30平米的餐厅,以便于我可以招待10位朋友来用餐。

            用户角色是家庭主妇,30平米的餐厅是功能需求,招待10位朋友用餐是为什么需要这个功能。千万不要小看这个三段论式的故事,需要仔细琢磨每一段的作用。用户角色表明了是谁使用这个功能,如果一个功能没有明确的使用者,是否可以删除呢?如果一个用户角色不重要,是否这个需求的优先级比较低呢?目的说明了为什么需要这个功能,这个功能解决了什么问题,如果一个功能没有明确的目的,那是否可以删除呢?如果目的不太关键,这个需求是否可以优先级比较低呢?


            优先级?没错,我多次提到了优先级,需求一定要分优先级!谁来划分需求的优先级? Product owner如何划分优先级?根据商业价值!根据对客户、对最终用户的商业价值来划分优先级。如何区分商业价值的大小呢?比如提问如果不实现此需求,如果晚实现此需求客户是否会不满意,是哪类人不满?不满意到什么程度?也有的专家提出了更专业的方法,其实没必要,如果product owner真的称职的话,相信他,可以凭经验划分出优先级。


            是否仅仅描述了这样一句话就充分了呢?其实还有第四段,即用户故事的验收标准,或者叫用户故事的测试要点,这也是由product owner来完成的,product owner可以先完成前三段,在和team member的沟通过程中,逐步丰富完善验收标准。对于前面我们提到的那个故事,如果你实现了这样一个餐厅,比如是一个2米宽,15米长的餐厅,那位家庭主妇会如何想?哈哈,如果她心理健康的话,估计她立马让你跳楼!如果她心理不健康的话,她会跳楼的。当然在敏捷的方法中不会出现这种现象,在你开发的过程中,product owner会和你随时沟通交流的,在沟通中product owner还传达了这样的信息:

                 1我希望这个餐厅是5米*6米;

                 2我希望这个餐厅光线明亮;

                 3我希望这个餐厅靠近厨房;

                4 ......

            这就是验收标准!也可以换一种角度,从如何验收的角度的来描述:

                1 我会量量这个房间是否是5米*6米的;

                2 我会测测如果在这个房间里白天打扑克,不开灯的话,能否看到扑克的花色和点数;

               3 我会测测从厨房到餐厅需要走几步;

               4 ......

            如果一个故事提不出来验收标准怎么办呢?不实现它,晚实现它,直到明确了验收标准。

            到目前为止我们实际讲了product backlog中包含了5

            Product backlog = 需求 + 优先级

                      = 用户故事 + 优先级 + 验收标准

                      = 用户角色 + 功能 + 目的 + 优先级 + 验收标准


            有的专家把验收标准单列出来,我认为验收标准是需求的一部分,只不过换了一种描述方式而已,所以还是作为product backlog的一部分吧。



            前面我一直在提“功能”二字,没有提非功能的需求,如果有非功能的需求怎么办?两种处理办法,一是如果能明确到某个故事,就描述在故事的验收标准中,二是写一个“技术故事”,单列出来,提醒开发人员注意这些故事,这个故事未必是product owner提出的。


             对于用户故事我们希望能达到如下的理想:

             1独立性。尽可能避免故事之间存在依赖关系,故事间存在依赖关系会造成划分优先级的困难,在安排开发顺序时需要考虑故事之间的依赖关系。

             2可协商性。故事是可协商的,故事是有弹性的,故事是需要讲的,不是必须实现的书面合同或者需求。

             3对用户或者客户有价值。确保每个故事对客户或用户有价值的最好方式是让用户编写故事。

             4可预测性。开发者应该能够预测(至少大致猜测)故事的规模,以及编码实现所需要的时间。

             5短小精悍。一般一个故事在一个迭代周期内一定是可以实现的,而我们提倡短周期迭代。

             6测试性。所编写的故事必须是可测试的,能够定义出验收标准。

            注意,这是理想!

            Product backlog在项目进展过程中是会发生变化的,只有product owner有权来修改此文档。你可以用EXCEL文件来描述它,也可以采用一些敏捷项目管理的工具来帮助你维护,或者使用一些缺陷的跟踪工具如JIRA之类的,最直观的最朴素的办法是采用不干贴纸,直接贴在办公室的白板上,让大家都能随时看到!









    sprint backlog

    Sprint Backlog就是任务列表,如果映射到传统的项目管理理论中就是WBS(work breakdown structure),而且是典型的采用面向交付物的任务分解方法得到的WBS



    比如有一个Product backlog 条目为:

        作为系统的合法用户,可以通过录入账号和密码登录到系统中。


         为了实现此需求,team member识别出了的任务,进行了工作量的估计,进行了任务了领用,其结果记录为:

    用户故事作为系统的合法用户,可以通过录入账号和密码登录到系统中。

    任务

    估计工作量

    责任人

    任务状态

     1)单元测试程序编写

    30分钟

    郭靖

    完成

     2)界面设计

    20分钟

    黄蓉

    进行中

     3)密码校对算法设计

    30分钟

    郭靖

    进行中

     4)程序调试

    30分钟

    郭靖

    未开始

    此表格是有开发人员基于经验采用头脑风暴的方法大家一起分解得到的,里面列举的任务为了实现该用户故事必须做的事情,按照简化的原则,可做可不做的任务则删除之。估计的工作量是由责任人自己估算的,任务的工作量合计应该不超过用户故事估算的工作量。如果任务拆分后发现工作量的合计远远大于用户故事估计的工作量,则可能需要对用户故事的工作量估算值进行修订。


    Product owner负责基于商业价值挑选某次交付中应该包含的用户故事,而开发人员负责基于开发的风险、用户故事之间的依赖关系等挑选在某次迭代中要实现的用户故事

    Sprint Backlog可以采用Excel、白板或者敏捷的项目管理工具进行维护。

     







    燃尽图

      Burn down chart翻译为燃尽图或燃烧图,很形象,是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint review、sprint retrospective真是越琢磨越有味道的好东西,也因此很喜欢scrum这种方法,这些实践简单有效、经典!

        燃尽图的样例如下:

     

        横坐标为工作日期,纵坐标估计剩余的工作量,每个点代表了在那一天估计剩余的工作量,通过折线依次连接起所有的点形成为估计剩余工作量的趋势线。另外还有一条控制线,为最初的估计工作量到结束日期的连线,一般用不同的颜色画上边的两根线。


        对此图的研判规则如下:

           (1)如果趋势线在控制线以下,说明进展顺利,有比较大的概率按期或提前完工;

           (2)如果趋势线在控制线以上,说明有比较大的概率延期,此时需要关注进度了。

        注意,趋势线并非一直下行,也有可能上行,即发生了错误的估计或遗漏的任务时,估计剩余的工作量也有可能在某天上升了。

        每天开完15分钟站立会议后,由scrum master根据进展更新燃尽图。第1个点是项目最初的工作量估计值,第2个点是第最初的估计工作量减去第1天已经完成的任务的工作量,依次类推计算后续的点。任务完成的标志是什么呢?准则如下:

          (1)开发人员检测:所有的单元测试用例都通过;

            (2)Product owner检测:Product owner通过了所有的功能测试;


        燃尽图最好是张贴在白板上,让每个人项目组成员抬头就能看见,这样给大家一个明确的视觉效果,每个人随时都能看到我们离目标有多远。

        燃尽图可以每天画,表示完成某个迭代的进展趋势,也可以某次迭代结束的时候画,表示完成整个项目的进展趋势,此时横坐标就是迭代的顺序号。

        燃尽图和传统项目管理理论中的挣值图比较起来更加简单、直观,这种设计深得管理的精髓!度量的精髓!真是让人佩服!






    四种会议

       在SCRUM方法中定义了4种会议活动:

             Sprint planning

            Daily meeting

            Sprint review

            Sprint retrospective


        除去开发活动外这4种会议构成了scrum方法的核心活动。

        这四种会议的要点如下:




    展开全文
  • 对于管理严格的项目团队,Scrum会议也会每天都在同一时间进行。通过每日Scrum 会议,团队成员之间可以彼此相互熟悉工作内容,充分了解项目进度,相互帮助解决问题。那么,在Scrum中的Sprint计划会议应当如何进行?...
  • 我们这样做Scrum的评审会议 在实践中,我们发现如果只在Sprint之后再做Demo,由于Sprint过程中沟通不充分,Demo展示的功能很可能不符合客户真正的需求,导致Sprint失败。于是,我们按照优先级和耦合做分组,高...
  • scrum

    千次阅读 2019-02-22 09:38:45
    1、scrum定义以及scrum流行的原因 ...c、五个会议:冲刺计划会、每日站会、评审会、回顾会、代办事项梳理 d、五个价值观:开放、专注、勇气、承诺、尊重 4、DOD 1、scrum定义以及scrum流行的原因 •...
  • Scrum验收会议,是在迭代结束前给产品负责人演示并接受评价的会议,以根据反馈结果,提出新的产品Backlog;Scrum回顾会议,在每个迭代结束后召开的关于自我持续改进的会议。 这些会议究竟怎么开,对项目研发有什么...
  • 本文主要是为了检测你对SCRUM Sprint 计划会议的了解和... Sprint 计划会议非常关键,应该算是 Scrum中最重要的活动(这当然是我的主观意见)。要是它执行的不好,整个 sprint 甚至都会被毁掉。  举办 Sprint计划...
  •  每日ScrumScrum的一个关键组成部分,它可以带来透明性,信任和更好的绩效。它能帮助快速发现问题,并促进团队的自组织和自立。所有Scrum会议都是限定时长的。每日Scrum通常不超过15分钟。下面我谈一谈自己的理解: ...
  • 通过本文你可以检测一下 1、你们的SCRUM Sprint 计划会议的过程和步骤 2、会议的输出结果 Sprint 计划会议非常关键,应该算是 Scrum中最重要的活动(这当然是我的主观意见)。要是它执行的不好,整个 sprint 甚至...
  • Scrum

    2019-10-02 10:54:51
    什么是ScrumScrum 是用于开发、交付和持续支持复杂产品的一个框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议...
  • 参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们。官方网站:http://www.agilemanifesto.org 《敏捷宣言》提出敏捷4条价值观: 1、个人与互动胜过过程与...
  • scrum经验

    千次阅读 2013-09-04 11:35:56
    scrum经验
  • scrum中的四个会议

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

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,141
精华内容 1,656
关键字:

scrum关键会议