今天完成的事情：

完成任务一深度思考

明天计划的事情：

开始任务二的部分内容

遇到的问题：

敏捷开发是一个特别大的概念，理解了很久，按自己的理解又重新整理了一遍，耗费了比较久的时间，目前来说仍旧不是特别全面，希望在以后的学习中可以加深理解

收获：

1.什么是敏捷开发? 

敏捷开发，个人认为就是一种强调去文档化、去流程化，追求高效沟通和合作的开发方法

目前主流的敏捷开发有五种方法，本次主要谈谈scrum

scrum本意是橄榄球赛，意味着一种多人协作围绕产品或目标高效工作的模式。

scrum中的主要角色有三个，Product Owner（产品负责人） Scrum Master（流程管理员） Development Team（开发团队）所有活动和流程由这三个角色展开

对于PM而言，展开scrum工作，首先要由PO（通常由PM担任）确定product backlog，然后确定sprint周期，将product backlog中的需求按商业价值排序，选择部分需求（根据sprint周期和人员情况控制数量）建立sprint backlog，但是PO不是完全懂技术的啊，于是SM上场了，SM需要帮助PO对产品的需求进行分解，划分成各个开发任务。等PO和SM确定好开发任务，再与整个开发团队开会商议其他要补充需求、功能点、预期时间等等事项，最后由PO整理需求列表、整理需求预期时间、完成故事版和故事版中的事项、制作燃尽图。

大致流程图如下：

确定backlog

确定sprint周期

按商业价值建立sprint backlog

与scrum master分解需求，确定开发任务

与scrum团队讨论功能点

整理需求列表、整理需求预期时间、完成当前故事版、制作当前燃尽图

你以为工作到此为止了吗？太天真了，以上只是准备流程，开发还没有正式开始。正式开发过程中，还有三大会议要开

每日例会，会议内容主要是各成员的昨日总结、昨日进度，汇报任务流程，目的是检验当前sprint进展，及时作出调整，优化次日工作（哦对了，别忘了更新故事版和燃尽图）

sprint评审和计划会议，目的是检验总目标的当前进展，以便及时做出调整，优化下个sprint工作（上一个括号再念一遍）

sprint回顾会议，目的是总结反思本次完成的总任务，为进行下一次scrum做好准备

scrum的开发过程切记

a.保持高度透明性，要让所有人互相了解彼此的工作进度

b.要进行频繁地检验，确保及时发现进程中的重大偏差

c.一定要及时进行调整

说了半天，那scrum有什么特点呢？

a.迭代开发，每代开发的产品都可以直接投入使用，不再是传统模式需要全部完成才能开始上线的模式

b.增量交付，增量即现阶段所有sprint可使用功能的总和，等到全部sprint结束的时候，增量要等于完成

c.自组织团队，传统的模式团队成员都是执行方，而scrum成员要共同负责设计、计划、执行的工作，分工协作

d.高优先级的需求驱动，因为建立sprint backlog的时候就是按需求的优先级选择的，高优先级永远是现阶段sprint的驱动动力

2.如何做需求分析？

用户肯定会有自己的需求，但是这部分需求是否真的符合产品需求？真的能转变为产品功能？这个不好说。如果让用户描述需求，可能生产的永远都是马而不是汽车。怎么才能判断用户需求是否符合产品需求，或者说要如何把用户需求转变为产品功能，这个过程就是需求分析。

需求分析最重要的就是要先从用户的动机入手，找准目标用户群体，找到目标用户的真实需求，然后考虑需求的受众面，使用程度、需求强烈程度、是否符合产品定位和当前规划。

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

程序员写出bug是没办法避免的，如果bug影响程序上的运行，那必须先进行修复再上线，如果bug优先级较低，应当先上线再后续进行修复

4.边界测试，功能测试，冒烟测试，黑盒测试，自动化测试，回归测试，性能测试的含义分别是什么，应该谁来主导，原因是什么？ 

边界测试：如果输入条件给了一定范围，测试的时候取范围边界或者超过边界的值进行测试，来判断有无bug

功能测试：对产品的各功能进行测试，根据功能测试用例逐步检测，看有无bug

冒烟测试：强调程序的主要功能，只对基本功能进行测试，耗时短

黑盒测试：通过测试检测每个功能是否都能正常使用，主要注重于软件的功能需求，而非逻辑结构

自动化测试：在预设条件下运行系统或应用程序，评估运行结果，需要注意的是，预设条件应包括正常条件和异常条件

回归测试：修改了旧代码以后，重新运行检测，看有没有出现新的错误

性能测试：通过自动化的测试工具模拟多种正常、峰值、异常负载条件来对系统的各项性能指标进行测试

如果有专门的测试人员，应由测试人员负责。

5.Bug如果长时间未得到解决，应该怎么处理？做为PM，是否应该推动Bug的解决，如果PM成Bug的推动者，会不会导致开发人员越来越不主动？

为了项目可按时上线，作为PM，适当推动bug解决是必须的，但是不能经常推动

6.怎么样判断Demo是否应该通过?  

程序可正常运行，不影响使用。

7.常用的Bug管理工具有哪些，互相之间有什么差别，你更喜欢哪一种，为什么？ 

easybug  禅道 QC  bugzilla  mantis（百度所知）

https://blog.csdn.net/haiyinshushe/article/details/81909714里面有差别

8.为什么要区分开发，测试，线上三个环境，三个环境之间的区别是什么？分别由谁来主导？

开发环境：程序员写代码的环境，代码可随意修改，相对来说比较随意。程序员进行主导

测试环境：程序员写完代码上传到测试环境，由PM和测试进行验收，检查出bug再回到开发环境进行修复。测试或PM进行主导

线上环境：发布环境，要求不能有任何bug，线上环境如果出现bug，优先级始终排在最高级。用户主导

9.什么是版本回滚，在发布上线的过程中，如果发布不成功，多久之内应该要回滚，谁来决定，原因是什么？

程序或数据处理出现问题，将版本恢复到上一版的状态。在造成较大影响前，必须要回滚。由PM决定

10.什么样的Bug是允许上线的，什么样的Bug是不允许上线的？

建议修改类的bug允许上线，核心功能无法正常运行的致命bug不允许上线

11.Bug的优先级是什么？一般会分成几个级别，分别对应什么含义？

immediate 马上解决，问题必须马上解决，否则系统无法达到预期需求

urgent 急需解决，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常

high 高度重视，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现

normal  正常处理，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，

low  低优先级，问题在系统发布以前必须确认解决或确认可以不解决

12.Bug的生命周期是怎么样的？什么情况下应该是Reopen？什么情况下去Close？

new（新的）   assigned（已指派的）  open（打开的）  fixed（已修复的）    pending reset（待再测试的）  reset（再测试的）   closed（已关闭的）   reopen（再次打开的） pending reject（拒绝中）

再次测试之后又发现新bug，需要reopen，等到完全没有bug的情况下可以close

13.什么是测试用例，为什么要写测试用例，测试用例中的前置条件是什么？预期结果是什么？一个登录注册的小模块，正常来讲，应该有多少个测试用例？

测试用例： 将系统的具体操作步骤用语言描述出来，提前进行测试

前置条件：要达到预期目的，需要满足什么条件才可以执行步骤。

预期结果：前置条件下，进行步骤操作，所期望或预想到的结果

注册状态下：注册用户名是否合规、是否已注册、密码是否符合要求

登录状态下：账号是否合规、密码是否合规、账号密码都正确、账号正确密码不正确、账号不正确密码正确

14.什么是产品经理?

负责从产品设想到产品终结期间所有产品活动的角色