Varios desarrolladores y yo fuimos agregados recientemente a un proyecto de cascada. Nos dijeron que el proyecto estaba casi terminado pero que necesitaban algunos codificadores adicionales para ayudar a terminarlo (ese es el primer error). A todos nos asignaron diferentes módulos para trabajar.
Esta fase del proyecto se volvió más ágil en el sentido de que realizábamos compilaciones e implementaciones nocturnas en un entorno de prueba y el equipo de control de calidad probaba e informaba de errores de forma activa. Ocasionalmente, nuestras pruebas de regresión en los nuevos módulos fallaban, cosas que solían funcionar ya no funcionaban. Descubrimos que se estaban realizando cambios de diseño que solo involucraban al desarrollador que trabajaba en el módulo y al arquitecto y PM. El problema era que esto afectaba a los módulos de otros desarrolladores.
Los desarrolladores se frustraron unos con otros y pidieron que se les informara sobre los cambios de diseño, ya que podría tener un impacto en su trabajo.
¿Cuál es la mejor manera de comunicar las decisiones de diseño que se pueden tomar en una conversación en el pasillo o en un correo electrónico entre algunas partes? ¿Debería haber un proceso formal para manejar los cambios de diseño, incluso si son extremadamente menores?
Si necesita moverse rápidamente y realizar cambios que puedan afectar a otros, quizás pueda encontrar una manera de aislar a otros de sus cambios, como con interfaces, fachadas o adaptadores.
Otras opciones incluyen (1) aprender cómo hacer los cambios correspondientes que "los demás" podrían necesitar hacer, y enviarles parches o hacer los cambios por ellos, (2) notificarles antes de confirmar sus cambios y preguntarles a "los demás " para una revisión de emergencia, (3) invitar a un "otro" a trabajar con usted cuando sienta que su trabajo afectará su módulo.
Me imagino que podría encontrar otros enfoques, pero cada uno de estos funcionaría.
Recomendaría construir en un ciclo adicional
antes de continuar con otros cambios de diseño o desarrollo.
Esto podría ser su propio hito (diseño completo) o estar integrado en cada iteración.
Documente sus decisiones de diseño mediante pruebas unitarias y comience a utilizar la integración continua . Ya no necesitará hablar más sobre diseño, lo verá en acción.
Puede que solo sea la forma en que lo has redactado, pero diría que los cambios de diseño no son menores si están rompiendo los módulos de los otros desarrolladores.
Si no desea volverse completamente formal y revisar cada cambio de antemano, entonces sus desarrolladores deben tener suficiente conocimiento del diseño general para evaluar el impacto de cualquier cambio e involucrar a los otros equipos según corresponda. Usted menciona a los arquitectos: deberían estar en una posición ideal para hacer esto, entonces, ¿por qué no está sucediendo eso?
También sugeriría algún tipo de registro de cambios central (su herramienta SCM puede brindarle esto) para que, si aún se producen cambios importantes, tenga más posibilidades de comprender cómo se produjeron.
Finalmente, si hay pocas áreas del sistema que se pueden modificar sin afectar a otras, es posible que tenga un problema de diseño mayor.
No soy un experto en Agile, pero veo esto como un problema de comunicación que se puede aplicar a cualquier metodología. ¿Sería útil que los equipos se reunieran diariamente para una revisión rápida de los cambios antes de comenzar a trabajar? ¿Entonces otra vez al final del turno?
rycornell