每个问题我做一个回帖。

     Q1：当大boss或客户指定了任务交付的时间点，我们应该如何根据自身资源进行发布计划的制定呢？按照交付时间点压缩任务评估的时间（实际完成时间往往超过预估时间）？还是项目组正常进行时间评估，超过的部分统一安排加班完成？

    完全无视现实的“指定”，相对来说较少。 但突发性的“政治”任务有时也是无可避免的。实践证明，当程序员长期处于疲累状态，产出质量通常呈持续下降状态。

    如果长期处于(Boss的)高压下，情况得不到改善，你考虑辞职吧。如果是偶尔高压（加班加点），我认为还是合乎情理的。

    正常状况下，工作日8个小时的工作时间是评估的依据。你的计划也是按照团队成员每周工作40小时评估的。偶尔，可能需要你每周工作50个小时或者60个小时。

    预估时间是不能压缩的，而应尽可能的接近实际时间，这样的预估时间才有作为计划的意义。假设出现了预估需要50个小时，而可使用小时却只有40小时，那么只能增加人力资源或者增加上班时间。

    至于预估时间不准确的问题，需要将故事做得更加可控，更加可预测，然后借助故事点数或者是理想因子等方法和手段来增加准确性，不过这又是另外一个话题了。

Q2：从客户调研来的需求列表，如何转化成有效的原型图？由项目经理进行设计再与客户确认？还是由项目组参与人员共同设计项目经理定稿？

首先说一下，我们这里只谈项目，不说产品。

   在（完整的）敏捷项目中，通常会有个BA(Business Analyst)的角色,也即是我们国内常说的系统分析员。 他是介于技术和商业逻辑之间的角色。他对于项目组的主要作用是识别商业逻辑，并翻译成技术人员能理解的形式，以便实现之。在不同规模，不同类型的软件企业，对BA分工有所不同。但大致有个过程是不会变的，(通过沟通)读取客户思想后，将理解和设计以最容易理解的方式展示给客户看，达成理解上的一致性。

需求列表(Feature List)是一种需求固化形式，可以供BA和项目内起提纲作用（相比较瀑布型的需求规格书而言）。 需求还需设计成软件系统，这时候需要一些适合客户的设计组织形式：发布计划，原型图，流程图，详细设计，概要设计等。你看，展现设计手段有很多种，我们选择了文档化最少、最直观、相对容易理解的发布计划和原型图两种方式。

实质上，设计需要BA和架构师工作在一起，有时还需要交互设计师的人参加，确认工作主要是BA和客户的工作，项目组仅仅担负执行的工作。

但是现实是很残酷的，中小型企业内或者国内企业，作为项目经理的我们，通常要同时担任BA、架构师、项目日常管理等角色。

所以，在做某项工作的时候，清楚自己在戴的是哪个角色的帽子，不要弄混，导致过于惯性思维。

好处也不是没有的，你是“全才”

Q3：迭代计划进行中，对于客户突发的优先级高的需求和任务，是推迟本次迭代时间，还是将部分功能砍掉移植到下个迭代进行？

  后者，放弃功能，保证发布日期。

Q4：迭代计划的任务分工由项目经理指派还是由项目组开发人员自行领取，或者两者结合？

Q5：对于不同层次的开发人员，如何进行针对、合理的任务安排，使其在项目组中发挥应有的作用？

   这和开发方法学没有关系，主要和团队氛围有关。 一带一显然是比较有效的形式。两个人工作在同一个工作台上，对于增加低层次的人员帮助明显。 

Q6：如何对处于敏捷管理中的开发人员进行合理的绩效评估？

   单纯从理论上来说，预估和实际完成时间越接近的人，绩效应当是越高。因为这样的同学容易计划，很接近机器~~~汗

  实际考核中，单纯这个因素是远远不足的。有机会我给你看看我创建过的关键性指标考核细则，但还是不全面。

Q7：可以采用哪些方式增强项目组学习的气氛，提升各项目组成员能力，使整个团队不断成长？