项目

20人开发2个月上线效率晋升 8 倍  图片来源于：PXhere 01互联网+时代下，家电企业的新挑战数字化转型是企业迅猛发展的重要撑持。随着新批发业务的疾速倒退，用户基数规模不断扩大，已高达百万级用户量，须要更弱小的新技术、新零碎架构来反对这百亿级数据。 如何将企业简单且宏大的用户数据进行整合并治理，如何打消信息孤岛，进步日常办公、业务经营的效率，成为“互联网+”时代下，家电企业的新挑战。 此次，飞速低代码平台助力国内龙头电器新批发企业通过可视化开发、微服务架构（松耦合）、分布式容器化部署等新技术架构重构老零碎。 （图片来源于：网络） 02七大支流新技术，重构售后老零碎飞速低代码平台，制订一套无效解决方案： 应用七大支流技术  （图片来源于：飞速低代码） 新技术架构 （图片来源于：飞速低代码） 1.分期建设 松耦合构造，能够优先实现紧急业务场景并上线应用，前期逐渐建设和关联成利用集群。 2.应用不同数据结构 每个微服务对应的数据库和数据结构能够是不同类型的，后盾数据隔离进步安全性。 3.程度扩大 分布式部署能够依据业务需要程度扩大，容器化部署也利用扩容和缩容。 4.数据互通 微服务架构和前台、中台、后盾的架构利于数据互联互通、新旧系统集成。 5.秒级响应 ES宽表构造的实时数仓和实时计算进步零碎的响应能力，十亿量数据秒级响应。 6.复用能力 多个前端能够复用后端，中台集中了可复用的能力供前端业务疾速翻新，提高效率。 03新批发零碎，重构后的成果  售后中台为多个前台提供IT共享服务 通过微服务架构将外围能力建设成能够面向不同渠道和场景的可复用的微服务应用层和数据服务平台，微服务能够向前端、第三方和其余中台提供API服务，无效对后盾的数据进行安全性隔离，实现通用能力和外围能力复用，为多个前台提供共享服务，反对前台业务疾速翻新。 （图片来源于：网络）  低代码可视化开发劣势  新零碎基于可视化平台迅速开发已有零碎间接口微服务化，连通信息孤岛和烟囱已有数据资产接入微服务，IT价值最大化已有零碎容器化治理，升高运维经营老本在建零碎微服务降级，技术架构低成本疾速革新1.我的项目开发 可视化利落拽构建页面，进步页面的好看度，1000+表构造导入建模平台，造成API接口。 2.一键部署 平台反对公布流水线，一键部署，自动化运维。 分布式容器化部署 ▲（图片来源于：飞速创软） 云端部署架构 ▲（图片来源于：飞速创软） 新批发零碎 重构后的八大能力 原生云技术架构自适应多终端架构数据架构与剖析自主可控平安平台可拓展的集成平台自动化运维平台微服务框架微服务市场及治理04引入飞速低代码，效率晋升近8倍国内龙头电器新批发企业引入飞速低代码平台，帮忙零碎重构和降级，2个月后零碎首次实现开发上线；后与飞速持续以协同开发的形式疾速实现系统核心能力和性能更新及新的性能的需要开发、降级、迭代；新零碎功能齐全、体验晋升，运维同时独立欠缺零碎性能； 企业利用飞速低代码平台的优越性安稳运维并一直进行数字化降级和拓展。 新批发售后零碎20人开发，2个月即重构结束线上应用，开发和迭代零碎及运维，效率进步了近8倍。（图片来源于：网络） 挪动信息化的时代，每个行业甚至每个企业都在面临着瞬息万变的信息冲击，成倍地排汇突飞猛进的信息改革。 这是一个以快取胜的时代，疾速倒退、高效运作成为每个企业不可或缺的一个外围。低代码的崛起，是快节奏、高需要时代必然的趋势。 飞速创软专一于云原生全场景低代码及数字基础设施，公司研发团队深入研究和实际面向对象业务建模、前后端拆散开发技术、云原生、微服务框架等，具备软件开发全生命周期平台产品；帮忙腾多行业多畛域大机构胜利实现数字化转型和降级。

PMBOK指南700多页学到吐血！ 齐全不想看，但又想通过考试...... 我该怎么办？？？ 你理解PMP项目管理中考试的重要知识点吗？ 晓得某些计算题你须要记忆这么公式或者数值吗？ 在项目管理中，谁次要负责什么呢？看到某些词又如何疾速锁定答案呢？ 明天小编给大家整顿了项目管理考试必备的锦囊知识点合集：点击卡片可取得Word版，打印下来记忆快准狠。 点击下载 --------知识点注释------- 一、须要记忆的公式1）三点估算：期望值、标准差、方差 ；2）要害门路计算：ES、EF、LS、LF、总浮动工夫、自在浮动工夫 ；3）挣值计算：CPI、SPI、ETC、EAC、TCPI ；4）决策树模型计算 ；5）沟通渠道计算 ；6）合同计算：CPPC、CPFF、CPIF、FPIF 。 二、须要记忆的数值1）三点估算概率：68.26%、95.46%、99.73% ；2）WBS：4-6层，80小时 ；3）品质老本：85%由管理层负责 ；4）管制图：7点规定 ；5）应急储备：10% ；6）沟通：项目经理占75%-90%工夫，55%通过非语言传递信息 。 三、谁次要负责什么1）谁负责制订我的项目打算?---(由我的项目团队制订，项目经理进行综合集成) ；2）谁是我的项目可交付成绩的次要负责人?---(我的项目团队成员或集体) ；3）谁负责批准/回绝变更申请,决定基准变更?变更管制委员会---(CCB) ；4）谁负责我的项目章程的批准?---（我的项目以外的,级别与我的项目须要相称的发起人）； 5）谁负责核准我的项目范畴?所有的要害的我的项目干系人---(发起人/客户/顾客等) ；6）谁负责确定我的项目老本偏差可承受的范畴?---(项目经理) ；7）谁负责设计与标准的根本责任?---(我的项目工程师) ；8）谁负责承当项目风险及项目管理中的次要危险?---(我的项目发起人) ；9）谁对我的项目的危险负责?---(项目经理) ；10）谁对我的项目施行中各项流动的品质一致性负责?---(品质经理) ；11）谁负责促使合同合乎我的项目的具体要求?---(项目管理团队) ；12）谁负责施行品质管制?---(由机构中的品质管制部门或名称类似的部门组织) ；13）谁负责辨认缺点并举荐缺点补救?---(品质管制部门或相似部门进行解决) ；14）谁负责利害关系者的治理?---(项目经理) ；15）谁负责做出申请和减少我的项目资源的决策?---(项目经理) ；16）谁负责品质和等级的确定及交付?---(项目经理和项目管理团队) ；17）在我的项目品质管制中,谁负责采取纠正措施?---(公司里每一位职员) ；18）谁负责我的项目团队的绩效评估?---(项目管理团队) ；19）谁对我的项目中部门的危险负责?---(职能经理) ；20）谁负责施行质量保证?---(全员参加，质量保证部或组织中与此名称类似的单位提供监督) ；21）我的项目品质治理的最终责任由谁来承当?---(项目经理) ；22）差错修复审核通常由谁施行?---(我的项目管制部门) ；23）谁负责将合同收尾的正式告诉提供给卖方? ---(合同治理负责人/合同管理员) ；24）谁负责流动定义? ---(负责工作包的集体或个体) ；25）谁负责流动持续时间估算?--- (我的项目团队最相熟具体打算流动工作内容性质的集体或个体) ；26）谁制订WBS? ---(我的项目团队) 。 四、看到什么选什么1）看到“限值”选管制图 ；2）干系人出问题，选治理干系人冀望 ；3）信息出问题，选沟通治理打算或布局沟通或沟通需要剖析 ；4）看到变更题目，抉择：最合乎流程的 ；5）回避针对危险事件，回避扭转打算;加重针对危险概率和影响 ；6）开辟——分派最有能力资源，缩短工夫和节约老本;进步——减少资源，缩短工夫。；7）看到我的项目收尾，找：可交付成绩的验收/总结经验教训 ；8）看到新任项目经理找：章程联盟 ；9）看到打算或章程实现了，找：批准 ；10）看到复原进度找：进度压缩，假如情景剖析，调整工夫提前量和滞后量 ；11）看到资源有余找：资源均衡或要害链 ；12）看到要执行危险应答措施找：变更申请 ；13）看到最佳会谈：踊跃聆听 ；14）看到危险出问题了：更新危险登记册 。

如果一个Web应用程序的目录和文件十分多，那么将这个Web应用程序部署到另一台机器上，就不是很不便了，咱们能够将Web应用程序打包成Web 归档(WAR)文件，这个过程和把Java类文件打包成JAR文件的过程相似。利用WAR文件，能够把Servlet类文件和相干的资源集中在一起进行公布。在这个过程中，Web应用程序就不是依照目录层次结构来进行部署了，而是把WAR文件作为部署单元来应用。 一个WAR文件就是一个Web应用程序，建设WAR文件，就是把整个Web应用程序(不包含Web应用程序层次结构的根目录)压缩起来，指定一个.war扩展名。上面咱们将第2章的Web应用程序打包成WAR文件，而后公布 要留神的是，尽管WAR文件和JAR文件的文件格式是一样的，并且都是应用jar命令来创立，但就其利用来说，WAR文件和JAR文件是有基本区别的。JAR文件的目标是把类和相干的资源封装到压缩的归档文件中，而对于WAR文件来说，一个WAR文件代表了一个Web应用程序，它能够蕴含 Servlet、HTML页面、Java类、图像文件，以及组成Web应用程序的其余资源，而不仅仅是类的归档文件。 咱们什么时候应该应用WAR文件呢？在开发阶段不适宜应用WAR文件，因为在开发阶段，常常须要增加或删除Web应用程序的内容，更新 Servlet类文件，而每一次改变后，从新建设WAR文件将是一件浪费时间的事件。在产品公布阶段，应用WAR文件是比拟适合的，因为在这个时候，简直不须要再做什么改变了。 在开发阶段，咱们通常将Servlet源文件放到Web应用程序目录的src子目录下，以便和Web资源文件辨别。在建设WAR文件时，只须要将src目录从Web应用程序目录中移走，就能够打包了————————————————版权申明：本文为CSDN博主「贺志武」的原创文章，遵循CC 4.0 BY-SA版权协定，转载请附上原文出处链接及本申明。原文链接：https://blog.csdn.net/weixin_...

2021 年 01 月 20 日，编程导航正式上线，做最业余灵便的编程导航站，助您轻松发现优质编程资源！ 编程导航不仅仅是一个我的项目，而是以 “帮忙大家发现优质编程资源，晋升效率” 为指标的残缺生态。目前已上线两个产品： 编程导航主站 - 发现优质编程资源 网址：https://www.code-nav.cn 编程导航主页 - 程序员必备主页 网址：https://home.code-nav.cn 为什么须要编程导航？总是有很多学编程的敌人问 “有没有学 xx 的资源”、“我须要 xx 资源，能发我一份么”。 在反复接管相似讯息后，我陷入沉思。 现在编程资源获取的大环境雾气重重，有很多不太好的景象： 很多徒有虚名的编程资源被捧上了天，名人效应、一叶障目好的编程资源被商业利益化，很多人利用信息差，将原本收费的资源进行贩卖好的编程资源因为作者不闻名，没有被人发现网上的编程资源十分零散，真实性、有效性很不确定意识到这些问题后，作为一个开发者，我能够做些什么？ 持续去网上搜好的资源，而后传到网盘上，分享给大家？ 一个人的力量终归渺小，好的编程资源环境须要大家的共同努力。 这是『 编程导航 』问世的起因：提供人人皆可举荐的编程资源导航平台，帮忙大家发现优质编程资源。 QA 问答Q：编程类导航网站都烂大巷了，为什么还要做导航？A：大多数编程导航网年久失修，也有不错的导航，然而在搜寻、归类上比拟局限，而且没有自主举荐、喜爱等性能，不具备可继续发展性。 Q：资源太多的话，会不会同样让人目迷五色，不晓得看哪个？A：当初编程资源十分多，必定会呈现这种状况，这也是咱们做 零碎 而不是整顿文档的起因。能够通过评分、评论、排序、举荐等形式缓解，大家感觉好的资源才会有更多被发现的机会！ 编程导航主站发现优质编程学习资源。 能够检索本人须要的资源、分享好的资源，并对别人举荐的资源进行评估。好的资源会被更多人发现，让更多同学感触到技术带来的美妙。 我的项目展现举荐资源 资源大全 收藏夹 资源详情 评论区 编程导航主页极简炫酷的浏览器主页，反对万能搜寻，晋升效率，还能够定制壁纸和主页站点。 我的项目展现通明主页 白底主页 万能搜寻 万能搜寻后果页 切换壁纸 随机壁纸 动静壁纸 最初整个编程导航体系的所有零碎，全副开放源码 给大家学习，应用这套代码，你也能轻松开发多端适配网站，搭建属于本人的炫酷主页！ 如果感觉不错的话，分享给身边须要的敌人吧，这将成为咱们不断改进的能源！❤️ 我的项目详情及源码地址：https://github.com/liyupi/code-nav ...

拜访页面时报错错误代码：404 错误代码：500

摘要：你感觉需要条目化怎么样？已经，大略在2010年之后的几年里，麻利在国内变得越来越广为人知，作为重要的麻利需要实际，用户故事简直成为了标配。但实践者们对于它，却始终都有着十分多的疑难和困惑，尤其是用户故事和用例的争议，贯通了国内简直整个倒退历程。尽管在我看来它们的关系很好了解、很简略，Craig Larman在他的工作坊外面讲得蛮分明的，也是我集体比拟认可的观点。 简略来说，就是如下这个用户故事实际，的确好用，实践者往往也很容易就能喜爱上它，尽管实际起来往往都偏离得比拟厉害，首当其冲的就是极少有人会真的严格遵循它的三段式去表述。 其次，当然就是在较大规模组织外面施行麻利的实践者都会产生的困惑，故事数量多了，该怎么治理？曾经实现的故事，怎么解决？跨团队的故事应该怎么解决？ 实践者们解决这些问题的办法，次要是用户故事地图（User Story Mapping）和影响地图（Impact Mapping），对于这两个实际，大家能够参考此创始者Jeff Patton、Gojko Adzic各自所著的同名书籍。用户故事地图解决了大故事到小故事的关系问题，以及故事公布排期的问题；影响地图则侧重于思考解决从业务指标到用户行为到零碎性能的关联问题。 惋惜的是，即使把这两个实际都用上，也还存在着没有齐全解决的问题。 在上家企业工作期间，给一个银行研发核心做过挺长时间的麻利转型服务，刚进到我的项目不久，对方就问了我一个问题：“你感觉需要条目化怎么样？”。那是我第一次据说“需要条目化”这个词，但我感觉这名字蛮有意思，挺好的。过后也感觉能连续客户自身的实际和术语概念有助于实际落地，于是我就把用户故事、故事地图、影响地图、UML局部图表、ATDD等大量麻利实际揉在一起，以及价值主张、设计思维等实际，作为“需要条目化”这个名字背地的操作外延。从我的角度来看，这些实际的揉合就是让需要条目化从定义变成可操作性定义（出自戴明，Operational Definition）的要害。 为什么忽然提到需要条目化？ 因为它是我心目中让用户故事变得更无效、更落地的一种套路。 首先，需要条目化的需要构造如下： 咱们能够认为它大抵上能够对应到Epic、Feature、Story，但本质上，这三个级别是性质上的不同，而不是EFS那样次要是需要规模大小的不同。需要概念位于问题域，廓清要解决的业务问题，比方为什么要启动这个我的项目？为什么要开发这个新版本？条目则位于计划域，尽管对于研发部门/团队来说，很容易把条目等同于零碎性能，但实际上，是齐全有可能而且是相对存在不实现任何性能也能够解决问题的计划的。子条目位于实现域，次要是用来解决研发团队之间分工协作的问题，比方不同模块之间或前后台之间，对于较小型的团队，没有简单的分工，那很有可能就不须要应用子条目。再往下，团队外部能够再拆分为具体的工作工作，解决外部团队成员之间的分工协作问题。 需要概念、条目、子条目，这三个级别，每个级别都是用户故事，都要以用户故事的品质要求看待，也即3C准则和INVEST准则。它们都要制订验收规范，而后细化出测试用例、实现测试自动化（我集体保持100%）、ATDD。对于验收规范和测试用例的关系，能够看看这篇文章里我跟吕毅老师的不同观点：《实例、接管规范和接管测试》。 具体来说这三个级别能够是什么呢？ 概念：市场热点、用户痛点、竞品参考等条目：端到端需要，具备终端用户应用价值的性能个性子条目：比拟小的端到端需要，或是因应组织现状而将端到端需要拆分到不同架构层级、模块或不同部门团队的技术型需要，例如某个端到端个性的前端出现和后盾解决性能值得注意的是，这三个级别需要的廓清，并不谋求要全副拆分分明、列举结束才开始下一步具体的研发工作，而是采取边廓清边研发的滚动刷新模式。当然这是有前提的，要产生好的实效，这个前提必须做到，就是要有好的能够录入并继续刷新保护三级需要构造的工具，简略来讲就是麻利需要工具。 廓清需要后，就是对应地纳入各级打算，此处也假如采取的是麻利布局模式。严格来说是以麻利布局模式为前提，传统模式通常都要求晚期廓清所有或绝大部分需要能力启动研发，麻利布局模式则强调逐步细化、增量布局，这些主张跟需要条目化一模一样。 依照工夫程序来讲，大抵过程如下。 确定我的项目/版本的外围指标并进行优先级排序，剔除低优先级、鸡肋型指标，我集体认为不论我的项目大小、人员多少，都应该聚焦到1-3个外围指标。人多、我的项目大，那需要概念就大；人少、我的项目小，那需要概念就大。但不管怎样，再顺着三级构造拆解，至多到子条目都可能成为满足团队迭代排期的颗粒度。 而后呢，就是画场景图，要从用户角度画。用户角度、用户角度、用户角度！用户≠客户、用户≠客户、用户≠客户！用户是厂商所提供服务、产品或性能的理论使用者。场景图也不难，就是理分明用户和厂商之间的交互过程和触点，比方，应该是用户和华为之间的交互，而不是用户和华为某个网站或某个零碎之间的交互。这些交互过程和触点的组合，就是条目，也略等于当初的JTBD这个术语的意思。 把场景图外面的厂商局部，再依照零碎架构层级或者服务层级或者模块拆分成不同的泳道，将场景图中厂商局部的触点细化为外部不同零碎、模块或团队的交互过程，变成子条目。 需要条目化的实际对于工具的要求是很高的，至多我心目中100分规范对工具是有很高要求的。比方下面的整个过程，外围关键在于有一个系统维护着这个三级构造，概念、条目、子条目每一级又能够开展需要详情（比方 Wiki）。需要验收规范拆分进去的测试用例要关联至自动化测试脚本，或者自身就是可执行的，最好是跟后面的需要关联起来，造成可执行需要。而且整个构造和各节点除了易于浏览的模式，也即Wiki、Word文档或零碎里的表单格局之外，最好还可能以一种纯文本化、代码化的模式存储，能够像代码一样进行版本化治理，并反对工具主动生成残缺的需要文档，需要、测试、代码的任何批改都可能触发整个流水线执行验证，真正成为实例化需要所主张的活文档（Living Documentation）。 本文分享自华为云社区《用户故事不是银弹》，原文作者：kaverjody。 点击关注，第一工夫理解华为云陈腐技术~

明天的知识点 (2020.12.05) —— 第599天 (我也要出题)[html] HTML5拖拽事件的程序是什么？[css] 怎么在@keyframes中应用CSS变量[js] 请解释下为什么上面第一种形式会报错而第二种不会？[软技能] 你本人做过哪些残缺我的项目，说说看《论语》，曾子曰：“吾日三省吾身”（我每天屡次检查本人）。前端面试每日3+1题，以面试题来驱动学习，每天提高一点！让致力成为一种习惯，让奋斗成为一种享受！置信 保持 的力量！！！欢送在 Issues 和敌人们一起探讨学习！ 我的项目地址：前端面试每日3+1【举荐】欢送跟 jsliang 一起折腾前端，零碎整顿前端常识，目前正在折腾 LeetCode，打算买通算法与数据结构的任督二脉。GitHub 地址 微信公众号欢送大家前来探讨，如果感觉对你的学习有肯定的帮忙，欢送点个Star, 同时欢送微信扫码关注 前端剑解 公众号，并退出 “前端学习每日3+1” 微信群互相交换（点击公众号的菜单：交换）。 学习不打烊，充电加油只为遇到更好的本人，365天无节假日，每天早上5点纯手工公布面试题（死磕本人，愉悦大家）。心愿大家在这虚夸的前端圈里，放弃沉着，保持每天花20分钟来学习与思考。在这变幻无穷，类库层出不穷的前端，倡议大家不要等到找工作时，才狂刷题，提倡每日学习！（不忘初心，html、css、javascript才是基石！）欢送大家到Issues交换，激励PR，感激Star，大家有啥好的倡议能够加我微信一起交换探讨！心愿大家每日去学习与思考，这才达到来这里的目标！！！（不要为了谁而来，要为本人而来！）交换探讨欢送大家前来探讨，如果感觉对你的学习有肯定的帮忙，欢送点个[Star]

➢ 假日狂魔去年春节前， 一不小心就聊到了过年的安排。 同事说打算在星巴克闭关， 好好深入下技术相关的内容。 也就意味着过年， 大概有十天半个月的时间沉浸在学习中。 后来，不知道他是不是真的， 选择了与书相伴，没有回家。 忘了是出于什么原因， 我也曾在去年的五一和国庆节奋斗过。 一个整整7天，一个整整10天。 除了看课程，就是在写代码。 甚至于残忍到像这种2,3天的小长假， 我都没放过。 ➢ 一个小长假节假日的意义很多， 但是最重要的有两个。 一个是和家里人一起聚聚， 一个是去外面的世界走走。 过几天就是端午节了， 是不是已经想好了怎么安排？ ➢ 上线定律没关系，如果你还没安排好， 你的老板也已经替你安排好了。 放假，不存在的。 一到节日就上线，加班加点撸起键盘开干吧。 如果节日前能够顺利上线，恭喜你。 节假日的24小时*3每分每秒你都可能被召唤。 如果节日前不能够顺利上线，还是恭喜。 妥妥的通宵和节日都加班，好好写，不要停。 ➢ 加班余额讲道理， 加班的另一个意义不是调休吗？ 上班的核心意义不就是赚钱吗？ 放假的意义不就是回家和休息吗？ 钱没赚到， 加班的时长到是比卡里的余额还多好几个0 ➢程序员的世界现在的程序员早已不是性格木讷， 不善言辞，没有社交了。 反而是上班撩妹，下班吃鸡， 明里暗里还在努力搞学习的那种。 也许有过我和同事类似体验的同学不多， 理由也各不相同。 愿大家的小长假能够如期释放， 至少，拥有了选择的权利。

工作中经常会遇到一些版本兼容问题，从而需要对某一特定版本或者此版本上下版本进行筛选，这里我们以4位版本为例，写一个简易的版本对比算法。 例如： 需比对的版本，version = '1.16.1.0' 参考版本：current = '1.5.2.2' /* 方法说明 * _numberFormater 数字格式化，不足前面补0 * param {string，number} number 需要格式化的数据 * param {number} n 格式化的长度 * return {string} 返回格式化后的数据*/const _numberFormater = (number, n) => { number = `0000000000000000${number}` return number.substring(number.length - n)}/* 方法说明 * checkVersion 版本号比对 * param {string} version 需比对的版本 * param {string} current 参照版本 * return {number} 0：相等 1：大于 -1：小于*/const checkVersion = (version, current) => { if (!version || !current) { return false } version = version.split('.') current = current.split('.') const length = current.length // 每位转为000格式 权值依次减少 1000 100 10 1 for (let i = 0; i < length; i++) { version[i] = _numberFormater(version[i], length) current[i] = _numberFormater(current[i], length) } const versionNumner = +version[0] * 1000 + +version[1] * 100 + +version[2] * 10 + +version[3] * 1 const currentNumner = +current[0] * 1000 + +current[1] * 100 + +current[2] * 10 + +current[3] * 1 if (versionNumner > currentNumner) { return 1 } else if (versionNumner === currentNumner) { return 0 } else { return -1 }}使用 ...

项目描述保险公司对个人投保时或根据历史数据生成的模型来计算个人保费，那么本次我们就以这个模型的求解过程为例来实践下多元线性回归。2 数据与简单分析数据集下载数据信息如下图所示:我们已经获取到保险公司部分数据，文件名为insurance.csv，文件内容如下。我们可以看出数据中共有六个维度：age（年龄）,sex（性别）,bmi（肥胖指数）,children（孩子数量）,smoker（是否吸烟）,region（居住地）。charges则是当前数据人上年度在保险的额度。所以我们可以构建一个六维高维空间来求解这个模型。相对于年龄来说， 年龄越大， 购买保险的金额应该越大；相对于性别来说，整体女性的寿命大于男性寿命大约10年， 因此男性的保险额度应该更大。相对于肥胖指数来说， 肥胖指数越小， 身体状况越不好， 购买保险的金额应该越大；相对于孩子的数量来说， 孩子的数量越多， 压力越大， 越劳累， 购买保险的金额应该越大；相对于是否吸烟来说， 吸烟的人寿命远少于不吸烟的寿命， 因此 购买保险的金额应该越大；相对于地区来说， 地区环境越差， 有雾霾， 则越容易生病， 那么购买保险的金额应该越大；最后说明一下，本章中的数据来源主要是来自某保险公司内部的真实历史数据。3 项目实践完成本项目后，您将知道：如何从训练数据中估计统计量。如何从数据估计线性回归系数。如何使用线性回归预测新数据。import pandas as pdimport numpy as npimport matplotlib.pyplot as pltfrom sklearn.preprocessing import PolynomialFeaturesfrom sklearn.linear_model import LinearRegression# 1). 读取csv文件数据;filename = ‘data/insurance.csv’data = pd.read_csv(filename)# 2). 清洗数据reg = LinearRegression()x = data[[‘age’, ‘sex’, ‘bmi’, ‘children’, ‘smoker’, ‘region’]]y = data[‘charges’]# 转换数据类型为整形x = x.apply(pd.to_numeric, errors=‘corece’)y = y.apply(pd.to_numeric, errors=‘coerce’)# 填充空值x.fillna(0, inplace=True)y.fillna(0, inplace=True)print(x)print(y)# 3). 开始建模# degree： 多项式的阶数，一般默认是2;# interaction_only:如果值为true(默认是false),则会产生相互影响的特征集。# include_bias:是否包含偏差列poly_features = PolynomialFeatures(degree=2, include_bias=False)# 降维X_poly = poly_features.fit_transform(x)# 4). 用线性回归进行拟合reg.fit(X_poly, y)print(reg.coef_)print(reg.intercept_)# 5). 预测y_predict = reg.predict(X_poly)# 5). 真实的y值绘制:图形绘制显示plt.plot(x[‘age’], y, ‘b.’)# 预测的y值绘制plt.plot(X_poly[:, 0], y_predict, ‘r.’)plt.show()预测值与真实值的图像显示:

阿里妹导读：复盘是项目结束后必不可少的阶段，好的复盘会议能够有效地促进团队成长。今天，阿里项目管理专家鹿迦以自身的经验，为大家分享如何做好一个项目的复盘。这篇文章分成两个部分，第一部分简单阐述对这种回顾会议的理解，认识会议的真正价值；第二部分是分享个人操作的团队回顾会议流程。在阿里天猫新零售的天地会项目中，因为我参与的团队是成立不到2个月的feature team，再加上团队成员来自于多个不同的BU（有钉钉的、天猫新零售的、手淘的），团队处在一个快速磨合成长期，在合适的节点上开展一个有效的团队回顾会议（也可以叫做复盘会议）可以对团队成长和进化起到一个非常明显的加速作用。抱着这样的信念，我们上周组织了一个团队回顾会议，基于团队成员的反馈这个会议算是取得了令人满意的结果，大家不仅加深了相互的了解、公开暴露了一些团队中隐藏的问题，更帮助大家对这些问题做了比较深入的探讨和分析，并产出了可落地的行动。一、我理解的团队回顾会议回顾会议（retrospective meeting）是来自敏捷方法scrum，这个会议是Scrum检视与调整的一个重要的环节，在这个会议上，我们鼓励团队对自己的开发过程进行改进，并确定什么样的调整可以使下一迭代的效率更高、结果更令人满意和更易于工作。就像我们频繁的迭代和交付是为了快速地获得外部用户的反馈，进而帮助我们做产品需求的调整一样，每个迭代的回顾会议就是想更快地得到大家对团队工作问题和改进点的反馈，帮助团队内部的工作效能和能力的不断提升。但是开好回顾会议并不简单，甚至我认为回顾会议是团队中最难开好的一个会议，但开好了也是价值最大的一个会议。我们整理了一下，认为这个会议可能达到的五个层次：单向宣讲式的回顾会议：团队管理者事先完成了整个回顾分析，会上只是面向团队成员做一个回顾结论的宣讲和说明。很明显，这种层次的回顾会议不仅很有可能不能发现团队最重要的问题，更不利的是很难让结论取得团队成员发自内心的认同。各自表达式的回顾会议：团队成员没有真的想敞开内心参与回顾会议，往往只是迫于会上的点名而击鼓传花式地各自讲自己的内容和观点，对其他人的观点没有回应，也没有质疑。这是明显的团队成员害怕冲突的表现，团队成员之间没有真正的融合，背后真正的问题可能是没有建立团队成员之间的信任。争论推责式的回顾会议：大家抢着发言，但是气氛紧张，经常有不礼貌地打断他人讲话的情况出现，大家都极力避免责任被认定到自己的头上，往往需要老板在最终的时候决策。定责式的回顾会议是我们需要极力避免的，这个不是我们回顾会议的目标，定责的行动往往会导致大家关闭沟通的门，导致真正的问题被掩盖。发散讨论式的回顾会议：回顾中抛出的问题很多，讨论的的过程中往往还会从一个问题跳跃到其他问题上，导致会议中涉及的论点不断发散，最终往往由于问题过多，没有时间也没办法形成能落地的结论。没有结论的会议，也就没有办法拿到最终的会议价值。聚焦共创式的回顾会议：明确回顾的目标是通过团队共创的方式发现团队持续进化的机会，鼓励大家用坦诚、合作、成长的心态挖掘团队改进的机会，并通过区分优先级以在最有价值的机会点上切实落地改进的行动。这个层次才是我们理想的情况，是我们追求的目标。二、可参考的回顾会议流程我们操作的回顾会议基本流程是参考了《Agile Retrospectives》这本书中所划分的会议5个阶段：准备收集数据产生见解确定改进项结束会议那我就按这几个阶段来讲讲怎么做。2.1 准备准备阶段其实是非常重要的，一些初次主持回顾会议的同学往往会忽视这个阶段，一上来就让大家写小卡片，这样不仅效果不好，次数多了更给人枯燥重复、走形式的感觉。准备阶段我往往会选择做下面几件事：设定一个安全的环境回顾会议不仅仅希望大家能参与进来，更重要的是能敞开心扉，大家没有顾虑地把问题暴露出来，找到改进的办法。但事实是肯定有人担心回顾会议会成为一个批判会议，在认为这个会议的目的是找到这个迭代中犯错的那个人，并把他拎出来痛批一顿，看以后还有谁敢再犯。如果这样大家肯定会有所保留，担心说错话，会议上就找不到真正的问题。一般我们会直接声明这个会议的目的，绝对没有想追究任何人的责任的意思。不仅如此，我们还需要在会议过程中避免讨论任何个人责任的问题。了解与会人的心态这是个很有意思的事情。会议本来就令人沮丧，更何状是回顾会议这种看似是锦上添花的会议。与会者都是带着什么心态来参加的呢？这里有一种非常有意思的收集与会者心态的小活动，叫做“ESVP”：Explorer （探索者）Shopper （推销者）Vacationer （度假者）Prisoner （囚犯）这四个角色代表了四种与会的心态，可以通过与会者不记名的投票（匿名的在贴纸上写上代表自己真实心态的角色首字母），统计完现场公开结果，就能知道会议室里大家的实际心态情况。统计的结果不一定总让人欢欣鼓舞，但这个小小的活动往往能有效的唤起大家内心的思考，帮忙确定会议的基调，很有价值。激活大家的发言欲望事实证明，一个会议上，如果一开始大家就可以不需要发言，只是听，那么很大机会大家在整个会议上都将保持沉默，没有什么想说的，尽管会议中后期你希望更多人参与发言。办法是一开始就破冰。简单常用的方法是让大家按座位顺序轮流用一个词形容他/她对这个迭代的感受。只让用一个词说实话非常难，不过没关系，这个时候大家就会开始脑子飞快的转起来了，到底哪个词比较合适。这样不仅把大家带到了回顾的思路里，更重要的是大家一开始就有机会开口表达自己的想法了。把大家带到这个迭代历史的回忆中来在开始收集数据之前，让大家先回忆这个迭代到底发生了什么，这个至关重要，不然暴露的问题很可能变成天马星空的抱怨。上面用一个词描述这个迭代的感受是一个很好的方法，但除此之外还有心情曲线法也是很有意思的方式。方法很简单，就是让大家画一条基于时间轴（标注团队的关键时刻或里程碑）的心情曲线。如图是一个团队真实的曲线结果，每个人都不一样，分享这个曲线的过程甚至能加强团队成员的相互了解，加强信任感。2.2 收集数据收集数据一般包含收集做得好的部分，做得不好的部分，有时还会创新想法部分。这个环节是回顾会议最具代表性的，发贴纸，然后大家各自写，一个问题一张贴纸……如下图就是一个真实的例子：上面这个方式用得非常广泛，就不多讲了。除此之外还有一些变形的方式：通过视觉化的、隐喻性的方法做引导，比如帆船回顾法。模拟论坛接力留言的方式，一个问题一张A4纸，大家按顺序传递加上自己的简介，通过书写来收集数据。2.3 产生见解收集到了数据只是第一步，如果顺利，到此为止我们就能收集到大量的、反应真实情况的好的和需要改进的点。接下来我们需要整理了。先分类，因为大家是各自独立写的，所以肯定会有重复的，所以把同类的放到一起我们才能让满墙的纸片不那么凌乱。分类需要花一点时间，但这个过程也是刚好让大家都了解其他人写了什么的好机会，所以我往往会邀请组员上来和我一起来做分类，一个人做卡片宣读，允许大家讨论，一个人把相同意思的卡片贴到一起。对做得好的部分，我们需要提出来鼓励大家，希望我们能坚持下来，甚至做得更好。这个部分在实际操作中往往比较忽视，大家更愿意快点调到待改进部分。无论如何，如果发现团队士气低落，需要鼓励的话，这时就是很好的机会，每个做得好的地方你都能有感而发。对待改进的部分，这个是本次会议的核心内容，不过很不幸，往往团队总结出来的待改进方面会比较多（>5个就算多吧），可会议时间有限，对这个部分，我们首先要做的就是确定优先级最高的核心问题（不超过3个）。确定的办法最常用的就是投票，比如每人两票。2.4 确定改进项当我们确定了待改进的重点之后，我们就需要讨论得出针对这些问题的改进方案。不过别急，不要这么快就跳到了改进方案上来，针对问题我们要先分析问题的根源，找到问题最根本的原因，我们再针对原因采取改进行动，这样才能对问题做到根本的解决。鱼骨图或5W的方法寻找问题根源最常见的方法有鱼骨图法，如下图，使用方法就不解释了，大家自己google。还有一个理论就是5个WHY，也是一个很好用的方法。分组讨论讨论寻找问题根源的的过程往往非常费时，这里常用的一个方式是把组员分组，每个小组专门讨论一个问题，我们可以限时让他们讨论出问题的根源和推荐出改进计划，这样我们一个能节省时间，更有价值的是可以调动每一个成员的积极参与度。SMART的改进计划一个老调重弹的就是所有的改进计划都必须是SMART的，SMART原则也不介绍了。这点说得容易，但做起来往往困难很大，大家非常容易产出一些类似建议一样的东西，完全没办法执行。这里给大家一个小窍门，在每产出一个action的时候就问一下大家“这个action可以执行吗？能判断是否完成吗？”，这样往往就能帮忙准确判断是否SMART。避免产出过多改进计划当然还有一个陷阱就是改进计划过多，到时候团队根本没有时间完成这么多的改进计划，这个也需要排优先级；还有超出团队能力范围的改进要避免，不然也没法落实。2.5 结束会议结束会议如果有必要的话我们可以简单对本次会议的组织做个总结建议，可以帮助我们提高下次回顾会议的组织能力。但我最喜欢的结束会议的方式是让大家每个人通过一张纸片的形式感谢团队里的一个人，并附上理由。我觉得这是一个很好的激励团队更多合作和相互帮助的好办法。写好纸片之后，我会请大家当众宣读一下卡片内容，并亲手交给自己感谢的人，纸片格式如下：三、提供几个需要注意的地方一般情况不建议团队的经理参加回顾会议。这有悖于准备环节中提到的设立一个安全的环境，大家会担心在会议上暴露团队问题会对他们绩效产生不好的影响。但也有一种情况我们需要经理在场，那就是团队已经积累了很多非常严重的问题，但是经理可能都不大了解情况，大家都期盼的经理在场能听到并推动解决这些问题。会议产生的改进计划怎么有效地跟踪？一般我们建议把这些action之间放到团队下个迭代的工作列表中，和普通开发工作一样对待跟踪，只有这样才能有效地使得改进落地。前后回顾会议产出相同或类似的改进计划。这说明老问题一直没有解决，有的时候会发现每次改进计划都完成了，但是老问题仍然还在。一般如果想改进能力或是外部依赖的问题往往会导致这样的情况，这些不像团队自己的流程那样能立竿见影，面对这样的问题，团队最好能计划一些长期的（周期跨迭代的）改进计划，下次回顾会议可以监控进展，而不是提重复的问题。如果需要，别忘了在回顾会议前面简单过一下上次回顾会议产出的改进计划完成情况。本文作者：鹿迦 阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。