京 东 价：
[定价：￥]
PLUS会员专享价
您购买此商品可享受专属价
增值业务：
重　　量：
搭配赠品：
服务支持：
加载中，请稍候...
加载中，请稍候...
加载中，请稍候...
硝烟中的Scrum和XP：我们如何实施Scrum
商品介绍加载中...
扫一扫，精彩好书免费看
京东商城向您保证所售商品均为正品行货，京东自营商品开具机打发票或电子发票。
凭质保证书及京东商城发票，可享受全国联保服务（奢侈品、钟表除外；奢侈品、钟表由京东联系保修，享受法定三包售后服务），与您亲临商场选购的商品享受相同的质量保证。京东商城还为您提供具有竞争力的商品价格和，请您放心购买！
注：因厂家会在没有任何提前通知的情况下更改产品包装、产地或者一些附件，本司不能确保客户收到的货物与商城图片、产地、附件说明完全一致。只能确保为原厂正货！并且保证与当时市场上同样主流新品一致。若本商城没有及时更新，请大家谅解！
权利声明：京东上的所有商品信息、客户评价、商品咨询、网友讨论等内容，是京东重要的经营资源，未经许可，禁止非法转载使用。
注：本站商品信息均来自于合作方，其真实性、准确性和合法性由信息拥有者（合作方）负责。本站不提供任何保证，并不承担任何法律责任。
印刷版次不同，印刷时间和版次以实物为准。
价格说明：
京东价：京东价为商品的销售价，是您最终决定是否购买商品的依据。
划线价：商品展示的划横线价格为参考价，该价格可能是品牌专柜标价、商品吊牌价或由品牌供应商提供的正品零售价（如厂商指导价、建议零售价等）或该商品在京东平台上曾经展示过的销售价；由于地区、时间的差异性和市场行情波动，品牌专柜标价、商品吊牌价等可能会与您购物时展示的不一致，该价格仅供您参考。
折扣：如无特殊说明，折扣指销售商在原价、或划线价（如品牌专柜标价、商品吊牌价、厂商指导价、厂商建议零售价）等某一价格基础上计算出的优惠比例或优惠金额；如有疑问，您可在购买前联系销售商进行咨询。
异常问题：商品促销信息以商品详情页“促销”栏中的信息为准；商品的具体售价以订单结算页价格为准；如您发现活动商品售价或促销信息有异常，建议购买前先联系销售商咨询。
加载中，请稍候...
加载中，请稍候...
加载中，请稍候...
加载中，请稍候...
加载中，请稍候...
加载中，请稍候...
加载中，请稍候...
浏览了该商品的用户还浏览了
加载中，请稍候...
七日畅销榜
新书热卖榜
iframe(src='///ns.html?id=GTM-T947SH', height='0', width='0', style='display: visibility:')在澳洲实施Scrum方法2年感受
等3人欣赏。
团队不大，7个人，再外加一个Project Manager。
为何要Scrum
实施Scrum前，公司搞的基本是很自然地瀑布流程，需求-》设计-》编码-》测试-》发布-》后期维护，很简单。长期存在的问题主要是3个：
1) 需求变得太快导致延迟交付
基本需求由Project Manager说了算。Project Manager又喜欢变想法，有时候脑袋一拍或者和市场一聊天临时起意就要改需求。大家按照他的吩咐开始改文档改设计改代码。结果做的差不多了给他一看他又有了别的想法，最后转到到了客户那里又会变更。非常折磨。
2) 测试人员前期没事后期太累
前期搞需求细化，搞设计文档的时候，测试人员都很闲。因为怕他们闲老板让他们先写测试计划。但是因为需求一直在变，所以计划也赶不上变化。等到了后期有东西可以运行了，测试又忙的半死，呼哧呼哧啊总喊时间不够。
3) 废纸一般的文档
在文档上花费的时间实在太多。公司要求从需求到测试发布一一齐全，但是文档似乎被写出来就不是为了给人看的。测试们不看（他们直接问开发和PM），PM不看（他直接问开发和客户），开发也不看（直接看代码）。最后文档就被默默地扔到一个地方再也没有人关心。
实施中的问题和解决
人都是不愿改变的。
首先是Project Manager不愿意。经常和市场客户打交道的他角色从Project Manager变成了Product Owner。以前只需要随时口头讲一下自己想要什么。现在却必须在每一个Sprint之前参加Grooming会议。一个Sprint通常2周对应的Grooming会议一下就要开4到5个小时。这让他觉得自己做的工作变多了。而一旦Sprint开始，需求就不能轻易改变。这又让他觉得自己的权力变小了，不能动辄就换想法。Sprint结束后的Review客户也会经常参加，这让Project Manager觉得自己的中间人作用被削弱。
开发人员不愿意。以前反正Team Lead让干嘛就干嘛呗，听命令就行了省的操心。现在要自己在Sprint中拿任务。Stand up会每天早晨都要开不说，每个Sprint结束要有Review和Retrospective会。但是以前的每周例会都还保留着，导致会议的数量有增无减。每个Sprint都要经历设计编码测试发布的完整周期，又还没有引入持续集成。这在以前不是问题，现在却要在每个Sprint内重复手工发布，很枯燥也耗费时间。
测试人员不高兴。每个Scprint Release都是Shippable的产品而且还经常变更功能让他们不得不反复进行回归测试和新的功能测试。
实行了3个月后大家纷纷诉苦。Project Manager觉得自己的新角色不能控制Sprint因此自己对进度没有把握。 开发测试人员都觉得干得太累一个接一个的Sprint简直没日没夜了，恨不得每一个Sprint之后都去休病假几天。
另外Sprint是以团队整体来看绩效。但是有的人能力强干得多觉得自己的成绩被别人拉平了担心到时候做绩效评估自己吃亏。
总的来说问题无非三方面：人，流程，技术
人的问题：关键是寻求公司大老板的支持，由他来发声搞定角色的定位问题。首先摆平原来的Project Manager和两个Tech Lead，让他们接受转变。同时也承诺他们在功能划定和排序上的权威性。
然后对开发团队每一个成功的Sprint都会有一点奖励（放假半天+Team Building）。Sprint翻译成中文叫冲刺，但是总是冲刺没有休息就提不上速度了。
虽然Scrum强调的是团体绩效，但是我们每个Sprint结束后还是有一张不公开的表（仅给高层可见）来显示每个人的任务完成量。每个Sprint做最难或者最多任务的开发人员，通常我们让他来在Reivew 会议上来给客户和管理层做演示，一方面让他有被重视的感觉；一方面也增强他的沟通能力为以后进一步发展做潜在铺垫。另外绩效考核方面要将个人对团队贡献比重提高。
流程问题：直接取消Team的例行周会。有Team Building替代足矣。Scrum Retrospective如果Sprint很顺利且团队一致同意，可以跳过不开。
技术问题：我们引入了TDD和CI，使得产品编译发布单元测试执行完全自动化以使得Sprint可以主要集中在编码上，同时也提高了版本健壮性。测试人员被要求和开发人员一起设计Test Case并尽量利用工具自动化测试来减轻工作量。
开始提到的3个主要问题得到了不错的解决。
首先项目的变更和延迟交付问题得到了不错的修正。Product Owner和客户由于可以每2周就看到演示并讨论产品变更，基本上也不会再头脑发热随便干扰Sprint。而客户由于总是不断看到产品的演进和并得到发布的版本，也就不再对延迟问题耿耿于怀。
开发人员的积极性有提高。每一次Sprint Review对主力开发人员也是一次Show off的机会。相对于以前单纯地被分配任务，Self-Organization初见成效。
测试人员的水平则被倒逼出来了。平时不会写程序的人都从纯粹的Tester变成了会写程序的Test Developer。测试的枯燥性有很大的降低。Cross-Functional的感觉有了。
文档被弱化了。因为成员之间联系更紧密沟通更频繁，很多东西不再需要文档化了（本来也没人看）。客户虽然还是要文档的，但是他们由于能够更紧密地参与产品开发周期，对系统已相当熟悉，很多问题也不用再求助文档。
高层支持第一位。至少不能反对。Scrum很可能会削弱/增强某些角色，牵扯到已存在角色的定位和利益。这些事情没有高层来逼迫是万万不行的。
Scrum master其实是弱角色（Servant-Lead)。主要是保证Scrum框架不乱并且Sprint不受干扰。如果全体人员对Scrum抱有坚定信心，此角色可以由开发团队成员轮流兼任即可。
Product Owner需要被激发。他们初期提出的需求经常和宽泛且容易漏掉诸如性能之类的“隐形需求”。所以Grooming非常关键。整个开发团队和Product Ower的讨论能够有效发现并细化需求。Grooming会议开3,4个小时，真的一点都不浪费时间。
设计很重要。没有经验的设计会导致频繁的Refactoring。虽然Scrum标准不反对Refactoring，但是实践中发现会死人（甭管你用多么牛逼的工具）。松耦合，高内聚，可扩展的原型设计很关键。
测试要会开发。测试不能只是单纯点鼠标写文档而要尽量使测试自动化。
没有CI，Sprint的快速迭代式发布就是噩梦。
最后想说的是，Scrum Guide一直强调Scrum是一个“Simple but Extremely difficult to master"的框架，我个人觉得其中很重要的原因是Self-Organized的团队是非常难得的。没有有效激励措施和融洽的氛围来鼓励成员发挥主观能动性，任何框架或者流程都是白瞎。
共25条回复
写得很详细，赞一个。
发现我们项目组现在的流程和Scrum很像~~~
这个流程给我最大的感受是:
对开发，需求确定，要变更也是在sprint结束之后有目的性的变，而不是随客户、PM突然一个想法就变。开发去sprint拿任务，每个requirement都有文档可查，这样可以量化任务，时间久了也不用担心，有据可查。
对测试，工作应该会比以前多，不过也更细一点，sprint多了，得看情况安排回归测试。
对Product Manager，可以更有针对性的制定feature，而且也更有利于深入产品的细节
不同的是，我们feature在确定之后，会由Team Leader再根据开发的实力来分配requirement，相对来说Team Leader会更累点，Project Manager放权给Team Leader。
成功实施Scrum的团队本身就不简单啦，从领导到每一位普通成员都要积极进取才行得通啊。国内不少公司都热过一阵Scrum，但是最终圆满的不多啊。
文档你现在人太少还不会感受到，以前50人团队的时候我就发现文档极端重要。原因如下：
没有详细的文档，就会导致模糊的地方出现开发人员决定实施方式的问题。最简单的比如：这里有一个输入框。具体到这个输入框接受什么，多少个字符，验证不通过应该显示什么，空的时候显示什么都是需要明确定义的。否则产品的品质（或者说情怀，等会儿我吐一下），就会有最差的开发人员决定。
不同人对于某一句话的理解是很随机的，而一个人对于记忆也是很随意的。PM说这里需要一个多选框，他以为是ComboBox，你错误的记成了DropDownList，于是你们就浪费了时间来改正错误，以及无止境的扯皮。
有些时候一些升级维护以及错误修复工具，尤其是上古时代产品，有一个文档解释一下一些奇怪设计的原因你会发现帮助会很大的。
你以后逐渐会发现，Spec不够清晰的情况下有可能出现做着做着会发现我操这个想法不对完全做不下去的情况，所以整个Sprint可能就会彻底失败的情况。其实瀑布和Scrum不是冲突的而是一个正交项，Scrum只不过是把颗粒度切细，力图（或者说试图）在尽可能短的时间里面看到成果而不是有人在做和尚撞钟，有的人则在瞎折腾一会儿这样一会儿那样，有的人则胡吹乱侃马屁火车满嘴跑而已。如果理解成有scrum就不需要文档了，那我只能说有一天你会遇到大问题的。
@ 我是赞同文档重要的。我现在的工作环境确实是人少，才体会到了没文档的速度感。
@ 你要理解当前速度和历史长河里面的速度不是一件事情。就算你用纯瀑布流，省略文档步骤也会在一开始剩下不少时间。但是以后你就知道了，这个擦屁股的事情迟早你是要还的。
之所以说大团队很快遇到，小团队现在可能还好，并不是说人多沟通成本高（当然这也是真的），而是人多速度快。好比远处有个冰山，你开泰坦尼克号一晚上就会出事，你一个人划个橡皮艇大概得要划一两个月。虽然总成本大团队会更高，但是单位成本就不好说了。因为你团队小，划得时间长，回头等发现问题再来回忆当初怎么想的，就好比你想搞清楚女娲补天这个故事是怎么来的一样。
另外，团队小的时候，即便你发现有问题，有可能时间赶你就会糊弄过去。等到时候发现搞不下去了才发现问题已经堆积成山了。大团队有的时候因为出于超大的总体成本，会更容易下决心在当下正确的解决问题。
反正，呃，你自己感受一下吧。也许对，也许不对。
@ 非常感谢。比喻很生动啊。我会谨记并注意的。
@ 经验之谈啊！赞一个，没在50人大团队里干过~不过一个项目时间久了，后来人维护，文档确实很重要
@ 特别是人员岗位有变动时， 没文档， 就不用开工了， 或准备好OT
关于需求的话我们都是开会讨论完的，就是Grooming和scrum review。所以基本上是没有什么正式文档的。只在jira里面有记录。关于软件系统的话直接用代码替代文档了。因为系统不是很大每个人对系统都有一定的了解，所以如果招聘新人的话就直接在找一个人带他。Scrum是非常轻文档的。大项目的话，我从来没有试过Scrum。
@ 我们项目组和你们很像哦，也用类似jira的工具，重要的文档都记录在上面，都是记录比较核心的内容，所以东西不会很多
另外，需求会议开完后我们PM会整理出一份正式文档，开发最终还是根据这份文档来实现feature，这点还蛮好的
本帖有25个回复，因为您没有注册或者登录本站，所以，只能看到本帖的10条回复。如果想看到全部回复，请注册或者登录本站。Scrum团队经历，如何在Scrum中进行风险规避
发表于 13:37|
来源Taoba QA Team|
摘要：Scrum团队经历和经验分享，首先感谢Scrum的技术指导立青对于整个执行的实际应用，以下内容也是根据参与项目情况后的体会和总结学习的分享。
Scrum团队经历和经验分享，首先感谢Scrum的技术指导立青对于整个执行的实际应用，以下内容也是根据参与项目情况后的体会和总结学习的分享。
主要内容划分：
整体流程的选择
各个分支流程的工作内容选择和如何进行风险的预估和快速进度的管理
PD期望的质量保障的效果和结果
测试如何进行PD期望和有效的测试保证
其他优秀总结分享可供参考的内容
首先Scrum的整体流程和过程体系：不多赘述，直接看图，大理论不谈。
每个阶段如何进行项目管理和规范选择以及风险防范和预估，所有事务都是前期投入越充分后期就越顺畅。
（1） PB阶段：描述功能的写法选择，需求写法的确定。确定用户权限要实现的内容，拆粒度的深度
确定迭代的时间进度：2周一个迭代
版本编写：迭代的计划规划
通过对于PD的PRD编写工作的内容：PRD的写法分析见下简图
本迭代选择的方式为用户场景涵盖型，选择原因：技术交叉性不大，主要在于实现用户场景和提高用户体验的功能改善和改进的项目。为了减少和项目成员过多的时间沟通。
产生的效果：需求沟通完全可控，在后期开发过程中的需求沟通和内容确认的时间不超过1个小时。
针对不同的项目的目的和要实现的内容，可以根据不同的优点选择需求的编写方式和撰写风格。
粒度的深度方式选择：期望看到的情况，User Story的形式，然后到task。拆分结果期望是独立的可测试的
User Story要由需求提交者来编写，团队中的任何人都可以是需求提交者、当然产品经理一定是主体；
永远不要在User Story中使用And和Or，因为这些分支词就表示分支任务，把它们拆成两个Story；
再大的Story也不要大于1个sprint、否则说明没有尽力或没有能力去分解功能，而不是不能分解；
User Story要有优先级和预计完成时间，以便团队根据其优先级和工作量来制定Sprint Backlog；
其目的是为了完成原始需求和实现需求的区分。
（2）计划会议1：初步的SB（团队工作量，US优先级和工作量，优先级，需要指定PM，整个大团队，组织者和ScrumMaster的指定）
（3）计划会议2：任务分解；工作量和任务分工；排期；PM自己开项目计划会议（SM）；
项目分开的选择PM主导；主要有3种，分别是
A标准（WBS,估时排期&会中全体）好处：民主，科学。可能产生不好的地方：效率低，统一。
B个人主导(会前：WBS，估时/个人会中：个人讲，集体review)|排期，会中全体(好处：半民主)。
C由PM主导（会前：WBS估时PM会中：PM讲，大家review）不好的地方，不科学，不民主，对其他考虑不够专业例如前端等。好处：效率高。
优先考虑B，风险性和效率综合考虑，在团队成熟了可以考虑使用A
根据资源和工作量分析出团队瓶颈来相互资源平衡，全功能团队。目的是实现团队风险的预防和提前应对。
任务条的设计：任务都是连续的第一天一部分时间紧接着第二天剩余的时间，按照优先级进行完成，目的是未完成的后期其他成员的时间影响就能清晰可见，例如：TC配合关系的影响和团队的时间风险的影响，出现问题就需要调整计划。另外如果资源分得太散了风险太大，需要投入在主要的，不要过分集中或者过分分散，例如过分分散：20号发布大家全部分散在各个单一的任务资源，如果出现任何一个问题，则会影响全部的发布，所以要进行拆分资源的投入来减少风险。
这样做的目的不是为了评价团队成员的工作任务量，强度和问题量而是为了识别风险。
另外一个优点是计划时间评估的准确度能力的提升会随着迭代团队的相互成熟，不断精准化。
（4）实际和期望产生的结果方式：任务按照优先级划分进行排列
任务时间和划分做个最简单的风险识别的例子：为何采用如此分配和团队目标呈现
上面两个图属于2个极端的来反应说明问题点，再取中间是可采取的有效的方式。
图1的问题在于区块化分工开发过于明细，如果任何一个开发在完成任务中出现问题，则即使其他任务都正常，那么整个项目组也会直接全部受到影响，全部无法正常上线
图2则是任务过于单一，人员集中，会存在技术实现人员的沟通和相互影响的风险过大串线的任务未实现资源最大化的应用。团队配合不合理，下游团队的闲置，测试被压缩。对不同技术和人员层次未规划
实际采用方法就是取2个极端进行中和，根据优先级和任务的难以程度和耗时情况，进行主力和协助资源的穿插分配达到有主导有协助，提高下游提前进行部分简易任务的进行，整体资源应用前移。
目的是通过团队的时间表也能清晰反映，主要工作困难和耗时点，假如，开发资源充足，测试资源紧张，完全可以全民皆兵，开发资源紧张，测试资源富裕可协助单元测试等，人员角色实现交叉，来实现共同目标的顺利达成。
（5）daily meeting：一个项目；晨会；PD参加-目的识别问题（PM-开发进度和人员情况的掌控 QA：项目风险识别，质量保证情况）。
（6）评审会议：功能（PM）&对功能实现进行评审，以及技术团队的技术评审等。
（7）回顾会议：（SM组织），全员参加。迭代的回顾。目标完成情况。
（8）经费：制定团队规则和惩罚以及活动规则，周期完成或者回顾会议进行团建。
以下是关于测试如何进行PD期望的有效测试保证
那么PD期望看到的测试需要完成哪些内容：
（a）对于需求评审阶段的需求测试内容
对于需求的内容的目的性能达成共识，测试提前化，了解项目要完成和后期期望达到的目标是什么，针对目标进行需求测试分析。
对于PRD和PB会议以及计划会议中，能够对功能内容或者需求能够进行场景拆分，最期望看到的就是业务场景的遗漏，异常甚至是场景交互的问题提交，所谓的需求测试的亮点所在和PD最期望看到的内容就在于测试在需求阶段对于场景的分析；是否有更为方便缩短流程的场景订正。以及良好的产品方向或者行业方向的建议。
（b）计划会议2阶段，以及技术团队的技术评审会议，测试人员能够协助开发在场景压力，技术实现以及如何设计测试方法进行快速测试，缩短周期上进行控制。由于良好的风险意识能对团队整体的资源，时间和技术上提供风险识别和问题分析。
（c）开发和实现阶段，以及测试阶段：此时的主要期望在于发现功能交互问题，以及可用性的提升。
（d）回顾阶段：nice to have能进行问题分析和残留问题的总结看法和处理计划。
希望这些对团队也能有一定的帮助。
（责任编辑：张红月）
推荐阅读相关主题：
网友评论有（0）
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章如何实施 SCRUM ？ - 知乎1235被浏览122830分享邀请回答0添加评论分享收藏感谢收起