Así que comencé a trabajar para un gran grupo, 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 ha enredado 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, en el que he estado y / o he oído hablar.
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 (piense en la perfección de Apple / Steve Jobs). ¿Quizás alguien aquí pueda ayudarme a entender antes de que me despidan?
Aquí está mi proceso de desarrollo y el de mi última puesta en marcha ... muy ágil.
Hacemos el trabajo de las características iniciales para ordenar la tarea de desarrollo / todos. Nos burlaríamos de un par de versiones y las presentaríamos 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 anteriores. Luego dividimos el trabajo y comenzamos. Tenemos hitos y fechas para cumplir, pero seguimos desconectando. No tenemos revisiones de código durante nada de esto. Varias veces durante las semanas de nuestro desarrollo, tenemos sesiones con los interesados nuevamente para ver si aún están de acuerdo en que las características / funciones / UX / UI siguen siendo adecuadas y están en el objetivo.
A medida que nos acercamos al final del ciclo de iteración de 8 semanas, el control de calidad comienza a probar, luego se dirige a los usuarios alfa y finalmente a los usuarios beta. Pero durante la fase alfa y beta, los desarrolladores revisan las nuevas características y las características más antiguas y realizan cambios iterativos diarios u horarios en la interfaz de usuario para mejorar la experiencia de usuario. Por lo tanto, una característica que se estaba desarrollando en esta versión, podría terminar cambiando 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 elegante o más inteligente). A veces, los cambios pueden ser superficiales, lo que significa que no se cambian ni modifican las operaciones CRUD, pero todas las IU solo cambian.
Entonces, con este tipo de proceso de desarrollo, extremadamente ágil, ¿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 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 ya que ese código / componente / UI fue desechado?
Nunca tuvimos muchos problemas de calidad con este proceso y sí, si un desarrollador dejaba todo el conocimiento salía por la puerta, pero siempre encontramos desarrolladores inteligentes para recogerlo y tomar el control.
Y sí, tenemos muchos probadores porque pueden tener que volver a probar cosas 3 o 4 veces. Además, no se obsesione con preguntar por qué cambia toda la UI / UX ... así es como se hacen las cosas ... y por eso la aplicación gana toneladas de premios por UI / UX y los usuarios matarán por aplicación El proceso de pensamiento es si puedo mejorar incluso un 2% en algo porque tengo una hora extra y luego hacerlo. Los usuarios estarán más felices, lo que significa más $ o usuarios. Y sí, nuestros usuarios están de acuerdo con que la aplicación cambie continuamente porque así se ha hecho desde el primer día para que no la vean como mala o negativa.
Espero que esta publicación no sea pomposa, pero 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. En cada versión podemos encontrar 3 errores a través de la revisión de código. ¿Entonces termina 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? Las posibilidades son del 50% de esos 3 a 5 errores habrían sido recogidos por QA de todos modos. ¿No sería mejor pasar esas 40 horas por desarrollador agregando una nueva característica o mejorando las existentes?