今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin） 

检查小课堂
明天计划的事情：（一定要写非常细致的内容） 

看复盘项目
遇到的问题：（遇到什么困难，怎么解决的） 
收获：（通过今天的学习，学到了什么知识）

真、假敏捷开发。。。

、真敏捷还是假敏捷？

事业部是在去年年底开始实时每周一个版本的迭代，那个时候,在全公司我所在的项目组是第一个开始做频繁发布的。

在变幻莫测的互联网环境下，快速的响应和发布是非常必要的，并且能得到ABtest的快速验证。

但是在这种快速迭代的初步尝试中，团队慢慢出现了一些问题。

1.假敏捷-7个团队各自为营

们从一个需求从产生到落地的过程来看，首先需求的来源有一些问题。

3月份在敏捷诊断的时候，几乎所有的产品都把最需要解决的问题投给了“产品定位”。

产品定位可以没有明文规定，但是在快速奔跑的过程中，每个人都要有一致的目标。

当项目组的每个人对产品的理解不一致的时候，我们传达给用户的，也是一些非常矛盾的东西。

时，需求的产生是在每一条业务线中产生的；按照不同的业务线，产品、开发、测试被分成了7个团队，团队之间更多的是一些同步的工作，缺乏沟通和讨论。

没有总体的共识，一个APP被分为7个团队，需求的产生比较分离，没有重点。

在需求迭代的过程中，每个组是只有一个开发和测试加入到需求讨论中，最后把会议精神带回团队;更多开发和测试的同学是直接按照PRD进行开发和测试的——团队缺乏沟通，对需求细节的把控没有那么到位。

最后，在需求交付的时候，功能核对大概几种是在上线前1-2天。

这会导致很多风险项都没有办法提前暴露，需求理解不一致的情况没有办法得到有效的处理。

2.真迭代-两个团队试点，每周一个敏捷冲刺

敏捷项目启动初期，在面对一个需求从开始到落地的五个环节：“产品定位”-“用户定位”-“需求挖掘”-“需求开发”-“需求跟踪”时，几乎项目组所有核心人员都把最紧急、最缺失的一票投给了“产品定位”。

我们发现，因为没有清晰的产品定位，所以每个人的着力点是不同的；大家像一盘散沙，看似忙碌充实却绵软无力。最致命的是：因为没有清晰的RoadMap，大家走一步算一步的状态影响团队士气和凝聚力。

于是，产品团队利用将近一个月时间的依据公司战略、产品目标、用户需求和市场环境确定了清晰的产品定位“打造用户的专属摄影师”，以及根据产品定位确定了接下来1-2年的长期目标和近三个月的短期目标。同时，每条线也根据共同目标制定了版本迭代的计划。

“计划的结果是无意义的，价值在与计划的过程本身”，在互联网瞬息万变的环境下，RoadMap肯定是会变的，但RoadMap能够让全项目成员做到“心中有数”，往同一个方向一起冲刺，这就是它最大的价值所在。

在同一个产品目标下，我们把小组分为几个线，在产品内部共同讨论下形成了需求池。

在需求迭代对过程中，我们也发生了一些改变。

例如产品经理开始用用户故事去表达和拆解需求（用户故事会在接下来展开来说），基于用户故事，开发测试的同学参与到了需求细节的讨论中，逐步达成共识。

在需求交付时，大家能够按照故事点做得点对点的每天交付，甚至为了迭代目标的达成，出现交叉开发、交叉测试的现象。