温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
学会享受生活
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
阅读(832)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_',
blogTitle:'Scrum 每日立会，应该做些什么？',
blogAbstract:'
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}改变Scrum的每日站会（Daily Scrum）-译 - 推酷
改变Scrum的每日站会（Daily Scrum）-译
本文讲述了改变Scrum每日站会的一个小故事。我们从典型的以人为中心转变到以Sprint Backlog里的故事为中心。这个想法来自于Jeff Sutherland的一篇论文。
本文的目的是简要描述我们为什么和怎样进行每日站会的变化，它的优缺点，以及我们得到的反馈。在开始之前，先介绍一下背景。
团队已经采用Scrum和每日站会，也有Product Owner（PO）角色。
何时何地出现了改变每日站会的需求？
改变的需求来自于团队的回顾会议。
在改变之前，每日站会按照标准的方式进行。每个团队成员将回答3个经典问题： 1）昨天我完成了什么？2）有什么障碍？3）今天我将要完成什么？ 当一个人完成后，下一个人继续。这种方式关注正在说话的每个团队成员。
几个月（许多迭代）之后，许多人抱怨每日站会效率低。基于大家对于这种效率低的原因的反思，团队达成结论，每日站会本身的这种方式可能导致了效率低。
提出什么行动计划？
我们读过Jeff Sutherland的论文
&并且非常喜欢关于改变每日站会的提议。Jeff提议在每日站会上检查Sprint Backlog中每个故事的功能，而不是每个团队成员的。作为教练，我留意到这篇论文，或许团队有兴趣学习一下。事实上，团队很高兴有这个提议，于是团队落实了行动计划，以在下一个迭代来验证这个变化。
这个改变是如何执行的？
在接下来的迭代中，团队在相同的地方开始每日站会，但是这次是基于Sprint Backlog中的每个故事回答3个经典问题。也就是说一个以上的团队成员（取决于几个人参与这个故事）都会说围绕着具体的故事他们完成了什么，将要完成什么，是否存在障碍，以及完成这个故事还需要什么。直到手上这个故事所有相关的问题都解决了，团队才会继续进行下一个。这个流程持续到Sprint Backlog中最后一个故事讨论完。需要注意的是，建议从最重要的故事开始，按照重要性的降序继续讨论。
这个改变带来什么好处？
假设PO参与每一次的每日站会，这个方法可以让PO听到团队关于产品开发的进展——比如，这个方法面向的是产品，而不是谁完成了什么。重要的是正在开发的产品，以及在Scrum中，团队整体执行开发工作。从概念上，我们说团队工作是一组有共同目标（愿景）的人在高度协作的环境中工作。
改变的结果是，团队的效率几乎马上得到提升。假设这是由于这样的事实导致的，当讨论故事的时候参与的每个人都发言，从而提高了专注力。相比之下，传统的每日站会经常有干扰。比如，如果两个开发人员做同一个故事，团队不得不等到两个人在不同的回合中都说完了，才能充分地理解这个故事过去和将来的行动。
更重要的是，对故事专注力的改变，需要整个团队强化正在构建产品的知识，因此现在团队专心在产品上，而不是开发人员的任务。
每个开发人员说话不做限制的事实，允许其他团队成员（他们可能在自己的故事中受阻，或只是完成了一个故事）尝试一起合作关掉正在讨论的故事，而不是去认领一个新的故事。
这个改变的缺点是什么？
大家都知道，在接下来的回顾会议中我们分析了这样的流程改变，为了识别出优缺点。在这个案例中，观察到的主要缺点是，它很难检测到团队成员是否在工作。现在的每个站会中，讨论围绕着故事，而不是每个人在做什么。因此，团队成员必须更积极主动处理这种“闲置”的状态。
同样的，当团队成员非常忙碌的时候，可能也不是那么明显。
作为教练，假设这迫使团队需要更多更好地自组织的话，我的观点是这个缺点可以转化为机会。每个人负责有效地利用自己的时间。每个人负责查看开发流程是否停滞。而且每个人负责决定为了前行而如何一起工作。事实上，参加改变的团队发现一个方法来减轻这个缺点。比如，团队修改仪表盘，因此，查看流程中的每个团队成员的情况更容易。
关于这个改变有数据吗？
通过调查我们收集到一些数字和指标：
团队A1有3个成员，团队A2有4个团队成员，两个团队共用一个ScrumMaster
团队B1有7个成员和1个ScrumMaster
团队C1有4个成员和1个ScrumMaster
根据上述数据，我们可以分析有多少人直接参与。总有有26个人：4个PO，18个团队成员和3个ScrumMasters。每个人的问题是：假定每日站会的这个改变，最符合下面哪条
： 专注，勇气，或者承诺 ？调查结果如下图：
基于上面给出的数字，我想突出观察到的第一手资料，这种方式工作的团队使Scrum里面关于“团队”的概念更具体。也就是说，每个人都被真正地激励并以可持续的方式工作。每个人都认识到“集体的力量大于个人”。Scrum的目标就是尽可能早的交付高质量的产品增量。
尝试改变，观察结果，从结果中获得认知，再次改变！如果有些事搞砸了，尽早的失败比以后的失败要更重要！
原文链接：
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。
Scrum的特性
　　Scrum是一个包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。
　　在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（product backlog）， 产品订单是按照优先级排列的要完成的工作的概要的需求。哪些订单项会被加入一次冲刺由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。
　　管理Scrum过程有很多实施方法，从白板上的即时贴到软件包。Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入。
Scrum中的角色
　　Scrum定义了许多角色，根据猪和鸡的笑话分为两组，猪和鸡
　　一天，一头猪和一只鸡在路上散步，鸡看了一下猪说，“嗨，我们合伙开一家餐馆怎么样？”，猪回头看了一下鸡说，“好主意，那你准备给餐馆卖什么呢？”，鸡想了想说“餐馆卖火腿和鸡蛋怎么样？”，“我不这么认为”，猪说，“我全身投入，而你只是参与而已”
　　猪 是全身投入项目和Scrum过程的人； they are the ones with &their bacon on the line.&
　　产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写 用户故事，排出优先级，并放入产品订单。Scrum主管（或促进者）Scrum主管促进 Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。Scrum主管确保Scrum过程按照初衷使用。Scrum主管是规则的执行者。开发团队负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开发者等）组成的小团队完成实际的开发工作。。
　　鸡角色并不是实际Scrum过程的一部分，但是必须考虑他们。 敏捷 方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。
　　用户软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”利益所有者（客户，提供商）影响项目成功的人，但只直接参与冲刺评审过程。经理为产品开发团体架起环境的那个人。
　　在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：
　　会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶鸡玩具）欢迎所有人参加，但只有&猪&可以发言。不论团队规模大小，会议被限制在15分钟。所有出席者都应站立。（有助于保持会议简短）会议应在固定地点和每天的同一时间举行。在会议上，每个团队成员需要回答三个问题：
　　今天你完成了那些工作？明天你打算做什么？完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）
　　每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。
　　Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。
　　Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了经验方法– 承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。
　　产品订单（product backlog）是整个项目的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要创建的什么产品。产品订单是开放的，每个人都可以编辑。产品订单包括粗略的估算，通常以天为单位。估算将帮助产品负责人衡量时间表和优先级（例如，如果&增加拼写检查&特性的估计需要花3天或3个月，将影响产品负责人对该特性的渴望）.
　　冲刺订单（sprint backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。
　　燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。燃尽图可以使'冲刺(sprint)'平稳的覆盖大部分的迭代周期，且使项目仍然在计划周期内。
自适应的项目管理
　　以下是一些Scrum的通用实践：
　　客户成为开发团队中的一部分。（例如客户肯定对开发的结果真正感兴趣。）和所有其他形式的敏捷软件过程一样，Scrum有频繁的包含可以工作的功能的中间可交付成果。这使得客户可以更早的得到可以工作的软件，同时使得项目可以变更项目需求以适应不断变化的需求。频繁的风险和缓解计划是由开发团队自己制定。– 在每一个阶段根据承诺进行风险缓解，监测和管理（风险分析）。计划和模块开发的透明 – 让每一个人知道谁负责什么，以及什么时候完成。频繁的利益所有人会议，以跟踪项目进展 – 平衡的（发布，客户，员工，过程）仪表板更新 –
利益所有者更新 – 你必须拥有预警机制，例如提前了解可能的延迟或偏差。没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会受到惩罚。在工作场所和工作时间内必须全身心投入。– 完成更多的工作并不意味着需要工作更长时间。
　　下面是Scrum用到的术语:
　　产品负责人 Product Owner： 负责维护产品订单的人，代表利益相关者的利益。
　　Scrum主管 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
　　开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。
　　产品订单 Product Backlog：按照优先级排序的高层需求。
　　冲刺订单 Sprint Backlog：要在冲刺中完成的任务的清单。
　　冲刺燃尽图 Burndown Chart：在冲刺长度上显示所有剩余工作时间逐日递减的图，因整体上总是递减而得名。
　　计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
　　每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。
　　评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。
　　反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。
　　冲刺 Sprint: 一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所承诺的一组订单项的开发。
Scrum其他领域的应用
　　虽然Scrum最初只应用于软件开发，它也可以被成功地应用于其他产业。现在Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的，增量的过程。
Scrum用于产品开发
　　将Scrum应用于产品开发是在《&T新新产品开发游戏&》（哈佛商业评论 6, 1986年）第一次提出，之后野中郁次郎和竹内弘高合著的《&创造知识的企业&》（牛津大学出版社，1995年）进行了详细的阐述。今天Scrum被用于开发金融产品，互联网产品，以及医药产品。
Scrum营销项目管理方法
　　由于市场营销通常以项目的方式运作，许多一般项目管理的原则应用在市场营销上。市场营销也可以像项目管理技术那样进行优化。 以Scrum方法进行市场营销被认为有助于克服市场营销经理们所遇到的问题。短时和固定的会议对于小的市场营销团队来说很重要，这是因为团队的每一个成员都可以了解其他人在做些什么，以及整个团队在朝着什么方向前进。Scrum在市场营销中应用可以：
　　在早期发现可能的问题，可以更快地，最小损失地应对问题。 根据Scrum的主要原则 “没有问题被扫入地毯下”，Scrum鼓励每一个团队成员描述他所遇到的困难，而这个困难可能会对整个团队的工作造成影响。降低财务风险。 在每一个冲刺周期的开始，企业所有者可以不付出任何代价的改变任何市场营销的因素：包括增加投资以夸大顾客数量，减少投资直至未知风险被减轻，或用于支持其他活动。使得市场营销计划更灵活。采用冲刺的短期市场营销计划可以更加有效。如果一种促销方法在冲刺过程中显示无效，市场营销经理有机会将其换成另一种促销方法。向每一个团队成员说明每一个小的，但重要的任务的交付时间也变得更容易。使得客户以不同的方式参与。
基于Scrum的项目管理软件
　　禅道项目管理软件，也称ZenTaoPMS，是为了解决众多企业在管理过程中出现的混乱，无序的现象，开发出来的一套项目管理软件。它集产品管理、项目管理、测试管理于一身，同时包含事务管理、组织管理等诸多功能，是中小型企业项目管理的最佳选择！
　　ZenTaoPMS基于国际流行的敏捷项目管理方式——Scrum，同时也融合了PMP中的很多概念，完美地体现了Scrum中迭代开发的精髓，很好地融合了燃尽图的概念。ZenTaoPMS基于LGPL协议，企业或者个人都可以免费获取禅道项目管理软件的源代码并安装使用，并可以结合自己的实际需要进行修改。禅道在遵循SCRUM管理方式基础上，又融入了国内研发现状的很多需求，比如bug管理，测试用例管理，发布管理，文档管理等。因此禅道不仅仅是一款scrum敏捷项目管理工具，更是一款完备的项目管理软件。基于scrum，又不局限于scrum。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1941914次
积分：22162
积分：22162
排名：第248名
原创：142篇
转载：997篇
评论：248条
(6)(9)(7)(13)(10)(27)(6)(15)(15)(57)(41)(7)(5)(6)(12)(21)(47)(32)(1)(28)(1)(23)(49)(35)(25)(60)(99)(36)(108)(45)(30)(7)(15)(1)(18)(62)(3)(53)(1)(8)(9)(9)(9)(22)(7)(15)(1)(11)(3)(9)Scrum完整流程框架（草稿阶段）：
我的图书馆
Scrum完整流程框架（草稿阶段）：
Scrum完整流程框架（草稿阶段）：&&
23:08:24|&&分类：
Importance
Initial estimate
How to demo
·“Importance”项只能由产品负责人决定；
·“Initial estimate”项只能由团队决定，可以在“评估会议”中由团队讨论决定；&
关于编制产品Backlog的一些说明：
可以参考以下流程来编制产品Backlog：
1.针对产品编制几个较大的产品Backlog，可以较笼统，几个较大的产品Backlog组成一个完整的产品。比如，手机短信软件，大的Backlog可以笼统划分为发送短信、接收短信和查看短信等。
2.针对每个较大的产品Backlog进行二次划分成若干较小的产品Backlog，比如发送短信可以划分成可以群发、可以单发、可以转发等。
3.针对每个较小的产品Backlog三次划分为若干任务。比如新建短信、输入、编辑、发送、存储等。
//————————————————————————————————————————
（2）全员会议（评估会议）
·由产品负责人向团队所有成员详细介绍产品（以客户角度描述产品及其用途等）；
·由产品负责人介绍产品中会涉及到的技术或产品的（已有）技术框架，产品的（新）开发框架也可以由团队Leader讨论制定；
·由产品负责人介绍产品的Backlog（包括详细用例）；
·由团队讨论，每个Story的Initial estimate；
&&（注意：此处无须每个人都要对每一个Story做出评估，只是可能会执行或有能力执行某个Story开发的成员针对此Story进行评估，如果针对一个Story，几个可能参与开发的成员评估的时间不同，将进行一个小型的讨论，重新评估；如果某个Story无人对其评估，那么这个Story将成为一个潜在的问题Story，因为在开发过程中可能会出现无人执行的风险；同时根据对每个Story进行评估的成员数量，可大概预测哪些Story具有普遍性，即相对容易执行，哪些Story具有专属性，即只有专门的成员能够开发，这就需要在必要的时候进行硬性的任务分配，因为有些专属性较强的任务可能都是要由一个成员执行，那么就要把其他具有普遍性的任务交由其他成员执行，同时注意对整个周期开发计划的依赖性持续关注。）
·由Scrum Master制定Sprint周期以及估算团队的生产率；
·定义“完成”，并达成共识；
·明确产品的设计结构；明确组织人员的设定（成员的技术特长，成员是否有开发侧重，团队成员技能如果不能满足产品开发所有技术，由谁去弥补）；明确团队针对产品开发采取的开发模式和开发方法，以及需要完成的一些准备工作；
注明：除产品负责人以外，其他人也可以向产品Backlog（故事列表）中添加故事，但必须经过团队讨论以及产品负责人认可，且无权设置故事的重要性及优先级。
考虑：讨论在第一个sprint周期中（或在项目正式启动前），团队共同开发出一个产品的demo（尽管可能极其简化），并将其作为产品的原型，在以后的开发周期中基于产品原型进行迭代开发。目的在于使团队每个人都可以在周期结束（或任何时候）通过产品的即时demo来检测本周期工作所达到的实际效果。
//——————————————————————————————————————————
（3）Sprint计划会议（第一层迭代）
重要前提：确保产品Backlog的井然有序。包括：
——产品Backlog必须存在。
——对于一个产品而言，只能有一个产品Backlog和一个产品负责人。
——所有重要的Backlog条目都已经根据重要性被评过分。
·制定本次Sprint目标；
·由Scrum及团队讨论决定，把哪些故事（按照优先级的先后顺序）放入本次的Sprint周期中；
·对每个故事进行任务分解；
其他，确定Sprint演示日期，以及确定每日Scrum例会的时间和地点。
//———————————————————————————————————————————
（4）Scrum每日例会（15分钟站立会议）（第二层迭代迭代）
·团队成员总结昨天做的工作，以及遇到的问题，是否需要其他人的帮助；
·团队成员确定今天要做的工作，“领取”任务，并在任务卡片中标识领取人；
·Scrum Master在公示板（白板）上设置每个任务的状态，并根据“燃尽图”检测团队的工作状态以及项目预期；
注明：如果发现某个任务无法在一个人-天内执行完毕，则需要对此任务分解。同时，每日例会的目的是：加强团队交流和信息共享。互相了解彼此都在做什么工作，完成了什么任务。这样，每日的信息传递，可以让每个人可以更多的了解整个项目的业务和技术状况。并且如果在工作中遇到障碍或问题，也可以在这时候提出来，请求大家的帮助（其实，一般在敏捷团队中，遇到问题，都会当场就提出来，或直接去找相关的同事，问他们有没有处理过类似的问题，或者有没有一些建议）；促使每个人在早上做好一天的工作计划。这样，每个人一天的工作就会有明确具体的目标。这会直接提高一天的工作效率。
关于人员绩效考核的一些说明：可以通过以下公式来判定人员在一段时期内的工作绩效，
&&&&&&&&&&&& 任务1 * 重要性 + 任务2 * 重要性 + …… + 任务n * 重要性 = 工作绩效
由于“重要性”一般的浮动区间较大，但为了更好的掌握人员的工作绩效，团队Leader可以对产品Backlog的重要性（由产品负责人制定）的数值按照一定统一规范或标准作出一定的修正，同时也应该允许“工作绩效”有一定的浮动区间。
关于开发队列任务容量限制说明：
在有些团队的项目开发中，开发和测试是分离的，即一些开发人员只负责编写代码，而另一些开发人员则只负责进行测试，那么开发人员和测试人员对彼此的工作进度以及对整体项目的有序管理都有着很大的影响。这样就要严格控制开发任务数量和测试任务数量的衔接，即尽可能保证在任何一段时间只有极少量的已完成代码程序等待测试。可以尝试规定等待测试代码程序的数量限制，当达到上限时，开发人员不能在开发新的代码程序，而是要协助测试人员完成代码测试，减少待测试代码程序的数量。也有的团队有专门进行代码程序集成、部署的工作，那么同样要协调开发队列、测试队列以及集成部署队列中等待任务的数量，分别要规定待开发队列、待测试队列和待集成部署队列中任务的数量上限，以保证在任何开发环节中都不会出现任务堆积现象，保证整个开发流程的顺畅进行。任何一个环节出现了潜在的任务堆积现象，与其上下相关的人员都应该参与解决。（这部分更详细的参考资料可以查阅《敏捷开发资料汇总》中“One day in Kanban land”）
另外补充，如果采用测试驱动编程的话，由于测试和开发几乎是同时由一个开发人员或一组开发人员（结对编程）完成，可以在一定程度上避免发生如上所述的任务堆积现象。
关于严格限制产品负责人参与每日Scrum会议说明：
严格上，产品负责人不允许参加每日Scrum会议，如果有必要，产品负责人在参与每日Scrum会议时必须保证不能作任何发言及表态，不能对开发团队的人员及工作做出任何评价，更不允许提出任何需求或变更。
在每个长周期迭代（比如三个星期）中应该划分若干短周期（比如一个星期），在每个短周期中规定将达到的演示目标。
产品负责人如果对项目产品需求有变更，只允许与Scrum经理直接沟通，Scrum把需求及变更进行汇聚，并由产品负责人制定重要性，Scrum经理会在本次短周期结束时，与团队交流需求和变更，重新制定下一个短周期的计划及演示目标。由Scrum经理与产品负责人沟通变更结果，包括下个短周期的演示结果，以及整个项目进度的延后时间和变更成本，如果客户确认，在下个短周期将执行新计划，否则仍按原计划进行。如果开始新计划，那么团队择时评估本次长周期的最终演示结果，Scrum经理与产品负责人进行沟通。
切记，保证产品负责人（客户）与团队在项目产品开发过程中绝对隔离。
关于敏捷中所谓的“不加班”的一些说明：
所谓的“不加班”，不应该严格的理解为就是排斥一切加班的行为，而应分清加班的诱因或说主导因素。所谓的“不加班”，因时在对每日的工作任务安排中，保证每个人分得（或领取）的任务的工作量为1人-天，这个基本可以确定，因为在前期对Story进行task分割时，即是按照每个task的工作量不超过1人-天进行分割的，所以基本保证了每个人每天所领取的task的工作量最多为1人-天，所以在整个项目的安排上已经排除了“加班”的因素。但是，由于个人原因，而耽误或延长了task的完成时间，那么所带来的后果，就是这个人以加班为代价弥补对效率的损失。即这个加班的行为是项目本身计划之外、由个人原因引起的行为。这个加班就不应该划定在敏捷中所谓的“不加班”的范围中。
//————————————————————————————————————————————
（5）Sprint评审会议（第一层迭代）
·团队成员按产品Backlog中的Story，逐个地介绍这次Sprint的结果，和演示新功能；
·产品负责人可以就新功能或新想法，向Backlog中添加新的Story；
·Scrum和团队成员总结本次Sprint中的问题和经验；
关于在一定程度上增加项目需求（或变动）而不延长整个项目开发周期的说明：
如果产品负责人在项目的开发过程中添加了额外的产品需求，而又拒绝延长项目开发周期，那么在团队本身可以尝试通过以下方法解决：
1.增加团队开发力量，即增加开发人员。
2.提高团队工作效率。因为每个团队的实际工作效率都是介于0-100之间，我们在团队效率评估的初期或许会留有一定的空间，比如我们以结对编程的工作时间为有效工作时间（因为结对编程效率较高且疲劳度高），初期我们可能估计每天每人有4个小时的结对编程时间（以日工作8小时计算），那么团队的工作效率可以看做是50%。当我们必须提高团队工作效率的时候，我们可以规定每天每人有6个小时的工作时间，那么团队的工作效率可以看作是75%。
要注意的是，按照初期对团队工作效率的评估，按照1人-天划分的task，在团队工作效率提高到75%的时候，相同的task则只需要0.75天，此时我们可以对剩下的task进按照75%的团队工作效率进行重新分割，即尽管项目需求增加，但通过提高团队生产率，来确保项目按原开发进度进行。
另外，关于上述两个方法的选择，应该以第2种为主，当团队的工作效率提高到一个所谓的极限的时候，再去考虑采取第1种方法作为对第二种方法的补充。
//————————————————————————————————————————————
（6）Sprint回顾会议
·总结：问题、经验，哪些需要改进的，对问题以及需要改进的工作明确负责人，并由负责人着手进行处理；
//————————————————————————————————————————————
（7）项目整体测试
·按照之前达成的对“完成”的共识，进行验收性测试（软件交付前的黑盒测试）；
发表评论：
TA的最新馆藏[转]&[转]&[转]&[转]&