Un equipo de programación es un equipo de personas que desarrollan o mantienen software informático . [1] Pueden organizarse de muchas maneras, pero el equipo de programación sin ego y el equipo de programador jefe han sido estructuras comunes. [2]
Un equipo de programación está formado por personas que desarrollan o mantienen el software informático . [3]
Los equipos de programación pueden organizarse de muchas maneras, pero el equipo de programación sin ego y el equipo de programador jefe son dos estructuras comunes que se utilizan habitualmente. [2] Los principales determinantes a la hora de elegir la estructura del equipo de programación suelen incluir: dificultad, tamaño, duración, modularidad, fiabilidad, tiempo y sociabilidad. [2]
Según Marilyn Mantei, las personas que forman parte de un equipo de programación descentralizado manifiestan una mayor satisfacción laboral. [2] Pero un equipo de programación sin ego contiene grupos de diez o menos programadores. Se intercambia código y se fijan objetivos entre los miembros del grupo. El liderazgo se rota dentro del grupo según las necesidades y las habilidades requeridas durante un tiempo específico. La falta de estructura en el equipo sin ego puede dar lugar a una debilidad en la eficiencia, la eficacia y la detección de errores en proyectos de gran escala. Los equipos de programación sin ego funcionan mejor para tareas que son muy complejas.
Un equipo de programadores jefes suele estar formado por equipos de tres personas: un programador jefe, un programador de alto nivel y un bibliotecario de programas. Cuando es necesario, se suman al equipo más programadores y analistas. Las debilidades de esta estructura incluyen la falta de comunicación entre los miembros del equipo, la cooperación en las tareas y la finalización de tareas complejas. El equipo de programadores jefes funciona mejor para tareas más sencillas y directas, ya que el flujo de información en el equipo es limitado. Las personas que trabajan en esta estructura de equipo suelen tener una moral laboral más baja. [2]
Una técnica de desarrollo en la que dos programadores trabajan juntos en una estación de trabajo.
Un enfoque de desarrollo de software en el que todo el equipo trabaja en lo mismo, al mismo tiempo, en el mismo espacio y en la misma computadora. [4]
Los modelos de programación permiten a los equipos de desarrollo de software desarrollar, implementar y probar proyectos utilizando estas diferentes metodologías.
En ambos modelos de programación, los miembros del equipo suelen participar en reuniones diarias de entre 5 y 15 minutos de duración. Tradicionalmente, cada miembro del equipo se pone de pie y dice en qué ha trabajado desde la reunión anterior, en qué piensa trabajar hasta la próxima y si hay algo que le impida avanzar, lo que suele denominarse "bloqueador". [5]
El modelo en cascada, considerado el enfoque más tradicional [6] , es un modelo lineal de producción. La secuencia de eventos de esta metodología es la siguiente:
Cada etapa es distinta durante el proceso de desarrollo de software, y cada etapa generalmente finaliza antes de que pueda comenzar la siguiente.
Los equipos de programación que utilizan este modelo pueden diseñar el proyecto en las primeras etapas del proceso de desarrollo, lo que les permite centrarse en la codificación y las pruebas durante la mayor parte del trabajo en lugar de repetir constantemente el diseño. Esto también permite a los equipos diseñar de forma completa y más cuidadosa para que puedan tener una comprensión completa de todos los entregables del software .
El modelo de desarrollo ágil es un enfoque de desarrollo más basado en equipos [6] que el modelo en cascada anterior. Los equipos trabajan en un proceso de entrega/implementación rápida que divide el trabajo en fases llamadas "sprints". Los sprints suelen definirse como dos semanas de entregas de software planificadas que se entregan a cada equipo o miembro del equipo.
Después de cada sprint, se vuelve a priorizar el trabajo y la información obtenida en el sprint anterior se utiliza para la planificación de sprints futuros. Una vez finalizado el trabajo del sprint, el equipo de programación puede revisarlo y evaluarlo y enviarlo de vuelta para otra iteración (es decir, el próximo sprint) o cerrarlo si se ha completado.
Los principios generales [7] del Manifiesto Ágil [8] son los siguientes:
{{citation}}: CS1 maint: varios nombres: lista de autores ( enlace ){{citation}}: CS1 maint: varios nombres: lista de autores ( enlace ){{citation}}: CS1 maint: varios nombres: lista de autores ( enlace )