《精益软件开发艺术》书评

精益神话

”Lean Startup“系列的书最近很火，可能是现在创业行为很多，而精益思想又确实提供了很好的指导作用吧。还看到一些调侃”精益人生“，”精益谈恋爱“等等等... 这本书买了很久直到最近开始看。书很薄，如果知道相关的敏捷开发的概念也很容易理解，翻译也还算不错。看完只是觉得精益思想没有多么神奇，和其他敏捷开发相比只是出发点不同而已。可能Toyota和其他创业故事让Lean听起来有一点美了。敏捷开发是一个理想模型。敏捷开发的四条思想说得好很响亮。很适合拿来做推销文案，全是优点的一套理论。但是有时候想想会觉得有问题像是骗局。下面找了一些原因但并不是有力的抨击证据。原因一 以最大化效率（最小化浪费）为目标。Lean强调消除浪费，却是不可能完全做到消除浪费。精益开发中药使用TDD方法，并不认为是引入浪费（因为它带来价值），但是TDD本身是需要维护的，而需求变化将会带来大于一倍的损失。但大家愿意相信在这种消除浪费的改进过程中能够提高生产效率。敏捷开发其实成功率也不高，但是大家也愿意相信以敏捷思想为目标就可以有所进步。其实这个是一种乐观主义，相信努力就算不成功也会比以前好。这是真的吗？原因二 积极响应变化。但是有一些变化是不允许的，比如说推迟发布期。如何不能够按时发布的话也有一定的”敏捷措施“让产品变得可以发布，比如用mock方法来模拟未完成的模块（骗人么不是...）。发布期是不可以响应变化的（每一迭代周期的任务也必须固定好），是因为如果响应变化了那么就违背了敏捷另外一些原则，而且损害是明显可见的。那么另外一些时候呢？敏捷思想要求如果出现了变化，总是积极思考对策并快速推行，而变化的代价有时候不太可见了。但约束原则指出，消除一个约束就会改变系统流程，那么也就会引入新的约束。一个变化是否应对必须考虑清楚，而且有一些时候响应变化的后果是难以估计的。原因三 总有一个合理解释。敏捷不是具体的流程步骤，而是精神指导。听上去很美。大家都被需求更改折磨的很惨的时候觉得敏就是救星。但是当在实践的时候发现细节处有很多问题，敏捷会让你尽快做出一种合乎敏捷原则的第一选择。但是有没有人在实践中发现过有多种合乎原则的选择呢？甚至可能有两种方案可能都不是朝一个方向的。或许这时候就会陷入选择困境。敏捷大师可能会告诉你，你想的还不够透彻。于是最后给你的建议是根据他的个人经验...敏捷神话。现状是有很多人还有很多机构在研究和推广敏捷开发。敏捷开发本身变得有一些甚嚣尘上。一个公司好的公司愿意去选择尝试敏捷；而敏捷大师的培训门槛也很高，一次培训价格不菲。形成了支持敏捷的公司很识货，会敏捷的人才很精英的这种现象。敏捷本身是个理想神话，个人觉得太追捧过于热衷就有一点那个X教的啥了。好的做法是，敏捷开发流程，Scrum，TDD，Lean，XP。不一定要选择或者忠于哪一种，而是能够应用一些工具，并且对团队有帮助就好了。一位朋友跟我说他们公司在搞敏捷开发，每天开站会，但是从来都不会按时下班。从来按时下班的都是欧洲人，在日企就更别想了，完全无视以人为本保证工作时间才能提高单位时间效率什么的。但是吐槽归吐槽，能够开展每天站会肯定是有好处的。前边黑完敏捷但是对自己来说，还是很想亲身实践的。每次听到谁说啊自己公司使用敏捷开发就好羡慕... 大学一个设计课程，和同学一起实践过Scrum。课程选完分好组之后我还做了PPT介绍Scrum给他们，大家觉得好燃（可能只有我觉得很燃，他们只是表示支持），觉得学了软件工程终于有用了。然后还给老师介绍了一下说咱们组要搞Scrum，老师表现的很欣慰然后就不管了。最后这个Product Owner继续根据课程安排来推进每一组的项目，而我们燃完之后也因为每个人其他事情而没有太多时间做项目，而且坚持Scrum更新啥的也很难，更别说每天寝室楼下站会了（团队两男两女不同寝室楼）。最后进行了两个Sprint就夭折了。包括之前让大家熟悉Scrum的Sprint 0。不过通过Sprint 0还是很有收获，很多有用工具亲自做了一次。也觉得会影响自己做事情的处理方式。（有一种寂寞叫一个人的Scrum。T T）但是为什么会这么有动力，归根结底就是现在的公司是在太XXX。近期规划说要做全新版本，把功能筛选出来重新编码，于是乐观的觉得，还是有一点点微微的盼头的...——————————————————————————————内容简介软件开发的书籍一般包括3类内容：原则和目标（思维引导）、方法和工具（可实际操作的）和案例分析。这本书没有介绍案例的章节，第一种和第二种内容大概4：6。这本书实际内容只有100页多一点，是概念科普型的，但是精益开发过程已经介绍的很全面了，如果有相关能力，比如说会TDD，会refactoring，应该就可以实践操作Lean Development了。如果把敏捷看成一种开发语言，Lean只能看做一种框架framework，而Scrum或其他敏捷开发工具也是，都是根据自己的出发点，从敏捷方法集合中挑选合适的实践方法子集。虽然精益思想来自与制造业，按作者的话是精益对敏捷开发是兼容和欢迎的，其实具体实践方法在其他的敏捷开发中都有体现的。作者只在最后一章才提到精益特有的工具，比如说价值流图和看板，而改善大会与Scrum中demo会之后的的review meeting相似，只是范围更大（可以广义到工作行为本身的不合理的改善），具体要求更详细（规定了推出，决定和执行三个阶段和时间周期）。另外值得一提的是，TDD是精益开发中是不可省略也不可替代的实践，可以看做是其他实践的基础，也反应了更多的精益方法的原则。而其他一部分实践方法是所有敏捷开发都必须要求的，比如代码管理、短迭代和持续集成。而还有一些实践都有一定的通融性存在。

《精益软件开发艺术》读后感

首先我要给予这本书高度评价，O'reilly出的书果然是精品。整体来说，它给人的感觉很精益，内容虽然不多，但几乎句句珠玑，好像每个词都是精心雕琢过的，看了以后你真的可以体会到软件开发中的艺术性一面。从篇幅来说，此书篇幅不大，一共一百多页，很快可以看完，平均每章10~20页，都很轻量，阅读起来很轻松。从内容来说，虽然它只重点讲了5个核心实践，但你可以感觉到对这些实践的选择，甚至是其顺序的安排，都是非常精准的，最大限度降低了敏捷和精益新手的困惑。从结构上来说，本书设计精良，思路清晰，每个实践都有说明前因后果，这个结构为阅读者的理解，提供了很大程度上的方便。所以，我的结论是严重推荐下对敏捷或者精益软件开发感兴趣的童鞋们，去读下这本书。如果说从我所看过的敏捷软件开发相关书籍中，只能选出一本作为实践指南的话，这一本是最合适的。

可能期望太高

可能之前看了cleaning code，翻这本书的时候没什么惊喜感，现在书的同质化现象有点严重啊，像《程序员修炼之道》和《卓有成效的程序员》都是比较好的书，但老是看到相似的影子，哎。

轻薄，却又厚重

薄薄的书，很快就看完了，文字也都还通畅，翻译得不错。里面的道理很容易明白。可是到真正实践应用的时候，就不像看书那么简单了。不过我相信一点点改进，哪怕慢一点，只要方向正确，就可以到达。总之感觉这本书很值。

富有lean的精神

刚到手，从头看到第二章了。不得不说这是一本很不错的书。 首先，结构很合理，内容很清晰。想从宏观上了解lean thinking的，这书值得推荐。 其次，该书翻译的很流畅，把原著的思想表达的很清楚！值得赞赏。 ps：拿到中文版后又下载了英文版对照着看的。很佩服译者的功力！卓越网读者elton_ghhttp://www.amazon.cn/mn/reviewDetailApp?reviewid=2448210&uid=480-0793983-9115937