敏捷开发

对于企业来说，软件管理系统是为了能让业务更加高效的开展和赋能，但在当下这个时代，技术变化飞快，企业要求多的背景下，企业管理变革也相应变的快了起来，这就要求软件管理系统的调整和进化要求也越来越高，任何小调整都去找厂商在成本上也不划算，但是如果采用低代码平台开发，这些都迎刃而解，那么在进行中的企业数字化转型中，低代码开发起到哪些作用呢？ 一、双模IT模式下，低代码开发服务“敏态IT” 面对数字化时代挑战，大型企业都将目光投向了自己的 IT（或“科技”）部门，造成IT部门在过去数年时间开始大面积转型。上一波互联网原生企业，如阿里和腾讯，业务直接植根于 IT 平台之上，创造了多种线上的新商业模式，成为了很多大型组织渴求的目标。 而大型企业的IT部门在此之前仍然是成本中心的定位，依靠大量COTS（commercial off-the-shelf） 商用软件系统，如 ERP 和数据仓库，来支撑大规模的业务运作，经年累月形成了业务赖以生存的中后台。复杂的业务逻辑和流程处理让这些系统长成了庞然大物，很难达成数字化时代要求的高响应力。金融行业仍然在经历的“去 IOE” 历程便是市场倒逼下的IT架构转型。 为了应对这样的挑战，全球领先分析组织 Gartner 在 2016 年率先提出了双模IT（Bimodal IT），被很多大型组织 IT 和科技部门广泛引用，随后不同的咨询机构也有“双速”的类似提法

人活着就是在对抗熵增定律，生命以负熵为生。 ——薛定谔 一、 熵增定律 1、熵增定律 熵的概念最早起源于物理学，用于度量一个热力学系统的无序程度。热力学第二定律，又称“熵增定律”，表明了在自然过程中，一个孤立的系统总是从最初的集中、有序的排列状态，趋向于分散、混乱和无序；当熵达到最大时，系统就会处于一种静寂状态。 通俗的讲：系统的熵增过程，就是由原始到死亡的过程。“熵”是“活跃”的反义词，代表负能量。 非生命，比如物质总是向着熵增演化，屋子不收拾会变乱，手机会越来越卡，耳机线会凌乱，热水会慢慢变凉，太阳会不断燃烧衰变……直到宇宙的尽头——热寂。 2、软件系统的熵增 在软件开发、维护过程中。软件的生命力总是从最初的理想状态，逐步趋向于复杂、混乱和无序状态发展，直到软件不可维护而被迫下线或重构。这种损坏软件质量的因素的逐步增长，叫做软件的熵增现象，也即本文讨论的软件复杂性。 二、 系统复杂性 的表现 1、 表象 代码混乱、新人不易上手 代码高度冗余，复用性低，开发效率低 扩展和修改困难，牵一发动全身 业务数据错乱 程序性能低下 系统难以移置 BUG率居高不下 其它…… 2、深层原因 （1）变更放大 复杂性的第一个征兆是，看似简单的变更需要在许多不同地方进行代码修改 （2）认知负荷 复杂性的第二个症状是认知负荷，这是指开发人员需要多少知识才能完成一项任务

题图：from unsplash 01传统项目管理模式，让设计成为累赘 作为一名资深软件行业从业者，我以前一直从事项目开发。在项目执行过程中，往往会采用快速开发模式，按照软件工程的基本流程建立一套项目软件管理模式。 这个流程大概是这样的： 1，需求调研：大概花费合同周期的六分之一时间来进行需求调研，需求调研环节力求对用户需求进行全面的掌握，并整理成需求规格说明书。 2，总体设计和详细设计：花合同周期六分之一的时间进行项目的总体设计和详细设计，详细设计必须覆盖所有需求，甚至需要精确到伪代码的编写。 3.项目部署：剩下的时间进行项目的现场实施工作。 项目的周期和项目的范围往往各不相同，为了保证软件的质量，上述每一个环节都非常重要，哪个环节的缺少都会对项目完成无法弥补的困难。 有时候，有的软件公司往往为了更快的完成项目，会把软件设计人员和开发人员分成两支不同的组织，一支专门进行软件的设计工作，完成甲项目设计后就快速的投入到乙项目的设计过程中。而研发任务留给研发团队来完成，如果遇到设计上的问题，再由设计团队对软件设计进行调整，由开发团队进行实现上的完善。某种意义上讲，这种模式已经成为软件工业上的主流模式，无数家软件公司正是靠这种方式实现了一个又一个的复杂项目的。 然而，这种模式并非完美无缺，他也造成了一系列问题，尤其是单纯从设计角度来说。例如，由于过份的重视设计

FaaS介绍 微服务（MicroService）是以专注于单一服务/功能的小型单元块为基础，利用模块化的方式组合成复杂的大型应用服务。 FaaS是Function as a Service的缩写,可以简单理解为功能服务化。FaaS提供了一种比微服务更加服务碎片化的软件架构范式。FaaS可以让研发只需要关注业务代码逻辑，不再关注技术架构。 例如：FaaS提供“选择工作流模板”、“启动工作流”、“完成流程”、“查看工作流状态“功能，当触发“启动工作流”事件后，再研发所需的业务代码。业务与架构分离，让专业更加专业。 FaaS特点 无状态 目的：业务隔离 1、组件业务配置抽离，脚手架工程使用则配置。 2、项目适合即使用 脚手架工程pom.xml引入便使用 脚手架 目的：自定义模版，快速集成 版本化 目的：多元化的需求变更互不影响 概要 技术架构 以微服务为核心的前后端分离，业务积木装配式技术架构。传感器采集，物联网+互联网转换，大数据分布式、存储、计算、可视化加持。消息引擎、搜索引擎、工作流引擎全方位技术支持。 研发模式 Scrum敏捷研发，让每一次需求迭代（task），就像讲故事（story）一样简单。 交付流程 采用DevOps思想，实现有效的软件开发和运营，同时实现卓越的质量和用户体验。 技术栈 微服务 微服务（MicroService）是以专注于单一服务/功能的小型单元块为基础

Leon是我朋友里为数不多的富二代，也是那种为数不多的比较吸引仇恨的富二代。而他吸引仇恨的方式，则是“别具一格”的炫耀方式。 周末，Leon在Skype群组里发了一条讯息：你们都在加班吗？加班狗们纷纷回复：是啊，是啊。他叹了口气说，我也是，我能体会这种感受，哎，我们码农好辛苦哦。大家好像在参见吐槽大会一般，纷纷附和，是啊加班好辛苦啊老板好无耻啊人生好艰难啊。 Leon马上发了一张照片。点开大图，Wow，碧海蓝天，阳光沙滩，天空蓝到你怀疑人生。他手上端着莫吉托，冰块多到快要从杯中溢出来，一旁的小方桌上放着笔记本电脑。 众人又惊又怒：您老在三亚加班呢？您别秀了行吗？ Leon没有回答，只是默默甩出一个定位。大家点开一看，呵！好家伙，巴厘岛库塔海滩七个大字出现在电子地图里。随即他又在感叹：啊哟！即使是太平洋热情的海风，也低挡不住我对工作的渴望。 众人说：爬爬爬，给爷爬！幸好Leon并不经常在大家面前出现，否则一定会被暴打。 我认识Leon已经很久了，那年我刚大学毕业，独自从老家来到良滨这个南部沿海的国际化大都市，在城市西南角的系守町，与一位在良滨打拼多年的老学长合租。 那时候人生地不熟，也没谈女朋友，下班就宅在家里鼓捣智能手机。那个年代的玩机圈很流行刷机，也就是给手机重装不一样的系统。有的人刷机是为了提升手机性能，而有的就单纯感兴趣为了好玩，体验不同系统带来的新鲜感，我就是后者。

自动化测试背景 什么是自动化测试 机器代替手工测试，自动验证结果是否符合预期 自动化测试优点 替代大量重复手工测试 提升回归测试效率，适合敏捷开发 在非工作时间自动执行，工作时间查看测试报告 保证每次测试执行的一致性与正确性，避免人为错误 自动化测试劣势 一般用于回归测试，项目开发初期不适合使用自动化 不能全部取代手工测试，只能替代手工测试中机械化，重复度高的操作，自动化测试极少能够达到100%覆盖率 自动化测试非常脆弱，特别是UI自动化 自动化测试工作量(框架设计+脚本开发)比单次手工测试大很多，当自动化多次执行时，性价比才会凸显 自动化测试实施流程 1.评估自动化测试实施可行性 想要开展自动化测试，应该遵循以下几个前提条件： 需求稳定，不会频繁变更 研发和维护周期长，需要频繁执行回归测试 项目资源足够「人力」 2.测试需求分析 自动化测试到底要做到什么程度 自动化测试覆盖范围： 主业务流程 历史BUG较多的模块 基础重复的功能 优先级 3.制定测试计划 测试工具/框架选型 接口自动化：TestNG+HttpClient+Maven+Allure+Log4j web自动化：TestNG+Selenium 框架设计，自动化测试脚本开发时间计划表 脚本执行的策略，冒烟测试/回归测试的频率 定义自动化测试的输出，测试框架，测试脚本，测试数据，发现的缺陷，测试报告 测试数据生成 UI方法

前言 会议定点：大运村1号学生公寓 会议时间：2019/4/30 会议目的：确定进度，分配下阶段任务 <br /> 一、任务进度 <table border="1" align="center"> <tr align="center"> <th width="30">组员</th> <th width="240">上周任务进度</th> <th width="240">下阶段任务</th> </tr> <tr> <td>大娃</td> <td>后端模型正确性说明文档</td> <td>增加新的模型代码</td> </tr> <tr> <td>二娃</td> <td>记录会议内容，撰写博客</td> <td>阅读后端文档，辅助主PM</td> </tr> <tr> <td>三娃</td> <td>撰写帮助文档，明确Beta阶段的目标</td> <td>组织会议，前后端交接</td> </tr> <tr> <td>四娃</td> <td>用户登陆注册设计</td> <td>完善用户登陆注册功能，为测试人员编写一个测试样例进行说明</td> </tr> <tr> <td>五娃</td> <td>熟悉学习前端框架和代码，从后端转入前端开发</td> <td>完善反馈功能</td> </tr> <tr> <td>六娃</td> <td>暂无测试任务，准备测试环境</td> <td

笨拙软件工程Scrum Meeting博客目录 一、Scrum Meeting 1. Alpha 【Alpha阶段】第一次Scrum Meeting 【Alpha阶段】第二次Scrum Meeting 【Alpha阶段】第三次Scrum Meeting 【Alpha阶段】第四次Scrum Meeting 【Alpha阶段】第五次Scrum Meeting 【Alpha阶段】第六次Scrum Meeting 【Alpha阶段】第七次Scrum Meeting 【Alpha阶段】第八次Scrum Meeting 【Alpha阶段】第九次Scrum Meeting 【Alpha阶段】第十次Scrum Meeting 2. Beta 【Beta阶段】第一次Scrum Meeting 【Beta阶段】第二次Scrum Meeting 【Beta阶段】第三次Scrum Meeting 【Beta阶段】第四次Scrum Meeting 【Beta阶段】第五次Scrum Meeting 【Beta阶段】第六次Scrum Meeting 【Beta阶段】第七次Scrum Meeting 【Beta阶段】第八次Scrum Meeting 【Beta阶段】第九次Scrum Meeting 【Beta阶段】第十次Scrum Meeting 3. Gamma 【Gamma阶段】第一次Scrum

“ 如何用一两句话说清楚敏捷的本质是什么呢？ ” 温馨提示，如果眼睛太累或者在忙其他事，按照这个攻略可以听本文： 看文章很累，不如听吧！手把手教你如何听公众号文章 大家都知道，敏捷虽然是由一群软件开发高人通过《敏捷宣言》提出，但敏捷思想早就已经破 圈 了，甚至成为一种企业管理的思想。 不管你的公司是否从事软件开发，如果你在公司里面每天都开十几分钟的站立会议，或者总是从领导的嘴里听到要快速迭代，又或者一个产品还在创意阶段，负责人总是要求先把最小可用产品做出来，这就说明你和你的团队已经被敏捷思想深深地影响了。 说一千道一万，到底如何用一两句话说清楚敏捷到底是个什么鬼呢？ 我们溯本求源，来看看《敏捷宣言》的创始人是怎么说的。 《程序员修炼之道》被一代代开发者奉为圭臬。时隔20年的新版，经过全面的重新选材、组织和编写，覆盖哲学、方法、工具、设计、解耦、并发、重构、需求、团队等务实话题的最佳实践及重大陷阱，以及易于改造、复用的架构技术。 这本书的书名虽然有“程序员”三个字，但既然敏捷思想已经破圈， 书中 提到的原则也适用于各行各业。 作者大卫·托马斯和安德鲁·亨特，作为《敏捷宣言》17位创始人中的其中2位，也借此书道出了敏捷的两大本质—— 先完成再完美 和 ETC (Easier To Change) 。 01 — 先完成再完美 有一句话贴在Facebook的墙上：“完成大于完美”。 在

写在前言：【版权声明】本作品为作者原创，请勿在未与作者联系的情况下随意盗取、抄录文章；作者水平有限，若阅读时发现错误，欢迎向作者留言提问。在此敬谢全体读者！ 文章目录 程序设计导引 数据结构 程序设计导引概述 程序 算法 高级语言 基本的数据结构 线性结构（1:1）（基本上=>线性表） 线性表（==最常用且最简单的一种数据结构==） 线性表的存储结构（*或称为物理结构*）（数组与链表） ==操作受限的线性表== 栈 队列 ==树形结构==（1：n） ==图形结构==（n:m） 软件过程 程序设计方法 模式化方法 结构化程序设计方法 面向对象程序设计方法 面向过程程序设计方法 软件生命周期（软件过程----软件工程） ==瀑布模型==： 定义阶段 计划 需求分析 开发阶段 设计 编码实现 [^12] 软件测试[^13]： 维护阶段 部署[^14]： 软件维护[^15] 瀑布模型的优缺点 优点 缺点 RUP模型 Scrum模型 ICONIX模型 程序设计导引 数据结构 程序设计导引概述 有几个重要的概念：程序；算法；高级语言 程序 程序 的概念：计算机程序是一组 计算机能识别和执行 的 指令 ，运行于电子计算机上，满足人们某种需求（或为帮助用户解决问题的信息化工具。【程序是一个指令 序列（或可理解为文档集合） 】 程序设计语言 的概念：用于书写计算机程序的语言