如何将敏捷引入使用刚性非敏捷方法的团队?


16

考虑一家通过非敏捷方法认证的公司,并以此为卖点向客户证明自己的责任。

您如何在不破坏整个系统的情况下逐步引入看板或Scrum并仍然使他们确信它仍然可以同样负责/可审计


我知道这可能与“ 您将如何引入像Scrum这样的敏捷方法论 ”有关,但是在这里,我想知道如何规避/解决该公司以某种虚假借口强加某种方式管理SDLC的事实。进行审核的唯一途径。


什么是认证?是ISO-9000吗?
罗伯特·哈维

1
您对细节有些了解;如果认证需要某种最低程度的工件才能保持认证,并且公司已经以将影响最小化的方式将这些工件紧密地映射到您的开发流程中,那么就没有解决方法。
罗伯特·哈维

@Robert Harvey:ISO-9001是一个很好的例子。任何需要可审核的要求,测试规范以及对文档和任务所有者的可追溯性的内容。
haylem 2010年

@Robert Harvey:是的,但是映射仅需要审核。据我所知,大多数问题/缺陷/任务/错误跟踪器可以随着时间记录任务所有权,因此可以作为审计跟踪的一部分。对于软件开发,甚至可以链接到SCM,以跟踪修订版本号。另外,您还可以使用跟踪器来识别需求,f规格和测试ID,并从那里获取可追溯性矩阵。
haylem 2010年

@罗伯特·哈维(Robert Harvey):特别是考虑到跟踪和维护ISO-9001并不是很困难,但是似乎经常被认为是需要极其冗长和冗长的事情。
haylem 2010年

Answers:


12

我认为,敏捷项目团队不记录其应用程序是一个神话,这是您的公司遇到的第一个抵制点,这些公司已获得按照其标准获得最佳文档的证明。

我在一家通过ISO-9001认证的公司中工作,但我们也对大量项目进行Scrums。在我们的案例中,更改来自项目交付负责人(即相当资深的人),这就是为什么采用了它-而不是项目经理或开发人员试图推动此更改。

我们遵循的一种有用的做法是“足够但连续”。显然,这意味着我们并未遵循该项目所规定的所有模板,但是对于需要哪些部分/文档与那些毫无意义的开销有意识的理解和共识。

然后,您需要对此观点进行社交化,并获得质量小组或标准部门或其他部门的批准。

敏捷原则是“足够”的文档。您是否可以尝试将其从客户那里推送给团队,以表明多少就足够了?项目经理可以与客户交谈并了解他们的期望和组织需求,然后记录决策并满足这些期望。如果对他们(即付费客户)足够好,那么您可以遵循它。

如果他们认为敏捷不能扩展到大型项目,请通过分解和并行的努力说服他们这样做。

在大型组织中,大型项目的控制和监督是通过运行项目监视办公室(PMO)来完成的,该办公室对成本/会计/资源管理等进行常规计划-因此,它们需要大量文档,但可以使用敏捷实践来监视进度(SCRUM燃尽图之一)。他们需要知道诸如持续集成之类的技术如何早于而不是后来对他们有帮助,因此,每个人的工作效率最好不要使用开销较大的文档。

敏捷是团队可以学习的一组技能,这些技能在很大程度上与我们的传统技术技能正交。但是,如果您将其添加到他们现有的技能中,那么您当然可以成为一个更有效的团队。每天的站起来(即Scrum会议)不可能在一夜之间发生-但是您目前会定期召开团队会议(例如每两周一次)?我要说的是先将它们转换成遵循Scrum问题议程(不要太偷偷摸摸;),然后再向更广泛的团队传达为什么这种方法行之有效,并不意味着文档松懈/标准不佳或其他任何神话。


虽然其他答案很好,但我认为您的答案是最努力解决特定问题的答案,而不仅仅是给出有关使用敏捷的一般性提示,并试图弄清楚为什么要使用它。好答案。谢谢。
haylem 2010年

@haylem:很高兴它有所帮助。在我们的案例中,我们任命了一位敏锐的团队成员“敏捷冠军”来促进过渡。他使我们所有人都意识到了很多这些东西。也许您可以自愿担任这样的角色。
JoseK 2010年

8

我先将Scrum与看板分开。

使用看板- 这是正确使用方法的一个很好的参考 -原理是,您在开始时会尊重现有的过程。看板不是您要替换现有流程的东西,而是您要应用的东西。进行规划,可视化并设置逐步改进的某些条件。

从某种意义上说,Scrum将会取代现有流程,从根本上来说是不同的。

习惯了12个月(或更长时间)的瀑布SDLC周期的团队将很难过渡到Scrum。将周期逐渐缩短到6个月或3个月的发行范围较小的火车可能是一个有用的中间步骤。


我喜欢尊重现有流程的想法。我不确定逐渐缩短的时间,但可能会带来一些痛苦而没有太多好处。我会去参加高级管理层的接任,然后花上几个星期让人们习惯于日常的敏捷和两周的迭代过程。
Michael Durrant 2012年

6

就像您尝试向组织介绍的任何新事物一样,您将面临强烈的反对。你准备好被批评是如果它失败负责?你必须成为一个坚强的人。那是暴露自己时要付出的代价。

  • 问问自己为什么要使用Scrum。您需要解决一个实际的问题吗?
  • 确保对它有所承诺,因为没有人会为您这样做。您将成为事物的所有者。至少要在组织中产生积极影响之前
  • 训练自己。书籍和互联网还不够。首先参加课程,否则您将大大增加错误实施Scrum的机会。这可能会使您的团队取得比以前更糟糕的结果
  • 首先把它卖给团队。很明显,您必须得到他们的全力支持
  • 不要提出变更,建议进行测试。并这样考虑。Scrum可能不适合您的组织(或您的团队)
  • 在最高管理层中寻找赞助商

+1:“问自己为什么要使用Scrum。您需要解决实际问题吗?”:非常好。在介绍一种新的工作方式之前,应该先问一下要解决的问题。不幸的是,引入SCRUM(或任何其他方法)来解决不存在的问题只会增加开销并降低生产率,而不是增加开销(我从直接经验中得出)。
Giorgio

3

这几乎就是我们公司发生的事情。我们遵循严格的,非敏捷的方法。当有SCRUM经验的新的首席技术经理加入时,他认为尝试一下会很好。

我们这样做的方法是让一小组开发人员(和分析人员)组成一个试点SCRUM团队。我们遵循了严格的SCRUM方法约4个月,之后公司反思了我们所做的事情,我们如何做,对数据进行了分析(您知道,广管局需要做的所有事情)。

他们发现飞行员很成功。因此,他们组建了另一支紧随看板的团队,他们也取得了巨大的成功。我认为有传言说其余的开发人员也组成了SCRUM /看板团队。

我认为飞行员很关键。它给了业务时间严格的一面,可以评估并确认它首先起作用。


1

我是一名敏捷教练,改变计划的关键之一就是在各个层面上接受!这包括高管,开发团队,经理等。在宣布大大小小的变更工作之前,我建议您先让个人加入您的行列。通过第三人称对话进行操作是个人开始提出新想法的最简单方法。什么是第三人称?博客,YouTube视频,演示文稿等。这样,这些人就可以开始提出自己的想法,并随着您的影响而主动提出改变。

这是我用来激发食物链各个层面兴趣的两个狡猾视频。

看板:http : //www.youtube.com/watch?v= 0EIMxyFw9T8

Scrum:http//www.youtube.com/watch?v = Q5k7a9YEoUI


+1表示支持,特别是考虑到问题中的评论显示缺乏支持。
Michael Durrant 2012年

@KanbAnimation:我认为您首先应该问自己SCRUM是否对您要引入它的公司有利。(根据我的直接经验)SCRUM不适用于所有类型的项目,引入SCRUM并不总是使公司更有效。如果SCRUM不能很好地适合他们所从事的项目,那么说服高管(可能缺乏了解后果的技术知识)可能会长期损害公司的利益。
乔治
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.