敏捷开发

本框架旨在为.NET开发人员提供一个Web后台快速开发框架，采用本框架，能够极大的提高项目开发效率。 整个框架包括三个版本：.net，.net core，java（开发中） 以上三个版本中，.NET为初始版本，开发时间最长，是目前老客户使用的主要产品；.net core为.net的升级版本，为新客户使用及老客户升级的主要产品；.net core能够跨平台，并且涉及Linux、Docker、Nginx、微服务等概念，将是未来的主流。Java是产品线扩充过程中的一个新产品，目前第一阶段开发已完成。 今天我们要介绍的是.net版本，由于.net core版本功能与其一致，不再单独介绍。 框架特点： 1.框架的主架构为基于.net MVC 的 BS 架构。 2.后台 ORM 支持 EF 和 dapper 两种模式。 3.用于实现各类业务系统，如 OA、ERP、MIS、CRM、电商平台等系统的开发。框架本身是一个可二次开发的开发平台，开发者可以根据开发向导进行配置直接生成功能模块；但是他又是一套源代码，开发者也可以直接在 VS 中基于框架开发，甚至还可以对开发框架进行开发扩展。 4.强大的权限管理组件，完成业务功能开发后，系统可以直接使用通用权限来管理业务功能的操作权限及数据权限。 5.集成工作流引擎组件，使业务流程灵活可控。 6.集 BS 开发、微信组件、APP 开发组件于一体。 框架优势

原文地址： https://www.knowledgehut.com/blog/agile/scrum-vs-safe Scrum是基于敏捷的价值观和原则的框架，而SAFe是在企业级别实施Scrum的框架，它们都是基于敏捷价值和原则下的产物。Scrum和SAFe之间的区别是有限的，但也存在着明显的差别。简单来说，Scrum主要基于敏捷的原则和价值观，侧重于少量团队，SAFe是在企业级别的实施敏捷的。 Scrum和SAFe之间的主要差异 让我们看一下Scrum和SAFe之间的主要区别： Sr. No. Scrum SAFe 1. 适用于小型的、阵列的、跨职能的团队 适用于大型的、多区域的团队 2. 它主要被敏捷团队采用 被整个企业采用，而不仅仅是一个团队。(Scrum的扩展) 3. 中层管理人员起不了任何作用 项目群和投资组合层是SAFe的两个重要层次 4. 基本组成部分是Scrum团队. 基本组成部分是敏捷发布火车（ART） 5. Scrum遗漏了各个基本方面。 整个组织的几乎全部的特性和各个方面通过SAFe都可以被管理。 Scrum是管理软件开发的敏捷方法，而SAFe是企业级敏捷的建立方法。 两者之间的主要区别取决于他们选择处理工作的方式。简而言之，Scrum基本上用于组织小型团队，而SAFe用于组织整个大型团队甚至企业。此外， SAFe填补了Scrum在各个重要方面的空缺。

简介 Learun快速开发平台 ，是一个以模块化为核心的快速开发平台，是一个集PC和APP快速开发、系统管理、任务监控、开发工具、可视化数据源管理与数据构建、API动态生成与统计、工作流、可视化表单设计、小程序等全方位功能于一体的高效、稳定的快速开发平台。 平台采用Jquery、Bootstrap、Dapper ORM、jquery mobile、vue.js、uni-app等核心技术。 功能特色 1. 模块化 丰富的模块稳定的框架后台极易上手 目前已包括敏捷开发、系统管理、单位组织、自定义流程、移动管理、报表系统、工作流引擎、开发工具等模块。 2. 快速开发 强大的代码生成器与代码模板一步到位创表、代码生成即刻开发，可视化配置与自定义接口分秒接入，权限控制、统计报表等一个都不能少。 3. 工作流引擎 像“乐高”一样做开发，严谨的工作流开发流程，拖拽式设计表单，可视化流程开发直观展示管理流程，所见即所得；还有企业级专业流程引擎等您咨询。 4. 可视化开发 整个平台贯彻可视化开发原则，平台首页任意模块都可以手动编辑，可视化报表开发更是简单，平台内部选好模板和布局，连接好数据库，做好SQL就行了。 5. 跨多端开发 Learun是PC和APP一体化开发平台，而APP有安卓、iOS、H5的区别，各大平台又有各自的小程序系统，learunAPP基于uni-app框架，一套代码可运行所有平台

什么是质量内建 随着时间的推移，我们项目的开发效率会逐渐降低，直到几年之后整个项目可能就无法维护，只能推倒重来。具体的表现首先就是随着时间推移，我们会发现整个需求列表里面能做的需求越来越少，因为每当我们增加一个新特性，需要改动的代码就非常多，所以最后每提出一个新的需求，团队评估出来的改动成本都非常高，导致最后难以增加新的特性。 第二个表现就是缺陷难以修复。我们做出来的系统只要有人用就会有反馈一些线上的故障，一开始代码很简单的时候修复起来是很快的，但是随着代码越来越复杂、代码行数越来越多，我们会发现定位问题太难了。尤其是现在我们的项目采用的是非常复杂的架构，所以当用户线上报错的时候，我们很难去定位到是哪里出了问题。但其实只要定位到了问题，修复起来是很快的。 第三个表现我们称之为“打地鼠现象”，简单来说就是当你“按”下一个缺陷的时候，又会蹦出来几个新的缺陷。这样会导致大家在工作的过程中压力非常大、心情也会比较沉重。 所以对于这些挑战，我们也有想办法去解决，CI、CD 以及 DevOps 的出现都让我们看到了很好的方向。但是我看到很多团队其实只是靠 DevOps 解决了一些基本的问题，并没有解决核心的问题。这是为什么呢？因为核心问题主要是靠开发人员的能力提升来解决的，但由于改变一个人是很难的，所以企业往往会绕开这些问题。所以我今天分享的内容主要会涉及到开发人员如何去写代码等一些实践。

项目 内容 这个作业属于哪个课程 2020春季计算机学院软件工程(罗杰 任健) 这个作业的要求在哪里 提问回顾与个人总结 第一次作业的链接 个人博客作业(1) 对第一次作业中提出的问题的回答 1. 单元测试要由最熟悉代码的作者来写吗？ 经过这几次作业，包括个人作业，结对项目和团队项目，虽然团队项目部分我没有负责单元测试，但是个人项目和结对项目的测试部分的经验，实际上单元测试不一定是要代码的作者来写。确实作者对代码最熟悉，写单元测试能检测功能，但是有个重要的问题在于作者设想的功能和题目、项目要求的功能不一定符合，作者写的单元测试能保证代码是否满足作者所设想的功能，但是作者不能保证其所设想的功能能够满足项目或者题目的要求。同时，作者的功能构思时候的局限性依然会反应到单元测试上，构思功能的时候忽略掉的边界条件之类的问题，除非构思测试的时候突然想到，不然还是很难通过单元测试反应出来。当然，作者设想的功能和需求的功能的符合程度，与作者自身的能力和项目管理以及人员之间交流有很大的关系，但是从实际效果的角度上，单元测试的目的是检验代码功能是否满足项目的需求。因此我认为单元测试的最佳人选是对单元功能的需求最了解的人，比如pm和负责测试的人员，当然如果对任务进行拆分的是代码作者，这部分的测试还是要代码作者来进行。总体上，负责测试的人员是保证从分配的任务的角度上保证代码功能的正确性

您的组织是否在实践或规模化企业敏捷性？敏捷状态报告提供了世界上最全面的数据，用于基准化您的敏捷实践并计划下一轮扩展。 第14份年度敏捷状态报告基于全球1,100名IT和业务专业人员的经验。自成立以来，全球40,000名敏捷高管、从业人员和顾问分享了他们的见解，使敏捷状态报告成为同类报告中规模最大、运行时间最长的报告。继续阅读今年研究的一些关键发现。 文化仍然很重要 采用敏捷和扩展（规模化）敏捷的最高挑战仍然与组织文化有关。总体上组织对变革的抵制，管理支持和赞助不足以及与敏捷价值观不符的组织文化仍然是前五项挑战。今年，领导层参与不足的新选择也位列前五名。 分布式敏捷团队 - 新常态 尽管面对面的工作对于敏捷实践来说是理想的，但受访者表示组织正在支持分布式团队。由于越来越多的受访者表示他们的组织继续支持和鼓励跨地理边界和跨时区的团队合作，因此没有迹象表明共处一地的趋势有所增加。当前的全球健康危机可能也是一个转折点，这导致分布式团队的增加是"新常态"。 SAFe®是首选的规模化框架 规模化敏捷框架（SAFe®）仍然是受访者引用的最受欢迎的方法（并不是Bob喜欢的方法），比去年增长了5％，超过第二选择 Scrum@Scale 达到了19％。 "我们为SAFe®继续成为市场上最流行，最有效的方法而感到自豪。自Scaled Agile诞生以来，我们的核心信念一直很简单

近期因为疫情的影响，不少互联网公司开始尝试远程工作。也出不了少如何做好远程工作的方法，我认为不管是场地办公还是远程办公都依赖于原来的产品开发流程。 我曾经遵循CMMI5的流程管理过15人左右的跨国/语言/文化团队，也遵循敏捷Scrum管理过9人的小团队，还针对一个从4人发展到近30人的团队尝试过各种方式的项目管理方法，这其中有2C和2B的产品，也有平台/生态型产品。 最后在自己创立公司的5人小团队（场地和远程办公融合方式）中摸索出了我认为最适合中小企业产品开发流程与管理方法。 今天我们聊聊产品开发流程与管理。我们通过对Scrum的改造，利用Gitlab的issue对需求、开发和测试进行可视化管理。应该来说能够适应绝大多数的中小企业和团队，当然再好的流程也会因不同的人来落地执行而产生不一样的效果。 定义产品 首先我们要确定开发的是产品，而非项目。产品和项目的区别是什么？与此对应的另外一个问题是产品经理和项目经理的区别是什么？ 后面的问题我们不在此篇中讨论，产品和项目的区别主要在两方面体现：生存周期和目标。 项目的生存周期比较短从启动、策划、执行、监控到收尾。验收交付给用户之后项目就结束了。而产品不存在结束的说法，因为产品是不断更新的，直到被新产品替代，生存周期才结束。 项目的目标是在规定的时间内，利用有限的资源，高质量的完成某个特定用户的需求。而产品更多是为了满足一些用户的通过用需求

简介 Learun快速开发平台 ，是一个以模块化为核心的快速开发平台，是一个集PC和APP快速开发、系统管理、任务监控、开发工具、可视化数据源管理与数据构建、API动态生成与统计、工作流、可视化表单设计、小程序等全方位功能于一体的高效、稳定的快速开发平台。 平台采用Jquery、Bootstrap、Dapper ORM、jquery mobile、vue.js、uni-app等核心技术。 功能特色 1. 模块化 丰富的模块稳定的框架后台极易上手 目前已包括敏捷开发、系统管理、单位组织、自定义流程、移动管理、报表系统、工作流引擎、开发工具等模块。 2. 快速开发 强大的代码生成器与代码模板一步到位创表、代码生成即刻开发，可视化配置与自定义接口分秒接入，权限控制、统计报表等一个都不能少。 3. 工作流引擎 像“乐高”一样做开发，严谨的工作流开发流程，拖拽式设计表单，可视化流程开发直观展示管理流程，所见即所得；还有企业级专业流程引擎等您咨询。 4. 可视化开发 整个平台贯彻可视化开发原则，平台首页任意模块都可以手动编辑，可视化报表开发更是简单，平台内部选好模板和布局，连接好数据库，做好SQL就行了。 5. 跨多端开发 Learun是PC和APP一体化开发平台，而APP有安卓、iOS、H5的区别，各大平台又有各自的小程序系统，learunAPP基于uni-app框架，一套代码可运行所有平台

微服务 微服务的由来 微服务的使用场景 微服务相较于单体架构的优点 微服务的本质 微服务的应用 微服务开发框架 微服务的由来 微服务最早由 Martin Fowler与James Lewis于2014年 共同提出，微服务架构风格是一种使用 一套小服务来开发单个应用 的方式途径， 每个服务运行在自己的进程中 ，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。 微服务的使用场景 在传统的IT行业软件大多都是各种独立系统，他们的缺点就 是扩展性差，可靠性不高，维护成本高 。所以目前大部分公司都使用微服务进行开发。 微服务相较于单体架构的优点 （1） 单体架构所有的模块全都耦合在一块，代码量大，维护困难。 微服务每个模块就相当于一个单独的项目， 代码量明显减少，遇到问题也相对来说比较好解决。 （2） 单体架构所有的模块都共用一个数据库，存储方式比较单一。 微服务每个模块都 可以使用不同的存储方式 （比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。 （3） 单体架构所有的模块开发所使用的技术一样。 （比如用的开发语言是Java，就得整篇是Java，但是微服务不同，他可以多个服务使用不同的语言） 微服务每个模块都可以使用

7分钟揭晓Scrum的秘密（Scrum框架） 什么是Scrum Scrum 是用于开发和持续支持复杂产品的一个框架。其中包括 Scrum 的角色、事件、工件，以及把它们组织在一起的规则... Scrum (名词): Scrum 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付尽可能高价值的产品。 Scrum 是: 轻量级的 易于理解的 难以精通的 Scrum 是一个过程框架，自上世纪 90 年代初以来，它就已经被应用于管理复杂产品的开发上。Scrum并不是构建产品的一种过程或一项技术，倒不如说，它是一个框架， 在此框架 中您可以使用各种不同的过程和技术。Scrum 让您的产品管理和开发实践的相对成效更加清楚地显现出来，因此您可以去改进它们。 -- Scrum指南 从 Scrum指南 中我们可以快速总结如下： Scrum是一个过程框架 Scrum框架用于开发复杂产品 Scrum框架帮助人们解决复杂的自适应难题 Scrum能帮助人们高效交付尽可能高价值产品 Scrum框架中可以使用各种不同的过程和技术 因此，Ken Schwaber 曾经说过： Scrum 就像你的丈母娘，不断的指出你的问题。 由此也不难看出，Scrum框架的核心在于不断暴露问题。即它是一个暴露问题的反馈框架。 下面我们来看看Scrum框架中具体包含什么内容。 Scrum 框架