Scrum and XP from the Trenches读后感100字

《Scrum and XP from the Trenches》是一本由Hendrik Kniberg著作，C4Media Inc.出版的6" x 9"图书，本书定价：US$22.95，页数：168，特精心收集的读后感，希望对大家能有帮助。

《Scrum and XP from the Trenches》读后感(一)：很好很强大

140多页，一天看完。

不亏是一本介绍scrum实施的书，写法也很实践，很敏捷。

我很喜欢sprint on the wall的方式，简单明了，比再先进的online app都来得爽快。非常适合集中式的开发，不过这样对办公室也有了一定成都的要求 ;)

《Scrum and XP from the Trenches》读后感(二)：从战壕中带来的Scrum与XP敏捷实践

非常不错的一本书。

关于敏捷方法的理论和介绍，可以说已经要汗牛充栋了，目前被人们广泛承认的敏捷方法也有一定的数量了。但是如何去敏捷，也许一千个组织有一千种各自迥异的实践方式。

没有哪一种敏捷实践告诉你要完全按照它所描述的章章条条照本宣科，也没有哪个组织所实施的敏捷实践会是银弹，更不用说是放之四海皆准的最佳时间。

那么这本书有什么意义呢？很废话的说一句当然有。作者Henrik Kniberg通过告诉你他们如何实践敏捷，具体来说就是最为流行的Scrum和XP这两个实践，给了读者一个敏捷方法在现实项目中实施的借鉴，从而为读者带来思考，如果自己的项目要实施敏捷，具体该怎么做。

《Scrum and XP from the Trenches》读后感(三)：充分交流 + 持续集成！

按部就班的正统流程如CMM注重评审，会议，周报。表面上是通过制度保障质量，深层次上也是营造交流的机制和环境。

SCRUM，或者说XP等敏捷方法虽然倡导了无设计，无文档的开发流程，但在充分交流这条路上走得更彻底：

* 结对编程是开发人员之间的强制交流

* 客户代表是开发人员与需求提出方的强制交流

* 持续集成是整个项目组开发人员的强制交流

* SCRUM中每次sprint计划会议，也是多方--需求方，管理者，开发人员的强制交流，最终的计划是多方意志妥协的结果。

...

http://blog.duofish.cn/articles/8%E6%9C%88%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0%E2%80%94%E2%80%94%E3%80%8Adreaming-in-code%E3%80%8B%E5%92%8C%E3%80%8A%E7%A1%9D%E7%83%9F%E4%B8%AD%E7%9A%84scrum%E5%92%8Cxp%E3%80%8B.html

《Scrum and XP from the Trenches》读后感(四)：Scrum学习之买椟还珠版

我所在公司是个百年名企，和很多startup company相比，组织结构庞大臃肿，headcount绝对超过150法则所建议的神奇数字150（该法则认为将组织规模控制在150人以下命令才得以执行团体才能良性互动），而且凡事讲究process，对客户需求的response难免迟缓滞后，这在如今事事讲究速度效率强调快速反应的时代，这头巨象的转身自然不如土狼迅捷灵敏，尤其在行业利润日益稀薄的大趋势下，在各方豪杰名士土狼的环伺下，市场占有率，竞争力自然今非昔比。大概也是基于此，公司上层才会积极拥抱各类新概念，掀起一轮又一轮项目管理执行的evolution, revolution罢，可惜，往往是形似神不似。

Recently when I have still suffered the deployment of streamline development and doubted the benefits of it, there comes a new strategy to pilot and deploy agile in our project management. Sure, It is trendy that everybody talking about the agile and scrum. But what agile really is？ How to scrum？ How to adapt to this new concept, new way of working？ How big benefit it will bring to our company？ What are the obstacles we face？ There is still no clear answer. We all are just learning when we swim.

This book can be viewed as good practices, I really learn something from this book, at least, not in theoretical level while combined abstract noun/theory with concrete example in reality. When I finished reading, I am clearer about agile and scrum. However, here I don’t want to get into the details what and how I learn from this book, how good this book is. I just select some interesting jargons from this book, I heard them somewhere else previously. In order to know them more: background, origin, story and meaning etc, I google them to get deeper understanding. You can view it as “买椟还珠”: I buy the glittering casket and return the pearls to the seller. I don’t care to be a modern version of 楚人。

Yesterday’s weather:

This is the principle that says you'll get as much done today as you got done yesterday. In iterative projects it says that you should plan to do as much this iteration as you did last iteration. The term comes from the Extreme Programming community. It is technique to make our future plans based on what we know.

Origin: Some country decides to build a sophisticated computer system to predict the weather. After spending more money than people can imagine, they come up with wonderful result - and proudly claim that the system is 70% accurate. Somebody then figures out that in this country if you predict today's weather will be the same as yesterday's weather you will be 69.5% accurate.

The point of course is that while Yesterdays Weather is a crude mechanism, it ends up being not significantly less accurate than more sophisticated (i.e. complicated) ways of doing it.

“Chickens and Pigs” metaphor:

It comes from the idea of a project to make breakfast of bacon and eggs. The Chicken suggests that the two involve themselves in a scheme making breakfast of bacon and eggs. In reply, the Pig always notes that, for the Chicken, only a contribution is required as a chicken can simply lay an egg and then resume normal activities, while for the Pig a "total commitment" (or total sacrifice) is needed as in order to make ham or bacon, the pig must be slaughtered. This example simply illustrates that being involved may mean being a participant with little or no effort, while being committed takes time and energy, and means much more than just being involved.

This fable is commonly referenced in the Agile software development community to illustrate two types of project members: pigs, who are totally committed to the project and accountable for its outcome, and chickens, who consult on the project and are informed of its progress.

Gut feeling:

A feeling that you are certain is right, even if you cannot explain why.