昨天提交测试用例文件完成任务一的
（任务提交）任务结果上传到百度网盘，在任务详情页点击“提交任务”按钮进行提交。

今天完成的事情：
完成任务1下第三部分深度思考环节（个别），完成方法有百度/小课堂/知乎/日报

• 1.什么是敏捷开发?  点击查看相关小课堂
  
• 百度告诉我们

敏捷开发

 编辑 讨论

恕我愚钝不太明白再看下面一个词条

敏捷开发模式_百度百科

https://baike.baidu.com/item/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91%E6%A8%A1%E5%BC%8F/8395733?fr=aladdin

敏捷开发模式

 编辑 讨论

敏捷开发模式是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

有点明白了，是一种软件开发方法，快速应变需求的能力。是以人为核心，强调团队与需求专家之间的紧密协作、面对面的沟通，频繁迭代，适用需求变化的团队组织方法。简而言之就是，需求随时变化，产品随时迭代，人高速理解迭代需求，进行产品迭代的思维理论模式。

这里还了解到敏捷开发的起源及其他开发方法的优劣

软件的开发方法依次以下四个时代   1970瀑布模型---迭代式开发---1988年螺旋开发---1990年敏捷开发
四者对比区别：
传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。
特别是前期阶段，设计的越完美，提交后的成本损失就越少。
迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，
最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。
螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。
敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化

点击小课堂，

五、参考文献
你大概走了假敏捷：认真说说敏捷的实现和问题
https://www.qcloud.com/community/article/766331

在这里我了解到了

敏捷的起源：有十七个程序员（程序员改变世界）在美国犹他州的一个风景区开了个碰头会，找到了一个团队耦合度高，流程极其灵活的方法，他们把它称为agile program development。这十七个人如同开宗立派的长老，在会议之后给自己起了个名字“敏捷联盟”，他们不仅赋予了新方法名字，还有宣言，甚至纲领。

中文版的“敏捷宣言”。在建立于2002年3月的 《Manifesto for Agile Software Development》里你可以找到几十种语言的“敏捷宣言”

显而易见，敏捷是绝对的结果导向，去文档化，去流程化，高效沟通和合作是究极奥义。
看起来是个很不错的方法，文档不重要了，流程不重要了，大家聚在一起说一说就可以了不是吗？太棒了，感觉可以从繁重的文书工作中解脱出来了呢。
失之东隅收之桑榆。一处的方便一定意味着另外什么地方以其他方式运行着简化掉的部分。
去文档，敏捷管理者需要维护更为精细的需求池；去流程，口头沟通成为常态，对团队的耦合度要求更高

敏捷概念（关键词）：名词听起来都玄乎乎的，很符合开宗立派的气质。这些概念定义了敏捷各个环节的工作，这些流程和节点是敏捷开展的基础和保障
agile：迅速，敏捷。这是敏捷的理念也是精髓：迅速响应需求，快速反馈结果
sprint：字面意思是短跑冲刺，一个开发阶段被认为是一次冲刺，一个个 sprint 首位相连，构成一个项目
Scrum:指的是英式橄榄球中一股脑争球这一战术或行为
Product Backlog:backlog 即需求池。待办事项列表
story board:很多领域都有故事板的概念，交互领域里，用故事板表述用户场景、电影领域里故事板用来更具体地描述分镜。在开发领域，故事版是任务流转的可视化窗口，一般有“待开发”“开发中”“待测试”“返工”“待发布”几个区块，所有任务由任务操作者负责流转至于下一个步骤，这样任何一个人项目成员都能看到任务的完成情况
burn down chart：燃尽图。一个 sprint 内，人/时是一个比较固定的值。在这个时间框架充分安排开发任务，每天进行时间结算，绘制时间燃尽图。项目成员通过燃尽图获知时间进展，若项目燃尽所用时间与预期时间契合，则需求时间预估和安排合理，若不契合则需要在下一个 sprint 进行调整。

敏捷工具：（国外jira、redmine，Axosoft ，国内的leangoo 、禅道，三大家则都有自研的工具，百度的icafe，阿里的aone，我鹅自研tapd）

PM在敏捷开发里面做什么：
一种思路是，设计拥有自己的敏捷流程。设计师作为一个 scrum 存在，以从上游获取的需求进行 sprint 。
另一种思路，是把设计和测试完全纳入到团队中来，一起进行 scrum 的合作，这样的话，UI工作至少要比开发工作前移至少半个 sprint 。

敏捷开发去文档的定义：

从短期收益上看，文档对于敏捷开发是非必须品，并且很有可能会拖慢进度。在一个 sprint 中，口头沟通显然效率更高，每个人都有精确到工时的任务，没人有等待文档更新的时间。强调文档就等于放弃灵活性
从长期和宏观上看，文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本，同时降低错误的发生概率。对于一个将要长期实施敏捷的 团队来讲，文档让后续的工作效率更高

我们挑选几个重要的文档：产品文档、概要设计、接口文档
产品文档包括：1.需求；2.加入日期；3.开发版本；4.呈现和详细方案
概要设计：敏捷的常规迭代中，概要设计不是一个必须的文档。但全新项目、重构以及重大新功能则必须输出概要设计文档。研发 leader 责无旁贷，这个落你身上了。
接口文档：必要且重要。包括接口说明、字段定义、字段类型、值定义、数据上报、错误码等。一般来说约定之后由接口开发者更新文档，如果你们没有云端存储的能力，至少咱们人手一份，定期更新。

总结本文重点：
1.敏捷是一种流程、方法、理念，甚至信仰。
2 用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作，线上的的流转如果削弱了这种配合性，反倒背离了敏捷的本意。实际上只要有白板纸张和笔，你的团队就能开始敏捷。
4.我们敏捷了，不是不要文档了。在外部交流多、世代跨度长的情况下，文档的必要性显而易见。长期的面对面沟通最终会导致低效，这也是敏捷缺陷的根源。
5.设计师可以完全介入到敏捷流程中，只需要做一些细心的安排。
6.大项目开发中可以走敏捷，具体问题具体分析，需要根据项目特点制定敏捷计划。

知乎查询敏捷开发

这里有对敏捷开发的描述定义，2011年修改至今，也可以了解到敏捷开发拓展话题的

十年敏捷开发最佳实践Live

内容大纲
 1 为什么需要敏捷开发 
 2 敏捷开发流程中有哪些工具可以使用 
 3 从零开始认识敏捷开发中的角色 
 4 产品经理/UI 设计师/后端工程师/前端工程师/测试工程师/运维工程师 
 5 敏捷开发的流程有哪些 
 6 产品设计阶段（ PPT/Story/原型/测试用例/需求评审/需求讲解/分期和迭代) 
 7 研发阶段（ leader 的职责/设计方案/晨会/MiniDemo/每日部署/环境/晨报/CodeReview/性能测试/Demo/燃尽图/Task/延期风险/接口文档/UI 自测表/打包和部署) 
 8 测试阶段(Bug 的级别/发布/发布日志/版本管理/发布步骤/上线时间） 
 9 怎么进行多团队的开发管理（拆分项目模块的依据/合理的开发节奏/Bug 和新模块需求的冲突)

这个是老大的LIVE，听一次应该理解不了很多，但基本的可以了解

敏捷开发有多火

敏捷开发工具（禅道）

敏捷开发角色

敏捷开发流程（敏捷开发流程自检手册）
一.需求讲解
1.理解需求背景
2.确认需求明确，无逻辑遗漏
3.确认所有的需求都有实现方案
4.合理预估时间
5.需求不明确或者是不清晰的点，可以当场提出来 ，或者是稍后整理
6.快速整理出未实现过功能，逻辑，技术点，可以和leader一起讨论交流方案
7.确认验收标准是否完善
8.确认Story优先级和粒度有无疑问，有问题反馈给leader
二. 方案评审
1.前后端快速整理出来多少个接口，哪些可复用，哪些需要合并
2.接口遵循Rest风格，考虑扩展性
3.参数和返回值都清晰明确，遵循接口定义规范
4.关键业务逻辑画业务流程图
5.DB设计完备，Sql语句完善，索引完整，常量标注清晰，表名和字段名符合规范
6.DB设计中预估数据量和增长速度
7.制作出架构图
8.后端预估并发数
9.前端给出公共组件
10.前端给出浏览器兼容版本
11.确定是前后端分离还是不分离
12.明确开发，测试，线上三个环境的IP，内存，域名等资源分配
13.给出多种解决方案和推荐方案
14.方案应该在两天之内完成
15.评审通过之后，Task在两个小时之内拆解完成，Task的粒度不超过2小时，Task无遗漏
三.日常任务
1.3次Todo List
2.下班前提交代码，部署开发环境，测试当天完成的内容
3.寻找影响Story完成的阻碍点
4.晨会演示昨天完成的内容
5.测试正常数据和边界数据
6.晨会审核燃尽图，更新Demo时间，找出延期的原因，给出解决办法
7.每天随时测试完成的结果，遵循测试方法
四.性能测试
1.明确结论，通过或不通过
五.CodeReview
1.是否符合编码规范
2.是否和方案设计一致
3.是否有逻辑漏洞和潜在风险
六.Demo
1.确保所有的关键业务逻辑全部走通
2.确保异常数据处理正常
3.确保各种兼容性
4.确保最终研发出来的产品符合用户的使用逻辑，没有反人类的设计

设计/研发/测试三阶段内容关键词

开发管理这个就学完了再听一下吧。

本次LIVE全程听过来，没有PPT,记不住多少，是一个BUG。

小课堂和/日报基本没有新的

以上内容都是来着自网站，目前阶段，只能是初步吸收这些观点，或许以后会有自己的看法吧。

• 2.如何做需求分析？  点击查看相关小课堂
  
• 百度需求分析

知乎需求分析

人人都是产品经理网站
需求分析查询
http://www.woshipm.com/search-posts?k=需求分析&is_v=1
看了以上需求分析文章，感觉被需求分析错乱了神经。

至此疑问比较多
1.需求有哪些？

参考http://www.woshipm.com/pmd/178560.html

需求包括这些

2.分析哪些需求？需求这么多分析全部可能吗？有意义吗？
参考http://www.woshipm.com/pd/2139803.html

参考http://www.woshipm.com/pmd/439561.html

需求的优先级

3.分析了需求是干什么？需求的决策因素在哪里？

参考http://www.woshipm.com/pmd/1033866.html

参考http://www.woshipm.com/pmd/857932.html

参考知乎https://www.zhihu.com/question/19655491

参考 http://www.woshipm.com/pmd/833371.html

参考 https://baijiahao.baidu.com/s?id=1593476535524390670&wfr=spider&for=pc4.

因素包括战略背景、产品定位、用户需求、可行性和实现成本

5.需求分析的方法？
参考百度https://baike.baidu.com/item/需求分析/2012709?fr=aladdin

参考百度https://baijiahao.baidu.com/s?id=1593476535524390670&wfr=spider&for=pc

参考知乎https://www.zhihu.com/question/19661689

7.需求分析的结果是得否得出最好的需求？
内容解答就是参考这些 http://www.woshipm.com/pmd/1833488.html，学会砍需求。

至于需求文档怎么写，用什么写？这个问题就相对不重要啦

需求不是这么好分析的？方法简单，结果难。存在哪些需求？分析哪些需求？分析的目的?分析的决策？我还是后续慢慢思考总结吧。至此好像没有看到一份完美的需求分析教程。

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

• 参考https://zhuanlan.zhihu.com/p/43583875，

• 第一个问题，Bug是不是可以不被写出来？为什么程序员总是会写出来各种各样的Bug？

• 做为一个曾经的程序员，也是现在的程序员，同时也是未来的程序员，我可以负责任的告诉你，Bug一定存在，多熟练的工程师都没用。

Bug就像是宿命一样，伴随着程序员的终生，而这也是人类最有意思的事情，它不像程序世界里一样充满了确定性，人是会犯划的，会漏掉各种各样的细节。
各种分支条件，极端运行情况，大多数程序员只能保证在大多数情况下不出意外。
可是Bug可以被消除，已经发现的Bug，除非特别难复现的，正常来讲都可以消除掉。
当然那些因为一开始系统构造的错误架构问题产生的Bug特别难修复。
在这个问题上，我想表达的含义就是，正确的认知Bug，不要因为Bug的存在而产生困惑，我们想做的，能做的，就是尽可能的减少Bug，以及在测试环境发现Bug后，快速的修复Bug。
第二个问题， 是不是程序员的水准越高，写出来的Bug就越少？
答案是对的。反过来说，其实更好理解，当一个程序员写出来的Bug很少的时候，他往往水平很高。
这是一件很有意思的事情，程序员之所以会犯错，很大的可能性是他不知道自己在犯错，而不是故意在犯错。在这种情形之下，如果能够有快速的反馈，他会修复自己犯下的错误，并且提醒自己不要再犯同样的错误。
Bug的修复史其实是程序员的成长史，好的程序员，会有足够多的经验做出预判，另外，在他们交付测试之前，往往会比测试人员测试的更仔细，以便提前发现自己的问题。
“让其他人发现自己写的程序有Bug，是程序员的耻辱。” -by 暗灭大人
做为产品和测试，很多时候并不太懂技术，不知道谁的水平高低，但是他们的感受很直接，谁做的项目容易出问题，谁负责的模块总是出故障，谁花的时间更少，心里会很清楚。

还存在Major级别以上的Bug，如果存在了，能否把这个模块去掉，先去上线没有问题的模块 

• • 4.边界测试，功能测试，冒烟测试，黑盒测试，自动化测试，回归测试，性能测试的含义分别是什么，应该谁来主导，原因是什么？  点击查看相关小课堂
    
  • 测试整体来讲，可以分成三大部分，

  • 功能测试；QA

  • 性能测试：开发

  • 自动化测试：开发

  边界测试：如果输入条件给了一定范围，测试的时候取范围边界或者超过边界的值进行测试，来判断有无bug
  功能测试：对产品的各功能进行测试，根据功能测试用例逐步检测，看有无bug
  冒烟测试：强调程序的主要功能，只对基本功能进行测试，耗时短
  黑盒测试：通过测试检测每个功能是否都能正常使用，主要注重于软件的功能需求，而非逻辑结构
  自动化测试：在预设条件下运行系统或应用程序，评估运行结果，需要注意的是，预设条件应包括正常条件和异常条件
  回归测试：修改了旧代码以后，重新运行检测，看有没有出现新的错误
  性能测试：通过自动化的测试工具模拟多种正常、峰值、异常负载条件来对系统的各项性能指标进行测试

• 5.Bug如果长时间未得到解决，应该怎么处理？做为PM，是否应该推动Bug的解决，如果PM成Bug的推动者，会不会导致开发人员越来越不主动？  点击查看相关小课堂
  
• 指派   QA指派给小组Leader/责任人，
• 
  
• 6.怎么样判断Demo是否应该通过?  点击查看相关小课堂
  
• 性能测试不通过，是无法进行Demo的。
• 
  
• 7.常用的Bug管理工具有哪些，互相之间有什么差别，你更喜欢哪一种，为什么？  点击查看相关小课堂
  
• easybug  禅道 QC  bugzilla  mantis, 禅道
• 
  
• 8.为什么要区分开发，测试，线上三个环境，三个环境之间的区别是什么？分别由谁来主导？  点击查看相关小课堂
  
• 各自独立环境，即独立的三台服务器，区分干扰确保bug出现的责任划分，保证开发迭代的周期。
• 参考https://zhuanlan.zhihu.com/p/45154579
• 
• 
  
• 9.什么是版本回滚，在发布上线的过程中，如果发布不成功，多久之内应该要回滚，谁来决定，原因是什么？  点击查看相关小课堂
  
• 程序或数据处理出现问题，将版本恢复到上一版的状态。在造成较大影响前，必须要回滚。由PM决定
• 
  
• 10.什么样的Bug是允许上线的，什么样的Bug是不允许上线的？  点击查看相关小课堂
• 而关于系统能否发布上线的一个非常重要的依据就是，是否还存在Major级别以上的Bug，如果存在了，能否把这个模块去掉，先去上线没有问题的模块。
• 11.Bug的优先级是什么？一般会分成几个级别，分别对应什么含义？  点击查看相关小课堂
• 优先级 critical   > block  >    major  >    normal    > minor

最严重critical 系统崩溃，停下工作立刻修复
次严重block操作卡死/流程不通 ,停下工作立刻修复
严重major业务数据不对/流程通，停下工作立刻修复         
一般normal偶然问题，
小问题minor兼容性/字体样式错误

• 12.Bug的生命周期是怎么样的？什么情况下应该是Reopen？什么情况下去Close？  点击查看相关小课堂

• • 参考https://zhuanlan.zhihu.com/p/44542420
• 通常,Bug的生命周期分成如下几个了阶段

• 1.新建   由QA记录Bug，第一个重要原则就是,说出运行环境和操作步骤,并配上截图 , 第二个重要原则就是,说明是偶现还是必现,第三个重要原则是,给出产生Bug的数据
• 2.指派   QA指派给小组Leader/责任人
  
• 3.接受   开发人员接受bug   可能甩锅
• 4.修复   开发环境验证之后.
• 5.关闭 
• Bug会有在两个环境发生,一个是测试环境,一个是线上环境.
• 线上环境验证通过的关闭。
• 如果说验证的时候,不通过,怎么办呢?
• 改成Reopen,重新打开(我不确定是否只在Bug关闭的时候才应该打开它,但是一个Reopen的状态就够了,它和未分配其实是一样的,只是用来标记一下,这是一个二婚

1. 明天计划的事情：完成以下深度思考

编辑日报内容...