敏捷开发

三个月适应一种工作节奏-敏捷/快乱中求序，熟悉一群人-多团队协作/跨部门沟通。从最开始的慌乱无序到后面的焦虑不安到现在的乱中求序各个解决，三个月的体会很多很杂很乱，觉得自己还有很多东西不懂，多到怀疑自己当初选择产品这条路是不是错误的。最后给自己的话是“脑洞不够就多看多想”，现在看起来起码自己还是个合格的员工。毕竟三个月了，还是需要总结，尽管现在的主旋律还是会乱得不可控制……

敏捷的工作流程初体验：

角色-po（产品汪一枚，准备项目目标并将项目目标分解成可执行的需求列表。确定好优先级，决定各个冲刺要完成的需求。），master（冲刺负责人，负责需求安排，技术问题把控，进度把控等。），团队（项目经理，开发，测试，运维等）

过程-需求计划会（全体成团参加，po讲解本冲刺的需求，和成员一起确定），站立会（全体成员讲昨天完成工作情况，今日计划完成以及现在遇到的问题，该会议大概进行15分钟），bug评审会（发布前两天回顾本冲刺测试提出的还未解决的bug，确定是否影响上线并给出解决方案），项目验收展示（上线后公布本冲刺的发布结果并展示成果），回顾会（全体成员参加，列出本冲刺中的优点，缺点，问题以及解决方案）

三个月体验下来，这套流程很适合现在公司的情况，小步快跑/快速迭代。但其中的问题也很明显，需求计划会一般需要一天，参与者对需求信息的接收情况并不是很理想。因为很多内容并不需要每个人都了解，当遇到听起来和自己无关的需求时，开发可能已经开始神游了，当然了这个有可能和需求的讲解者有关。迭代开始前几天本团队的测试可能需要等技术提交功能才能开始测试，迭代后几天测试忙着测试，技术修修bug，可能存在工作不饱和的情况。这需要产品和master前期沟通迭代需求会的时候能有一个整体把控。

回顾会上一个永恒的问题就是需求不够详细……有完美并一次到位的需求么，有不挖坑的产品么～经历多了，遇到的坑多了就成了所谓的经验吧，我需要时间成为一个经验丰富的产品，路还长，我在路上走着，一步一个脚印。

最后还是走走文艺路线

很想说谢谢，很真诚的那种，尽管现在不是我曾经想象的未来……