Acabo de comenzar un trabajo con Scrum y parece que falta algo. Soy nuevo en Scrum

El código es un completo desastre de una combinación de ASP / ASP.NET clásico. El scrum consiste en que nosotros arreglemos el gran desastre o hagamos adiciones. Estamos muy ocupados haciendo eso para comenzar una reescritura, así que me pregunto ...

¿Dónde está la parte en Scrum donde los desarrolladores pueden tener el poder de decir que ya es suficiente y exigir que se les dé tiempo para comenzar la gran reescritura? Parece que estamos en un ciclo interminable de simplemente parchear código antiguo con 'Historias'.

Así que las cosas no están siendo manejadas por personas no técnicas que parecen no tener deseos de presionar por una reescritura porque no entienden lo mal que se ha vuelto la base de código.

Entonces, ¿quién está a cargo de hacer realidad este gran cambio de reescritura? Los desarrolladores? El Scrum Master?

La estrategia actual es solo encontrar tiempo y hacerlo nosotros mismos sin los altos mandos involucrados, ya que ellos son los principales culpables del desorden actual en el que estamos ... <-inserte discursos acerca de personas no técnicas que le dicen a las personas técnicas qué hacer aquí ->.

No estoy seguro de por qué esto es tan difícil para la gente. Su caso de negocios está aquí:

We seem in an endless loop of just patching old code with 'Stories'.

El tiempo del desarrollador es dinero. Mucho dinero. Dejé una empresa que planeaba renovar su interfaz de usuario hace más de un año y esperaba que la adopción de scrum les ayudara a dejar de girar sus ruedas. ¿Que pasó? El mismo viejo 'mismo viejo'. Continuaron agregando nuevas características y la "deuda técnica" no tenía ningún caso comercial a pesar de que la mitad del código que escribimos dejó de tener sentido con cada iteración debido a que la base de código subyacente era un desastre completamente obsoleto. Nada ha cambiado en su extremo frontal desde que me fui, y fui contratado con el solo propósito de renovarlo por completo. En los dos meses que estuve allí, en realidad no toqué CSS ni JavaScript. Estaba jugando con HTML y algún antiguo sistema de plantillas Java de finales de los 90.

¿Mi respuesta? Haga lo que pueda, pero si los otros desarrolladores ya se han rendido y están trabajando hasta tarde para cumplir con los objetivos del sprint en lugar de afirmar plazos más prácticos e insistir en que la deuda tecnológica es en realidad un problema de bloqueo, asuma lo peor y comience a buscar un nuevo trabajo ahora. ¡Sus desarrolladores no pueden o no pueden comunicar sus inquietudes o el negocio también lo es! @ # $ Ing miope para comprender cuánto dinero están gastando.

Ignorar estos problemas SIEMPRE cuesta más a largo plazo. Y no un poco más, sino MUCHO más. No solo es una herida en el pecho por succión en lo que respecta al tiempo de desarrollo, sino que también inevitablemente reducirá sus niveles de talento ya que los desarrolladores que conocen mejor y tienen otras opciones evitarán su compañía como la peste. Mi jefe actual es un desarrollador Y el dueño de la empresa. Hay cosas que no reescribiremos a favor de centrarnos en otras prioridades, pero cuando algo realmente necesita un refactor debido a ser un disipador de tiempo constante, obtiene un refactor adecuado. Y los resultados son obvios. Modificar y agregar cosas nuevas se vuelve más fácil y rápido por múltiples factores. Lo que una vez pudo haber tomado horas puede tomar minutos con la arquitectura adecuada. A las empresas no les gusta escucharlo, pero vale la pena poner las cosas en espera para eso.

Scrum es una falla en entornos en los que los desarrolladores no tienen mucho dominio, en mi opinión, porque es demasiado fácil para los tipos de negocios querer ignorar el mantenimiento y las actualizaciones a favor de los puntos que pueden incluir en sus listas de "iniciativas exitosas" cuando El tiempo de evaluación llega. Siempre favorecerán sus pieles y su potencial de promoción a largo plazo, incluso cuando les moleste constantemente ignorar estos problemas también.

Scrum también es una industria con ánimo de lucro y algo más. Las empresas pagan mucho dinero por el entrenamiento scrum. Las personas que buscan adoptar deben mirar con cautela a quién se comercializa y cuán realista será dentro de su cultura.

De todos modos, si realmente le importa el desarrollo, una base de código horrible, la administración con cera en los oídos y los desarrolladores sin espinas es una receta para la miseria y un entorno que hará muy poco para mejorar su conjunto de habilidades en cualquier aspecto útil. No dude en comenzar a poner en marcha los pasos para GTFO antes de haber descubierto si sus esfuerzos para solucionar el problema realmente están dando resultado.

Si realmente estuviera haciendo Scrum, lo cual dudo, el propietario del producto sería responsable de decidir sobre una reescritura. La mayoría de las veces una reescritura no es una buena idea, por cierto, porque no produce nuevas funcionalidades, solo introduce nuevos errores.

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

Para ampliar "reescribir no es una buena idea":

Casi siempre es mejor intentar una mejora gradual. Al igual que Jarrod Robertson escribió en un comentario, encuentre un módulo que necesita mejoras, conviértase en el experto para ese módulo y escriba una historia para el próximo sprint para mejorar ese módulo en particular. Explique al propietario del producto por qué ese módulo necesita trabajo.

Voy a ser muy directo ...

• ¿Estás a cargo de los desarrolladores en este trabajo?
• ¿Eres el líder del proyecto?
• ¿Cuánta "participación" tienen los desarrolladores en el proyecto?
• ¿Cuál es su justificación comercial para una reescritura?
• ¿Qué tiene el código base que lo hace completamente inútil e irrecuperable?

Has declarado que acabas de comenzar un trabajo y, sin embargo, ya pareces ser un maestro de la situación allí. Tal vez he entendido mal la intención de su pregunta, pero tengo la impresión de que ha ingresado a un trabajo donde ve una serie de problemas, y ha llegado a la conclusión más fácil en la que el código está roto y el único camino a seguir es una reescritura, pero ¿realmente ha considerado el costo para su empleador?

Con cualquier base de código existente, sin importar cuán pobre sea el estado en que se encuentre, el propietario generalmente tendrá una inversión considerable en los productos que representa el código. Hay costos directos e indirectos asociados con la base del código, y una reescritura es a menudo lo último que desea hacer como desarrollador de software, ya que corre el riesgo de devaluar los activos de su código y, por lo tanto, obtener un rendimiento más bajo de todos sus anteriores esfuerzos

Tome el sistema operativo de Windows como ejemplo. Con cada nueva versión creada, ha habido una gran porción de código de la versión anterior. En ocasiones, se arrastran bibliotecas y API completas a través de varias generaciones de SO. ¿Por qué? Debido a que los desarrolladores saben que estos elementos funcionan, se han probado, se han parcheado y reparado para evitar problemas de seguridad y memoria, y porque han costado muchísimo dinero entrar en ese estado. Nadie quiere tirar el código de trabajo cuando les está haciendo dinero, incluso si los costos de mantenimiento son relativamente altos, el costo de comenzar desde cero siempre será aún mayor, y en una compañía como el caso de Microsoft, tienen miles de millones en el banco que permitirles comenzar desde el principio si quieren, pero no lo hacen t porque quieren maximizar el retorno de su inversión. Su empleador no es diferente a Microsoft, excepto por el hecho de tener miles de millones en efectivo para lanzar en un proyecto.

Por lo tanto, el código es un desastre y parece que hay problemas de comunicación y límites entre las diversas áreas de la empresa. ¿Qué pueden hacer usted o sus colegas al respecto?

Una opción es simplemente continuar como lo ha estado el equipo y esperar un milagro en el futuro. Probablemente no sea una buena idea, y es probable que solo aumente su frustración y estrés.

Una mejor opción es simplemente esforzarse y hacer su trabajo, pero como parte de esta búsqueda de oportunidades para agregar pruebas para admitir aquellas áreas de código que parecen ser las más frágiles, luego refactorícelas hasta que se vuelvan más estables. Te resultará más fácil hacer un argumento convincente para mejorar la inversión de la compañía en lugar de argumentar que simplemente lo descartes.

Una opción aún mejor es organizarse como un equipo y asegurarse de que alguien esté de acuerdo con la suficiente antigüedad como para que puedan hacer un buen caso para permitir que el equipo tenga más flexibilidad para programar el tiempo para mejorar la base del código. No me importa cuán ocupada esté una empresa, o cuán rígido parezca ser el cronograma, siempre hay "pausas" ocasionales en la actividad que se pueden usar para exprimir una o dos mejoras. Sin embargo, es aún mejor si las mejoras se pueden realizar al completar otras tareas. Si fuera yo, me estaría acercando a un gerente y presentándoles conceptos en algunos de los libros canónicos que leen los desarrolladores de software. Código limpioes probablemente la que más necesita tu equipo. Plante algunas semillas sobre cómo mejorar el código y proporcione algunos ejemplos de lo que quiere decir. Un buen administrador verá el valor de agregar mejoras incrementales al código, especialmente si puede describir el concepto de Deuda técnica . Ayude al líder o gerente de su equipo a hacer un buen caso de negocios para mejorar el código, y tendrán una mejor motivación para actuar en consecuencia.

Tampoco es suficiente decir "el código está desordenado". Debe alentar a sus colegas a que practiquen la codificación limpia todo el tiempo, y a utilizar una técnica de codificación limpia para alentar un poco la limpieza a medida que avanza. Tengo un pequeño póster que imprimo y cuelgo de la pared de mi oficina cada vez que tomo un nuevo trabajo. Dice "Siempre trata de dejar el código un poco más hermoso de lo que lo encontraste". Justo al lado, agrego otro que dice "Los lirios no necesitan ser dorados". Ambos sirven para recordarme que siempre debería tratar de mejorar lo que encuentro, pero evitar simplemente dorar un problema con otro. Las reescrituras masivas son a menudo el peor tipo de "chapado en oro", porque a menudo se hacen por razones equivocadas. Seguro que una versión de producto completamente nueva podría ser justificable en algún momento,

Aquí está la definición oficial del Equipo de desarrollo de Scrum de la Guía oficial de Scrum . Pongo énfasis en las partes que te conciernen directamente:

El Equipo de Desarrollo está formado por profesionales que realizan el trabajo de entregar un Incremento potencialmente liberable del producto "Listo" al final de cada Sprint. Solo los miembros del equipo de desarrollo crean el incremento. Los equipos de desarrollo están estructurados y capacitados por la organización para organizar y administrar su propio trabajo . La sinergia resultante optimiza la eficiencia y efectividad general del Equipo de Desarrollo. Los equipos de desarrollo tienen las siguientes características:

• Son autoorganizados. Nadie (ni siquiera el Scrum Master) le dice al equipo de desarrollo cómo convertir la cartera de productos en incrementos de funcionalidad potencialmente liberable;

• Los equipos de desarrollo son multifuncionales, con todas las habilidades como equipo necesarias para crear un incremento de producto;

• Scrum no reconoce títulos para los miembros del Equipo de desarrollo que no sean Desarrollador, independientemente del trabajo que realice la persona; No hay excepciones para esta regla;

• Los miembros del Equipo de Desarrollo Individual pueden tener habilidades especializadas y áreas de enfoque, pero la responsabilidad pertenece al Equipo de Desarrollo en su conjunto; y,

• Los equipos de desarrollo no contienen sub-equipos dedicados a dominios particulares como pruebas o análisis de negocios.

Por lo tanto, el equipo de desarrollo es responsable de su propio desorden y debe abordarlo por sí mismo, sin tener que preguntar a nadie fuera del equipo.

Incluya un tiempo de fijación de deuda técnica en cada una de sus estimaciones futuras y asegúrese de que la calidad del software que entrega sea de primera categoría.

Si realmente tiene que hacer una reescritura completa, debe abordar el problema en la Scrtros Restrospective. El propietario del producto eventualmente puede cancelar el proyecto y comenzar uno nuevo. El propietario del producto también es el único capaz de cancelar un sprint.

Como se describe esto, tengo que decir que no veo cualquier cosa que tenga algo que ver con SCRUM, o su equipo de desarrollo de productos es un problema actualmente .

Esto es normal

Lo que describe es la entropía normal de una base de código. En su caso, el equipo probablemente comenzó más lejos del ideal, pero aún así cada base de código finalmente se convierte en una Gran Bola de Barro .

En un escenario greenfield completamente perfecto , todo lo que puede hacer es comenzar más lejos de la entropía absoluta y avanzar más lentamente.

Estoy de acuerdo con otros, el desorden de la base del código se debe a los desarrolladores. Estoy seguro de que es anterior a la adopción de SCRUM por muchos años.

Esta no es una decisión técnica o del desarrollador para volver a escribir, es una decisión comercial.

No sabe por qué los propietarios de los productos no quieren una reescritura. Usted como desarrollador cree que es necesario, pero ¿hay realmente algún caso de negocios para ello?

Si hay un verdadero caso de negocios , no solo una mano saludando; "el código es un desastre heredado que quiero comenzar de nuevo porque eso es lo que quiero" , entonces la gerencia consideraría el gasto de una reescritura, considerando la rentabilidad de esa inversión.

Nadie se ha dado un sólido caso de negocio para una re-escritura, sólo una queja acerca de su opinión sobre cómo todo el mundo causó este lío y que no quieren tratar con él.

Prueba: las ganancias impulsan las decisiones comerciales de deshacerse del software de trabajo, no una necesidad del TOC de una base de código limpia

Si realmente puede mostrar pruebas , no solo la teoría, sino también pruebas contundentes de que el gasto de Xdólares en una reescritura de greenfield garantizará GANAR X * N dólares para el negocio en el Ymarco de tiempo (donde Nes alto y Yes corto), puede obtener algo de tracción de la gerencia . Este es un caso altamente improbable que puede presentar y probar.

De lo contrario, solo tiene que lidiar con eso, esta es la realidad. Contrariamente a sus inflexibles afirmaciones de que no hay absolutamente ningún camino a seguir sin esta gran reescritura inmaculada, apostaría dinero a que más de 5 años a partir de ahora la base de código de la que se queja seguirá funcionando y funcionando en algún lugar proporcionando a alguien funcionalidad y valor mucho después Has dejado la empresa.

Generalmente soy escéptico cuando la gente presiona por "grandes reescrituras". Hay algunos casos en los que definitivamente tiene sentido, pero la mayoría de las veces, ese código heredado tiene valor (en el sentido de que ya está en producción y se utiliza para los fines que inspiraron su creación). Realizar una gran reescritura es en muchos casos lo contrario de ágil. ¿Cuánto tiempo llevaría llevar la nueva versión de la aplicación a un punto en el que pueda reemplazar de manera viable la aplicación existente?

El enfoque que preferiría es lo que Martin Fowler llama la vid estranguladora . Implemente una nueva funcionalidad (incluidos los cambios en la funcionalidad existente) usando el nuevo enfoque, pero use la aplicación existente como un enrejado sobre el cual la nueva funcionalidad puede crecer. Esto le brinda lo mejor de ambos mundos, no tiene que detener todo mientras se reescribe la gran reescritura, pero obtiene el beneficio de escribir un nuevo código que aprovecha los marcos actualizados. Definitivamente es un enfoque más difícil que comenzar de cero y puede que no sea tan sexy, pero proporciona más valor al negocio que deshacerse de todo lo que está allí porque está desactualizado.

Dónde estoy y cómo trabajamos, esto es lo que haríamos: escribir una nueva historia y entregarla al propietario del producto, quien luego decidirá cómo priorizarla. Un ejemplo sería: "Como desarrollador del producto X, me gustaría volver a escribir el código en esta área para que el desarrollo futuro sea más eficiente" Los criterios de aceptación tendrían que estar en la línea de: Reescritura / refactorización x para que sea mejor de esta manera.

No sé acerca de la situación en la que se encuentra, pero aquí, si quisiéramos reiniciar desde cero, sería un caso de sentarse con el propietario del producto y convencerlo de por qué y luego escribir un montón de historias para recrear las existentes. funcionalidad

Las otras cosas que hemos hecho para tratar de lidiar con el código incorrecto y / o heredado han sido incluir tareas para reelaborar cuando se distribuyen las historias de los usuarios.

Decidir grandes reescrituras es una decisión comercial. Puede intentar influir en las decisiones comerciales vendiendo desde su punto de vista a las personas responsables de la parte comercial de las cosas.

Sin embargo; El cambio en la calidad del código de una iteración a la siguiente es una decisión del desarrollador. Si permite que disminuya la calidad del código, está agregando deuda técnica para cumplir con las expectativas del propietario del producto ahora. Lo que puede hacer es comenzar a asumir la responsabilidad del código que escribe y asegurarse de que mejore la base del código, y no al revés. Ahora, esto significa que perderá velocidad, ya que está disminuyendo continuamente la cantidad de deuda técnica, y el propietario de su producto seguramente se decepcionará. Puede intentar explicar que en su afán de agradar, ha dejado que la calidad del código se degrade y ahora está tomando medidas para corregir este problema.

Ahora, me doy cuenta de que es un paso aterrador, y puede ser tentador retrasarlo solo un sprint más para que puedas salir de la función X antes de una fecha límite importante. Desafortunadamente, será más difícil cuanto más esperes.

Por cierto, esto no es estrictamente un problema de Scrum, ni estoy sugiriendo una solución que sea específica para Scrum. Esto se trata de que los desarrolladores se apropien del código.

Los desarrolladores son responsables de alertar al mundo sobre el estado actual de la base de código. Esto puede suceder durante un scrum diario, una retrospectiva o solo de manera informal. Puede parecer obvio, pero si no expresa claramente qué desastre es y cuánto tiempo pierde debido a eso, nadie lo notará. El Scrum Master generalmente será responsable de pasar la información a la OP y a las personas a cargo del proyecto y convencerlos de que se debe hacer algo, y luego facilitar la implementación de una solución por parte del equipo.

Como nota al margen, una reescritura de Big Bang es IMO no necesariamente la respuesta correcta a este tipo de problema. Sin embargo, hartos de que los desarrolladores estén con la base de código actual, tomar pequeños pasos medibles hacia una arquitectura más limpia a menudo es una mejor idea, ya que puede ver el progreso, justificar su trabajo al mostrar regularmente a la OP los logros y continuar el flujo de implementación de nuevos usuarios historias paralelas en lugar de perderse en un cambio de imagen interminable y monopolizador de recursos.

Tu preguntaste:

¿Dónde está la parte en Scrum donde los desarrolladores pueden tener el poder de decir que ya es suficiente y exigir que se les dé tiempo para comenzar la gran reescritura? Parece que estamos en un ciclo interminable de simplemente parchear código antiguo con 'Historias'. Por lo tanto, las cosas no están siendo manejadas por personas no técnicas que parecen no tener deseos de presionar por una reescritura porque no entienden lo mal que se ha vuelto el código base.

Como alguien que es tanto gerente como desarrollador, la respuesta más simple a su pregunta es que no hay parte en Scrum, ni en ninguna otra metodología, ni en ningún escenario comercial, donde el desarrollador tenga el poder de decir que ya es suficiente y exigir un volver a escribir. Muchas personas aquí han presentado argumentos buenos y válidos para explicar por qué las reescrituras son con frecuencia malas ideas, y para explicar cómo el cambio puede y debe llevarse a cabo de manera incremental y ágil. Y estoy de acuerdo con todos ellos.

Pero el resultado final es aún más simple. No puedes tomar esa decisión, NUNCA. Usted es el empleado, y la única decisión que realmente puede tomar es "continuaré trabajando para estos imbéciles o encontraré un nuevo trabajo que teme a mis habilidades locas". Tu nuevo trabajo tampoco te permitirá tomar esa decisión, pero al menos sentirás que tienes el control de tu destino mientras saltas de un trabajo a otro.

Siento tu dolor, pero no estoy seguro de qué tiene que ver con Scrum. La decisión de volver a escribir el código no depende del proceso de desarrollo.

¿Esperar lo?

¿Estás remendando ? Deberías estar refactorizando . Se adhieren a los valores ágiles. Use TDD y las prácticas apropiadas y la situación eventualmente mejorará.