『壹』 常用的数据分析工具有哪些
1.QUEST
QUEST是IBM公司Almaden研究中心开发的一个多任务数据挖掘系统，目的是为新一代决策支持系统的应用开发提供高效的数据开采基本构件。系统具有如下特点：
提供了专门在大型数据库上进行各种开采的功能：关联规则发现、序列模式发现、时间序列聚类、决策树分类、递增式主动开采等。
各种开采算法具有近似线性（O(n)）计算复杂度，可适用于任意大小的数据库。
算法具有找全性，即能将所有满足指定类型的模式全部寻找出来。
为各种发现功能设计了相应的并行算法。
2.MineSet
MineSet是由SGI公司和美国Standford大学联合开发的多任务数据挖掘系统。MineSet集成多种数据挖掘算法和可视化工具，帮助用户直观地、实时地发掘、理解大量数据背后的知识。MineSet有如下特点：
MineSet以先进的可视化显示方法闻名于世。
提供多种 萃诰蚰J健0 ǚ掷嗥鳌⒒毓槟J健⒐亓 嬖颉⒕劾喙椤⑴卸狭兄匾 取?br>
支持多种关系数据库。可以直接从Oracle、Informix、Sybase的表读取数据，也可以通过SQL命令执行查询。
多种数据转换功能。在进行挖掘前，MineSet可以去除不必要的数据项，统计、集合、分组数据，转换数据类型，构造表达式由已有数据项生成新的数据项，对数据采样等。
操作简单、支持国际字符、可以直接发布到Web。
3.DBMiner
DBMiner是加拿大SimonFraser大学开发的一个多任务数据挖掘系统，它的前身是DBLearn。该系统设计的目的是把关系数据库和数据开采集成在一起，以面向属性的多级概念为基础发现各种知识。DBMiner系统具有如下特色：
能完成多种知识的发现：泛化规则、特性规则、关联规则、分类规则、演化知识、偏离知识等。
综合了多种数据开采技术：面向属性的归纳、统计分析、逐级深化发现多级规则、元规则引导发现等方法。
『贰』 用敏捷开发方法创建产品之看板
前篇文章中介绍了敏捷开发的 Scrum方法 ，本文将要介绍的是另一种流行的方法——看板Kanban，以及两种方法的对比。
看板源自丰田公司开发的用以改善汽车制造流程的体系，其生产体系注重及时生产「Just-in-Time，JIT」，以避免浪费，这可以认为是精益软件开发运动的前身。
看板的核心概念是可视化。每张卡片代表一个用户故事或随之而来的开发子任务。卡片都被排在看板上，从左至右，每一列按照工作流程顺序，如下图所示。
有些列代表工作正在进行「如开发中、测试中」；有些则表示有待进入下一个工作阶段「如预备、开发完成」，同时这些列表中积攒的一系列工作，当一名团队成员完成了手头的工作后，便可以从中选取最优先一项。
当工作项目逐一经过各个阶段时，代表这项工作的卡片也会从上一列移动至下一列。整个团队的工作状态都可以通过看板一目了然，与此同时也很容易从那些积攒了很多卡片的列中看出瓶颈所在。
「开发」和「测试」有两种状态的好处在于有助于让团队对工作状态有一个更清晰的认识，易于发现瓶颈。
看板中激活的工作数量受到“进行中的工作”的制约，开发团队会决定每一列所允许的最多卡片上限，称为在制品数量上限「working in progress，WIP」。这条规则能确保工作流程的平稳、顺畅。
还可以用用到来进一步划分看板，采用水平线横向管理个列表中的卡片。采用优先泳道的方式为每个史诗故事分配单独的泳道；可以为每个人分配单独的泳道来更清楚地显示其工作流程；可以在一块看板上记录下多个相关项目，将每个项目放在一个单独的泳道。
看板的重点在于工作流程，它没有Scrum的迭代时限。当工作向前推进时，相应的工作项目也持续从看板的左侧向右侧移动，所以Scrum中的开发速度改变并不是适用于看板。但可以按团队在一段时间内完成的工作项目来测量团队的生产能力。
看板中有两个经常用到的指标： 循环时间「即某工作项目从开始处理到交付给客户所消耗时间的平均值」和交付时间「即每项工作从创建之初到交付给客户所消耗时间的平均值」 。工作循环时间和交付时间并不一定与工作量相关。比如某项工作可能只需要一个小时「循环时间」即可完成，但由于需要等待开发团队来处理而很较长的交付时间。
可以用累积流图形象地观察看板系统中的工作流状况，如下图示，简单起见，只用了三种工作状态：待办、开始和完成。
看板理念体系专注于持续改善，团队应定期回顾和讨论如何更快、更好的工作。随着团队技能水平和流程持续的改善，产品的交付时间和循环时间也会逐渐缩短。
对于看板工具，小型团队一般会用一块白板+便利贴来表示，另外一些专业的管理看板工具，如Trello、国内的Teambition、Worktile、Leangoo等。
Scrum vs Kanban
看板往往适合小型开发团队， 更低的流程开销和无需预先定义迭代时间的长短，使得产品交付更加快捷。但随着开发组织发展至多个团队，由于缺乏预定的工作节奏，要保持所有人达成共识所需的沟通成本越来越高，看板就越来越难以应付。如果团队有强大的协作功能，可以藉此放大看板的使用范围。
如果组织能有多个开发团队需要协调工作，工作节奏更加可控的Scrum比较合适。
如果很难抛开时间节点的限制，或者心里没底，那Scrum可能比看板更适合。 因为在Scrum中，至少知道每轮迭代后还有什么工作可做，并且能大致预估出每项功能需要多少轮冲刺迭代才能完成。而绝大多数看板并不会在评估工作量或预测完成日期上花时间。
不论采取何种方法，敏捷开发方法成功创建产品有一下几个秘诀，
跨职能合作： 强有力的跨职能团队的相互协作；
精密排序： 维护一份最新的、根据优先级排序的待办任务事项列表；
为开发者充分定义产品： 提供一份清晰明了的用户故事，配以框架图或模型；
不能让开发者无米下锅： 待办事项列表的内容至少要保证开发人员在一个冲刺迭代期内满负荷工作；
分解用户故事： 用户故事不应超过某个合理的规模范围，应分解成尽可能小的模块。
『叁』 求推荐一款比较适合敏捷开发团队协作的工具
不请自来了~
过去的软件如word之类的迭代都以年为周期的，自然无法应对快速变化的市场需求。因此，需要更加敏捷的方式，应对快速发展的互联网世界的发展。
敏捷开发最重要的特点是： 以用户需求为中心，快速灵活，团队合作度高 。
敏捷开发以scrum最为普遍。
scrum3.0中有6个角色，3个工具，4个会议。 其中3个工具指：交付清单、工作清单、正在进行的工作；4个会议是：计划会议、产品评审、进度回顾、团队回顾。
因此，scrum3.0既有计划会议、产品评审、进度和产品回顾会议，也有迭代期内的灵活应变过程，是一种轻重结合的比较好的敏捷方法。
敏捷开发scrum3.0在日事清团队内部中也在使用。下面详细说下~
在日事清软件中，利益相关者如销售、市场、运营等，
在与用户平日的接触中积累的功能、缺陷、创意上的建议，
并收集于计划看板的【BUG看板】、【建议看板】。
接下来，业务所有者(BO）需要维护精细的需求池（如下），这个职责通常由产品经理担任，他需要非常明白产品的定位和发展，将需求池中的任务按照优先级排序，并拆解为一个个小的用户故事。然后设置具体的实施时间和项目名称，将可交付成果和待办清单，记录于 road map 中。
在日事清中，这些用户故事的描述会记录在 任务描述 上，可以让开发人员更快速获取信息。
之后，我们的scrum团队会创建一个计划为 【产品开发】 ，产品经理（业务所有者）以及开发经理（团队负责人）会从【roadmap】中提取功能形成work backlog，复制到 【产品开发】 的 【规划池】 中，work backlog中还包含一些开发团队必须做的工作，会直接记录在 【规划池】 中。
正式开始开启sprint （sprint：整个开发过程中若干个短的迭代周期组成）的第一件事，就是召开sprint计划会议。sprint会议上会确定本次sprint周期的目标是什么，我们需要完成哪些功能。
在会议中，开发经理（团队负责人）需要将 【规划池】 中的功能拖动到 【开发中】 ，从 【开发中】 到 【测试中】 就是日事清所实践的正在进行的工作(WIP)。
会议上会评估每个功能所需的工时以及功能的负责人，我们为确定好的功能添加时间以及任务成员。通常计划会议会开比较长的时间，它是之后迭代开始运作最关键的会议。
为使得这个会议得到很好地传达，可以通过日事清的日程应用创建好会议任务，并下发给团队成员。
sprint计划会议的开启，意味着第一个sprint开始了！
从开发到测试，形成的工作成果都发布到beta版本中。
另外，在日事清中，【bug管理】、【建议管理】、【产品开发】都可通过计划模块中的 列表、看板和进度 这三种不同的视图方式显示。
列表视图
看板视图
进度看板
日事清还可以在统计中，多角度查看项目工作进展，自动生成 燃尽图、任务完成情况等统计数据 。通过这些数据可以任务的完成度和迭代的是否顺利，人员分工是否合理。
执行sprint的过程中也有很多问题被发现，需要解决，应此需每日召开约15分钟的站立会。
在每日站立会上，每个团队成员需要回答三个问题：
昨天做了什么工作？
今天要做什么？
完成目标是否存在什么问题？
在日事清一键生成的工作日报中，通过“KPTP+今日未完”成可以实现“每日站立会”，减少了面对面的沟通成本。
当测试人员完成了本个周期内的所有功能的测试工作时，预示着本个sprint结束。
在迭代结束前，产品负责人需要进行产品评审，产品会对测试中的功能进行验收。将达到了产品目标的成果拖动到 【待发布】 中。
最后整个团队还需要进行一次回顾总结会议，回顾这次迭代有哪些做的好，哪些做的不好，有什么计划。团队成员需轮流发言，完成自评和他评，分析和总结上一个迭代中遇到的问题，并列出下次的可执行任务，便于改进整个团队的效能。
至此，一个sprint周期完成，以此开始下一个sprint，不断循环往复。
希望对你有用~
分享一款开源的企业级协同在线文档-无忧·企业在线文档。
这是一款支持 开源 （提供100%源代码）、私有化 部署 （并支持SaaS模式与PaaS模式）、支持
二次开发 的企业级在线文档。
产品功能介绍：
登录界面，干净利落，没有任何广告（支持多模式用户登录，微信登录、账号密码登录、也可添
加其他登录方式）
在线编辑，协同办公 ：可多人同时编辑，目前是各个大小企业办公中必不可少的功能，协同办公
在相同成本的情况下，大大的提高工作效率
便捷操作：像书架一样的 知识库 的目录及大纲功能，让多篇文档结构化，形成一本本像书一样清
晰易读的知识库，方便知识创作及沉淀。文章内容编辑时刻上手，无需培训。
完善的权限体系：组织、部门、菜单、角色、等权限体系，更加适合于企业管理
高效协同，支持团队管理，提供所有者、管理者、成员、普通游客等多种角色控制信息分享范围
支持多种文档：富文本、脑图、在线表格、画图等等。。。
简单好操作的文本编辑器
功能丰富强大的在线表格，你想要的功能都有
清晰极简的脑图编辑
协同办公，提升团队效率
组件超多的流程文档编辑，支持自动瞄点
强大的文库搜索引擎，轻松查找任何文档，任何内容，更加方便
多种应用扩展，更加轻松便捷
安全的信息分享，多种分享方式，密码分享让信息更加安全
产品核心特色：
私有化部署 ：提供容器化部署方案，支持公有云、私有云的多种模式，满足不同场景需求，私有
的才是安全的。
代码开源 ，目前开源的代码在gitee、github等代码托管平台开源，100%源码开放。
扩展性强 ，底层采用spring cloud 的基础框架，可以扩展海量并发，并且目前除了知识库，开发
团队正在构建私有化的视频会议、邮件管理、任务管理等应用。
支持多种模式 ：支持多租户（SaaS），也支持单租户（PaaS）模式，后端自主控制
开源地址：https://gitee.com/software-minister/jvs-knowledge-ui
无忧文档目前版本2.1.2，下一个版本更新规划：
除了上述的功能，我们接下来还将逐步开源 “项目任务管理”、“私有化的视频会议”、“企业内部管
理系统”等等一些企业级应用PaaS产品。
推荐使用畅写office（
www.51changxie.com
理由有如下几点：
1.方便团队使用，只需要登录网页便可以使用，并且是电脑端/移动端双端使用，不需要下载额外的安装包，省时省力，使用起来非常简单易操作。
2.畅写是基于原版office软件来进行整合使用的，支持多人协作编辑，能够深度兼容微软Office2003-2019的文件格式，支持doc、docx、xlsx、xls、ppt、pptx等格式。换句话说，不管团队使用任何的办公软件进行办公，都不会出现像乱码、格式错误等情况；也不会出现文件下载or上传后不兼容的问题，非常适合团队办公。
3.畅写拥有良好的团队协作能力，能够实现与团队成员良好的沟通，不会出现耽误团队办公的情况，实时性非常强
成员可以对要编辑的文档同时进行批注、编写，实现真正的协作、共享、权限控制、分享，协作者随时都可以获取文档数据最新内容，沟通与协作同时进行。
上图是可以对文件进行分享协作，实现单个文件的多人同时编辑。
这是对文件进行分享后的状态，可以发现在这里是不允许对此文件进行二次分享的，通过设置权限来确保分享的安全性。
总之，畅写通过协作空间等功能，很好的实现了多人同时协作编辑，文件和人员等多维度的操作权限控制，文档自由与管控的分发，群组共享与协作。随时随地都可以获得最新文档状态和数据，使得沟通、协作、编辑系统化，一体化，打破空间和时间的限制，并且能够保证文档传输更安全、更高效。
畅写office正是团队协作工具的不二选择。
推荐一款功能比较全，上线时间比较快（差不多一周就能交付），最重要的是大部分团队的需求而且价格便宜的产品。
接下来我就直接贴的介绍了，感兴趣看看。
SNAP——企业社交化协作平台
利用移动社交技术，连接企业员工、客户与合作伙伴，构建企业社交三张网，通过多端协作满足不同用户的安全沟通、办公协作、内容分享的一站式服务诉求，形成企业办事的最短路径，大幅提高组织工作效率。
更多详细的内容建议你去官网了解，毕竟一两句话也说不全。
https://cloud.neusoft.com/pages/proct/p_snap
推荐一下 Worktile 。
Worktile的7.0版本可以完美适配敏捷开发。
先来看下Worktile的所有需求以表格的方式展示。
还可以甘特图的形式展示。
而且Worktile有敏捷开发专用的【迭代】组件，可以一目了然的看清当前迭代的进展。
任务看板的属性支持自定义。
有时候一个需求需要拆分成多个子需求，这时就需要子需求或者关联其他任务。
同时，支持属性自动同步，例如更改了任务A的某个属性，任务B中的这个属性也自动同步变更，例如迭代、负责人等。
好啦，以上只是Worktile的部分功能，有兴趣的朋友可以戳「 Worktile 」免费注册试用一下。
蓝湖产品设计协作平台了解一下。
『肆』 看板方法 与 Scrum 的比较：选择最佳敏捷项目管理框架[译]
“我们在使用敏捷方法。”在与软件开发团队交谈时，您经常会听到这样的声明。确实如此，根据统计2018年全球大约90％ 开发人员在使用敏捷方法。
但是，敏捷并不统一的方法。作为组织开发流程的通用方法，敏捷软件开发设定了共同的价值观和原则，旨在使开发过程更加简化，更加高效，更能响应变化。这些价值观和原则可以在 敏捷宣言 中找到，其中还包含了建立开发流程的推荐方法。
在现实生活中，这些敏捷原则已经衍生出了相当多正在实际使用的软件开发框架。看板（Kanban）和Scrum是其中最受欢迎和最常使用的开发框架。虽然两种方法都有一个共同的目标，即创建一个高效的开发流程，但是两者还是存在着一些差异。这就是我们今天要讨论的内容。
了解Scrum方法和看板方法的工作原理，可以帮助客户和开发人员理解开发团队的工作节奏，并制定相应的开发计划。
在我们深入研究Scrum和看板的差异之前，让我们先看一下两个框架的主要概念。这样，更易于我们比较看板与Scrum。两者都在为建立一个自组织团队而设计流程; 但是，采用了不同的方法。
Scrum的名字来自橄榄球术语，意思是球员组成阵型共同占据球权。在软件开发中，Scrum是指组织团队的方法，该方法旨在更高效地开发复杂的软件产品。
Scrum方法哲学是基于这样一个假设 - 或者说事实？ - 开发团队在项目开始时并不知道项目的最终成果，而是随着开发过程中不断了解和试探调整，最终完成交付。Scrum通过在每次迭代开始时重置优先级来简化这种调整，迭代在Scrum术语中被称为“冲刺（sprint）”。
我们再来看一个Scrum的核心概念 - 冲刺，即一个2到4周的迭代周期，在此期间需要完成明确数量的开发任务。冲刺有助于将项目范围分解为更容易管理的任务包，能更频繁地交付可运行的软件组件。我们将简要地介绍冲刺计划，计划调整和计划完成的细节。
基于冲刺计划进行开发，并专注于每个冲刺中应该完成的任务项，这使得开发计划具有很大的灵活性。团队从一个“空白的任务列表”开始每个新的冲刺，根据当下的情况和项目需求的变更来制定新的冲刺的开发计划。
看板方法最初是丰田公司为了优化其工厂库存发明的。在日语中，“看板”是指公告板或卡片。在最初的实践中，工厂生产部门会为某种数量不足的零件向仓库发送“看板”，要求补足数量。然后，仓库将“看板”发送给供应商以订购更多相应的零件。
从这个例子中，我们可以看到看板方法专注于当前容量，这也是它引入软件开发领域的主要概念。与Scrum不同，看板方法没有时间限定; 相反，它限定了可以同时执行的工作量。
看板的主要指标之一是“正在进行的任务” ，即当前正在执行的任务。根据看板方法，为了实现最高效率，正在进行的工作任务应限定为与团队的能力相适应的任务数，从而降低任务瓶颈产生的风险。
看板也能很好地适应变化，这很重要，因为变更会在项目的任何阶段产生，并需要随时添加到要执行的任务池中。
如果我们想比较Scrum和看板，我们需要看看两个框架组织工作流的方式以及它们使用的主要形式和定义。
角色的分配是Scrum和看板之间的第一个重大区别。 在Scrum中，您总能在团队中找到三个主要角色：
反之，看板对团队角色没有严格的要求。 也许会有一个产品负责人管理项目backlog中的任务，但除此之外，团队是自组织的。
正如我们所说，Scrum开发是在迭代中进行的，Scrum定义每次迭代中要完成的工作任务。看板则限定了当前正在进行的工作任务数，而没有具体的时间限定。让我们来看看这两种方法的实际应用。
项目计划从定义backlog开始，即应该交付完成的产品的用户故事列表。在这种情况下，Scrum使用以下主要概念来帮助我们理解计划和发布过程：
每个冲刺都以 计划阶段 开始，选择接下来冲刺所要完成的任务。对于制定计划过程，通常整个团队都要参加，包括产品负责人和Scrum导师。团队决定在冲刺结束时提交的内容，并从产品backlog中选择相应的用户故事。通过这种方式，团队整合了冲刺backlog。
在冲刺期间，团队每天召开 “每日立会” ，讨论他们的进展以及可能遇到的问题。每日立会的目的是尽早发现问题并快速找到解决方案，以免破坏冲刺流程。
冲刺完成后，客户将审查完成的功能。在 冲刺回顾 期间，团队有机会收到有关其交付物的反馈和变更请求（如果有的话）。
与此同时，团队会召开 冲刺回顾 会议，分析他们刚刚完成的冲刺并找到可以改进的地方。回顾完成后开始新的迭代，新的冲刺又从计划阶段开始。
在看板方法中，没有必须完成一定数量工作任务的时间计划。相反，看板专注于匹配团队的开发能力与当前正在进行的工作任务数。
看板项目流程从一个包括需要完成的所有任务清单的backlog开始。每个团队成员从backlog中为自己选择一项任务，并专注于完成它。任务完成后，成员再从backlog中选择下一个任务，依此类推，直到backlog清空为止。backlog按照优先顺序，把最紧急的任务放在最顶层，便于团队成员优先选择。
在看板项目周期内， 正在进行的工作任务 数量都不超出团队的工作容量至关重要。为此目的，可以根据可分配工作量为各种类型的工作任务设定限制。
产品负责人可以根据需要随时设定或调整backlog中的任务优先级，因为backlog管理不会影响到开发团队的工作绩效。开发团队只关心正在进行的工作任务，且只有在当前任务完成后才会关注backlog。
每项任务都沿着“待办” - “进行中” - “已完成”的状态路线行进。当然，看板也支持“已完成”概念的定义，即每个任务被接受的标准。
最终，已完成的任务组成产品组件，以便度量交付产品所需的时间。在看板中，它被称为 “周期时间” ，对周期时间的度量为过程优化提供了许多机会。当然，所有团队成员都在努力尽量缩短周期时间，并寻找解决开发瓶颈的方法（如果有的话）。
在这种情况下，让团队成员具有多重技能至关重要。如果只有一个人拥有某种技能 - 例如，如果你只有一个测试人员 - 那测试就会成为瓶颈。所有测试任务都将排队等待，以致于产品交付延迟。
总而言之，我们可以说两种方法的主要区别在于，Scrum方法努力使团队在指定时间内完成预定工作任务，而看板方法则确保正在进行的工作任务永远不会超过设定的团队最大工作量。
说到Scrum和看板，我们不能忽略其任务板。两种方法都使用任务板作为可视化工具来规划和监控项目进程。任务板反映了Scrum和看板的主要概念，及相应的组织方式。
虽然有很多工具用于创建并管理Scrum和看板的任务板（例如，Jira和TargetProcess两者都支持，而Trello最初是一个看板工具，但也可以扩展用于Scrum），你也可以使用带有标记和即时贴的纯白板。关键是学习如何使用任务板，而与具体的工具无关。
Scrum任务板至少应包含三列，分别标记为“待办（To Do)”，“进行中(In Progress)”和“已完成(Done)”。如果需要，您还可以添加“用户故事”列，显示所有的用户故事，或在“已完成”之前插入“测试”列，但最终它们都会及时显示当下的任务进度。
在每个冲刺开始时，所有任务都在第一列中，而在冲刺结束时，它们都应该按照“已完成”的定义移动到最后一列“已完成”中。之后，就可以清空任务板为下一次冲刺做好准备了。
Scrum任务板总是由为同一产品开发的一个团队所拥有。通常，Scrum团队成员是跨职能的，包括所有技能，从开发人员和架构师到测试人员和技术文档撰写者。
看板任务板的外观和工作方式与Scrum相同，但有一个主要区别 - “进行中”列中显示了任务限定量。正在进行的任务数量不能超过该限定量。
看板存在于整个工作周期中。 因为它们不受任何特定时间段的约束，所以没有必要重置。
因为看板是用于整个工作周期的，所以它们不属于某一团队，可以在不同团队之间共享。在看板中，任务板可用于特定的工作，例如营销任务板等。
如果您一直在等待这个问题的确定答案，我们可能会让您失望。到目前为止，我们希望我们能够证明这两种方法都有其优点，并且两者都有助于建立敏捷开发流程。当然，我们提供了一些建议，可以帮助您选择最适合您团队的方法。
使用Scrum方法，如果：
使用看板方法，如果：
您还可以随时组合这两种方法！ 甚至还有一种称为 Scrumban 的方法，其中包含Scrum和看板的方法。在Scrumban方法中，您可以在短迭代周期内完成工作，并使您的工作量保持在一定限度内。超出限定量的任务会触发新的迭代。
如您所见，可以像您希望的那样灵活和自由地选择项目管理方法。没有任何规则是一成不变的，您可以根据自己的项目需要对项目管理方法进行裁剪，组合和使用。实际上，选择项目管理方法的主要标准始终是您的项目成功和团队对工作流程的满意度。
原文： Kanban vs Scrum: choosing the best Agile project management framework