敏捷开发

例如：WMS项目中我们有表ECI_DATA_CACHE 表 下面就来显示怎么样开发这个画面的基本功能 首先分析下： 我们需要开发两个画面 查询列表页 编辑维护页 后台提供4个API 保存、删除、查询、加载 打开辅助开发工具：如上图 数据表填写 ECI_DATA_CACHE 点击【一键所有】 生成了这个功能的所有层的代码 下面就是拷贝、拷贝、还是拷贝 就完事了 接下来：需要在权限平台维护对应的菜单地址： 点击编辑 点击保存，系统保存成功。 至此，一个基本的功能 就开发完毕了，没有写一行代码，全部是拷贝、拷贝。 当然了很多时候，这样子还是不行的，需要开发人员根据业务的实际需要进行调整。 在已有代码的基础上调整就为轻松非常多了。 已经实现的功能 查询列表页 编辑维护页 后台提供4个API 保存、删除、查询、加载 包括默认的导出Excel都是OK的！ 接下来就是对不满意的地方进行微调！ 来源： oschina 链接： https://my.oschina.net/u/4344760/blog/4316311

1. SCRUM会议 会议记录表(2020-05-29) 组员 昨天完成的任务 今天花了多少时间 还剩余多少时间 遇到什么困难 今天解决的进度 明天的计划 221701224叶博宁 对接新的后端 6.0 2天 暂无 群组详情的布局优化 尝试实现一下通知设置为已读 221701340沈志峰 错误处理机制完善、添加通知自动转待办接口 3.0 2天 暂无 完善对通知自动转待办的测试修复测试过程中登录用户获取失败漏洞 进行单元测试 221701221赵伟男 初步实现用户注册邮件发送时间间隔限制功能 3.0 2天 暂无 完善用户注册邮件发送时间间隔限制功能 错误处理机制 221701331陈赐 完善错误机制和待办事项搜索接口 1.0 2天 暂无 实现分类的搜索接口 进行单元测试 221701233岳逾先 修改部分代码符合规范 2.0 2天 暂无 切换新的后端 样式和布局优化 221701103郑澜 修改用户中心接口地址，使其适配新的后端项目 2.0 2天 暂无 修改用户中心URL资源，代码符合规范 优化代码修复BUG 221701235张必润 优化样式 2.0 2天 暂无 为备忘录模块所有页面添加一个搜索框 优化待办事项样式 221701327王清斌 暂无 0.0 2天 暂无 暂无 暂无 会议照片 Commit记录 Issue链接 https://github.com/abse4411

接上一篇： 我们一起开发了 查询页面和编辑页面： 看状态这个字段： 如果下拉框是固定的，可以如下实现： 直接硬编码： 执行效果如下： 如果需要增加一个空：或者叫请选择 以上是简单的情况， 但是如果这个下拉框的内容是动态的呢，就不能硬编码了。 那就面临规划： 规划有不同的层级， 我们有很多选择，不同的处理方式，有其特定的适用场景。 例如我们这个例子：状态是动态的，也不是太多，也不建议创建单独的表对它进行维护。 那么我们可以将它定义为基础参数 我们基础参数维护功能 打开框架提供的公共参数维护画面 我们点击新增，先定义个参数 我们定义一个 缓存状态 这个概念 对应的英文： CACHE_STATUS 保存成功： 点击明细 维护两笔数据 接下来要创建数据选择数据源 如上图，我们定义了一个数据源：CACHE_STATUS 后面就可以直接在画面中使用这个数据源 例如编辑画面的代码： 显示效果如下图： 如果希望增加一个 空的选项呢 打开调试看到，有个combox下拉框数据的请求，通过名称 CACHE_STAUTS 到后台自动完成请求并绑定到控件上 开发人员不需要特别关注，只需要记住我们定义的资源名称即可。 =================继续================== 我们面临的情况是，很多下拉框的数据，都是稳定不变的 那么每次都要从后台查询，这样是有点浪费性能

在一个不断发展的大型应用中，新的业务需求和功能不断增加，技术也在不断演进，不同团队构建的功能子系统采用的技术架构五花八门，子系统之间的开发、部署和运维模式也存在较大差异。 如果企业内部没有统一的服务框架进行技术层面的拉通，开发和运维效率都将受到很大制约。 传统垂直架构改造的核心就是要对应用进行服务化，服务化改造用到核心技术就是分布式服务框架。 分布式服务 分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。 逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的。 比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。 分布式服务架构与微服务的区别 分布式服务架构强调的是服务化以及服务的分散化，微服务则更强调服务的专业化和精细分工。 从实践的角度来看，微服务架构通常是分布式服务架构，反之则未必成立。所以，选择微服务通常意味着需要解决分布式架构的各种难题。 微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高

面试的时候你首先要明白一点： 面试官有非常大的可能是不会自动化的： 他们有的全程不问你自动化的知识，有的全程都问自动化，问自动化的UI，API知识，不懂还想懂，问的问题你都忍不住想笑。当然我们不能流露出对面试官的鄙视，要对他的问题作出详细的讲解，让他能够听明白。（一般问自动化的问题，两三个就能够判断出面试官会不会自动化，最后问了一下他们是如何进行自动化的，他们告诉我录制的。你懂得，录制的脚本有多难用，多容易出错，开发们改一点东西就会崩溃）。 测试很注重基础知识，希望大家有时间把测试基础多多温习。 1.自我介绍： 2.你是如何保证测试完全的。 测试点挖掘到页面的每一个元素，空间。使用边界值等价类等方法挖掘出系统级的测试用例。使用场景法和流程图挖掘出冒烟级测试用例。测试用例不只要有正向的还要有逆向的。 3.测试用例包括哪些点 4.敏捷开发了解吗？敏捷开发的流程 5.你们是使用什么框架，语言进行自动化开发的 6.你认为自动化有必要吗？他有什么优势。 7.自动化的时候遇到过哪些问题，你是如何解决的。 8.会性能测试吗？了解Jmeter吗 9.postman是如何使用的，具体说一下。 10.数据库了解吗？使用的是什么数据库。常用的语法知道吗 11.你们使用什么工具来管理测试用例？说一下他的流程是什么？（禅道） 12.当你认为是bug，开发不认，你如何解决？ 13.与同事产生矛盾该怎么办？

第四天 日期：2020/6/15 2.1 今日完成任务情况以及遇到的问题 2.1.1 今日完成的任务 团队成员 今日完成的工作 王嫄 Alpha版本首页整体框架设计 牛莉梅 实现用户数据库，首页最新图书页面制作 祁甜 检查接口，首页热门图书页面设计 王爽 实现前端数据检查以及与后端的通信，首页必读书目页面设计 2.1.2 遇到的问题 团队成员 遇到的问题 王嫄 没有遇到问题 牛莉梅 数据库设计时候，哪些值可以为NULL，哪些值不能，很难有统一的规定 祁甜 没有遇到问题 王爽 模块之间如何联系起来，互相通信，不太容易实现 2.2 成员贡献时间 团队成员 王嫄 牛莉梅 祁甜 王爽 贡献时间 2h 3h 2h 2h 工作量比例 20% 40% 20% 20% 2.3 明天任务安排 团队成员 明天的任务安排 王嫄 个人中心页面整体框架设计 牛莉梅 个人中心页面制作 祁甜 书架页面整体框架设计 王爽 书架页面制作 2.4 站立会议照片 2.5 项目燃尽图   由于所用的Leangoo在线燃尽图制作工具过期，所以，这里只能给出剩余天数的燃尽图 2.6 项目进展情况   今天的主要任务是进行数据库创建和注册功能的实现，后续会开始详细的页面设计，因此，我们得加快进度才能保证项目顺利完成。 首页设计，热门图书设计，必读书目设计，成果截图展示如下： Github迁入记录 来源： oschina 链接：

这个作业属于哪个课程 2020 春福大软工实践 W 班 这个作业要求在哪里 团队作业第六次——beta冲刺+事后诸葛亮 这个作业的目标 Beta冲刺 集合随笔 集合随笔 其他参考文献 《构建之法》 SCRUM部分: 学号 今日进度 遇到的困难 明日计划 221701408 文章详情页，编辑资料页面 登录页 041701124 文章详情api 用户点赞模块 221701413 修改邮箱页面，搜索列表页 个人空间 221701418 指定用户的文章api 文章评论模块 SCRUM 会议的照片 PM 报告： 学号 预计任务量 目前已花费时间 剩余时间 221701408 40 34 6 041701124 45 40 5 221701413 55 45 8 221701418 60 62 8 燃尽图 每名成员的贡献比 学号 贡献比 221701408 20 041701124 20 221701413 30 221701418 30 221701441 0 221701205 0 221600233 0 来源： oschina 链接： https://my.oschina.net/u/4254968/blog/4308145

Scrum精髓之咀嚼篇一：Scrum定义及流程 Scrum精髓之咀嚼篇一 Scrum到底是个啥？ 为什么用Scrum Scrum角色 流程 下期预告 Scrum精髓之咀嚼篇一 前两天刚刚完成了和几个部门大佬们的deep dive，结果负责的产品线受到了很大的关注。一方面大佬们发现了各个部门对我们产品依赖性极强，另一方面大饼画的足够好，大佬们发现了未来的发展空间。比较严重的是，我们组开发人数稀少，成了被需求侧同事炮轰的对象【手动捂脸】。作为刚入职的PM，只能停下了摸鱼的生活，被迫营业了 与此同时，我发现了几个较为严重的问题： 作为PM自身虽然独立负责过很多需求，但是对于整个项目管理知识相对匮乏，老板提到的backlog、sprint planning等概念之前并未有过任何了解，感觉自己 像个白痴 组内产品需要对技术有较深的理解，需要深入到AI算法、训练框架、推理引擎等 多个层面理解产品 ，给出相应的规划 组内 资源匮乏 ，但是承接项目过多，支线任务繁多，产品迭代周期较长。其他组同事需要我们的时候，我们只能第一时间给予一个温暖的拥抱 总结一下，找到合适的项目管理对策，合理利用资源并深入结合产品特性进行规划和迭代，对我至关重要。搜索老板提到的backlog、sprint planning后我找到了这本救命稻草----Scrum精髓 Scrum到底是个啥？ 没办法，搜索这几个关键词

原文作者：Sjoerd Nijland 原文地址： https://medium.com/serious-scrum/the-sprint-planning-c24df3e09779 翻译：柴晓燕&付新圆 对于敏捷中的活动有很多，本文先从Sprint计划开始，分享一些方法、建议和注意事项，这些对理解和实践Scrum都很有帮助。 Who？ Sprint计划的参与者：整个Scrum团队。 请注意， Sprint计划是 一个积极的、合作的活动。如果需要的话，大家可以随意走动查找资料或解决问题。开发团队可以召集其他人来帮忙，在会议期间能收集到更多信息。 “开发团队还可以邀请其他人参加，以提供技术或领域建议。” — Scrum指南 参与性 并不是每位成员都会在参与活动时表现出积极主动和创造性，有些成员只有在感到自信或舒服时才会加入。 出勤率和参与度低都会降低透明度，并带来风险。Scrum Master认为每个人都参加和参与是他们的责任。 “ Scrum Master可以确保活动进行，并确保参与者了解其目的。” — Scrum指南 我认为，解释出勤和参与的价值，同时创造一个舒适、愉快、平静和尊重的环境，是Scrum Master 激励团队成员参与的最佳方法。 “给他们提供所需的环境和支持，并信任他们来完成工作。” —敏捷宣言。 有时，参与者可能会占据主导地位

写在前面 这个作业属于哪个课程 <班级的链接> 这个作业要求在哪里 <作业要求的链接> 团队名称 啥都有 这个作业的目标 beta冲刺 作业正文 正文如下 其他参考文献 ... SCRUM部分 Part1.每日汇报 学号 昨日进展 遇到困难 今日任务 明日安排 221701105 实现记住我功能 无 实现注册功能 邮箱发送验证码 221701207 用新的函数完善所有的老接口，并且将分区和热点加入进去 无 实现取消订单，订单投诉，获取评论信息，发表评论的接口 评论回复、违规评论举报、发表评论 221701212 完成忘记密码界面，调整布局 如何用CSS截取过长的文本(已解决) 搜索结果布局调整完毕，并加入热卖商品推荐功能 与评论区查看他人信息功能对接，实现头像图片裁剪 221701218 商品详情页完善购买操作、以书易书适配 暂无 订单申诉以及订单相关交互，评论区点击查看他人信息 毕业专区样式，测试部分接口交互 221701229 已发布页面框架，发布页面条件显示输入 如何使许多输入表单的页面更美观 已发布商品列表测试完成，图书专区页面调整，管理员端完善 消息通知 221701235 实现举报处理相关接口，实现获取通知列表接口，修改管理端封禁用户接口（新增下架其商品、删除其评论操作） 暂无 已发布商品相关接口（获取列表、修改、下架） 根据分区在相应视图中查询并返回热榜商品