Rincolor - 知乎互联网欧冶云商产品经理郑州大学电子商务阅读全文0添加评论分享收藏感谢该回答已被折叠 阅读全文01 条评论分享收藏感谢上一页1234...15下一页获得 7162 次赞同如果严格按照书本上的 Scrum 法则一条条地看，那么我们队伍现在的做法也许根本不算 Scrum。不过好歹我们也被称作 Scrum 一段时间了，我的资历比不上前面的资深开发者，只能说一些目前的一点经验。&br&&br&经验一：整个团队必须理解 Scrum 的目的和限制。&br&如果管理团队把 Scrum 当作一种新的管理流程，那么这个理解绝对是错误的，而且有害。要正确理解 Scrum 的实施原则，需要从理解其设计目的开始。&br&&br&我所理解的 Scrum 的目的在于两点：&br&&ol&&li&适应变化。Scrum 的一个基本假设，就是外部需求模糊而难以理解。Scrum 对此的理念是：让客户直接看到半成品，他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的：比如每个 Sprint 结束时由 Product Owner 为客户进行展示，又比如任务细化一般不超过一个 Sprint。理解了这一点，才会理解为什么 Scrum 似乎总在变化，因为需求总在变化。&/li&&li&快速迭代。Scrum 的另一个基本假设，是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本，而竞争对手半年就能发布，那么几年之内，我们就会被对手甩得远远的。Scrum 对此的理念是：发布即 Milestone（里程碑），宁可每次发布二十个功能发布五次，也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点，才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。&/li&&/ol&&u&要实施 Scrum，整个团队至少必须取得共识，即以上两点是不能商量的。&/u&流程必须为目的服务。如果队伍相信增加前期沟通才是让需求清晰起来的最好方法，或者相信发布的功能必须是大批量一次性，那么请使用瀑布开发模式。&br&&br&相应地，我们必须明白 Scrum 不能做什么。我的理解可能耸人听闻，仍是两点：&br&&ol&&li&因为发布周期缩短，团队没有能力保证作出的每一个决定都正确，很多开销都必须花在试错上；&/li&&li&快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队，因为一个人的离职或病假都可能对单一功能的进度造成影响，不利于短期频繁发布。&/li&&/ol&Scrum 对此的解答是：不要试图不犯错误，而是保证小的错误能被尽快发现从而不会酿成大错。所以 Scrum 过程中总会有些不确定性，或者功能不合需求而返工，或者突然缺了人手导致一些单个功能必须延期完成。如果非要事先确定发布周期而且还得保证不许功能裁剪，请出门左转找 CMM 认证：它可以把任务精确到每个对话框上该用什么字体。前期计划精确到这个粒度，什么都可以在掌控之中。但问题是，我们必须用更长的发布周期来换。&br&&br&理解了上面的内容，我们实施时就不会对某些形式性的东西过于纠结，比如 Burn down chart，比如 Scrum 扑克。需知形式服务于目的，而形式未必适用于每一个团队，正如瀑布模型在每一个团队中也都有差异。如果仅仅是因为团队成员没有在 planning meeting 上打扑克就认定这不是 Scrum，那么未免愚蠢了些。反过来，某些看似烦人的「流程」却不可或缺，比如每天的 15 分钟 stand-up，如果我们明白它对交流方面的重要作用，就绝对不会认为它可以被省略。&br&&br&举个实际的例子，在我们的团队里，我们强迫一周一个 Sprint。就我所知，即使在很多实施很成功的项目中，这种做法也是相当激进的。一开始我也不理解这一点，但实施了一段时间后，我开始认同这一条，因为一周的发布周期让我们没有机会把任务往后推，从而迫使我们尽快从瀑布模型中转移出来。这对一个有着悠久瀑布开发传统的团队来说非常重要，但对别的团队来说，就不一定了。&br&&br&&br&经验二：正确定位队伍中的 Scrum Master。&br&为什么单独提 Scrum Master？如果只是看书本和参加培训，我相信多数人都会同意我的观点，即 Scrum Master 或许是整个开发过程中作用最不清楚的角色：不参与需求分析、不参与代码开发、甚至不参与任何人事问题，只有一句「去除阻碍」这种含糊的表述。但是，当我真正当起这个 Scrum Master 之后，才发现这个角色承担的职责非常具体。比如：&br&&ol&&li&确保流程执行正确。进入 Scrum 之后，很多团队仍然会以各种方式走老路，比如有意无意地拉长 Sprint 周期，并以此区别计划周、开发周和测试周，实际上是把原来三个月的瀑布开发周期变成了两到四个星期的瀑布周期；又比如以开发时间有限为理由把自动测试开发任务缩减为手工测试。好的 Scrum Master 应该有能力发现并制止这种情况。——顺便说一句，相信我，不要以为两个星期的瀑布周期是个可行的开发计划，我们不可能完成测试任务的。&/li&&li&制止官僚主义流程。典型的例子就是一个又一个的 spec/plan review 和 sign-off 邮件；又比如非要区分所谓 Unit Test、BVT 和 Functional Test：或许对一个图形界面程序来说这两者区别极大，可对于函数库则几乎没有原则差别。合格的 Scrum Master 应该制止这样的倾向。——不过我也得说，这一条我现在做得很差，还需要改进。&br&&/li&&li&构建交叉知识结构。整个团队的知识模型应该是各有专长但互有交叉的，而传统开发的一个很重要的问题是知识结构不平衡，比如测试的只管测试，开发的只管开发。这种模式对于发布时间长的大团队来说也许能接受，但对人手短缺又要求快速发布的小团队则是致命的。好的 Scrum Master 应当能够对团队的决策具备影响力，确保不会让某个任务陷入「只有一个人知道细节」的情况。——这一条在习惯了传统瀑布开发模型的团队中往往是最大的阻碍，需要时间改善。&/li&&/ol&&br&但正因为上面的理解，我基本上不同意 Scrum Alliance 的教科书里关于 Scrum Master 的大多数表述。首先，Scrum Master 必须承担一部分开发任务，因为没有介入一线开发，很难想象 Scrum Master 会真正理解团队的「痛点」。其次，Scrum Master 需要关注团队的每一个人，不然队伍可能由于所谓「自组织」的原则而隐藏一些问题，比如某个人过于专精某一项而忽略了和其它成员的交流。当然，也有些部门的 Scrum Master 只负责写报告和推事情。这不是我共事过的任何一位 Scrum Master 的做法，而且我也可以很自信地说，这种 Scrum Master 在我们公司是生存不下去的。&br&&br&Scrum Master，你是肩负着人类使命的人啊！嗯！（握拳）&br&&br&&br&最后，贴两句最近刚学到的话：&br&&ol&&li&50% percent of our decisions are wrong. Fail fast, learn fast. （我们作出的决定中， 50% 都是错误的。早早失败，早早学习。）&/li&&li&No matter what you want to do, choose what is good for your team.（无论你选择做什么，选择对你的团队有利的事）&/li&&/ol&先声明，说上面两句话的哥们本人在我们队伍里不算很受欢迎，但这两句我很喜欢。在我眼里，这两句话指出了 Scrum 的所有实质。&br&&br&共勉之。
如果严格按照书本上的 Scrum 法则一条条地看，那么我们队伍现在的做法也许根本不算 Scrum。不过好歹我们也被称作 Scrum 一段时间了，我的资历比不上前面的资深开发者，只能说一些目前的一点经验。 经验一：整个团队必须理解 Scrum 的目的和限制。 如果管理…
其实就是基于一种假设：团队工作量是可以拆成一个一个基本单元的——即标准工作量。&br&实际使用当中，使用费波那希序列更多的意义在于此种思想的贯彻，而非一种标准。&br&就比如说8以上的部分，则更多的是象征意义——告诉大家太大了需要拆分了。&br&至于8以下的部分，还真不一定需要硬按着数列来，我认为是可以调整的。
其实就是基于一种假设：团队工作量是可以拆成一个一个基本单元的——即标准工作量。 实际使用当中，使用费波那希序列更多的意义在于此种思想的贯彻，而非一种标准。 就比如说8以上的部分，则更多的是象征意义——告诉大家太大了需要拆分了。 至于8以下的部…
请参看Martin Fowler网站上的一篇详细的关于站立式会议的文章
&br& &a href=&///?target=http%3A///articles/itsNotJustStandingUp.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/articl&/span&&span class=&invisible&&es/itsNotJustStandingUp.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
&br&&br& 楼上提出的“.明确说明这个会大家只说三个问题， 我今天做了什么，将要做什么，有什么障碍”不够准确。应该说“昨天我完成了什么，今天我计划完成什么，什么让我的计划Delay了”，这里边的关键是：每个团队成员昨天对一个计划进行承诺，今天回顾下计划是不是按时完成的，进一步承诺今天的计划，如果延误了该怎么办，需要团队帮助么？
&br&&br& 站立会议是一个成员和团队分享项目状态的机会而不是向项目经理汇报
请参看Martin Fowler网站上的一篇详细的关于站立式会议的文章
楼上提出的“.明确说明这个会大家只说三个问题， 我今天做了什么，将要做什么，有什么障碍”不够准确。应该说“昨天我完成了什么，今天我计划完成什么，什么让我的计划Del…
不可行，希望大家好好理解下为何scrum整个方法论上要把这两者分开。对于产品经理代码的product owner和scrum master完全是各自代表的不同利益，本身是处于一直矛盾关系的，如果是同一个人都兼顾做了代理的就是各种无原则的坚持或妥协。这和大型项目里面开发和测试岗位必须分离是一个道理。&br&&br&对于产品经理代表的是客户的利益，重点是保证做正确的事情，保证做出来的东西是客户想要的，因此产品经理是客户驱动的，对客户任何的需求变化和产品优化他们的唯一想法就是尽快的传递到开发实现团队并尽快实现，这种对scrum迭代开发过程势必造成影响和失去控制。&br&&br&对于scrum master更多的是项目管理和项目目标型的，即按照一定订好的sprint backlog，按照项目目标完成一个迭代的交付。其它所有的干扰因素和条件，一旦sprint backlog确定了就必须要保持稳定性，保持开发团队尽可能的少受到干扰，否则项目目标无法按计划实现，也打乱了整个节奏。即使是需求出现变更和优化，对于scrum master的思路也是只有在下个迭代去解决。
不可行，希望大家好好理解下为何scrum整个方法论上要把这两者分开。对于产品经理代码的product owner和scrum master完全是各自代表的不同利益，本身是处于一直矛盾关系的，如果是同一个人都兼顾做了代理的就是各种无原则的坚持或妥协。这和大型项目里面开发…
已有帐号？
无法登录？
社交帐号登录
1800 人关注
1601 人关注
212 条内容
101 条内容Scrum扑克_百度百科
声明：百科词条人人可编辑，词条创建和修改均免费，绝不存在官方及代理商付费代编，请勿上当受骗。
《Scrum扑克》是一款生活实用类软件，支持Android 1.6。
Scrum扑克运行环境
支持Android 1.6
Scrum扑克应用类型
生活实用类软件
Scrum扑克应用介绍
Scrum Planning时，各个Team member使用打牌的方式对story进行时间估算，时间长了纸牌总是会丢失，还老是忘记带牌。本应用用于取代纸牌。自日起Scrum中文网所有内容迁移到新版网站，
一、估算和计划工具
Scrum团队通常使用估算扑克进行工作量的估算和计划。
什么是估算扑克？
使用估算扑克来做工作量估算是最有效，也是非常有趣的一种估算方式。估算扑克由一组类似斐波纳契数列的数字组成，这些数字包括：0，0.5,1,2,3,5,8,20,40,?,∞, 每幅扑克有四组这样的数字，可供4个人使用。
通过Scrum中文网您可以获得两种形式的估算扑克：
1. 使用Scrum中文网手机版估算扑克
如果您使用智能手机，并安装了微信，请关注Scrum中文网微信公众账号便可以使用Scrum中文网微信版估算扑克，具体使用方式，请关注后发生help给Scrum中文网微信公众账号。
Scrum中文网二维码名片如下：
2.& 购买纸质版估算扑克
每幅扑克30元，购买请联系 021 - &,
付款方式：银行转账，提供正规发票
上海浦东发展银行九江路支行 帐号: 00 0152 9 户名: 雪鸟企业管理（上海）有限公司
付款请注明： 用途： 购买估算扑克，付款人名称
估算扑克的使用方法：
1.每个团队成员拿到一组卡片，包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共计12张。2. 产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问。3. 团队讨论这个条目。4. 当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌，估算结果不能告诉其他人，出牌时数字朝下扣在桌面上。5. 所有人都出牌之后，阅读者向大家确认是否都已经确定估算结果，确认后，数”1,2,3",大家同时展示估算结果。6.团队评估不同的估算结果.我们是否想法一致？我们是否存在分歧？有没有什么是我没有考虑到的？团队共同讨论估算的差异，最终达成一致。7. 回到第二步，开始估算下一个条目。&&为什么要使用估算扑克来做估算&有人可能会问，在传统的做法中，我们一般是让一个专家或者项目经理来做估算，给出结果，然后团队照做就可以了，多个人都参与估算不是浪费时间吗？&使用估算扑克来做估算基于两个结论，第一：团队的智慧要高于某一个人的智慧。第二：真正参与工作的人做出的估计要高于其他人做出的估计。&估算扑克有效还有如下几个方面的原因：1.&传统估算通常是一个人在思考，而使用估算扑克估算时，鼓励跨职能团队的多个团队成员参与估算，团队成员可以从不同的视角来思考和分析问题，估算的过程中考虑的更加全面、估算也更加准确。2.&在估算的过程中，团队对估算的结果进行讨论和评判，在一个高度透明的环境下，估算的结果更加真实和客观。这样也避免了很多时候过于武断，或是拍脑袋做出的决定。3.&估算的过程也是一个知识分享和学习的过程，对某一个条目不清楚的成员通过其他成员的阐述会增加对该条目涉及到的要点的认识。
全国咨询热线：400 - 696 - 6280， Email：地址：上海市杨浦区五角场国宾路18号万达广场A座21楼2137室 联系电话：021 - &&传真：021-& 邮编：200433Copyright (C)
&&& Scrum中文网 上海享知信息科技有限公司 &本站文章与其它资源未经允许禁止抄袭或转载!}