agile - son - php full stack
La programación de pares implica un costo doble por desarrollador. ¿Vale la pena ese dinero? (21)
¡De ninguna manera! ¡En la empresa en la que trabajo, practico mucho par de programación! ¡hace que las cosas se hagan realmente rápido y realmente eficientemente! solo haz una prueba! lo valorarás más tarde!
La programación de pares en Agile requiere que dupliquemos el salario pagado al programador individual. Por supuesto, con este enfoque la calidad del código es mucho mejor, los errores se encuentran mucho antes, etc., pero ¿vale la pena ese dinero? Tal vez deberíamos pagar el salario del segundo desarrollador a los pocos probadores (estos últimos suelen ser mucho más baratos que el programador calificado). ¿Alguien tiene alguna experiencia con tal comparación?
¿Cómo sabes que tus programadores no emparejados son más eficientes? A veces pienso que el single / pair es comparable al antiguo cuento de hadas del conejo y la tortuga.
El emparejamiento no deriva en días de trabajo contraproducente. No tengo idea de la frecuencia con la que he visto a los desarrolladores pasar semanas trabajando en cosas que luego resultan reemplazadas por algo mucho más simple. El programador individual "en la zona" a menudo hace cosas estúpidas. Es demasiado fácil producir demasiados códigos, cuando lo que quieres es más golpe con menos código.
Y en la posteridad, cuando se asienta el polvo, encontrará cientos, sino miles de líneas de código que podrían no haber sido escritas porque alguien no sabía acerca de la biblioteca X o la técnica Y. El emparejamiento mejora este problema, pero no lo elimina. Alienta a los individuos y a la pareja a investigar más antes de sumergirse en la euforia del código sin sentido.
Ojalá pudiera emparejar más ...
Aunque estoy de acuerdo con la mayor parte de la respuesta hasta ahora acerca de que la programación de pares es algo bueno, haré de abogado del diablo y argumentaré que no siempre tiene sentido.
Cuando te emparejas no obtienes un programador que tiene el doble de cerebro. Obtienes un programador que es la unión de tus dos cerebros. Así que, básicamente, cada vez que lo arruino y mi compañero lo atrapa o encuentra de alguna manera mejor, es una ventaja. Sin embargo, cada vez que escribo el código correcto es una pérdida de dinero ya que mi pareja no era necesaria.
Básicamente, debes evaluar el código en el que estás trabajando. Las tareas simples generalmente no valen la pena el dinero para pagarle a alguien que se siente por encima del hombro y asegúrese de haber escrito correctamente su bucle for. Sin embargo, en algún umbral, las tareas son lo suficientemente complicadas como para justificar la programación de par para la programación de pares.
Con la programación de pares, combinas:
- Código de mayor calidad
- Mejor distribución del conocimiento interno
- Más espíritu de equipo
No obtendrá ese retorno de la inversión mucho más fácil que eso.
Por otra parte, no debes usarlo para todas las tareas.
Cuando estoy programando en el barco de mi amigo no siempre tenemos tiempo porque uno de nosotros navega mientras el otro codifica. Sin embargo, cuando estamos anclados o en aguas tranquilas podemos hacer la programación de pares y funciona bien.
Cuanto antes se encuentre un error / defecto, más barato será arreglarlo, por lo que usar el dinero para contratar a más gente qa frente a otros desarrolladores le costará más tiempo / dinero debido a la cantidad de viajes de DEV a QA.
Habiendo dicho esto, la programación de pares no funciona con todos, algunos desarrolladores no se emparejan bien, se distraen, pasan todo el tiempo peleando, etc.
Si tiene desarrolladores que pueden emparejar programas, puede ser más beneficioso a largo plazo cuando agrega un código más fácil de mantener, menos defectos, menos tiempo en garantía de calidad y, lo que es más importante, si uno de los desarrolladores es golpeado por un autobús, usted no tiene que esperar a que alguien se apresure en un proyecto antes de poder trabajar más en él.
Si sus desarrolladores no pueden emparejar el programa, no los obligue a ello, todo lo que hará será perder tiempo y dinero.
Depende de los desarrolladores. Desafortunadamente, no se puede unir a dos desarrolladores y esperar resultados oportunos y de alta calidad. No todos están desconectados para la programación combinada o incluso desconectados para trabajar en un entorno de desarrollo ágil. Dos cosas sobre la programación de pares que creo que lo hacen valer son: (1) Entrenamiento cruzado entre desarrolladores; y (2) evaluaciones por pares en tiempo real. El entrenamiento cruzado ayudará a fortalecer las habilidades del equipo como un todo, y las evaluaciones por pares en tiempo real pueden eliminar la necesidad de revisiones paritarias formales. He aprendido más de mis compañeros a lo largo de los años de lo que aprendí en una capacitación técnica.
En el trabajo usamos programación de pares todo el tiempo. El truco es saber qué tareas se deben hacer en pareja y cuál sería una "pérdida de tiempo" si lo hacen dos desarrolladores. La regla del pulgar es que las tareas que están más orientadas a la investigación (es decir, POC y picos) deben hacerse en pares, así como el desarrollo de nuevas características (para que el conocimiento exista en más de una mente). Las tareas que son más mundanas, como la instalación del servidor de CI o el reemplazo de los íconos de complementos, las realiza un único desarrollador. Otro factor es la disponibilidad actual de los miembros del equipo y las tareas actuales que se realizarán en esa iteración.
Es difícil de decir: he pasado mucho tiempo trabajando en un entorno de pares de fuerzas y también en un entorno opcional de emparejamiento. El código de mayor calidad que he visto no está en el entorno emparejado. Eso probablemente tiene más que ver con el calibre y la disciplina de los desarrolladores individuales. Algunas veces obtendrá el valor de su dinero por el emparejamiento, especialmente cuando algunos de los codificadores no son de primer nivel. Pero si todos los codificadores son codificadores experimentados y bien disciplinados, solo están desperdiciando su dinero si se están emparejando todo el tiempo.
Un tipo de experiencia que he tenido varias veces y que tiene un gran impacto en mi disciplina de codificación y en la calidad del producto que produzco es la siguiente: llevar un buscapersonas. Cuando tengo que admitir un sistema para el que codigo, cambia la forma en que codigo. Es decir, código de tal forma que evita que se active el busca. El resultado es un producto de mejor calidad y, por lo general, una mejor calidad de código. Los codificadores que he visto que nunca han llevado un localizador producen código que es más frágil. No es algo que puedan entender y mejorar hasta que hayan recibido apoyo.
La experiencia de gestión de calidad de otras muchas industrias nos enseña que la prevención de defectos es más barata a largo plazo que la detección de defectos (también conocida como QA) y la posterior fijación.
También aprendieron que el largo plazo varía en la mayoría de los casos de 1 a 2 años, lo que significa que su inversión vale la pena después de eso. Teniendo en cuenta que normalmente se espera que las inversiones en esa escala lleguen a un punto de equilibrio incluso después de 4 años, ¡esto es bastante bueno!
El problema es que las otras industrias tardaron varias décadas en acumular datos suficientes para poder demostrar que este es el caso para ellos. Puede encontrar fácilmente datos para respaldar su conclusión y sacar una conclusión para el software en analogía con eso, pero a partir de hoy, no hay pruebas para el negocio del software.
Dicho esto, creo que la conclusión análoga es válida: un par de desarrolladores y un probador son más productivos que un desarrollador y dos evaluadores.
Si tiene problemas para justificar la gestión de dos costosos desarrolladores que se encuentran frente a una computadora, hay muchas otras cosas que ayudan con la prevención de defectos, pero que no son tan visibles (y por lo tanto irritantes) para la gerencia.
La premisa es que su productividad más que duplica. Parte de la ganancia se realiza de inmediato (p. Ej., Antes de que se registre el código) y la parte se realiza más adelante, cuando hay menos errores y fallas.
Cuando enseño a estudiantes con la experiencia de dos semestres, para la mayoría de los pares su productividad se duplica porque se hacen preguntas y aprenden y terminan más rápido. Pero no es universalmente cierto; un par mal combinado puede tomar más tiempo y hacerlo peor que la mitad más habilidosa.
La primera suposición que uno hace con la programación de pares es que una tarjeta de historia costará el doble de desarrollo. La suposición es defectuosa. Aquí está el porque?
- Calidad mejorada : un par de programadores activos que trabajan en la misma tarjeta completarán la tarjeta con menos defectos
- Productividad mejorada : es menos probable que un par disminuya su velocidad si no se bloquea completamente cuando se resuelve un problema. Además, es más difícil tomar un correo electrónico o unas vacaciones en la web cuando trabajas con un compañero ... no quieres decepcionar al socio. Resolverás el problema con un diseño más limpio y menos líneas de código cuando trabajes como un par
- Elimine los silos del conocimiento : con los pares rotativos, aprenderá el conocimiento del negocio de aplicaciones y dominios en todo el equipo. Es menos probable que el equipo esté bloqueado porque Sue está de vacaciones y nadie más conoce su código.
- Transferencia de conocimientos: los pares rotativos enseñan nuevas habilidades (ingeniería y dominio) entre sí mientras trabajan juntas. El nivel del equipo aumentará para todos y el conocimiento se propaga a través del equipo.
- El equipo selecciona por sí mismo: el equipo aprende las habilidades de una antera y eliminará rápidamente a alguien que no esté actuando.
De la experiencia real, hemos visto que los defectos disminuyen significativamente. Se pueden agregar nuevos miembros del equipo sin ralentizar el equipo (prueba eso con un equipo no emparejado). Para una prueba, un equipo calculó el trabajo para un juego de fichas como si seis desarrolladores individuales completaran el código individualmente. Luego se les dijo al desarrollador seis que se emparejara. Completaron el trabajo a tiempo con alta calidad. Si no se empareja, está gastando mucho tiempo para entregar a poca calidad, no tiene forma de escalar y tiene demasiados silos de experiencia.
En un segundo ejemplo, calculamos que para completar el trabajo en el tiempo requerido, necesitaríamos llevar un equipo de 4 pares a 7 pares. Nos dimos 1 mes a bordo de los nuevos pares. Emparejamos un nuevo desarrollador con un desarrollador experimentado y rotamos los pares en las tarjetas de historias. El equipo acertó todos los entregables con calidad en el tiempo planeado. ¡Sin emparejar uno no podría haber agregado 6 desarrolladores a un equipo de 8 desarrolladores y dar en el clavo!
En pocas palabras, ahorrará dinero con el emparejamiento. Tendrá más o menos el mismo tiempo, entrega con mayor calidad, mejorará el rendimiento, las habilidades y el conocimiento del equipo y eliminará la madera muerta. Sus ahorros vendrán con un ritmo sostenible y significativamente menos defectos en la forma de desacelerar al equipo.
La profesora Laurie Williams de NC State es la autoridad principal en el mundo académico sobre la efectividad de la programación de pares, ella hizo un montón de estudios sobre esto.
Si quieres la "palabra oficial", visita su lista de publication .
Su artículo: "Strengthening the Case for Pair-Programming" es extremadamente famoso.
La programación de pares no duplica el costo, solo reduce a la mitad la cantidad de tipeo. Escribir no es programación. Completar la funcionalidad en el software es la programación. Es la resolución de problemas. No se puede simplemente medir en líneas de código escrito. Algunos programadores usarán un mejor algoritmo para que terminen escribiendo menos.
¿Cómo definirías la relación calidad-precio? ¿Posible tiempo total transcurrido entre el inicio de la codificación y la función de trabajo completada en vivo?
El costo de no aparear no suele contarse correctamente: el problema es que la mayoría de las personas no miden la cantidad de defectos o la cantidad de tiempo adicional necesario para reparar el trabajo que no se completó correctamente en primer lugar; simplemente miden el tiempo necesario para "tirar el trabajo sobre la valla" en primer lugar.
Hay algunos intentos de medir la productividad cuando se corta, pero lamentablemente se relaciona un poco con la "cantidad de líneas entregadas", lo cual es una métrica falsa.
Puede encontrar relevante este estudio: http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
La programación de pares puede ser increíblemente efectiva, sin embargo, no debería contratar programadores de a pares. No puede obligar a los desarrolladores a emparejar el programa. Solo funciona cuando dos desarrolladores hacen clic y deciden que pueden aprender unos de otros y construir algo increíble juntos. Mi consejo es contratar a la mayor cantidad de desarrolladores más inteligentes que pueda encontrar y ponerlos en un entorno que, naturalmente, se presta para fomentar la programación de par a tiempo parcial. Los desarrolladores necesitan poder codificar solo, pero también hablar con otros miembros del equipo al respecto.
Encontrar la combinación correcta que funcione para usted y su empresa será más arte que ciencia, y ciertamente no es algo que pueda hacer siguiendo ciegamente las demandas de alguna metodología publicada.
Dicho esto, mientras más errores se acumulen antes de que se controlen, más se ahorrará en el largo plazo. Tener a otro desarrollador mirando mientras diseña algo siempre será más efectivo que tener un probador que lo bloquee después. Yo lo llamaría dinero bien gastado.
No es una cosa en blanco y negro o una bala de plata de ningún tipo, el concepto de programación de pares.
La programación de pares generalmente es extremadamente eficiente por varias razones, pero si se hace bien, también es muy agotador (en mi opinión, de cualquier forma), lo que significa que un buen par podría vincular el programa unas horas al día como máximo. Esto debería ser alentado, por supuesto, pero no obligatorio y especialmente no obligatorio al 100% de tiempo porque parece difícil de manejar (con eficiencia sostenida y sin cerveza de todos modos).
Entonces, la programación de pares es solo una forma de abordar un problema, y me resulta difícil verlo desde la perspectiva de la pregunta. No es necesario contratar el doble de desarrolladores para esto. Es como preguntarse si vale la pena contratar un mensaje chico / chica para que dos empleados del mismo departamento hablen entre sí ... cuando la solución obvia es hacer que hablen entre sí directamente sin un mensajero adicional.
No he hecho las estadísticas, y sospecho que tendrías dificultades para realizar un estudio estadísticamente válido, pero ten en cuenta el objetivo aparente de producir código funcional, libre de errores , no solo la cantidad de código. Un buen par debería ser capaz de crear al menos tanto código correcto como dos programadores que trabajan por separado.
No significa el doble del costo si lleva menos de la mitad del tiempo que hubiera llevado con un desarrollador. Creo que en tareas difíciles o de bajo nivel esto sería útil. Me parece que vale la pena porque tienes a alguien que dice "no, no hagas eso". mucho antes de que termine en el código de producción donde REALMENTE le costará tiempo y dinero.
He escrito sistemas operativos y cosas de esa naturaleza en las que fue invaluable que alguien estuviera sentado a mi lado para verificar mi lógica.
No, tu no. Cada programador todavía recibe exactamente un salario.
¿Crees que tus programadores no hablarán entre sí si no lo llamas "programación de pares"? ¿Crees que la programación es perfectamente paralelizable?
Usamos este enfoque en nuestra compañía, pero solo para las tareas difíciles o cuando no está seguro sobre algo en lo que alguien más ha trabajado y que creo que funciona muy bien. Le ahorra quedarse atascado en la rutina y ser capaz de rebotar las ideas de las personas cuando sea necesario sin dejar de ser capaz de trabajar de forma independiente para la mayoría de las tareas simples.
También creo que es más beneficioso que una revisión de código, que es algo más que hacemos donde trabajo. A menudo es difícil saber completamente qué sucede cuando se realiza una revisión del código sin proporcionar un contexto significativo, momento en el que no siempre se tiene tiempo para pensar en todo lo que se puede y lo que no. La programación en parejas le brinda ese contexto desde el principio y le permite dedicar más tiempo a pensar en casos límite que pueden o no causar problemas.
A menos que sea una tienda muy pequeña, probablemente ya esté pagando los salarios de dos programadores. La programación en pares es solo una manera de obtener (teóricamente) más software depurado y funcional de esos dos en el mismo período de tiempo.