敏捷组织中PMO应遵循的准则 敏捷改变了人们的工作方式,不仅仅是开发部门,而且还包括其它的部门,例如HR.财务以及PMO等.在大多数组织中,PMO是一个控制体.它指导项目团队的规范.模板以及流程.目前,大多数的IT组织都敏捷化了. Nick Oostvogels,SkyCoach公司的项目经理及敏捷教练,最近发表了敏捷组织中PMO的新角色的文章. Nick说,组织敏捷带来了一些影响,例如业务单元有偏差.项目组合规划不满足敏捷的步调,以及项目管理办公室不知道如何支持敏捷团队. 一个经典的PMO突然

敏捷改变了人们的工作方式,不仅仅是开发部门,而且还包括其它的部门,例如HR.财务以及PMO等.在大多数组织中,PMO是一个控制体.它指导项目团队的规范.模板以及流程.目前,大多数的IT组织都敏捷化了.Nick Oostvogels,SkyCoach公司的项目经理及敏捷教练,最近发表了敏捷组织中PMO的新角色的文章.Nick说,组织敏捷带来了一些影响,例如业务单元有偏差.项目组合规划不满足敏捷的步调,以及项目管理办公室不知道如何支持敏捷团队. 一个经典的PMO突然必须处理敏捷项目时都会表现相同的方

所谓的"敏捷组织"其实并没有标准的模式,而且PMO(项目管理办公室)并没有一个标准的角色定义.有一个非常普遍的误解,公司在选择"敏捷"或者"瀑布"的开发流程时只能做二元互斥的选择,导致的结果就是一些公司会试着让他们的业务和项目严格遵循这种模式到一种极致的状态.而正确的解决办法应当是让开放方式去适应业务需要,并且很多时候,两种开发方式应当兼而有之.一般来说,任何PMO都有责任去最大化组织内部项目组合的投资回报率,他们通过以下方式去达成: 通过选择对

我: Tech Leader 团队:团队成员分布在两个城市,我所在的城市包括我有4个成员,另外一个城市包括SM有7个成员.另外由于我们的BA离职了,我暂代IT 的PO 职位.PM和我在一个城市,但他不参于敏捷的运作里面. 迭代: 双周 主要会议: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting. 现在有名外部敏捷教练在带着我们实施敏捷,不过从sprint3

我: Tech Leader 团队:团队成员分布在两个城市,我所在的城市包括我有4个成员,另外一个城市包括SM有7个成员.另外由于我们的BA离职了,我暂代IT 的PO 职位.PM和我在一个城市,但他不参于敏捷的运作里面. 迭代: 双周 主要会议: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting. 现在有名外部敏捷教练在带着我们实施敏捷,不过从sprint3

我: Tech Leader 团队:团队成员分布在两个城市,我所在的城市包括我有4个成员,另外一个城市包括SM有7个成员.另外由于我们的BA离职了,我暂代IT 的PO 职位.PM和我在一个城市,但他不参于敏捷的运作里面. 迭代: 双周 主要会议: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting. 现在有名外部敏捷教练在带着我们实施敏捷,不过从sprint3

我: Tech Leader 团队:团队成员分布在两个城市,我所在的城市包括我有4个成员,另外一个城市包括SM有7个成员.另外由于我们的BA离职了,我暂代IT 的PO 职位.PM和我在一个城市,但他不参于敏捷的运作里面. 迭代: 双周 主要会议: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting. 现在有名外部敏捷教练在带着我们实施敏捷,不过从sprint3

我: Tech Leader 团队:团队成员分布在两个城市,我所在的城市包括我有4个成员,另外一个城市包括SM有7个成员.另外由于我们的BA离职了,我暂代IT 的PO 职位.PM和我在一个城市,但他不参于敏捷的运作里面. 迭代: 双周 主要会议: Grooming, Sprint Planning, Daily Standup Meeting, Sprint Review Meeting, Retrospective Meeting. 现在有名外部敏捷教练在带着我们实施敏捷,不过从sprint3

注:由麦思博(MSUP)主办的2013年亚太软件研发团队管理峰会(以下简称MPD大会)分别于6月15及6月22日在北京.上海举办,葡萄城的部分程序员参加了上海的会议,本文是参会的一些感受和心得. 今年的大会延续往届模式,以产品创新.团队管理.架构设计.开发管理.测试管理等五个维度作为五个分会场的主题.对于今年来在软件研发中百谈不厌的敏捷开发的问题,大会从团队管理.开发管理等多个角度为与会者全面剖析敏捷开发中所涉及的种种问题,不单单聚焦于敏捷开发本身,更将视线拓展到管理整个敏捷开发团队上. 讲师都

携程敏捷总动员是由携程技术管理中心(PMO)发起的敏捷项目管理线下主题沙龙活动(每2月一次),旨在和研发管理同行分享互联网行业第一线的优秀敏捷实践.     5月10日携程敏捷总动员-OKR专场活动,携程PMO团队邀请了来自Worktile和携程黄埔训练营的两位OKR专家,为现场的参会者带来了OKR在研发团队如何落地的精彩分享.   研发管理圣器   第一位分享嘉宾是来自WMC首席咨询顾问/管理合伙人,王晓萱.   晓萱老师以让人头疼的研发管理为开题,讲述了Agile.Devops.OKR在企业

摘要: 敏捷转型成功的企业究竟是从老总开始?还是从项目经理开始?还是团队本身具有这种意识?相信还有很多想要转型敏捷的公司都存在这样的疑问. 从06年首届敏捷中国开发者大会召开到现在,敏捷方法在国内的应用不断增加,关于敏捷转型的热度只增不减.敏捷转型成功的企业究竟是从老总开始?还是从项目经理开始?还是团队本身具有这种意识?相信还有很多想要转型敏捷的公司都存在这样的疑问. 在企业中,除了老总.项目经理和团队,还有产品经理.测试.运维.PMO.质量管理.人力资源.行政财务等等角色.企业想要进行敏捷转型

本系列的第一篇[用户故事驱动的敏捷开发 – 1. 规划篇]跟大家分享了如何使用用户故事来帮助团队创建需求的过程,在这一篇中,我们来看看如何使用这些用户故事和功能点形成产品backlog.产品backlog是敏捷开发中用来管理需求列表,排定优先级,形成迭代计划,组织开发/测试和交付过程的工具.可以说,产品backlog是一个敏捷团队管理开发过程的核心,所有的活动和交付物都围绕backlog来进行.一旦需求明确,我们就必须在开发过程中持续的跟踪backlog内容的实现和交付过程,确保我们的想法可以按

1.我们知道敏捷开发是一套流程和方法的持续改进,通过快速迭代的方式交付产品,从而控制和降低成本.但是在实行敏捷初期,往往看不到很好的效果.这里面,您觉得问题主要出在哪?团队应如何去解决问题?金根:我认为敏捷通过快速交付主要目的之一是快速上市,快鱼吃慢鱼,时间往往能够决定产品的价值,例如很多互联网公司:而国内也有很多企业把敏捷作为质量提 升的重要手段,例如广联达.价值和质量这两点是我认为敏捷最重要的两个目的.当然,成本也是目的之一,在我培训的一些企业中,这往往也是一些领导者最关心 的问题,他们会说

传统的瀑布工作模式使用详细的需求说明书来表达需求,需求人员负责做需求调研,根据调研情况编制详细的需求说明书,进行需求评审,评审之后签字确认交给研发团队设计开发.在这样的环境下,需求文档是信息传递的主体,也是一份契约. 然而详细的需求说明书有以下5大弊端: 单向的信息传递,容易出现理解偏差. 文档很正式,我们会误以为它一定是对的,不去质疑它,让我们停止作出判断. 有了详细的文档,我们不会反复讨论它,相互确认. 书面文档不利于团队共享责任,它扮演了证据的角色.Scrum强调团队共享责任,不论是需求人

PS:是我从看过的书籍<软件测试进阶之路>上摘录的 很喜欢:深耕细作一词,可以走管理leader方向,但我更愿意是技术掌握到手后,兼职管理岗位. 庆幸吧,脚踏实地,没有上来就学自动化,所以没有在测试这条路上走偏,真的是一步一个脚印,而非越级而上. 1.1 黑盒 (1)业务功能测试专家 (2)用例设计专家 (3)需求测试负责人 1.2 灰盒 接口测试专家 1.3 白盒 单元测试专家 1.4 性能测试专家 1.5 安全测试专家 1.6 自动化测试 (1)Web端自动化测试专家 (2)应用程序端自动

2017.9.16~17日,深圳市共创力企业管理咨询有限公司为某上市企业提供了为期两天的内训服务.该次内训的主题为<敏捷MINI体验式实践培训>,为期两天.此次培训由共创力资深讲师George主讲,George老师分别从敏捷的概论.SCRUM精髓.精益需求.质量内建等几个维度对敏捷的方法论进行讲解,此次培训是本次实施敏捷转型的第一期培训,来自该公司各部门负责人.敏捷教练.SE.QA等角色参与了此次培训,培训结束后,大家与George老师合影留念,期待下一场培训更加精彩.

早期,腾讯公司的架构是比较简单的.从上至下分别是:公司——商业单元(BU)——部门——组——员工,每个部门基本上就是负责一个大的产品,每个组都是按照专业进行分工和管理,例如:产品组.终端组.后台组.设计组.运维组.质量组等等. 草拟一个项目需要在每个小组里面抽调人力,部门的总经理就需要和每个小组的组长沟通,经过沟通以后,确定了该项目需要的人力安排,然后就开始执行项目.执行项目过程中的困难,需要决策,例如:人员安排调整,产品需求变更和是否延期发布等等,都需要总经理和组长们开会协调或者私下沟通决定,

敏捷开发并不是由敏捷工具来推动的.但是没有敏捷工具的支持,就很难进行各种软件工程的相关事件,工具的作用是约束和流程,正确使用敏捷工具可以事半功倍,实践敏捷.近几年来敏捷开发催生大量敏捷工具的产生,在敏捷工具上多了很多种选择,每个团队需求不一样,就会使用到不同的敏捷工具. 工具基础概念 什么是问题? 不同的组织使用JIRA追踪不同的问题.JIRA的项目是根据你的企业组织需要定制的,是问题的集合. 例如, 一个JIRA项目可以是: 一个软件研发项目 一项市场推广活动 一个技术服务/帮助台系统 一个需

“敏捷是什么鬼” 最近对外进行<腾讯产品敏捷研发体系>授课的时候,我经常可以从参课学员的眼睛里找到这句话. 通常我会鼓励大家,说:“告诉大家一个好消息,你们今天所有的疑问都是有答案的,唯一担心的问题是你们短期内能否接受和理解.” 我之所以敢说出这句话,仅仅因为大家的状态和我2006年末的时候并无二致. 一.初识敏捷 2006年年末的时候,鹅厂决定开始引进“敏捷”. 对于当时大部分公司的小伙伴来说,既完全搞不清楚这个概念,也不理解为什么要做这个事情,更不可能想象到这件事对于鹅厂未来的深远意义.

上回腾讯敏捷转型系列第一篇文章<敏捷到底是什么鬼?>讲到公司铁了心要推进敏捷,这是战略层面的决定,为什么呢? 当时的我们并不知道公司为什么一定要推行敏捷的新概念,但是后来公司的变化帮助我们理解为什么推行敏捷. 腾讯公司成立在1998年11月11日,2001年接入中国移动的移动梦网,做了SP业务之后开始盈利.到了2004年,因为腾讯有了连续三年的盈利,顺利在2004年6月16日在香港股票交易所上市.上市后又得到了一大批融资资金,所以在2005年腾讯内部做出了一次非常大的组织结构调整,将原来各自为