|
club.mypm.net
在The Workplace Within这本优秀的著作中，Larry
Hirschhorn用很长的篇幅分析了挑战者号灾难。在导致坠毁的许多事件中，让我们感触最深的是，NASA的管理层认为，航天飞机的每次成功发射都降低了灾难发生的风险。在NASA，许多人都知道，那个导致灾难发生的、有缺陷的O型密封圈可能会出故障，但管理层的乐观情绪随着一次次发射日益高涨，让工程师们倍感沮丧和无奈。PgMp.mypm.net
敏捷宣言告诫我们，要避免这样的脱节。在选择Agile Practitioners
2016大会的主题时，我们希望找出危害组织的症状，看一下它们可能如何让组织偏离敏捷的道路。我们希望突出可以帮助组织避免灾难的价值和原则。bbs.mypm.net
本文面向初学者以及那些质疑敏捷实施的敏捷怀疑论者。项目管理者联盟
本文提出了10条敏捷失败之路，旨在说明采用相反的做法可以提高敏捷性和成功几率。PgMp.mypm.net
1)缺少领导支持项目管理论坛
管理层必须参与和投入。club.mypm.net
在NASA，工程师知道密封圈有缺陷。显然，不管是他们，还是管理层，都不想看到灾难发生。让我们回归根本，敏捷宣言告诉我们，“在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。”“必须”一词是经过慎重选择的。如果管理层最终代表业务，就意味着他们应该花时间到开发人员中间去工作，感觉就像公司里的一名工程师。参与和投入意味着在同一个战壕里——拿着项目自己的“O型圈”，了解工程师们正在谈论的内容。项目管理者联盟
在一家独立的软件公司，研发部门副总裁引入了一家敏捷顾问公司帮助组织转型。在最初培训期间，该副总裁表达了对Scrum概念的怀疑。她不想将自己的观点强加给团队，就花时间和工程团队呆在一起，观察他们如何工作。她第一次看到，测试人员和程序员如何一起实现每周的增量价值。“我不明白”，她告诉我们，“但每个人，包括客户，都很高兴，像这样，到了最后，与我无关了。”从那以后，她开始放弃她的命令式风格，这种风格在组织中非常普遍。项目管理者联盟文章
2)转型目的缺失或不明确项目管理者联盟文章
企业必须明确希望从敏捷得到什么。www.mypm.net
“变得敏捷(Becoming
agile)”是一项艰苦的工作。它需要不断地实践，打破旧习惯，采用新思维，这仅仅是其中的部分挑战。它意味着组织需要投入大量的精力调整文化。项目管理者联盟
如果你连正在努力解决的问题都不清楚，那么就需要更多的精力来保持动力。首先定义好你希望从敏捷得到什么，并不断地改进那些目标。还有，是的——每个人都那样做并不足以成为采用敏捷的理由。你必须眼睛盯着自己的问题，弄清楚为什么希望作出改变。项目管理者联盟文章
在大型企业中，最高管理层选择敏捷是为了缩短上市时间、改进质量、加强沟通以及更好地适应变化。但管理层并没有给这些目标指定一个优先级，TTM和质量相互矛盾，会妨碍沟通改善。由于变革目标不条理，一段时间之后，这四个目标就被人们完全遗忘了。项目管理者联盟
3)组织结构与角色和敏捷不相容
现有的团队结构必须不会妨碍“完工”。管理角色必须不会妨碍服务型领导/学习文化。转自项目管理者联盟
敏捷宣言告诉我们，“最好的架构、需求和设计出自于自组织的团队。”过分依赖其他团队的团队无法实现自组织——例如，如果开发团队依赖于测试团队来推动工作“完工”，那么该团队可能会表现出对他人无益的行为，如归咎文化或冷漠。项目管理者联盟
同样地，强力或高压领导很可能会导致对领导者的依赖，留给创新和创造力的空间很小。由于我们的行业依赖于创新和创造力，所以我们希望团队成为它们生长的沃土。团队角色和任务的多样性是关键。training.mypm.net
根据你希望创造的价值建立组织结构，这样，人们就可以更独立地工作，减少对管理人员的依赖——反过来，管理人员可以帮助那些人提高。项目管理者联盟
一个大型的政府组织在他们的软件研发部门实施Scrum。软件QA、BI和DBA分属不同的部门。每当研发团队需要其他部门的支持，研发团队负责人就不得不接洽其他部门的负责人，请求他们腾出时间。研发团队的成员觉得，他们必须尊重其他非敏捷团队，这让他们觉得被推入了一种瀑布式文化。www.mypm.net
4)破“构建”理论项目管理者联盟
不修复问题释放了允许质量糟糕的信号。pmp.mypm.net
上世纪80年代的破窗理论指出，忽视像破坏公物这样的小罪会向人们释放更严重的犯罪也会被忽视的信号。后来，纽约市市长Rudy
Giuliani采纳了这种方法，应对轻微犯罪。被破坏公物的人打碎的窗户会及时得到修复。警察接受训练，对付罪犯，帮助社区处理轻微犯罪行为，而不是忽视它们。结果难以置信。纽约市臭名昭著的危险区域成了最安全的区域之一。虽然有人批评这一研究不科学，但这种方法在其他城市也得到了成功应用。转自项目管理者联盟
类似地，对于软件组织而言，这几乎是不言而喻的：如果你忽视了有问题的构建，如Bug或者拼写错误，那么你就释放出了可以不编写单元测试、不重构，或者不按照需求开发的信号。标准就是这样形成的。项目管理论坛
另一种选择?不要厌烦查找问题原因，确保问题得到修复。成为你希望达到的标准的榜样，并赞扬那些追随你的步伐的人。其他人也会这样做。talent.mypm.net
|
