什么是Scrum及认证_百度知道
什么是Scrum及认证
每个小的的跌代周期称为一个Sprint。在这个框架中、讨论和估算得到一个Sprint的任务列表，产 品backlog是一个按照商业价值排序的需求列表，使用产品Backlog来管理产品或项目的需求，是一个增量的Scrum是一个敏捷开发框架。Sprint中挑选的需求经过Sprint计划会议上的分 析。在Scrum中。Scrum的开发团队总是先开发的是对客户具有较高价值的需求，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发、迭代的开发过程。 在每个Sprint中，Scrum团队将交付潜在可交付的产品增量。 在每个迭代结束时，我们称它为Sprint backlog ，列表条目的体现形式通常为用户故事，每个Sprint的建议长度2到4周，整个开发周期包括若干个小的跌代周 期
知道智能回答机器人
我是知道站内的人工智能，可高效智能地为您解答问题。很高兴为您服务。
其他类似问题
为您推荐：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁Scrum Master认证培训（-26日史文林第9期）_PMP|PMP培训|PMP考试-现代卓越
当前位置：
Scrum Master认证培训（-26日史文林第9期）
第9期:&&2014年7月25-26日
敏捷是目前最有效的解决软件及产品开发项目中面对的挑战的新思维与方法。这些挑战包括需求的渐进性与不确定性、市场的时刻变化、技术的快速更新、计划赶不上变化、团队过度劳累及缺乏动力与激情、沟通的失效、质量问题及技术债务的累积、项目严重超时超支、无法交付用户及客户真正需要的软件等等。
这是一个2天的敏捷产品开发过程、需求管理及演进的强化集训课程，详细阐述产品负责人（Product&Owner)如何与敏捷开发团队互动和协作，以及如何运用Scrum及相关的敏捷实践在频繁及限时的迭代中快速地交付潜在的可交运软件产品。
本课程综合运用讲座和体验式学习以形成对Scrum框架的真正理解，把重点放在产品定义者、管理者、需求人员及敏捷团队在履行其职责并追求达到高生产力时的实践活动。
本课程适用于IT企业部门经理、项目经理、产品经理、项目团队成员、流程管理人员等；同时也适用于企业信息化，营销，培训等各个业务体系的一般项目管理人员与项目参与实施人员。
oScrum联盟ScrumMaster&CSM认证及&PMI&PMP&PDU&&&ACP&Contact&Hours&
o知名ScrumMaster认证培训师现场授课
o互动性和实操性强，千锤百炼的口碑课程，获广泛推荐
o4星级的场地和服务
（体验式学习及练习，一般是指UPerform游戏、练习、团队活动或模拟仿真等学习方式。在此课程大纲中，只表示了比较大型及主要的eLearning活动。贯穿培训中，将视需要插入一些简短的角色游戏和练习（每次5-10分钟）。另外，课程中会穿插很多的学员问答环节）
一、开场介绍及简单游戏规则
破冰练习：传统问题解决方法&vs.敏捷问题解决方法
小组活动：项目为什么会失败（＃FAIL）
产品项目管理方法-&预定义过程&vs.&实验性过程
二、敏捷定义
2.1&敏捷价值观－敏捷宣言&&&&&2.2&敏捷原则&&&&&2.3&潜在可交付产品增量
三、Scrum的特征
四、Scrum的框架概要
4.1:3个角色&&&4.2:3个工件&&&4.3:5个仪式／时间箱&&&4.4:5个价值观&&&4.5:Scrum框架视图化
练习：打造你自己的Scrum&(Build&Your&Own&Scrum)
五、高效的Scrum,&持续交付价值及价值驱动
练习：敏捷价值游戏；Cycle&Time&&&Lead&Time
六、软件及产品开发中需求管理的挑战
6.1&大盘主义&vs.&小盘主义&&&6.2&产品需求管理及规划中的角色与责任
6.3&为什么叫“Owner”？&&&&&6.4&产品负责人在Scrum框架要素中的角色和责任
七、需求中的质量
7.1&完成的定义（DoD:&Definition&of&Done)&&&7.2&视频：The&IDEO&Shopping&Cart&开发
7.3&Design&Thinking
产品／发布的远景&(Visioning)&及练习
用户角色建模及练习
八、创建产品Backlog及其梳理
8.1&用户故事（Backlog)&及不同层次的需求&&&8.2&编写有效的用户故事&(Backlog)
8.3:3C&原则&&&8.4&&INVEST&原则&&&&&8.5&Backlog的分拆&&&8.6&测试驱动的需求及接受条件
练习：创建有效的产品Backlog；&工具及信息可视化概要
九、需求优先级排序技巧探索
9.1&价值：绝对值vs.&相对值&&&9.2&投资回报（ROI）的考虑&&&9.3MoSCoW
9.4&价值－成本&&&&&&&&&&&&&&&&9.5&Kano&模型&&&&&&&&&&&&&&9.5风险及新知识
练习：Theme&Scoring
十、敏捷计划过程概述
敏捷工作量估算概要
十一、计划一个发布（版本）
11.1&MMF&&&MVP&(Minimum&Marketable&Feature&&&Minimum&Viable&Product)
11.2&速率与容量&&&&11.3&燃尽图／燃上图及进展跟踪
十二、产品负责人探讨
12.1&与利益干系人的协作&&&12.2&与开发团队的协作&&&12.3&价值抽取
12.4&短期及长期&&&&&&&&&&&12.5&技术债务&&&&&&&&&&&12.6&候选人及行为
CRACK（Collaborative,&Representative,&Authorized,&Committed,&Knowledgeable)
最后回顾，以及Scrum及敏捷如何应对项目的失败原因（＃FAIL重访）其他涌现出来的关于敏捷和Scrum的高阶课题。
史文林(Vernon&Stinebaker)先生：CSM,&CSP,&CST&(精通中文)
史先生是Scrum联盟的认证Scrum培训师（CST），具有资格颁发CSM及CSPO认证。
他是一个中国通老外，原籍美国，是中国敏捷和Scrum社区公认的顶级实践者、贡献者和敏捷培训师。
他的专长是敏捷思想和方法（Scrum、FDD、XP极限编程等）、技术领导、软件开发、业务流程管理和再造、商务/运作绩效管理。
他拥有20多年的海内外信息技术产业经验，其中包括10多年在中国领导屡获殊荣的软件工程高层管理工作、IT及组织运营工作。从战略规划到团队组建，通过提供服务及持续的服务管理等业务发展的各个阶段施展经验与才干。在领导力、管理培训、技术实践、咨询和业务发展等发面均扮演成功的角色。
除了敏捷，他也熟知传统过程方法，也是CMMi体系方面的专家，曾经在2011西雅图Scrum&Gathering,&2010、2011上海Scrum&Gathering大会、2010北京系统与软件过程改进大会、2009杭州Scrum&Forum、2010、2011、2012&Agile&Tour等多个行业大会上发表与软件过程相关的演讲。
在中国敏捷领域服务过的知名企业包括：IBM,&Cisco，Sun&Micro中国研究院,&HP，腾讯,&Autodesk,&东软，支付宝，eBao&Tech,&2K&China,&EDS，诺基亚，Virtuos&Games等等。
课程结束后完成注册手续时，每位学员获得Scrum&Alliance颁发的Certified&Scrum&Master证书及2年的联盟会员资格，同时获得PMI的14PDU学分及ACP&Contact&Hours。课程结束后学员将获得课程电子版材料。
线上：组建Scrum&Master学员QQ群作为交流讨论平台；真正能提供全天的网上答疑及辅导服务！
线下：学员依区域分组适时以聚会等方式组织讨论，交流经验，相互促进，增进友谊。
课后：课后将适时联系学员，了解学员复习进度并提醒报考时间
北京丽亭华苑酒店（北京海淀区知春路25号）
地铁：十号线F2口向东300米既是。
截止到2014年6月，现代卓越集团成功举办了8期敏捷Scrum&Master&认证培训，成功取证人数达300余人。
敏捷项目管理适合我们所做的项目，敏捷就是灵活地应对变更。
传统项目管理是：瞄准，射击，击中目标。
敏捷则是：瞄准，射击，调整调整调整，击中目标。
&&&&&&&&只通过Specification来传递需求。活动把每个小组（4-5个人）中的2人留在屋子里，其他人到屋子外面等待。在屋子里的人，会得到一张A4纸，上面画着几个比较简单的图形，比如一个十字，2个套着的圆，一个淡蓝色的六边形，等等。要求，留在屋子里的人不能用绘画的方法，只能用文字，描述这些图形的形状、位置、大小、颜色，并写在纸上。写好后转交给等在屋外的对此还一无所知的人，屋外的人在不许有任何语言交流、肢体动作的情况下，根据屋内人所写Specification，画出原来的所有图形。而整个过程被限定在10分钟内完成。&结果是：在参与活动的3个小组中，没有一个小组能画出全部图形，即使画出部分图形，要么位置不对，要么大小不对。&展示了各组的结果后，大家总结经验教训，想想在哪些地方需要改进，之后进行第二轮。当然，图形跟第一轮完全不同，而且又稍微复杂一些。即使大家吸取了前一轮的教训，改进了方法，但结果还不如第一轮的情况。&这个活动其实在让我们感受一个事实：只用文档（或Specification）来传递需求信息，是非常不准确的和容易被误解的。SCRUM（包括其它敏捷方法）提倡用面对面的交流，而不是通过文档交接正是基于此事实。
&&&&&&& 老师在讲到敏捷合同的时候，举了个对比传统合同和敏捷合同的例子，我觉得不错，可能对那些没有使用敏捷合同但使用敏捷方法开发的公司有用。例子是这样的：对于很多传统合同的签署，情况往往是这样的：客户给出的价格是固定的，比如是5百万，但随着不断地改变需求，造成项目的代价是8百万，而且还可能要不断地修复Bug和完成那些之前并没有真正完成的功能，最终成本是1千万。而敏捷合同的类似这样的：&-&乙方保证交付高质量的、真正完成的功能给甲方。&-&增加2个规则以适应变化：&1.&优先级的改变免费。&2.&可以免费增加新功能，如果等量的其它工作被同时移除。&-&甲方可是随时终止（Abort）合同，终止时，乙方从剩下合同额中返还一部分给甲方。&
&&& 这样的合同体现了2件事情：即Change&for&Free和Money&for&Nothing。&Change&for&Free：当总量不变，增减需求是免费的，这对客户是个好事情。&Money&for&Nothing：当客户在任何时刻认为，所有优先级相对较高的功能都开发完成，剩下的那些没有价值或价值较小的功能不再需要时，可以终止合同。
&&& 终止时客户可以拿回部分（比如80%）剩下的钱（现有使用传统合同的企业，要先从IT公司拿回钱简直是天方夜谭），同时提供产品的甲方也可以拿到另外的20%，而没有任何成本，即所谓的Money&for&Nothing。比如：总合同额为1千5百万，当投资回报率（ROI）降到1/3时终止（也就是用掉5百万后），甲方可以拿回剩下1千万的80%（也就是8百万），乙方可以也可以拿到20%（即2百万）。这是一个双赢的局面。有人经常会说：如果甲方不敏捷，我们怎么能敏捷。我想当甲方理解知道敏捷可以给他带来收益或节约成本后，他是乐于签署敏捷合同的。
附件一：培训报名表
＊PMI登录名
您是否介意把个人信息填写在通讯录发给其他同学
□&&是&&□&&否
□&&是&&□&&否
报名缴费方式
1、现金、刷卡、支票、电汇、邮汇或银行转账均可，请注明项目管理认证考前培训费；
2、学员亲自上门报名；
3、预约后我们的工作人员免费上门报名（限北京市城八区范围）。
开户名称：北京泛华卓越企业管理顾问有限公司
开户银行：建行北京永安支行
北京咨询：程少帅
报名地点：北京市朝阳区建国路号万达广场号楼室，
请将报名表发送到：注：带“＊”为必填
& 010－ 李老师
& 010－ 王老师
& 010－ 马老师
& 010－ 师老师
曾任香港集信、东软集团等知名企业项目经理、实施部经理、项目总监，拥有十多年的项目管理经验，及大型项目监理、咨询经验。从事...现代卓越项目管理集团首席PMP讲师/咨询师；美国PMI会员；500强外企项目经理；PMP/CSM/项目经理/高级软...现代卓越项目管理PMP讲师；资深的项目管理专家；资深的方案架构师和咨询顾问；国内第一批研究项目组合管理与项目群管理的专家...
非常荣幸可以有机会跟大家分享PMP考试的经验，也预示着我的考试通过了。1P4M，这不是一个好的成绩，本也不该在此体现，但...报考PMP的时候是项目过TR5点的时候，晚上加班，周末加班，往往参加培训前还需要去趟公司，发下工作计划安排，培训结...6月份接到卓越顾问的电话，推广PMP，我对电话外呼这种是比较反感的，期间各种不信任各种曲折不表，最后在工作时间比较...
本课程是针对广大测试相关工作学员的现实情况，有针对性的进行辅...主办单位：北京现代卓越管理技术交流中心
支持单位：中国国家...? 作为项目的领导者, 你可能经常被这种现象所困惑: 工作的...中层干部是企业链条中至关重要的一环，是承上启下的中坚力量，更...
||隐私声明|
PMI, PMP, PMBOK and the PMI Registered Education Provider logo are registered marks of the Project Management Institute, Inc.
京ICP备号-1如何实施 SCRUM ？
如何实施scrum？能重点介绍一些要点吗？
按投票排序
如果严格按照书本上的 Scrum 法则一条条地看，那么我们队伍现在的做法也许根本不算 Scrum。不过好歹我们也被称作 Scrum 一段时间了，我的资历比不上前面的资深开发者，只能说一些目前的一点经验。经验一：整个团队必须理解 Scrum 的目的和限制。如果管理团队把 Scrum 当作一种新的管理流程，那么这个理解绝对是错误的，而且有害。要正确理解 Scrum 的实施原则，需要从理解其设计目的开始。我所理解的 Scrum 的目的在于两点：适应变化。Scrum 的一个基本假设，就是外部需求模糊而难以理解。Scrum 对此的理念是：让客户直接看到半成品，他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的：比如每个 Sprint 结束时由 Product Owner 为客户进行展示，又比如任务细化一般不超过一个 Sprint。理解了这一点，才会理解为什么 Scrum 似乎总在变化，因为需求总在变化。快速迭代。Scrum 的另一个基本假设，是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本，而竞争对手半年就能发布，那么几年之内，我们就会被对手甩得远远的。Scrum 对此的理念是：发布即 Milestone（里程碑），宁可每次发布二十个功能发布五次，也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点，才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。要实施 Scrum，整个团队至少必须取得共识，即以上两点是不能商量的。流程必须为目的服务。如果队伍相信增加前期沟通才是让需求清晰起来的最好方法，或者相信发布的功能必须是大批量一次性，那么请使用瀑布开发模式。相应地，我们必须明白 Scrum 不能做什么。我的理解可能耸人听闻，仍是两点：因为发布周期缩短，团队没有能力保证作出的每一个决定都正确，很多开销都必须花在试错上；快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队，因为一个人的离职或病假都可能对单一功能的进度造成影响，不利于短期频繁发布。Scrum 对此的解答是：不要试图不犯错误，而是保证小的错误能被尽快发现从而不会酿成大错。所以 Scrum 过程中总会有些不确定性，或者功能不合需求而返工，或者突然缺了人手导致一些单个功能必须延期完成。如果非要事先确定发布周期而且还得保证不许功能裁剪，请出门左转找 CMM 认证：它可以把任务精确到每个对话框上该用什么字体。前期计划精确到这个粒度，什么都可以在掌控之中。但问题是，我们必须用更长的发布周期来换。理解了上面的内容，我们实施时就不会对某些形式性的东西过于纠结，比如 Burn down chart，比如 Scrum 扑克。需知形式服务于目的，而形式未必适用于每一个团队，正如瀑布模型在每一个团队中也都有差异。如果仅仅是因为团队成员没有在 planning meeting 上打扑克就认定这不是 Scrum，那么未免愚蠢了些。反过来，某些看似烦人的「流程」却不可或缺，比如每天的 15 分钟 stand-up，如果我们明白它对交流方面的重要作用，就绝对不会认为它可以被省略。举个实际的例子，在我们的团队里，我们强迫一周一个 Sprint。就我所知，即使在很多实施很成功的项目中，这种做法也是相当激进的。一开始我也不理解这一点，但实施了一段时间后，我开始认同这一条，因为一周的发布周期让我们没有机会把任务往后推，从而迫使我们尽快从瀑布模型中转移出来。这对一个有着悠久瀑布开发传统的团队来说非常重要，但对别的团队来说，就不一定了。经验二：正确定位队伍中的 Scrum Master。为什么单独提 Scrum Master？如果只是看书本和参加培训，我相信多数人都会同意我的观点，即 Scrum Master 或许是整个开发过程中作用最不清楚的角色：不参与需求分析、不参与代码开发、甚至不参与任何人事问题，只有一句「去除阻碍」这种含糊的表述。但是，当我真正当起这个 Scrum Master 之后，才发现这个角色承担的职责非常具体。比如：确保流程执行正确。进入 Scrum 之后，很多团队仍然会以各种方式走老路，比如有意无意地拉长 Sprint 周期，并以此区别计划周、开发周和测试周，实际上是把原来三个月的瀑布开发周期变成了两到四个星期的瀑布周期；又比如以开发时间有限为理由把自动测试开发任务缩减为手工测试。好的 Scrum Master 应该有能力发现并制止这种情况。——顺便说一句，相信我，不要以为两个星期的瀑布周期是个可行的开发计划，我们不可能完成测试任务的。制止官僚主义流程。典型的例子就是一个又一个的 spec/plan review 和 sign-off 邮件；又比如非要区分所谓 Unit Test、BVT 和 Functional Test：或许对一个图形界面程序来说这两者区别极大，可对于函数库则几乎没有原则差别。合格的 Scrum Master 应该制止这样的倾向。——不过我也得说，这一条我现在做得很差，还需要改进。构建交叉知识结构。整个团队的知识模型应该是各有专长但互有交叉的，而传统开发的一个很重要的问题是知识结构不平衡，比如测试的只管测试，开发的只管开发。这种模式对于发布时间长的大团队来说也许能接受，但对人手短缺又要求快速发布的小团队则是致命的。好的 Scrum Master 应当能够对团队的决策具备影响力，确保不会让某个任务陷入「只有一个人知道细节」的情况。——这一条在习惯了传统瀑布开发模型的团队中往往是最大的阻碍，需要时间改善。但正因为上面的理解，我基本上不同意 Scrum Alliance 的教科书里关于 Scrum Master 的大多数表述。首先，Scrum Master 必须承担一部分开发任务，因为没有介入一线开发，很难想象 Scrum Master 会真正理解团队的「痛点」。其次，Scrum Master 需要关注团队的每一个人，不然队伍可能由于所谓「自组织」的原则而隐藏一些问题，比如某个人过于专精某一项而忽略了和其它成员的交流。当然，也有些部门的 Scrum Master 只负责写报告和推事情。这不是我共事过的任何一位 Scrum Master 的做法，而且我也可以很自信地说，这种 Scrum Master 在我们公司是生存不下去的。Scrum Master，你是肩负着人类使命的人啊！嗯！（握拳）最后，贴两句最近刚学到的话：50% percent of our decisions are wrong. Fail fast, learn fast. （我们作出的决定中， 50% 都是错误的。早早失败，早早学习。）No matter what you want to do, choose what is good for your team.（无论你选择做什么，选择对你的团队有利的事）先声明，说上面两句话的哥们本人在我们队伍里不算很受欢迎，但这两句我很喜欢。在我眼里，这两句话指出了 Scrum 的所有实质。共勉之。
首先当然是需要自己先把Scrum给吃透，至少从理论知识方面先做足准备，这方面有很多不错的书可以先看看，例如小部头的《Elements of Scrum》，中等规模的Ken Schwaber的书例如《敏捷软件开发——使用Scrum过程》、《Scrum敏捷项目管理》等等，以及更大部头的Mike Cohn、Craig Larman他们的书。其次呢，如果想验证自己的知识了解得如何了，可以先做做的免费公开测试题目：。想进一步测试的话，可以选择参加的CSM、CSPO培训课，或者是的PSM、PSPO培训课，课程都有进一步的测试，可以验证自己的知识。此时就可以开始着手在自己的团队内开始尝试了，建议此时不要急着铺开大范围推广，因为Scrum框架本身虽然简单，但能够在实地产生实效，全看调整实施的功力。在开展Scrum方式的过程中，可以多多加入各种敏捷和Scrum的社区和大家交流，大家主要在Yahoo Groups和Google Groups上面讨论交流的比较多；还可以多参加一些本地敏捷社区的聚会活动，见见其他Scrum实践者，和他们多交流交流心得，看看他们是否也有相同的疑问和问题；另外就是，建议参加一些业内大会，如果在上海，可以考虑Scrum Gathering，北京的话可以考虑敏捷中国，其他地区可以考虑敏捷之旅，等等；最后，当然，如果有足够的预算支持，建议邀请一些有经验的实践者参与更深入的交流，或者是聘请外部敏捷咨询师，会很有帮助（我在惠普的时候，我们团队就是专门对外提供敏捷咨询服务的）。最后就是，按照Scrum自身的方式来看待Scrum的开展，通过检验和适应不断地观察开展Scrum的过程和变化，进行相应的调整，即可。
更新，Scrum只是一个过程，最重要的就是不要死守教条，比如Scrum中是可以采用XP的一些方法的，不要因为XP也是敏捷开发的一种，采用了Scrum之后就不用XP了，还有的可以看看teambition这个网站，上文链接就很好地介绍了如何利用teambition来开展scrum。目前好多Scrum的书看起来比较生硬，有些是直接翻译的，有些写的太过形式主义。推荐一本书，叫做《轻松Scrum之旅:敏捷开发故事》，是以前的IBM的人写的，以小说的形式来讲Scrum的，你也可以看一看，希望对你有帮助。
我来分享点拙见。分别在通信行业和互联网行业实践过几年的Scrum，有一些体会。首先，敏捷被很多人和团队视为对传统项目管理的否决，视为不要流程，不要规则的依据。项目管理本身是一门高深的，非常有价值的学问。不懂项目管理的人做敏捷常常做成野鸡流程。Scrum的精华有两点，第一是短迭代，第二是自组织。短迭代让团队可以形成节奏感，并在每个迭代后有机会进行回归，并在下一个迭代中提高。相比传统的瀑布流程，因为缺乏这样的反馈机制，团队的改进相对困难。自组织的目的是让团队对目标进行自我承诺，激发团队最大的能量以达成目标。这是在公司这种权威组织中实行的小规模民主激励。对于自尊心较强的工程师团队，相当有效。不过也有缺点，那就是团队自我意识可能过强，导致跨团队合作出现问题。但如果仅仅实现这两点，Scrum的结果可能是非常糟糕的。特别是短迭代造成两个负面后果：第一，短迭代倾向于产生短期设计，在将来的迭代中需要经常重写。第二，短迭代导致没有时间进行全面的回归测试，导致bug数量上升。为了有效的解决这两个问题，Scrum必须伴随一些关键的工程实践。第一，最重要的，是测试自动化。无论是单元测试还是功能测试，都是在短迭代下保证质量的重要，甚至是唯一手段。第二，重构。有了自动化测试，敏捷团队应该勇敢的不断重构代码，消除技术债务第三，持续集成。有了自动化测试，持续集成可以在最短的时间内报告问题，并要求团队将CI的错误作为最高优先级立即处理。所以可以看出来，自动化测试是scrum最重要的实践之一。一个没有自动化测试的组织，采用scrum虽然也可以受益，但达不到“高绩效团队”的水准。
先泼你一摊冷水吧，实施scrum很困难。无论是对上层还是下层，你都得好好去说服和培训他们，否则，一定做不好！说点我的故事作为反例吧。今年有个项目，管理层觉得需要快，所以对项目经理说要搞Agile。于是发生了下面的事情：项目经理不懂Agile，为了讨好上层，买了一堆白板，贴了一堆的纸条，发了一堆所谓的backlog。没有制定验收的标准，当然项目经理自己也不碰产品，所以也就呵呵了。因为项目经理不懂Agile，所以也就没有做Velocity，也没有严格按照Scrum去分小组搞Daily Update，仍然搞的是Waterfall的全体大会。每天早上都需要耗费1个多小时开会。后期则因为队员投诉太多，会议都取消了，只留下一个一个星期一次的全体大会。因为项目经理不懂Agile，所以没有迭代出build，每次都是为了要给上层Demo才去出一个。当然，那一定是个非常不稳定的build。由于在Waterfall浸淫太深，大部分队员都只会死守自己的那个岗位。开发的不想做测试，也不想跟测试沟通，只想code完且review完就算了。而测试的人因为之前啥技术都不怎么懂，既做不来代码审议，也做不来自动化测试。最大的问题是，公司的整套流程和工具就是为了waterfall而设计的，每次check in，每次review都需要一堆的设计文档，一堆人的review，每个新的特性都得开会开会开会，否则根本不能check in。虽然本公司印度那边的人宣称公司一直是Agile，但是我从来不知道有哪些项目是搞Agile的。对Agile这个词的理解，大部分人都以为敏捷就是快速开发和交付，我只能说呵呵了。Agile不应该被翻译成敏捷，应该翻译成“快速响应与调整”。因为项目经理和部分管理者觉得敏捷就是要“快”，所以搞得经常加班且身心疲倦。如果不能说服管理层敏捷的目的是为了早试错，早反应，早超生的话，我建议还是waterfall吧。上层的人也很少过来抓项目或过来看项目是如何的，虽然上层的人来自某些大公司。哦，还有，我们的敏捷项目可是没有Scrum Master的哦，因为项目经理觉得自己啥都懂，完全都是按照他想的去做的。别的开发经理或者测试经理想插嘴都不行。我的测试经理被挪出了邮件组，每次开会都不叫他。当然最后上层觉得这个项目似乎很混乱，才把测试经理和开发经理加到某些会议去，当然，邮件组还是没有加。哈哈。下面是我的经验总结：如果你的项目是需求已定，且基本相当于copy & paste的，我建议走waterfall，或者学工厂的模式，设置人开发，集成和测试。可别以为这种项目没有哦，我们公司大部分项目就是如此。如果你的人员都不懂Agile，且技能不能交叉的，建议你换血或者精挑某些人，否则会累死你！除非你觉得这些人学习能力都不错。我所遇到的问题就是，测试的不懂开发，开发的不懂测试，配置环境的事情基本没多少人管。去说服上层管理人员，一般上层管理人员对 大词 都是一知半解的，什么大数据啊，什么云啊，什么敏捷啊，他们几乎都是根据营销的数据来 觉得 这个是如何如何的，至于实际嘛，呵呵。找个有权力且聪明的人去做Scrum Master，尤其是在中国的环境下。
在下已多年不参与SP的话题。但见题主求知心切，特将压箱底的法宝倾囊相授与你：最重要的一点：每天早上把你的伙计们弄来站着开会第二重要的一点：找块白板，上面贴满五颜六色的纸条第三重要的一点：把工位隔断统统拆了，买几张长条桌子即可然后你的团队甚至整个企业就敏捷啦，SCRUM啦。从此以后，就可以享受以下福利：一、不用设计、不用建模、不写文档；二、四处参加party、各种网站上发鸡汤、Title升级为XX认证专家；三、就算项目做成狗屎，也跟你无关，因为你已经敏捷了；四、谁要不服，抡起Agile和Scrum大棒就砸。哦，还有最最重要的一点，特补充于后：一定要多拍照片发网上（包括但不仅限于站着开会的码农、白板上的纸条、俩头凑一块儿pair programming、没有工位通铺似的Office、或者team一起开香槟最次也得举个啤酒杯）切记，切记。
建议把Scrum分成两部分，1是Scrum流程，比如计划会议、每日会议、燃尽图、回顾、用户故事、扑克估算等等，2是Scrum团队，三个典型的角色。建议先从Scrum流程开始，然后考虑是否采纳Scrum团队典型角色，不采用Scrum典型角色，也是可以执行Scrum流程的。
任何先进的管理流程和理念都是为了一个目的——节省成本，协调好资源，完成并超出计划目标。Scrum也是一样！
说起来简单，做起来不简单。原因何在？树是一天一天生根发芽，人是一步一步开始走路说话。先进的东西也需要一步一步来，Scrum第一步：掌握Scrum知识
知识是前辈实践总结的条条框框，帮助大家理解的信息Scrum第二步：运用Scrum理论，知识是把一个具体的事情的方法变成抽象的文字，规则；运用则是把抽象的东西作为指导转化成实际中通往成功的方向标。Scrum第三步：外部的指导。有经验的教练指导可以帮助大家少走许多弯路，照猫画虎，照葫芦画瓢道理相通。客观的说：Scrum中文网
——是国内最早最大的敏捷社区，案例
知识，文章等应有尽有。国内的敏捷知识大部分都是从这里获取的。Scrum中文网的教练，国内最多的，20位左右。都是国内外知名企业实战派的大牛。而且该机构服务特别好，培训的学员3万之多，任何一家机构也比不了。都是实战经验特别丰富的，世界500强企业基本都是选择他们所以选择培训的话，
这样的机构，一条龙到位。我比较推荐 他们的
,如有需要可以和他联系: 021-
QQ：Scrum中文网
最重点的是，所有项目干系人都必须理解、接受敏捷的思想。其它那些流程、工具什么的，都是次要的。我所理解、总结的敏捷思想，主要是“看准目标小步快跑”。
这个问题比较大，首先需要知道你和被实施的团队中是什么关系？如果是团队负责人，这个我认为就相对难度小一些，只要你对scrum有较深的理解，相信可以稳步的做好。如果你是团队外部的人，难度就要稍微大一点，你需要对scrum有很深的了解，并且要有实际的实施经验。建议几点：1.明确自己的出发点：实施scrum是为了帮助实施团队解决问题，而不是证明scrum是有用的，站好位置，至少就减少了一大部分难题2.看重差异，了解目前团队中的难题3.通过解决问题的方式，将scrum引入
a）做好松土--对团队成员作知识和理念上的培训
b）建立信心--持续的进行scrum的交流，对团队中遇到的问题进行关注和解决
c）度量价值--做好数据的度量，例如质量变化，计划符合度等等
已有帐号？
无法登录？
社交帐号登录