敏捷并不是什么新玩意儿,但它已经成为这个瞬息万变的互联网+科技商业时代的主流管理运营体系。如果一个企业还没开始拥抱敏捷并付诸实践,那它很快就要被淘汰了!
现在我们遇到的问题大多是如何让敏捷落地,如何把敏捷带给整个企业。《大产品,小团队:携程敏捷技术与管理转型实战》并不是敏捷方法教授的纯理论书,作者只是把 5 年敏捷转型中趟过的那些坑,吃过的那些亏,流过的那些泪……通过一个个鲜活的案例呈现出来,送给那些已经开始尝试敏捷但可能遇到一些问题的人,以及虽然没有开始但已经跃跃欲试准备实践敏捷的人。
《大产品,小团队:携程敏捷技术与管理转型实战》适合初级和资深 Scrum Master、产品经理、技术管理者、项目经理,以及敏捷爱好者学习和参考。
携程技术中心,作为携程旅行网的核心竞争力,由超过3000位来自海内外的精英工程师组成,为携程旅行网业务的运作和开拓提供全面技术支持。以技术创新为产品、服务创造价值,以技术引领业务增长,使携程技术中心成为更优秀的OTA技术团队。
我们拥有10年以上互联网产品项目管理经验。我们乐于分享,自发组织了一个小团队,把我们在产品、项目、技术等专业领域的收获贡献给敏捷社区。为此,我们集结了10位总监和20位一线专家分享亲身实战经验,还特别邀请了火车票事业部和创新工场CEO陈刚以及车船票和租车事业部CEO王玉琛亲自执笔,带你修炼绝世武功。
本书是敏捷项目管理领域的全面实践记录,通过 理念 + 团队 + 技术 + 产品 四个篇章,真实反映了携程敏捷项目管理的理论与实操。(上述是百度百科的给出来的) 从自己当前对敏捷开发的认知水平来看,个人感触如下。 一、落实敏捷过程中需要完成以下内容: 1.对现有的研发团队的...
评分本书是敏捷项目管理领域的全面实践记录,通过 理念 + 团队 + 技术 + 产品 四个篇章,真实反映了携程敏捷项目管理的理论与实操。(上述是百度百科的给出来的) 从自己当前对敏捷开发的认知水平来看,个人感触如下。 一、落实敏捷过程中需要完成以下内容: 1.对现有的研发团队的...
评分本书是敏捷项目管理领域的全面实践记录,通过 理念 + 团队 + 技术 + 产品 四个篇章,真实反映了携程敏捷项目管理的理论与实操。(上述是百度百科的给出来的) 从自己当前对敏捷开发的认知水平来看,个人感触如下。 一、落实敏捷过程中需要完成以下内容: 1.对现有的研发团队的...
评分携程集团创作,作者有产品、开发、测试、PMO等多种角色。有一点比较怪异,每个章节的作者是放在书的最后部分的。 主要内容是携程的软件开发流程改进的故事。携程的做法是把大部门拆成十几个人的小单位,小单位内部实施OKR、OK制、十分感谢制等管理制度(后两种是携程自创,书...
评分携程集团创作,作者有产品、开发、测试、PMO等多种角色。有一点比较怪异,每个章节的作者是放在书的最后部分的。 主要内容是携程的软件开发流程改进的故事。携程的做法是把大部门拆成十几个人的小单位,小单位内部实施OKR、OK制、十分感谢制等管理制度(后两种是携程自创,书...
我关注的重点在于技术和工程文化层面,《大产品,小团队》在这方面的洞察力远超我预期的范围。很多敏捷书籍会把技术实践轻描淡写地带过,认为只要流程对了,技术自然会跟上,但携程的经验证明,没有强大的工程文化支撑,敏捷就是空中楼阁。这本书里关于如何平衡快速交付与代码质量的探讨,特别是对“技术债务”的量化和管理机制的描述,让我茅塞顿开。我们团队一直纠结于“赶功能”还是“重构”,书中提供的决策框架,帮助我理解了如何在商业价值和长期健康之间找到一个动态的平衡点。它不仅仅告诉你“要持续集成/持续部署”,而是细致地描述了在数千个微服务环境中,如何建立统一的质量门禁和自动化管道,这才是真正的大规模工程挑战。读完这一部分,我感觉自己的技术领导力得到了极大的提升,不再是盲目地追求速度,而是学会了如何为速度构建坚实的地基。
评分这本《大产品,小团队》真是一剂给身处复杂组织架构中挣扎的敏捷实践者的强心剂。我原以为敏捷转型就是引入Scrum指南,然后组织站会、评审会,但读完这本书才明白,真正的挑战在于“大”与“小”的结构性矛盾。它没有停留在那些人人都知道的敏捷仪式上,而是深入剖析了携程这样一家巨型OTA平台,如何用“小团队”的敏捷方式去支撑“大产品”的战略目标。最让我印象深刻的是关于跨团队依赖管理的章节,那里的描述简直是我的日常写照——无数个团队像多米诺骨牌一样相互牵制,一个需求牵动十几个接口人。书中提出的那些围绕组织结构、技术债务和流程再造的实战经验,不是空泛的理论,而是经过血与火检验的有效解药。特别是它坦诚地展示了转型过程中的阵痛和妥协,而不是美化一个完美的敏捷故事,这种真实感,对于正在泥潭里打滚的管理者来说,简直是无价之宝。
评分老实说,一开始我对这类“企业转型实战录”抱有戒心,总觉得里面充斥着企业公关的辞藻,把所有困难都轻描淡写地过去了。但《大产品,小团队》最打动我的地方在于它的“去神化”处理。它没有将携程描绘成一个已经达到“完美敏捷”的圣地,而是坦诚地展示了在转型过程中,组织内部权力斗争的现实、旧有系统与敏捷流程的摩擦,以及面对市场变化时,那些被迫做出的痛苦“妥协”。比如,为了维持系统的稳定性,某些非核心业务线的敏捷化进程不得不放缓,这种艰难的取舍在其他光鲜亮丽的成功案例中是看不到的。这种近乎“内部备忘录”式的坦诚,让我感到这本书是真正站在一个实践者的角度,而不是一个布道者的角度来写,它给予了正在经历相似挣扎的团队巨大的心理支持——原来,我们遇到的那些“不可能完成的任务”,别人也曾面对过。
评分我个人认为,这本书最大的价值在于提供了一种“组合拳”式的解决方案,而不是单一的“银弹”。它没有宣称“只要用SAFe就能成功”或者“只有Spotify模型才能活下去”。相反,它通过携程的案例展示了,在面对从数百万用户到数亿用户规模的业务差异时,需要像一个精明的建筑师一样,根据不同的“地基”和“承重要求”,灵活地搭建出最适合自己的敏捷结构。书中对中台化、微服务演进与敏捷组织形态之间相互作用的分析尤为深刻。它揭示了一个核心观点:技术架构的演进和组织结构的敏捷化,必须是同步且相互促进的。如果你想在技术上实现“小团队快速部署”,就必须在组织上赋予这些团队真正的“小产品边界”,否则,技术投入的敏捷性会被流程和组织层级吞噬殆尽。这为我下一步推动我们公司技术与组织协同发展提供了清晰的路线图。
评分这本书对于非技术背景的产品经理和业务线负责人来说,也是一本揭示“冰山水下部分”的绝佳读物。我以往总觉得,既然是敏捷,那就是产品经理告诉开发团队要什么,然后团队自己搞定。然而,《大产品,小团队》清晰地描绘了在复杂系统中,“清晰的边界”和“自治权”是如何被小心翼翼地设计和维护的。它详细阐述了如何将一个庞大、模糊的业务目标拆解成一个个可独立交付的、有明确客户价值的“小产品”,并赋予对应的小团队足够的决策权。这种自下而上和自上而下目标对齐的精妙手法,是很多宣扬敏捷的公司学不到的。书中对 OKR 在这种大规模敏捷环境中的落地细节,以及如何防止 OKR 异化为新的KPI束缚,提供了一套非常实用的操作指南,让我对如何设计更有效的组织激励机制有了新的启发。
评分虽然内容编辑得不是特别有层次,但是很接地气吧,技术人的一种阐述,基本没有理论,都是在说是怎么做的,属于分享型的,有一定的参考价值
评分弃。
评分挺实在的
评分2019年7月读的,整体还是很不错的,我一直都觉着这类企业内部团队名义出版的书籍,都较接地气。
评分这本书副标题就是“携程XXX”,所以内容大多数都是携程有关的这点并无问题。其中不少方法很明显有没有说全的地方,比如一开始的启动,如何获得支持。考虑到本书的定位,也能理解。不要期望从本书中获得太多“可执行”的内容,都是敏捷、DevOps 的基本操作。作为历史性数据了解即可,当历史来看是个不错的选择。
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2026 onlinetoolsland.com All Rights Reserved. 本本书屋 版权所有