敏捷开发

创建一个应用 快速开始 首先，创建你要存放应用的目录： mkdir myapplication 进入目录： cd myapplication/ 生成应用： yo jhipster 根据需求回答相应的问题，详细的问题在 下面部分 会提到. 当应用生成后，你可以通过 Maven ( ./mvnw on Linux/MacOS, mvnw.cmd on Windows) 或者 Gradle ( ./gradlew on Linux/MacOS, gradelw.bat on Windows) 启动应用。 你可以前往 Using JHipster in development 页获取更多信息。 你可以通过 http://localhost:8080 访问你的应用。 当生成应用时需要回答的问题 _一些问题的改变取决于你前面的选择。例如，如果你zhiq没有选择一个SQL数据库的话，你不需要配置一个 Hibernate 缓存。 你想创建什么类型的应用？ 你需要选择的应用依赖于你是否想选择微服务作为你的架构。关于微服务的详细描述在 available here ，如果你不确定，就选择默认的 “Monolithic application”。 你可以选择： 一体化应用：这是一个典型的，通用的应用。它容易使用和开发，是我们默认推荐的。 微服务应用：采用微服务的架构，这是其中一个服务实例。 微服务网关

摘要 微服务架构 vs 一体化架构 概览 JHipster 的API 网关 使用网关进行HTTP路由 安全 自动生成文档 请求速率限制 访问控制策略 JHipster 的注册中心 JHipster 注册中心概览 JHipster 注册中心的安全保障 在JHipster 上注册你的应用 创建微服务应用 为微服务应用生成实体对象 使用HazelCast做分布式缓存 不带数据库的微服务应用 使用 Docker Compose 使用JHipster Console 和ELK技术栈来监控服务 生产环境 部署到 Docker Swarm 部署到 CloudFoundry 部署到 Heroku 微服务架构 vs 一体化架构 使用 JHipster 生成应用时，第一个问题就是让你选择你要的生成的应用(目前有4个选项)，但实际上你是在两种架构风格里面做选择： 一体化架构，用来创建单独的一个应用，包含前端 AngularJS 代码和后端 spring boot 相关代码，项目中所有代码都在一个应用中。 微服务架构，进行了前后端分离，优点是它可以让你很容易的控制单个应用的规模，并处理好这些应用中一些简单细小的问题。 相对来说，一体化架构是比较容易上手，官网默认推荐这个，如果是刚接触 JHipstert，建议从这个入手，熟悉后，如果项目有要求，则再选择微服务架构应用。

敏捷开发 简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发方法目前还没有一个明确的定义其特点是对软件生产率的高度重视主要适用于那些需求不确定有责任感和积极向上的开发人员用户容易沟通并能参与十个人以下的小项目等情形的软件开发是在保证软件开发有成功产出的前提下尽量减少开发过程中的活动和制品的方法体现刚刚好 价值观 沟通、简单、反馈、勇气 开发过程 几种常用的敏捷方法 　　 极限编程（XP） 计划永远赶不上变化 XP无需开发人员在软件开始初期做出很多的文档 XP提倡测试先行为了将以后出现BUG 的几率降到最低。 XP由4部分组成、价值、原则、行为和实践。其中价值包括简单、交流、反馈和勇气4种5项原则为快速反馈、简单性假设、逐步修改、拥抱变化和高质量的工作；行为则包括倾听、测试、编码和设计。 水晶方法（Crystal） Crystal根据项目规模和项目的重要性来区别项目，并赋以相应的方法，所以Crystal是方法的组合。它阐明了其把交流和对话放在首位的立场。Crystal方法中只有两条绝对的准则：使用的增量式循环不超过4个月，应用反思工作室促使方法学的自适应

听acp宣讲时候，老师推荐的书 来源： 51CTO 作者： HappyBoyLi 链接： https://blog.51cto.com/thinklili/2084711

摘要 :目前软件开发除了强调产品质量,同时对产品能够快速发布并且迅速适应市场变化的要求也日益强烈。为适应这种开发环境和市场需求,传统的软件开发模式已被敏捷开发模式所替代。本文介绍敏捷软件开发中的Scrum方法,并结合实际问题,分析Scrum方法在实践中的运用。 关键词 :敏捷开发;Scrum 产品质量和开发效率一直是软件产品开发的关键。随着科技和经济的发展,软件的市场环境和用户需求不断发生变化,这对软件产品的快速发布提出很高的要求。传统的瀑布模型、螺旋模型、原型模型等已不能适应越来越复杂和不断变化的需求和市场环境。近年来,敏捷软件开发逐步流行,并被广泛认识、研究和使用。敏捷开发具有应对快速变化的市场和需求的能力,因此,它被越来越多的公司企业采用。用于敏捷软件开发的方法有很多,其中Scrum方法是被广泛应用的方法之一。 1.Scrum简介 Scrum是一个增量的、迭代的开发过程,名称来自英式橄榄球的争球。Scrum的整个开发周期包括若干个小的迭代周期,每个小的迭代周期称为一个冲刺(SPrint),每个冲刺的长度一般为2到4周。在Scrum中,使用产品订单来管理产品或项目的需求,产品订单是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。开发团队总是先开发的是对客户具有较高价值的需求。在每个冲刺中,开发团队从产品订单中挑选最有价值的需求进行开发

迭代验收评审是Scrum中的重要活动之一，迭代验收评审会议召开过程是否符合敏捷原则，实践是否贴近实际，参照以下： 要点一：参加迭代验收评审会议的角色是否完整和投入 ●敏捷团队所有成员，包括PO、Scrum Master、团队成员。 ●敏捷团队干系人，包括客户、最终用户、运维人员、管理人员等。 要点二：谁来进行操作和演示 ●建议PO进行操作和演示，或者是团队内对功能熟悉的团队成员。 ●PO需要关注完成了什么而不是怎么完成的。 ●迭代验收评审会议不是向PO进行工作汇报的会议，而是给所有人员展示需求完成的情况。 ●PO应该在迭代过程中就验证完成的功能，而不是等到迭代验收评审会议上才看到。 要点三：事先准备好演示环境和演示数据 ●演示环境和演示数据需要提前准备好，避免浪费迭代验收评审会议的时间。 ●演示环境建议基于测试环境进行，功能测试环境和准生产环境都可以。 ●迭代验收评审会议演示的是完成的软件功能而不是PPT。 要点四：重复确认刚结束迭代的目标 ●需要在会议开始前重申本迭代的目标，起到提醒团队成员的作用，同时让相关干系人也充分了解，从而更加聚焦迭代验收评审会议的主题。 要点五：事先约定好会议规则 ●为了确保迭代验收评审会议的顺序召开，需要在开始前约定好会议纪律： ●会议过程中需要保持聚焦不发散。 ●提出问题的同时最好有对应的解决方案。 要点六：会议内容谁来记录

[原创]浅谈敏捷测试 最近“敏捷”一词非常热，热到测试行业大家也都在谈论敏捷测试，哪么究竟什么是敏捷测试呢?敏捷测试如何实施？敏捷测试的流程是什么？敏捷测试与传统测试有什么区别？ 一 敏捷开发： 所谓敏捷开发，简言之就是是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈 进行思考、反省和总结，不停的进行自我调整和完善。 二 敏捷4个核心价值观： 1 个体与交互 胜于 过程与工具 2 可用的软件 胜于 复杂的文档 3 客户协作 胜于 客户谈判 4 响应变化 胜于 遵循计划 三 敏捷12个原则： 我们遵循以下原则： 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 业务人员和开发人员必须相互合作，项目中的每一天都不例外。 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 可工作的软件是进度的首要度量标准。 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 坚持不懈地追求技术卓越和良好设计

关于“银弹” Brooks 在 No Silver Bullet 一文中开篇便提到 “There is no silver bullet”，并且从软件工程的本质上解释了为什么一个能够解决关键问题的“武器”在软件工程上不存在（软件工程的 Complexity;Conformity;Changeability;Invisibility）。之后作者又从这么多年软件工程的发展来解释为什么没有“银弹”，无论是高抽象的语言、合理的构建方法、面向对象的思想等等。这些都不能解决软件工程带来的根本性问题。我认为，作者这么说是有道理的。 而在另一篇关于“银弹”的文章中，作者以思辨的角度从历史和方法论的观点来对软件工程中是否有银弹做了分析： 面向对象的编程思想提供了一种编写复杂系统的方法（从小的组件开始写起（造轮子））；可复用的组件以及硬件的更新都推动了软件工程的发展。软件工程发展到了现在，确实还有问题需要解决，但是正是这些问题能够不断推动软件工程的发展。 所以，就从现在来说，软件工程中的“银弹”还未出现，但是随着方法、科技的不断进步，或许之后会产生。 关于“大泥球” 大泥球的定义： 在软件工程的整个结构方面，大泥球是这样被定义的：A BIG BALL OF MUD is a casually, even haphazardly, structured system. 在具体实现上面

团队任务描述: 在确定完分组，并对于敏捷开发做了相应的了解之后，我们团队开始了第一次的冲刺。对于我们团队的第一次的 Scrum冲刺，我们团队开展了团队会议。首先，我们明确了我们的目标，对其进行了相对初步的规划。其次，对 我们的任务进行了分解，针对团队成员的特点，兴趣爱好以及擅长的方面进行了大致的分工。每个人完成自己的 那部分，然后把大家的内容都结合在一起，一步一步的完成第一次确定的任务需求。 团队分工情况说明： 1.谢翊璇———————模拟客户 2.全超—————————产品负责人 3.郑舒壬———————Scrum负责人 4.唐祥安———————需求分析 5.谭轲、齐博————前端、后端程序 6.刘魁、郑盛渤——数据库编程 团队第一次任务完成情况描述： 1.初步确定了需求。 2.类图和活动图。 3.数据库存储用户数据的表建立。 4.用户数据的增删改查代码完成。 用户信息表[user] 数据项 命名规则 数据类型 长度范围 备注 userinfo_IDcard 430+15位数 VACHAR 1~18 例如：430424123456781111 userinfo_name 2~4个字符 VACHAR 1~20 例如：郑小渤 userinfo_age 2位整数 VACHAR 1~4 例如：20 userinfo_address 1~20个字符 VACHAR 1~20 例如

介绍软件工程之前我们得说明一个问题，什么是软件？软件就是应用程序？就是一堆代码？首先来看看软件三大特征： 软件是设计开发的，并不是生产制造的，他不是工厂流水线。 软件不会被消耗 软件是根据客户实际需求定制的 所以软件本质就是一个特定的指令的集合，来满足预期功能需求。 而软件则设计的领域有工程/科学软件，嵌入式软件，产品线软件，web应用软件，开放计算，人工智能，网络资源，开源软件等 还有些软件叫做遗留软件，就是开发时间距现很久的！！也就是旧软件，而这些软件一般都是性能差。所以这些软件要想在现在还有一定的生存空间，那么就要升级或者重构，甚至于重新开发。 Webapp的特性 W3不光只有html，java，asp，php都属于w3的，webapp是独特的软件类型，但是绝大多数的webapp逃不过以下属性 网络密集性 并发性 无法预知的负载量 性能 可用性 数据驱动 内容敏感性 持续演化 即时性 10.安全性 11.美观性 说完了软件，我们接谈谈软件工程，在21世纪得今天我们做一个软件产品，有如下几个事实： 软件已经融入我们生活 个人、企业和政府的信息技术需求日益复杂， 对特定的用感价值会增加软件的寿命 所以软件要工程化，那么软件工程到底是什么？软件工程的定义如下： 将系统化的、规范的、可量化的方法使用到软件的开发上。 软件工程是一种层次化的技术，层次如下： 那么“怎么做”是一个问题