www.Treetops.Com.cn 先给团队成员1周的任务，如果自己管理的不好，说明个人计划和管理能力偏弱，则改为给3天任务，还不行则改为给1天任务并进行培训。如果管理的很好，则给2周的任务，2周任务还能够管理的很好则可以给1个月的任务再带两个人，逐步从个人管理过渡到小组管理再过渡到项目管理。6 f/ E1 p; l: E
, } i1 s9 e! z B o }www.treetops.com.cn' F2 d+ q: `2 y: }
一件事情项目经理知道如何做，也有具体做的经验。那么他可以选择团队里面最适合做这件事情的人来做。如果项目经理不知道如何做，则选择团队里面他认为最合适的有能力的人来做。第一种情况风险项目经理可以完全把控，第二种情况虽然基于充分信任和授权，但是风险很多时候却都在被授权人处。这是IT项目经理是否懂技术的一个区别。
7 t4 M6 }: ]' E" v* T' Z2 c" s& X
- W6 q# u, i+ P6 x% Vwww.treetops.com.cn
7 F( P, F4 Y! K$ D) E 一个项目，应该留多少的进度缓冲呢？这个和项目周期和项目允许的进度偏差都相关。如果一个项目允许进度偏差20%很多时候可以不预留缓冲，因为延期20%已经是缓冲。如果一个项目允许进度偏差为0%那可想而知我需要留足够的项目缓冲。如果按照三点法估算，一件任务最悲观是16最可能是12最乐观是8可以考虑(最悲观-最可能)/2作为缓冲时间。也就是说项目周期为14天，最可能是12天完成，留2天缓冲。如果按最悲观来留4天缓冲，那么项目进度把控就没有意义和挑战，不是项目进度管理水平高，而是本事预留缓冲太多了
* l6 t+ z' n9 @ 5 z- t6 A2 l0 Y) w
www.treetops.com.cn
9 G* y/ s% g/ T4 p) ^: a: E, H 敏捷项目管理中的SCRUM核心是什么？原来讲过很多，包括迭代，可视化，短周期，持续集成等。这里要看到其一个核心机制就是高速的短周期迭代，并在迭代过程中自适应调整。做IT项目我最好不要去假设需求不变化，因为这个根本就不成立，而是应该考虑如何通过SCRUM核心价值观，通过采用相关的方法工具和技术去应当变化，动态适应变化。
5 O* A& D- U/ L8 _1 H$ h" C
/ _* B/ V& Z' t. jwww.treetops.com.cn. O" t- A' Q- I4 d: A# d! R) B) g
来看看团队中出现意见冲突和分歧的时候应该如何决策？对于需求问题，需求分析师具有最高的决策权，但是需求分析师不能跨边界决策采用的实现方法和实现技术，除非客户明确进行了约束。对于实现方法和技术，架构工程是具有最高的决策权，要保证高度的概念完整性，即使可能在某个事件上的决策不是最优也不要紧，一致性的保证往往比单点最优更加重要。
+ N) m: {- H, s$ k5 }
/ _& y' p: m0 x4 U3 s# bwww.treetops.com.cn& d9 f/ h! Q ~/ B7 w3 b
敏捷项目管理中强调过程，但是必须保证核心过程不能裁剪，又保证任何不增值的过程都排除出去。任何一个过程的保留必须要有存在意义。敏捷里面强调沟通，但是同样任何不增值的沟通，重复的沟通，由于前期团队公用词汇表没有形成导致的沟通都需要清楚。而如何看待和选择核心过程呢？这个和团队本身的成熟度有很大的关系，随着团队的成熟核心过程会越来越少，因为大家已经能够很默契的沟通和协作。而对于核心过程的定义可以从以下几个方面来考虑：
: u7 j! c( d6 j4 G5 _ B : B: X. L" z, F k$ w
能够尽早的暴露项目关键问题的过程，一定是核心过程。如持续集成和冒烟测试，站立会议等。 能够最大化的减少返工工作量的过程，一定是核心过程，如需求开发和评审。 |
