用户故事地图

为什么80%的码农都做不了架构师？>>>   

阅读用户故事地图笔记，联合技术，管理，产品的融合经验总结

1. 用户故事不是另一种写需求的方式，讲述用户故事，在过程中用文字和图片相结合的方式辅助讨论，这是一种建立共识的机制．故事即流程.
2. 用户故事也不是需求，他是一种关于问题解决方案的讨论，解决公司的问题，客户的问题，用户的问题，目的是我们对要开发的功能达成共识．同一份文档，阅读的人不同，得到的信息也不一样．
   
3. 你的工作不是开发更多的功能，而是使那些投入精力开发的功能在成果和影响上可以最大化．
4. 用户变得开心是因为在使用我们的软件或网站或APP，他们可以用不同于以往的方式做事，这才是用户感到开心的原因．
5. 实际上，你的工作是改变世界． 最小化输出，最大化成果和影响
   
6. 如果我们要始终把握好整体，就要在抓住所有细节之前，先走一遍整个用户故事．＂思路宽广，细节有度＂．
7. 软件开发中的一个基本事实：像做得功能，总永远超出你来得及做的．所以我们是努力缩小产品范围，找出最小可行产品集,只做必要事
8. 划分发布路线图，增量发布.为目标成果排定优先级，而非功能．排优先级，只有做和不做，＂没有他就无法工作＂就做，其他的都先不做．先跑通主流程. 制定优先级的秘密：(１)讨论业务目标，(２)目标用户的目标行为，(３)功能
   
9. 最小可行产品(MVP), 指可以产生预期成果的最小产品发布．或指为了验证假设而做的最小规模实验.MVP（最小化可行性产品）快速搭建：搜狐快站
10. 滚动波式计划，越近开发越详细
    事：
    
    
11. 基于验证的学习：**开发－度量－认知循环:打磨产品.**一次性就把事情做对是一个冒险的策略，尤其在软件行业．不要假设自己总是对的，不然最后一定很失望．要先降低期望最小化试错，迭代．
    
12. 最靠谱的估算来源于真正理解自己在估算什么的工程师．达成共识是估算的法宝．大的项目要拆分，细化有利于度量．谁最了解完成一项任务的时间，任正非说：＂离战场最近的人＂．
13. 多年经验总结：开发分支的迭代周期为两周最合适开发．产品的开发是增量的，迭代的．早期目的侧重试错，后期目的侧重微调．
14. 讨论和会议的人数一般情况下限定在５人以内
15. 如何讲好故事，关键靠套路(也可用trello管理电子卡片)，模板就是：
    
    
16. 管理就是平衡干系人需求的艺术．做个演好戏的导演．
17. 不要太好说话，要有眼光，有定见，有远见．要和干系人一起做决断，果断抛弃对预期结果帮助不大的机会．要维护自己在他人眼中是专家的地位．
18. 世界那么大，总有你不了解的东西，一定要设定截止时间，及时停止．
19. 敏捷团队最大的抱怨之一是开会时间太长，大家一直同意，并不是达成共识，只是希望早点结束拖沓，折磨人的会议．
20. 常见的问责：＂你为什么不能一次性把事情做好呢？＂时，我们要努力解释每周的推进与改善．
21. 总结要记住：发布之后的改进最有价值．项目成功是 质量，时间，成本的平衡, 干系人的满意．．
22. 最后送给大家的是：软件从来都不会被真正完成．

转载于:https://my.oschina.net/sunmin/blog/732391