Scrum项目如何获得管理层的支持和合作

标签: scrum 项目 管理 | 发表时间:2012-12-12 14:46 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

Scrum项目在公司的组织结构中无法单独生存,必然需要公司其他部门的合作和约束。Andrew Pham和Phuong-Van Pham在“ Scrum in Action”中分享了和管理层沟通的技巧和经验。

除非你独立工作或者就职于小型的创业公司,否则项目经理总是需要和组织内的许多人沟通来推进项目。虽然Scrum本身没有项目经理的概念,但是这并不意味着项目管理被抛弃了。对于实践Scrum的人来说,我们知道Scrum中的项目管理责任被转化并分配给了产品负责人、团队和ScrumMaster。

企业高层管理者

在与企业高层管理者(如CEO、总裁、首席财务官或者业务部门的高级副总裁)沟通时,Andrew和Phuong建议避免谈论Scrum会如何帮助你更快地构建更好的软件:

作为企业高层,他们会对你彬彬有礼,但是最终拒绝你,同时还会奇怪到底是谁把你招进了公司——浪费他们的时间泛泛而谈,而不是通过他们更加容易理解的财务术语来提出想法。​虽然构建更好的软件或者改进开发人员的效率对高管来说重要,但是他们更感兴趣的是公司整体市场份额、大规模的成本降低和整体的利润率。因此,尽管你对Scrum怀有好感,但是不要得意忘形地和高管谈论如果你被允许使用Scrum之后你的软件会如何出色或者你的构建会如何迅速。

​​相反,通过数字或者至少是整体的业务战略来把你的技术实力和热情与高管的财务思想关联起来。不论和你组织里的哪个人交流,都必须考虑倾听者的观点和角度,并就此沟通。​了解IT项目如何适应高管的整体构想和战略将帮助你更加有效地告诉他们,你的项目将如何对公司的整体战略做出贡献。请谨记,通过财务数据(也就是业务语言)将你的项目贡献​与公司联系起来是很重要的。你的老板会感谢你。

关于项目管理办公室,Andrew和Phuong建议:作为负责IT绩效并与公司业务需求和战略保持一致的机构,项目管理办公室(PMO)应该是你第一个需要面对的机构。如果你了解PMO的关注点,你应该很容易把PMO变成盟友,因为它的使命是确保IT项目为业务带来最大价值。毕竟,我们对产品负责人的使命的所有了解应该来自于Scrum项目,不是吗?​​

中层管理者

在我们深入讨论中层管理者或者执行团队的职责之前,我们应该搞清楚在日常职责中,这些人​的工作受你的项目影响最大。Andrew和Phuong建议:

因此,你有必要取得他们的支持来成功地完成项目。请记住,中层管理者的作用不是来捣乱的,而是提供支持和帮助。他们关注的是把问题降到最小,看起来像是一个成功的团队,并在正确的时间做事情。变化总是困难的,需要合理的管理。你作为给团队带来变化的人,应该了解大家通常是如何处理变化的。你必须知道如何与中层沟通并给与他们足够的理由使之相信这些变化让他们受益。当大家听到变化来临时,你可以期待的最好反馈是他们尝试理解这些变化会带给他们的后果。希望,反馈不是恐惧和反感。​接下来,根据沟通和收到信息的质量和数量​,他们可能直接或间接地抵制,或者如果他们认为对自己的工作和职业生涯有好处,他们会接受变化。因此,在沟通时,时刻记住对方的利益,确保你的沟通产生了所期望的结果,并且为你提供了你所需要的帮助。你应该计划的联系,保持接触,与您的项目将带来的变化将影响人们的沟通,你应沟通,在这样一种方式,他们可以清楚地看到,这是对他们有好处。你应该与会被项目引入的变化所影响的人保持沟通,并采用上述的方式使他们清楚地认识到这些变化对他们有好处。

质量保证管理层

考虑到Scrum中测试的重要性和变化本质,你应该想要与质量保证团队建立良好的关系。​根据你的公司是否已经为常用的Scrum实践做好准备,主要是测试基础设施方面,你可能需要为此或多或少的做些工作。如果Scrum是企业文化的一部分了,那么你只需要了解流程并试着利用。如果Scrum还没有成为企业文化的一部分,你可能需要向质量保证管理层解释Scrum,特别是主管测试的人,并获取他们的支持。你可能要求他们派出某个人全程参与你的项目,并且/或者为项目搭建合适的测试环境,这样,你可以快速准备好自动化测试、回归测试和持续集成测试。

运维管理层

不论你喜欢与否,都无法避开运维管理层。他们负责控制所有的预生产和/或生产活动。确保和他们沟通并解释你所需要的东西,以便在每个Sprint结束时交付的代码符合他们的预期标准。首先,请记住,开发团队和运维团队具有不同的,有时是相反的目标。​作为开发团队的一员,你的目标是持续地交付对业务的实际价值​。但是,在此过程中,你引入了变化,而运维团队的目标是在确保一切稳定的状态下持续交付价值。因为Scrum开发的本质,会有更多的软件发布,通常存在许多更小的更新,而不是几个较大的更新,这些都需要运维团队来处理。运维团队不会也不能仅仅因为你的更新较小,而放弃他们的控制过程。这样做会导致在运行业务系统时增加中断。运维团队仍一如既往地严格实施预生产验证测试。整个变更过程保持不变,即使针对较小的更新。

因此,除非你的公司已经准备好了某种自服务的部分,或者更确切地说,自服务部署过程的自动化,否则请努力与运维团队做好日程安排,因为这会帮会组他们处理持续的更新。作为回报,他们会帮助并感激你。随着时间推移,运维团队会发现有更多时间处理其他工作,从而很高兴为开发团队提供变更支持,同时,也会保留对生产环境的所有控制。​

​​ 把你的直接管理者变成盟友

正如行业众所周知的,中层管理者的目标是确保项目前进,避免翻船,因此除非你直接向CIO或者CEO汇报,否则请花时间与你的中层管理者沟通,确保她完全理解了Scrum和它需要什么。如果你的经理不知道Scrum如何运行,而且你的项目进展不顺或者进度落后,那么存在这样的风险:你的经理希望很快地转化到传统的命令控制式过程。​​你必须尽可能地在项目启动之前向管理层解释清楚:Scrum是什么、在项目日常执行时它的运行机制、在进展顺利时如何运转、在不顺利时如何运转。

崔康 热情的技术探索者,资深软件工程师,InfoQ编辑,从事企业级Web应用的相关工作,关注性能优化、Web技术、浏览器等领域。

您可能也会喜欢

相关 [scrum 项目 管理] 推荐:

研发管理06:Scrum敏捷项目管理

- - CSDN博客推荐文章
本文结合自己5年多的Scrum 敏捷开发经验, 并结合PMP相关知识与技能, 总结了实际开发过程中的敏捷实践过程. 从介绍敏捷开发方法开始, 逐步介绍Scrum敏捷开发的流程与相关关键技能与框架的应用技巧. 作者:bamboolsu 发表于2015/5/12 9:42:40 原文链接. 阅读:54 评论:0 查看评论.

Scrum项目如何获得管理层的支持和合作

- - InfoQ cn
Scrum项目在公司的组织结构中无法单独生存,必然需要公司其他部门的合作和约束. Andrew Pham和Phuong-Van Pham在“ Scrum in Action”中分享了和管理层沟通的技巧和经验. 除非你独立工作或者就职于小型的创业公司,否则项目经理总是需要和组织内的许多人沟通来推进项目.

Scrum中管理bug

- - CSDN博客研发管理推荐文章
如果bug来自于正在开发的sprint. 会在task阶段就被QA/Scrum Master/Product Owner标记为有bug,并且Story不能被置为done状态,这个很容易解决. 如果bug来自于已经结束的sprint,那么怎么办呢. 理想状态下是将bug放到backlogs中,然后由product owner调整其优先级,并决定放在后面的哪一个sprint中修复.

项目经理和Scrum Master

- - InfoQ cn
在博客上,大家对于Scrum Master和项目经理这两个角色依旧争论不休,许多评论员清晰地指出两者的不同,并表示两者不可并存,更不适合合二为一. Steve Hunton在Scrumalliance站点上发布了名为《 Scrum Master并不是项目经理的别名》的博文,他提到:. 与大众的认识相反,Scrum Master和项目经理这两个角色是完全不同的,也不应该混为一谈.

Scrum项目准备程度的自我评估

- - InfoQ cn
在启动Scrum项目之前,我们需要了解项目成功的几率,Androw和Phuong在“ Scrum in Action”中从组织、基础设施、团队、技术、过程和业务六个方面提供了自我评估的标准,对于Scrum项目团队有很好的借鉴作用. 主要评估不同部门和团队是否熟悉了Scrum的价值观和实践. 组织内部对Scrum越熟悉,Scrum过程越顺利.

如何让第一个试点Scrum项目成功

- - ITeye博客
如何让第一个试点Scrum项目成功. 当我们在尝试应用敏捷开发时,Scrum方法是最容易实施的. 但是如果要想使敏捷开发进行下去,第一个试点的Scrum项目要尽量成功,这样会得到管理层更多的支持. 以下是我们在实践中的一些具体做法:. 1)这个项目是对企业的business有一定影响(但不是最影响的),这样一方面可以得到管理层的支持,如果成功有很强的示范效应,同时由于新方法最初的采纳期间会出现各种各样的问题,有失败或者延期的风险,试点团队不会由于Business的压力重新回到以往熟悉的开发方式上以完成任务.

《Scrum敏捷产品管理》读书笔记

- - CSDN博客研发管理推荐文章
提到产品管理,在Scrum中,首先就想到的角色是产品负责人. 因此我们先来看看产品负责人(Product Owner),以及这个角色的特征:. 然后对于大型产品而言,一个产品负责人是不够的,所以存在产品负责人扩展的问题. 对于产品负责人,常见的问题有:. Kano model (卡诺模型)可以帮助我们选择合适的功能,开发出吸引人的产品.

敏捷管理系列:基于 Jira 的 Scrum 敏捷管理实战

- - IT瘾-dev
敏捷管理系列-四种常见研发模式 一文介绍了常见的四种研发模式,适用场景及优缺点. 敏捷管理系列-学习实践Scrum,看这一篇就够了. 一文介绍了敏捷与Scrum的关系,Scrum的核心概念价值、落地三三五五及度量标准等做了总结. 本文将介绍如何在团队中引入敏捷及基于Jira的Scrum管理实战的.   01 研发管理生命周期(SDLC).

Scrum的故事

- Philip - 《程序员》杂志官网
2001年2月,17位敏捷先驱齐聚犹他雪鸟度假村,起草《敏捷宣言》的时候,Scrum只是众多方法中不太起眼的一个. 十年之后,Scrum却成为最流行的敏捷方法,几乎成为敏捷的代名词. 本文来介绍下Scrum的两位创始人——Jeff Sutherland与Ken Schwaber. 大家可能不会想到,Jeff Sutherland的第一份工作居然是美国空军战斗机飞行员,还曾于1967年获得了“壮志凌云”称号,完成过100次飞越北部越南的作战任务.

scrum经验

- - CSDN博客研发管理推荐文章
Scrum是基于过程控制理论的经验方法,倡导自组织团队;其运行框架核心是迭代增量型并行开发,也是“适应性”的软件开发方法. Scrum提供了高度可视化的用于管理软件开发复杂性管理的敏捷项目管理的实践框架或敏捷过程,可以用于对现存软件工程实践的包装,提高软件生产率,改善沟通和合作的方法,使人们协作并注重业务目标.