今天学习任务：

做完任务一，学会写测试用例，进行测试，找出bug，深度思考

深度思考

以下问题均为个人理解：

1，敏捷开发：以人为核心、迭代、循序渐进的开发方法。不是一门技术

      以人为核心：尽量减少文档，只需要写有必要的文档，注重人也人之间面对面交流，强调以人为核心，开发不是一个人完成的而是一个team，只是分工不同。出了问题是整个小组的责任。

在敏捷开发中需要每个人思路必须清晰，清楚自己要做什么。进入开发阶段项目成员需要跟进和控制项目进度减少风险，主动测试项目中出现的问题

迭代：我自己的理解为在接到一个项目时需要按照优先级分为多个模块，先把主要的模块做出来并上线，后边的次要模块根据优先级逐步开发上线。

2，用户需求分析：使用对象、使用习惯、场景、动机、用户属性、使用哪些功能、期望。如果脱离了这些就会出现‘伪需求’这时就要想清楚产品目标以免出现功能叠加。学会判断伪需求（判断是否是目标用户的需求、是否是普遍的需求、是否与产品定位相符）

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

程序员会写出bug：这个问题是有多方面的，有可能是程序员粗心大意，代码逻辑不严谨、有可能是程序员理解能力不够、有可能程序员技术能力不够、有可能pm原型图描述不明确，逻辑有问题、有可能双方在沟通上出现问题，不在一个频道上哈哈等等。。。。。

做到无bug交付？一句话概括：世界上没有十全十美的事情。即便是有那也是少之又少

衡量修复与上线时间：先修复影响正常使用的主要bug按时上线，在逐渐修复不影响使用的次要bug，但是也要尽快修复不要拖太长时间。

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

   Bug长时间未那就催促抓紧解决或者加在下一个迭代模块里。个人觉得pm不应该推动bug解决，不应该做这个推动者，因为解决bug问题是程序员的职责，如果一个程序员需要靠Pm去催促推动解决bug那这个程序员可以去天堂度假了。

明天任务

今天时间太晚了，明天继续把深度思考其他的问题搞明白，做任务二