Q：如何把控产品产出的进度？
A：把产品的工作也纳入项目管理，按时间盒子迭代，每个开发迭代周期开始之前都需要列好Backlog，屡次没准备好，可能不只是吐槽，还需要看看产品团队可能存在的问题：
1.人不够
2.能力不够
3.对流程规范不重视
Q：我们维持固定的周期迭代，那么是不是就要死守这个周期呢？如果出现延期或者提前结束怎么办？一个迭代到了时间未完成的话就终止，那么终止之后呢？放到下一个迭代做？
A：这里可以分成俩个问题，第一个是不是要死守迭代周期另外一个是团队不关心迭代完不成我们怎么办？
第一个问题：我个人倾向于不必，提前完成就提前结束，就是在计算Velocity的时候，麻烦一点。还有时间到了，没完成也结束，没完成的放到下一个迭代作为输入。
第二个问题：我们首先要探寻的团队成员为什么不关心，是因为觉得目标没意思？还是团队内部有其他问题？比如都不觉得是自己的事情或者觉得自己太在意的话会影响人际关系？还是自身的观念问题？ 我们可以考虑用以下方式解决：比如设定KPI可以设定迭代完成率达到百分之多少以上。
同时我们也可以在Retrospective的时候来看一下是森么回事，是目标没有挑战？还是团队内部有不和谐的因素，团队在做承诺的时候是不是太随意？最重要的是先要找出根源的问题，这样才能做出判断和找出解决方案。
Q：故事点估算如何考虑两个人共同完成一个用户故事的情况，是叠加还是按最长的那个来算？
A：这个问题和后面的一个问题类似，问题是既有客户端开发又有服务端开发的用户故事如何评估故事点？这俩个问题的共性是不同角色和不同职能的人做同一件事情如何去评估Story Point。
Scrum团队里面实际上团队看起来是一个团体，不希望大家能分得很清楚，希望大家都能做很多不同的事情，但在实际的执行过程中设计，开发，测试都有不同的专业，可以考虑看待成不同的任务。我个人比较倾向于把前端和后端的资源分开来评估，因为他们的分工是不同的。
Q：共享资源，如果团队成员服务于多个项目，有什么办法掌控不确定性和非专职性？
A：对于这个问题首先要看的是有多少个团队共享？属于哪种职能？是构架师、视觉设计师、交互还是某个模块的负责人？
如果是构架师，让他排个优先级，因为所有的依赖关系和重要性他是可以把控的，时间分配也可以控制，优先级低的部分因此可能会有一些等待;
如果是交互或者视觉设计师，可以考虑用看板这类的工具来看工作量，找到其中的瓶颈，因为会有上下游的依赖其中的一个环节。
如果是模块的负责人，这个问题比较常见，可能是这个问题的主要目的。首先，可能存在单点故障的风险，对于一个组织来说需要做一下负载均衡或者备份，比如培养新人，或者给有潜力的人留出空间。
其次，如果暂时没有办法解决，比如这位模块负责人不原意共享，或者没有合适的人来做这部分的事情，那瓶颈在这里，那就是要提高这位负责人的产出，保证他的专注，减少他的切换，保证他按照优先级来做。他的时间和精力是有限的，帮助他始终做最重要的事情，做完了再做下一件。
Q：开发的工作已经完成了，现在进入测试阶段，那么每日站会还开么？
A：对于这个问题我倾向于开，但在实际执行中会有不同的场景。比如开发的同学为什么没事做，他们可以做点什么？下一个版本的开始？还是和测试团队一起测试？比如Bug的数量和解决的难易程度，如果数量很多，或者很难，是不是可以用一个看板来管理，站会沟通一下。如果Bug数量也很少，半个小时干掉一个Bug，开发确实也无事可做，要不，就别开了吧。
Q：什么是自适应敏捷？
A：敏捷在落地的时候是需要根据实际情况来进行调整的，比如Scrum或者LeSS在实际使用的时候在落地时候也应该按照敏捷的拿来主义精神，不是照搬而是根据实际情况来使用。比如站会是不是必须这个也要看情况。
之前和一些业内比较知名的咨询师在沟通的时候，他们也提到说会根据实际的情况做裁剪，因为执行的时候是需要考虑到团队的成熟度和业务类型的和相关人员的接受程度，这些都不是一蹴而就的，当然最理想的状态是最后能做到完整的敏捷的实施。
Q：如何让团队认可每日站会、迭代计划会议等仪式感很强的会议？
A：我以站会举例。
首先是要看谁想开站会，是Scrum Master还是Manager？是PO还是团队成员？每个人的能使用的影响力或者权利是不太一样的，因此，可以的做法也不太一样，可以是强制，也可以是引导，或者算了。对，算了也是一个很好选择。
其次，看为什么要开站会，好处是什么？对于团队成员的好处是什么？团队知不知道这些好处和作用，有没有解决团队的问题，或者帮助团队成员解决了什么问题？
Q：敏捷项目管理与瀑布式项目管理优缺点？
A：这个问题比较大，大家可以在学习完《互联网项目管理微专业》这门课以后再思考一下。这边我讲俩个点。一个是区别，一个敏捷的缺点。
我认为最大的区别：在敏捷里，交付和反馈是重点，完成很重要，但可能不是最重要的。
缺点：大家可能认为敏捷很快，但其实恰恰相反，敏捷项目管理可能会使得项目花费的时间更长。
Q：传统瀑布开发的团队想转敏捷，如何分步进行，团队成员抵触较小？
A：对于这个问题首先要从产品层面为什么要做敏捷，对谁影响最大，支持和反对的人是谁，他们的诉求是什么？搞清楚这些就会知道你可以得到谁的支持和反对，在做的时候如果遇到困难就可以知道谁可以支持你，也可以评估一下，有这些支持和反对的情况下，转型是否能够做下去；
其次要搞清楚这件事对团队和团队成员有什么好处和坏处，因为团队成员只有清楚了对他们的好坏处之后他们才会在内心接受这个新的开发模式；
另外就是要搞清楚是否需要解决成员是否抵触的问题，至上而下和至下而上的方式是不一样 ；更加具体的说传统的瀑布开发转型成敏捷型，可以先从了解敏捷是什么，以及网易的方法来进行学习。
作者介绍
（本资讯于2017-12-29首次发布）
