登入帳戶　 |　訂單查詢　 |　購物車/收銀台(0)　|　在線留言板　 |　付款方式　 |　聯絡我們　 |　運費計算　 |　幫助中心　|　 加入書簽
	全部範圍 - 圖書 - 　- 中文簡體書(大陸書) - 　- 英文書（原版） - - 音碟 - 　- 音樂 - 　- 影視 - - 雜誌 - 全文 精確	會員登入 新註冊 |　新用戶登記

HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類閱讀雜誌

香港／國際用戶

最新/最熱/最齊全的簡體書網

品種：超過100萬種書，正品正价，放心網購，悭钱省心

送貨：速遞 / EMS，時效：出貨後2-3日

新書推薦： 《 你的认知正在阻碍你 》 售價：NT$ 296.0 《 我们身边的小鸟朋友：手绘观鸟笔记 》 售價：NT$ 356.0 《 拯救免疫失衡 》 售價：NT$ 254.0 《 收尸人 》 售價：NT$ 332.0 《 大模型应用开发：RAG入门与实战 》 售價：NT$ 407.0 《 不挨饿快速瘦的减脂餐 》 售價：NT$ 305.0 《 形而上学与存在论之间：费希特知识学研究（守望者）（德国古典哲学研究译丛） 》 售價：NT$ 504.0 《 卫宫家今天的饭9 附画集特装版（含漫画1本+画集1本+卫宫士郎购物清单2张+特制相卡1张） 》 售價：NT$ 602.0

建議一齊購買： + NT$ 656 《 敏捷软件需求：团队、项目群与企业级的精益需求实践 》 + NT$ 621 《 看板方法：科技企业渐进变革成功之道（看板方法之父大卫 安德森开山之作） 》 + NT$ 656 《 管理3.0：培养和提升敏捷领导力 》 + NT$ 656 《 Scrum敏捷软件开发 》 編輯推薦： 大规横敏捷软件开发领域经典著作，由HP公司3位均拥有20年左右从业经验的敏捷先锋撰写，ThoughtWorks公司执行顾问Jim Highsmith作序推荐，Amazon全五墨评价 全面展示跨越3个洲、4个国家和4个业务单位，拥有400位开发人员的大型团队成功实施敏捷方法获得巨大成功的全部过程和宝贵经验，为大规模开发团队应用敏捷方法提供详细指导 內容簡介： 《大规模敏捷开发实践：hp laserjet 产品线敏捷转型的成功经验》是大规模敏捷软件开发领域的经典著作，是世界一流it 企业成功实施大规模敏捷的经验结晶。来自惠普的3 位作者均是有近20 年从业经验的敏捷先锋，以故事的形式详细地阐述了他们亲历的 laserjet 产品线成功实现敏捷转型的完整过程、具体方法和宝贵经验，被奉为大规模敏捷软件开发领域的经典案例，为大型组织或大规模敏捷开发团队应用和实施敏捷方法提供了详细指导。 全书共16章。第1～5章介绍了大型组织推行敏捷方法的基础，如敏捷的原则和实践、如何让敏捷辅佐业务目标、如何让架构支撑业务目标、如何用敏捷理念稳固新的架构、大型组织实施敏捷的关键等；第6～7章详细介绍了大型企业实施敏捷需要使用的工具和方法，并通过案例讲解了如何用敏捷方法对现有项目或产品进行改进；第8～16章则详细讲解了hp laserjet 产品线成功实施敏捷的完整过程，包括大型创新组织做估算的难点、大规模敏捷中的项目管理、跨地域和跨文化的高效敏捷开发模式、如何正确选择和使用能提升生产效率的工具、如何通过敏捷方法提高团队的灵活性，以及敏捷方法对整个hp laserjet 产品线带来的好处等。 關於作者： gary gruver，hp laserjet core firmware lab的前总监，在hpi作了22年．他目前是macys．com公司副总裁，负责产品发布、质量和公司运维。gary既充分掌握了敏捷精髓，又能够在业务及财务上做出必要的决策，促使敏捷转型获得成功。 mikeyoung，hp laserjet core firmware lab项目群经理，负责管理hp lasedetcore firmware lab团队。mike已经在hp laserjet打印机开发部工作了18年。在此之前，他曾在hughes航空公司负责设计卫星控制系统。在这个项目中，他是最主要的敏捷倡导者，负责查看度量报告，并独自处理那些可预见的问题，从而解决开发过程中可能遇到的瓶颈。 pat fulghum，hp laserjet futuresmart firmware架构师，是敏捷开发团队的“百宝箱”。pat在高压的工作环境中始终确保架构的完整性，同时他所设计的架构能够充分保障引rmware开发进程和质量。pat还热衷于钻研技术及解决技术问题，他同样倡导任何能够提高开发人员生产效率的改进编译时间、分流时间等，对我们“提高10倍生产率”的愿景充满热情。他已经在hpi作了24年。 郑立，hp公司敏捷教练、csp、管理咨询顾问和资深软件开发工程师，致力于敏捷技术的实践、研究和推广，曾发表论文《敏捷软件开发模型实施研究，组织并参加了中国敏捷之旅agiletour、serum gathering china、敏捷中国agile china和其他敏捷活动。在软件开发流程和管理方面有深刻的认识，专注于提高企业级软件的开发效率和品质。译著有敏捷技能修炼：敏捷软件开发与设计的最佳实践 目錄： 《大规模敏捷开发实践：hp laserjet 产品线敏捷转型的成功经验》 译者序 序 前言 第1章　敏捷原则与敏捷实践 1.1　《敏捷宣言》背后的原则 1.2　我们所采用的敏捷精益原则 1.3　快速指引：敏捷与瀑布模型的对比 1.4　小结 第2章　让敏捷辅佐业务目标 2.1　背景：hp futuresmart firmware案例分析 2.2　hp futuresmart firmware成本和周期驱动优先 2.3　hp futuresmart firmware架构和流程重构的价值主张 2.4　通过业务分析确立开发目标 2.5　小结 第3章　让架构支撑业务目标 3.1　现有架构的挑战 3.2　支撑业务的架构：动态演进以及前向兼容 3.3　持续改进和易于维护的架构 3.4　小结 第4章　如何用敏捷理念稳固新架构 4.1　迭代地重构架构 4.2　取得进展 4.3　薄片模型 4.4　架构演示过程中实现文化上的转变 4.5　小结 第5章　大型组织实施敏捷的真正秘密 5.1　根据群众意愿而改变 5.2　沟通从度量开始 5.3　敏捷管理的迭代模型 5.3.1　小里程碑目标 5.3.2　将目标关联起来跟踪 5.3.3　沟通 5.3.4　学习 5.3.5　敏捷式调整 5.4　小结 第6章　持续集成和质量系统 6.1　减少编译资源和时间：持续集成 6.2　通过持续集成实现高质量：自动化分层测试 6.2.1　l0测试 6.2.2　l1测试 6.2.3　l2测试 6.2.4　l3测试 6.2.5　l4测试 6.2.6　发布流水线的持续改进 6.3　自动发布流水线带来的生产率 6.4　企业级软件系统特别需要注意的几个地方 6.5　小结 第7章　驯服计划兽 7.1　用初略预测和趋势观察预测 7.1.1　初略预测：让rd部门尽早介入初始工作 7.1.2　趋势观察预测：快速反馈需求提出者（他们想在什么时候要这个功能） 7.2　清晰的优先级 7.3　及时的用户故事定义 7.3.1　对系统工程师角色的投入 7.3.2　让市场人员负责1-n需求列表 7.3.3　引入技术架构师 7.3.4　让项目经理成为“功能开发组长” 7.3.5　重用需求和测试标签来增加可扩展性 7.3.6　用实物代替估算交付 7.4　说服业务人员：敏捷计划也可行 7.5　小结 第8章　在大型创新组织中做估算的难点 8.1　瀑布模型和挑战 8.2　敏捷方法 8.3　敏捷方法面临的挑战：大型架构的成本投入 8.4　改变管理模式并将管理和业务方向相结合 8.5　小结 第9章　大型组织敏捷中的项目管理 9.1　统筹和排优：项目群经理 9.2　全权负责：部门经理 9.3　健壮性和扩展性：架构师 9.4　将高层整合到一起 9.5　小结 第10章　组织级方法：管理劣势项 10.1　测试责任制组织 10.2　组件型和功能型组织方式 10.3　传统项目管理与scrum自我管理 10.4　小结 第11章　横跨美国和印度文化的高效敏捷开发模式 11.1　经验1：提问权限 11.2　经验2：确保互访时间 11.3　经验3：从小成功开始 11.4　经验4：利用时区差异 11.5　经验5：关注培训——不放松 11.6　经验6：人是团队的根本 11.7　通过组织调整最大限度使用海外团队 11.8　小结 第12章　正确的工具：对生产率有量级的提升 12.1　公共开发环境 12.2　为自动化测试创建模拟和仿真环境 12.3　支持可扩展的测试架构：公共测试框架 12.4　自动化测试最重要的一点：虚拟机供应系统 12.5　实时的度量和跟踪 12.6　集成的工具集 12.7　好的工具值得投入 12.8　小结 第13章　真实世界的敏捷结果：hp futuresmart firmware 13.1　解放资源到创新 13.2　rd和开发人员生产效率 13.3　提升对现有产品的支持 13.4　小结 第14章　提高企业管理灵活性 14.1　敏捷转型对其他rd组织和质量系统的影响 14.2　敏捷转型对产品群组的影响 14.3　敏捷转型对非rd的产品生产组的影响 14.4　组织灵活性的边界在哪里 14.5　hp futuresmart firmware敏捷转型后的变更管理 14.6　小结 第15章　规模化敏捷结果和我们预期的不同之处 15.1　敏捷推广的不同期望 15.2　注重团队灵活性而不是运作方式 15.3　改变部署流水线 15.4　拥抱敏捷带来的变化 15.5　企业级的任务追踪和持续改进 15.6　小结 第16章　启程 16.1　想清楚第一步踩在哪里 16.2　futuresmart转型的下一步 16.3　决定你的第一步 16.4　小结 附录a　敏捷软件的十二条原则 参考文献 內容試閱： 第1章 敏捷原则与敏捷实践 如今在网上搜索敏捷软件开发相关的图书，将会得到上千个搜索结果。每本介绍敏捷的图书，都会从讨论敏捷的原则开始，然后迅速转入作者所擅长的那些实践。书名一般也以“一个可实践的方法”开始，你也大致可以猜到本书也会讲到很多实践方面的内容。那是因为对一个组织推行敏捷原则非常困难，但是相对来说推行实践就比较容易。实践是看得着、摸得到的，它们包括工具、培训和流程等能“工作起来”（make it work）的一切内容。虽然实践容易上手，但是从一开始就引入敏捷原则其实非常关键。有一次访问印度软件IT中心城市Bangalore（这个城市也因为它的创新能力成为全世界讨论的话题），三年前我们将敏捷实践引入那里，这次我们与几个坚持敏捷流程的团队一起工作了一段时间。在那里看到的一切让我们很吃惊，因为当我们解释了敏捷原则，他们才理解为什么要引入敏捷实践，而不再是“因为敏捷而敏捷”。团队开始建立真正敏捷的做事方式，开始提问，开始思考每日活动以及如何实现等。他们也帮助每个人用最好的实践。 本章描述了敏捷的基本原则，以及我们如何将它转化成可以满足大型组织业务要求的形式。在本章的结束，我们简单比较了一下瀑布模型和敏捷模型的差异。 1.1《敏捷宣言》背后的原则 《敏捷宣言》（www.agilemanifesto.org, 2001）极其精简同时也非常强大（参见图1.1）。它没有讨论任何实践和方法，而是简单地列举了一些清晰的原则，使得敏捷可以与时俱进，同时符合业务目标。 我们同时也非常推荐敏捷宣言后面的“敏捷软件的十二条原则”，在本书附录A中列举出了这些原则。但是在很多图书和实际应用过程中，用敏捷宣言来衡量是否遵循敏捷更为快速。请读者也不要误会，那里也会讨论很多敏捷方法、实践和想法，只是建议不要盲目运用它们。想在一时之内就把所有的工作做完，显然会顾此失彼。因此，我们需要思考我们最痛苦的痛点在哪里，以及每个敏捷实践的意义是什么，这样就可以在我们的日常工作中取得大幅度的提高。 本书需要读者具有基本的敏捷原则和实践的知识。因为我们不会解释敏捷的来历和含义，或者介绍最流行的敏捷实践是 图1.1敏捷软件开发宣言 什么。取而代之的是，我们会重点关注在大型组织转型过程中的一些经验谈。如果需要的话，你可以先从本书的参考文献中了解敏捷的基本知识。其中一些我们认为比较不错的书是： 1.2我们所采用的敏捷精益原则 基于实际学习和收集敏捷宣言实施的经验，我们从6条敏捷精益原则开始敏捷实践。前两条来自于精益开发，接下来三条来自于敏捷，最后一条是我们自己摸爬滚打的经验所得。我们用这6条经验去判断新的实践或者工具是否真的可以帮助我们。要想全面敏捷很容易，但是是不是走在正确的道路上，是值得我们深究的问题。 1.减少开支和浪费（保持简洁） 如果敏捷实践使得计划和开发活动成本比敏捷实施之前更高，那么我们就不是在做敏捷。在本书案例中，唯一比我们功能交付模型更为敏捷的东西已经融入到了开发流程和工具里。历史经验告诉我们，大的流程和工具每隔几年就会变更一次，每次变更我们都小心翼翼的，特别是在主要工程的交付过程中更是如此。经历了敏捷转型之后，我们学会了自我学习，开始自问：“如何减少编译时间？”“如何增加每天的集成次数和编译次数？”“我们为什么还在那样做？”分析日常工作是否合理。改善所有事情的效率。在我们的团队中，不管处于什么级别，都有权利提出改进意见，减少不必要的花费和资源的浪费。 2.量力而为 在敏捷精益中，管理任务的方式被称之为工作进行项（Work In Progress，WIP）。即使我们后来完全理解了敏捷的精髓，如果我们一刻不关注敏捷原则、交付日期、并行项以及依赖项等，所有人的工作效率就会下降。我们有一个项目经理形象地把我们之前的工作方法称为“花生酱功能开发方法”，因为所有人都薄薄地平摊到了所有的事情上，这使得我们的效率很低。这听上去好像跟常识不一样（安排的事情多了，效率反而低了），但是事实就是你想做更多的时候，你能完成的事情就越少。这里有个解决问题的好办法就是：少承诺，多出活。我们会对这方面的内容在敏捷计划章节进行充分的讨论。敏捷计划的关键是能不能和市场、业务领导者的方向相一致，同时也需要重点引导他们对产品的预期。 3.打开瓶颈 让团队“只是交付”很容易，如果只听取片面消息，比如只听好消息，那么大家都闭口不谈坏消息，等坏消息来的时候，再想防治就来不及了。那么管理层可以在这方面做些什么呢？是采用更强硬的方式还是希望事情可以自己变得好转？事实上，大规模敏捷转型方式可以处理非常复杂的项目。任何项目中都会存在瓶颈，所以需要建立一种文化，不仅可以发现瓶颈，而且能够很好地打开瓶颈。作为管理层需要经常了解系统全局，理解瓶颈所在并即时优化它们。如果团队意识到，当他们碰到困难，就会有人来帮助他们解决，那么他们就会在刚碰到问题的时候就将问题暴露出来。这样得到的好处是，团队将来会更愿意准备好资源来处理将来会碰到的瓶颈。 4.越早越多地集成 我们在做主代码库变更的时候，可以通过树立严格的代码规范来保障代码质量。但是历史经验告诉我们，如果没有简单自动化的集成流程，每次集成代码前都会积累大量的变更。通过经验总结，我们终于找到了破解这个魔咒的钥匙，那就是“多次提交少量功能的代码，并做增量测试”，而非只做几次集成，每次集成都有一大堆变更。在我们看来这是最基本的原则之一，也是提高组织生产率和产品质量的关键点。 ……

書城介紹　 |　合作申請　|　索要書目　 |　新手入門　|　聯絡方式　 |　幫助中心　|　找書說明　 |　送貨方式　|　付款方式	香港用户　 |　台灣用户　|　海外用户
megBook.com.tw
Copyright (C) 2013 - 2024 （香港）大書城有限公司　All Rights Reserved.