Scrum敏捷软件开发

Scrum 敏捷软件开发前言要的改变,如程序员、测试人员、项目经理等。第9章介绍一些技术实践,包括持续集成、结对编程、测试驱动开发等,这些技术实践应该使用,至少也要做些尝试,它们会使每个人的日常工作方式有很多变化。在第I部分中,我们向外扩展到团队的话题。我们首先关注如何设计 Scrum团队的结构,以充分体现 Scrum的优势。然后,第11章阐述在 Scrum项目中团队协作的本质。第12章将一起来看在Scum中领导一个自组织团队意味着什么。在这一章,我具体针对 Scrummaster、职能经理和其他领导者给出一些建议。第13章至第15章通过对 Sprint、计划和质量的讨论完成第m部分内容。第IV部分,我们进一步扩展到企业级别的话题。在第17章,我们将进一步研究如何把 Scrum扩展到更大的工作范围,跨团队的项目中必须要做哪些事等。第18章考虑分布式团队的更多的复杂性。然后,在第19章进行更加复杂的讨论,谈谈如何在一个部分使用瀑布式流程的项目中使用 Scrum,在有监管需求时如何处理。第ⅣⅤ部分以第20章作为结尾,这一章特别讨论 Scrum对公司的人力资源后勤及PMO等部门的影响第ⅴ部分包含两章。第21章归纳企业敏捷转型的各种度量方法。第22章对全书进行小结,并且再次阐明只有持续改善才能做到真正的敏捷。不论你今天已经做得有多好,为了保持敏捷,你下个月必须做得更好!关于术语像大多数情况一样,笔论Scrm比仅仅口头讨论它要难一些读者在阅读时,一不小心就会误读一个句子或者脱离语境去理解它。为了避免这样的问题,我在使用一些术语时尽量小心并且精确。比如,我使用“开发人员”这个词时,我是指在项目中参与开发的任何一个人。它包括程序员、测试员、分析师、用户体验设计师、数据库管理员等术语“团队”也有它自己的问题。它当然包括开发人员,但是“团队”包括ScrumMaster和产品负责人吗?自然,它也取决于语境。当我需要精确表达时,2 Scrum敏捷软件开发我使用“整个团队”来指所有的人:开发人员,产品负责人和 ScrumMaster。然而盲目地使用“整个团队”会降低本书的可读性。所以有时你还是会看到“团队”,通常是在所指含义非常明确的地方。除 Scrum及敏捷团队外,我也需要一个术语来专指那些两者都不是的团队。在不同的地方,我曾使用“顺序式团队”、“传统型团队”和“非敏捷团队”等术语,它们每一个之间有细微的含义差别并恰如其分地用在不同的地方。本书使用说明很多书的前言都有这样的小节标题。但是这些标题通常是在说“如何阅读本书”。阅读这本书最好的办法是使用它。不只是停留于阅读。当你遇到“试一试”时,停下来试一下。或者在我有特别建议的地方,记住它们然后在下一次回顾会议或者计划会议的时候尝试用一用不必按照章节的顺序阅读本书。事实上有可能有些章节你根本没有必要读。如果你在计划方面已经没有问题,或者是没有分布式团队,你只是应公司的期望要求做得更好而已,尽可以把相关的章节全部跳过。但是,我建议每个人都至少通读前4章并且按照顺序阅读——它们是后面所有章节的基础第4章介绍“改进社区”和“改进 Backlog”想法。改进社区是指一组志同道合的个体,他们热衷于推动企业的在某一个方面的改进。改进社区可能由这样三种人组成:他们热衷于改进产品 Backlog;决定收集相关的最佳实践;在团队间共享。另外的改进社区有可能包括几百个热衷于改进公司测试活动的人。改进Backlog正如其名,是一个排好序的、改进社区的任务列表。我希望改进社区能使用本书来实施他们的改进 Backlog,包括指导及推动转型的企业转型社区(ETC。事实上有些章节的标题被特意地命名以使其能直接进入改进 Backlog。例如,第13章的“把文档转化成讨论”,第14章的“在当前的 Sprint中为下一个 Sprint做准备”,第16章的“在不同层次上进行自动化”等等。前言作为一个有多年经验的 Scrum培训师和顾问,我曾服务于几百个团队和公司,我相信Scrm可成功适用于每个公司。有些公司比其他公司可能难一些。有些公司会因为强势的公司文化而面临挑战,还有的会因一些顽固的难以变通的人而造成人员损失。在一些幸运的公司,会得到管理层的支持并积极鼓动员工参与。但是,所有这些公司的共同点是,他们都需要实用的、经过证明的建议。我写作本书的目的就是为他们提供这样的建议。目录第1章为什么敏捷转型难(但值钱渴望提升具之第部分33能力………………为什么转型困难…能力开发工具…………34成功的变革不是完全的自上而下推广…………或者自下而上……Scrum推广工具结束状态是不可预知的传递Scrum是无处不在的“企业重力”的来源41是截然不同的44承前启后变化来得比以往更快………1045延伸阅读……最佳实践是危险的1011第3章 Scrum实施模式.为什么值得投入更高的生产力及更低的成本…13小团队试点,还是全面转型员工的参与度和工作满意度增强15选择小团队试点的原因更快的产品上市时间16选择全面转型的原因……4917更高的质量……在全面转型和小团队试点之间项目干系人的满意度提升…………180选择现在的做法已经不再有效19公开敏捷,还是悄悄行动5120承前启后……选择公开展示敏捷的原因522053延伸阅读…选择悄悄行动的原因……第2章 ADAPT模型从公开展示和悄悄行动中做出4选择5意识5527crm的推广模式意识开发工具………5529先拆分后播种渴望艺2 Scrum敏捷软件开发先成长后拆分关注实际相关的目标….82内部教练鲁香非。看e·垂·。音垂●非。章57改进社区的成员优先选择先拆分后播种模式的原因.57解散社区非鲁非非非。,非·非非非非选择先成长后拆分模式的原因58种尺寸不能适合所有的…85选择内部教练模式的原因承前启后85选择你自己的方式59延伸阅读…185引入新的技术实践60第5章试点项目87马上开始的原因61选择试点项目…17推迟尝新的原因理想试点项目的四个属性.…最后一点考虑.延伸阅读…64选择合适的时机启动项目…濒临失败的项目91第4章渐进敏捷选择试点项目团队改进 Backlog68试点项目不成功会怎样94企业转型社区…垂非章垂鲁·非音·非音,自音非70设定和管理期望……95ETC的 Sprint…......,172关于进度的期望…95发起人和产品负责人……73关于可预测性的期望ETC的职责……174关于对 Scrum态度的期望…改进社区…番自卷。。鲁·非关于参与程度的期望…98改进的催化剂78不过是个试点项目有效性的两个度量指标…79延伸阅读。。垂100改进社区 Sprint第Ⅱ部分个体第6章克服抵触从领导那里听到107预见抵触从同伴那里听到108哪些人会抵触个体抵触的方式和原因瀑布深信症和敏捷恐惧症106怀疑论者…关于变革的沟通……107破坏者15目录顽固分子…1116架构师151追随者119不编码的架构师………152把抵触视为一个有用的危险信号121职能经理……153延伸阅读122职能经理的领导角色153第7章新角色123人员管理职责…155程序员….15ScrumMaster的角色,123数据库管理员.157优秀 ScrumMaster的品质124测试员…157技术带头人担任 ScrumMaster127用户体验设计师160内部或外部的 ScrumMaster…128三个常见主题…163轮流担任 ScrumMaster∴…129延伸阅读163克服共同的问题.130产品负责人第9章技术实践65132产品负责人的职责132追求技术进步165每个团队只需要一个产品负责人….135测试驱动开发…166优秀产品负责人的品质……138重构169ScrumMaster担任产品负责人…139集体所有权…171克服普遍问题…140持续集成∴…172新角色,老责任结对编程174延伸阅读.143设计:有意的而又是涌现式的.176第8章角色转换178145习惯于不做大型设计引导设计179分析员145技术实践的改进并不是可有可无的…82项目经理.…148延伸阅读182为什么头衔要发生变化∴150第Ⅲ部分团队第10章团队结构为什么两个匹萨就够了…191给他们两个匹萨小团队的效率1925 Scrum敏捷软件开发支持特性团队195承前启后∴232保守地使用组件团队……197延伸阅读233谁来做这些决定?第12章领导自组织团队235今天对,明天可能错201自组织不等于随意组合影响自组织团队07236一人一个项目…205容器、差异与交流237任务太多的时候,花在单一任务上的选择外部环境………245时间会减少定义绩效245206何时可以多任务管理思想……246208公司的多任务表引入替换选择系统24609立刻停止247209给系统注入能量…良好的团队结构指导原则……1211领导力远不仅限于买匹萨249承前启后延伸阅读249…213延伸阅读213第13章产品 Backlog…251第11章团队协作215从文档到讨论的转变……252拥抱团队责任制切勿良莠不分21254培养团队承诺.21在产品 Backlog中使用用户故事255。,·着非。音春非依赖专家但须谨慎.…持续地提炼需求…258所有工作总是逐渐完成……20涌现的需求…258不要等到spnt快结束时才完成产品 Backlog冰山…29所有任务.…221为什么要持续地提炼需求?…261承诺完成不同粒度的产品 Backlog对用户故事的持续提炼262事项…222学会在没有详细说明书的情况下开始.266鼓励团队学习通过事例说明……1267223确保学习环境223跨职能的团队能降低对文档的设计学习型团队需求224消除知识浪费228创建DEEP的产品 Backlog271通过承诺鼓励合作…不要忘记讨论…271230