6月想的很杂、倒也没有太明确一定要想出个所以然，而且故意把学习节奏放缓了，最终还是决定，需要把最近的思考写下来，就当自己的成长笔记了，等过段时间在来拍死现在的自己。所有内容还是跟神奇的agile相关。
一、用户故事和用户故事地图
1、用户故事是什么，怎么写，为什么需要用户故事，都略过，之前这趴已经想清楚了，重点是怎么从产品习惯的PRD（我还见过有些产品连PRD都没有，直接原型一扔）转换到用户故事，同时，product backlog refinement的目的，怎么做，理清了。
从PRD转到用户故事，最简单的方法：行政命令（从上到下），哪怕PO不理解，团队不理解，没有关系，你会发现有了行政命令后，他会这么去做的。其实之前最困扰我的问题是，如果没有行政命令支持，我怎么可以让产品马上就改用用户故事去表述需求，无数实践证明，很难，需要有一些数据支持证明原来的方法有些许无效或老板的力量，难道没有办法了吗？肯定不是的，这时候读了好几遍的《硝烟中的scrum和XP》就派上用场了，我又一次认真读了一遍，发现书里提供了很多实践的办法，可惜，我之前从没有认真每一条照着做过，有选择的错过了一些内容。书里提供了故事的模板，可以用excel制作，也可以去henrik的博客找，每次填好打印出来即可，见下图：
产品经理需要填写除了estimate之外的字段，这样的故事就可以用来作为planning meeting的输入了，在planning meeting上，团队在对故事进行估算，填写estimate字段。等PO习惯这样去书写后，在进一步就可以去写标准的US了，这是一个心理接受转换的过程，同时故事到更标准的故事而已，大家可以尝试一下。我也会在后面尝试实践。
2、refinement
在说refinement，之前对refinement模模糊糊，完全不知道为什么一定要有这个会，明明scrum guide里面是没有这个会的。最近突然被点通了，因为US也是分粒度的，按澄清程度可以分为乱麻、砖头、钻石三类，所以可以理解为refinement其实是讲乱麻->砖头的一次梳理过程，这个过程也需要PO和研发团队的参与，和planning meeting完全不矛盾，planning的目的就两个，what和how，当提前做好refinement（解决做什么what），planning时能专注在细节（怎么实现how），节约时间，并且很多时候，从乱麻->砖头也是需要探讨很久的，这是一个过程。
3、用户故事地图怎么用，为什么用，理清了，第一次带团队实践。
为什么需要用用户故事地图呢？主要是为了解决“只见树木，不见森林”问题，很多时候产品也好，开发也罢，都觉得自己很忙，可是到底做了多少需求，还有哪些需求没有做，有没有全景图呢？这时候就发现大家一脸懵逼，用户故事地图就解决这个问题。用户故事地图（user story map）即将用户故事部署在产品地图上，产品地图是根据用户使用产品的行为活动和关键行为抽象出的一张产品路线图。所以最上一层是user activity，第二层是theme（所有theme的集合也叫做backbone），第三层是US（通常PBL里的US），当你把用户故事地图做出来，讨论完，mapping好，其实也相应对齐了iteration、sprint goal。这里可以说一下第一次带团队做了实践后，我们这个产品因为有3个PO，大家第一次对齐了第一层（想想就知道这有多可怕，我们这个产品已经发布了很多功能了），接下来在对齐了之前的几次iteration。
二、Scrum和XP
在推荐一次《硝烟中的scrum和XP》一书，曾经最熟悉的scrum其实并没有理解透彻，我们现在很多时候用的scrum里，工程实践部分来自XP，比如持续集成、编码规范、代码集体所有、TDD（测试驱动开发）等，这提醒了我，很多时候学习时一个循环过程，看书->实践，千万不要丢下任何一环，毕竟经典的书是每看一次都会有新收获的。
三、端到端
端到端的概念在解释一次，即需求提出到需求上线，在近几年的工作中，很幸运地接触过一次端到端，后来的实践里面发现都是断掉的，我们了解到需求的时候已经是需求到了PO，PO到传递到团队，团队开发上线的这一段了，虽然对这一段比较熟悉，但是前面一段完全丢失，跟踪不到，也没有职权去跟踪，还是会影响一些理解和方法使用，总的来说，整体端到端要打通，不仅会用到scrum、肯定也会用到kanban，至于工具的选择，还是推荐jira、或者白板（sticker），做方案也是一件困难的事，需要去分析痛点，做完方案还需要去宣讲，确保正确执行，修正，持续跟踪。
好啦，这次先写这么多吧，是很混乱，先当练笔吧，以后希望可以写自己的公众号，加油。
