关于任务一的深度思考

关于敏捷开发：

敏捷开发是一种开发方法，更是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发，这种开发方式的主要驱动核心是人，它采用的是迭代开发。

以人为核心：敏捷开发注重人与人之间面对面的交流，所以它强调以人为核心。

                    而传统的瀑布开发模型流程是：需求分析>>设计>>编码>>测试>>交付

                    在该流程下，居于核心的就是需求分析。一旦需求分析出现大的偏差，之后的设计、编码、测试，即使做的再好，也是徒劳。

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

Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；指一个开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它

如何进行Scrum开发？

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

关于如何做需求分析

需求是人类欲望的满足。这种满足既包括人类的动物性，也包括人类的社会性。

人类的动物性：最基础的包括食色，就像人们常说的食色性也，也包括占有欲、控制欲等（这点因人而异）

人类的社会性：包括人类社交的需求。被人尊重的需求等

经典的马斯洛需求理论：

分析需求离不开三个要素：人、场景、角色   即谁在什么样的场景下要做什么。

怎么理解程序员会写出Bug这种事情，可不可以要求他们做到无Bug交付？怎么衡量Bug的修复时间和项目的上线时间冲突问题？ 

这很正常呀，Bug产生的情况如：写代码过程中难免会有写错的时候；需求理解偏差；前后端等衔接磨合难免会有冲突；用户不按常理出牌；需求发生改变等等，没有bug似乎不太正常呢。

无bug交付，emmm 反复提bug改bug后，应该可以实现吧，但是一旦环境或者需求发生变化，又会有新的bug出现吧。

bug的修复时间和项目上线时间冲突   emmm   那是不应该先评估bug的级别，一般的不影响功能的，不造成重大损失的bug的话，可以先上线，那当然问题很严重的bug还上线毛线呀，赶紧改bug呀。

这就用到bug五种优先级：

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

Block的Bug也是非常严重的，它的含义是，用户的操作被卡住了，无法进行下一步。系统并没有大规模的崩溃，而是无法进行到下一步。

Major的Bug通常是指流程可以走的通，但是关键的业务或者是数据错误，影响用户的正常使用。

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

Minor的Bug，指那些无伤大雅的小问题，通常是指兼容性，不重要的文案错别字，样式错误等。这种Bug上原则上的修复时间看开发人员的空闲期。

边界测试，功能测试，冒烟测试，黑盒测试，自动化测试，回归测试，性能测试

边界测试：探测和验证代码在处理极端或偏门的情况会出现什么，边界包括输入输出的边界，数据结构的边界，状态转换的边界，功能界限的边界或端点。

冒烟测试：是在软件开发过程中针对软件版本包的快速基本功能验证，主要目的是快速验证软件基本功能是否有缺陷。

功能测试：对产品的各项功能进行验证，检查产品是否能够达到用户要求的功能。

黑盒测试：检测每个功能是否能够正常使用，与功能测试相似。

自动化测试：在预设条件下运行系统或者应用程序，评估运行结果，预设条件包括正常条件和异常条件；应用自动化测试应满足以下条件1）需求变动不频繁2）项目周期足够长3）自动化测试脚本可重复使用。

回归测试：指修改了旧代码后，重新进行测试以确认修改没有引进新的错误或者导致其他代码产生错误；选择回归测试策略应兼顾效率和有效性两个方面，常用方式有以下四种1）再测试全部用例2）基于风险选择测试3）基于操作剖面选择测试4）再测试修改部分。

性能测试：指通过自动化测试工具模拟多种正常、峰值以及异常负载条件对系统的各项性能指标进行测试，包括负载测试、压力测试、容量测试、基准测试、性能配置、争用测试等；目的是1）评估系统能力2）识别体系中的弱点3）系统调优4）检测软件中的问题5）验证稳定性可靠

其实关于这几个测试还是不算很明白，后面慢慢再深入了解吧