本文将带你了解测试管理方法之动起来再调整 - 向项目经理推荐敏捷，希望对大家学测试管理有所帮助。

　　要成为一个好的项目经理需要学会逆水行舟。虽然顺水推舟有时也能到达目的地，但学会逆水行舟，你才能到达任何地方。
      　　“虽然很有道理，但我认为现实不允许，很多项目都有规定的期限。中途还有给客户演示效果，往往实际项目中都是按最后上线日期来进行项目规划管理的。”
    　　“写得不错，但是有些建议过于理想化了。毕竟说得很有道理，但实际中具体做起来又不是那么一回事了。”
    　　这是两位网友对《软件项目经理新手上路》的评论。这话很有道理，也是在现实生活中碰钉子碰出来的。在项目中确实存在很多限制，我们应该顺应限制，顺水推舟，否则会很难看。但如果这些限制间存在矛盾的话，如何能够做到顺水推舟呢？例如，项目资源限制与最后期限限制的矛盾。
    　　1. 向项目经理推荐迭代
    　　例1：项目经理张三到了一个新公司带一个项目。客户、产品、团队、流程、制度、环境、领导，一切的一切对于张三都是全新的。
      　　例2：开发人员张三因为优异的工作表现被提拔成项目经理。虽然张三对于项目中的业务、技术、产品和团队成员都比较熟悉。但是项目经理是一个全新的视角，张三需要从一个全新的角度去看待和处理问题。
    　　公司领导找到张三谈话，明确提出了项目的最后期限，希望张三能够给出一个计划。张三应该怎么办呢？
      　　虽然上述两个案例比较极端一点，但是在接手项目的时候存在几种未知情况是很常见的事情。在前面的建议中我们谈到了项目经理要承认有所不知，同时尽可能在公司内寻找一位项目经理导师。但这还不够，在应对项目的实际情况时，推荐采用迭代。
    　　迭代的时间一般是一到三周比较好。即使你的项目只有两周，也推荐分为一周的两个迭代。应该在项目经理导师的指导下，将需求划分到迭代中。每个迭代都应该像一个真实的项目，包含从需求到测试再到发布的全过程。
    　　2. 迭代的优点和注意事项
    　　麻雀虽小，五脏俱全，子项目也是一个完整的项目。以半年的项目为例，三周一次迭代，就能变成八个子项目，两周一次迭代，就是十二个子项目。
    　　无论你是新手项目经理，还是对项目本身情况不够了解的项目经理，你都可以从迭代中获得如下好处。
    　　2.1 好处：咱输得起
    　　分成迭代的第一大好处就是咱输得起。如果一个项目只有一次实施机会，如果完成的不好，就只有完蛋。而换成迭代后，一个迭代完成的不好，咱输得起，下个迭代想办法追回来。
    　　2.2 好处：先动起来
    　　相比以前漫长的计划协调、需求调研、可行性分析等等过程，迭代让你能够快速启动项目。专注于第一个迭代的目标，从而很快就能有产出。
    　　2.3 好处：暴露问题
      　　对一个项目而言，其实很难完全预测问题会出现在哪里。是团队人际关系、设计开发能力、刁钻的客户、资源不足，还是其他问题？要预测全部问题并给出完美的答案解决是几乎不可能的。而迭代能够帮助暴露这些问题，不需要老是拍脑袋，投入资源去处理可能根本就不会发生的风险。
    　　咱输得起，毕竟只是一个迭代嘛。项目的大问题就这样变成了迭代中的小问题，而项目经理经常处理这些小问题，经验就积累起来了三。
    　　2.4 好处：快速积累经验
      　　相比以前漫长的项目周期，迭代可以帮助你快速积累项目管理经验。除了通过解决问题积累经验外，还可以多做尝试。既然咱输得起，咱就敢在合适的情况下不断尝试项目管理的想法和做法，而不像以前必须对公司的标准做法生搬硬套，以便在项目失败后少被挑刺。
    　　2.5 好处：辅助沟通
      　　领导愿意在有产出的项目上继续投入，却不愿在项目早期花太多时间给你磨嘴皮讨价还价。第一个迭代的产出可以帮你大忙。领导你看，我们的产出是这些，但是还有些困难，是不是帮解决下呢？这个时候领导也会变得好说话些。客户也一样。人皆如此，要创造锦上添花的机会，别老是叫别人雪中送炭，很辛苦的说。（至于给领导的计划，就告诉他在用敏捷，然后给一个分迭代的计划就好。）
    　　2.6 好处：持续成长
    　　每一个迭代都会有收获、有产出，而下一个迭代会建立在上一个迭代的基础上。在这个过程中，你、团队、技术、业务、流程等都可以持续成长。
    　　2.7 注意事项
      　　全讲好处了，你心动了没？要使用迭代还是有些注意事项的。迭代需要改变一次性完成的设计和开发方式，并且在后期回归测试的工作量会明显增加。需要在项目经理导师的指导下，引入对应的实践逐步解决。（话说不用迭代，采用老方法，一样有注意事项。）
    　　3. 继续演化
    　　在确定了使用迭代后，需要从原有的整体需求中取出一块作为迭代的需求；需要在迭代前召开会议，和团队一起了解迭代需求，并制定迭代的开发计划；每天早上和项目团队一起开个会了解下有没有问题，进展是否顺利；在迭代结束时需要检查迭代需求是否切实完成（通过测试并发布）；在迭代结束后，举行回顾会议，和团队一起巩固做得比较好的部分，对发现的问题需提出改进方案。
      　　也需要自己进行一下回顾，看下自己在这个迭代中哪些地方做得好，哪些地方还可以提高；哪些方法有用，哪些方法效果不佳，下次迭代采用什么方法；项目中还有什么问题，领导和客户的反馈怎么样；需要采取哪些措施，需要进行哪些沟通。
      　　这么一步步来，好像敏捷就不远了。这不，除了角色和燃尽图外，Scrum的其它要素就齐了。C项目就是这么一步步走过来的，虽然由于组织原因，C项目的敏捷实施并不完美。
    　　你是不是也想试试呢？（尝试有风险，请在你的导师指导下进行，呵呵。）    

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标软件测试之测试管理频道！