《精益开发实战》是一本由克里伯格著作，人民邮电出版社出版的平装图书，本书定价：39.00元，页数：168，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《精益开发实战》精选点评：

　　●敏捷开发项目管理

　　●和以前在InfoQ上看过的看板迷你书一样简洁明了

　　●从《码农》上看到了书评，于是就在多看买了本电子版，一直喜欢敏捷的的我很适合这本书，一些观点正好在实践，一些方法适合我现在的项目。

　　●细节，重点要看细节。

　　●清风老师推荐的书~前天晚上第一遍刚读完，整本书写的挺好的，尤其是前13章，感觉我现在面临的问题就是那些章的反面教材。。。~等读5遍以后再写好好感受吧~

　　●看板实例

　　●很不错的入门书籍，实践和理论结合的很好，值得一看

　　●前面的项目实战有些东西还是可以借鉴实施的。可以做下个管理例会的议题了。后面的敏捷概念介绍，有点凑字数的感觉。

　　●#实践出真知，方法靠自己#

　　●书中的所有实践，在ThoughtWorks的各个项目组都已经在使用了

　　《精益开发实战》读后感(一)：敏捷没有界限、适用即为标准

　　写的挺实在、基本无废话，介绍了在比较大的团队中采用敏捷开发的案例和实际经验：例如有分工的小组、人员交叉、多级看板、这些内容以前没有我在其他的书里看到。

　　敏捷本身并无定式，随时调整十分重要。重要的是不断反省、持续改进。

　　《精益开发实战》读后感(二)：重新思索看板

　　正在看第二遍，也积极地在项目里实行用看板来管理项目。而我对于看板的核心理解来源与书中的一句话：

　　项目的开发速度很大程度上取决于团队成员对项目当前状态的数值程度。

　　其实看板的目的就在这里，让团队成员明白项目当前的进度，我需要做什么。然后通过“完成”中的任务来激励技术，原来我们已经做了那么多东西。

　　而书中提到的另外一个思想也很新颖，把项目开发流程的持续改进当做一个任务来做，不断的发现问题，改进流程，让团队更加磨合，这样效率才能更高。

　　《精益开发实战》读后感(三)：在一起，真的在一起

　　不得不说Henrik Kniberg的每一本书都又薄又好用。价钱不贵，看着不累，居然路子还对。这就有意思了。

　　有意思的是，他的每一本书也是一个真实的项目得出来的。所以，有很多话一说出来，经历过的人，都会深有感触，微微一笑吧。

　　在这一本中，他同样是用一个真实的PUST项目演绎。提及了很多有用的实践。看板、站会、持续改进、度量、经验教训。引用了敏捷、精益、Scrum、XP、看板，甚至因果图（CLD-Casual Loop Diagram）。

　　如果让我来用一句话来总结。满本写的都是一句话：在一起。在这本书里你会看到，研发团队和客户在一起。开发和需求在一起，开发和测试在一起。做一个需求的在一起。

　　整个项目的人都在楼的同一层，在肉体上在一起，是的。

　　整个项目的人都在使用看板并且将目标和自己所面对的工作与其他人紧密合作，这是精神上在一起。

　　每个人都在做对团队有意义的事情。围绕着物理看板，让团队里的其他人看到。更紧密的沟通，让团队之外看到。

　　在整个过程中不断改进自己，摒弃无用之物，比如估算。

　　最后，合作于是紧密无间，团队的自发性就越高。

　　真的是在一起，自发的在一起。

　　这就是效能的来源。

　　《精益开发实战》读后感(四)：很全面的精益流程

　　敏捷开发的执行和过程。敏捷开发的参与人员包括需求分析人员、开发人员、测试人员等。最核心的元素是看板，通过看板展示每个阶段的实际情况，看板的信息通过每日站会或阶段性会议来更新，同时团队核心人员也会通过一些其他的定期会议持续改进流程，以至提高工作效率。

　　1）看板划分多个区域，主要分需求、开发、测试、发布状态；用便利贴记录功能需求，而便利贴的流转路径：需求池-->开发池-->测试池-->发布池；每个池的状态都是持续更新的，一旦有需求确定可供开发，转入开发池，程序猿开始动工，完成可测试单元时，转入待测试池，完成通过，则可放入待发布池。

　　2）当团队人员较多时，分多个小组进行每日站会，小组站会结束后，再由小组接口人开个汇总站会。站会主要汇报昨天做了什么，今天计划做什么，当前存在的问题或需要支持的地方。通过站会，各成员充分沟通反馈，知悉整个团队的开发进度和依赖关系。

　　书中的后半部分讲了比较多的在敏捷过程中涉及到的版本规划、版本发布、自动化测试、因果分析等等方法和技巧，这些也曾在实际工作中遇到过，觉得很赞

　　《精益开发实战》读后感(五)：看板的价值

　　如副标题所示，这本书让我体会最深的是看板。

　　看板主要的好处有几个：

　　1. 确定优先级 优先级一目了然，如果老板，领导，产品，有新的想法需要插入时请先看看当前的任务列表。这个一定程度上确保任务不会被头脑发热的想法或者临时事务打乱。在当前的公司的官僚组织体系中，领导的一些想法和改进往往会被安排到第一优先级来处理。这个主要原因有两个：老板可能不知道当前正在进行哪些任务。

　　2. 区分技术改造和功能开发 保证不要亏欠太多的技术债务，避免后期受技术债务拖累

　　3. 清晰的掌握整个工作流的任务状况，快速发现影响交付周期的瓶颈点比如 开发功能太快，导致测试堆积，延长交付周期，这时候就需要重点进行技术改造，加快测试速度（如:提高单元测试覆盖率，完善自动化测试工具等）

　　4. 协助开发人测试运维人员进行工作计划以及安排 虽然开发者个人进行工作计划或者写工作日报是个好习惯，但据我观察，能这样坚持的人如凤毛麟角。也有的公司强制开发人员写工作日报，但一般都流于形式，收益甚微。如果有看板每日早晨review，这个工作会简单许多，并且节省时间。

　　5. 如果是大型团队，看板拆分，便于各小团队之间的沟通 很多大团队会通过周会等机制进行定期沟通，互通有无，协调工作。但这往往会导致冗长的会议，沟通也不能及时。如果各小组每日先行组内例会，然后再由teamleader进行大的项目同步例会，对于消除大会议以及及时沟通有非常大的意义。

　　看板只是一个工具，需要和Scrum,XP,Sprint等思想结合。工具不是万能的，重点还是在团队的组织方式和开发交付的思维方式的改进。

　　http://jolestar.com/recently-reading-notes/