Gestión de contratistas en un esfuerzo de conversión de tecnología de una aplicación

Esta pequeña pregunta inocente se lee como un gran fracaso corporativo en muchos niveles...

Recientemente contratamos a una empresa para convertir una aplicación de .NET a .NET Core.

Déjame adivinar. Hace dos o tres años, se hizo evidente que tendrías que hacerlo. La gerencia barajó esa decisión en sus escritorios hasta el año pasado. El año pasado compararon a muchos contratistas y reflexionaron sobre el lenguaje del contrato y las modalidades de pago. Y ahora el proyecto puede comenzar. Pues la realidad no se detuvo y no te esperó. Ese proyecto era bueno hace tres años, pero Microsoft anunció, pasó por una fase beta y lanzó .NET 5 mientras tanto, reemplazando tanto a .NET como a.NET Core, por lo que su proceso corporativo lo ha ralentizado tanto que, a estas alturas, su buen proyecto se ha convertido en un proyecto condenado al fracaso, trayendo su antiguo proyecto heredado al mundo de proyectos heredados ligeramente más nuevos. Es como descubrir que su iPhone 6 es demasiado lento y pedir un iPhone 7 hace tres años y este año finalmente el pedido fue al departamento correcto para obtener uno para usted. Felicitaciones a su nuevo teléfono heredado. Si desea estar al día, su proceso de actualización debe ser al menos tan rápido como el ciclo que desea estar al tanto. Y en comparación con otras tecnologías, Microsoft .NET no se mueve exactamente a la velocidad de la luz. Eres demasiado lento.

Como Scrum Master, estoy tratando de entender el Refinamiento en esta situación.

No hay refinamiento y usted no es su Scrum Master. Has contratado a una empresa para un proyecto. No un grupo de desarrolladores que incorporas a tu estructura de equipo, una empresa. Tienen su propia gestión de proyectos. Ellos le darán actualizaciones si lo solicita. Eso es todo.

Nosotros, como empresa, contratamos a esta empresa debido a su comprensión declarada de cómo hacer la conversión.

Lo que no entiendo... ¿Tienes una aplicación .NET, pero no tienes desarrolladores de .NET? ¿Cómo ocurrió eso? ¿Quién mantiene esta aplicación?

Hemos creado epopeyas que hablan de una aplicación general que necesita ser convertida.

Bueno, creo que no tiene ningún conocimiento de lo que realmente significa "convertir a .NET Core". Si no tiene desarrolladores de .NET de su parte, no es su culpa, pero es muy inconveniente para su empresa, entrar en esto a ciegas sin comprender lo que se debe hacer.

Deben comprender qué tickets deben crearse, en qué orden deben completarse y también qué prioridad tiene cada uno. Deben tener una comprensión de los puntos y estimaciones por tarea.

¿Por qué usarían Scrum en absoluto? Los contrataste para hacer un proyecto. Podrían ejecutarlo como quisieran. Suponiendo que quieran usar Scrum por alguna razón, aquí no hay historias de usuarios. No puede ir característica por característica de la aplicación, eso no tiene ningún sentido. Los cambios de .NET a .NET Core son básicamente cambios de infraestructura. Es posible que todo el código siga ejecutándose igual, pero se debe cambiar la comunicación de red. O la tecnología de base de datos. No puede ingresar a este proyecto y decir "primero haremos la función sobre el inicio de sesión del usuario". No puede cambiar la tecnología de la base de datos para una función . Hacer que esa función se ejecute independientemente de las demás sería más trabajo que simplemente convertirla por completo.

Por lo general, estoy acostumbrado a que el Product Owner ejecute Refinement, haya priorizado el backlog, revise historias, tareas y errores y obtenga comentarios sobre los puntos de la historia y la prioridad.

Tal vez hagan eso. Pero desde fuera diría que no es tu trabajo. Si hacen Scrum, es su trabajo de Scrum Masters. Mostrarle sus elementos de trabajo atrasados ​​no significaría nada para usted, porque no se asignan a las funciones que conoce de su aplicación.

Entonces, como resumen : si desea ser su Scrum Master, debe contratar desarrolladores de .NET en su equipo. Como no lo ha hecho, sino que ha otorgado un contrato para realizar un proyecto a una empresa externa, ellos harán el trabajo como mejor les parezca. Tal vez usen Scrum o tal vez no, pero sus elementos de trabajo no se parecerán a nada que se le hubiera ocurrido a usted, debido a la naturaleza de la tarea. Es puramente técnico y no tiene nada que ver con lo que realmente hace la aplicación.

Por lo general, estoy acostumbrado a que el Product Owner ejecute Refinement, haya priorizado el backlog, revise historias, tareas y errores y obtenga comentarios sobre los puntos de la historia y la prioridad.

Recomiendo mantener una configuración muy similar.

Priorice el trabajo en función de qué características de su aplicación son más valiosas. Esto ayudará a eliminar el riesgo del trabajo: si se excede o tiene problemas al final, será cuando los contratistas estén trabajando en las características de menor prioridad.

Piensa en cómo lanzarás el trabajo. ¿Tendrá una versión de producto mínimo viable (MVP) en .NET Core? ¿Lanzarás las funciones actualizadas a medida que avanzas?

También vale la pena pensar en cómo probará el trabajo. ¿Necesita crear pruebas funcionales en su producto .NET existente que pueda usar para confirmar que el producto .NET Core no ha alterado la funcionalidad?

Bueno, la ventaja es que ya sabes lo que estás construyendo, por lo que no se trata de un proceso de descubrimiento, experimentación y aprendizaje que evoluciona mientras construyes el producto. Por lo tanto, su refinamiento probablemente girará en torno a cómo hacer la conversión.

Probablemente debería sentarse junto con el equipo de contratistas y juntos discutir y decidir sobre una "Definición de Listo". ¿Qué necesitará saber el equipo antes de escribir el código? Esto podría girar en torno a información como:

• cuáles son las dependencias; qué cosas dependen de los demás.
• las dependencias podrían indicarle el orden en el que debe realizar la conversión. O tal vez ordene el trabajo por otra cosa, como lo que podría ser una progresión natural de cambios dada la naturaleza de la aplicación. O tal vez vaya primero por las cosas más importantes y más riesgosas solo para quitarlas del camino.
• criterios de aceptación. Normalmente, esto significaría que las cosas funcionan igual después de la conversión. Si tiene pruebas unitarias o pruebas de integración, aún deben pasar, o al menos cambiarse para pasar en función de lo que ha cambiado. Si algo no está cubierto por las pruebas, ¿qué otros criterios buscará para determinar que nada se rompió? Probablemente deberían discutirse antes de que se realice el trabajo en un sprint.
• comprensión de los requisitos. El código es sagrado. Pero aun así, cuando el código no cumple con los requisitos escritos (porque en Agile no tienes requisitos exhaustivos, solo tienes suficientes seguidos de una conversación), las personas tendrán preguntas y alguien debe responderlas, preferiblemente antes de que el trabajo esté en marcha. sobre algún componente.
• estimaciones Las cosas (código, documentación, etc.) probablemente se revisarán lo suficiente como para tener una buena confianza del esfuerzo necesario y asegurarse de que se ajuste a un sprint.

Tú podrías ser más, pero eso es lo que me viene a la mente ahora. Sin embargo, creo que tratar de ponerse de acuerdo sobre la "Definición de Listo" le dará una pista de lo que debe hacer durante el refinamiento.

Dijiste que los contrataste debido a su comprensión declarada de cómo hacer la conversión. Así que llévelo y pregúnteles cómo quieren atacar esta conversión y qué apoyo necesita ofrecerles. Ayúdalos a que te ayuden.

Y por último, tenga cuidado. Este tipo de proyectos (al menos en mi experiencia, YMMV) pueden hacer que las personas generen nuevas solicitudes. Pueden aparecer nuevas ideas mientras revisa el tema (es decir, "mientras está allí en el código, ¿podría cambiar esto, agregar aquello o eliminar esto otro?" ). Así que asegúrese de no terminar evolucionando el proyecto existente a menos que se haga de manera consciente.