先给团队成员1周的任务，如果自己管理的不好，说明个人计划和管理能力偏弱，则改为给3天任务，还不行则改为给1天任务并进行培训。如果管理的很好，则给2周的任务，2周任务还能够管理的很好则可以给1个月的任务再带两个人，逐步从个人管理过渡到小组管理再过渡到项目管理。

一件事情项目经理知道如何做，也有具体做的经验。那么他可以选择团队里面最适合做这件事情的人来做。如果项目经理不知道如何做，则选择团队里面他们认为最合适的有能力的人来做。第一种情况风险项目经理可以完全把控，第二种情况虽然基于充分信任和授权，但是风险很多时候却都在被授权人处。这是IT项目经理是否懂技术的一个区别。

一个项目，我们应该留多少的进度缓冲呢？这个和项目周期和项目允许的进度偏差都相关。如果一个项目允许进度偏差20%，我们很多时候可以不预留缓冲，因为延期20%已经是缓冲。如果一个项目允许进度偏差为0%，那可想而知我们需要留足够的项目缓冲。如果按照三点法估算，一件任务最悲观是16，最可能是12，最乐观是8。可以考虑(最悲观-最可能)/2作为缓冲时间。也就是说项目周期为14天，我们最可能是12天完成，留2天缓冲。如果按最悲观来留4天缓冲，那么项目进度把控就没有意义和挑战，不是项目进度管理水平高，而是本事预留缓冲太多了。

在敏捷项目管理中的SCRUM核心是什么？我们原来讲过很多，包括迭代，可视化，短周期，持续集成等。在这里要看到其一个核心机制就是高速的短周期迭代，并在迭代过程中自适应调整。做IT项目我们最好不要去假设需求不变化，因为这个根本就不成立，而是应该考虑如何通过SCRUM核心价值观，通过采用相关的方法工具和技术去应当变化，动态适应变化。

我们来看看团队中出现意见冲突和分歧的时候应该如何决策？对于需求问题，需求分析师具有最高的决策权，但是需求分析师不能跨边界决策采用的实现方法和实现技术，除非客户明确进行了约束。对于实现方法和技术，架构工程是具有最高的决策权，要保证高度的概念完整性，即使可能在某个事件上的决策不是最优也不要紧，一致性的保证往往比单点最优更加重要。

在敏捷项目管理中强调过程，但是必须保证核心过程不能裁剪，又保证任何不增值的过程都排除出去。任何一个过程的保留必须要有存在的意义。敏捷里面强调沟通，但是同样任何不增值的沟通，重复的沟通，由于前期团队公用词汇表没有形成导致的沟通都需要清楚。而如何看待和选择核心过程呢？这个和团队本身的成熟度有很大的关系，随着团队的成熟核心过程会越来越少，因为大家已经能够很默契的沟通和协作。而对于核心过程的定义可以从以下几个方面来考虑：

  • 能够尽早的暴露项目关键问题的过程，一定是核心过程。如持续集成和冒烟测试，站立会议等。
  • 能够最大化的减少返工工作量的过程，一定是核心过程，如需求开发和评审。

(from: 人月神话http://blog.sina.com.cn/s/blog_493a84550100ktrx.html )