敏捷开发

开发模型 1.瀑布模型（Waterfall Model） 瀑布模型是按线性顺序进行的开发模式，主要有计划、需求分析、设计、编码、测试和运行维护这几个阶段。当每个阶段结束的时候都会进行自我验证，如果出现问题就返回上一个阶段。 优点：强调开发的阶段性； 强调早起计划及需求调查； 强调产品测试。 缺点：依赖早期进行的唯一一次需求调查，不能适应需求的变化； 项目的风险要到后期的测试阶段才显露，失去及早纠正的机会； 可以运行的产品要等到项目完成才能被看见。 2.螺旋模型（Spiral Model） 当软件开发初期需求不是很明确的时候，就需要渐进式的开发模式，螺旋模型就是渐进式的开发模型。螺旋模型适用于规模庞大、复杂度高、风险大的项目。螺旋模型有四个阶段：制定计划、风险分析、实施工程、客户评估。这四个阶段是迭代进行的，这种模式在软件测试的时候不允许有一段独立的测试时间和阶段，测试必须随着开发的迭代而迭代。 优点：强调严格的全过程风险管理； 强调各开发阶段的质量； 提供机会检讨项目是否有价值继续下去。 缺点：由于引入了严格的风险标识、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求； 还需要人员、资金和时间的投入。 3.增量开发/迭代开发 增量开发：是将要开发的软件模块化，每个模块为一个组件，从而可以分批次的研发出这些组件。例如画一幅人物画，用增量模型的角度来看就是先画人的头部

摘要： 本文介绍了成熟度模型在软件开发行业的应用，重点阐述了成熟度模型对于敏捷和DevOps在企业中进行规模化推广的价值，探讨了成熟度模型的设计原则，并对于如何明智使用成熟度模型给出了建议。 导言 在敏捷和DevOps社区，尽管对成熟度模型一直有些争议，但使用各种成熟度模型来指导转型的尝试却从未停止过；从笔者的从业经历来看，谨慎地使用成熟度模型，对敏捷和DevOps在企业中的规模化推广具有很重要的现实意义。 成熟度模型简介 “团队定期地反思如何能提高成效，并依此调整自身的举止表现”，这是敏捷宣言的一个原则，它鼓励我们持续地对软件开发方法进行改进。这种改进直接表现在提升团队的效能（更多的价值，更快的交付速度，更高的交付质量，以及更低的成本等），最终服务于企业的业务目标。改进通常由团队交付业务价值所面临的问题或挑战触发，团队共同识别改进点，采取改进措施，检查改进成效，再发起新的改进；周而复始，永不停歇。 针对软件开发方法的改进没有终点，这个漫漫长路需要指引，成熟度模型正是为了满足这一需求。所谓成熟，意思是长大和成长，指生物体发育到完备的阶段，或事物发展到完善的程度。虽然成长的过程是连续的，但还是可以通过观察主体特征的明显变化来确定一些阶段，譬如人类成熟的过程可以分为婴幼儿、儿童、青少年、成年、老年等阶段。基于这个隐喻，成熟度模型使用一个结构化的框架

这个作业属于哪个课程 2020春|S班（福州大学） 这个作业要求在哪里 团队作业第六次——beta冲刺+事后诸葛亮 团队名称 软工实践互动评价小组 这个作业的目标 beta冲刺 作业正文 其他参考文献 2020/06/02 Part 1 -> SCRUM 一、成员描述 学号 遇到的困难 今日进度 许家诚 无 页面优化 陈 茜 无 完善页面细节，day7博客 傅少华 无 优化搜索功能，加入模糊搜索 肖玮昊 无 使用Jmeter测试了多人(100人)同时使用时的性 蔡 俊 无 完成的接口测试全部测试，对web的跨设备响应进行屏幕测试，对昨天出现的问题重新测试了，对web的性能进行了测试 张增燊 接口文档的一些接口的描述和实际不符合，需要修改接口文档 解决昨天遇到的困难，修改了接口文档的一些内容 蔡鸿辉 无 优化代码，增加可读性 陈家祯 无 改进部分接口代码 二、开发测试截图报告 commit记录 测试结果 2.1 性能测试 测试报告：接口测试完毕，对之前存在问题的接口测试了，已经解决了问题，对web的性能进行了检测，http请求未发现错误，平均响应时间为289毫秒，部分响应过久，达到预期目标，对56台跨设备的响应式屏幕测试包括平板手机，只有Galaxy Note9未作出响应，原因未知，显示器尺寸改变，显示都正常。 2.2性能测试 测试范围：多人(100人)访问时的性能 测试方法

背景 名词解释 如果你的团队目前正是构建微服务架构风格的软件系统，问自己两个问题？ 软件架构演进 软件架构大致经历了从单机架构，集中式架构，分布式微服架构，程序的层次图如下所示。 单机架构 特点如下： 1， 面向过程的设计方法； 2， 结构为CS； 3，程序的层次分两层，即UI层和数据库层； 4， 设计的核心在数据库和字段。 集中式架构 特点如下： 1， 面向对象的设计方法； 2，程序层次为经典的3层架构，即业务接入层， 业务逻辑层，数据库层； 3，部分企业也采用SOA架构风格； 4，集中式的架构缺点：扩展性，伸缩性差，系统容易变得臃肿； 分布式微服务架构 特点： 1， 基于微服务的理念：分而治之，模块高内聚（独立团队，独立部署，独立存储，技术异构），模块之间通过RPC或者HTTP通信，松耦合； 2，模块之间松耦合，解决了扩展性和伸缩性的问题； 架构对比 单体架构和集中式架构，系统分析， 系统设计，系统开发这3个阶段是割裂的，即分属3个不同的人或者小组或者岗位的人负责，这样的后果是： 1， 系统分析，设计，开发三个阶段的信息不一致，导致上线之后功能跟需求偏差非常大； 2， 系统的开发无法快速响应需求和业务的变化，错失发展的良机。 微服务的困局 微服务解决的问题 微服务解决了单体架构和集中式架构的问题：扩展性，弹性伸缩，敏捷开发快速响应业务变化； 但是微服务并非毫无缺陷。

apache jmeter是apache软件基金会出品的一款用于接口测试，压力测试的开源软件，由于其免费开源，插件j自由扩展，跨平台，所以理论上可以支持所有种类的接口测试。jmeter自身也已经提供了许多优秀的插件，极大地增强了jmeter的能力。 问题引入 jmeter提供了两种运行模式，一种是GUI模式，一种是CLI模式，这两种运行模式有各自的场景： GUI-图形用户界面： 顾名思义，用户可以在任意支持java的操作系统上打开一个jmeter客户端，因为GUI模式下提供了可视化的脚本编排工具，因此常用于脚本编排。 CLI： 命令行模式，也叫non-GUI，headless（无头模式），可以在不启动jmeter图形客户端的情况下发起脚本测试，CLI模式是更常用的jmeter运行模式，因为不需要启动图形客户端，所以该模式下占用的资源会更少，是在负载测试和压力测试中最常用的运行模式。 无论使用jmeter执行何种类型的测试，都离不开脚本的编排，GUI模式下固然可以编排脚本，但是这种方式在面对现在越来越盛行的敏捷开发及devops理念时稍微显得心有余而力不足，主要的问题在以下几个方面： 碎片化严重： 当新的需求完成或旧的需求发生变更时，需要重新编排测试脚本，脚本很难管理或碎片化非常严重。 历史记录难以回溯： 每次使用jmeter进行性能测试都会生成新的日志、报告

这个作业属于哪个课程 2020春|S班（福州大学） 这个作业要求在哪里 团队作业第六次——beta冲刺+事后诸葛亮 团队名称 学长帮帮组 这个作业的目标 冲刺第六天！！ 作业正文 学长帮帮忙—Beta冲刺（7/7） 其他参考文献 暂无 SCRUM部分 Part1-每日汇报 学号 昨日进展 遇到啥困难，今日解决的进度 221701423 完成部分代码的检查，优化部分逻辑，花了一小时 无困难，今天根据测试提交的问题进行修复工作 221701222 完善用户帮扶模块，花了1小时 暂无，进行前端参数校准 221701203 进行布局部分的代码复审，完善页面，花了一个多小时 今日继续进行代码复审并进行项目的收尾工作 221600423 协助进行代码复审完善页面，花了一个小时 协助进行代码复审 041701407 测试并优化所有接口，系统消息完善，用时3个小时 要是能早点写个生成数据库虚拟数据命令就好了。 221701404 为消息模块添加查找聊天记录功能，用时一个半小时 协助后端对新增模块进行接口测试，暂无困难 221701305 完成辅导模块的代码复审，用时一小时 无困难，今天进行了真机测试，发现了一些bug 221701121 帮扶模块代码复审，花了一个多小时 暂无，剩余模块代码复审 221701320 辅助测试剩余接口，花费一个小时 进行剩余部分模块的测试，暂无问题 Part2

项目 内容 课程班级博客链接 https://edu.cnblogs.com/campus/xbsf/nwnu2020SE/ 这个作业要求链接 https://www.cnblogs.com/nwnu-daizh/p/13190137.html 团队名称 莫得感情的Coder 团队成员分工描述 冯志霞：“我的”模块功能测试,博客撰写； 李晓菁：“记录”模块功能测试，测试方案撰写； 马昕璐：“记录”模块功能测试，博客撰写； 唐月晨：“推荐”模块功能测试，博客撰写 团队的课程学习目标 掌握软件黑盒测试技术，掌握软件项目确认测试内容，学会编制软件项目总结PPT。 这个作业在哪些方面帮助团队实现学习目标 通过团队合作学习，每日的讨论与交流，学就会了在项目过程中beat阶段的冲刺该如何有效执行 团队博客链接 https://home.cnblogs.com/u/mdgqdcoder 团队项目Github仓库地址链接 https://github.com/fengzhixia17393162576/fit-u- 1. Beta 冲刺Scrum meeting导航 【Beta】 Scrum meeting 1 【Beta】 Scrum meeting 2 【Beta】 Scrum meeting 3 【Beta】 Scrum meeting 4 2.提供任务1要求在团队项目仓库中上传测试文档

这个作业属于哪个课程 2020春软工实践|W班 这个作业要求在哪里 作业的要求 这个作业的目标 团队及项目简介 作业正文 作业正文 其他参考文献 无 一、SCRUM部分 昨天进展、存在问题、今天安排 221701127(李昊天) 昨日进展:由于内存不够服务器挂在搁置，考虑本地配置映射外网 存在问题:钱不够换不了内存更大的服务器，由于部署WAR包的空间需要较多，组内没有足够的资金 今天安排:把本地部署调试到最佳状态，寻找服务器空间不足是否有其他部署方法 心得体会:第一次遇到项目因为资金问题导致任务无法完成，感觉一下子非常真实 221701138(林亿祥) 昨日进展:接口继续对接中 存在问题:老问题，传过来的参数有少部分错误，或是数据库内测试用例出错 今日安排:继续进行对接，同时修复对接中发现的前端BUG 心得体会:最后阶段，坚持就是胜利，希望项目顺利完成 081700308(付其佳) 昨日进展：完善自己部分的全部接口 存在问题：暂无 今日安排：待命，等待修复可能出现的BUG 心得体会：自己部分完成之后感觉心情舒畅，希望其他组员也能加把劲 221701425(黄杰辉) 昨日进展：完成所有接口 存在问题：暂无 今日安排：待命，等待修复可能出现的BUG 心得体会：补充文档的过程用来结尾很能感受到自己做的东西确实完成了 221701434(曾峻祺) 昨日进展:修复了一些层的代码BUG

背景 在某开发团队辅导的回顾会议上，团队成员对于优化估计具体方法上达成了一致意见。询问是否有什么具体的估计方法来做估算。 问题分析 回顾意见上大家对本次Sprint的效果做回顾，其中80%的成员对于本次Sprint的估算效果不满意，最终团队希望在下一个Sprint中，估算活动能有所改善。 经了解，团队目前的估算方法很简单，基本上是架构师和团队中有丰富开发经验的成员一言堂。估算的速度也很快。对于有些有疑问的需求，开发成员也是保持沉默，草草认领了任务。 团队迫切希望学习新的估算方法来优化目前的估算活动，因此分享几个具体的估算方法给团队实践，让他们自己选择适合、喜欢的估算方法是解决问题的关键。 解决措施 我们来学习下具体的故事点估算的实践，感受一下估算。这里介绍最常用的两种估算方法：一个是计划扑克估算，另一个是敏捷估算2.0。下表内容展示了这两种估算方法在什么情形下选择。 计划扑克估算 在敏捷开发中，最典型的使用故事点做估算的方法是计划扑克（Planning Poker）。 计划扑克由James Grenning在2002年首次提出。计划扑克集合了专家意见（Expert Opinion），类比（Analogy）以及分解（Disaggregation）这三种常用的估算方法，使团队通过一个愉快的过程快速而准确的得出估算结果。 计划扑克的参与者是团队的所有成员。典型的敏捷团队规模推荐为7±2人

之前我写过一篇文章，关于 敏捷坑人系列不清晰的完成 ，在这篇文章当中，描述了完整的定义和验收标准之间的区别，但是最近的课程当中依然有不少小伙伴在提问关于完成的定义，那今天的来说一下，为什么我们要设定完成的定义（即其重要性） 完成？！ 在工作当中往往我们会说这个事情我完成了。当我们说完成的时候，每个人对于这个完成是有不同的定义。比如PO认为完成是需要包含完成编码，提交到代码库，完成单元测试，完成集成测试，完成功能测试，等等一系列的测试。 而开发小伙伴可能认为完成只包含代码，以及在自己的电脑上测试，没有问题就算是完成了。 那这两个完成之间是有很大的一个差距，而这个往往会造成大家对于完成的理解误区，及同时也会造成沟通上的冲突。 完成的定义 Definition of Done 在这个背景下，团队需要对于完成有一个统一的认识。这个完成会包含很多不同的层面及不同的步骤。 举例说，如果说一个产品功能完成了会包含什么？如果开发完成了会包括什么，如果测试完成会包括什么，这是不同的层面。但是在 Scrum指南 中完成默认是指的产品完成。 完成的定义就像是一道门槛 团队一起设好了门槛，能跳过去的功能（PBI）就是完成了，跳不过去的，就是没完成。没有完成一半或者完成90%这样的概念。 所以对于这道 门槛 我们要设多高，这个是看团队对于自己的要求是多少，以及团队对质量的要求是多少，这是非常重要的一一个概念