福袋开发迭代总结

（1）因为担心有改动，然后影响到数据模型。然后要原型图， 实际上是需求没有聊透。怎么聊透呢？ 要提出一个好的问题，也就是思考到一个待确认的点

（2）配置数据太麻烦，因为条数多，每条涉及的点没有问题。

（3）图片的压缩问题。在30K以上的，都要压缩一下 [   https://tinypng.com/  ]

（4）还遇到一个点，加缓存的点比较多，一下子脑子中放不下，需要一个扩展脑容量的抓手。todo

后端接口的改动，会连带测试的回归，前端的改动：接口改动的潜在的连带工作量

一个 开发流程：

        List<lotteryLevel> lotteryLevels = getLotteryLevel();
        int total = lotteryLevels .get(lotteryLevels .size() - 1).getEnd();
        lotteryLevel lotteryLevel = null;
        int luckyNum = ThreadLocalRandom.current().nextInt(0, total);
        for (LotteryLevel lotteryLevelTmp : lotteryLevels) {
            if (lotteryLevel.getBegin() <= luckyNum && lotteryLevel.getEnd() > luckyNum) {
                lotteryLevel = lotteryLevelTmp ;
                break;
            }
        }

@Data
public class LotteryLevel {

    /**
     * 大于等于begin
     */
    private int begin;

    /**
     * 小于end
     */
    private int end;

}

对随机数据的UT:

    @Test
    public void given100000Times_thenGetPercent() {
        int total = 100000;
        int size = 10;
        Map<Integer, Integer> map = new HashMap<>(size);
        for (int i = 0; i < total; i++) {
            int value = ThreadLocalRandom.current().nextInt(0, size);
            map.merge(value, 1, (a, b) -> a + b);
        }
        System.out.println(map);
        Map<Integer, BigDecimal> result = new HashMap<>(size);
        for (Map.Entry<Integer, Integer> entry : map.entrySet()) {
            Integer count = entry.getValue();
            BigDecimal percent = new BigDecimal(count.toString()).divide(new BigDecimal(total), 5, RoundingMode.HALF_UP);
            result.put(entry.getKey(), percent.stripTrailingZeros());
        }
        /**
         * {0=0.0997, 1=0.09972, 2=0.09974, 3=0.09993, 4=0.10029, 5=0.09989, 6=0.10067, 7=0.10019, 8=0.09987, 9=0.1}
         *
         * {
         *     0: 0.10007,
         *     1: 0.10009,
         *     2: 0.09977,
         *     3: 0.10047,
         *     4: 0.0998,
         *     5: 0.09986,
         *     6: 0.1002,
         *     7: 0.09998,
         *     8: 0.09953,
         *     9: 0.10023
         * }
         */
        System.out.println(result);
        System.out.println(JSONUtil.toJSON(result));
    }

定义问题

为迭代回顾会议做准备

    本节所介绍的会前准备都是针对上述的通用议程而言。好的准备应该做好三件事情：寻找主题、收集数据、选择工具。

寻找主题

    作为敏捷教练或者迭代回顾会议的主持人，要在迭代过程中时刻观察迭代工作的开展情况，并思考以下问题：

1. 团队之间的沟通、协调、协作有什么不足的地方？
2. 日常工作中有哪些值得记录的瞬间？
3. 整个迭代期间，团队成员的心理状态如何？
4. 迭代工作是否顺畅？
5. 迭代过程中是否有违背按照敏捷框架的？
6. 迭代过程中团队对质量的关注程度如何？
7. 迭代过程统计数据有能发现什么问题？
8. 团队的产出物如何？

    也可以与一些团队成员或者PO沟通他们的看法。他们在本迭代期间对什么感兴趣？迭代过程中有什么令他们烦劳的事情？
    将这些观察和思考的结果、与沟通的内容记录下来，尝试从中找到一两个主题供迭代回顾使用。

收集数据

    目前，在收集数据上很多项目管理工具给我们提供了强有力的支撑，但是也给我们带来的极大的限制。大家收集数据基本上都是从项目管理工具上直接获取统计数据表。更极端的是从第一次迭代回顾会议到最后一次迭代回顾会议用的都是同一个模板。
    事实上，面对不同的会议主题，我们最好收集有针对性的数据，并使用合适的数据统计格式。项目管理工具上的数据只能用来作为基础数据，不要僵化地采用上面的数据。

 基础数据

    基础数据是客观存在的，主要有用户故事、缺陷、燃尽图等基础数据。在做回顾时，用户故事要更多地关注上轮迭代的计划完成情况；缺陷要更多地关注于未解决的缺陷；迭代燃尽图可以更好地复现迭代的过程；发布燃尽图能帮助大家对整个项目的状况有一个更全面的认识。
    不是所有的基础数据都要在某一个迭代回顾会议上全部展示，正确的做法应该是选择与本次回顾主题联系紧密的数据。在选定的基础数据上，采用不同的展示形式，多角度的对比分析，让数据能反应更深层次的问题。

数据对比

    数据对比主要是横向对比和纵向对比两类。横向对比是指与同行业、同公司、同项目组的其他团队进行对比；纵向对比是指与本团队前期多个迭代的情况进行对比。当然也可以二者结合。

数据展示

    好的数据展示不但可以让数据看起来不那么枯燥，还可以更直观地反应问题。常见的统计数据展示方式有很多。如：折线图、直方图、雷达图、饼状图、散点图、曲线图等等。

数据分析

    数据分析是在迭代回顾会上的事情，但是作为会议主持人，特别是敏捷教练，在会前一定要先对数据进行分析。两个目的：验证是否能通过数据分析出一些问题；事先对数据有深入的认识，方便会议引导。
    数据分析能力是每个敏捷教练都必须具备的技能。可以从量、势、复、特、度五个角度进行分析。量是指数值的大小(有时还要关注某些曲线的包络面积)、势是指数据发展趋势、复是指类似数值、类似数据形状的重复情况、特是指与众不同的特殊数据、度是指数据影响广度、深度。

选择工具

    这里的工具是指在迭代回顾会议过程中所使用的图片、音乐、视频、游戏、思考方法等等，而不是简单地表示实体工具。这些工具将分别在营造氛围、定位问题、寻找方案和承诺等环节上使用。下面给大家一一罗列一些典型工具。一个好的敏捷教练或者会议主持人需要对这些工具有充分的掌握，并能合理地使用它们。

迭代回顾会议常用方法与工具

破冰游戏

    开始迭代回顾会议时，部分成员可能还没有从紧张的迭代开发中走出来，因此主持人可以选择合适的游戏破冰。
合适破冰游戏有三个要点：所有人都参加、规则简单、耗时短。比如说自我介绍、感恩、成语接龙、看图说文、看视频等等。
    好的破冰游戏除了可以营造会议氛围，甚至能在一定程度上激发灵感，为后续的各议程打下坚实的基础。

头脑风暴法

    头脑风暴法一般可用于进行定义问题和寻找方案。分为直接头脑风暴法（简称为头脑风暴法）和质疑头脑风暴法（也称反头脑风暴法）。前者用于群体决策尽可能激发创造性，产生尽可能多的设想的方法；后者则是对前者提出的设想、方案逐一质疑，分析其现实可行性的方法。
    采用头脑风暴法组织群体决策时，要集中有关专家召开专题会议，主持者以明确的方式向所有参与者阐明问题，说明会议的规则，尽力创造在融洽轻松的会议气氛。一般不发表意见，以免影响会议的自由气氛。由专家们“自由”提出尽可能多的方案。
    头脑风暴法有6大原则：延迟评判、自由畅想、以量求质、综合改善、禁止批评、限时限人。

MECE

    MECE，是Mutually Exclusive Collectively Exhaustive，中文意思是“互斥，完全穷尽”。 也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并解决问题的方法。
    该方案有助于管理者进行问题或解决方案的排序、分析，并从中找到令人满意的解决方案。通常的做法分两种：
    一是在确定问题的时候，通过类似鱼骨图的方法，在确立主要问题的基础上，再逐个往下层层分解，直至所有的疑问都找到，通过问题的层层分解，分析出关键问题和初步的解决问题的思路；
    另一种方法是结合头脑风暴法找到主要问题，然后在不考虑现有资源的限制基础上，考虑解决该问题的所有可能方法。然后再往下分析，每种解决方法所需要的各种资源，并通过分析比较，从上述多种方案中找到目前状况下最现实最令人满意的答案。

六何分析法

    也称"5W1H"法：是对选定的项目、工序、操作或者问题，都要从原因（何因Why）、对象（何事What）、地点（何地Where）、时间（何时When）、人员（何人Who）、方法（何法How）等六个方面提出问题进行思考。
常常被运用到制定计划草案上和对工作的分析与规划中，并能使我们工作有效地执行，从而提高效率。在寻找方案时运用可以让解决方案更具备实效性。

举手表决

    举手表决有允诺确认和共识确认两种表决方式。
    允诺确认是在所有人都已充分发表意见，团队已达成共识时使用，用于突出承诺使用。常用的方式是“不同意的请举手”。
    共识确认则是部分人因为各种原因没有能充分表达出自己的看法的情况下使用。常用的方式是“展示1~5根手指，5表示非常赞同，1表示有严重疑虑，邀请展示1到2根手指的成员发言”。
这两种举手表决法在达成承诺上有奇效。 

鱼骨图

鱼骨图也称为因果图、因果分析图或石川图。它看上去有些像鱼骨，问题或后果标在"鱼头"外。在鱼骨上长出鱼刺，上面按出现机会多寡列出产生生产问题的可能原因。
鱼骨图有助于说明各原因之间如何相互影响。也能表现出各个可能的原因是如何随时间而依次出现的。这有助于将复杂问题清晰化、逻辑化，并迅速找到关键点着手解决。

思维导图

    又叫心智图，是表达发射性思维的有效的图形思维工具，是一种简单却又极其有效的思维工具。
思维导图运用图文并重的技巧，把各级主题的关系用相互隶属与相关的层级图表现出来，把主题关键词与图像、颜色等建立记忆链接，思维导图充分运用左右脑的机能，利用记忆、阅读、思维的规律，协助人们在科学与艺术、逻辑与想象之间平衡发展，从而开启人类大脑的无限潜能。

    思维导图在用于解决问题和寻找方案时跟头脑风暴法配合使用将具备神奇的效果。

小结

    如何开好迭代回顾会议（1）（2）所介绍的通用迭代回顾会议，都是从解决问题出发而使用的回顾议程与工具。事实上，并不是每次迭代回顾会议都必须是解决问题。你偶尔可以帮团队换换口味。

    另外，作为一个敏捷教练来说，不能全程把控迭代回顾会议。敏捷教练要坚信，团队能自己开好迭代回顾会议。但是，这并不表示敏捷教练在迭代回顾会议上就什么都不用做。

    《如何开好迭代回顾会议（3）教练、不同的口味》将希望给你带来新的启发、新的视角。

https://blog.csdn.net/xuefeimengli2007/article/details/70172249