【标题】敏捷转型实战演练
【字数】982
给自己一个提醒，目前自身来说还是有拖延症的影子，原计划周一就要输出的敏捷转型流程文档，今天才去找沛杰去了解。拖后了两天时间，要进行跟进改正。
今天找到叶导师，咨询了他的业务线进行敏捷转型开发之后的一些问题，包括：
1、敏捷开发每天要做什么
2、敏捷开发的几个关键会议
3、敏捷转型之后对团队的好处
4、敏捷转型之后未解决的问题
1、每日站立会
站立会需要定时开，形式不重要，大家在工位站起来就可以开始。主要的内容是每日开发进度的同步，开发上遇到的问题，需要的支持等信息，时限15分钟内。
2、每周迭代回顾会议
形式：每个人都需要参与进来，把需要回顾的信息都写在一张小卡片上
a）本次迭代做得好的事情，需要具体案例，不能只是写什么负责任之类的虚话，回顾好的事情，有利于激励自己包括团队。
b）本次迭代可以做得更好的地方，不能满足于当前的解决方案，我们还能有更好
c）为下一次迭代做些什么准备的事情
d）为本次迭代评个分，如果是最低或者最高，需要问为什么是这个分数
最后需要把会议上的卡片内容进行回收汇总。
3、每周计划会
回顾会和计划会建议是当天完成，其实听到这里的时候，心里面是很忐忑的，因为目前我们的版本发布比较频繁，临时需求又比较多，计划会议要求PO在上一周就要想好的需求内容，计划会当天必须全部评审完毕，在下周的其他时间，不在进行其他需求评审。在进行评审之后，需要当天立刻输出工时安排，保证每个开发在下周都有明确的开发任务可做，且工时覆盖接下来的工作日4天。
每个需求任务的评审要求团队每个人都要达成共识的。
4、好处与未（待）解决的问题
以上几个敏捷转型的形式好处很明显：
大家参与度会很高，目标统一，信息透明，分享度高。本次敏捷转型使用的工具是Jira，Jira要求每次都只能只有一个进行中的迭代版本，这回大大提供每个成员的专注度，输出高质量的交付产品。
当前未解决的问题
输出的效率是没有提高的，如何科学的度量我们每次迭代版本的任务限额也需要一个很规范的标准。同时，虽然说我们都任务我们做的东西是业务想要的，都是最紧急的。但是会导致一部分的相对不紧急但是重要的需求交付时间会拉长，每个业务都会说自己的需求是重要的，紧急的，这就对PO产生了很大的挑战，如何根据最有业务价值的标准进行优先级排序，任重而道远。
另外本身我们产品线可能特殊一点，PO长期与开发团队只能进行线上沟通，沟通成本和效率有所欠缺。
