Johanna Rothman——把敏捷项目扩展为敏捷计划

Johanna Rothman在OnAgile2016题为《把敏捷项目扩展为敏捷计划:自主、合作、探索的小世界网络》的演讲中,她鼓励观众使用公司内已有的小世界网络来帮助改变、沟通和整合。此外,她推荐了不同的方法来加强这些小网络,使它们能够改善交付大型功能程序的流程。

Rothman是《敏捷和精益项目管理:将合作扩展到整个公司》(Agile and Lean Program Management: Scaling Collaboration Across the Organization)的作者。她指出,大多数公司有一个非正式的网络,经常用来传播谣言,也可以以强大的方式支持公司的需求。当与社区实践和路线图相结合使用的时候,这个网络也可以为项目成功做出贡献。

Rothman说“做大事,要从小处着手”。她指出,许多小的、基于团队使用敏捷实践的流程用在大项目上也一样可以和谐运行。定期地完成功能或用例就可以获得更大的透明度,能更加清晰地和更频繁地获得项目风险信息。有一些做法,比如运行两个星期或更少时间的迭代,或者完成能够在一两天内完成的小交付,都可以帮助团队频繁地得到对于他们正在进行的工作的反馈意见。对交付的功能进行测量也是有用的,因为这些构建块可以通过业务和技术的手段进行跟踪,以查看项目完成的进展情况。

对于项目管理方面的实践,Rothman建议的做法是采用滚动波路线图——频繁地规划短时间的界限和在这些短时间框架上建立稍微长一点约三个月的愿景。每个月的内部交付有助于建立每季度的版本,以发布到生产(或生产阶段区域)。每一次内部交付后都更新计划,这将有助于让每个人都意识到变化和障碍。在大型的项目中,这些路线规划可以在任何相互依存进行管理的地方进行,而不是只是在两个或多个团队的内部进行。

此外,Rothman鼓励以流动和不断变化的方式进行系统架构工作。她指出,在“最负责任的时刻”,提供一个系统架构草案,比试图在任何开发活动开展之前确定一个工作架构更有用。软件时时在变化,Rothman建议我们要接受这样的变化,以确保团队能在该架构中得到指导。

作为管理项目的一部分,Rothman建议创建两个主要的团队来驱动大型项目的交付——核心团队和技术项目团队。核心团队旨在协调公司各个和项目相关部门(技术部门、人力资源管理部门、法务部门、市场营销部门等等)的工作。这个团队引领着公司中的整个项目的商业价值。技术项目团队着眼于风险评估、管理问题,并确定在公司的技术领域内的变化。这个团队由系统架构、软件程序管理和项目产品经理三方为代表领导运作,方能正常运作。

在Rothman结束演讲之前,她提供了一些导向性建议。首先,判断出在哪里会习惯性地阻碍项目。第二,尽可能保持发展势头。最后,任何项目的成功都依赖于合作——使用一些正在使用的小型网络,并用路线图引导项目的发展,以保持目标清晰、明确。

本文转自d1net(转载)

时间: 2024-09-25 10:08:00

Johanna Rothman——把敏捷项目扩展为敏捷计划的相关文章

敏捷项目估算之故事和点数

引言 当你要雇一位漆工来装饰你的房子,或者一位修理工来修你的车时,你会要他们先给个估算,对吗? 你需要知道大概会花多少钱,需要多长时间.这是常识. 然而经验告诉我们什么?初始的估算和最终的账单有多大差距?很有可能漆工会发现有松动的石膏需 要铲除,墙面需要修补和重新粉刷:修理工一定会发现要让你车子重新上路还有些其它的问题要解决. 在1951年的<纽约客>杂志中有这样一幅漫画,Syd Hoff画了一个修理工对他的客户说: "当然,那不过只是个估算,实际的花费一定会更多" 如果漆

优秀的敏捷项目经理是项目成功的尚方宝剑

如果按照思维定式来考虑已有的Scrum框架,项目中本没有敏捷项目经理(Agile PM)这样的角色.而在另 一些敏捷方法中--例如特征驱动开发(FDD)人们仍然依仗项目经理(PM).但项目经理的角色已更多转变 为负责项目行政方面,而非负责协调开发团队及其活动方面,或是处理资源问题方面(也远非项目管理知识体 系--PMBOK中所描述的传统意义上的项目经理).仍旧以特征驱动开发(FDD)为例,以上描述的是开发经理 的职责而不一定是项目经理的职责.在战术层面上,敏捷项目经理应该比普通项目经理看得更远,

业务分析师在敏捷项目中的作用

敏捷http://www.aliyun.com/zixun/aggregation/13764.html">软件开发实践的文化中存在着一个断层,该断层同样体现在许多敏捷团队中.这个断层就是业务分析人员在敏捷项目中的角色--谁来担任这个角色?它的作用 和价值是什么?它又是如何发生改变的?这种情况的潜台词(其实我曾至少听人说过一次)就是:"我们不需要什么见鬼的分析师!".无需赘言,我当然认为这是 大错特错!在本文中,我证明如下观点:只要以正确的方式向业务看齐,业务分析师就可

敏捷项目中的安全需求管理

在软件开发初期处理安全需求是防止安全问题最经济的方式.大多数安全需求都属于非功能性需求(Non-Functional Requirements ,NFRs).很多从业者发现,在敏捷项目中处理安全和其他NFR非常具有挑战性.原因有二: 匹配NFR和特性驱动的用户故事需要付出很大努力: 安全控制常因缺少可见度而被忽视.敏捷过程容易让团队不自觉地侧重于那些可以直观改善客户体验 的新功能开发或缺陷修复. 在本文中,我们会探讨以上两个问题. 在用户故事中处理NFR 敏捷专家们提出过一些方法,用以定义用户故

最近的一次敏捷项目Scrum经验总结

Team刚刚完成了一个敏捷项目,做一下项目总结,以备以后借鉴和提高. 需求 - 沟通 – 人 - 过程 - 工具 项目要成功的最关键因素是什么?软件要快速高效又高质量的提交靠的是什么?有人说最关键是项目经理,关键是沟通,有人说是技术设计,有人说是对需求的把 握- - 从我看来,都是盲人摸象,项目要成功,软件要快速高效又高质量的提交,靠的是多重因素的整合和平衡:首先要对需求的准确理解和把握,贯穿全流程的沟通,做 项目靠人,对人/士兵的管理(物质.心理),适合组织的先进的过程(开发,测试,评审,组织

《规范敏捷交付:企业级敏捷软件交付的方法与实践》——3.2 Scrum

3.2 Scrum Scrum作为一种核心敏捷方法,所表达的是非常出色的想法,在如今的敏捷团队中得到了广泛应用.但是,Scrum有意不提供方法指导如何将这些实践应用到框架中,而是由团队自身去发掘哪些实践对这个框架有价值有帮助,并决定是否采用它们.另外,它的重点主要在于敏捷交付的产品构造阶段的方方面面.从图3.2中我们也可以看出,Scrum生命周期重点关注敏捷交付的产品构造阶段.下面列出在DAD过程框架中用到的核心Scrum实践: 产品Backlog(工作项列表).在Scrum中,产品Backlo

javaee-Javaee 项目扩展当中遇到的问题

问题描述 Javaee 项目扩展当中遇到的问题 项目最初开发是采用SSH框架的,其中有个功能是从数据库表中获取数据,然后生成报表 现在想对这个功能进行扩展,需要从另外的表中获取数据,生成同样格式的报表. 即现在用户可以选择,是从表A中获取数据,还是从表B中获取数据,然后生成报表. 我想请教各位高手,我是应当在DAO层.Service层中重新实现一遍生成报表的功能,还是在原来的代码当中加if else进行判断呢? 我的困惑是,如果我重新实现了一遍生成报表的功能,就相当于重复造轮子,以后还要维护相同

eBay再次扩展全球运送计划(GSP)

7月17日消息,跨境电商平台eBay再次扩展全球运送计划(GSP),在原有的54个可送至国家列表中又加入了6个拉美国家,将覆盖更广泛的美洲跨境消费者. 亿邦动力网获悉,从7月21日当周开始,智利.哥伦比亚.哥斯达黎加.多米尼加共和国.巴拿马以及特立尼达和多巴哥共和国的买家将可使用eBay全球运送计划. eBay指出,今年拉丁美洲的电子商务销售有望增长19.8%,达到576.9亿美元,而跨境电商在拉丁美洲的发展也具有很大的潜力.有了全球运送计划,一方面,买家将可获得参加此计划的卖家提供的各类丰富产

甲骨文合作伙伴网扩展Oracle Exastack计划

北京, 2014年7月2日--如今的数据量正在以前所未 有的速度增长,应用提供商需要一个强大的.可扩展的高性能基础架构,以根据自身业务的发展速度来管理和分析数据.为了帮助独立软件开发商(ISV)应对这些挑战,甲骨文合作伙伴网(OPN)近日宣布扩展其Oracle Exastack计划,为合作伙伴提供机会,以实现面向甲骨文大数据一体机和甲骨文数据库一体机的Oracle Exastack Ready或Optimized状态.   该计划在第六届甲骨文合作伙伴网(OPN)全球启动大会上推出,此次大会以"