敏捷

IPD是一套产品开发的模式、理念与方法。既然是方法，肯定有她的背景、体系和核心思想。在华为引入IPD流程后，从管理上看确实规范很多，一切都有据可循，有规章制度去规范和约束各个产品团队，不能再像过去小作坊式的野蛮生长。 背景 1992 年IBM在激烈的市场竞争下，遭遇到了严重的财政困难，公司销售收入停止增长，利润急剧下降。经过分析，IBM发现他们在研发费用、研发损失费用 和产品上市时间等几个方面远远落后于业界最佳。为了重新获得市场竞争优势，IBM提出了将产品上市时间压缩一半，在不影响产品开发结果的情况下，将研发费 用减少一半的目标。为了达到这个目标，IBM公司率先应用了集成产品开发（IPD）的方法，在综合了许多业界最佳实践要素的框架指导下，从流程重整和产品 重整两个方面来达到缩短产品上市时间、提高产品利润、有效地进行产品开发、为顾客和股东提供更大价值的目标。 IBM公司实施IPD的效果不管在财务指标还是质量指标上得到验证，最显著的改进在于： 1、 产品研发周期显著缩短； 2、 产品成本降低； 3、 研发费用占总收入的比率降低，人均产出率大幅提高； 4、 产品质量普遍提高； 5、 花费在中途废止项目上的费用明显减少 核心思想 IPD作为先进的产品开发理念，其核心思想概括如下： a) 新产品开发是一项投资决策。IPD强调要对产品开发进行有效的投资组合分析，并在开发过程设置检查点

仅以此文用来抒发一些对于行业现象的批判。 敏捷是现在十分流行的软件研发模式，并且正在成为业界主流。下图来自于2018年软件测试行业报告，可以看到在受访测试人员中，工作于敏捷或类敏捷项目中的比例已经高达89%。 将测试融入敏捷模式中，根据敏捷项目的模式进行调整，实现“敏捷测试”，是成熟的测试团队必须具备的能力。 在谈论敏捷测试之前，首先要搞清究竟什么是敏捷。 敏捷，汉语名词解释指反应（多指动作或言行）迅速快捷，关键在于快字。也正是由于这一特点，非常适用于小步快跑的现今项目节奏，也使得敏捷得以大行其道。做项目，必谈敏捷，不敏捷项目经理出门都不好意思跟人打招呼。 然而，许多（危言耸听的说，甚至是大多数）项目对于敏捷的理解和应用都是产生了偏差的。对于某些项目组织者而言，敏捷就像是一棵救命稻草，使得他们可以名正言顺的抛弃掉他们认为的那些繁文缛节，自以为是的将团队力量投入到他们认为最有价值的领域中去。 这样的敏捷，蔑视流程，蔑视管理，蔑视所有的准备和规划，到头来项目只能是乱成一团 。 敏捷是行之有效的理念和模式，但必须被正确的看待和使用。 当我们谈论敏捷，我们到底在谈论什么 有一些理论体系中，会将敏捷和一些常见的软件生命模型并列而谈，认为敏捷与瀑布模型、迭代模型一样是一种“模型”。但笔者认为，与其认为敏捷是一种模型，不如说是一种颠覆性理念。敏捷这一概念所对比的，并不是软件生命模型，而是更基础的

背景介绍 我从大学05年开始直到现在就总共干了10年的软件开发，期间参与了各种类型的软件项目开发，包括高校和企业应用软件项目，外企的金融软件项目以及互联网软件项目，也参与过最近流行的移动端互联网项目的开发。分别在外企、创业企业、自己创业和中大型互联网公司工作过，所以实际参与的互联网项目种类繁多，工作过的公司类型也较多，因此对于软件项目开发这件事情有一些自己的思考和实践经验。 从2011年开始接触到敏捷项目管理，期间学习和实践了像Scrum和看板方法等敏捷方法，也进行了包括持续集成、代码评审等多种敏捷工程实践，也使用了谷歌公司发明的OKR工作方法。因此对于敏捷软件开发也有一些总结的经验。 因此本文就是将自己多年的软件开发和敏捷软件开发的多年学习和实践经验进行汇总，形成本文。 软件的价值 提高数据计算和存储效率 首先软件带来的价值就是提高工作效率。互联网盛行之前软件开发行业主要是为企业开发应用软件，它的价值是提升企业员工的工作效率，比如财务软件及各种管理类软件，主要是解决信息存储和检索问题，解决数据计算效率问题。 提高信息传递效率 其次软件及互联网带来的价值是提高信着互联网技术的广泛应用，软件给人们带来的价值是以更低的成本，更高的效率传递来传递信息。 还有其它的一些价值。上述两类价值是软件及互联网带来的核心价值。 那么我们软件开发的目标就是通过一系列的过程和活动让软件的价值得以体现

1、瀑布模型 是由W.W.Royce在1970年最初提出的软件开发模型，　瀑布式开发是一种老旧的计算机软件开发方法。 瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。 步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整， 代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。 2、迭代式开发 也被称作 迭代增量式开发 或 迭代进化式开发 ，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。 什么是迭代式开发？ 每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代. 在迭代式开发方法中，整个开发工作被组织为一系列的短小的、 固定长度（如3周）的小项目，被称为一系列的迭代。 每一次迭代都包括了需求分析、设计、实现与测试。 采用这种方法，开发工作可以在需求被完整地确定之前启动， 并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。 再通过客户的反馈来细化需求，并开始新一轮的迭代。 迭代式开发的优点： 　　1、降低风险 　　2、得到早期用户反馈 　　3、持续的测试和集成 　　4

作者: 殷坤 来源: InfoQ 　　在本系列的第一篇文章“我们的测试为什么不够敏捷”中，根据实例总结出敏捷自动化的两大阻碍：“脚本维护困难”、“断言条件繁琐”。本文针对如何降低脚本维护难度分享一些实践经验。 　　近几年，Web技术发展势头迅猛，浏览器市场群雄争霸、各种UI组件库也如雨后春笋。现在互联网上已经很少有仅支持一种浏览器，并且不基于任何可复用的UI组件库进行开发的应用了。开发人员基于各种优秀的UI组件库（如， JQuery 、 Dojo 、 ExtJS ）可以很容易的开发出功能强大、展现绚丽、兼容各种浏览器的页面（如下图）： 　　UI组件库的广泛采用在提高开发效率的同时，也极大的提升了用户体验。基于UI组件库之所以能快速开发出功能强大的页面，是因为UI组件库可以自动生成海量、结构类似的HTML源码（如下图）： 　　开发人员是幸福的，因为这一切对于他来说完全透明。于是只剩下自动化测试人员独自面对这样“恐怖”的页面源码。 　　如前文“我们的测试为什么不够敏捷”中所言，业界常见测试工具的脚本本质上还是针对页面源码的，因此原本就举步维艰的自动化测试在开发使用UI组件库之后变得雪上加霜： 页面DOM结构非常复杂 　　导致所录制/编写脚本的复杂度变的更大、可读性变得更差。 UI框架的升级很可能会导致DOM结构的变化 　　因此即使开发人员没对代码做任何改动

作者: 殷坤 来源: InfoQ 　测试是为了保证软件的质量，敏捷测试关键是保证可以持续、及时的对软件质量情况进行全面的反馈。由于在敏捷开发过程中每个迭代都会增加功能、修复缺陷或重构代码，所以在完成当前迭代新增特性测试工作的同时，还要通过回归测试来保证历史功能不受影响。为此我们期望： 　　测试范围足够广： 测试用例要覆盖所有功能； 要在各种可能的环境下作兼容性测试； 系统的稳定性、性能都要测试； 　　测试频率足够高： 每日构建产生的版本要保证可用； 每个迭代都需要对历史功能做回归测试； 释放前或上线后如果打了补丁，就需要回归； 　　但实际情况往往不遂人愿： 　　实际测试周期变短： 上线时间提前确定，研发进度延期，测试计划被迫延后； 最后阶段经常会临时增加测试任务； 所有人都知道还需要再经过一轮测试，但时间没有了； 　　有效测试资源稀缺： 临时从其他项目抽调的测试人员不能立刻有效的开展测试工作； “搞不清楚”本项目的研发人员到底是不会做测试还是不愿做测试； 　　因此由于客观上的资源和时间限制，完整的、及时回归测试在人工测试情况下，往往是不可能完成的任务。团队内部也会产生各种争执： 提交给测试的版本为什么研发人员不先做通过性测试？ 这次代码改动量不大，有必要再花那么多时间回归么？ 当初不是承诺这次修改肯定不会影响以前的功能么？ 怎么不早说要支持Chrome浏览器，现在哪还有时间测试啊？

作者: 殷坤 来源: InfoQ 　　在本系列的第一篇文章“我们的测试为什么不够敏捷”中，根据实例总结出敏捷自动化测试的两大阻碍：“脚本维护困难”、“断言条件繁琐”。本文针对在不失自动化测试有效性的前提下如何降低断言成本来分享一些实践经验。 　　目前业界常见的自动化测试工具在断言方面大多都是采用“指哪儿打哪儿”的细粒度模式，即，在自动化测试过程中只能对设置为断言条件的字段（页面元素）进行断言。而且这些测试工具即使提供录制脚本的功能，但对于断言往往还需要测试人员手工补充插入。 　　除了补充、维护断言条件的工作量大之外，这种断言模式还存在一些明显的不足，下面结合一个实际的例子（如下图）进行分析： 无法感知未设为断言对象的字段上发生的错误 以上图为例，如果在“增加用户”的测试脚本之后只对列表中的“用户姓名是否存在” 进行断言，那么就可能遗漏“入职日期没有提交成功”的错误。而且由于页面的信息量往往很大，我们是不可能对所有字段都设置为断言条件的。 难以对于UI样式或UI逻辑进行断言 以上图为例，有一个UI样式类的缺陷（左侧菜单树的根节点“console”下面多出来一条虚 线）和一个UI逻辑类的缺陷（右侧用户列表只有一页，但“下一页”和“最后一页”图标依然是可以点击的，即没有灰显）。此类缺陷即使对于经验丰富、心思缜 密的测试人员，在人工测试时也是很可能发现不了的

在软件开发时，经常面对的第一个项目实现决策是“我们应该使用哪种开发方法?”这是一个引起很多讨论(和激烈辩论)的话题。如果您以前没有使用过这种方法，那么适当了解开发方法和理论是必要的;简单地说，这是一种组织软件开发工作的方法。这与项目管理的风格或特定的技术方法无关，尽管您经常会听到这些术语混在一起或互换使用。最流行的两种基本方法是:瀑布开发和敏捷开发。这两种方法都是可用的、成熟的方法。 现在，说起敏捷开发（Agile Model）和瀑布开发（Waterfall Model）模式，很多人认为敏捷开发是未来的项目实施的趋势，瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼，联想也在使用敏捷的方式实施一些项目。但实际上我们看到绝大多数公司还是依然在采用瀑布的方式实施项目。本文主要简单介绍敏捷和瀑布的区别和优劣。 敏捷开发和瀑布开发 1、瀑布模型 瀑布模型是一种项目分解为有限的阶段来开发软件的方法。只有在审查并验证其前一阶段时，开发才会应进入下一阶段。在瀑布模型中，阶段不重叠。在这种方法中，事件的顺序是这样的: 收集和记录需求 设计 代码和单元测试 执行系统测试 执行用户验收测试(UAT) 解决任何问题 交付成品 对于瀑布的开发模型来看，似乎依然具备很可靠的工作逻辑，一个工程或项目分为多个阶段，每一个阶段都投入相应的资源，来完成本阶段的工作。每一个阶段到下一个阶段，都有明确的输入输出产物

转自本人运营的公众号“ 携程技术中心PMO ”（ID：cso_pmo） 8月3日由携程技术管理中心组织的2019年度“敏捷总动员”在上海携程总部举行，超过300人参与了本次年度敏捷盛筵。 查看现场音乐相册 活动回顾 按照出场顺序，排名不分先后 《去哪儿研发度量体系建设》-- 去哪儿 贺冰 度量在去哪儿整个体系中的定位是，作为过程改进的一个问题入口，同时也是衡量改进效果的工具，不作为kpi考核的工具，不会直接用数据评判一个团队好或者不好。正是有这样清晰的定位才使得这套体系运作了几年之后还能发挥作用。 贺冰老师从以下四部分讲述了去哪儿如何使用度量来帮助研发过程落地持续改进。 我们为什么要度量 面临的调整和对策 如何可视化 可支持改进的度量系统 《全流程敏捷项目管理实践》-- 唯品会 陈炜骅 全流程敏捷项目管理，是基于敏捷团队，在全流程上让所有干系人一起参与“敏捷”，打破团队壁垒，最有效地利用资源效率。陈炜骅老师以一首“满江红”开篇，讲述了他的团队如何定义核心价值、各阶段准入准出规则、打通全流程沟通链。 优先级由运营、产品和开发一起决定，不会再出现扯皮 只排一个迭代周期的开发/测试任务，免去优先级调整后的反复排期 运营、产品、开发、测试、UED走得更近，提升战斗力 项目经理不再成为沟通的瓶颈、上游的需求方都可以直接对接下游的测试 《用敏捷思维打造经典图书》-- 电子工业出版社 孔祥飞