软件项目管理与敏捷方法

出版时间：2010年06月  出版社：机械工业出版社  作者：Michele Sliger,Stacia Broderick  页数：246  译者：初悦欣,亢江妹  
Tag标签：无  

前言

我们致力于软件开发方法中的敏捷开发实践（我们也被人们称为敏捷开发人员），但是我们的软件开发生涯并不是以这种方法学开始的。我们最开始是项目管理专业人员（PMP），在软件开发中采用更为传统的方法。为什么要写这本书在大部分职业生涯里，我们都遵循项目管理研究所（PMI）的《A Guide to the Project Management Body of Knowledge，Third Edition》（后文简写作《PMBOK Guide》）中的方法学，在使用敏捷方法的过程中我们越来越清楚地意识到与这本书的主题有关的一些误区——一些我们曾经相信但不正确的思想。直到现在，作为敏捷方法的咨询师，我们仍然能听到一些客户说他们相信（这是不正确的）如果要保持PMP资格并且遵循《PMBOK Guide》中的实践，就必须采用类似瀑布模型的软件开发方法学。我们还听到一些错误的观点，认为敏捷方法缺乏纪律性和严格性。我们看到一些人带有恐惧和失望情绪，因为他们觉得如果遵循敏捷方法的路线，那么之前在PMI上的投资可能会付诸东流。本书的目标是消除这些疑虑，并说明《PMBOK Guide》第3版确实支持敏捷软件开发方法，项目管理者在。PMI上的投资和《PMBOK Guide》所列的实践仍然有效并且适宜采用。我们认为《PMBOK Guide》处于方法学的中立位置，无论选用了哪种软件开发方法，它都支持良好的软件开发方法学实践。尽管许多人知道这个事实，但是还有许多人并不知道。我们曾经是PMP的追随者，现在成了敏捷开发的狂热分子。我们认为另一个重要的问题是如何消除敏捷开发群体认为PMP从业者不能成为好的敏捷开发项目管理者的误解。我们希望建造一座两者之间沟通的桥梁——这便是本书想要做的事。

内容概要

　　《软件项目管理与敏捷方法》重点论述了项目管理研究所（PMI）的《PMBOK Guide》一书中介绍的软件项目管理实践与敏捷软件开发方法之间的关系，同时建立两者之间的桥梁。《软件项目管理与敏捷方法》的内容广泛，包括了项目管理中所有重要的主题，同时还包含了作者多年从事软件开发和项目管理的经验总结，为软件项目管理人员转换到敏捷方法给出了理论参考和实践指南。　　《软件项目管理与敏捷方法》适用于高等院校相关专业的师生作为辅助教材或参考读物，同时适合于每一位参与到敏捷开发方法中的管理人员和工程技术人员。

作者简介

作者：(美国)斯里格(Michele Sliger) (美国)Stacia Broderick 译者：李晓丽 李虎 赵华 等Michele Sliger是Sliger CotlsLdting公司的老板。该公司的咨询业务涉及从初创的公司到财富500强公司，帮助组织采纳敏捷方法。Michele是stickyrmids．com上的定期撰稿人，她拥有项目管理专业人员资格(PMP)认证和Scrum培训师认证(CST)资质，并获得MBA学位。Stacia Broderick创建了AgileEvoltution公司，目的是帮助其他公司以更人性化、更合理的方式采纳敏捷开发实践。Stacia是具有丰富经验的敏捷教练，并且同时拥有项目管理专业人员资格(PMP)认证和Scrum培训师认证(CST)资质。

书籍目录

译者序前言作者简介绪论项目管理者如何跨过桥梁第一部分敏捷开发方法概述第1章 敏捷方法1.1 敏捷方法的起源1.2 敏捷宣言1.2.1 个体和交互胜过过程和工具1.2.2 可工作的软件胜过全面的文档1.2.3 同客户的协作胜过合同谈判1.2.4 对变更的响应胜过遵循计划1.3 指导敏捷项目团队的敏捷原则1.4 小结1.5 尾注第2章 《PMBOKGuide》到敏捷方法的映射：2.1 项目管理研究所和《PMB0KGuide》2.2 项目生命周期2.3 项目管理过程2.4 小结2.5 尾注第3章 敏捷项目生命周期详解3.1 敏捷项目生命周期概览3.2 敏捷项目3.3 敏捷发布3.4 敏捷迭代3.4.1 迭代计划3.4.2 迭代评审3.4.3 迭代回顾3.5 例行工作3.6 敏捷方法和计划驱动方法之间的区别3.7 小结3.8 尾注第二部分 桥梁——《PMBOKGuide》中的实践和敏捷开发实践的关系第4章 集成管理4.1 开发项目章 程和初步的范围陈述4.1.1 宣贯会议4.1.2 简要比较4.2 开发项目管理计划4.3 指导和管理项目的执行、监视和控制项目工作4.4 集成的变更控制4.5 结束项目4.6 小结4.7 尾注第5章 范围管理5.1 范围计划5.1.1 范围定义5.1.2 创建wBs5.1.3 范围验证5.1.4 范围控制5.2 小结5.3 尾注第6章 时问管理6.1 战略计划Vs战术计划6.2 发布计划：开发战略层面的时间进度计划6.2.1 发布计划：在战略层面开发时间进度计划6.2.2 发布计划：战略层面上的时间进度控制6.3 迭代计划：开发战术层面的时间进度计划6.3.1 活动定义6.3.2 活动持续时间评估6.3.3 活动排序6.3.4 活动资源评估6.3.5 迭代计划：战术层面的时间进度计划控制6.4 小结6.5 尾注第7章 成本管理7.1 成本评估7.1.1 敏捷项目的成本最好由产品交付团队进行评估7.1.2 敏捷项目是自顶向下评估而不是自底向上评估7.1.3 项目团队在发布计划期间可以给出选项7.1.4 成本评估在项目生命周期中逐步细化7.2 成本预算7.3 成本控制7.3.1 管理发布待完成事项列表7.3.2 锁定迭代7.3.3 将成本的变更情况通知给利益相关人7.3.4 度量成本性能的AgileEVM7.4 小结7.5 尾注第8章 质量管理8.1 质量计划8.2 质量保证8.2.1 演示、评审和回顾8.2.2 质量控制8.3 小结8.4 尾注第9章 人力资源管理9.1 人力资源规划9.2 组建项目团队9.3 发展项目团队9.3.1 敏捷价值观9.3.2 从价值观到行为9.4 管理项目团队9.5 小结9.6 尾注第10章 沟通管理10.1 沟通计划10.2 沟通基本项目信息——谁、什么、何时、何地和怎样10.3 信息发布10.3.1 迭代演示和评审会议10.3.2 通过每日站立会议进行交流10.3.3 回顾10.3.4 实时信息指示器10.4 业绩报告10.5 利益相关者管理10.6 小结10.7 尾注第11章 风险管理11.1 敏捷开发方法中的有机风险管理11.1.1 消除进度表固有的缺陷11.1.2 缓解规格故障11.1.3 减轻范围蔓延的影响11.1.4 缓解人员流失11.1.5 缓解生产率变化11.2 风险管理规划11.3 风险识别11.4 风险分析11.5 风险应对规划11.6 风险监测和控制11.7 小结11.8 尾注第12章 采购管理12.1 采购规划12.2 合同规划I12.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 清除障碍13.9 小结13.10 尾注第14章 如何与不采用敏捷方法的团队共事14.1 在瀑布开发模式的公司中以敏捷开发团队方式工作14.1.1 整合传统开发过程的前端需求14.1.2 整合传统开发过程的最终需求14.1.3 在敏捷开发过程中集成传统过程需求14.2 敏捷开发团队与非敏捷开发团队在同一个项目中共事14.3 了解瀑布式开发中的障碍14.3.1 反对14.3.2 文化14.3.3 资源管理14.3.4 供应商和承包商14.3.5 设施和工具14.3.6 成本计算和汇报14.3.7 审核人员和评估人员14.3.8 沟通14.4 小结14.5 尾注第15章 项目管理办公室如何支持敏捷开发方法15.1 产品管理的延伸15.2 项目启动15.3 我们符合标准吗15.4 资源分配15.5 待完成事项列表操控和变更操控15.6 项目度量标准15.7 PMO作为培训者和教练员15.8 回顾管理员15.9 谁是敏捷PMO15.10 是否真的需要敏捷PMO15.11 小结15.12 尾注第16章 推销敏捷开发方法的优点16.1 推销常识16.2 推销给团队16.2.1 会议太多了16.2.2 整体估计没有意义16.2.3 如果不进行任何技术上的计划会议，整个架构就会失败16.2.4 不在同一地点办公，所以不能进行敏捷开发16.2.5 一些潜在的原因16.3 推销给项目管理者16.3.1 敏捷开发中没有长期计划，如何进行预算呢16.3.2 现在就挺好的，为什么要改变16.3.3 我们的情况太复杂了，不适用敏捷开发16.3.4 为获得最高效率，需要对资源进行矩阵化16.3.5 不相信员工能进行自我管理16.3.6 没有甘特图，我们如何做出策略决定16.4 推销给客户和产品负责人16.4.1 签的合同是基于时间和花费的，这样你们就可以不断要钱了16.4.2 在每次迭代中没有足够的时间同团队一起工作……第17章 常见错误附录A 敏捷方法附录B 敏捷制品术语表

章节摘录

插图：我是Stacia Broderick，我想讲一个非常私人的、有关我思想转变的故事，希望能够帮助你认识到正视自己想法以及学会如何成长的重要性，尽管这个故事可能令人十分不舒服。我在1993年成为一名项目管理者，2003年开始从事敏捷开发。我还是一名PMP，正式接受过在我之前取得项目管理专业人员资格认证的数千人的培训。在我开始管理项目的时候，我对我的能力带有一丝骄傲，我能学会如何将数据输人到一个项目管理工具中，学会如何举行状态会议，如何同承包商和第三方供应商协商有关资源和材料等事宜，如何减少项目风险，当然，还有如何控制项目的范围。我甚至在睡觉时都能完成向前或向后的推算。项目管理对我来说是一项完美的事业。作为家里的老三，我把项目管理的思想灌输给我的两个姐姐，我们把项目管理运用到每周家务杂活的时间计划上。我甚至还设计了一个过程来削减洗碗的工作量，通过一个批量抽取系统将洗碗机清空（只在需要时取出一个碗并且不再反复使用它，直到重新装碗的时候才一次把碗放进洗碗机），但是我的父亲并不支持这种新方法。对我（一个故步自封的怪物）来说，项目管理是一项完美的事业。我和Scrum的冲突始于2003年，Scrum是敏捷软件开发方法中的一种。我强烈反对这种新的、轻量级并且不被任何正式的主流开发方法学支持（也许是我自己这么认为）的方法。但是当Ken Schwaber开始培训我们的软件项目管理者和软件开发人员的团队的时候，我的看法发生了剧烈的颠倒。作为虔诚的：PMP信徒，又或许是仍然对软件开发相对陌生的原因，一开始我对。Ken教我们的自我管理团队和迭代式开发抱有一丝疑惑。随着我沉浸其中并接受了两天的“ScrumMaster”培训之后，最吸引我注意力的地方是“你没有权力”。Ken的意思是说产品的所有人和产品的交付团队这两个角色在本质上应该是相互协作的，项目管理者在Scrum方法中并不是决策者。像唱颂歌一样，我反复思考这一问题，想知道我是否能够习惯和适应这个观点。我不停地思考：“没有权力怎么管理项目或人员呢？在项目中采取强制性手段并且要求人们加班工作和周末工作（但是要承诺未来请他们吃免费馅饼）是一个先决条件吗？随着项目团队变得日益庞大和行动缓慢，是不是意味着可以更容易地迫使他们屈服？”

编辑推荐

《软件项目管理与敏捷方法》：两位资深培训师构建了一座从传统开发方法转换到敏捷开发方法的桥梁。他们深入讲解了项目管理者如何成功转换到敏捷开发方法，这种转换是通过对“推动和协作”的重新关注实现的，而不是通过“命令和控制”实现的。作者解释了敏捷开发方法与传统方法学之间的区别和这种方法的优点以及在现实世界中的应用效果，详细论述了敏捷方法学中的过程和生命周期，涉及从项目范围、时间管理到成本管理，以及和利益相关者沟通等诸多主题。《软件项目管理与敏捷方法》主要内容：《PMBOK Guide》中的思想和敏捷开发实践之间的关系。理解敏捷开发方法的角色和价值，例如迭代／发布计划和回顾等。采用敏捷技术持续和系统地降低风险。在开发各个阶段实施质量保证(QA)：分析、设计、缺陷预防和持续改进。学会信任项目团队并倾听他们的声音。在敏捷、协作的开发环境中实施采购、购买和签订合同。软件项目团队转换到敏捷方法时如何避免常见的错误。同项目管理办公室和非敏捷项目团队进行协调。在自己的项目团队或组织中“推销”敏捷开发方法。《软件项目管理与敏捷方法》适用于每一位希望自己更敏捷的项目管理者。

用户评论 (总计4条)

•   刚拿到书，随便翻开到91页，看了一遍“真实的评估”，结果，语言不通。“其中11个组都要交付一个对遗留系统的重新改写。”这绝对是一个病句，所有中国字都认识，但你就不是能知道是什么意思。我猜测是想说每一个组都要交付一个对存有遗留问题的系统的一个重新改写的计划，或者说最终交付物。另外，逻辑也不通。8月份作项目计划，项目需要8个月完成，实际次年5月完成项目。文中却说“最终在5月份完成了全部特性的交付，整整比计划拖延了9个月……和实际完成情况只偏差了一个月。”译者与出版社都很不负责任。但我相信英文版水平应该还是不错的。有时间和精力的人，我建议直接读英文版。
•   感觉还可以，但有些晦涩的翻译
•   纸质非常薄，从正面可以看到背面的字，非常不爽。
•   帮朋友买的，据说不错。但是亚马逊现在也玩儿第三方这块了，渐渐变淘宝第二了。中国特色。呵呵