《Scrum敏捷软件开发》是一本由Mike Cohn著作，清华大学出版社出版的474图书，本书定价：69.00元，页数：2019-11，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《Scrum敏捷软件开发》精选点评：

　　●我觉得方法论是为了弥补个人和团队的缺陷。好的管理者应该掌握足够多的方法论帮助你发现团队的缺陷，并用选用合适的不同粒度的方法论去弥补。这本书有一些关于scrum的实施历史数据和指导原则还是很有用的，能给我们实践一些参考。

　　●对书中的很多见解很有同感。而且给出了很多指导性的建议。是从实践中总结出的经验。

　　●本年度除了德鲁克之外，这本是看过写得最好的书了。

　　●开窍了

　　●适合高级用户

　　●非常适合作为敏捷开发的第二本书看，特别是实施一段时间之后看，硝烟是武功招式，此书是内功心法。摘要：团队的形态决定了产品的形态。提高过程可见度，缩短反馈周期。不管今天做的多好，下个月做的更好，一直、一直、一直设法改善才是敏捷。

　　●翻译有一点点诡异，对于入门了解的人来说，非常的全也很详细。

　　●相当不错的一本书，很多实例，相比《用户故事与敏捷开发》，都是实际经验分享。

　　●不是工具书，也不是初学者入门书籍，对于对Scrum有一定基础了解，想更深入的理解并进行传播的人有一定启发

　　●额~看不下去

　　《Scrum敏捷软件开发》读后感(一)：很有价值的一本

　　比较早就知道这本书了，也比较想看。不过，当时还没有中文版，找了英文来翻了几页就放下了。中文版出的时候，我也不知道，直到上个月才在偶然间发现中文版已经出版了……（推广力度不足啊）。

　　不过，我发现这本书的时间对我来说应该是恰到好处。如果早了，这本书我的评价一定不会很好，这本书的内容相对比较散，如果没有相关的知识和经验，估计很难看懂，也不会有那种于我心有戚戚焉的感觉。

　　但当你有了一些实际经验，又为一些问题所困扰的时候，这本书就能给你非常非常大的启发。而且很多方法的操作性还是也很强。

　　所以，我推荐有一些实际经验的同学来看这本书，如果想了解基本概念，或者还没实际去运转过几个sprint，这本书看了估计意义有限。

　　另外，书的校对还是存在一点问题，有些比较明显的错误没有发现，比如111页得那个图就错了，非常明显。其他也还有些小瑕疵，不过总的来说还不错。强烈推荐。

　　《Scrum敏捷软件开发》读后感(二)：一本颠覆更新思维的书，值得再读和作为手边的工具书。

　　一本颠覆更新思维的书，值得再读和作为手边的工具书。

　　分为：启航，个体，团队，组织，下一站的结构。

　　crum中的应用：

　　1. Scrum推行的方法

　　2. 个体对scrum的适应

　　3. 团队对scrum适应转型角色转换

　　4. 组织对scrum的支持

　　不同文化之间的差异： 美国看中个人主义和功劳，中国看中权威

　　《Scrum敏捷软件开发》读后感(三)：不是面相完全的初学者

　　首先要说的是，这本书不是面向初学者的，读者至少需要有一些敏捷开发的基本知识，如开发模式、迭代的概念等，最好可以有相关的开发经验。我们公司一直使用的是瀑布模型的开发方式，严格遵循着需求－设计－编码－测试的流程，虽然对敏捷开发和迭代模型我也有一些了解，但是看这本书的时候仍旧有不少地方不能很好的理解。

　　看这本书的初衷是为了找出一种结合瀑布和敏捷两者优点的开发方式，所以我关注的重点是敏捷的开发流程、遇到的问题、如何管理。不过可惜的是，在这本书中，这方面的内容并不多，只有在书的最后部分提到了这个问题，但也仅仅是问题，而没有提出具体的解决方案。书中大部分内容有些源于scrum而高于scrum，更多涉及到了团队建设方面的问题，像如何转型、成员激励等。这些内容，有些属于通用的团队管理方法，已经从别的渠道学习过；有些属于更高层面的知识，对我现在的情况而言并不实用，没有击中我的痛点。但是作为一种知识储备，在脑中有个印象，将来如果用到，可以再回来学习。

　　最后说下翻译，个人感觉一般，总感觉把ETC和IC中的C（community）翻译成社区有些奇怪，因为作者像表述的更多是一种团队活着工作小组的概念。不过也能看懂，没有让人啼笑皆非的错误。

　　《Scrum敏捷软件开发》读后感(四)：scrum大部头

　　一本scrum方面的大部头, 很多内容讲的比较细, 也比较全, 很多地方都涉及到项目管理的知识, 当然还有敏捷相关的知识, 不过较少, 有选择性的看了看, 算是其他scrum书籍的一个补充吧.

　　------------------我是读书笔记的分割线------------------

　　crum这个游戏如同围棋, 入门容易, 成为九段高手难

　　在scrum领域, 没有最佳实践, 只有最合适, 最有效的实践.

　　crum不在于让你现在有多优秀, 而在于你下个月有没有变得更好.

　　衡量开发人员的效率是不可能的(martin flower)

　　对于scrum团队成员来说, 不要考虑是你的任务还是我的任务, 而应该考虑是我们的任务.

　　crummaster一方面是团队的领导, 另一方面是毫无行政权力的普通人

　　更多内容：http://macrochen.iteye.com/blog/1097294

　　《Scrum敏捷软件开发》读后感(五)：收获了几个新观点对敏捷

　　敏捷宣言：

　　持续交付尽早交付

　　尽早交付是因为，再充分的前期调研和设计还是不够，不如真刀实枪让用户“放几炮”来的真切；持续集成，持续交付是，尽早暴露发现问题。

　　面对变化掌控变化

　　尽早交付是因为，再充分的前期调研和设计还是不够，不如真刀实枪让用户“放几炮”来的真切；

　　掌控变化，变化无可避免，那我就拥抱它，写在合同稿上需求，不能改善用产品的满意度，只能让你的用户愤怒！

　　追求协作、激发、共享、信任、简洁、卓越

　　去***各种头衔的“经理”，信息透明共享，共同讨论，合适的人一起工作，实现卓越的目标。这一条真心不容易做到，但想想这样的场景是令人激动。

　　敏捷实践看起来就像是“小清新”之风一股，吹入IT宅男胸膛，沁人心脾。那是怎样一副场景：

　　写代码的桌子旁边的大落地窗外面是那几乎望不到对岸的中心湖，19吋MAC Pro Book旁边，24小时不限量供应的现磨咖啡正热气袅袅，哦，下午4：30钟还有一场球，得下班了。

　　醒一醒，还没有完。好书难得，而受众不明，主题不突出，内容冗繁的图书比比皆是，本书页不例外，但总算还是有几个观点收益。

　　敏捷实践页可以和CMMI模型之类配合，但是，那套老式的“瀑布模型”怕是需要做个大手术了。

　　敏捷实践，在新时代下适应软件开发的挑战而出现。