敏捷开发

小谷围驻广东某工业719电竞大队—团队合作项目 Teamwork project <br/> ## 一、团队展示 ## #### 1. 队名： #### >小谷围驻广东某工业719电竞大队 #### 2. 队员： #### | 成员 | 学号 | 成员 | 软工角色 | |---------------|---------------|---------------|---------------| | 何思敏 | 3216005167 | 产品策划 | （组长）产品经理 | | 刘粤轩 | 3216005168 | | UI设计 | | 叶文涛 | 3116004708 | Java 开发 | 后台开发 | | 罗展宏 | 3116005151 | 前端开发 | 前端开发 | | 姚康友 | 3116004707 | 前端开发 | 前端开发 | | 谢东洪 | 3116005159 | 前端开发 | 测试 | #### 3. 团队项目描述： #### >广工生活社区 #### 4. 团队的首次合照： #### > #### 5. 团队的特色描述： #### > 719电竞超级爱开车小分队 <br/> ## 二、选题要求 ## - 确立团队选题，确定之后每个团队需要写描述要做的究竟是什么系统

云原生成为趋势之际，企业对容器监控的需求日渐增长，Prometheus也日益受到关注，随之掀起了新一轮关于监控选型的探讨。 Zabbix 因轻量、 成熟度高 、开发门槛低等优点被广泛应用，但在 云环境下却 渐显力不从心。 该如何对 二者进行选型和 应用？ 针对大家关心的监控问题，dbaplus社群开启【deeplus · 当打之年 】 第一期，邀请到分别专研于 Prometheus 和Zabbix的两位专家，在线上直播间连麦探讨，帮大家答疑解惑： 直播时间 2020年9月12日 14:00-16:00 【线上直播间】 直播议程 ① 讨论 - 关于Prometheus与Zabbix，你最关心的核心问题（约20min） 两者各有哪些优劣异同？应该根据哪些方面进行选择？ 监控经常出现的告警风暴和误报，两者怎么进行解决？ 在故障自愈上，两者怎么结合其他手段实现？ 大规模场景下，两者怎么做架构搭建和优化？ 关于监控指标，单个指标与聚合指标该如何设计？需要做什么区分吗？ 基于开源监控工具做自研监控平台，从哪方面入手更好？ 二者怎么解决存储问题？ 如何基于二者做分布式监控架构？ …… 更多讨论议题 由你决定！ 点击文末 阅读原文 ，报名并填写你希望听到或感到疑惑的监控话题，让这次探讨的内容真正 为你适用！ ② 案例 - 基于Prometheus与Zabbix的实践经验分享（约60min） 主题：

随着敏捷在国内的推行，越来越多的公司和组织开始使用敏捷领导团队。 敏捷团队如雨后春笋之势涌现。 敏捷教练的团队也越来越壮大。 原先只需要一个敏捷教练就能搞定，但是随着团队越来越多，我们难免会将一些新成立的或者已有的团队交接给新的敏捷教练。 如何做好敏捷团队的交接也是我们面临的最现实的一个挑战。 每次当有新的scrum master入职，接到领导分配给他的一个scrum Team，会思考的第一个问题，可能就是：我到底要做些什么。 情境领导模型 对于如何领导一个敏捷团队，Mike Cohn的一篇文章对此进行了详尽的阐述。 （引1） Paul Hersey的情境领导模型，该模型描述了团队的四个准备阶段，处于每个阶段中团队的意愿和团队能力都有所差异。 根据Hersey的说法，领导者需要调整自己的行为以适应团队的准备程度。并因此引入了任务行为与关系行为： 以上模型清晰的阐述了一个scrum master需要基于团队的状态，调整带领团队的方式。看完上面的模型，你可能非常认同这个关系和任务行为模型。 当你开始认真琢磨如何使用这个模型的时候，你可能会突然发现无从下手。 对于一个刚刚接手一个scrum的scrum master来说，直接根据以上模型应用到自己的团队，几乎是不可能的事情。在我们试图按部就班的按照模型采取行动的时候，我们可能会处处碰壁。 我们一直在强调，研发人员，产品经理并非资源。

转自本人运营的公众号“ 携程技术中心PMO ”（ID：cso_pmo） 关于我们 我们面临的挑战 敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。先把一个大项目分为多个相互联系、可独立运行的小项目，再分别完成，而在此过程中软件一直处于可使用状态。 敏捷开发模式可以对过程进行自主调整，它强调人的因素，能够灵活响应需求和技术的不断变化，并且产出高质量的软件产品。 实行敏捷开发之前，我们面临的挑战： 如何令30多人的团队保持高效运作？ 如何定义BU和内部需求的优先级？ 如何迅速将需求实现并落地？ 与时俱进，迅速转型 第一步，将团队拆分为三个相对独立的小团队，保证在快速迭代的同时保持高效沟通。 第二步，从需求着手，积极向敏捷模式靠近。 产品同学明确当前阶段的KPI/OKR，按照ROI和紧急程度区分优先级； 开发同学提前进入以便聚焦技术方案，拆解并认领工作任务，加强配合； 测试同学共同思考验收标准并执行严格的测试流程。通过单元测试、功能测试的案例，提前规避风险； 成员紧密地配合，验证需求强度和假设，以迅速推动产品更新和迭代； 通过sprint计划会，可以更加明确团队成员的任务和目标。而通过每日站会，可以更迅速地同步项目开发进度。 第三步，充分利用iKanban高效管理产品需求，需求饱和度及完成度一目了然，进一步提升团队工作效率。 我们的收益 如何评估敏捷的效率呢

学习资源 1.教材P28-P76 2.第3章教学课件3.1-3.8 3.corejava.zip中第3章示例程序3-1—3-5 4.Eclipse简明教程.pdf 5.MOOC & 视频：浙江大学 翁恺老师：零基础学java 1.2-1.3、2.1-2.4、3.1-3.2、4.1-4.3、6.1-6.3 周次 （阅读/编写）代码行数 发布博客量/评论他人博客数量 课余学习时间(小时) 学习收获最大的程序阅读或编程任务 第一周 70/10 1/1 6 JDK、eclipse的安装、九九乘法表的编译 第二周 90/40 2/1 8 数据类型的总结，第三章实验四、实验五、实验六 第四周 　　200/60 1/0 10 掌握类与对象的基础概念，理解类与对象的关系； 2. 掌握对象与对象变量的关系； 3. 掌握预定义类Date、LocalDate类的常用API； 4. 掌握用户自定义类的语法规则，包括实例域、静态域、构造器方法、更改器方法、访问器方法、静态方法、main方法、方法参数的定义要求；（重点、难点） 5. 掌握对象的构造方法、定义方法及使用 6. 理解重载概念及用法； 掌握包的概念及用法 第六到七周 526/62 1/0 12 1.深入理解程序设计中算法与程序的关系； 2.深入理解java程序设计中类与对象的关系； 3.理解OO程序设计的第2个特征：继承、多态； 4

因为所接触的业务复杂度高、技术难度大，不能像之前开发APP那样拿到需求后画画流程图、定一下各领域的时间节点和项目里程碑就开干，因为不对技术做抽象并输出技术方案设计文档是讲不清楚项目的整体实现方案的，即使做出了功能，只要技术指标不达标（比如准确率低、耗时长等），就很难达到和产品预期相符的用户体验。所以需要有和类似于大型项目的服务端技术方案设计一样，对客户端APP做技术方案设计的环节，设计出高性能和高扩展性的技术方案，避免项目风险大、项目目标难达预期、技术债务堆积等问题。 移动端的技术方案设计，同样要遵循合适（合适优于业界领先）、简单（简单优于复杂）、演化（演化优于一步到位）的原则，以高可用、高性能和高扩展性为目标。相比于服务端的技术方案设计，做事的思路和方法都差不多，只是侧重点不一样而已。 在做技术方案设计时，我对自己的要求是需要遵循如下几大原则： 成事心态：作为架构师，在设计技术方案时要想方设法达成产品需求和目标。即使产品需求实现难度大、目标不切实际、技术上存在瓶颈，经过严谨的分析验证后，在客观陈述技术瓶颈的同时还要基于对用户需求的洞察给出自己对产品方案的建议，推动其它领域一起去促成项目目标的达成； 全球视野：对于技术难度大或没有头绪的事情，多看看同行头部企业是怎么做的，尤其是自己不了解、认为有难度的地方，要通过查阅资料、深入交流等方式，去开阔自己的视野，切忌成了井底之蛙在坐井观天

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

目录 DevOps是什么？ 为什么我们需要DevOps？ DevOps与敏捷开发有何不同？ 重要的DevOps工具是什么？ Docker如何帮助DevOps？ Kubernetes如何帮助DevOps？ Azure DevOps如何帮助DevOps？ 持续集成，持续交付是什么？ 基础架构即代码是什么？ Terraform和Ansible如何帮助DevOps？ DevOps是什么？ 与围绕软件开发的大多数流行语一样，DevOps没有公认的定义。 定义从简单（如这两个定义）到复杂（可以持续一整本书）不等。 DevOps是文化理念，实践和应用快速交付工具的组合–AWS DevOps是组织内部的跨学科协作，旨在确保软件新版本的自动化持续交付，同时确保其正确性和可靠性 –L Leite 与其尝试定义DevOps，不如让我们了解软件开发如何演变为DevOps。 瀑布模型(Waterfall) 几十年前，软件开发以Waterfall模型为中心。 Waterfall模型开发，与建筑项目类似-例如，建立一座令人惊叹的桥梁。 你将分多个阶段构建软件，这些阶段可以持续几周到几个月不等。 在大多数Waterfall项目中，企业要几个月才能看到应用程序的有效版本。 构建优秀软件的关键要素 在瀑布模型中工作了几十年，我了解到了开发出色软件的一些关键要素： 沟通 反馈 自动化 沟通的重要性

好久没有更新简历了，于是更新了下个人简历，算是自我总结吧，这也是多年来养成的一种习惯，定期维护更新。简历更新后，很快就接到了很多电话(虽然简历设置了不对外公开)，目前我还没有换工作的打算，除非有非常合适的机会，哈哈！所以90%的面试机会我还是不由分说的拒绝了。 某天接到了一位猎头的电话，被告知是thoughtworks的岗位，问及是否有兴趣考虑。对这家公司之前还是有些了解的，以技术、咨询为驱动，敏捷开发而闻名，于是相互加了微信，了解一下总归没有坏处。于是，就有了接下来的经历，在此与大家分享一下，记录如下。(Homework、Pair Program、Face-to-face Interviews真的是非常棒的面试指导，值得仔细阅读) 1、猎头初聊 猎头加了微信后，发来了thoughtworks介绍及岗位JD，我主要看了下岗位JD，岗位还是偏于技术为导向的，相对吻合，就答应可以考虑，先看看。 随后，猎头与我约定时间进行了电话沟通，沟通的主要内容： thoughtworks公司介绍 岗位JD介绍 个人情况了解 电话聊了将近一个小时，首先进行了简单的自我介绍，近期工作内容、所用技术栈、团队人员组成情况、平时遇到问题是如何解决的、自己的未来职业规划等等这些问题，反正关于个人情况问的特别细，不输于一场技术面试。 接下来，就是猎头介绍了岗位JD情况、TW情况、以及TW面试流程的特殊性等。

#2019第十一周作业 #2019年春季学期第十一周作业 课程名称 c语言程序设计2 作业要求 第十一周作业 我的课程目标 了解使用递归的方法来进行解决问题 这个作业在哪个方面帮助我实现目标 了解了递归这种方法 参考文献 课本c语言程序设计 ##单选题 2-1.宏定义“#define DIV(a, b) a/b”，经DIV(x + 5, y - 5) 引用，替换展开后是（A）。 (1分) A.x + 5 / y - 5 B.(x + 5 / y – 5) C.(x + 5) / (y - 5) D.(x + 5) / (y - 5); 2-2.定义带参数的宏“#define JH(a,b,t) t = a; a = b; b = t”，对两个参数a、b的值进行交换，下列表述中正确的是（C）。 (1分) A.不定义参数a和b将导致编译错误 B.不定义参数a、b、t将导致编译错误 C.不定义参数t将导致运行错误 D.不需要定义参数a、b、t类型 2-3.如果所有的变量按照下面的程序进行定义和声明，那么在main()函数中所有可用的变量为 （C）。 (2分) void fun(int x) { static int y; …… return; } int z; void main( ) { int a,b; fun(a); …… } A.x,y B.x,y,z C.a,b,z D.a,b