《轻松Scrum之旅》书评

读完了，感觉还可以

读完了，感觉还可以。主要讲了一个scrum团队的成长过程。其间，比较吸引我的地方就是scrum master向他的教练请教的那些问题，也是我比较想不通的问题，看了答案后感觉还算有所收获，我个人认为这是本书的最大亮点，也是我评价为“推荐”的原因。其他叙事部分，也就那样吧~~这导致了我感觉读这本书更像是在读小说⊙﹏⊙b汗读这本书时，我是参考着《Scrum要素》读的，那本书写的是关于Scrum的概念，感觉比较官方，所以感觉《Scrum轻松之旅》中有些地方好像不对，对scrum中的某些概念理解有偏差。。。但因为我刚接触scrum不久，也说不出个大概来（尴尬了~~#）总的来言还是有所收获的。在这推荐下《Scrum要素》这本书，敏捷联盟的联合创始人写的，译者也是国内的Scrum方面的大牛，诠释Scrum的、返璞归真的一本书，老少皆宜。 http://book.douban.com/subject/20507350/

本书让我回忆起当年实施Scrum时的点点滴滴

当在豆瓣上看到此书时，就决定买下来....也许是对与Scrum方法论的感情，也许是为了追寻曾经的一些美好回忆.....本书以主人公所经历的第一次Scrum项目为载体，引领读者与作者一起亲身经历着一个scrum实施过程中的点点滴滴，轻松与紧张中，的确让我学到很多。书中以第一次接触并实施Scrum为主线，开始在项目中实施敏捷的项目管理方法论，这让我回忆起一年前自己刚刚开始接触Scrum时的点点滴滴......同样是一个跨国家的团队，在一天下午收到国外同时Henry的邮件，关于一个Scrum的pdf手册，几十页的手册很多究竟读过，但是仅仅留下深刻印象的是“猪和鸡“。也同样经历scrum管理方案/工具的选型，而我们不同得是选择了白板与Scrum Excel 的方式进行跟踪整理productbacklog,以及每次的Sprint 与燃尽图........经历着测试如何集成到Sprint中，也是让团队困惑了很长时间......第一次Sprint review的场景都历历在目。本书让我重新经历的Scrum的开始到.....面临质询过吹是的问题，并一起解决问题继续前进，同时David的邮件是重要的资料整理，在实施Scrum的各个环境可能遇到的问题，借用David的邮件都做了详细的解答。的确，scrum仅仅是敏捷的一个方法论，是一种打破传统项目管理方式的思想，所以执行过程中的关键在于”执行力“以及不断的总结、回顾，团队一起来解决问题提升效率。

我的Scrum之旅

如果你想了解敏捷的Scrum方法，那么就请阅读本书吧！《轻松Scrum之旅》并没有像其他的技术书籍一样以讲概念为主，而是将敏捷的思想、Scrum的概念和Scrum的实施方法以故事的手法很形象地讲述了出来，非常容易理解。对于想要了解Scrum的新手来说，入门很快。由于我在公司也经历过Scrum敏捷开发，所以在读本书的时候，总有一种身临其境的感觉。读过之后，也对敏捷有了更深的理解。敏捷不仅仅是一堆软件开发方法和开发流程，它的本质是一种哲学思想，是一种做事情的方法论。敏捷之道就两点：以价值为本，以人为本。You don't Agile, you are Agile !

呵呵 入门的 比那些正式的书好看多了

刚开始推行敏捷的时候,老大买了几本小说,说大家不想看技术书的话,就看这个吧.那时候感觉很有意思,也便看了,确实是本入门 的好书.现在我也在做项目,感觉这书是死的,人是活的,大家拼命的赶项目.什么敏捷不敏捷,感觉像是在扯蛋,做出东西才是王道.但是这本书确实很有意思,可以拿过来当小说看,真的.

贾子河=关毅 段姗姗=段美女 段永刚=胖子 蒋博=小胡

题目当然是不负责任推测，不过书中主人公和作者人数一样且都是三男一女，且女的都姓段，那么贫僧的浮想联翩也是可想而知的，哈哈。本书作为小说来看写的文笔水平相当一般，诸如“XX露出了满意的笑容”，“XX兴奋的跳了起来”之类文字不忍卒读。不过毕竟情节是宾，scrum实践部分才是干货，忍之。现在国内的主流互联网企业大多采用scrum开发，在Agile的各种实践里面，scrum的好处我想最关键的在于结果导向性：能够在每一轮的sprint有可工作的产品产出，并且在整个的过程中有相对透明直观的通报机制，最得公司上层大老板的欢心，利于推广。同时作为框架它比较灵活，能够容纳大中小型各类团队协同工作。我所在互联网产品团队的开发过程中也实践了scrum，个人觉得scrum的精髓实在在于daliy scrum会议。而传统重量级CMM的软件开发模式，其主要问题就在于：1.依赖单点，基本需要有一个很牛逼的程序员（一般美其名曰架构师）先把整个事情想清楚，然后做好设计，再带几个菜鸟一起开发。或者更糟，干脆就像海鸥拉完一泡屎之后就啥也不管了，要是一上来的设计就错了（这是大概率事件），基本后面就一条路走到黑。即便这个架构师既有能力又愿意放下架子一起干活，其他项目组员的积极性也会受到很大挫伤，同时由于单点的存在，对于管理者的压力很大。2.文档重于代码，流程重于人，邮件沟通多于当面沟通，希望一切都能under control，但是实际上这是不可能做到的，一般都是学鸵鸟罢了。scrum强调的，恰恰是去中心化，强调迭代和拥抱变化，强调群体决策，这样带来的表象是看起来项目的一切事情都乱糟糟的，但是这就好比中午吃饭的时候一千个人跑去食堂排队，虽然看似乱哄哄，实际上大家很快就能排出几条差不多长的队伍买饭，根本不需要有人从旁协调“管理”。只要做manager的敢于充分信任自己的团队，不要太强调控制，或者每月来一次管理狂热干涉这干涉那，基本我觉得这项目就成功了一半。对于scrum团队绩效的考评，我觉得是一个非常好的问题，但是由于本书不是阐述人员管理的，因此在书中借由David之口含糊带过。作为manager，实际在应用scrum的时候必然会遇到同样的问题（在书中这个问题是徐天的）。其实对于绩效，主要可以分为过程考核和结果考核。scrum是注重团队的最终执行结果的，因此如果产品最终达成预期考核目标，我会倾向于对产品团队的结果部分给出高分，但与此同时，过程考核却是因人而异的，需要结合scrum团队中对于Story分解的能力，计划的执行力，代码的规范质量，模块的服务稳定性等等综合衡量。这样组合的绩效考评方式，应该既能够起到激励scrum团队，又保证了能够评估团队个体间的差异。本书有一个明显的论调就是天塌下来不用愁，一切靠老外：scrum的答疑解惑有David，产品的Backlog靠Greg，Peter等；基本上北京团队就是外包，从头到尾也没有看到实际上的产品决定权，看完本书我决定这辈子不去IBM，给我Band10我都不去。书中的世界，仿佛活在我天朝新闻联播中：主角聪明能干，上司和蔼可亲，下属温顺善良，同僚热心解惑，老外纷纷恨不得跟你挖心掏肺，真实的世界，远远不是这样。另外，本书为IBM插播的广告还是有点多，BuildForge啦，Rational Function Tester啦，最后忍不住把全书力捧的scrumworks也拉下马，搬上来Rational Team Concert，还不忘一盆脏水泼给创业公司：留在国际化大公司吧，这里是主战场大舞台啊，有钱有粮有地盘有美女应有尽有啊，千万不要去创业公司啊。不过现在巴巴的出本书哪有不把自己公司捧上天以谋个功名啥的，哥们习惯了已经。

小说般的书

作者使用了小说的形式来介绍Scrum的基本概念，以及在使用过程中作者遇到的问题以及解决思路。这样更容易使用读者产生感性认识。但Scrum在文章过分强调Scrum能产生的作用。虽然也有特意说明Scrum只是一个框架。从我的理解，Scrum确实也只是一个框架，很多东西都实践的方法都没有。不能作为有价值的一种开发模式。因为在实际的开发过程中，更应该对人的管理导引都是中层管理的职责。但怎么去管理和导引，这是所有中层管理所关心的，而Scrum不能提供。就像只给了一个目标，而没有相关的方法。Scrum描述的团队是一个自我管理的团队。但自我管理需要有一个核心。大部分的工作者，上班只是为了单纯的RMB。对于维护这样的一个团队，Scrum Master需要花很多的时间和管理技巧让团队成员围在一齐。反过来说，如果有这样的时间和管理技巧也不一定需要使用Scrum这一框架。不怎么样，我的这些观点是否值得准确。但这本书还是值得推荐一下想了解Scrum的人看。起码能有基本的感性认识。

第一本scrum阅读书籍

公司实行scrum后，偶然看到这本书，对里面很多东西发现和公司里正在发生的都很象，马上买下。这本书是非常好的scrum书籍之一，完完全全是真实工作经验中的东西。你会慢慢发现和工作中很多相似的地方。

SCRUM入门的书籍，有优点，但是收益也很有限

第一次看这本书的时候，是2011年8月，我对敏捷只有初级的理解，当时去公司另一个试点项目参观学习，于是忙里偷闲进行扫盲，用电子版快速读了一遍，觉得还不错，基本实现了扫盲的目的，4个月后，我们部门的敏捷试点进行的小有成绩，并且我也看了其他几本敏捷的书籍，部门买来了这本书，于是我抽空又翻了一遍，觉得可以对这本书进行点评了。这是本敏捷入门书籍，有优点，但是收益也很有限。优点:1、用小说的方式，逐步引入SCRUM实践，应该都覆盖全了，从计划会，每日立会，展示会，回顾会等，包括自组织团队，而且都给出了理解和思考，这一点比较容易让人认可，2、为了对比敏捷开发方式，关毅用博客回忆原有公司的工作方式，就是P17-P19的内容，与我们公司研发现状很相似，非常有共鸣；3、因为读起来轻松，可以送给领导看，这样他更容易支持我们的敏捷试点；不足：1、理论太浅显，对于SCRUM只是从表层进行分析；2、几个关键技术实践：TDD，持续集成，结对编程，都没能深入的探讨；3、缺少全面考虑；4、试用项目很小，只有4个人，没有说服力；总体评价，入门小说是不够用的，还需要一些更深层次的敏捷书籍。

大公司铿锵的原生态敏捷之路

在地铁上看完的，看的比较快，一气呵成的感觉，没有冗长晦涩的理论。关毅新加入E公司，带领新组建的敏捷团队，在实施过程中遇到不少问题，从而水到渠成的把敏捷的理论和如何应用呈现出来，面临的问题不攻自破。作为冷眼观全局的读者，也会各有所得。敏捷本身也是一种高效的工作方法论，敏捷重视高效沟通，避免无谓的资源浪费。敏捷强调自管理，需要精干的成员主动承担。敏捷重视回顾和总结，团队在每次迭代中成长。一本书看下来，这正是我们理想中的团队形态，彼此信任，同舟共济，高绩效。随着书中sprint的过程，你会带着认同的，恍然大悟的，未雨绸缪的心态。作为实施敏捷的前车之鉴，关毅的团队面临的困惑，混乱和磨合，在过去或未来，我们也会遇到，尤其是刚刚踏上scrum之路的团队。如果我们所有的教科书都这样引人入胜，让人在甜果实的路上渐入佳境，孩子在享受中吸收那些生硬的理论。相信中国的未来不可限量，可持续性发展不是一句空话。

比较理想化的scrum之旅

看完这本书起码不会不喜欢敏捷，感觉所有问题都是可以解决的，主人公的遭遇和困难都会有办法和有人去解决，真正的敏捷应该没有那么多牛人参与，所以会困难重重，不过感觉主人公真是很幸运啊，有老外的帮忙和答疑，不过这个书还是值得一看的

买了

周末在书店看了一半，我决定还是买本下来。书中讲述的X公司故事，也是我曾或者说正在经历的。重复的，无明确预期的工作，加班，让人非常沮丧。。。张毅这样的机会让我羡慕，其中我发掘的一点，就是英语要好,呵呵。总体而言，本书对了解敏捷和SCRUM应该不错的

呵呵 入门的 比那些正式的书好看多了

刚开始推行敏捷的时候,老大买了几本小说,说大家不想看技术书的话,就看这个吧.那时候感觉很有意思,也便看了,确实是本入门 的好书.现在我也在做项目,感觉这书是死的,人是活的,大家拼命的赶项目.什么敏捷不敏捷,感觉像是在扯蛋,做出东西才是王道.但是这本书确实很有意思,可以拿过来当小说看,真的.

书轻松 scrum不轻松 贾子河你能当我们的David吗？

这本书可以用平易近人来评价吧。我也算是一口气看完，不晦涩。把整个scrum的流程讲了一遍，将敏捷的一些概念也解释了，很适合入门选手来看。书中关毅遇到的问题都是小问题吧，相信贾子河遇到很多比这些问题难得多状况。不知道贾子河有没有什么联系方式 可以做我们的David啊？

轻松Scrum之旅，没看出轻松之处

有点像故事，还算有可读性，但是确实看不出什么轻松之处，主角不断遇到问题，解决问题，一点也不轻松。所以搞不清轻松是什么，如果是阅读上的轻松，讲得过去，因为像故事嘛。但是这个标题给人的感觉是用了scrum，就会非常轻松，但是没有点题（比如跟传统的比较下）。我倒是可以想到一些轻松的地方，用scrum用团队管理替代个人管理，那么管理者就轻松了；用dialy scrum，团队的工作互相透明，沟通就轻松了；不用写文档，程序员就轻松了。在scrum中不断提高个人乃至团队的效率，以后的工作就轻松了。

要是我有一个那样的David就好了

一口气读完的这本书，当然了“一口气”只是一个比喻，不过不是很恰当，要真是一口气读完的，估计多半会脑缺氧，而这本书带给我的是一种畅快淋漓的感觉。那种似曾相识，那种知音难觅，那种恨不得将书举过头顶大声呼喊太好了的冲动，正是这本书不装逼的独特魅力所在。在漫长的运通112之旅，唯有此书可以解忧啊。首先是风格，讲故事，非常像小说，或者也可以称之为管理小说。这个和《目标》，《关键链》是非常一样的。我非常欣赏这样的管理小说。从某种角度来说，管理就是各种方法的实践，停留在条条框框就显得不怎么地道。也许我本身也是一个实用主义者，根本受不了不能实践的管理思想。我也习惯于在实践中去学习新的思想，新的理论。当然也有的管理书不是写成小说的，但依然也很注重实践，比如德鲁克的书，还有《精益软件开发艺术》，都有非常明确的实践指导。这本书把故事安排的很好，节奏紧凑，有详有略，故事中的知识点巧妙的通过主人公的邮件，blog，对话，会议逐步向读者渗透。在主人公的开发道路上，精巧地设计了困难，一下子就给读者砸出了一个又一个的问号。看这本书的人，可能很多都有一定开发经验，或者有一些管理经验，对于实践中的问题不但有着切身的体会，更有着自己的迷茫，他们的眼光是挑剔的，嗅觉也是敏锐的。想用一个一帆风顺的案例也是不可能蒙混过关的。故事讲得好坏，关键是看主人公能否遇到读者一样的问题。读者会用自己的痛苦经历去衡量主人公所遭遇的种种问题。也会以审慎，甚至苛刻的眼光来看待主人公学到，或者悟出的解决方案。人人都有不幸，而读者的不幸一定要小于主人公的不幸，主人公才能获得读者的深度认同，才能获得在一线苦拼的IT斗士们尊敬。这人主人公获得了我的认同，我对他的遭遇有着切肤之痛，我有着和他一样的迷惑与彷徨，他遇到的问题犹如每天我问自己的问题。我没有太多的经验，但是我遇到过《完美软件——对软件测试的各种幻想》中提到的所有问题。如果你也是一个实践者，相信这本书会符合你的口味的。其次，我真的好羡慕主人公有一个可以求救的通道啊，在本书中就是那个无所不知的David。我们遇到了问题该怎么办呢？我们试图在公司推进敏捷，但是没有培训，没有大师，没有鼎立的领导支持，我们是坚持自己还是消灭自己？靠社区去解决问题么？这些都是这本书不能回答的问题。本书的的确确带我们领略了敏捷的魅力，但现实要我们回答更多更棘手的问题。带着敏捷的思想上路了，别忘了我们还是要有武器的。这么说吧这本书有点像童话，虽然有野兽，但多半就像《狮子王》里的狼，不见血。真正的沟通是要见血的，要骂娘的，真正的团队是要有人滚蛋的，真正的任务是不管你他妈的有没有计划的。但是这并不是说这本书就不实用。我觉得一方面作者都在IBM，相对来讲沟通环境比较好，一方面也可能觉得这些暴力血腥的场面不宜在这本书里介绍。不过敏捷的确在恶劣的环境下更能显出其威力。处理头痛问题才是敏捷的要义。在没有David大师的日子里，我看就先把主人公遇到的场景反复温习，反复思考吧。还要说的是，这还是一本初级读物，带领大家领略以下scrum的要义，却不是全部。话又说回来，敏捷没有全部，只有不断的前行，不断的实践，不断的修炼自我，才能到达至高的境界。大家还需要汲取更多的营养才能武功长足精进。我个人的看法是scrum+lean+xp+toc+kanban。scrum注重了管理框架，lean注重节约避免浪费，能够很好地衡量权重，找出薄弱环节，xp给了大量的实践套路，toc对整体步调给了很好的协调方案，kanban对可视化的要求又更近了一步。“我们度量什么，就会改善什么”scrum关注了用户真切的体验，让用户有效度量这一指标，所以真的是一种很不错的管理实践。

讲的挺有意思的

周末在中关村图书大厦看了60多页，然后还是决定买下来。开始是因为书中的开头吸引了我，我仿佛在书中找到了我自己的影子，我目前在一个比较大的民营企业工作，书中主人公关毅在X公司的遭遇我基本上都碰到了：公司以市场为重，不重视技术人员，开发过程比较混乱。而且在我上一次准备辞职的时候，上级挽留的说法一模一样：我们这里提供没有天花板的舞台。所以看到这部分感触挺深，我想也许我能从书中发现点什么，现在我们正在启动一个新的项目，也许能从中学习一些什么经验，等我看完了这本书再来做仔细的评价。

比较理想化的scrum之旅

看完这本书起码不会不喜欢敏捷，感觉所有问题都是可以解决的，主人公的遭遇和困难都会有办法和有人去解决，真正的敏捷应该没有那么多牛人参与，所以会困难重重，不过感觉主人公真是很幸运啊，有老外的帮忙和答疑，不过这个书还是值得一看的

比较理想化的scrum之旅

看完这本书起码不会不喜欢敏捷，感觉所有问题都是可以解决的，主人公的遭遇和困难都会有办法和有人去解决，真正的敏捷应该没有那么多牛人参与，所以会困难重重，不过感觉主人公真是很幸运啊，有老外的帮忙和答疑，不过这个书还是值得一看的

正在开始读,惊讶于技术的活可以写成小说

刚开始读,午餐后,饱困,在这种状态下还能让我细心地读三章,我想,这样的技术书我是第一次接触^_^前面几章的道理基本还是懂,后面的怎么样就不太清楚了,快快看,看完了再和大家来分享~计划于下周内读完...学习敏捷开发,这书应该是不错的入门

呵呵 入门的 比那些正式的书好看多了

刚开始推行敏捷的时候,老大买了几本小说,说大家不想看技术书的话,就看这个吧.那时候感觉很有意思,也便看了,确实是本入门 的好书.现在我也在做项目,感觉这书是死的,人是活的,大家拼命的赶项目.什么敏捷不敏捷,感觉像是在扯蛋,做出东西才是王道.但是这本书确实很有意思,可以拿过来当小说看,真的.

以另一种角度理解极限开发

作者用具体项目向读者展现Scrum的魅力，从每一次总结、子开发、挫折中提炼出Scrum的重点。结合具体的东西进行介绍让读者更真切的体会，不过建议在读过Scrum开发的定义介绍性书籍来读收获会更多。最后，有小小的质疑，虽然这也是为了全面介绍Scrum开发，但是作者在第一次的Scrum开发居然会遇见Scrum开发的几乎所有问题，怀疑是将很多次体验综合在一起。不管怎么说，书籍值得推荐。