您的位置:知识库 » 项目管理

动起来再调整 - 向项目经理推荐敏捷

作者: 大卫张  来源: 博客园  发布时间: 2011-07-03 10:55  阅读: 2145 次  推荐: 0   原文链接   [收藏]  
摘要:敏捷开发在中国很火热,但大家怎么用好敏捷开发?今天的新手软件项目经理应该了解敏捷如何用好。

  要成为一个好的项目经理需要学会逆水行舟。虽然顺水推舟有时也能到达目的地,但学会逆水行舟,你才能到达任何地方。

  “虽然很有道理,但我认为现实不允许,很多项目都有规定的期限。中途还有给客户演示效果,往往实际项目中都是按最后上线日期来进行项目规划管理的。”

  “写得不错,但是有些建议过于理想化了。毕竟说得很有道理,但实际中具体做起来又不是那么一回事了。”

  这是两位网友对《软件项目经理新手上路》的评论。这话很有道理,也是在现实生活中碰钉子碰出来的。在项目中确实存在很多限制,我们应该顺应限制,顺水推舟,否则会很难看。但如果这些限制间存在矛盾的话,如何能够做到顺水推舟呢?例如,项目资源限制与最后期限限制的矛盾。

  1. 向项目经理推荐迭代

  例1:项目经理张三到了一个新公司带一个项目。客户、产品、团队、流程、制度、环境、领导,一切的一切对于张三都是全新的。

  例2:开发人员张三因为优异的工作表现被提拔成项目经理。虽然张三对于项目中的业务、技术、产品和团队成员都比较熟悉。但是项目经理是一个全新的视角,张三需要从一个全新的角度去看待和处理问题。

  公司领导找到张三谈话,明确提出了项目的最后期限,希望张三能够给出一个计划。张三应该怎么办呢?

  虽然上述两个案例比较极端一点,但是在接手项目的时候存在几种未知情况是很常见的事情。在前面的建议中我们谈到了项目经理要承认有所不知,同时尽可能在公司内寻找一位项目经理导师。但这还不够,在应对项目的实际情况时,推荐采用迭代。

  迭代的时间一般是一到三周比较好。即使你的项目只有两周,也推荐分为一周的两个迭代。应该在项目经理导师的指导下,将需求划分到迭代中。每个迭代都应该像一个真实的项目,包含从需求到测试再到发布的全过程。

  2. 迭代的优点和注意事项

  麻雀虽小,五脏俱全,子项目也是一个完整的项目。以半年的项目为例,三周一次迭代,就能变成八个子项目,两周一次迭代,就是十二个子项目。

  无论你是新手项目经理,还是对项目本身情况不够了解的项目经理,你都可以从迭代中获得如下好处。

  2.1 好处:咱输得起

  分成迭代的第一大好处就是咱输得起。如果一个项目只有一次实施机会,如果完成的不好,就只有完蛋。而换成迭代后,一个迭代完成的不好,咱输得起,下个迭代想办法追回来。

  2.2 好处:先动起来

  相比以前漫长的计划协调、需求调研、可行性分析等等过程,迭代让你能够快速启动项目。专注于第一个迭代的目标,从而很快就能有产出。

  2.3 好处:暴露问题

  对一个项目而言,其实很难完全预测问题会出现在哪里。是团队人际关系、设计开发能力、刁钻的客户、资源不足,还是其他问题?要预测全部问题并给出完美的答案解决是几乎不可能的。而迭代能够帮助暴露这些问题,不需要老是拍脑袋,投入资源去处理可能根本就不会发生的风险。

  咱输得起,毕竟只是一个迭代嘛。项目的大问题就这样变成了迭代中的小问题,而项目经理经常处理这些小问题,经验就积累起来了三。

  2.4 好处:快速积累经验

  相比以前漫长的项目周期,迭代可以帮助你快速积累项目管理经验。除了通过解决问题积累经验外,还可以多做尝试。既然咱输得起,咱就敢在合适的情况下不断尝试项目管理的想法和做法,而不像以前必须对公司的标准做法生搬硬套,以便在项目失败后少被挑刺。

  2.5 好处:辅助沟通

  领导愿意在有产出的项目上继续投入,却不愿在项目早期花太多时间给你磨嘴皮讨价还价。第一个迭代的产出可以帮你大忙。领导你看,我们的产出是这些,但是还有些困难,是不是帮解决下呢?这个时候领导也会变得好说话些。客户也一样。人皆如此,要创造锦上添花的机会,别老是叫别人雪中送炭,很辛苦的说。(至于给领导的计划,就告诉他在用敏捷,然后给一个分迭代的计划就好。)

  2.6 好处:持续成长

  每一个迭代都会有收获、有产出,而下一个迭代会建立在上一个迭代的基础上。在这个过程中,你、团队、技术、业务、流程等都可以持续成长。

  2.7 注意事项

  全讲好处了,你心动了没?要使用迭代还是有些注意事项的。迭代需要改变一次性完成的设计和开发方式,并且在后期回归测试的工作量会明显增加。需要在项目经理导师的指导下,引入对应的实践逐步解决。(话说不用迭代,采用老方法,一样有注意事项。)

  3. 继续演化

  在确定了使用迭代后,需要从原有的整体需求中取出一块作为迭代的需求;需要在迭代前召开会议,和团队一起了解迭代需求,并制定迭代的开发计划;每天早上和项目团队一起开个会了解下有没有问题,进展是否顺利;在迭代结束时需要检查迭代需求是否切实完成(通过测试并发布);在迭代结束后,举行回顾会议,和团队一起巩固做得比较好的部分,对发现的问题需提出改进方案。

  也需要自己进行一下回顾,看下自己在这个迭代中哪些地方做得好,哪些地方还可以提高;哪些方法有用,哪些方法效果不佳,下次迭代采用什么方法;项目中还有什么问题,领导和客户的反馈怎么样;需要采取哪些措施,需要进行哪些沟通。

  这么一步步来,好像敏捷就不远了。这不,除了角色和燃尽图外,Scrum的其它要素就齐了。C项目就是这么一步步走过来的,虽然由于组织原因,C项目的敏捷实施并不完美。

  你是不是也想试试呢?(尝试有风险,请在你的导师指导下进行,呵呵。)

0
0

项目管理热门文章

    项目管理最新文章

      最新新闻

        热门新闻