用户故事地图

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

  1. 用户故事不是另一种写需求的方式,讲述用户故事,在过程中用文字和图片相结合的方式辅助讨论,这是一种建立共识的机制.故事即流程.
  2. 用户故事也不是需求,他是一种关于问题解决方案的讨论,解决公司的问题,客户的问题,用户的问题,目的是我们对要开发的功能达成共识.同一份文档,阅读的人不同,得到的信息也不一样.
  3. 你的工作不是开发更多的功能,而是使那些投入精力开发的功能在成果和影响上可以最大化.
  4. 用户变得开心是因为在使用我们的软件或网站或APP,他们可以用不同于以往的方式做事,这才是用户感到开心的原因.
  5. 实际上,你的工作是改变世界. 最小化输出,最大化成果和影响
  6. 如果我们要始终把握好整体,就要在抓住所有细节之前,先走一遍整个用户故事."思路宽广,细节有度".
  7. 软件开发中的一个基本事实:像做得功能,总永远超出你来得及做的.所以我们是努力缩小产品范围,找出最小可行产品集,只做必要事
  8. 划分发布路线图,增量发布.为目标成果排定优先级,而非功能.排优先级,只有做和不做,"没有他就无法工作"就做,其他的都先不做.先跑通主流程. 制定优先级的秘密:(1)讨论业务目标,(2)目标用户的目标行为,(3)功能
  9. 最小可行产品(MVP), 指可以产生预期成果的最小产品发布.或指为了验证假设而做的最小规模实验.MVP(最小化可行性产品)快速搭建:搜狐快站
  10. 滚动波式计划,越近开发越详细
    事:

  11. 基于验证的学习:**开发-度量-认知循环:打磨产品.**一次性就把事情做对是一个冒险的策略,尤其在软件行业.不要假设自己总是对的,不然最后一定很失望.要先降低期望最小化试错,迭代.
  12. 最靠谱的估算来源于真正理解自己在估算什么的工程师.达成共识是估算的法宝.大的项目要拆分,细化有利于度量.谁最了解完成一项任务的时间,任正非说:"离战场最近的人".
  13. 多年经验总结:开发分支的迭代周期为两周最合适开发.产品的开发是增量的,迭代的.早期目的侧重试错,后期目的侧重微调.
  14. 讨论和会议的人数一般情况下限定在5人以内
  15. 如何讲好故事,关键靠套路(也可用trello管理电子卡片),模板就是:

  16. 管理就是平衡干系人需求的艺术.做个演好戏的导演.
  17. 不要太好说话,要有眼光,有定见,有远见.要和干系人一起做决断,果断抛弃对预期结果帮助不大的机会.要维护自己在他人眼中是专家的地位.
  18. 世界那么大,总有你不了解的东西,一定要设定截止时间,及时停止.
  19. 敏捷团队最大的抱怨之一是开会时间太长,大家一直同意,并不是达成共识,只是希望早点结束拖沓,折磨人的会议.
  20. 常见的问责:"你为什么不能一次性把事情做好呢?"时,我们要努力解释每周的推进与改善.
  21. 总结要记住:发布之后的改进最有价值.项目成功是 质量,时间,成本的平衡, 干系人的满意..
  22. 最后送给大家的是:软件从来都不会被真正完成

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值