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

23

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í ->.

punkouter
fuente
20
Sham Agile vuelve a levantar su fea cabeza ... Muchas compañías dicen que son "ágiles" y usan "scrum", cuando en realidad no lo hacen.
Oded
44
No estás haciendo Scrum
20
considere imprimir un póster grande de esto y colocarlo en la pared justo donde su personal no técnico pueda verlo claramente: Manifiesto para el desarrollo de software ágil a medias ... mientras que los elementos de la izquierda suenan bien en teoría, estamos una empresa, y no hay forma de que dejemos ir los artículos a la derecha
mosquito
12
enlace obligatorio al blog de Joel: joelonsoftware.com/articles/fog0000000069.html
marco-fiset
8
"<-información sobre las personas no tecnológicas que les dicen a las personas tecnológicas qué hacer aquí->" , la gerencia debería estar 100% por ciento diciéndoles a las personas tecnológicas qué hacer, es por eso que son gerenciales y responsables del negocio , eso es lo que Haz lo mejor. Lo que el 100% debería no estar haciendo les está diciendo cómo hacerlo, las personas tecnología deben decidir sobre la forma en que técnicamente lograr lo que se les ha pedido hacer. ¡Cualquier otra cosa es ingenuidad total !

Respuestas:

7

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.

Erik Reppen
fuente
Con respecto a la refactorización, me parece extraño que la gente no pueda 'internalizar' que la refactorización es una parte constante de todo el desarrollo, no es algo de lo que se pueda criticar cuando el problema es tan grave que no hay mucho que pueda hacer.
nicodemus13
1
O no tienes pruebas unitarias. :) Uno de los principales beneficios de las pruebas unitarias es que le permite refactorizar con confianza. El mayor problema con las buenas prácticas es el mismo que todo: requiere disciplina y, en general, las personas prefieren ser flojas.
nicodemus13
2
Eso o son otro regalo de la multitud de codificación extrema que puede convertirse fácilmente en una herramienta que permite el mal comportamiento en las manos equivocadas. Las pruebas automatizadas son útiles en puntos clave, pero prefiero la arquitectura de sonido y la escritura en una interfaz en lugar de una prueba.
Erik Reppen
1
Yo diría que es lo mismo para cualquier cosa, personalmente escribo las pruebas para ayudar a definir la interfaz.
nicodemus13
1
Luego viene el dolor de todos los errores que se deben volver a poner, ya que hay esas pequeñas excepciones que el análisis inicial no puede captar fácilmente.
JB King
33

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.

EricSchaefer
fuente
8
Si tiene tanta experiencia y sabiduría como afirma, intensifique y sea el tipo que descubra ese módulo que falla, conviértase en un experto en él y corríjalo, y luego prepare un caso de negocios para volver a escribirlo, porque entonces usted será el experto en ese módulo.
3
Algunos desordenes necesitan ser limpiados. Citar los artículos de Joel y afirmar que las reescrituras rara vez funcionan sin ninguna estadística que sería dudosa de todos modos (porque ¿quién se jacta de reescrituras exitosas?) No cambia eso.
Erik Reppen
3
@ErikReppen Entonces, cuando tu sala de estar está desordenada, ¿derribas la casa y construyes una nueva?
EricSchaefer
44
Si lees sus comentarios, no está hablando de la sala de estar. Probablemente sea difícil saber dónde comienza una habitación y dónde termina otra. Y toda la casa está en llamas.
Erik Reppen
55
Vaya, vaquero. Antes de hacer una declaración general sobre "reescribir no es una buena idea", creo que debemos calificar eso con la verdad de que pasar a las nuevas tecnologías y adaptarse a los tiempos es esencial para la supervivencia de TI de su negocio. Si no adopta tecnologías más nuevas (ojalá mejores) y las ventajas que ofrecen, sus competidores lo harán. Esto es cierto para la tecnología en general. El Model-T era un vehículo perfectamente bueno, pero gracias a la competencia y la adopción de nuevas tecnologías, los autos han sido "reescritos" muchas veces en los vehículos mucho mejores que manejamos hoy.
carne
18

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,

S.Robins
fuente
No. No estoy a cargo. Soy un desarrollador que ha codificado 12 años profesionalmente y 7 años .NET. He estado presente en muchos contratos y después de un tiempo rápidamente puede tener una idea de la calidad del código. ¿Cuánto 'estaca'? No estoy seguro de lo que quieres decir con eso. Podemos seguir desconectando arreglando el viejo ASP CLÁSICO que ahora es extremadamente frágil y tomar 10 veces más tiempo que si estos cambios fueran parte de una buena arquitectura moderna. La justificación comercial es que el sitio ahora se está bloqueando en la producción debido a un módulo que nadie parece entender debido a la alta rotación
punkouter
No creo que entiendas cuán malo es este código base. Además de eso, esto no es ciencia espacial. Esto es CRUD 101. Esto muestra un formulario, permitiendo que un usuario lo complete, valide y luego cree algunos informes y archivos PDF a partir de los datos. Eso es básicamente eso ... Pero a lo largo de 10 años el código se ha fragmentado en tantas partes que es horrible. He formado parte de unos 20 proyectos en los últimos 12 años y esta tiene que ser la peor colección de código que he visto que realmente se usa en la producción ... Desearía poder mostrarles a todos
punkouter
Lo que estoy haciendo para empezar es encontrar a las personas que están en el equipo que tienen cierta pasión por la codificación y están interesadas en ser parte de finalmente hacer esto bien. No es fácil encontrar a esas personas por ... brucefwebster.com/2008/04/11/…
punkouter
16
@punkouter: No creo que entiendas el punto que se hace aquí; El código base es "malo" no es un caso de negocios para una reescritura. Tener pasión por la codificación y querer hacer las cosas bien no es un caso de negocios para una reescritura. Errores de producción costosos e interrupciones, y tomar meses para implementar nuevas características triviales pero importantes: AQUELLOS proporcionan un caso de negocios para una reescritura.
Michael Borgwardt
1
@punkouter Su enlace a una descripción del fenómeno del "Mar Muerto" también es particularmente adecuado. No tiene ningún valor para el negocio perder conocimiento a través del desgaste, y de gran valor reclamar lo que puede. Una inversión de su tiempo para evitar una reescritura potencialmente costosa e innecesaria tiene mayor valor comercial que perder conocimiento y experiencia. Fomentar mejores prácticas de contratación y enfrentar el desafío de reducir el problema y mejorar el sistema es una oportunidad para que usted gane un poco de prestigio y se convierta en un activo valioso para su empleador.
S.Robins
13

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.


fuente
8
El equipo es responsable de su propio desorden, pero no pueden elegir la prioridad de la deuda técnica frente a las nuevas características. Es el propietario del producto quien decide eso. Es solo que, una vez que el OP ha decidido la prioridad del trabajo atrasado, el equipo puede decidir cómo entregarlo. Pueden decir "no podemos entregar la función X sin primero refactorizar Y" pero no pueden decir "no, lo siento, no agregaremos ninguna función nueva hasta que la reescribamos desde cero".
Bryan Oakley
66
@BryanOakley: Reescribir desde cero no es lo que sugiero. Sugiero reducir progresivamente la deuda técnica a medida que el equipo de desarrollo trabaje en las áreas en cuestión. Y también sugiero que estimen en consecuencia.
1
Eso es bueno, pero ¿qué pasa si necesitamos nuevos servidores, nuevas bases de datos, nuevo software para que los desarrolladores tengan todas las herramientas que necesitamos para reescribir? ¿Y cómo comienza la reescritura cuando las únicas 'Historias' tratan sobre solucionar problemas actuales y nunca sobre el concepto de permitir una reescritura?
punkouter
1
@punkouter: si tiene que volver a escribir, aborde el problema en la retrospectiva de scrum. Luego, el Propietario del producto asumirá la responsabilidad de cancelar el proyecto actual y comenzar uno nuevo.
55
No asuma que la decisión de reescribir es la "correcta" solo porque es la que más atrae a los desarrolladores. A veces hay una buena razón comercial para ofrecer funciones ahora, a pesar de que va a aumentar la deuda técnica.
DJClayworth
8

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.

Peter Mortensen
fuente
1
eso no significa que no sea responsabilidad de los desarrolladores usar algún sistema de control de versiones de forma interna , independientemente, diría que todavía es responsabilidad de los desarrolladores cuidar de sí mismos y de sus mejores intereses independientemente. En su caso, esos 200 desarrolladores no hicieron lo que tenían que hacer, la administración no les puso un arma en la cabeza y les prohibió configurar ellos mismos el sistema de control de versiones.
3
Las bases del código desordenado nunca son un resultado directo de la administración, ya que la administración nunca es directamente responsable de escribir el código. Es así de simple. Manangement es responsable de tener y fomentar un entorno de trabajo menos que ideal para los desarrolladores, pero la responsabilidad de resolver problemas como la falta de control de versiones siempre recae en quienes realizan el trabajo real.
Peter Lange
1
Los desarrolladores externos son un problema de gestión. La gente del interior sabía mejor. A la gerencia le gustaba fingir que estaban ahorrando enormes cantidades de dinero mediante la contratación de 200 desarrolladores, cuando de hecho probablemente podrían haberlo hecho bien con 20 competentes. Al igual que muchas de las implementaciones de Scrum que he visto, la estrategia adoptada fue producto de la incompetencia y nada sobre lo que los desarrolladores que en realidad eran empleados de la compañía tenían control.
Erik Reppen
2
@Erik, sin decir que los gerentes no tienen que asumir la responsabilidad de una mala base de código (o cualquier otra mala decisión tomada en su departamento) y que los gerentes no son directamente responsables de proporcionar el entorno en el que trabaja el desarrollador, como el escenario que usted describió. Pero la única persona que puede ser directamente responsable de la base del código es la persona que escribe el código en sí.
Peter Lange
3
También me gustaría agregar que es estúpido no hacer que sus desarrolladores conozcan los objetivos comerciales. Nunca he entendido por qué las personas están tan decididas a ocultar estas cosas a las personas que realmente determinan el comportamiento de su producto. Conocer los objetivos a largo plazo de una empresa puede, de hecho, informar cómo diseña una aplicación. Además, los desarrolladores, al menos los buenos, resuelven problemas. Constantemente, resuelven problemas. Algunos de nosotros anticipamos y resolvemos con anticipación en nuestras cabezas o al menos dejamos las puertas correctas abiertas en nuestro código.
Erik Reppen
7

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.

Michael Brown
fuente
Eso puede ser difícil si la base existente es un desastre. Él está hablando de múltiples sistemas asp.net heredados de autores completamente diferentes estrechamente unidos para el mismo maldito sitio. Los formularios web por sí solos son un monstruo y estoy seguro de que eso está en la mezcla.
Erik Reppen
Oh, nunca dije que sería la ruta más fácil ... pero es más apetecible para las partes interesadas. Además, al revisarlo una vez, con suerte se asegurará de que cuando lo último y mejor de hoy se vuelva anticuado mañana, sea más fácil eliminarlo gradualmente.
Michael Brown
Estoy de acuerdo. Pero como he dicho (y no estoy seguro de que todos lo conozcan). Lo que existe ahora es una colección de aproximadamente 9 aplicaciones web separadas, la mitad de las cuales son ASP clásicas y la otra mitad son formas diferentes de ASP.NEt. Todos usan formas totalmente diferentes para manejar el acceso a datos, etc. Entonces, la única forma de hacer lo que se habla es falsificar la IU para que parezca que el nuevo código es parte del código anterior ... así que sí, tal vez ... pero luego hay una la base de datos .. ¡Una tabla tiene 400 campos!
punkouter
Soy curioso. ¿Qué representa esa tabla? Eso es lo peor que he oído desde que vi i ++; hacer algo (i); repetido más de una docena de veces en algún código que se derramó de una etiqueta JSP rota.
Erik Reppen
5

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.

BennyB
fuente
¿Entonces los desarrolladores pueden escribir 'historias' y enviarlas? El problema es explicar que las razones para reescribir son demasiado técnicas para que puedan manejarlas ... Todo lo que puedo decir es ... 'El código actual es difícil de administrar y se rompe' ...
punkouter
66
@punkouter: si las razones para querer reescribir son puramente técnicas (es decir, no le cuestan dinero al negocio), entonces NO TIENE razón suficiente para una reescritura.
Michael Borgwardt
@MichaelBorgwardt: ¿Estás diciendo que alguna razón técnica nunca es suficiente para reescribir algo? Ese es un enfoque fundamentalmente roto, si te entiendo correctamente. Una cosa que continuamente me pone nerviosa es el enfoque normal maestro / esclavo de que el 'negocio' determina todo lo que 'TI', o cualquier departamento hace. Eso solo es cierto hasta cierto punto. TI tiene sus propios requisitos que son internos y no son decididos por el negocio; esto es algo que generalmente falta y conduce a un software no diseñado, no apto para el propósito.
nicodemus13
1
@ user12355 Como he visto, el punto de Michaels es que si no les está perdiendo dinero, no les hará dinero, entonces nunca habrá un caso. Si no están perdiendo dinero, una reescritura les cuesta dinero. Dinero que no se puede recuperar. Un desarrollador podría presentar el caso de "este código apesta", pero a menos que puedan demostrar un beneficio financiero para su empleador, nunca obtendrán la luz verde para volver a escribir a menos que lo hagan por su cuenta.
Plataforma
1
@ user12355: Las razones técnicas son definitivamente suficientes para una historia de usuario. No son necesariamente suficientes para que esa historia pase a la cima de la lista y se coloque en un sprint.
Adam V
4

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.

Buhb
fuente
1
Correcto y cuando tienes un historial de 10 años de rotación constante y de desarrolladores únicos que claramente no podían codificar bien o entender la arquitectura moderna entonces ... tienes lo que tengo ahora ... Estoy más alarmado que nadie desde que yo soy nuevo en el trabajo y no estoy acostumbrado a ver un nivel de código de tan baja calidad ... Quiero la reescritura no solo por mi deseo egoísta de disfrutar escribiendo un nuevo código bueno ... sino también por el bien de todos los demás ... incluso si ellos no entienden la situación como yo.
punkouter
1
Solo puedo reiterar lo que ya se ha dicho; Formalmente, no puedes decidir que ahora es el momento de la gran reescritura. Supongo que podría intentar mostrar a los interesados ​​cuánto esfuerzo se necesita para convertir gradualmente su base de código en un estado un poco menos doloroso, y compararlo con el esfuerzo que se requiere para realizar una reescritura completa.
Buhb
3

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.

guillaume31
fuente
Como mencioné .. No hay forma de avanzar con una colección de 6 sitios ASP clásicos + 4 sitios .net 1.1 que se combinan en un solo sitio. Todo codificado por diferentes personas de diferentes maneras.
punkouter
Estoy bastante seguro de que la base del código avanzará, en los próximos años, parafraseando al Dr. Ian Malcom del Parque Jurásico "Estoy, simplemente digo que la gerencia, eh ... encuentra la manera" .
Es posible que esté presente en los próximos años, pero no es probable que los sabores variados de sitios .net heredados estrechamente unidos se muevan muy lejos en esos años.
Erik Reppen
Claro, pero si todos esos sitios .net continúan funcionando y su funcionamiento continúa generando ingresos directa o indirectamente para la empresa, ¿por qué es tan importante el impulso hacia adelante? Cuando los ingresos se ven directamente afectados por la calidad de la base de código, puede creer que los gerentes no perderán tiempo en rediseñarla, ya que todos tienen hipotecas que pagar al igual que los desarrolladores.
Peter Lange
El impulso directo incesante es generalmente la raíz del problema en primer lugar en mi experiencia. El dolor comienza cuando las expectativas de respuesta no disminuyen mientras todavía hacen oídos sordos a los problemas en la arquitectura y piensan que Scrum desarrollará mágicamente nuevos conjuntos completos de características completas cada dos semanas sin agravar aún más el problema. No digo que no debamos tener cuidado con la urgencia de arrancar cosas si no podemos encontrar alternativas que resuelvan los sumideros de tiempo que estamos encontrando, pero he visto al menos dos casos muy buenos para grandes Revisiones en mi carrera.
Erik Reppen
2

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.

Peter Lange
fuente
1
Si estoy leyendo entre líneas aquí correctamente, parece que estás un poco amargado por tu incapacidad para aferrarte a los nuevos empleados. Si no me equivoco, ¿ha considerado que las nuevas contrataciones cuyas habilidades tienen de hecho suficiente demanda para caminar cuando no les gusta trabajar en su empresa son las únicas no constantes en la ecuación?
Erik Reppen
1
Ni siquiera cerca. En realidad, los empleados de mi departamento han estado conmigo durante algunos años. Prácticamente no tengo vuelta. El punto que estoy tratando de hacer es que, en última instancia, en cualquier empresa, en cualquier industria, el trabajo que realiza el empleado depende completamente de la persona que firma el cheque de pago y no del empleado. La única decisión que debe tomar el empleado, incluido yo mismo cuando mi jefe hace una solicitud, es persistir o no con la relación del empleado. El póster original preguntaba cuándo él, como empleado, puede dictar el desarrollo. La respuesta es nunca.
Peter Lange
Entonces, ¿qué pasaba con la caracterización de "temer a mi loco skilz"? Este chico es un desarrollador experimentado. Y puedo decirle, por mi experiencia con situaciones similares, que el problema del que está hablando no es solo una cuestión de querer las cosas a su manera, sino en realidad un desastre continuo que está haciendo que todos se sientan miserables y que le cueste mucho más a su empleador desperdiciar el desarrollo retención de tiempo y talento de lo que probablemente se dan cuenta.
Erik Reppen
1
Porque estaba ilustrando la falacia del argumento básico, que estaba enraizado en el ego (en un sentido psicológico). No se trata de cuán hábil sea. No es una cuestión de qué tan mal está el código. No se trata de lo que la metodología de desarrollo puede hacer por él. Es una pregunta sobre el poder. El poder de tomar decisiones en una relación de empleado reside en el empleador. El único poder decisivo que tiene un empleado es cancelar la relación cuando se vuelve demasiado difícil de soportar.
Peter Lange
1
Estoy de acuerdo, scrum es pésimo para lidiar con la deuda tecnológica. Pero no estoy de acuerdo sobre la base de la pregunta original. De hecho, estaba haciendo una pregunta de relación empleador / empleado, pero acaba de mencionar scrum en la pregunta. Es como si le preguntara: "Como cristiano, ¿cuál es la mejor manera de hacer una Enchillada?". No es realmente una pregunta teológica; Es una cuestión de cocina, incluso si cometí el error de pensar que mis preferencias religiosas eran relevantes.
Peter Lange
1

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.

Nemanja Trifunovic
fuente
Un proceso de desarrollo que promete que las cosas se completarán cada dos semanas puede hacer mucho para obstaculizar la refactorización a gran escala que se ha ignorado durante años. Lo primero que noté en el entrenamiento de scrum es la forma en que aclaran el tema de la deuda tecnológica. No es emocionante declarar que su aplicación ahora es más ágil y más mala y que puede hacer las cosas más rápido. Los tipos de negocios quieren valores visibles que puedan mostrar a amigos e inversores.
Erik Reppen
1

¿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á.

Halcón
fuente