Así que empecé a trabajar para un gran cuerpo, uno de esos con 3 letras en el nombre, y están tratando de volverse ágiles, pero tienen toneladas de procesos, que no creo que sean ágiles.
El que más me tiene herido son las revisiones de código. Mi último trabajo fue con una startup que diría que es el equipo de desarrollo más ágil que he visto, estado y / o escuchado.
De todos modos, mi argumento es que las revisiones de código son una pérdida de tiempo en el desarrollo iterativo o ágil donde la UX / UI es extrema / intensa (creo que la perfección de Apple / Steve Jobs). Tal vez alguien aquí pueda ayudar a entender antes de despedirme?
Aquí está mi proceso de desarrollo y el de mi último inicio ... muy ágil.
Realizamos el primer trabajo de características para clasificar la tarea de desarrollo / todos. Nos gustaría burlarnos de un par de versiones y presentarlas a los usuarios, al equipo y al marketing para obtener comentarios. Luego hacemos otra iteración de maqueta para obtener una ronda de los mismos interesados mencionados anteriormente. Luego repartimos el trabajo y comenzamos. Tenemos hitos y fechas que cumplir, pero seguimos conectándonos. No tenemos revisiones de código durante nada de esto. Varias veces durante las semanas de nuestro desarrollo, celebramos sesiones con las partes interesadas de nuevo para ver si aún están de acuerdo en que las funciones / funciones / UX / UI siguen siendo un ajuste adecuado.
A medida que nos acercamos al final del ciclo de iteración de 8 semanas, el control de calidad comienza a probarse, luego va a los usuarios alfa y finalmente a los usuarios beta. Pero durante el alfa y beta, los desarrolladores están revisando las nuevas características y las características más antiguas, haciendo cambios iterativos diarios o de hora en la interfaz de usuario para mejorar la UX. Por lo tanto, una característica que se estaba desarrollando en esta versión podría terminar siendo cambiada 3 veces más en las últimas cuatro semanas para mejorarla y perfeccionarla o agregar algunas características pequeñas (por ejemplo, hacer que el componente sea un poco más pulido o más inteligente). A veces, los cambios pueden ser superficiales, lo que significa que no se modifican ni modifican las operaciones CRUD, pero solo cambia la interfaz de usuario.
Entonces, con este tipo de proceso de desarrollo, Agile extremo, ¿las revisiones de código no serían una pérdida de tiempo? Lo que significa que si otro desarrollador o dos revisaron mi código, pero luego ese código cambia 3 veces más antes de que salga por la puerta, debido a todas las mejoras de UI / UX, ¿no estamos perdiendo el tiempo las primeras 3 veces que lo revisaron? código como ese código / componente / UI fue desechado?
Nunca tuvimos muchos problemas de calidad con este proceso y sí, si un desarrollador dejó todo el conocimiento salió, pero siempre encontramos desarrolladores inteligentes que lo recogen y lo toman.
Y sí, tenemos muchos evaluadores porque es posible que tengan que volver a realizar las pruebas 3 o 4 veces. También, por favor, no se preocupe por preguntar por qué todos los cambios de UI / UX ... así es como se hacen las cosas ... por eso la aplicación gana toneladas de premios por UI / UX y los usuarios matarán por el la aplicación El proceso de pensamiento es si puedo lograr una mejora de hasta un 2% en algo porque tengo una hora extra y luego lo hago. Los usuarios serán más felices, lo que significa más $ o usuarios. Y sí, nuestros usuarios están de acuerdo con el cambio continuo de la aplicación porque así se ha hecho desde el primer día, por lo que no lo ven como algo malo o negativo.
Espero que esta publicación no parezca pomposa, pero simplemente no puedo ver cómo las Revisiones de Código no son un desperdicio. Tal vez el 2% de todo nuestro código en el código revisado tiene errores. Cada versión podríamos encontrar 3 errores a través de la revisión de código. Entonces, ¿terminan siendo 40 horas de revisión de código por desarrollador por lanzamiento (4 x 40 = 160 horas) para encontrar de 3 a 5 errores? Es probable que el 50% de los errores de 3 a 5 hayan sido recogidos por QA. ¿No sería mejor pasar esas 40 horas por desarrollador agregando una nueva función o mejorando las existentes?