这一步所产出的其实就是传统软件开发过程中的软件规格说明书。软件规格说明书对于开发人员实现产品功能非常重要，是软件开发中不可缺少的部分。很多人认为敏捷开发不需要文档，其实这是个巨大的误解，但是敏捷开发中的文档确实和传统的需求文档有很多区别： 敏捷开发重视的是文档产生的过程，希望通过

查看更多 →

题。 解决措施 敏捷方式是趋势，越来越多的开发团队开始接触和使用，CodeArts产品也是基于敏捷思维设计的，以下内容均以敏捷方式叙述，包括但不限于Scrum框架。 对于场景一，可以从人员分工角度思考，建议开发团队人员要有工作侧重点的划分。一部分人员精力侧重于开发，另一部分人员侧

查看更多 →

取措施走出混乱。敏捷看似拥有很快的速度，但变化可以是循序渐进的，采用敏捷的新团队可以较慢的去实现一些新的实践，例如测试驱动开发等。 From:《敏捷软件测试：测试人员与敏捷团队的实践指南》 团队构成 敏捷项目团队是跨职能的，敏捷团队与传统的跨职能团队的区别就是敏捷是向整体团队运作

查看更多 →

产品开发 产品开发指引 创建产品 开发产品模型 开发编解码插件 在线调试

查看更多 →

度，然后再考虑其承载意义。 此处需要考虑一个问题：一个产品是一个Epic吗？产品的每个业务模块是Epic还是Feature？ 产品通常具有战略意义，从这个角度看，产品适合作为一个Epic。但是不是所有的产品都适合，还要看产品是什么，它的颗粒度有多大。在本文的实例中，网上商城周期是

查看更多 →

敏捷回顾 如何玩转每日站会 父主题： Scrum项目最佳实践

查看更多 →

Story）排进产品待办事项（Product Backlog）开始开发了呢？答案是还不可以。 用户故事是敏捷开发中普遍使用的实践，但常见的困惑是：产品负责人整理了一大堆的产品Backlog，还编排了优先级，过早地陷入到细节的讨论中，只见树木不见森林。 传统敏捷开发中，扁平的产品待办列表，

查看更多 →

evOps是敏捷在运维侧的延伸”这一说法也不无道理。只是，敏捷与DevOps，都已经不再是原来的那个敏捷和DevOps了；世界变化太快，问题域发生了变化，解决方案域自然也要随之变化。 敏捷的好处是，有一个敏捷宣言，宣告其诞生。敏捷的缺点，也许也是因为有敏捷宣言。敏捷宣言并不应该被

查看更多 →

测试方法：敏捷开发对软件带来的最大影响便是测试了。传统的α（内部测试）、β（交付客户测试）、γ测试（优化处理）方式在采用敏捷开发后几乎不存在了，因为敏捷开发在开发周期内不断的进行测试工作，因此也就没有了在交付做α、β、γ测试时必须停止开发、冻结开发的时间浪费了。 父主题： 持续规划与设计

查看更多 →

Viable Product，最小化可用产品）的概念。MVP的目的是以最小的投入发布对用户有价值的产品，快速试错，并通过不停的迭代最终找到产品的正确方向。 这个思路很好，但如何确认backlog中的内容是“最小的”而且“可用”的产品却是件很困难的事情。 团队一起讨论初始产品需求的时候

查看更多 →

在对项目的需求进行简单的规划后，我们就要进入具体的开发环节。而在开发之前，当然需要对即将开展的工作进行计划。 那么，在敏捷的开发模式中，计划是如何制定的呢？ 让我们以CodeArts这个产品为例，一起来看看CodeArts作为一款产品是如何制定它的开发计划的。 两级项目计划 计划是演进的，试

查看更多 →

随着近些年敏捷在行业及企业的推广，越来越多的企业意识到了敏捷所带来的好处，并愿意在敏捷上有所投入，从而越来越多的朋友加入了敏捷从业者行列，愿意学习敏捷知识。 本文内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。 定义和特性说明 定义 敏捷开发方式有

查看更多 →

开发产品模型 什么是产品模型 在线开发产品模型 离线开发产品模型 导出和导入产品模型 父主题： 产品开发

查看更多 →

编解码插件流程 产品开发流程 设备接入控制台提供了可视化的界面，帮助开发者快速开发产品（产品模型、编解码插件），并进行自助测试。 图2 产品开发流程图 创建产品：某一类具有相同能力或特征的设备的集合称为一款产品。除了设备实体，产品还包含该类设备在物联网能力建设中产生的产品信息、产品模型（Profile）、插件等资源。

查看更多 →

DevOps敏捷测试之道 本文介绍企业在敏捷和DevOps的逐步转型过程中，测试如何应对挑战，如何有的放矢进行测试，建立适合产品自身发展阶段、产品特点的敏捷测试能力。 敏捷和DevOps 敏捷和DevOps转型始终是被业务目标和客户需求驱动的。市场竞争环境越来越激烈，新商业模式的

查看更多 →

们会面临一些自动化的开发工具，需要对接自动化平台，需要有一定的开发能力，这对测试人员的自身素质提出了更高的要求。而对开发人员来说，首先是质量意识不足，第二是对于大部分开发人员来说白盒测试用例会写，但是黑盒测试用例不会写。另一方面开发在转型的过程中往往忽视了敏捷价值观，他们的思想还

查看更多 →

Scrum项目需求管理流程介绍 Scrum是增量迭代式的软件开发方法，也是当前主流的敏捷开发过程。通过迭代冲刺的方式，持续交付，从用户需求到用户反馈实现各个迭代闭环的软件开发过程。 Scrum项目类型中，预置了敏捷实践中推荐的“Epic > Feature > Story > Task”的四层模型，如图1所示。

查看更多 →

在线开发产品模型 概述 在线开发产品模型前需要创建产品。创建产品需要输入产品名称、协议类型、数据格式、所属行业和设备类型等信息，产品模型会使用这些信息作为设备能力字段取值。物联网平台提供了标准模型和厂商模型，这些模型涉及多个领域，模型中提供了已经编辑好的产品模型文件，您可以根据自

查看更多 →

求从看板中替换出来，移动到Product Backlog中，这也是Product Backlog Refinement的过程，然后看板中加入高优先级需求的卡片就好。如果是交换已经产生工作量的需求就需要分情况处理：一种是移回到Product Backlog列，这种情况多于以完成特性

查看更多 →

这就是产品待办列表（Product Backlog）。这些内容在得到了PO和团队的认可后会交付给团队进行开发，就变成了sprint backlog，这个过程可能很复杂（比如包含多层分解、涉及多个子产品/组件、多个团队协作），也可能很简单；转换成sprint backlog的过程一

查看更多 →

所以离线开发产品模型就是按照产品模型编写规则和JSON格式规范在devicetype-capability.json中定义设备能力，在servicetype-capability.json中定义服务能力。因此离线开发产品模型需要熟悉JSON的格式。 由于离线开发产品模型文件相对

查看更多 →