2012-01-18 11:26:37 dyllove90 阅读数 98
  • 19年录制SpringBoot2.x整合微信支付在线教育网站项目...

    SpringBoot2.x开发在线教育微信支付项目实战,2019年新录制,课程分为11章63节课,从需求评审到设计数据库,编码,单元测试,Nginx集群部署;整合各种正式开发的工作技巧; IDEA工具热部署,Ngrock本地域名映射,数据库逆向工程生成实体类,动态Sql,微信OAuth2一键登录,网页微信扫码支付,JWT微服务登录鉴权,阿里云集群部署,公网域名解析配置,前端页面接口动静分离

    1419 人正在学习 去看看 张颜源

欢迎大家访问我的个人网站 萌萌的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输入

    

 

2016-08-01 11:55:37 phil_code 阅读数 3793
  • 19年录制SpringBoot2.x整合微信支付在线教育网站项目...

    SpringBoot2.x开发在线教育微信支付项目实战,2019年新录制,课程分为11章63节课,从需求评审到设计数据库,编码,单元测试,Nginx集群部署;整合各种正式开发的工作技巧; IDEA工具热部署,Ngrock本地域名映射,数据库逆向工程生成实体类,动态Sql,微信OAuth2一键登录,网页微信扫码支付,JWT微服务登录鉴权,阿里云集群部署,公网域名解析配置,前端页面接口动静分离

    1419 人正在学习 去看看 张颜源

最近负责一个项目,工期较长,涉及方也较多,项目开发测试完后,就到上线阶段,为了控制整个上线过程,整理了一份上线检查表,如下:



由于项目负责人不是代码编写人,程序逻辑肯定没有研发人员清楚,因此,这份表必须是与开发人员开会沟通达成一致输出的结果。

在上线过程中不断检查完成点。

2012-02-09 09:07:22 jingwenjingwen 阅读数 7
  • 19年录制SpringBoot2.x整合微信支付在线教育网站项目...

    SpringBoot2.x开发在线教育微信支付项目实战,2019年新录制,课程分为11章63节课,从需求评审到设计数据库,编码,单元测试,Nginx集群部署;整合各种正式开发的工作技巧; IDEA工具热部署,Ngrock本地域名映射,数据库逆向工程生成实体类,动态Sql,微信OAuth2一键登录,网页微信扫码支付,JWT微服务登录鉴权,阿里云集群部署,公网域名解析配置,前端页面接口动静分离

    1419 人正在学习 去看看 张颜源
这是敏捷开发一千零一问系列的第四篇。(之一,之二,之三,问题总目录)

有一次课程上居然来了一个非开发人员,他是个网站的业务人员,提出了这个问题,并被评为课堂最佳问题之一。

问题
一线业务部门应该怎样具体参与到敏捷开发中来?

答案
方案1:

敏捷开发中有很多活动是需要业务部门参与的,如果没有时间,第一个要参与的事情是“评审会”,就是阶段性验收产品的会议。在会上应该思考产品在实际应用中是否可用,并提出改进意见。

但是要注意改进意见不要急于实现,而是应该询问下一步原来的计划,或许原来的计划更加重要。

如果能在评审会上对产品未来的应用做出一点预测,对之后的迭代会有帮助。

方案2:

如果能选出一个代表,参与到计划会中,对于产品经理难以解答的问题给出补充解答,是一个更好的活动。

各种解答应该具有预见性,因为所谓软件需求,无非是业务需求在软件中的体现。业务需求很少是没有计划就盲目开展的,因此若能提供预见性的解答,对整个产品未来的方向都会有很大的帮助。

方案3:

将业务架构、商业计划转达给开发人员。

技术架构实际上是业务架构的体现,比如360,其业务从最开始就没打算局限于杀毒,所以业务部门就可以提前告诉开发组,当有一天要开发聊天、安全桌面、安全浏览器的时候,开发组并不需要把一个杀毒软件“重构”成一个聊天软件,这是不可能的。

对于产品研发,业务部门若能将市场定位、商业计划、竞争对手等信息充分与开发人员沟通,可以有效地避免闭门造车、缺乏预见性、变更频繁等情况。

方案4:

变敏捷开发为敏捷交付。

敏捷交付是最近的一个热词,其核心是真正地次第地交付产品。

在以往的开发中,比如微软、Nokia,都是做敏捷开发、持续集成的高手,但是他们的产品都不是“敏捷交付”的,都有巨大的版本和断代存在,而销售模式也是工业时代的模式:一次付款,不退不换。

在新兴的企业中,比如腾讯、苹果、Google、Facebook及众多网络游戏,都会感觉到他们的产品不是“一次买来的”,每次使用都可能有所更新(苹果是更新应用),这就叫做敏捷交付。

敏捷交付创造了新型的互动关系,使得“拥抱整个市场的变化”落到实处,而不再是“把可用产品拿给部分用户评价一番”,这将是未来业务架构的趋势。

案例
1. 某银行

在访谈某银行的开发过程时,开发部门抱怨说业务部门的人只能说出零星的功能,而且还经常在变化,导致变更很多。

后来访谈业务部门的时候,业务部门却抱怨说开发部门每次开发的产品都不太符合自己的预想,而且每次增加功能都要“重构”,反应时间较长。

后来又访谈一个“战略规划部”,发现原来业务部门的业务发展,远在一年前就会有详尽的规划,业务部门所提出的零星需求,其实都是基于这些计划产生的。若能与研发部门事先沟通这些计划,开发部门就能充分理解需求的来源、根本目的、未来走向等等客户价值相关的信息,开发出更加好的需求。

战略规划部接受了一个建议:将定期与研发部沟通未来的计划,从而让研发部能看到整个业务的全貌。

实际上在银行这类业务预见性较强的领域,“拥抱变化”不是不断改进核心价值(在互联网则是),而是在确定业务目标的情况下,不断改进具体的实现方法而已。

分析
1. 在很多场景中,业务部门都以“客户”自居(尤其是甲乙方真正的合同关系时),认为摸索、返工这些事情都是开发组的负担,与自己无关(有我)。

但实际上,如果开发混乱,真正受害的无疑是业务人员这些终端用户。因此应该以无我的精神,去帮助那些为自己“交付价值”的开发人员,最终自己也将受益。

2. 从案例中可见,“拥抱变化”和低头走路是两码事

在能看到未来的时候,有时候可以延长Sprint0中做架构的时间,将变化局限于具体业务细化、评审会上改进产品等活动,开发出来的产品反而更好。

人们在“敏捷地”寻找最佳方法的时候,找到的未必是“敏捷的”方法,而是一种相对重型的方法,因为其业务本身是重型的。这是“无住”的一种典型体现。

用副词“敏捷地”来描述敏捷开发的时候,一个问题就成了伪命题:“什么项目(不)适合敏捷?”任何项目,都应该敏捷地寻找最佳方法。
2017-04-01 14:30:30 English0523 阅读数 8236
  • 19年录制SpringBoot2.x整合微信支付在线教育网站项目...

    SpringBoot2.x开发在线教育微信支付项目实战,2019年新录制,课程分为11章63节课,从需求评审到设计数据库,编码,单元测试,Nginx集群部署;整合各种正式开发的工作技巧; IDEA工具热部署,Ngrock本地域名映射,数据库逆向工程生成实体类,动态Sql,微信OAuth2一键登录,网页微信扫码支付,JWT微服务登录鉴权,阿里云集群部署,公网域名解析配置,前端页面接口动静分离

    1419 人正在学习 去看看 张颜源

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

关于开会,日常工作当中各种会议、培训、沟通等都会占用掉大量的工作时间,因此会议贵精不贵多,在最短的时间内达成最有效的决议,这才是一个有成果的好会议。产品团队必然也会面临这样的问题,在敏捷团队内部,除了必要的全员培训外,尽量保持在团队内部只有敏捷的这四个会议,其余的沟通和会议都可以由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的责任,不仅仅是某几个人的责任;最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。

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

2012-03-26 09:26:53 dyllove98 阅读数 2588
  • 19年录制SpringBoot2.x整合微信支付在线教育网站项目...

    SpringBoot2.x开发在线教育微信支付项目实战,2019年新录制,课程分为11章63节课,从需求评审到设计数据库,编码,单元测试,Nginx集群部署;整合各种正式开发的工作技巧; IDEA工具热部署,Ngrock本地域名映射,数据库逆向工程生成实体类,动态Sql,微信OAuth2一键登录,网页微信扫码支付,JWT微服务登录鉴权,阿里云集群部署,公网域名解析配置,前端页面接口动静分离

    1419 人正在学习 去看看 张颜源

注: 开发管理 CheckLists-系列文章是从本人   Iteye博客中移植过来.后续会直接在此更新     开发管理 CheckLists   专栏

本文主要是为了检测你对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输入




<开发管理 CheckLists> by dyllove98 @开发管理 CheckLists 


<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>
没有更多推荐了,返回首页