欢迎光临本店     登录 注册   加入收藏
  •   
欢迎光临清华大学出版社第三事业部!

此页面上的内容需要较新版本的 Adobe Flash Player。

获取 Adobe Flash Player

当前位置: 首页 > 科技 > 计算机与网络 > 软件工程及软件方法学 > 深入核心的敏捷开发:ThoughtWorks五大关键实践

浏览历史

深入核心的敏捷开发:ThoughtWorks五大关键实践

深入核心的敏捷开发:ThoughtWorks五大关键实践

prev next

  • 商品货号:20201209005
  • 商品重量:0克
    作者:肖然,张凯峰
    出版社:清华大学出版社
    图书书号/ISBN:978-7-302-53734-2
    出版日期:20191001
    开本:16开
    图书页数:244
    图书装订:平装
    版次:1-1
    印张:15.25
    字数:333000
    所属分类:TP311.52
  • 上架时间:2020-12-09
    商品点击数:631
  • 定价:¥79.00元
    本店售价:¥79.00元
    注册用户:¥79.00元
    vip:¥75.05元
    黄金等级:¥71.10元
    用户评价: comment rank 5
  • 商品总价:
  • 购买数量:

内容简介:

商品附加资源

内容简介

本书介绍了ThoughtWorks是如何实践敏捷开发的,主题包括测试驱动开发、持续集成、持续交付、全功能团队、需求分析和敏捷转型等。ThoughtWorks经过十多年的实践和沉淀,总结得出一套独特的、切实可行的敏捷软件开发核心原则、核心实践、管理体系和敏捷转型过程。全书共5部分18章,介绍了什么是合理正确的需求分析方法,如何采纳先进和理性的技术,自适应的团队组织形式是怎样的,如何建立客户价值优先的思维,如何持续改善软件交付方法。与此同时,作者也提到了一些可能遭遇的坑,引导读者参与思考什么是敏捷的实质。

本书面向开发者、敏捷咨询顾问、CIOCTO,可以帮助他们顺利导入和实施敏捷。

推荐序1  “大象起舞”,别有一番风景


—— 价值驱动的精益研发转型实录
2019年7月30日早上8:30,深圳南山科技园招行研发大楼,步履匆匆的上班族;8:45,每一层的员工围向各自工作区域的看板,开始每日站会,面对面沟通当天工作。已使用电子看板的开发室组,深圳、杭州、成都三地同事在同一个看板上进行远程即时沟通。9点左右,站会结束,紧张充实的一天开始了——这是招行信息技术部深、杭、蓉三地6500多员工(含外包)每天工作的开始。
从2015年看板和敏捷SCRUM的引入,到2019年7月全面规模化精益研发转型,招行经历了四年多的时间。事实上,规模化精益研发转型并没有相对成熟的可参考的案例,尤其对于监管严格的大型银行科技部门,一路走来,可以说一直摸索着前进。值得欣慰的是,招行有一群致力于工程管理、过程改进,有责任心和使命感的SPI(Software Process Improvement)人,始终紧紧围绕科技的目标及痛点,瞄准“价值”“质量”“效能”,持续开展前瞻性研究、试点,立足当下,着眼未来,脚踏实地,敢于创新,摸索出一条适合招行的精益研发转型之路,这个过程可谓环环相扣、步步为营,推动招行科技在支持全行业务发展的新时期未雨绸缪、占领先机。这个过程中,招行与ThoughtWorks咨询事业部精诚合作,共同探索,为转型输入了先进的理念和方法。
与大多数银行科技组织一样,招行的软件工程管理大体分为三个阶段,如下图所示。

让我们看下几个重要的时间点。
* 2009年和2013年,招行科技分别通过了CMMI2级和3级的认证,建立了软件过程管理体系,项目开发的过程能力和质量相对稳定,积累了软件工程管理、过程改进等方面经验,尤其培养了招行IT人的规范化工程管理素质。
* 2015年,面对互联网金融的冲击和市场竞争,如何提高需求响应速度和交付速度,如何把有限的IT资源投入到更有价值的需求开发中,是摆在科技面前首要解决的痛点。当年,招行与ThoughtWorks合作,开始在个别相对独立的软件产品上试点敏捷SCRUM开发;同年,引入了“看板”在基层开发组织落地,并着手研究和规划DevOps流水线建设,积累了一些迭代开发的经验。
* 2016年下半年,一个问题自然摆在面前,面对业务不断增长的需求及快速交付的呼声,90%的传统开发项目该何去何从?11月,总结敏捷试点经验,秉承循序渐进的改进原则,确定了双模的“精益研发转型”目标和方向。
* 2017年初,招行确定了Fintech战略,首次提出了“科技敏捷带动业务敏捷”的要求。6月,敏捷产品模式从几个业务片区做起,逐步形成套路,开始推广到其他片区。着手培养招行内部的精益教练队伍。
* 2018年9月,总结提炼三年多的经验,确定精益研发管理与工程实践集,明确双模的定义及使用场景,创新提出“过程制定选择”机制,正式发布了 “价值驱动、质量为先”的“精益研发管理体系V1.0”,软件工程管理翻开了新的一页。
* 2019年3月,招行科技启动规模化精益研发转型,截至7月底,近60%科技队伍转入精益研发模式,可以预见在不久的将来,招行科技将全面完成精益研发转型。

值得一提的是:招行不但没有放弃、而是继承了原有软件过程管理体系(CMMI)的框架,保留了原有体系中经过多年验证有效的过程及活动,在此基础上总结、吸收了这几年试点的精益、敏捷的理念及核心实践,重构工程与管理实践集,建立新的价值驱动的端到端的软件生命周期,改变原来串行的来料加工式的开发模式,真正形成从产生想法到上线运营数据分析的闭环。研发模式上,明确“精益项目”和“敏捷产品”两种模式,及相对弹性的定制选择机制。这些是招行精益研发管理体系的核心。
思想上统一认识,行动上才有一致的可能,我们总结提炼了“精益研发”的愿景、目标及四项原则:
* 愿景:打造招行端到端的精益研发管理体系,价值驱动、质量为先,以行业领先的科技能力驱动创新与变革。
* 目标:更高的产品质量,更快的交付速度,更好的客户满意度,更高的研发效能,建立生机型文化氛围。
* 原则:价值驱动,质量为先;快速响应,高效执行;尊重信任,紧密协作;持续改进,追求卓越。

精益原则已纳入招行科技组织级的价值观中。其核心是“价值驱动”,这也借鉴了ThoughtWorks“价值驱动的业务创新管理框架”的理念。这四个字不仅仅是指业务价值,也包含IT自身的价值衡量,比如如何优化IT内部流程,尽可能减少浪费,如何在关键的技术环节强化决策等等。同样,“紧密协作”不仅仅是深化IT与业务的融合,IT内部的开发、测试、运维等等,也需换位思考,紧密协作。
招行始终坚持走演进式而非颠覆性的持续改进之路,注重“体系化、结构化、规范化”,时刻聚焦转型的“愿景和目标”。2017年,招行Fintech战略的落地,也推动了业务部门的思想转变,使IT与业务融合走向深入,为精益研发转型提供了有利的条件。
规模化转型落地方面,继续发挥EPG(Engineering Process Group)工作组牵头作用,从愿景和目标分解出几大专项工作,强化组织级的推进,逐年扎实落地,
* 重构软件过程管理体系及资产库。战略上,“愿景-目标-原则”,层层分解、保持统一;战术上,“领域-实践-定制选择”,针对每一个跨职能交付团队的痛点和目标,定制选择合适的开发模式和实践(含管理实践和工程实践)。
从业务(产品)片区入手、相对弹性的定制选择(而非全盘强制执行)、变“要你做”为“我要做”,是招行精益研发管理体系的一项创新。定制重点考虑的因素有:业务战略重点、需求的连续性及特点、软件交付期望、业务架构与系统架构状况、CICD成熟度、业务方的能力与参与度、资源情况等等,针对性地选择相匹配的研发模式及实践,形成各自特色的实施方案,重点强化业务IT紧密协作,真正解决研发过程中的痛点与难点。
同时,根据产品发展的状态及市场绩效的变化,定期对方案进行适应性检视,并提供研发模式之间的转换及多模的协同机制。
* 全面推行精益看板。看板是招行最早引入的精益实践,招行一开始就把看板定位于基层开发室组(<=12人)的跨组织管理与工程管理的工具(而不仅仅局限于迭代管理),建立了招行看板应用的成熟度模型,全面推广,逐年提升应用能力。推广的前期侧重于组织管理,后期随着精益研发的深入,与新的软件生命周期紧密结合,侧重于工程管理及效果,聚焦资源效率和流动效率,与精益转型形成1+1>2的态势。看板的全面推广,在工作透明化、限制在制品、加快工作流动、高效沟通、建立自组织文化氛围、提高基层小组织的活力等方面发挥了重要作用。
2017年,招行开始着手电子看板的自主开发,截至2019年7月,已有2/3的物理看板迁移到电子看板,在功能上与项目管理、DevOps流水线、度量分析平台等实现无缝链接,可以说开辟了大规模IT组织研发过程数字化的崭新道路,未来也必将是招行精益转型取得更大成效的重要利器之一。
* 建立持续交付的DevOps流水线。工具平台对研发管理来说可谓如虎添翼。DevOps在招行精益研发体系中占据重要位置,也是规模化精益转型的核心支撑。早在2015-2016引入敏捷SCRUM的同时,招行即着手研究“DevOps”理论与实践,2017年形成招行的DevOps实施框架和路线图,并提出目标:建立适应招行特点的端到端的持续交付“高速轨道”,更快地交付高质量的软件产品,全面支持精益研发转型。几年来,招行大力投入资源推进工具平台建设,优化整合原有的工具资产,并将精益管理实践和工程实践有机结合,形成工具生态链,为规模化转型提供了强有力的支撑。
* “精益需求分析”,转型的核心实践,没有之一。要达成“价值驱动、快速迭代交付”的目标,必然要求在需求侧做好两件事:一是结构化分解业务目标,做好价值分析与决策;二是分解及细化需求,形成MVP,建立和维护需求动态优先级列表,做好版本规划。这两点是精益需求分析的根本目的,也是研发转型的前提。传统项目开发始终困扰的需求不清晰、需求分解问题(结构化、条目化)、无法排出优先级、需求价值无法衡量和验证等诸多问题,在精益需求分析实践中一一考虑解决。这是个艰巨的任务,但又是PO或BA必须掌握的能力,唯有迎难而上。
* 内部赋能,能力自建。2015—2016年招行与ThoughtWorks合作引入敏捷Scrum期间,当时的教练主要以外部为主,2017年起,招行开始建立内部教练的培养机制,加大内部精益教练(包括管理方向、技术方向)的培养力度,因为我们认识到,面对几千人的规模化精益转型,仅靠外部资源远远不够,培养内部教练队伍,加强能力自建,才能更好做到及时响应、务实有效,也才能走得长远。两年多时间,招行培养了近100位的精益教练,开展各项社区、开放日活动,营造精益敏捷文化氛围。不但QA队伍全面转型精益教练,各开发团队也逐步培养自己的教练队伍,一方面在转型中辅导内训、反馈问题,发挥布道者作用,另一方面这支队伍在适当时候转身QA角色,开展背靠背的审计活动,监督执行过程,自我发现问题,自我持续改进。
* 建立精益研发度量体系。数据让我们知道现在的能力与目标的差距,了解自己的现状,为管理决策提供依据。度量分析是招行从CMMI2级就开始建立的组织级重要能力,多年来招行坚持用数据说话,所谓“来自一线、服务一线”。精益研发转型,也同样从愿景和目标分解出可度量的指标,同时优化度量分析平台,与电子看板等数字化管理工具结合,为项目、团队、组织级提供及时的指标数据,助力转型效果的自我量化分析。

“不忘初心,方得始终”,每年底,EPG工作组对标精益转型的愿景与目标,组织专题研讨,提出下一年度的目标和具体行动计划,采取“方案-试点-验证-形成规范-发布推广”策略,协同作战,稳步推进。研发模式与实践的定制选择、自我能力建设、自我度量分析、自我回顾改进等,逐步形成良性循环,自驱式的生机文化在招行科技队伍中慢慢生根发芽,也即将蔚然成风。
当前,招行科技又提出“从精益研发到精益组织”的目标,可预见的未来必然是:“大象起舞”别有一番风景——转型,我们仍在路上。

欧红
招商银行总行信息技术部  项目办&EPG负责人
过程改进与管理变革资深专家
2019年8月19日,深圳


推荐序2
ThoughtWork敏捷开发的四大经济价值



15年前,ThoughtWorks开始在中国技术社区推广敏捷开发理念和实践,由一开始被认为是一小撮离经叛道者的游戏,逐渐生根发芽,被越来越多的实践者所接受。特别是最近几年,商业环境的变化节奏不断加快。科技,特别是软件,正是在这种变化的驱动下开始在业务当中扮演核心角色。这些变化倒逼着企业寻求突破,采用高响应力的软件开发模式,其影响也延伸到了商业的组织模式。
ThoughtWorks不是一家互联网公司,却是一家数字原生的组织。我们一直吸引追求卓越的专业人士,打造学习型的组织,寻求更好的方法应用科技来解决复杂商业问题。更重要的是,我们与一群难能可贵的客户合作。这些客户有的是以互联网模式运营的数字化公司,也有正处于积极转型当中的百年企业。他们的业务和组织差异巨大,但都有个共同点,就是拥有锐意进取、勇于变革的领导团队。ThoughtWorks和这些组织一起,探索适合业务发展的技术和方法,共创科技驱动的数字化组织。在这个过程中,一线团队并不死守教科书式的各大敏捷流派,而是在明确核心原则的基础上,在一线生产的热土中,反省和提炼经验,总结核心实践。本书就是这些实践的生动呈现,并且深入分析了这些实践所处的组织和管理生态,最后以企业实际所经历各个发展阶段的演进案例,以及采样丰富的行业分析,描述了这个领域从微观到宏观的动态。
最近,Forrester在对大量ThoughtWorks客户调研之后,撰写了关于总体经济影响(Total Economic Impact)的研究。报告以量化的度量,总结了ThoughtWorks方法为各种商业组织所带来四个方面的经济价值:
* 通过更快将产品和服务投入市场提升营收
* 通过缩短新客户导流的周期加速营收的产生
* 减少维护遗留系统的成本
* 减少新开发系统的维护成本

但是,要让实践持续发挥上述商业价值,除了需要软件开发团队不断学习,刻意练习,以至于能够娴熟地运用书中的核心实践以外,还需要团队所在公司文化和结构上的配合,也就是要把敏捷理念和方法融入运营的流程、预算和政策,我们称其业务敏捷。
来自一线开发团队的总结让本书的实操性区别于世面上的其它书籍。希望本书能为打算采纳敏捷方法的团队提供有价值的参考,帮助已经起步、正在持续改进的团队提供努力的目标。

张松
ThoughtWorks中国区总经理  


目录


序曲  ThoughtWorks的敏捷开发    1
第Ⅰ部分  核 心 原 则
第1章  敏捷宣言到底有几句    19
为什么写此文    19
敏捷宣言到底有几句    20
第2章  开发人员的客户思维    23
开发人员与客户思维    24
第Ⅱ部分  核 心 实 践
第3章  基于统一迭代节奏的全功能团队    33
从汽车贴膜看专业团队    33
团队的精进之道    37
第4章  基于用户故事的需求及范围实时管理    41
估算的目的    41
需求风险的坏味道和对策    44
需求的冰川    50
浅谈软件项目规模估计,到底在估什么    53
软件项目规模估计,怎么估?    57
第5章  基于持续集成和测试前置的质量内建    63
关于Gitflow    63
改善单元测试的新方法    68
超越“审,查,评”的代码回顾    74
不做代码审查又怎样    76
敏捷实践之提前验收    82
让我们再聊聊TDD    85
结对编程的正确姿势,你学会了吗?    89
第6章  基于效能和周期时间的持续改进    95
看板和利特尔法则    95
点之殇    100
高效回顾会议的七步议程    107
第7章  组建人人深度参与的统一团队    111
开不好站会?因为不同阶段站会的目的不一样    111
展示会的七宗罪    114
浅谈敏捷离岸团队沟通    119
第Ⅲ部分  管 理 体 系
第8章  为什么你的Scrum会失败?    129
三个角色    130
四个会议    132
第9章  技术领导者即服务    135
责任拆解    136
技术栈管理    137
第10章  项目管理中的敏捷实践    139
敏捷的项目管理:追求最大价值的成功    140
那么,这个定义是正确的吗?    141
用户故事    142
估算和迭代计划    143
迭代会议和功能演示    144
站会和用户故事开卡    145
代码审查和回顾    145
最大程度的可视化    147
沟通计划    148
结语    150
第11章  也谈精益    151
追求快速价值交付的小批量生产模式    152
追求极致卓越的生产匠艺    154
结语    155
第Ⅳ部分  转    型
第12章  团队敏捷转型的三个阶段    159
阶段一(Agile 0~1):建立敏捷流程,缩短交付周期    160
阶段二(Agile 1~3):引入技术实践,质量内建,减少返工    161
阶段三(Agile 3~5):提升价值交付效率和响应力    165
结语    166
第13章  绩效考核,敏捷转型的鸿沟    167
敏捷转型过程中的必然挑战    167
传统绩效考核    169
绩效考核的困境    170
如何破局?    171
第Ⅴ部分  案    例
第14章  一个交付故事    179
技术带来的新挑战    179
自治团队的演化    181
第15章  又一个交付故事    185
明线:所有权?经营权?决策权?监督权?    185
暗线:寻找时间之矢    188
第16章  一个遗留系统自动化测试的七年之痒    191
背景    191
七年之痒:痛点    191
问题分析    192
解决问题    193
第17章  如何在团队建设工程师文化?阿里资深技术专家这么做    197
工程师文化与KPI文化    197
敏捷    200
基础技术团队实践    200
第18章  敏捷转型下的团队管理:来自一线管理者的思考    207
管理者的“神光”并不总是好事    209
敏捷转型下管理者应该如何自处?    210
需要团队管理者首先要做到信任和放手    210
自组织团队需要适度的灰度管理作为土壤,以管理者的自律来浇灌    210
附录  2017中国企业敏捷实施的调查与反思    213
参考文献    225

 

 

商品标签

购买记录(近期成交数量0)

还没有人购买过此商品
总计 0 个记录,共 1 页。 第一页 上一页 下一页 最末页

用户评论(共0条评论)

  • 暂时还没有任何用户评论
总计 0 个记录,共 1 页。 第一页 上一页 下一页 最末页
用户名: 匿名用户
E-mail:
评价等级:
评论内容:
验证码: captcha