两个团队的故事

这是我有史以来第一篇博客文章! 关于来自不同部门的遗留软件移交问题。

最近,我们受命从其他部门使用某些软件产品。 这些产品对我们的业务功能至关重要。 他们是由一位远程开发人员与一位业务分析师(作为与业务团队的联系)一起工作的,经过15多年的发展。 作为规模的指标:有16个可部署软件系统。 C#ASP.net Web表单网站和支持WCF服务的混合,所有这些都依赖于大型中央SQL数据库。 该数据库具有约4000个存储过程,约1000个表,并且很少有有用的架构。 这项工作还涉及人的方面。 我们各自的部门对发展实践和原则持有不同意见,并有不同的工作方式。 我们以前从未像这样合作过。 目前的开发人员正离开组织,因此我们有6周的入职时间。

这给我们带来了一些挑战:

·在短时间内评估一套复杂的软件产品和功能。

·远程开发人员无法上任,并且现有文档很少。

·部门之间的发展文化和工作惯例不同。

入职非常成功。 我们的团队现在能够为这些软件产品提供有效和及时的支持,并且还帮助提高了产品复杂性对企业的可见性,使我们能够开始讨论以寻找其他长期解决方案。 我们回顾了自己在入职尝试中取得的成功和经验教训。 我们希望与将来可能面临类似挑战的任何人分享我们的关键见解。

成功案例

我们使用了新鲜面孔 -我们组建了一个以前从未与其他部门合作过的新团队。 新的关系帮助我们避免了可能影响入职成功的现有假设。

我们有一个多学科团队 -我们使用了一个多学科团队进行入门。 开发人员和运营人员共同评估了系统和体系结构。

我们尽早建立了信任 -这对于不同的工作方式至关重要。 我们尽早沟通,对正在进行的工作具有包容性和透明性。 这些小事有助于使用人们的名字,说“请”和“谢谢”。 我们明确了假设,并强调了共同的工作目标。

我们经常交流-我们决定不让开发人员移交一次强烈的家访,而是选择常规的视频通话。 这给了我们更多的时间来完成工作。

我们尽早与用户会面 -我们及早与用户交谈以帮助我们确定关键功能。 这帮助我们避免了面对大量功能的干扰。

我们确定了未知数—我们的送货经理埃莉诺·莫雷特(Eleanor Mollett)向我们介绍了唐纳德·拉姆斯菲尔德(Donald Rumsfeld)估计,这是一种识别未知数的计划技术。 这有助于我们将未知因素优先于更明显的工作。

我们制作了图表-尽早创建一些关键图表有助于我们了解系统的广度。 系统景观图(来自可视化软件体系结构的C4模型)向我们展示了用户,系统和关键交互。 数据库模式图突出了耦合和复杂性。 不要低估一个好的图表的价值。

我们进行了一场表演并讲述 -我们举行了一场早期表演并告诉我们更广泛的团队以提高意识和反馈。 这也帮助我们组织和确认了自己的知识。 展示和讲述不仅限于新产品开发。

下次吸取的教训

再次承担类似的任务,我们会做一些不同的事情。

优先考虑移交未完成计划的工作 -我们对此感到不知所措。 在整个移交期间,其他开发人员将进行临时更改。 这是为了完成进行中的工作,直到很晚才意识到这一点。 我们应该优先考虑知识交接,而不要完成系统上计划的工作。

尽早进行简单部署-尽早进行首次部署,以最大程度地学习新系统。 我们本可以早点学习有关流程和依赖项的重要课程,而不是记录文档。 您会从中学到很多东西。

没有未发布的工作-直到为时已晚,我们才意识到还有未完成的,未发布的更改。 工作项跟踪尚不明确,当时没有部署管道。 在移交期间,我们没有时间发布此消息。 这使我们无法进行一段时间的热修复,直到解决为止。 移交之前,请确保代码处于可释放状态。

低估复杂性很容易。 我们认为我们可以在入职时将系统迁移到我们的基础架构中。 我们很快意识到我们低估了系统的复杂性。 我们决定支持现有的系统。 因此,我们浪费了一些时间。

希望这对于那些在遗留系统切换的艰苦工作中工作的人可能有所帮助。