敏捷开发

在首个 Sprint 开始之前，需要召开一个递增的 Sprint 计划。用来计划和确定一列敏捷发布火车的时间维度，通过定量的时间递增（Sprint）来保证编码实现和我们计划任务（Mission）的持续一致。PI 将在固定的时间箱内计划出一个可量化、可实现和最终可测量验收的计划路线图。Choerodon猪齿鱼通过以下步骤进行PI过程： ART同步会议 通过项目群看板促进可视化 通过迭代日历提高敏捷团队可见性 ART同步会议 在 PI 计划会议之后，各种项目群事件创建了一个闭环系统，从而 “保持火车在轨道上行进”。如图所示： 为了保持工作持续进展和透明度，就需要频繁的协作。为了评估和管理进度和依赖关系，ART通常通过各种同步会议进行协调。这其中包括: Scrum of Scrum（SoS）：发布火车工程师（RTE）每周（或更频繁）引导 Scrum of Scrum会议，来协调依赖，并将进展和障碍以可视化的方式呈现出来。Scrum Master或者其他人向大家同步敏捷团队实现里程碑和PI目标的进度,并管理团队间的依赖关系； 产品负责人(PO)同步：产品经理（PM）和产品负责人（PO）通过 “PO 同 步”会议，对 ART 的进展在多大程度上与项目群 PI 目标相一致获得可视化呈现。讨论特性开发中遇到的问题或者创造的新机会，并评估任何可能出现的范围调整。这个会议也是每周进行一次

这个作业属于哪个课程 https://edu.cnblogs.com/campus/fzzcxy/SE 这个作业要求在哪里 https://edu.cnblogs.com/campus/fzzcxy/SE/homework/10838 这个作业的目标 个人总结 作业正文 如下 其他参考文献 ------ 1）我做了哪些作业； 作业类型 作业链接 个人作业 所写既所思（个人简介） 个人作业 个人编程作业（一） 结对作业 第一次结对作业 结对作业 第二次结对作业-原型设计 个人作业 用例图 团队作业 第五小组多语言工作者——团队展示 团队作业 多语言工作者-项目介绍与问答 团队作业 团队作业——UML设计 团队作业 团队作业——需求分析 团队作业 团队Github实战训练 团队作业 多语言工作者——项目系统设计与数据库设计 团队作业 代码规范与计划 团队作业 团队作业第五次——Alpha冲刺 团队作业 多语言工作者の十日冲刺<1/10> 团队作业 多语言工作者の十日冲刺<2/10> 团队作业 多语言工作者の十日冲刺<3/10> 团队作业 多语言工作者の十日冲刺<4/10> 团队作业 多语言工作者の十日冲刺<5/10> 团队作业 多语言工作者の十日冲刺<6/10> 团队作业 多语言工作者の十日冲刺<7/10> 团队作业 多语言工作者の十日冲刺<8/10> 团队作业 多语言工作者の十日冲刺

第3天 日期：2020/6/14 3.1 今日完成任务情况 成员 完成的任务 遇到的问题 王颖奇 熟悉项目结构和框架，汇总第三次例会报告 暂时没有问题 汪慧和 熟悉项目结构和框架，模块整合 有bug产生 杨野 熟悉项目结构和框架，连接手机调试 usb调试有点问题 李婷华 熟悉项目结构和框架，模拟环境与真机测试 两者环境存在差异 3.2 成员贡献时间 成员 贡献时间 王颖奇 1 汪慧和 5 杨野 2 李婷华 2 3.3 明天任务安排 熟悉代码和环境 编写其他模块界面代码 会议交流，阐述问题 学习相关的移动应用知识 一天之后的总结 3.4 站立会议照片 燃尽图及其任务安排 3.5完成的模块展示 集成开发环境运行测试（Nexus 5x API 24） 真机测试（机型：小米8se） 来源： oschina 链接： https://my.oschina.net/u/4361935/blog/4313450

一：禅道使用的基本流程 禅道管理软件中，核心的三种角色：产品经理、研发团队和测试团队，这三者之间通过需求进行协作，实现了研发管理中的三权分立。其中产品经理整理需求，研发团队实现任务，测试团队则保障质量，其三者的关系如下图： 基本流程如下： 产品经理创建产品 产品经理创建需求 项目经理创建项目 项目经理确定项目要做的需求 项目经理分解任务，指派到人。 测试人员测试，提交bug。 敏捷开发及scrum简介 在正式讲述禅道的基本使用流程之前，先让我们来了解下敏捷开发和scrum。因为禅道的设计理念基础是基于 scrum 的，因此了解scrum的基本概念有助于您了解和使用禅道。 1. 敏捷开发 我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->开发->测试。基本假设只要把每一个环节都做正确，那么终得到的结果也是正确的。瀑布开发有非常成功的案例，比如微软。但从总体来讲，瀑布项目失败率比较高。国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结，终提出了Agile的概念，中文翻译为敏捷开发。敏捷开发有很多种方式，其中scrum是比较流行的一种。 2. scrum 1. scrum里面的角色 scrum由product owner(产品经理)、scrum master和team(研发团队)组成。 其中product owner负责整理user story

经历了几个从商业角度来看或成功或失败的项目，都会发现代码、设计都会慢慢地、在不经意间腐化。而且有一个项目开始的时候，架构是经过精心设计的，也有较为严格的代码规范，并且通过静态代码检查来尽量保证代码的质量，连code review都有一个可供参考的checklist。但半年一年之后，还是会发现，很多代码都已经臃肿走样，到处都是复制粘贴，动辄好几千行代码的模块，能 work、但不 right的代码。 getting it work is easy getting it right is hard 不禁想问问代码和设计是如何一步步腐化的？ 本文地址： https://www.cnblogs.com/xybaby/p/13173047.html 代码如何开始腐烂 其实大家都听说过 clean code，但不一定真正意识到其重要性，且知道并不等同于做到，而时间更是一把杀猪刀，让程序员秃了，让代码烂了。 一个新项目开始的时候，大家都是满怀壮志，期待灵活可复用的架构，期待成功的产品。与此同时，敏捷开发告诉我们不要过度设计，当然，本身也是很难预料到以后需求变化的方向，于是应该等到第一次变化的时候才去考虑如何重构以应对这一类型的变化。但问题很可能就会出现在这里。 也就是说，也许哪一天，当我们需要加一个新功能的时候，会发现原来的设计和代码不是很方便增加这个新功能。当然，我们不应该过多苛责之前的设计

项目 内容 团队名称 三带一队 日期 2020.06.14 地点 9C501 1.1. 今日完成任务情况以及遇到的问题 组员 完成的任务 葛佳诚 前后端的连接部分完成 张芹 部分网页界面的编写 李佩杉 部分系统模块的编写与部分网页界面的编写 赵栋 前后端的连接部分知识的学习 任务的完成情况如下图所示，关于网页界面部分这里给出部分展示。在今天的任务中，我们暂时没有遇到新的问题。 图1.1.1 Github界面 图1.1.2 系统界面 图1.1.3 系统界面2 1.2. 成员贡献时间 组员 贡献的时间（h） 葛佳诚 4.5 张芹 5 李佩杉 5 赵栋 2 1.3. 明天任务安排 组员 明天的任务安排 葛佳诚 继续进行系统前后台的连接 张芹 系统前端界面的编写 李佩杉 系统基本模块的编写 赵栋 编写系统页面上的文档 1.4. 站立会议照片 站立会议照片如下： 图1.4.1 会议照片 1.5. 项目燃尽图展示 项目的燃尽图如下： 图1.5.1 项目燃尽图 1.6. 项目总体进度 今天是小组开始Alpha阶段冲刺的第三天，小组成员之间合作得很好，由于各自的工作量都较大，所以一些工作需要在之后的几天里继续进行，希望在之后的几天里我们能取得好的进展。 来源： oschina 链接： https://my.oschina.net/u/4393390/blog/4313451

以下为博云近期在活动中分享的关于《如何通过 DevOps 让数字化转型变得更加敏捷》的主题演讲实录。 01 金融科技进入VUCA时代 大家好，今天分享的题目是《如何通过 DevOps 让数字化转型变得更加敏捷》。首先，我们认为现在金融科技已经进入到了 VUCA 时代。VCUA 是关于四个词的缩写，即易变性、不确定性、复杂性和模糊性。金融科技行业进入了 VUCA 时代，导致金融业务已有了太多的不确定性和复杂性，驱动金融科技向敏捷化发展，这使得金融IT系统的应用开发和运维必须要关联起来，这也是为什么一定要引入 DevOps 文化。 对于金融行业而言，金融服务的发展离不开信息科技的推动，金融服务的业务变化是非常迅速的，在众多行业领域中，金融行业对新技术的需求、接受，以及迫切希望进行数字化变革的需求也是最强烈的，这也是为什么 DevOps 文化能够快速进入到金融行业的原因。 另外，从整个行业和政策的发展趋势来看，在全球信息技术的发展和中国金融行业十三五规划下，利用新型技术来促进复杂行业的变化，通过敏捷和精益的原理来交付价值和保证质量，打造敏捷组织，是实现业务与 IT 的敏捷协同，加速金融业数字化转型的关键举措。这里我也引用美国马坎特的一句话——“以创业公司的速度交付业务价值，我的团队正在拥抱 DevOps 的原则，以便减少从代码提交到我们的版本管理系统到产品功能对客户可用的时间。”

敏捷软件开发是从1990年代开始逐渐引起广泛关注的一种新型软件开发方法，是能够应对快速变化的需求的一种软件开发能力，它作为一种新型的开发模式，被越来越多地应用到软件项目中。 敏捷软件测试指的是在敏捷软件开发过程中跟质量相关的一系列活动，和传统意义上的软件测试有很多区别，因为敏捷软件测试的概念一直比较模糊，所以经常会有人走入误区，我曾经在瀑布型的软件开发模式下做过几年的测试人员，所以在刚刚接触敏捷项目的时候也曾有过一些误解，但是在敏捷软件开发团队工作将近5年后，对很多问题有了新的认识，以下针对几个常见的误区和大家分享一下我的理解。 不需要测试策略 测试策略关注的是目标和方法，即怎样在限定的时间内有效利用有限的资源达到提前制定的目标，一般制定测试策略时会首先明确测试目标，然后确定需要哪些测试类型，各种测试类型所占的大概比例，选择测试框架，最后规划一下软件发布前需要经历哪些测试阶段。 很多人认为，敏捷软件开发以用户故事为单元，是不是集中精力在用户故事测试就足够了？是不是根本不需要考虑测试策略？ 其实这是一个很大的误解，因为敏捷软件开发通常都是迭代式的发布，周期比较短，资源非常有限，这就更需要我们统筹规划，小到一个用户故事，大到一个完整的用户特性，都需要考虑怎么合理利用测试资源，所以敏捷项目是非常需要测试策略的。 具体到实际项目中，通常团队会在项目初期（迭代0）制定测试策略，明确目标

5.5软件概要设计 　　概要设计，用于子系统或模块设计，也可用新增业务需求的跨子系统设计。概要设计在总体设计框架下，遵循总体设计思想，丰富子系统或模块设计，从而能够指导开发实现子系统或模块。 　　由于软件总体设计从宏观上架构软件，距离开发实现，还有许多需要细化之处。如果系统由多个子系统组成，每个子系统可以视为一个独立的应用软件或服务，此时概要设计不可省略；如果系统不大，重点模块也应需要做概要设计来细化。可以理解为概要设计粒度介于总体设计和详细设计之间。 　　另外，概要设计与代码实现的联系更紧密一些，如代码分层、核心的对象类及关系等。 　　 责任人 ：开发项目组长。 　　 执行人 ：高级程序员、子系统或模块开发人员。 　　 关键行为 ：分析和概要设计。　　 分析：根据子系统或模块的功能规划，结合对软件需求进行分析，完整把握需求； 概要设计：在总体设计框架下，完成子系统或模块的概要设计。 　　 输入 ： 软件需求规格书（SRS）； 数据字典（DD）； 用户故事集合； 其它需求资料； 软件总体设计文档。 　　 输出 ： 软件概要设计文档； 子系统结构设计； 功能模块设计； 接口设计； 软件结构设计； 数据库设计。 　　 职责要求 ： 概要设计； 沟通、协调、明确对接的上下游子系统/模块的接口和边界； 提请软件概要设计评审： 概要设计人员：主讲人，负责讲解和答复各种质询和疑问； 产品经理

Axure RP是一款专业的快速原型设计工具，让我们能够快速设计并创建出应用软件或Web页面的具备高保真和交互能力的原型。通过原型设计，不但能更好地与客户进行交流确认，也能明确地给开发人员以成品效果作为开发指导。本文介绍如何透过这款工具实现下拉子菜单功能的原型设计。 在本次的下拉子菜单功能实现中，我们主要用到了动态面板（当然不用动态面板也能实现，只是效果和效率上没有那么好），动态面板是Axure中的一款高级组件，可以有效帮助我们实现隐藏/显示、滑动、拖动、状态切换等效果。 我们先来看一下最终效果图，此示例主要靠动态面板的状态切换来实现子菜单的下拉和收起的效果： 下面我们一起来看下实现的过程： Step 1 从元件库中拉取3个动态面板到画布中，按如下图示进行排列。 Step 2 双击第一个动态面板，为其起个名字【模板管理】，并且增加两个状态，分别为菜单收起和菜单下拉。 Step 3 双击第一个状态【菜单收起】，进入该状态的编辑中，添加一个矩形并输入菜单的名字【模板管理】。 Step 4 重新双击动态面板打开状态管理页面，双击第二个状态【菜单下拉】，把第一个状态的矩形框负责过来，同时增加几个子菜单用的小矩形框，并且填入菜单名。 Step 5 按上述步骤把其余两个菜单及其子菜单编辑好。 Step 6 接下来需要对菜单进行状态切换的配置了，选择菜单【模板管理】，双击右边的【鼠标单击时】。