我是丹仙仔，我是要成为站在产品顶端的那个男人。
近日公司组织发生了变动，把两个小产品线独立出来，配备各自的产品、研发、设计、市场、售前、交付，我们团队也来了位新领导，一个让人放心的领导，并且致力于改善我们团队现有的协作模式，我们将重新采用Scrum模式。
首先是对需求模式的改动，需求与迭代分离是我们之前没有做到的，之前我们直接把需求放在迭代里，而由产品经理安排迭代任务，而Scrum模式择推崇需求池，提前进行需求评审，由团队所有成员评估story point，这个sp也和我们之前的人天概念不一样，它正确的解读是对需求复杂度的大致评估，可用来整合一个迭代里团队能完成任务量，这个由团队一致达成的协议比我们之前由任务执行者评估可要准确多了。刚才说到需求和迭代分离，也就是说评估完的需求先丢到需求池，等待迭代开始的上午进行排期仍入迭代池，相比之前由我们产品根据需求优先级提前放入迭代，然后有研发经理自行安排任务，这样的作法之前也遭到了吐槽，所幸的是，这个模式是非常理性科学滴
第二个变动是周一晨会改为迭代排期会，基本流程是主持人先把上一迭代未完成的story计算下point，先拖入这个迭代，然后用团队稳定的points减去未完成的，剩下的points根据需求的优先级拖入开发中状态，然后由技术同学一起将story拆成task，最后分配给相应的研发，所以这一套下来理论上所有成员都可以做任何人的backup，当然这只是理论上了，也是未来努力的方向。
第三个变动是每周五的在Scrum中，每个Sprint结束的时候会有两个会议（Sprint Review/Demo和Sprint Retrospective回顾）。这两个会议是对过去的一个Sprint的一个总结，其中Review/Demo是检查过去一个Sprint的产出（What），主要是PO根据先前的计划来检查Team在过去一个Sprint的工作成果，包括一些Demo，以及未完成部分的总结和分析；而Retrospective则是回顾过去一个Sprint整个Team的运作模式，有什么好的和不好的实践，怎样在未来的Sprint做的更好，强调How。
Sprint Review 主要是由研发同学进行主持，给PO展示迭代上的功能，以及未完成部分的总结，这一块我们团队做的还比较草率，之后我也应该更加重视,比如要记录下演示过程中出现的一些bug
验收会议是一个非正式会议，并不是进度汇报会议，无需整理幻灯片，只要提前准备下要演示的内容即可。验收会议的意义并非单纯的演示，最主要的目的是通过演示获取反馈，从而促进产品优化改进。根据最后的完成情况，所有参会人员协同讨论，并记录下发现的Bug及问题。
最后一项就是Sprint Retrospective,大家难得聚在一起,进行敞开心灵的交流,我最爱的是我的产品mentor为大家自费出了零食,让这个会议的氛围骤然欢脱.\.
第一次总结会 我们先对这个迭代所处于的心情点做了标记以及原因的展示,接下来是每人对这这个迭代团队中做得好的以及做得不好的写下自己的意见,然后每人上台抽别人写的,展示在白板上,从图上看我们记录了Good和Not so good的点 我们针对每个点都进行了讨论,尤其是对no so good的点进行解决方案的讨论,最后我们针对not so good选了几个措施
第二次迭代总结 我们换了个模式,首先也是对于这个迭代的心情,你是属于happy,unhappy,confortable or 并说明理由, scrum mastrer听完我们的分享,认为我们忽略了一个重要的点:那就是迭代的完成与否,我们都没有讲到迭代没完成让我们unhappy,说明我们本还没有到达一定境界.第二项活动是考验我们的描述性语言,将一张纸叠成三份,由一个人先画一幅画然后交给左边的人,由左边的人看到这幅画后用一段描述性语言描述出来,再由其左边的人根据这段描述画出一幅,从而完成两幅画的对比,我们也感觉到语言的精准性会带来多么不一样的差距,所以平时沟通是要注重语言的精准 第三项活动就真的很吃鸡了,由每个人写出团队所有人的优点以及需要改进的点,这个氛围当时就略显难顶哈哈哈,不过通过这项uncomfortable的活动,我们不光对团队的人有了更深入的了解,更重要的是对自己,对未来自己的方向有更高的期待,有不足就有提升, 自己对自己往往会有思维定势,但在别人眼里自己的不足往往是真实且重要的.
真的很棒我们的团队,焕然一新的感觉,时候不早了,仓促结尾,赶着去跑步了,我们下周再聊
我是丹仙仔，我是要成为站在产品顶端的那个男人。