具体描述
My new boss wasn’t being a jerk, but it seemed like it at the time. We were writing new software for use in the company’s high-volume call centers. Instead of the 12 months I told him we’d probably need, he had agreed to give me 4 months. We wouldn’t necessarily start using the new software in 4 months, but from that point on, all my boss could give me was 30 days’ notice of a go-live date. After the first 4 months, I would have to keep the software within 30 days of releasable. My boss understood that not all functionality would be there after 4 months. He just wanted as much as he could get, as fast as he could get it. I needed to find a process that would let us do this. I scoured everything I could find on software development processes, which led me to Scrum and to Ken Schwaber’s early writings on it.
In the years since my first Scrum project, I have used Scrum on commercial products, software for internal use, consulting projects, projects with ISO 9001 requirements, and others. Each of these projects was unique, but what they had in common was urgency and criticality. Scrum excels on urgent projects that are critical to an organization. Scrum excels when requirements are unknown, unknowable, or changing. Scrum excels by helping teams excel.
In this book, Ken Schwaber correctly points out that Scrum is hard. It’s not hard because of the things you do; it’s hard because of the things you don’t do. If you’re a project manager, you might find some of your conventional tools missing. There are no Gantt charts in Scrum, there’s no time reporting, and you don’t assign tasks to programmers. Instead you’ll learn the few simple rules of Scrum and how to use its frequent inspect-and-adapt cycles to create more valuable software faster.
Ken was there at the beginning of Scrum. Ken, along with Jeff Sutherland, was the original creator of Scrum and has always been its most vocal proponent. In this book, we get to read about many of the Scrum projects Ken has participated in. Ken is a frequent and popular speaker at industry conferences, and if you’ve ever heard him speak, you know he doesn’t pull any punches. This book is the same way: Ken presents both the successes and the failures of past Scrum projects. His goal is to teach us how to make our projects successful, and so he presents examples we can emulate and counterexamples for us to avoid.
This book clearly reflects Ken’s experience mentoring Scrum Teams and teaching Certified ScrumMaster courses around the world. Through the many stories in this book, Ken shares with us dozens of the lessons he’s learned. This book is an excellent guide for anyone looking to improve how he or she delivers software, and I recommend it highly.
作者简介
Apply the principles of Scrum to software project management with guidance from one of the leaders in the agile process movement. Case studies and project examples demonstrate Scrum concepts in practice and emphasize driving projects for maximum ROI.
The rules and practices for Scrum—a simple process for managing complex projects—are few, straightforward, and easy to learn. But Scrum's simplicity itself—its lack of prescription—can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results. In this illuminating series of case studies, Scrum co-creator and evangelist Ken Schwaber identifies the real-world lessons—the successes and failures—culled from his years of experience coaching companies in agile project management. Through them, you'll understand how to use Scrum to solve complex problems and drive better results—delivering more valuable software faster.
Gain the foundation in Scrum theory—and practice—you need to:
Rein in even the most complex, unwieldy projects
Effectively manage unknown or changing product requirements
Simplify the chain of command with self-managing development teams
Receive clearer specifications—and feedback—from customers
Greatly reduce project planning time and required tools
Build—and release—products in 30-day cycles so clients get deliverables earlier
Avoid missteps by regularly inspecting, reporting on, and fine-tuning projects
Support multiple teams working on a large-scale project from many geographic locations
Maximize return on investment!
目录信息
读后感
The writer give very detailed description of Scrum theory and give a lot success samples of using Scrum to manage a agile Project. All help readers familiar with Scrum or whom know about it first time to understand it easily. Furthermore, he gives a clear a...
作者是一位实践者。他结合各种实际中的案例，将Scrum剖析了一番。 重点介绍了Scrum的流程，即四个会和sprint的流程。对人和工件的介绍较少。 后面的翻译不是很通顺，比较生硬。大家看看罢了。 后面的翻译不是很通顺，比较生硬。大家看看罢了。
今年开始尝试做PM, 在我看来PM貌似就是个打杂的角色, 不管了, 先尝试一下, 因此找了一些书来看看, scrum也是我今年规划中需要了解的一个东东, 因此就选了这本书. 这本书据说是scrum的入门书, 也是scrum的鼻祖ken schwaber的大作. 以前也在网上对scrum有过只言片语的了解, 从这...
Ken是一个实践者，但是Ken有个特点就是他会先告诉你Scrum解决不了那些问题。大家在找寻方法论的时候都希望它能帮你解决所有问题，但是世界上没有后这样的方法论，这些东西永远都是指导，是别人的成功，你要成功只能靠自己。 如果大家没有时间来看书的话，《Scrum指南》在14页的...
Ken是一个实践者，但是Ken有个特点就是他会先告诉你Scrum解决不了那些问题。大家在找寻方法论的时候都希望它能帮你解决所有问题，但是世界上没有后这样的方法论，这些东西永远都是指导，是别人的成功，你要成功只能靠自己。 如果大家没有时间来看书的话，《Scrum指南》在14页的...
用户评价
市面上关于敏捷的书籍浩如烟海，很多都只是对Scrum指南的简单复述和美化。然而，这本书的独特之处在于它对“适应性规划”和“价值流管理”的深度挖掘。作者将项目管理提升到了一个战略层面，它探讨的不是如何更快地完成一堆既定工作，而是如何确保我们总是在做最有价值的工作。书中关于“产品待办列表的动态优先级排序”的论述，结合了经济学原理和风险分析，让我彻底改变了对需求管理的看法——需求不是要被锁定的，而是要被持续验证和调整的。我尤其欣赏作者关于“大型组织中的敏捷实践”的章节，它承认了规模化带来的复杂性，并提供了处理跨团队依赖和协调的切实方法，而不是简单地推荐某个特定的规模化框架。对于那些在大型企业中推行敏捷转型的专业人士来说，这本书提供了必要的理论支撑和实践的缓冲垫，让我们知道在面对既有官僚结构时，应该如何巧妙地植入敏捷的种子，并观察它们如何生根发芽。
作为一个团队领导者，我最头疼的就是如何构建一个真正具有自我组织能力的团队。这本书在阐述“团队动力学”和“仆人式领导力”方面，提供了独到且极具启发性的见解。作者没有采用那种一厢情愿的理想化描述，而是非常务实地指出了构建高绩效团队所必须跨越的障碍，比如权力的真空、冲突的规避以及责任边界的不清晰。书中关于“授权的艺术”的讨论尤其让我受益匪浅，它教会我如何逐步放手，让团队成员在明确的框架内自主决策，而不是事无巨细地进行微观管理。我尤其喜欢作者用生动的案例来解析不同阶段的团队成熟度模型，这使得我们团队能够准确地自我定位，并针对性地调整领导介入的深度。读完后，我开始重新设计我们的站会（Stand-up Meeting），不再让它变成汇报会，而是真正聚焦于障碍的移除和协作的增强。这本书帮助我理解到，敏捷的真正核心在于“人”，而不是文档或会议，而如何激发人的潜力，才是项目成功的关键所在。
这本书简直是为我量身定做的，它以一种极其直观和实用的方式，拆解了敏捷项目管理的复杂性。我之前总觉得“敏捷”这个词听起来高大上，实践起来却总是在团队内部打转，效率提升不明显。然而，作者在书中对于如何将理论框架落地到日常工作中，给出了大量可操作的建议。比如，书中关于“用户故事撰写”的部分，不再是枯燥的模板罗列，而是深入探讨了如何从业务价值的角度去提炼需求，并详细演示了如何通过故事地图（Story Mapping）来可视化整个产品路线图。我特别欣赏作者在强调速度与质量平衡时的那种辩证思维，没有一味鼓吹快速迭代，而是着重说明了在迭代中如何通过持续集成和测试驱动开发来保证交付的可靠性。读完关于“衡量与改进”的章节后，我立刻组织了一次回顾会议，使用的正是书中推荐的几种非指责性反馈技巧，团队的参与度明显提高了，气氛也变得更开放了。这本书更像是一位资深教练在耳边细语，指引你避开那些常见的“敏捷陷阱”，真正将敏捷思维融入血液，而不是仅仅停留在工具或仪式层面。对于任何身处快速变化环境中的项目经理或团队领导者来说，这本书提供的不仅仅是方法论，更是一种思维模式的重塑，让人在面对不确定性时，能更有底气和清晰的方向感。
从读者的角度来看，这本书的行文风格是极其清晰且富有感染力的。它似乎有一种魔力，能将原本晦涩的专业术语包裹在易于理解的叙事之中。我个人感觉，作者在撰写这本书时，不是在写一份教科书，而是在进行一次深入且真诚的经验分享。特别是书中关于“失败中学习”的态度，非常令人鼓舞。作者没有回避敏捷转型中必然出现的挫折和误解，反而将这些时刻视为宝贵的教学机会。比如，书中关于“冲刺回顾会议（Sprint Retrospective）”的建议，它强调的不是找到“替罪羊”，而是建立一个“安全空间”来进行深刻的内省。这种人性化的处理方式，让这本书充满了温度，而不是冰冷的流程指导。对于新手来说，它提供了稳固的入门基础；对于资深人士来说，它提供了重新审视和优化自己实践的契机。我阅读这本书的过程，更像是一次与行业内最聪明头脑的深度对话，它不仅教会了我工具和技术，更重要的是，教会了我如何以一种更具同理心和适应性的方式去领导和协作。
我花了大量时间阅读了关于技术实践的部分，坦率地说，这本书的深度远超我最初的预期。我原本以为它会更侧重于流程和管理职能，但作者对工程实践的论述，展现了深厚的软件开发背景。特别是关于“持续交付管道（CI/CD Pipeline）”的章节，作者并没有停留在概念介绍，而是深入探讨了在不同技术栈下如何配置自动化测试和部署流程，甚至提到了如何处理遗留系统的集成问题。这种对技术细节的关注，对于现代软件开发团队来说至关重要，因为没有坚实的技术基石，任何敏捷流程都将是空中楼阁。书中对于“技术债务”的讨论也极其深刻，它将技术债务视为一种需要被透明化管理的业务风险，而不是单纯的开发人员偷懒的结果。这种跨职能的视角，极大地帮助我与开发团队进行了更有效的沟通，让我们能够共同权衡快速交付和系统健康之间的关系。我强烈推荐那些希望提升团队工程成熟度的技术领导者仔细研读此书，它提供的不是“你应该做什么”的口号，而是“你可以如何做”的蓝图，充满了实操价值的指导。
A bunch of case studies. 日拱一卒。。
scrum的第一要素是人，只有有经验、有主观能动性的人才能使scrum真正运作起来。但吊诡的问题是，既然有了有经验，有主观能动性的人用什么方法论能有多大的区别呢？
不错的SCRUM 介绍书籍.
A bunch of case studies. 日拱一卒。。
经历过这样的项目模式，再回头看看指导手册，一一对应三个角色、报表、Daily & whole process，又多一层理解，感觉很有趣。
