异步任务异步任务又是什么东西？在我们前面的学习中讲过一个全局变量的问题，当时我们给服务设置了一个 worker_num 属性，这是一个工作者进程的设置。设置了这个参数，然后启动 Swoole ，通过 ps 命令就可以查看到运行的程序多了几个进程。现在，你应该就能明白到了 Worker 其实就是一种子进程
WebSocket服务对于 Web 应用来说，最主流的当然就是我们之前学习过的 Http、TCP、UDP 这一类的应用。但是，最近这些年，特别是 HTML5 成为主流之后，WebSocket 应用日益丰富起来。要知道，之前我们在做后台时，如果要做消息通知之类的应用，全都是使用 JQuery 来进行轮询的
其实在上篇文章中，我们就已经运行起来了一个 Http 服务，也简单地说明了一下使用 Swoole 运行起来的服务与普通的 PHP 开发有什么区别。想必你现在会说这没什么大不了的呀，这些我们的传统开发又不是做不到，而且还更方便一些。在基础篇章中，我们还不会看到 Swoole
在对 Swoole 有一个初步的印象之后，今天我们就来简单地搭建起 Swoole 环境并且运行起一个简单的 Http 服务。大家不用太有压力，今天的内容还没有太多理论方面的东西，一步步地一起把运行环境先准备好，能看到 Swoole 运行起来的效果就可以了。
在Swoole的世界中，你将学习到什么？在接下来的学习中，我们将要接触到的，将是 PHP 扩展中非常出名的一个高大上的框架，那就是 Swoole 。或许你已经在生产环境中使用过了，或许你只是看过官方文档写过几个例子，当然，更有可能你只是听过它的名字。不用太担心，通过我们的学习，你将会掌握到基本的
恭喜大家，当然也要一起恭喜我自己，又是一个大型的连载系列完成了。前前后后差不多也有半年时间，对比技术类的文章来说，项目管理这类理论学科的内容其实会更难写一些。一是篇幅不像技术类的文章好凑，贴几段代码文章就会显得很长；二呢也是需要参考很多的资料
在学习完风险、问题之后，我们再继续学习一个简单的内容，是和 QA 有关的缺陷、质量方面的内容。关于这一点，又要搬出 PMP 了。在 PMP 中，质量管理也是一个非常重要而且非常大的章节。是范围、成本、进度三大知识领域外最最重要的一个知识领域。还记得在开篇文章中我们讲过 PMP 有
风险，一般来说会是我们预估的，可能会发生的“问题”。而 问题 ，则是已经出现并且放在你面前的麻烦事。不管你做任何事，做任何项目，风险有可能发生，也有可能不会发生，但问题，你一定会遇到。有的问题在成为问题之前不一定会是风险，因为可能你都没有察觉到它，它就出现了。
在 PMP 中，风险是一个重要的章节，并且有许多的过程，比如说我们要识别风险、进行定性定量分析、应对风险等，工具方面也有决策树、敏捷性分析等，最后还有一个风险应对和机会应对（PMP认为风险和机会是对应的）。这些内容其实是相当有意思的，不过这并不是我们在敏捷中学习的重点。
在敏捷团队中，我们一直会说没有项目经理，而传统的项目经理这个角色，更多的会体现在敏捷教练这个角色中。对于传统的项目管理，项目经理要管理团队成员，管理项目计划。而在敏捷团队中的教练，则更多的是一种服务式的领导，很少有管理成分。当然，并不是说完全没有管理，只是我们认为领导力会更优于管理
在传统企业中，要想达到高绩效，往往是需要非常多的管理过程参与。也就是说，我们会制定许多的规则、制度以及奖惩措施，并通过各种激励手段来达到让团队努力冲冲冲的干劲。而在敏捷中，我们提倡的是自组织、自管理的团队，而且从头到尾，我们也一直强调 SM 要以领导的方式来带领团队，而不是管理。
前面讲了很多东西，是不是都感觉和 PO 有很大的关系。但其实 SM 也是一直贯穿其中的，当然，这也是敏捷中最重要的部分。因为我们要将有价值的内容给客户，那么如何识别价值，如何与相关方合作，如何进行敏捷规划都是决定一个项目产品的关键。剩下的还有什么呢？别忘了，敏捷中还有非常重要的一点，那就是“人”。
上篇文章用大量篇幅学习了敏捷中计划的概念以及用户故事的估算，毕竟都是新东西，所以大家还是要好好消化消化。今天我们主要学习的是敏捷计划的具体实施以及敏捷的适应问题。适应其实是针对于计划的变动、修改方面的相关内容。
我们已经准备好了用户故事，也了解到了用户故事的一些相关的知识。这个时候，就要开始敏捷计划的制定。我们将学习到一系列的概念和方法用于敏捷中计划的制定。或许他们和 PMP 中关于计划的概念和形式有很大的不同，但这也是敏捷和传统项目管理最典型的区别。
经过上一篇的学习，你对用户故事有了一个大概的了解了吗？用户故事这个东西，是需要多多练习的，并且最好是有经验的 Scrum Master 能够带着你一起学习并建立合适的用户故事应用到实际的项目开发中。对于用户故事来说，我们还有一个层次的概念以及用户故事地图的概念
一看到这个标题，是不是感觉马上就激动起来了，自从讲完敏捷框架之后，我估计大家最激动的地方就在今天这篇文章了。用户故事这个东西吧，现在已经是在敏捷中用来描述需求的通用工具了。但凡提敏捷，必须要问用户故事。之前我们学习过的 待办事项列表 ，迭代冲刺事项列表 之类的内容，记录的都是用户故事。
这篇文章的内容我觉得会比较有用，怎么说呢，我们即将学习到的都是可以在日常工作生活中应用到的，而且马上就可以尝试的内容。而且，从我工作这些年的经历来看，会说话，会沟通的人真的是自带光环属性加成的。
讨论完相关方参与和愿景规划之后，我们就来到了如何管理相关方参与。前面已经说过，用“管理”这个词在敏捷中是不恰当的，因此，我们用增强相关方的沟通和协作来说会更好一些。既然是沟通和协作，那么必然就要学习一些工具技术来帮助我们实现增强的目的。今天的文章主要来讲的就是这些工具和技术。
对于敏捷来说，相关方是可以包括任何与项目有关的人的。也就是说，不管是客户、用户、高层领导、甲方员工，只要是与我们要进行的项目有关联的人都是相关方。在 PMP 的十大知识领域中，有一个 管理相关方 ，但是从敏捷的角度来看，我们与相关方应该是相辅相成的，所以，用 “参与” 会更合适些。
在学习了评估价值和为需求排定价值优先级的一些方法之后，我们接下来就看看在迭代或者冲刺中应该注意些什么才能不枉费之前的努力。毕竟前期花了那么大的精力，但是迭代冲刺之后却提交了一个没什么价值的产品，那可不是所有人愿意看到的结果。
Laravel Swoole 设计模式 算法 数据结构 PHP基础 Nginx 压缩 缓存 性能 命名空间 信管师 Redis MySQLi 迅搜 MQ 消息队列 MySQL PHP 谷粒商城 加解密 PDO PHP数据库 时间日期 文件操作 国际化 GD库 图片处理 PHP SPL CURL Composer PHP魔术 PHP框架 ACP 敏捷
