学习ES6零基础-彩票项目中，解决项目代码中运行错误的问题
最近在学习ES6，在B站上看了一些视频再结合阮一峰老师的《ES6标准入门》基本上对ES6的各特性过了一遍，那就开始动手练项目咯，在找到视频对应的代码后，下载并运行出现了几个问题，通过百度又没查到相关的解决思路，这不还得科学上网，毕竟你询问的人群是全世界，总有适合的哪一个。话不说，开始叙述问题，并一步步的解决问题。项目的源代码在我的github上：https://github.com/sun2013126370/es6-lottery-master，视频的话去B站找咯。 先说一下我的相关配置吧
|
1 2 3 4 |
nodejs版本： v10.13.0 npm版本：6.4.1 gulp版本：CLI version 3.9.1（全局安装-npm install -g gulp） |
1 2 3 第一个问题： Failed to load external module @babel/register 网上说gulp的版本变成3.9.0（命令：npm install -g gulp@3.9.0）就可以，可以解决这个问题，但是至今还没找到出现这个问题的原因。还好，这个问题并不影响项目的运行，因此选择忽略这个错误或者将gulp的版本换成3.9.0都可以。 第二个问题：TypeError: require.extensions.hasOwnProperty is not a function 这个问题是由版本造成的，打开项目中的package.json，将0.3.1版本改成0.3.2即可，并执行npm install 命令。 重新执行gulp --watch命令，又发现了如下错误，go on! 第三个问题：gulp[13772]: src\node_contextify.cc:628: Assertion `args[1]->IsString()’ failed. 具体什么原因，还没有搞明白，后续再补充。解决这个问题的办法就是npm install natives，再次运行 gulp --watch，OK啦，项目起来了。在浏览器输入localhost：3000，就看到效果了。那接下来就是敲敲项目代码，把出现问题的原因找出来。 from:https://blog.csdn.net/a2013126370/article/details/84102343
View DetailsNodejs Sass安装报错一招解决
背景： 这个问题不是一天两天了，有时候是网速不行，有时候是被墙了，有时候是github把node-sass的包转移目录导致下载失败。 Cannot download "https://github.com/sass/node-sass/releases/download/xxx/binding.node的问题 另附node-sass的binding.node各个版本的安装包，哪里少，就单独下载哪个，下载完了之后，跟着我，一起把文件放在指定位置即可解决这个问题 https://github.com/sass/node-sass/releases/tag/v4.7.2 1.本机位置 C:\Users\Administrator\AppData\Roaming\npm-cache\node-sass\ 这个里面是各种版本，报错提示你哪个版本下载失败，你就塞到哪个版本的文件夹里，如图所示 2.删除项目的node_moduls目录 3.重新npm install 4.另附全局安装命令
|
1 2 3 |
npm i sass-loader node-sass webpack <span class="hljs-comment">--g</span> npm i style-loader css-loader <span class="hljs-comment">--g</span> |
qq 43163707 落雨 本文地址:http://www.cnblogs.com/ae6623/p/8711853.html
View Detailsgulp自定义标签
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
var gulp = require('gulp'); var connect = require('gulp-connect'); var replace = require('gulp-replace'); function defaultTask(cb) { // place code for your default task here cb(); replaceTask(); connect.server({ root: "build", port:8888 }); connect.serverClose(); } function replaceTask(){ /*index*/ gulp.src(['./index.html']) .pipe(replace("@@{user_domain_url}", "http://user.domain.com")) .pipe(replace('@@{nickname}', 'gz')) .pipe(gulp.dest('build/')); /*js*/ gulp.src(['js/*.js']) .pipe(replace("@@{user_domain_url}", "http://user.domain.com")) .pipe(replace('@@{nickname}', 'gz')) .pipe(gulp.dest('build/js')); } exports.default = defaultTask; |
View Details
前端构建工具gulp超详细配置, 使用教程(图文)
流程 1. 输入命令(可以使用git bash或者命令控制台cmd) npm install -g gulp 安装全局gulp命令 2. 创建一个项目文件夹, 当前项目文件夹下输入命令npm init 配置package.json文件, 这一部分看情况自己决定是否填, 不想填也可以, 直接按回车 当前项目文件夹下输入命令npm install gulp --save-dev 全局安装gulp后，还需要在每个要使用gulp的项目中都单独安装一次 开始使用gulp 其实, gulp的使用比webpack要简单很多. 配置gulpflie.js文件 在当前项目文件下创建文件名为gulpfile.js文件, 作为该项目配置文件.
|
1 2 3 4 5 6 |
//gulpfile.js var gulp = require('gulp'); gulp.task('default',function(){ console.log('hello world'); }); |
其实在项目文件夹下输入命令gulp时, 就是触发这个default任务, 因此, 我们定义多个自定义事件, 这样在输入gulp时, 就可以直接将我们写的命令也一起触发. gulp API gulp.src(globs[, options]) globs参数是文件匹配模式(类似正则表达式)，用来匹配文件路径(包括文件名)，当然这里也可以直接指定某个具体的文件路径。当有多个匹配模式时，该参数可以为一个数组。 options为可选参数。通常情况下我们不需要用到。 下面我们重点说说Gulp用到的glob的匹配规则以及一些文件匹配技巧。 名称 说明 * 匹配文件路径中的0个或多个字符，但不会匹配路径分隔符，除非路径分隔符出现在末尾 ** 匹配路径中的0个或多个目录及其子目录,需要单独出现，即它左右不能有其他东西了。如果出现在末尾，也能匹配文件。 ? 匹配文件路径中的一个字符(不会匹配路径分隔符) […] 匹配方括号中出现的字符中的任意一个，当方括号中第一个字符为^或!时，则表示不匹配方括号中出现的其他字符中的任意一个，类似js正则表达式中的用法 !(pattern|pattern|pattern) 匹配任何与括号中给定的任一模式都不匹配的 ?(pattern|pattern|pattern) 匹配括号中给定的任一模式0次或1次，类似于js正则中的(pattern|pattern|pattern)? +(pattern|pattern|pattern) 匹配括号中给定的任一模式至少1次，类似于js正则中的(pattern|pattern|pattern)+ *(pattern|pattern|pattern) 匹配括号中给定的任一模式0次或多次，类似于js正则中的(pattern|pattern|pattern)* @(pattern|pattern|pattern) 匹配括号中给定的任一模式1次，类似于js正则中的(pattern|pattern|pattern) 例子:
|
1 2 3 4 5 6 7 8 |
//转换html文件 gulp.task('html', function(){ gulp.src('./src/index.html') .pipe(connect.reload()) .pipe(gulp.dest('./dist'));//写入命令 }); 当有多种匹配模式时可以使用数组 |
|
1 2 3 4 |
//使用数组的方式来匹配多种文件 gulp.src(['js/*.js','css/*.css','*.html']) 使用数组的方式还有一个好处就是可以很方便的使用排除模式，在数组中的单个匹配模式前加上!即是排除模式，它会在匹配的结果中排除这个匹配，要注意一点的是不能在数组中的第一个元素中使用排除模式 |
|
1 2 |
gulp.src([*.js,'!b*.js']) //匹配所有js文件，但排除掉以b开头的js文件 gulp.src(['!b*.js',*.js]) //不会排除任何文件，因为排除模式不能出现在 |
数组的第一个元素中 此外，还可以使用展开模式。展开模式以花括号作为定界符，根据它里面的内容，会展开为多个模式，最后匹配的结果为所有展开的模式相加起来得到的结果。展开的例子如下： a{b,c}d 会展开为 abd,acd a{b,}c 会展开为 abc,ac a{0..3}d 会展开为 a0d,a1d,a2d,a3d a{b,c{d,e}f}g 会展开为 abg,acdfg,acefg a{b,c}d{e,f}g 会展开为 abdeg,acdeg,abdeg,abdfg gulp.dest(path[,options]) gulp.dest()方法是用来写文件的 path为写入文件的路径 options为一个可选的参数对象，通常我们不需要用到 要想使用好gulp.dest()这个方法，就要理解给它传入的路径参数与最终生成的文件的关系。 gulp的使用流程一般是这样子的：首先通过gulp.src()方法获取到我们想要处理的文件流，然后把文件流通过pipe方法导入到gulp的插件中，最后把经过插件处理后的流再通过pipe方法导入到gulp.dest()中，gulp.dest()方法则把流中的内容写入到文件中，这里首先需要弄清楚的一点是，我们给gulp.dest()传入的路径参数，只能用来指定要生成的文件的目录，而不能指定生成文件的文件名，它生成文件的文件名使用的是导入到它的文件流自身的文件名，所以生成的文件名是由导入到它的文件流决定的，即使我们给它传入一个带有文件名的路径参数，然后它也会把这个文件名当做是目录名，例如：
|
1 2 3 4 5 6 7 8 |
var gulp = require('gulp'); gulp.src('script/jquery.js') .pipe(gulp.dest('dist/foo.js')); //最终生成的文件路径为 dist/foo.js/jquery.js,而不是dist/foo.js 要想改变文件名，可以使用插件gulp-rename 下面说说生成的文件路径与我们给gulp.dest()方法传入的路径参数之间的关系。 gulp.dest(path)生成的文件路径是我们传入的path参数后面再加上gulp.src()中有通配符开始出现的那部分路径。例如： |
|
1 2 3 4 5 6 7 |
var gulp = reruire('gulp'); //有通配符开始出现的那部分路径为 **/*.js gulp.src('script/**/*.js') .pipe(gulp.dest('dist')); //最后生成的文件路径为 dist/**/*.js //如果 **/*.js 匹配到的文件为 jquery/jquery.js ,则生成的文件路径为 dist/jquery/jquery.js 再举更多一点的例子 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
gulp.src('script/avalon/avalon.js') //没有通配符出现的情况 .pipe(gulp.dest('dist')); //最后生成的文件路径为 dist/avalon.js //有通配符开始出现的那部分路径为 **/underscore.js gulp.src('script/**/underscore.js') //假设匹配到的文件为script/util/underscore.js .pipe(gulp.dest('dist')); //则最后生成的文件路径为 dist/util/underscore.js gulp.src('script/*') //有通配符出现的那部分路径为 * //假设匹配到的文件为script/zepto.js .pipe(gulp.dest('dist')); //则最后生成的文件路径为 dist/zepto.js 通过指定gulp.src()方法配置参数中的base属性，我们可以更灵活的来改变gulp.dest()生成的文件路径。 当我们没有在gulp.src()方法中配置base属性时，base的默认值为通配符开始出现之前那部分路径，例如： |
[…]
View DetailsJava Platform Standard Edition 8 Documentation
Oracle has two products that implement Java Platform Standard Edition (Java SE) 8: Java SE Development Kit (JDK) 8 and Java SE Runtime Environment (JRE) 8. JDK 8 is a superset of JRE 8, and contains everything that is in JRE 8, plus tools such as the compilers and debuggers necessary for developing applets and applications. JRE 8 provides the libraries, the Java Virtual Machine (JVM), and other components to run applets and applications written in the Java programming language. Note that the JRE includes components not required […]
View Details高并发接口设计思路
并发队列的选择 Java的并发包提供了三个常用的并发队列实现，分别是：ArrayBlockingQueue、ConcurrentLinkedQueue 和 LinkedBlockingQueue 。 ArrayBlockingQueue是**初始容量固定**的阻塞队列，我们可以用来作为数据库模块成功竞拍的队列，比如有10个商品，那么我们就设定一个10大小的数组队列。 ConcurrentLinkedQueue使用的是CAS原语无锁队列实现，是一个异步队列，入队的速度很快，出队进行了加锁，性能稍慢。 LinkedBlockingQueue也是阻塞的队列，入队和出队都用了加锁，当队空的时候线程会暂时阻塞。 在请求预处理阶段，由于我们的系统入队需求要远大于出队需求，一般不会出现队空的情况，所以我们可以选择ConcurrentLinkedQueue来作为我们的请求队列实现 1. 请求接口的合理设计 一个秒杀或者抢购页面，通常分为2个部分，一个是静态的HTML等内容，另一个就是参与秒杀的Web后台请求接口。 通常静态HTML等内容，是通过CDN的部署，一般压力不大，核心瓶颈实际上在后台请求接口上。这个后端接口，必须能够支持高并发请求，同时，非常重要的一点，必须尽可能“快”，在最短的时间里返回用户的请求结果。为了实现尽可能快这一点，接口的后端存储使用内存级别的操作会更好一点。仍然直接面向MySQL之类的存储是不合适的，如果有这种复杂业务的需求，都建议采用异步写入。 当然，也有一些秒杀和抢购采用“滞后反馈”，就是说秒杀当下不知道结果，一段时间后才可以从页面中看到用户是否秒杀成功。但是，这种属于“偷懒”行为，同时给用户的体验也不好，容易被用户认为是“暗箱操作”。 高并发下的数据安全 我们知道在多线程写入同一个文件的时候，会存现“线程安全”的问题（多个线程同时运行同一段代码，如果每次运行结果和单线程运行的结果是一样的，结果和预期相同，就是线程安全的）。如果是MySQL数据库，可以使用它自带的锁机制很好的解决问题，但是，在大规模并发的场景中，是不推荐使用MySQL的。秒杀和抢购的场景中，还有另外一个问题，就是“超发”，如果在这方面控制不慎，会产生发送过多的情况。我们也曾经听说过，某些电商搞抢购活动，买家成功拍下后，商家却不承认订单有效，拒绝发货。这里的问题，也许并不一定是商家奸诈，而是系统技术层面存在超发风险导致的。 1. 超发的原因 假设某个抢购场景中，我们一共只有100个商品，在最后一刻，我们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，然后都通过了这一个余量判断，最终导致超发。（同文章前面说的场景） 在上面的这个图中，就导致了并发用户B也“抢购成功”，多让一个人获得了商品。这种场景，在高并发的情况下非常容易出现。 2. 悲观锁思路 解决线程安全的思路很多，可以从“悲观锁”的方向开始讨论。 悲观锁，也就是在修改数据的时候，采用锁定状态，排斥外部请求的修改。遇到加锁的状态，就必须等待。 虽然上述的方案的确解决了线程安全的问题，但是，别忘记，我们的场景是“高并发”。也就是说，会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。 3. FIFO队列思路 那好，那么我们稍微修改一下上面的场景，我们直接将请求放入队列中的，采用FIFO（First Input First Output，先进先出），这样的话，我们就不会导致某些请求永远获取不到锁。看到这里，是不是有点强行将多线程变成单线程的感觉哈。 然后，我们现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，但是，系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说，队列内的请求会越积累越多，最终Web系统平均响应时候还是会大幅下降，系统还是陷入异常。 4. 乐观锁思路 这个时候，我们就可以讨论一下“乐观锁”的思路了。乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样的话，我们就不需要考虑队列的问题，不过，它会增大CPU的计算开销。但是，综合来说，这是一个比较好的解决方案。 有很多软件和服务都“乐观锁”功能的支持，例如Redis中的watch就是其中之一。通过这个实现，我们保证了数据的安全。 from:https://my.oschina.net/momisabuilder/blog/2992962
View DetailsGulp:静态资源(css,js)版本控制
为了防止客户端的静态资源缓存，我们需要每次更新css或js的时候，通过md5或时间戳等方式重新命名静态资源； 然后涉及到的html模板里的src也要做相应的修改，静态资源需要优化(压缩合并) 文件目录结构 html模板文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <html> <head> <!-- build:css styles/main.min.css --> <link rel="stylesheet" href="../styles/one.css"> <link rel="stylesheet" href="../styles/two.css"> <!-- endbuild --> </head> <body> <!-- build:js scripts/main.min.js --> <script type="text/javascript" src="../scripts/one.js"></script> <script type="text/javascript" src="../scripts/two.js"></script> <!-- endbuild --> </body> </html> gulp配置文件:gulpfile.js 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 […]
View Details为什么Scrum不行？
导语：此前小编发了一篇《Scrum敏捷价值观与原则》阅读量杠杠的，发现产品汪们对这种开发方式还是很感兴趣的。 so,小编又去挖掘了一篇老文章，《为什么Scrum不行？》 如果还不知道Scrum敏捷开发的朋友们，同理，还是请出门左转，点击 Scrum 了解下。 以下是原文中提到的9个Scrum不行的理由。除此之外，作者陈皓在里面加入了自己的分析（感谢陈皓提供的精彩内容）。 Reason 1: Scrum的基石是相信人。创造一个安全的环境，这样每个人都能相互学习，相互直言。但是，这是不行的，这世上有很多人并不关心这些，而且政治和竞争到处都是，办公室里无小事，你和别人交心，你相信他们，最终受伤的你自己。你真的以为那里有空间让你可以去犯错，去冒险吗？ Reason 2: Scrum认为只要给员工足够多的自由员工就能做得最好。这该死的理论是基于什么玩意？不可能，人的天性是懒惰的，他们才不会把事做好的，他们只会做相应报酬的工作量，还可能基本甚至达不到其相应的报酬，大多数人都在混日子。尤其是和经理比起来，谁不想能尽快地成为经理或Team leader啊，因为那样他们就可以即不干活，又挣得多。另外，你给他们自由，你就会发现，他们会只会做他们感兴趣的事，要么聊QQ，要么打游戏，看闲书，反正不干正事。直到你催了，他们才动一动。 Reason 3: 因为前面的原因，所以，我们仍然要把一个PM放在Scrum团队的上面做管理，这样才会有产出。于是，PM给团队分配任何，管得细枝末节，事无巨细，天天让你做进度汇报，等等。直至把团队拖垮。 Reason 4:Scrum只不过是一个流程。这世上有太多的流程，尤其是那那些执行CMMI的公司。几乎所有玩CMMI流程的公司，你都能看到的是员工都是那一副副难看的脸。所以，Scrum的流程同样会这样。因为这些都不是开发团队自发出来的，而是上面管你喜欢不喜欢按给你的。Scrum根本不可能增进你的软件质量和技术，只能是优秀的人才才可能！使用Scrum的公司都是些吝啬鬼，他们不愿花大钱招优秀的人，他们妄图使用Scrum这种东西让现有的这些廉价劳动力发挥更大的生产效率，Scrum成了push程序员最有用的工具。 Reason 5:Scrum delivers ‘business value’。不是这样的，实际上，Scrum不可能。这有很多原因。真正了解业务的那帮人根本不可能加入项目团队，那些人谁TMD愿意和苦逼的技术人员加班啊。 那些人喜欢和我们的用户吃吃喝喝，花天酒地的，根本不会和你们那些奇怪的东西（如：backlog）或是那堆ugly的内向古怪的技术人员打交道，更别说什么技术了。所以，你的团队就像一个客服团队或救火队一样疲于奔命。 Reason 6: 一个敏捷的团队应该是持续进步的。这就是为什么Scrum总是在问什么干得好，什么需要改进，并定义行动方案。你真的以为员工想进步吗？让他们不得不去想想自己和团队怎么进步，然后他们还不得不去执行行动方案。别天真了，人的天性是不喜欢改变的，人的天性是习惯于一些按部就搬的事，也许那样做令人讨厌，但是人家还是能干点东西出来。如果你逼着人家改变，你就是在压迫人家，人家自然会反抗。 Reason 7:Product Owner专注于 ‘what’ 和 ‘why’ 的问题，开发团队决定 ‘how’。很不错的分工，于是可以造就一个即高速有重质量的团队。然而，这根本不行。你的Product Owner马上就想要这个功能，他才不管你的软件开发的技术难题，人家只要快，要你meet deadline，要你给我们重要的客户做出承诺。另外，你千万不要以为你们可以轰走这个初级的product owner，因为他的后台是直接汇报到高层管理。你作为一个程序员可能只是其个小部门的一个小喽啰，或者只是外包公司，你觉得可能吗？你觉得建立信任可能吗？ Reason 8: 软件质量和生产率成正比。也就是说，质量越高，生产率越高。如果质量不高，你开发效率就会低下，但是谁管呢？我们朝九晚五的上班，质量好了也是做8小时，质量差了也是做8小时，无所为嘛。另外，我们的project manager (或者是Scrum master!) 总是会批评我们没有按计划完成。所以，这根本不可能。 Reason 9: “是的，如果我们只做需要的功能，那么我们就会最低的成本，对吗？”，为什么这世上总是会有这些幼稚的人？这种事怎么可能啊。很多很多的银行或保险公司的项目在你还没有启动项目前就谈好了一个价格（可能还会有回扣），为了打单子，销售什么都干得出来，让你去做项目是因为你是廉价劳动力，而且，他们会不断地加需求，因为软件合同谈好的价格时候，连需求都没有，你去做了才有，还是模糊和不确定或根本就是错的，然后需求是越来越多，越改越多。等你精疲力尽的时候，你才意识到，销售早就把你卖了。 有人看到这篇文章后也分享了团队实践Scrum后的心得，他觉得在他的团队里不适用Scrum有几个原因： 1.大家对技术不熟悉，因为目前主要的工作量在前端。大家以前都是做java后台的，对js不熟悉，把js当作java来面向对象。而且没有一个成熟的控件库使用。 2.没有在项目开始前做足够的技术调研。本来，应该有个architector来做这些事情。我觉得什么TDD，就是胡扯。没有前期调研，什么都是假设我们能做到，然后就去break down,然后就是估时间，只能是瞎估。估完了，真正implement的时候才发现，一堆东西stand in my way。 3.人的本性就是利己。如果一个team的performance，不和salary挂钩，大家凭什么会齐心协力，deliver更快，更好。目前情况下，scrum只是pm push developers的工具。现在，大家都想到偷懒的方法，就是尽量多估一些时间，或者implement的时候粗一些，反正都是一个个task领的，谁知道bug是谁的code导致的。以前如果一个人responsible for one module,就很容易知道谁的代码质量不高。 4.user story 拆分的不好，容易漏掉很多东西。大家现在都关注task,只想着做完就拉倒，根本不会想着各个task之间的边界和交叉影响。而且，大家现在就习惯看看task就做了，根本不会去看case,所以有些重要的flow全都漏掉了。 5.pm就是scrum master,整个team就是在一个不平等的环境下，scrum只不过是pm试验的工具，能在她的简历上添砖加瓦。我们只不过是小白鼠。 另一种观点认为，Scrum适用于一帮资深程序员组成的team，每个人都是牛人，每个人都有激情干活，这样才work。在国内大家只是干活拿工资，没什么激情，很不适合Scrum。 Scrum就是一把双刃剑，如何用、是否合适还是要看具体的情况。那么，您的团队是否采用过Scrum模式，效果如何呢？ 英文原文出自：《Why Scrum will never work》（很抱歉原英文链接小编已经找不到了，如果有哪位找到了这篇原英文链接，请告诉小编哦！） from:http://www.woshipm.com/pd/85814.html
View DetailsScrum敏捷价值观与原则
Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。如果还不知道Scrum敏捷开发的朋友们，请出门左转，点击 Scrum 了解。 敏捷价值观 个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客服合作 高于 合同谈判 响应变化 高于 遵循计划 敏捷的原则 1.我们最重要的目的，是通过持续不断地及早交付有价值的软件使客户满意。 2.欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。 3.经常的交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 4.业务人员和开发人员必须相互合作，项目中得每一天都不例外。 5.激发个体的斗志，以他们为核心搭建项目。提高所需的环境和支援，辅以信任，从而达成目标。 6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 7.可工作的软件是进度的首要度量标准。 8.敏捷过程倡导可持续发。责任人、开发人员和用户、要能够共同维持其步调稳定延续。 9.坚持不懈的追求技术卓越和良好设计，敏捷能力由此增强。 10.以简洁为本，它是极力减少不必要工作量的艺术。 11.最好的架构、需求和设计出自组织团队。 12.团队定期地反思如何能提高成效，并依次调整自身的举止表现。 参考文献 《Scrum要素》作者：Chris Sims & Hillary Louise Johnson from:http://www.woshipm.com/discuss/84052.html
View Details