• 可以放慢脚步:BA效率不是通过击键来衡量的
  • 业务分析的通配符身份
  • 是的,您可以在Covid-19期间实际上有效地提出要求!
2015年7月31日星期五07:15

您可以' t快吃点敏捷蛋糕!

撰写者

可以肯定地说,许多执行软件开发的组织要么正在使用某种形式的敏捷方法,要么正在实施敏捷。这些组织中的管理层很可能认为敏捷将为组织带来许多好处,从而使他们因其不可思议的远见而获得众多赞誉,掌声和认可。不幸的是,这些崇高的期望常常大相径庭,并有可能损害其组织。沮丧和失望是首次采用敏捷的组织中的典型现实。了解造成这种挫败感的根本原因将有助于避免失望和项目团队工作效率的下降。

根据我的经验,大型开发团队从命令和控制瀑布式结构过渡到敏捷开发时,团队沮丧和失望的头号原因是执行管理层需要确定优先级和规定截止日期,就好像他们为项目做出了贡献。

敏捷宣言简单地指出,软件开发团队应该在个人,团队互动,工作软件,客户协作以及对变化的响应上给予更多的重视。相比之下,Waterfall将重量级过程,工具,计划和文档视为重中之重。希望采用更敏捷的方法的组织通常被作为命令和控制瀑布商店进行管理。指挥和控制管理风格包括执行管理确定项目优先级,然后指定截止日期。然后,项目管理创建工作分解结构或其他工具来识别项目完成所需的所有任务,然后瀑布就开始了!在这种敏捷方法论中,管理层采用这种指挥和控制风格的舒适度是造成摩擦的主要根源。面对现实,高管们没有完成与项目相关的任何直接工作。他们不编写要求,编写代码或测试产品。因此,他们认为自己可以为项目做出贡献的唯一方法是使用与命令和控制方式相关的大棒,该命令和控制方式规定了截止日期,并迫使团队进行英勇地履行任务。

软件开发团队非常了解《敏捷宣言》及其承诺。他们通常对在更敏捷的环境中工作的机会感到兴奋,并摆脱了局限性的命令和控制思想。当我们的部门着手从非常严格的Waterfall方法转换为Agile的旅程时,就产生了巨大的希望,兴奋和热情。团队非常渴望摆脱我们当前的流程,该流程从字面上表明,只有在管理层正式批准所有要求之后,开发才能开始。显然,这是一种无效且无法实现的软件开发方式,因为如果不经过整个需求审查和批准流程就无法实施发现的不可避免的需求变更。项目通常很晚,超出预算,无法完全满足业务需求。经过几年这种无能为力的业绩之后,高层管理人员进行了全面重组,并且我们的部门希望敏捷部门能够节省很多时间。新管理层到位后,敏捷顾问开始出现。这些顾问开始就与敏捷相关的技术指导组织。诸如“站立”,“迭代”,“回顾”,“积压整理”和“迭代计划”之类的术语像野火一样在组织中传播。事后看来,那时候我可以用流行语宾果游戏来赚大钱了!乐观是很高的,学习和实施敏捷的新目标乱丢了每个人的年度绩效目标。

在一个小型概念验证项目上,敏捷的最初推出相对较好。基于这些结果,管理团队批准在我们的旗舰产品完全重新开发时使用新的敏捷方法。这是一个十八个月的努力。部署敏捷的第一步是要求业务分析小组事先确定与此工作相关的所有用例,以便我们可以估计整个项目并计算截止日期。旧习惯很难改掉,要教老狗新的技巧很难用陈词滥调来描述这种情况。 BA小组反对所有可以先识别所有用例的想法,并表示我们认为我们将变得敏捷。尽管如此,我们还是被迫提供最好的猜测,项目管理小组提出了18个月的艰巨期限。该团队现在致力于对产品进行完整的改写,该产品在18个月的时间里经过了7年的生产和修改!具有讽刺意味的是,我们在新的敏捷世界中的第一步是完成一项典型的指挥和控制任务,即识别所有工作并提前完成任务。团队对此截止日期表示不满,但管理层确信每个人都知道这是目标而不是承诺。实际上,无论何时将日期传达给高层管理人员,都将成为交付的期望,无论说多少次仅是估计。
团队开始使用顾问教给该小组的所有新颖的敏捷工具进行开发。参加了起立仪式,教科书上的问题是“你昨天做什么?”,“你今天打算做什么?”和“您有任何障碍吗?”被问及回答。这些问题并不是很有帮助,很快就变得显而易见了。团队询问我们是否可以放弃该脚本,而只花时间直接进行交流,而不受三个教科书问题的限制。项目管理部门对此要求的最初回应是负面的。我们必须遵循敏捷方法论,即在站立时必须问这三个问题!
这是因敏捷推出而产生摩擦和沮丧的第二个主要原因。项目管理开始强调团队协作和人际互动方面的敏捷工具和流程。

具有讽刺意味的是,这是一种完全反敏捷的方法。随着时间的推移,我们成功说服了项目管理人员,使团队有权决定独立会议的结构和频率。不幸的是,这是一场艰苦的战斗,在开发团队和项目经理之间造成了相当大的摩擦。可以肯定地说,鲜花盛开了,与敏捷部署相关的最初的兴奋和乐观开始减弱。
这是开发团队与项目管理机构在使用敏捷工具方面进行的众多战役中的第一个。开发团队被迫为每个迭代中接受的每个用例和变更请求提供初始点估计。然后,项目管理团队使用这些总分来计算团队速度。然后使用团队速度来比较每个团队的假定生产率。每周都会通知管理层,每个团队可以完成多少分,“第1团队此迭代完成了80分,而第2团队完成了40分!”这不可避免地引起了管理层的疑问,即为什么第2团队的效率是第1团队的一半。这又是敏捷部署的另一个摩擦和挫折源。用于计算团队速度的点估计只是一种敏捷工具,可以帮助大致预测开发团队何时完成某项功能。但是,由于很难打破旧的命令和控制习惯,因此可以轻松使用此工具来质疑开发团队的工作。在不了解与工作相关的所有复杂性的情况下,根据初步估计提出的质疑努力会导致士气低落,并进一步使敏捷方法破灭。

团队尽职尽责地继续发展,并参加了结构化的敏捷会议。站立,迭代计划,积压整理,回顾和展示都计划在每次迭代中进行,并得到了充分的参与。但是,随着时间的流逝,在每次迭代结束时进行回顾的实用性开始减弱,并受到质疑。在许多迭代中,不断回答“什么有效?”,“什么无效?”。和“我们应该改进什么?”致力于一遍又一遍地重复同样的事情。此外,事实证明,在每次迭代结束时都必须举行强制性展示会,这比正面经历更是负面的。每次迭代都不一定为功能提供完整的功能,因此像时钟一样展示团队的工作会引起利益相关者的困惑。鉴于这些发现,团队反对项目管理,以查看是否可以调整这些强制性敏捷会议的频率。与以前的要求类似,这遇到了阻力。 PM辩称:“敏捷说,我们必须在每次迭代结束时进行回顾和展示!”指示开发团队繁重过程的命令和控制思想再次抬头。开发团队的士气再次沉没,对我们敏捷的想法继续失望。
当我们迈向几个月前设定的不可谈判的最后期限时,很明显,我们将很难完成最小可行解决方案(MVS)中包含的所有工作。业务涉众开始意识到(或开始关注)该产品的MVS版本中实际包含的内容,并开始要求附加功能。管理层屈服于这种压力,要求团队在截止日期之前尽可能多地提出其他要求。开发团队英勇地工作了60多个小时,并在最后一次迭代中推迟了暑假,以便在截止日期之前交付产品。这项工作进一步扭曲了团队速度报告,因为它显示了团队每次迭代完成100+分。管理层中的一些人不可避免地问到为什么他们在项目后期这么有生产力,或者评论了固定的,不可协商的期限如何推动项目的完成。实际上,这种经验使开发团队在我们的新“敏捷”流程上感到更加痛苦,因为它肯定感觉像旧的“命令和控制会在最后期限之前完成”瀑布流程。

在项目完成时,开发团队,项目管理和执行管理人员开始致力于开发一种更加令人满意的敏捷方法论,该方法论将与实际的《敏捷宣言》更加一致。开发能够真正实现更高效率承诺的敏捷方法的关键如下:
1)。通过命令和控制管理风格来识别管理层的舒适度,该风格决定了流程和截止日期。
2)。通过指示流程和抵制团队授权来认可项目管理的舒适度

克服这些现实的关键是在自我授权的开发团队,项目管理和执行管理之间建立信任。执行管理层必须明确定义项目中每个角色的职责和权限,以确保团队真正有权选择如何使用敏捷工具集。一旦清楚地理解了这些角色和职责,开发团队就必须通过在使用敏捷工具的同时持续交付工作软件来赢得管理的信任。建立信任需要时间。允许自力更生的团队根据他们的需求使用敏捷工具,从而消除了将命令和控制思维与敏捷结合在一起所带来的麻烦。

我将在以后的文章中提供一个框架,以沟通团队的职责和权限级别,以确保敏捷成功。

 大卫·谢弗

Dave目前是Reed Tech的业务分析经理,在卓越业务分析中心内管理着一组业务分析人员。 自2002年以来,他一直在制药和制造行业从事业务分析工作,并且可以通过  领英简介

©BA Times.com 2020

麦格雷戈徽标白色网站