编辑日报内容...什么是敏捷开发

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；

为什么说是以人为核心？

我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

什么是迭代？

迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

关于Scrum和XP

前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。

什么是Scrum？

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。

【Scrum开发流程中的三大角色】

产品负责人（Product Owner）

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

流程管理员（Scrum Master）

主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）

主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

个人理解：在过去的瀑布式开发的固定模式下导致产生大量的文档与不必要的工作量，增加了时间成本拖长了项目的周期已经不适合时代的需求，在这种情况下敏捷开发应运而生，减少文档流以及时沟通反馈避免在不必要的细枝末节上消耗太多的时间，这样来开发项目会更加具有效率同时提高执行力。

2.如何做需求分析？

用户需求是用户从自身角度出发，自以为的需求。

用户经常提出的需求，从他们角度而言都是正确的，但更多是从自身情况考虑，对于产品的某个功能有自己的期望，但对产品定位、设计的依据等情况不了解，他们的建议也许并不是该功能的最好实现方式，也就不足以直接作为产品规划的直接依据。

产品需求是提炼分析用户真实需求，并符合产品定位的解决方案。

解决方案可以理解为一个产品，一个功能或服务，一个活动，一个机制。

我们不能简单地看用户需求，而是应该去挖掘用户产生这个需求时，其心里是什么驱动着用户。

所以，更应该思考，需求分析的过程，是如何把用户需求转为为产品需求，中间的纽带是什么？

理解：在做需求的时候从产品的行业与用户出发，产品为用户提供有吸引力的东西，在制作产品的时候站在用户的角度来思考，从用户的角度出发，挖掘用户的需求，并转为为产品。

3.Bug的优先级

对事情进行轻重缓急的分类，是人类生存史上的重要支柱。

Bug的优先级用来标志Bug的严重程度，以便用于在Bug修复和上线之间提供决策支持。

通常会分成以下几种。

critical

block

major

normal

minor

五种级别的划分，并不是单纯的12345分级这么简单，而是分别对应有它自己的含义。

Critical的Bug是最严重的，代表着系统崩溃，完全不可用。这种Bug出现，就是最严重的事故，完全打不开，比如说，网站无法访问，点击出现系统错误，直接跳转到404页面。

要注意的就是，Bug的严重程度和它易于修复的程度并不总是一致，举个例子，当用户打开修真院网址的时候发现打不开，这是非常严重的，Critical级别的Bug。最后发现原因很简单，域名过期，解决方案也很简单，就是交钱续费而已。

一个系统是否能正常运行，并不在于导致它不能运行的问题复杂或简单。

Block的Bug也是非常严重的，它的含义是，用户的操作被卡住了，无法进行下一步。系统并没有大规模的崩溃，而是无法进行到下一步。拿12306来说，当你选好车票的时候，想要点击购买，这个时候却发现购买按钮点击之后无法使用，而其他的一切功能都正常。

这就是Block级别的Bug，一个地方卡死，导致你无法进行下一步的操作。

通常，在线上出现的Critical和Block，都可以称之为事故了。

Major的Bug是严重的，也是在Bug体系里的一个分界线，绝大多数团队在初期的目标，都应该是在提交测试之前，完全消除Major级别的Bug，减少Normal级别的Bug数量。

Major的Bug通常是指流程可以走的通，但是关键的业务或者是数据错误，影响用户的正常使用。比如说，在修真院的师兄弟体系中，你加入了班级，按理来说应该分配一个师兄。你按提示完成操作，但是却没有被分配到任何师兄。

这种级别的Bug往往是不没有任何操作流程上的问题，但是就是和预期的结果不对，而且影响了用户的正常使用，特别是在关键业务逻辑上。

Normal的Bug就比较常见了，像一些分支业务逻辑里，偶尔会出现的问题，又或者是一些不太重要的地方出现的错误。通常我们知道他是一个Bug，但是对大部分用户来说都无关紧要，可以用，可以不用，我们知道他有Bug，噢，没关系，我可以等等。

Normal的Bug应该被控制数量，我们建议的数量，是在开发人员提交测试之后，不超过3个。

Normal的Bug通常情况下都很容易被发现，不需要花太大的力气去寻找。

Minor的Bug，指那些无伤大雅的小问题，通常是指兼容性，不重要的文案错别字，样式错误等。

以上五种Bug级别，分别对应了在系统中对用户使用时候的影响度。

理解：如果在影响客户使用与体验的bug要立刻修复，这种bug是不允许流出的，如果只是一些小的bug可以在下一个版本进行修复。在产品面对这些问题时需要知晓事情的轻重缓急来做出判断。

明天计划的事情：开始任务2 

遇到的问题：任务中的问题倒是没有遇见，看了一下深度思考倒是发现好多知识需要掌握，任务2就开始接触产品的知识了期待

收获：知晓测试用例流程与方法，了解了什么是敏捷开发，如何做产品需求，bug的生命周期