会议分类

按会议功能分类

全体大会(忽略)

表彰会议(忽略)

餐会(忽略)

培训会议

传达/贯彻会议

领导的意思,思路,想法,精神,要落实下去,情况要传达下去,务求一级一级的能贯彻落实。

进度会议

工作行进过程中,对进度的汇报、知会,可定期召开,也可以根据工作具体情况临时召开。

专题会议

就某一专项问题,把相关人员集中起来,进行讨论,协调并形成解决方案的会议。

例会 定时、定期的工作会议

比如周例会,月度例会,以通报工作情况,讨论解决问题为主。

工作简会

临时因为某件事情,需要马上布置,马上讨论的,三五人招呼到一起,十几分钟就能结束的简短工作会议。

总结会议

某项工作完成之后,旨在对工作进行总结,经验教训整理的会议。

座谈会

以征求看法,听取别人的意见为主旨的会议,比较随便地、不拘形式地讨论。

项目周期分类

项目启动会议

项目启动会议是项目成立以后第一次召开的全体会议,它是项目实施前的内部会议,由项目经理负责筹备和主持,要求所有的项目利益者都应参加会议。(如果没有必要,客户以及主管部门的管理人员可以不参加)。

项目启动会议的目的是,为以后的项目会议树立榜样;为项目成员之间的相互了解和熟悉提供机会,为以后的合作打下基础;使项目成员全面深入地理解项目目标、意义;明确项目经理的权力职责范围;明确项目成员的工作任务、工作岗位和职责范围;统一项目团队及利益相关者对项目的组织结构、工作方式、管理方式等的认识;讨论项目工作的实施规则和项目实施中的管理控制方法;处理团队成员对现阶段工作的意见,并尽可能将其解决。

项目启动会议的内容涉及到项目的基本情况(如目标、意义、规模、完成时间等)、主要成果、管理制度、主要任务及进度安排、项目所需资源的要求以及项目可能会遇到的困难及变化等。

项目情况评审会议

项目情况评审会议是项目管理者获得信息、解决问题以及了解项目进展情况一种方式。召开项目评审会议的基本目的是通报项目进展情况、找出问题和明确下一步的行动计划。

项目情况评审会议的内容涉及到:自上次会议后所取得的成绩,即已实现的项目目标和已完成的项目工作,以及以前会议决定要开展的活动的落实情况;以已完成的任务、实现的实际质量和实际成本等方面的最新信息为基础,与计划指标进行比较,分析各种计划的完成情况;明确项目实际工作和项目成本、质量以及进度方面与计划要求之间的差异,这种差异可能是正的,也可能是负的,找出存在差异的原因;明确项目工作的发展变化趋势,无论这种趋势是如是坏,都必须明确,并在会议上进行讨论,以便项目可以按规定日期完成;根据项目的进展情况和发展趋势,分析预测项目完工日期和完成成本的情况,并结合项目目标和计划进行比较分析,给出预测,各种需要采取的措施,最后要确定出下一步具体的行动计划安排,注明每一项行动的负责人及预计的开始和完成日期。项目情况评审会议应该定期召开,以便及早发现项目进展中存在的问题,防止危及项目目标实现的情况发生.会议同期根据会议的中心议题确定,可以是一周\一个月\一季度\一年。这种会议通常由项目经理主持召开,会议成员一般包括项目项目团队的全部或部分成员以及项目业主/客户或项目的上级管理人员。

项目技术评审会议

不管何种项目都要召开项目技术评审会议,以确保项目业主/客户同意项目提出的技术方案。不同专业领域的项目召开的技术评审会议会有所不同,但大数项目都会召开项目技术初步评审会和项目技术终审会议两种技术评审会议。 项目技术初步评审会议是为了在项目开始之前或项目初期获得客户对设计方案符合技术要求的批准,在项目初期或开始之前,项目承担者完成最初的概念说明、图形或流程图设计后,由项目业主/客户对项目的技术初步方案进行的审批而召开的会议。

项目技术终审会议是为了在项目承担者开始建设、装配和生产项目交付物之前获得项目业主/客户对技术方案的批准,在项目初期或开始之前,项目承担已经完成详细设计和说明、各种图形和报告格式准备妥当之后,由项目业主/客户对最终技术设计方案进行审批而召开的会议。

项目问题解决会议

项目问题解决会议是当项目团队成员发现项目进展中存在问题时召开的会议。在项目开始时,对于该种会议的主持者、参加者及召开时间等都应当设立相应的规章和准则。

项目问题解决会议通常涉及到以下内容:描述和说明项目存在的问题;找出项目问题的原因和影响因素;找出解决项目问题的各种可行方案,并对这些方案进行评价,从中选出最有可能或满意的方案,作为解决项目问题的实施方案;最后,如果所选定的项目问题解决方案涉及计划变更问题,则会议还需要对项目计划进行修订,反之则结束会议。以上各项内容都需要与会者共同讨论,共同分析。

Spring会议类型

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

作者 耿远超 all right reserved,powered by Gitbook该文件修订时间: 2017-10-08 08:11:08

results matching ""

    No results matching ""