看板方法：科技企业渐进变革成功之道 [Kanban: Successful Evolutionary Change for Your Technology Business] 下载 mobi epub pdf 电子书 2024

☆☆☆☆☆
简体网页||繁体网页



点击这里下载

类似图书 点击查看全场最低价

---

编辑推荐

　　看板方法是近年来软件开发社区流行的新型管理方法，它能在不大幅改变原有开发流程的情况下，有效提高开发效率。它最突出的两个特点：实施阻力小、切实有效。这也正是它迅速走红的原因。

内容简介

　　《看板方法：科技企业渐进变革成功之道》由看板方法创始人David J. Anderson亲自编写，是看板方法的奠基之作。看板方法脱胎于丰田生产方式和约束理论，是精益方法的进一步延伸。它将软件开发过程视为一种价值流，并且相信拉动式的管理能产生更好的结果。它通过限制在制品的数量等一系列简单可行的技巧，发现和缓解软件开发过程中的压力和瓶颈，提高生产效率。看板方法的奇妙之处，在于它与企业原有的开发流程无缝结合，在不知不觉中提高生产效率。换句话说，它是一种渐进式的改良，不是翻天覆地的革命，因而更容易被企业接受。实施阻力小且切实有效是看板方法在软件开发社区中迅速流行起来的原因。

作者简介

　　大卫·J.安德森（David J. Anderson），有三十多年IT行业从业经验，曾在多家大型跨国企业管理软件开发团队，拥有丰富的团队管理经验。他是精益软件和系统协会（Lean Software & Systems Consortium）的创始人，并且创办了David J. Anderson & Associates咨询公司和LeanKanban培训公司，致力于传播和推广精益思想和看板方法。

精彩书评

　　★“本书既是看板方法的快速上手指南，又提供了丰富的理论内容。每次阅读我都有新的收获。”
　　——Chris Simmons Sophos公司开发经理

　　★“使用看板方法奇迹般地改善了公司的业务状况。阅读本书，我现在理解个中原因了！”
　　——Alission Vale Phildelis公司创始人

目录

第一部分 导论
第1章 解决敏捷管理者的困境
1.1 我对可持续步调的探索
1.2 我对成功变革管理的探索
1.3 从“鼓-缓冲-绳”转向“看板”
1.4 看板方法的出现
1.5 看板方法被社区采纳的过程
1.6 看板的价值是反直觉的
第2章 什么是看板方法
2.1 什么是看板系统？
2.2 把看板应用于软件开发中
2.3 为什么使用看板系统？
2.4 看板方法模型
2.5 识别看板方法的应用实施
2.6 作为权限授予者的看板

第二部分 看板方法的益处
第3章 一种成功秘诀
3.1 使用秘诀
3.2 成功秘诀和看板方法
第4章 在五个季度内，从最差变为最好
4.1 问题
4.2 可视化工作流程
4.3 影响效能的因素
4.4 明确过程策略
4.5 估算是一种浪费
4.6 限制在制品
4.7 建立输入节奏
4.8 达成新契约
4.9 实施变革
4.10 调整策略
4.11 寻求进一步的改善
4.12 成果
第5章 持续改进的文化
5.1 改善文化
5.2 看板方法会加速组织成熟度和能力的提升
5.3 社会学变革
5.4 文化变革也许是看板方法带来的最大好处

第三部分 实施看板方法
第6章 价值流映射
6.1 定义控制起点和终点
6.2 工作项类型
6.3 绘制卡片墙
6.4 请求分析
6.5 根据请求分配产能
6.6 工作项卡片详解
6.7 电子跟踪
6.8 设置输入和输出边界
6.9 应对并行活动
6.10 应对次序无关的活动
第7章 使用看板进行协调
7.1 可视化控制和拉动
7.2 电子跟踪
7.3 每日站立会议
7.4 会后讨论
7.5 队列填充会议
7.6 发布规划会议
7.7 鉴别分类
7.8 问题日志的审查与升级
7.9 现场贴纸代理
7.10 跨多个地理位置保持同步
第8章 建立交付节奏
8.1 交付的协调成本
8.2 交付的事务成本
8.3 交付效率
8.4 确定交付节奏
8.5 通过提高效率来提升交付节奏
8.6 进行随需或临时交付
第9章 建立输入节奏
9.1 优先级排序的协调成本
9.2 确定优先级排序节奏
9.3 优先级排序的效率
9.4 优先级排序的事务成本
9.5 提高效率以支持更频繁的优先级排序节奏
9.6 进行随需或临时性的优先级排序
第10章 设置在制品限额
10.1 工作任务的限额
10.2 排队队列中的限额
10.3 瓶颈前的缓冲
10.4 输入队列大小
10.5 工作流中不设WIP限额的区域
10.6 不要使组织压力过大
10.7 不设置在制品限额是错误的
10.8 产能分配
第11章 建立服务水平协议
11.1 服务类别的一种典型定义
11.2 为服务类别设置规则条款
11.3 确定服务交付目标
11.4 设置服务类别
11.5 应用服务类别
11.6 根据服务类别来配置产能
第12章 度量和管理报告
12.1 跟踪在制品
12.2 前置时间
12.3 准时交付率
12.4 交付速率
12.5 问题和受阻工作项
12.6 流动效率
12.7 初始质量
12.8 破坏负载
第13章 使用两层系统扩展看板
13.1 层次化的需求
13.2 将价值交付和工作项的变异性解耦
13.3 两层卡片墙
13.4 引入泳道
13.5 应对规模变异性的另外一种方法
13.6 和服务类别结合在一起
13.7 系统集成
13.8 管理共享资源
第14章 运营回顾
14.1 会前准备
14.2 在开始时设置好业务基调
14.3 邀请嘉宾扩大听众范围并带来附加价值
14.4 主要议程
14.5 精益转型的基础
14.6 适宜的节奏
14.7 体现管理者的价值
14.8 组织层面的专注能培育改善文化
14.9 一个早期案例
第15章 启动看板变革
15.1 看板系统的首要目标
15.2 看板系统的次要目标
15.3 理解目标，阐明益处
15.4 实施步骤
15.5 看板方法带来新的谈判模式
15.6 启动看板实施的谈判

第四部分 继续改进
第16章 三类改进机会
16.1 瓶颈、消除浪费和降低变异性
16.2 看板方法与公司文化的适配
第17章 瓶颈和非即时可用资源
17.1 能力受限资源
17.2 非即时可用资源
第18章 精益的一种经济学模型
18.1 重新定义“浪费”
18.2 事务成本
18.3 协调成本
18.4 如何识别一项活动是否是成本
18.5 破坏负载
第19章 变异性的根源
19.1 变异性的内部根源
19.2 变异性的外部根源
第20章 问题管理和升级策略
20.1 对问题的管理
20.2 问题升级
20.3 问题跟踪和报告
参考文献
致谢
索引
关于作者

精彩书摘

　　1．1我对可持续步调的探索　　2002年，敏捷社区将可持续步调简单解释为“每周工作40小时”。 《敏捷宣言的原则》告诉我们：“敏捷过程倡导可持续开发。出资人、开发者和用户应共同维持一个长期稳定的步调”。两年前，Sprinl PCS公司的团队已经普遍认同了我的观点，“大型软件开发是一场马拉松，不是短跑冲刺”。如果要求项目成员在持续18个月之久的长期项目中保持步调，那么绝不能让他们在头一两个月就精疲力竭。必须为项目制订计划、预算成本、进行调度和估算，以确保团队成员每天合理的工作时间，避免他们过度疲劳。作为经理的我，所面临的挑战是，在实现这一目标的同时，还要能够确保满足所有的业务需求。　　1991年，我首次在一家成立已经5年的创业公司里从事管理工作，该公司主要制造面向个人计算机与其他小型计算机的视频采集卡。我从CEO那里获得的反馈信息是，领导认为我“非常消极”。我们的开发能力已经达到极限，而领导却仍然要求增加更多的产品特性，这时我总是以“不行”断然拒绝他们。2002年以前，我形成了一种明显的模式：一直以“不行”这种拒绝的方式，抵挡来自业务方持续不断和善变的需求。　　软件团队和IT部门似乎总会遭遇被其他组织任意摆布的悲惨命运。即使计划已经做得无懈可击、公正客观，这些组织仍然会对他们极尽软磨硬泡、恐吓威逼之能事。即使是基于深入分析、有多年历史数据支持的计划，在这些组织面前也会变得脆弱不堪。大多数团队则是既没有透彻的分析方法，又没有任何历史数据支持，在那些想要迫使他们承诺未知的（通常是完全不合理的）交付期限的权术手腕下，他们无疑势单力薄而只能任其摆布。　　与此同时，软件工程师也已经基本上接受了疯狂的进度表和献身工作的荒谬言论，并对此司空见惯。软件工程师好像本不该拥有社交活动和家庭生活似的，这真是莫大的羞辱！我知道有太多人因献身工作而影响了和家庭成员的关系，并因此蒙受了不可弥补的损失。但要人们对那些身处主流的软件开发极客（geek）表示同情却很难。在我居住的美国华盛顿州，软件工程师的年收入仅次于牙医。就像20世纪20年代福特汽车装配线上的那些工人一一样，其收入是美国平均工资的五倍，由于他们的报酬丰厚，没有人会考虑他们工作的单调性或身心的幸福感。很难想象，在诸如软件开发这样的知识工作领域会涌现出劳工组织；没人会从根本上去解决软件开发者日常遭遇的生理和心理方面疾病的问题。　　……

前言/序言

　　自有软件开发活动以来，在软件工程界和软件开发社区中，一直有不少先行者和实践者在积极探索如何更高效地组织团队进行高质量的软件开发活动。敏捷方法和精益方法正是近十几年来，从这波潮流中涌现的最精彩夺目的两项成果。敏捷方法和精益方法的大伞，覆盖多种软件开发方法学，其中最具代表性的有Scrum、极限编程等，它们以《敏捷宣言》定义的价值观为基石，构成了这张大伞的一半幅面，另外一半幅面则由以精益价值观为基石的方法学组成，其中最具代表性的是由Poppendieck夫妇共同创立的精益软件开发方法（lean software devleopment）。本书所介绍的看板方法，则是精益阵营中涌现的一种不可忽视的新方法。
　　看板方法，由David Anderson创立，它脱胎于大野耐一所创立的丰田生产方式（TPS），以及埃利亚胡?高德拉特（Eli Goldratt）的约束理论（TOC），并结合统计质量控制（SQC）、排队论（QT）、工业工程（IE）、软件成熟度模型（CMMI）等多个领域的知识，在软件开发社区中获得了极高的关注度，并迅速传播开来。
　　David在从事软件开发管理的实践经历中，发现商业组织中的软件开发团队经常产生过载现象。这对软件开发者带来了深深的伤害，反过来也伤害了商业组织，因此他期望找到一种双赢的软件开发模式，寻找到一种系统性的途径，能够带来可持续的步调，既有利于软件从业者，也有利于商业组织。同时，作为变革推动者，David还发现，在团队中导入新技术总是不可避免地会遭遇到阻力。他领悟到，必须寻找到一种能够使变革阻力最小化的方法才行，最好的策略便是从团队当前状况出发，采取逐步改善的变革引导方式。这两个方面，是David创立看板方法的两个基本动机。
　　看板方法采用了精益的思维范式，将软件开发视为一个价值流（Value Stream），并且基于拉模式来驱动其流动。“价值流”是精益思想和看板方法的基础隐喻，基于这个隐喻，引申出来的是一系列其他元素，例如，拉动（pull）、在制品（WIP）、批量规模（batch size）、前置时间（lead time）、阻塞（block）、瓶颈（bottleneck）、缓冲区（buffer）、吞吐量（throughput）、改善（kaizen）等。改善是精益和看板方法的精髓，它旨在通过持续性地实施系统性变更来优化生产系统。
　　看板方法的各种设计元素，为质量和过程中的问题提供了可见性，能够迅速暴露价值流中影响效能的问题，从而引导团队专注于解决问题以维持稳定的流动。通过帮助软件团队建立稳定的工作节奏，实现始终如一的可靠交付，看板方法能够在开发团队与客户、相关部门、供应商、价值流下游合作伙伴之间建立信任关系，从而建立具有高度协作、高度信任、高度授权和持续改进特征的组织文化。
　　软件开发中的看板方法本身还在不断发展过程中。作为本书的中文版译者，我非常荣幸能够把这本奠基之作介绍给中国的敏捷和精益软件开发社区。期待本书能够给社区带来新的视角和启迪，更期待国内社区对看板方法的实践能够反过来促进看板方法的进一步发展。
　　祝大家都能够精通保持平衡和持续改善的艺术！
　　章显洲
　　支付宝高级技术专家
　　2013年11月5日于杭州古荡
看板方法：科技企业渐进变革成功之道 [Kanban: Successful Evolutionary Change for Your Technology Business] 下载 mobi epub pdf txt 电子书 格式

评分☆☆☆☆☆

给老公买的，他说还不错，推荐下

评分☆☆☆☆☆

不咋地，内容太老了，描述生硬无趣，毫无实用价值。

评分☆☆☆☆☆

还没看，京东正版，不用去书店

评分☆☆☆☆☆

东西内容不错 问题是我买错了 印刷质量一般

评分☆☆☆☆☆

很不错的书籍，很好看，适合程序员

评分☆☆☆☆☆

还没看。。。。。。。

评分☆☆☆☆☆

内容不错，很多实践经验值得借鉴。

评分☆☆☆☆☆

强烈推荐，非常好的一本书

评分☆☆☆☆☆

看了别人的，觉得好于是自己也买了一本。很不错的敏捷方法，不止适用于科技gongsw

类似图书 点击查看全场最低价