今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin）

今天根据师姐的建议了解了banner图的意义和位置，访问不同网站观察banner展示的内容和位置及优缺点，了解学习优先级，了解测试流程，这个过程是怎么走的，了解深度思考的问题，

任务一地址 https://pan.baidu.com/s/1BFV-Y9-_2tzY1q41ttTXiQ

Banner横幅广告（旗帜广告）

468×60像素的称为全横幅广告（Full Banner），234×60像素的称为半横幅广告（Half Banner），120×240像素的称为垂直旗帜广告（Vertical Banner）。从表现形式上，横幅广告可以分成三种类型：静态横幅、动画横幅、互动式横幅，banner的大小，一般不能超过15k。

banner一般是一个活动或广告页面的入口，点击可进入相关页面,

banner可以在任何位置，但是它必须是醒目的，最容易被发现的位置，用户最可能看到的位置,

最常见的是图文左右排版、文字居中排版。

排版方式要看banner所要传达的内容主要是什么，图左文右或者文左图右，一般是考虑到这符合人们从左至右的阅读习惯，能让用户快速接受信息。若是商品广告，重点在于商品图的话，通常是图在左，右边搭配文案主标或副标题，起到说明商品的作用

文左图右的情况通常用于宣传某个运营活动，文案是主要传达内容，而右边配图是起到装饰美化整个banner的作用，同时与文案有一定关联性，让用户更加形象地理解banner传达的含义

______________________________________________________________________________________________________________________________

手机访问微博

这个banner 摆放的位置应该是最好的价钱肯定不便宜，用户一般都爱看热搜，一切换热搜界面就可以看到它，优点是曝光率高，缺点是这张图没有任何吸引力和冲击力，没有点击了解的欲望

访问知乎

这个banner推荐经典书籍，文字有冲击力，点进去看看再说，首要目的让人有点击的欲望它是成功的，优点，文字有冲击力，图片有点击查看的欲望，缺点是需要切换到会员模块，如果能放在主页效果会更好

访问淘宝

优点，文字够突出，把商品放在图中，如果对这款杯子外观感兴趣肯定会点击查看。 缺点，轮播很快，如果能把功能和价格标出会更好

————————————————————————

访问苏宁易购官网

总结，banner一般都是放在最显眼的位置，用户第一眼可视位置，文字或图片有点击了解查看的欲望，核心使命是吸引用户关注，然后被点击

附上一张banner设计的流程图

——————————————————————————————————————————————————————————

优先级

为什么需要优先级排序

首先，每个公司或者团队资源是有限的，不控制需求的优先级，产品可能永远无法封闭，得不到想要的产出。就好比我每天下班，希望早点到家，但公司离地铁站有点远。回家的方案有走路或骑共享单车到地铁站，然后坐地铁回家。也可以直接打车回家。每种方式的成本和效益都不一样。

其次，需求是经常变更。没有哪个产品是完全按照预设出来的。中间总会因为各种原因导致无法按照预期步骤进行。可能市场环境变了，可能领导想法变了，可能…..这也是为什么互联网产品快速迭代不断试错。

——————————————————————————————————————————————————
了解测试流程

1.切记产品测试的主要目标

产品测试的本质是发现功能、流程、界面等现存的产品问题，而不是提出功能或界面的产品优化方案。

做产品测试的时候坚持‘提bug为主，提需求为辅’才是正确的测试姿势。唯有这样才能做到工作与提升两不误。

2.提bug时，注意用语的准确度

描述产品漏洞要求有三个主要的要素：一：产品漏洞在哪里；二：产品漏洞是什么；三：如何解决产品漏洞。

一个完整的开发流程。从提需求、开发、交付。这中间都应该有个结果。就如你做一件事，得有个东西来判断你是否已经完成了这件事。那么测试结果就是这个东西了。

在编写测试用例之前，你得想好有哪些前置条件。这些前置条件满足了才能达到你得预期。比如账号密码登录，前置条件时账号和密码同时正确才能正常登录成功。那么此时你就得编写条件不符的时候，是否也会成功。如果成功了，那就属于BUG，需要技术进行修复。

一般正常情况，请考虑一下几个方面：

1. 页面布局是否合理，如导航栏上面应该显示三个按钮，实际上却显示了两行。
2. 页面文字描述是否准确，如气泡提示：密码格式错误，请重新输入。实际上却显示：账号密码错误。
3. 如果有加载规则，是否符合加载规则。如：进入页面加载20条内容，实际上却加载了10条。
4. 如果有排列规则，是否符合排列规则。如应按照时间倒序排列，实际上却是正序排列。
5. 操作是否符合要求，如单击某个点，是否准确跳转或显示内容。如本应该进行跳转，实际上却未进行跳转。
6. 输入框输入的内容是否有符合格式要求。如：账号不允许”,”,而实际上却允许了。
7. 输入的内容是否符合合法性要求。如：账号密码是否一致等问题。
8. ……

这些基本考虑内容都需要考虑进来。

大概理清楚需要考虑的内容之后，就可以开始动手写了。

1. 序号： 不用说，就是按顺序下去的。
2. 模块：该功能点具体属于哪个模块的，填写这个主要是方便查找，如：注册/登录模块
3. 编号：对每个用例进行编号，方便后期跟进。毕竟用文字说，容易口误。不过此处建议编号设计的有点规则，方便快速定位查找。如：A0001。其中A表示注册/登录模块。00表示账号登录，01 表示账号密码登录下的第一个测试用例。
4. 功能点：具体指某个功能，如：账号登录、首页、发布等。
5. 子功能点：具体指功能点，如：账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。
6. 用例名称：具体测试用例的名称。如：输入账号、输入密码、密码不合规等等。
7. 前置条件：指要达到预期测试结果，需要满足那些条件才能达到。如：账号密码不一致时，就需要登录失败，那么此时就得保
   证账号正确或密码正确以及账号正确时是存在的。
8. 操作步骤：指要达到预期测试结果，需要按这些步骤来。最好说明在什么页面，点击或操作什么内容，输入什么内容。
9. 预期结果：说明按照前面写的应该呈现出怎样的结果。
10. 测试结果：如果符合预期结果，直接填写正常或OK，如果不符合，则说明不符合或NO，
11. 结果描述：如果正常，可以不用填写，如果不符合预期结果，则说明哪里不符合。
12. 测试人员：填写测试人的名字，方便后期跟踪BUG。
13. 测试日期：填写测试的时间，方便后期查询。
14. BUGID：跟测试编号一样，自己设定ID规则，方便快速查询。
15. BUG负责人：此处应该有技术那边填写，具体落实到某个人身上，才能更好的解决到问题。

————————————————————————————————————————————————

敏捷开发

敏捷是绝对的结果导向，去文档化，去流程化，高效沟通和合作是究极奥义。

初识敏捷，有一些概念需要了解，如果你是老司机，跳过这部分，阿敏。

agile：迅速，敏捷。这是敏捷的理念也是精髓：迅速响应需求，快速反馈结果。agile 的引入像一股活水冲击着老气横秋的瀑布流模型，速度上跑赢几条街。

sprint：字面意思是短跑冲刺，一个开发阶段被认为是一次冲刺，一个个 sprint 首位相连，构成一个项目。

Scrum:指的是英式橄榄球中一股脑争球这一战术或行为。

scrum 即为这样一种方式，大家一拥而上，团队是球员，球是产品目标，人员环环相扣，围绕着产品目标进行工作。这里面多少有点“统筹法”的影子，人员深入协作以达到最优化效果。

Product Backlog:

backlog 即需求池。待办事项列表。

Backlog 里面写什么：

1.待开发任务。

2.任务优先级。

敏捷需要维护一份详尽的需求列表。这份列表常常要求 scrum 持有人（一般是产品经理）对所有待开发事项有深入了解，并且能够把待开发事项分解成更为细致的任务（或者跟敏捷教练一起，后面我们会再次提到敏捷教练）

story board:

很多领域都有故事板的概念，交互领域里，用故事板表述用户场景、电影领域里故事板用来更具体地描述分镜。在开发领域，故事版是任务流转的可视化窗口，一般有“待开发”“开发中”“待测试”“返工”“待发布”几个区块，所有任务由任务操作者负责流转至于下一个步骤，这样任何一个人项目成员都能看到任务的完成情况。

一个app使用情景故事版

在开发中，故事板展现所有需求的工作流

burn down chart：

燃尽图

一个 sprint 内，人/时是一个比较固定的值。在这个时间框架充分安排开发任务，每天进行时间结算，绘制时间燃尽图。项目成员通过燃尽图获知时间进展，若项目燃尽所用时间与预期时间契合，则需求时间预估和安排合理，若不契合则需要在下一个 sprint 进行调整。

——————————————————————————————————————————————————————

总结敏捷开放

敏捷需要维护一份详尽的需求列表，一般由产品经理持有，对所有待开发事项有深入了解能把待开发事项分解成更细致的任务。

产品经理要维护“产品文档” 产品文档包括

1.需求    2.加入日期  3.开发版本  4.呈现和详细方案

在非敏捷开发流程中，文档在评审会后完善并更新，形成一个给研发参考的实现目标

在敏捷中，需求本身在sprint周期不断完善，可以在一个sprint之后将文档补全

产品经理要维护“概要设计文档” 敏捷的常规迭代中，概要设计不是一个必须的文档。但全新项目、重构以及重大新功能则必须输出概要设计文档。

接口文档，必要且重要。包括接口说明、字段定义、字段类型、值定义、数据上报、错误码等。一般来说约定之后由接口开发者更新文档，如果没有云端存储的能力，至少人手一份，定期更新。

没有任何项目协同软件 敏捷开发怎么实施？

敏捷路径里必须有一个项目持有者，制定规划并把握项目走向

还有一个关键人物SM 全称 scrum master，中文称敏捷教练。一般说来，SM 需要由对技术开发以及当前项目明晰的技术经理担任。

然缺少线上工具，但至少要准备一些简单材料：一卷双面胶+白纸或一沓便利贴；笔，一面平坦的墙或一块黑板。如果有电脑可用excel、word。

总之要找个地方写下backlog（需求池，分别是 任务名称、平台详细描述、优先级、PO-PX逐渐递减）

一周（五个工作日）作为sprint周期，按优先级选择一个差不多一周左右开发量的sprint里的需求，之后找SM开会预览需求，SM对需求分解一遍，比如某需求要分解为A、B、C三部分，就形成三个开发任务。分解完成得到一个详细的待开发列表。

——

正式开始一个sprint之前

产品、研发、测试需要一同开一次scrum会议，共同讨论本次sprint功能点

讨论: 需求讨论或技术讨论、预估需求所需开发时间、需求是否match人力时间，需求排入sprint、交流感情。 任务的预估时间在最后由SM综合判定。

产品经理scrum会议后的工作

1.整理这个sprint的需求列表

2.整理每个需求预期开发时间

3.撰写故事板上的小纸条，写明开发者、任务描述、预估时间和每日燃尽时间

4.把小纸条贴到故事板上，最开始所有的小纸条都贴在待开发一栏

5.制作一个燃尽图

产品经理参加每日的项目短会，早上上班后或晚上下班前抽时间完成

参加人员，PM、SM、其他scrum成员

做什么？

昨天任务完成状态，剩余多少时间，是否需要进行时间修正（增加或减少时间），已完成的任务流转到下一环节（把小纸条从一个item内撕下，贴到下一个item里），昨天做了什么事，遇到什么问题，如何解决或寻求解决方案，功能测试后是否有返工，交流一下感情。结束后PM制作燃尽图。

完成一个sprint后第二次开会，复盘上一个sprint

任务未能燃尽、研发返工过多、测试要求淤积、针对问题讨论解决方案，根据实际情况进行下一个sprint任务安排

另一种情况

由设计师情况

产品经理将小纸条需求分为UI支持和非UI支持两类

UI设计师参加scrum会中

对于需要UI支持的需求，设计师给出一个UI制作时间预估，产品经理将这部分时间加到扩展后的小纸条上，在一个sprint中，设计师的工作和研发的工资分别进行，设计师将某一需求完成时，将小纸条的UI部分撕下，汇入到待开发中去。

明天计划的事情：（一定要写非常细致的内容）

把深度思考看完，了解任务二任务

遇到的问题：（遇到什么困难，怎么解决的）

对敏捷开发流程还需要更加熟悉

收获：（通过今天的学习，学到了什么知识）

了解了banner图的位置优缺点，简单了解了敏捷开发流程，了解了优先级和测试流程