信息系统IT项目管理杂谈

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

( Y7 Q( e) F( O) }8 pwww.treetops.com.cn
" e5 v& z$ g' m7 v% C# h 一件事情项目经理知道如何做，也有具体做的经验。那么他可以选择团队里面最适合做这件事情的人来做。如果项目经理不知道如何做，则选择团队里面他认为最合适的有能力的人来做。第一种情况风险项目经理可以完全把控，第二种情况虽然基于充分信任和授权，但是风险很多时候却都在被授权人处。这是IT项目经理是否懂技术的一个区别。

1 d, [+ m# S* b$ \, gwww.treetops.com.cn
一个项目，应该留多少的进度缓冲呢？这个和项目周期和项目允许的进度偏差都相关。如果一个项目允许进度偏差20%很多时候可以不预留缓冲，因为延期20%已经是缓冲。如果一个项目允许进度偏差为0%那可想而知我需要留足够的项目缓冲。如果按照三点法估算，一件任务最悲观是16最可能是12最乐观是8可以考虑(最悲观-最可能)/2作为缓冲时间。也就是说项目周期为14天，最可能是12天完成，留2天缓冲。如果按最悲观来留4天缓冲，那么项目进度把控就没有意义和挑战，不是项目进度管理水平高，而是本事预留缓冲太多了
$ d2 f  B9 L% C4 d' v
; b1 N# |. o( V) Zwww.treetops.com.cn
; F( I4 p; a! a; M% N 敏捷项目管理中的SCRUM核心是什么？原来讲过很多，包括迭代，可视化，短周期，持续集成等。这里要看到其一个核心机制就是高速的短周期迭代，并在迭代过程中自适应调整。做IT项目我最好不要去假设需求不变化，因为这个根本就不成立，而是应该考虑如何通过SCRUM核心价值观，通过采用相关的方法工具和技术去应当变化，动态适应变化。
* B8 h/ `, X4 U$ j
5 P: z8 g! r1 Rwww.treetops.com.cn
来看看团队中出现意见冲突和分歧的时候应该如何决策？对于需求问题，需求分析师具有最高的决策权，但是需求分析师不能跨边界决策采用的实现方法和实现技术，除非客户明确进行了约束。对于实现方法和技术，架构工程是具有最高的决策权，要保证高度的概念完整性，即使可能在某个事件上的决策不是最优也不要紧，一致性的保证往往比单点最优更加重要。
; i* N  T' Y- U- R
8 k' s) J9 W/ k# Rwww.treetops.com.cn
$ e% o; k. E$ Y% T 敏捷项目管理中强调过程，但是必须保证核心过程不能裁剪，又保证任何不增值的过程都排除出去。任何一个过程的保留必须要有存在意义。敏捷里面强调沟通，但是同样任何不增值的沟通，重复的沟通，由于前期团队公用词汇表没有形成导致的沟通都需要清楚。而如何看待和选择核心过程呢？这个和团队本身的成熟度有很大的关系，随着团队的成熟核心过程会越来越少，因为大家已经能够很默契的沟通和协作。而对于核心过程的定义可以从以下几个方面来考虑：

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