考虑一家通过非敏捷方法认证的公司,并以此为卖点向客户证明自己的责任。
您如何在不破坏整个系统的情况下逐步引入看板或Scrum并仍然使他们确信它仍然可以同样负责/可审计?
我知道这可能与“ 您将如何引入像Scrum这样的敏捷方法论 ”有关,但是在这里,我想知道如何规避/解决该公司以某种虚假借口强加某种方式管理SDLC的事实。进行审核的唯一途径。
考虑一家通过非敏捷方法认证的公司,并以此为卖点向客户证明自己的责任。
您如何在不破坏整个系统的情况下逐步引入看板或Scrum并仍然使他们确信它仍然可以同样负责/可审计?
我知道这可能与“ 您将如何引入像Scrum这样的敏捷方法论 ”有关,但是在这里,我想知道如何规避/解决该公司以某种虚假借口强加某种方式管理SDLC的事实。进行审核的唯一途径。
Answers:
我认为,敏捷项目团队不记录其应用程序是一个神话,这是您的公司遇到的第一个抵制点,这些公司已获得按照其标准获得最佳文档的证明。
我在一家通过ISO-9001认证的公司中工作,但我们也对大量项目进行Scrums。在我们的案例中,更改来自项目交付负责人(即相当资深的人),这就是为什么采用了它-而不是项目经理或开发人员试图推动此更改。
我们遵循的一种有用的做法是“足够但连续”。显然,这意味着我们并未遵循该项目所规定的所有模板,但是对于需要哪些部分/文档与那些毫无意义的开销有意识的理解和共识。
然后,您需要对此观点进行社交化,并获得质量小组或标准部门或其他部门的批准。
敏捷原则是“足够”的文档。您是否可以尝试将其从客户那里推送给团队,以表明多少就足够了?项目经理可以与客户交谈并了解他们的期望和组织需求,然后记录决策并满足这些期望。如果对他们(即付费客户)足够好,那么您可以遵循它。
如果他们认为敏捷不能扩展到大型项目,请通过分解和并行的努力说服他们这样做。
在大型组织中,大型项目的控制和监督是通过运行项目监视办公室(PMO)来完成的,该办公室对成本/会计/资源管理等进行常规计划-因此,它们需要大量文档,但可以使用敏捷实践来监视进度(SCRUM燃尽图之一)。他们需要知道诸如持续集成之类的技术如何早于而不是后来对他们有帮助,因此,每个人的工作效率最好不要使用开销较大的文档。
敏捷是团队可以学习的一组技能,这些技能在很大程度上与我们的传统技术技能正交。但是,如果您将其添加到他们现有的技能中,那么您当然可以成为一个更有效的团队。每天的站起来(即Scrum会议)不可能在一夜之间发生-但是您目前会定期召开团队会议(例如每两周一次)?我要说的是先将它们转换成遵循Scrum问题议程(不要太偷偷摸摸;),然后再向更广泛的团队传达为什么这种方法行之有效,并不意味着文档松懈/标准不佳或其他任何神话。
我先将Scrum与看板分开。
使用看板- 这是正确使用方法的一个很好的参考 -原理是,您在开始时会尊重现有的过程。看板不是您要替换现有流程的东西,而是您要应用的东西。进行规划,可视化并设置逐步改进的某些条件。
从某种意义上说,Scrum将会取代现有流程,从根本上来说是不同的。
习惯了12个月(或更长时间)的瀑布SDLC周期的团队将很难过渡到Scrum。将周期逐渐缩短到6个月或3个月的发行范围较小的火车可能是一个有用的中间步骤。
就像您尝试向组织介绍的任何新事物一样,您将面临强烈的反对。你准备好被批评是在如果它失败负责?你必须成为一个坚强的人。那是暴露自己时要付出的代价。
这几乎就是我们公司发生的事情。我们遵循严格的,非敏捷的方法。当有SCRUM经验的新的首席技术经理加入时,他认为尝试一下会很好。
我们这样做的方法是让一小组开发人员(和分析人员)组成一个试点SCRUM团队。我们遵循了严格的SCRUM方法约4个月,之后公司反思了我们所做的事情,我们如何做,对数据进行了分析(您知道,广管局需要做的所有事情)。
他们发现飞行员很成功。因此,他们组建了另一支紧随看板的团队,他们也取得了巨大的成功。我认为有传言说其余的开发人员也组成了SCRUM /看板团队。
我认为飞行员很关键。它给了业务时间严格的一面,可以评估并确认它首先起作用。
我是一名敏捷教练,改变计划的关键之一就是在各个层面上接受!这包括高管,开发团队,经理等。在宣布大大小小的变更工作之前,我建议您先让个人加入您的行列。通过第三人称对话进行操作是个人开始提出新想法的最简单方法。什么是第三人称?博客,YouTube视频,演示文稿等。这样,这些人就可以开始提出自己的想法,并随着您的影响而主动提出改变。
这是我用来激发食物链各个层面兴趣的两个狡猾视频。
看板:http : //www.youtube.com/watch?v= 0EIMxyFw9T8
Scrum:http://www.youtube.com/watch?v = Q5k7a9YEoUI