Aunque no lo creas hay una práctica común en el mundo de la programación que consiste en dos personas trabajando en un sólo computador. A esta práctica se le conoce como pair programming y tiene numerosas ventajas dependiendo de la situación.
Más Disciplina. Emparejando correctamente es más probable que hagan «lo que se debe hacer» en lugar de tomar largos descansos.
Mejor código. Trabajando en parejas es menos probable producir malos diseños ya que su inmersión tiende a diseñar con mayor calidad.
Flujo de trabajo constante. Bajo la metodología de pair programming el flujo de trabajo distinto al trabajar solo. En parejas el flujo de trabajo se recupera más rápidamente: un programador pregunta al otro «¿por dónde quedamos?«. Las parejas son más resistentes a las interrupciones ya que un desarrollador se ocupa de la interrupción mientras el otro continúa trabajando.
Y finalmente hay una virtud muy útil cuando se trabaja de forma maratónica, ya sea porque se acerca un plazo de entrega o se está una competencia y es la resistencia a la fatiga, los programadores estamos acostumbrados a trabajar muchas horas seguidas, pero durante los periodos finales cometemos muchos más errores que cuando estamos descansados, en ese caso pair programming sirve para que uno de los miembros revise los detalles menores (errores que introduciremos) mientras el otro trabaja en el big picture.
¿ Cuando no ocupar la metodología de Pair PRogramming?
Como en todas las estructuras de trabajo no hay balas de plata ni formulas mágicas, en ciertas ocasiones el trabajo de un programador puede ser relativamente mecánico, en ese caso y cuando los errores no son críticos, el pair programming es una práctica que no es muy útil, puesto que hay dos personas haciendo el trabajo de una sola, lo que puede ser visto como un desperdicio de tiempo en la empresa.
Tampoco es aconsejable obligar a dos personas que no se relacionan bien a trabajar en conjunto, el pair programming requiere que dos personas pueden comunicarse bien, una debe liderar el proceso y la otra lo sigue, pero esos roles son dinámicos a lo largo de la jornada y también es común que ambos intercambien de asientos durante el proceso.
- ¿Por qué Twitter fue hecho en Ruby on Rails? - abril 15, 2016
- Construyendo una landing page en Ruby on Rails desde cero. - febrero 11, 2016
- Pair programming (de a dos es mejor) - febrero 11, 2016
- Creando un wordpress en hostinger - abril 18, 2015
- Login con facebook en rails 4.1 y 4.2 - febrero 3, 2015
- EL ASSET PATH DE RAILS - enero 26, 2015
- Entendiendo los objetos en Ruby - enero 21, 2015
- La verdadera educación Tecnologica - enero 14, 2015
- Kit Digital del gobierno de Chile - enero 14, 2015
- ¿Como diseñar un buen Layout para tu página web? - enero 13, 2015
