如何把敏捷思想融入到瀑布式开发环境中(5)

　　预测性的元素位于信封框架的第二层和第三层。第二层信封包含的是是项目中要计划和管理的瀑布模式中的元素。硬件部署就是一个很好的例子。第三个信封包含的是项目与企业中的其他项目组合要交互的工作内容。在这一层，项目经理需要与外部项目协调、处理企业发布计划和企业报告。

　　第二个信封 预测性元素

　　预测性元素的这个信封包含了没有在敏捷模式中管理的项目工作。一个很好的例子是为项目获取新硬件。期望新硬件在迭代一开始就采购好、并且在迭代期间就安装好，这是不合理的，尤其是当迭代非常短时，例如只有1-2周的迭代时间。按月来衡量硬件的交付周期并不罕见。采购和实施硬件的工作不先做好充分的计划，对于项目经理来说是不够专业的，预测性元素所在的信封提供了一种框架来管理这类工作。团队在做高层次的初步计划时，就应该列出迭代对预测性元素的预期要求。此外，如果是按顺序式模型管理项目的，那么企业测试是在这个信封里的。一些组织虽然能够按迭代管理企业测试，但是如果需要配合企业发布委员会来管理全部的发布时间表，那么企业测试也应该放在第二个信封里。但是，如果团队能够按迭代模式交付成果，并且按迭代模式执行单元测试/组件测试和集成测试、向最终用户演示可工作的软件，企业测试执行起来很可能会更快。我看到过给定六周时间来做的企业级用户可接受性测试，按迭代模式只用了20分钟就完成了。

　　第三个信封 企业整合

　　第三个信封包含了敏捷项目跟其它的企业项目组合、项目发起人、督导委员会、高管交互所做的工作。在信封框架的这一层，项目经理负责项目管理、解决项目和项目组合层级的问题。目的是让敏捷团队可以完全不必关注这些事情。例如，项目经理负责与职能经理一起识别并解决项目组合与项目的问题。在处理跨项目的依赖关系时，可能需要由项目经理和敏捷团队负责人一起识别依赖关系并确定它们对项目的影响，重要的是避免让正在工作的敏捷团队受到影响。如果确实需要敏捷团队参与，建议最好等到迭代计划完成了再打断他们，以便让团队能专注于执行迭代工作。

　　这一层也包含了项目经理向企业管理层汇报项目状态的工作内容。项目经理需要像翻译一样，把敏捷指标转化成可以接受的企业报告的结构。敏捷对完整、勇敢和透明的关注，使项目经理很容易就能获取所要求的任何报告结构的信息，包括挣值(Suliaman，2007)(Rusk，2009)。可能出现这种情况：随着组织中成功的敏捷项目越来越多，企业开始修改报告的结构，以包括进一些敏捷的元素。不过无论如何，项目经理都要清楚地向企业汇报项目的健康状况。这些报告可能也会用来向管理与督导委员会作汇报。在信封框架的这一层级上，项目经理和项目发起人一起来管理项目和产品的关系，并确保项目范围、进度和预算是受控的。

　　最后，第三个信封还包含部署项目交付物到企业生产系统的内容。因为目标是要限制对敏捷团队工作的影响，这可能是管理敏捷项目最棘手的部分。项目经理和敏捷团队负责人应该一起制定项目发布计划。敏捷团队的最终目标是实现无缝部署，这样就不会对工作中的团队产生影响。但是，很可能项目团队需要从迭代中分出一部分时间用于规划、部署和签出发布包。如果可能，应该从迭代中分配一小部分储备时间(减少他们的预留时间)，从团队专门抽出一个人来负责处理部署问题，以使部署中出现任何问题都能被迅速解决。

　　总结

　　在瀑布式和敏捷式项目混合的环境中使用敏捷方法是复杂的。项目经理必须高度注意产品需求和项目需求的区别，按项目发起人的委托来管理项目的范围、进度和预算。项目经理可以使用信封方法来维持三者之间的关系：敏捷团队、项目中的非敏捷元素、企业中其它因素。

　　我经常被问到在敏捷环境中，项目经理的角色是怎样的。他们害怕在敏捷项目中不再需要项目经理这个角色了。在业务背景简单(如小型或中等规模的业务)的小型敏捷项目中，项目经理是不需要的。想要指挥项目团队工作的项目经理在敏捷项目中也没有合适的角色。怀着为项目服务的心，并且愿意迎接更大型项目的挑战的项目经理，在敏捷项目中将有不止一个角色。对项目的成功他们是必不可少的。

　　关于作者

　　Joseph Flahiff是一位广受欢迎的演说家和项目交付顾问。他通过综合敏捷、精益和新兴的项目管理方法，帮助企业组织改善他们的项目交付物。作为一位在敏捷和传统项目管理方面具有15年以上经验的专家，Joseph在世界各地讲授敏捷模式和瀑布模式的整合方法。关于在企业中敏捷项目管理最新趋势的视频、文章和免费资源可以在他的Whitewater Projects博客中找到。

　　参考文献

　　A tale of two teams. (2008, April 25). Retrieved January 29, 2011, from Youtube.com

　　Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al. (2001, 2 11=13). The Agile Manifesto. Retrieved 1 21, 2011, from agilemanifesto.org

　　Cassidy, D. (2002, 5). Quantum Mechanics: 1925-1927 THE UNCERTANTY PRINCIPLE. Retrieved January 20, 2011, from American Institute of Physics

　　Ebert, D. C. (2009). Software Product Management. Crosstalk the Journal of Defense Software Engeneering, 15-19.

　　Hunt, A. (2010, September). The Agile Manifesto a decade later. (J. Flahiff, Interviewer)

　　Legorreta, C. W. (2009, April 2). Beyond waterfall and agile methods:Towards a new contingency model for IT Project Management. Retrieved January 30, 2011, from Social Science Research Network

　　Rusk, J. (2009). Earned Value for Agile Development. Retrieved January 30, 2011, from agilekiwi.com

　　Schwaber, K. (2010). Scrum.org. Retrieved January 30, 2011, from Scurm.org

　　Schwaber, K., & Sutherland, J. (2010). Scrum Guide. In K. Schwaber, & J. Sutherland, Scrum Guide (p. 5). scrum.org.

原文转自：http://www.ltesting.net