1 作者观点。绝大多数问题都是由于分解的粒度太大造成的，大块的需求不能谈取舍，但小的就比较合理。
读后思考，（yy 个例子，和人讲把头发剃光是不好谈的，但是谈谈把哪里剃一下，可以换来xxx 这个是好谈的 ）
2 INVEST 介绍。
Independent，独立的
Negotiable，可协商的
Valuable，有价值的
Estimatable，可估算的
Small，小
Testable，可测试的
读后思考，天啊，这么多的单词，这么详细的解释（罗里吧嗦）， 我是记不住的，自己yy 个故事去记忆吧。（为了方便，直接借用作者昨天的例子来扯需求好了）
google 整理术告诉我们，长期的记忆是一个encoding 过程，使用故事是一个非常好的套路（作者也同样说了这点，只是没站在大脑认知学的维度来谈而已）
step1：在漫长的等待后，产品的用户登录登出需求出来了（出来了，出来了....）。 做为开发，我第一时间对他的需求做了梳理含以下内容, 基于(Independent 独立性的)分解如下 并且分解得很(small 小)
手机号密码登陆（判断 （不能为空，手机号格式，密码长度校验））
记住密码
第三方登录（微信扫码，微博登录，qq 登录）
登录时长为2小时
。。。。。
登出
step2 : 我拉来了产品,协商。（便于简化 ，这里只谈记住密码，和第三方登录） 这写说明了，分解的粒度是（Negotiable 可协商的）
2.1记住密码这事，其价值是用来方便用户的（Valuable 价值判断），但现在，chrome,ff,360se等浏览器 早以集成了这些功能，花了不少的时候，做出来的东西，并未额外给客户带来更多价值，所以，在我们这个mvp 版本中，这个先砍掉，我们多些思考，找出做这里的价值，再来开发如何。。。（small）
2.2 第三方登录这事，（我们的客户特征，是一定有微信的，（在其它应用场景中，是直接使用了微信的例如群发通知，微信课评等...）） 所以，微博登录，qq 登录，对我们来说，是做了多余的事。
关于微信登录呢，在沟通用说到 平台需要收集到用户的手机号，顺带方便客户手机登陆，所以在首次扫码时，提示下客户去做手机绑定，和直接使用。 (毕竟我们不是流氓平台，动不动强制用户绑了手机才能用)
这个沟通， 我们先砍了价值 我们通过沟通发现，我们把微信登录后手机号绑定这个需求，单独给提了出来 （small） 并且把微信登录这事（Testable 可测试的） 的需求出来。
step3 梳理玩需求后，开始估算进度了。
微信登录这事吧 先拍脑袋 2 days (Estimatable) （ 我讲下如何拍出来的， 我看了下文档 https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html 难度适中，考虑到开发之前没有做过类似开发，但这个早已被大量网站给实践出来了，先初步给两天吧。 （基于dod 原则，我和程序员聊了下，给这么多时间，主要是 1 完成pc 端扫码登录的任务，并测试完成【紧急】。 2 熟悉知识和习惯一种与第三方协同的开发模式【重要】 我为认工程师不能只限于事务（完成1 ），还需要能力成长 （完成2） （再讲个个人习惯 ，我会再预留半天时间，程序员写崩了后，我去快速填坑 ， 小概率事件，做一个合适的预留 ，这里我多扯一句，要基于库尔贝勒交叉熵去适当预留资源，项目开发需要鲁棒性，别让极小概率事件把整个项目搞崩） 其实这个 2days 的结论，也是由于分解的足够独立，且粒度足够小，才可以做出来估算. 所以，我在后续估算工做量发现蒙b 时，就会去思考是否分解到位了。
3 作者推荐了两本书《User Stories Applied》和《Agile Estimating and Planning》。
做以下操作， 复制 User Stories Applied 打开某东，搜索 User Stories Applied 先加入购物车
由于价格很感人 User Stories Applied ￥571.00 Agile Estimating and Planning ￥620.00
我登上download.csdn.net (vip ) 下载了对应的pdf , 然后再上传至百度网盘（还是vip）
 并分享出来 https://pan.baidu.com/s/1jWbXqUX2kXJGJcyurGDh4w 提取码： e28v