¿Cómo hacer frente a diferentes estilos de desarrollo (de arriba hacia abajo frente a abajo) en un equipo?

Digamos que acaba de comenzar a trabajar en un equipo muy pequeño en un proyecto {actualmente relativamente pequeño, aunque con suerte más grande más adelante}. Tenga en cuenta que este es un proyecto real destinado a ser utilizado por otros desarrolladores en el mundo real, no un proyecto académico destinado a ser desechado al final de un semestre.
Sin embargo, el código aún no se ha publicado a otros, por lo que aún no se ha tomado una decisión.

Las metodologías

A uno de ustedes le gusta comenzar a codificar y hacer que las piezas encajen entre sí antes de que necesariamente tenga una idea clara de cómo interactuarán exactamente todos los componentes (diseño ascendente). A otro de ustedes le gusta hacer todo el diseño primero y precisar los detalles de todos los componentes y la comunicación antes de codificar una solución.

Suponga que está trabajando en un nuevo sistema en lugar de imitar los existentes, y por lo tanto no siempre es obvio cómo debería ser el diseño final correcto. Por lo tanto, en su equipo, diferentes miembros del equipo a veces tienen ideas diferentes de qué requisitos son incluso necesarios para el producto final, y mucho menos cómo diseñarlo.

Cuando el desarrollador de abajo hacia arriba escribe un código, el desarrollador de arriba hacia abajo lo rechaza debido a posibles problemas futuros previstos en el diseño a pesar del hecho de que el código puede resolver el problema en cuestión, creyendo que es más importante corregir el diseño antes de intentar codificar la solución al problema.

Cuando el desarrollador de arriba hacia abajo intenta resolver el diseño completo y los problemas previstos antes de comenzar a escribir el código, el desarrollador de abajo hacia arriba lo rechaza porque el desarrollador de abajo hacia arriba no cree que algunos de los problemas surjan en la práctica , y piensa que el diseño puede necesitar ser cambiado en el futuro cuando los requisitos y restricciones se aclaren.

El problema

El problema que esto ha provocado es que el desarrollador de abajo hacia arriba termina perdiendo el tiempo porque el desarrollador de arriba hacia abajo con frecuencia decide que la solución que ha escrito el desarrollador de abajo hacia arriba debe descartarse debido a una falla de diseño, lo que resulta en la necesidad de volver a -escribe el código.

El desarrollador de arriba hacia abajo termina perdiendo el tiempo porque, en lugar de paralelizar el trabajo, el desarrollador de arriba hacia abajo ahora se sienta con frecuencia para elaborar el diseño correcto con el desarrollador de abajo hacia arriba, serializando los dos hasta el punto en que incluso puede ser más rápido para 1 persona para hacer el trabajo que 2.

Ambos desarrolladores quieren seguir trabajando juntos, pero no parece que la combinación esté realmente ayudando a ninguno de los dos en la práctica.

Los objetivos

Los objetivos comunes son obviamente maximizar la eficacia de la codificación (es decir, minimizar el desperdicio de tiempo) y escribir software útil.

La pregunta

En pocas palabras, ¿cómo resuelve este problema y hace frente a esta situación?

La única solución eficiente que se me ocurre que no pierde el tiempo es dejar que cada desarrollador siga su propio estilo para el diseño. Pero esto es más difícil de lo que parece cuando revisa el código y realmente necesita aprobar los cambios de los demás, y cuando está tratando de diseñar un marco coherente para que otros lo usen.

¿Hay una mejor manera?

Obviamente, ambos están equivocados.

El tipo de abajo hacia arriba está pirateando el código y nunca producirá algo que haga lo que se supone que debe hacer: será una rotación continua a medida que se determinen los requisitos desconocidos.

El tipo de arriba hacia abajo puede pasar el mismo tiempo en visión arquitectónica y no hacer nada productivo.

Sin embargo, un término medio es ideal: si conoce los objetivos hacia los que está trabajando (que obtiene de un trabajo de diseño amplio) y continúa con la codificación (sin ninguna planificación detallada), cosechará las recompensas de un sistema que es ambos organizados y desarrollados eficientemente.

Por cierto, se llama Ágil (no la versión BS de ágil que algunas personas practican donde los procedimientos son más importantes que el software de trabajo), pero es realmente ágil y continúa trabajando hacia un objetivo final comúnmente descrito y comprendido.

Para solucionar el problema aquí, intente un enfoque ágil (Kanban es probablemente el mejor) que obligará al tipo de arriba hacia abajo a hacer un trabajo y obligará al tipo de abajo hacia arriba a planificar lo que está tratando de lograr.

Los dos desarrolladores deben mantener un respeto mutuo entre ellos.

La persona de arriba hacia abajo debe respetar el hecho de que la persona de abajo hacia arriba puede haber encontrado algo que realmente funcione. Como me dijo uno de mis profesores "cuantitativos", "Un modelo de trabajo vale 1000 conjeturas". Si ese es el caso, la persona de arriba hacia abajo debería considerar volver a hacer su "diseño" para acomodar el trabajo de la persona de abajo hacia arriba.

La persona de abajo hacia arriba también debe respetar el "marco" de la persona de arriba hacia abajo y darse cuenta de que puede ser bueno para evitar el esfuerzo perdido, resolver el problema incorrecto, salir del tema, etc. El codificador de abajo hacia arriba debe al menos tener en cuenta qué la persona de arriba hacia abajo está tratando de hacer, y tratar de abordar al menos las preocupaciones de los principales depresores, como se expresa en el marco. Eso sería cierto incluso si la parte superior inferior no estuviera de acuerdo con partes del marco en sí.

Puede minimizar la pérdida de tiempo que dedica cada desarrollador si divide grandes tareas en múltiples tareas más pequeñas y más enfocadas. Haga que trabajen juntos para que ninguno de los dos se adelante demasiado al otro. Los sprints cortos y las entregas pequeñas son muy útiles. Es más fácil arreglar un pequeño error que uno grande.

Puede parecer contrario a su objetivo, pero la programación de pares funciona. Hay cosas que simplemente no captará de inmediato, a veces durante horas o incluso días. Si no se puede trabajar directamente en las tareas juntas, intente revisar el código / standups con más frecuencia durante la semana.

¡Mantenga a todos informados!

Si está viendo a los desarrolladores deshacerse del código porque estaban en su propio mundo, debe atrapar y conciliar los conflictos de la manera más rápida y eficiente posible. Su jefe lo apreciará, y el equipo apreciará no tener que tirar el trabajo de una semana porque no sabía lo que estaba haciendo el otro tipo.

También debería verlos trabajando juntos como una bendición. El hecho de que estén trabajando juntos y reparando sus errores a medida que avanzan es una buena señal. Llegué a la mitad de tu publicación pensando "hombre, estos dos probablemente se odian ..." y para mi sorpresa, dijiste que querían seguir trabajando juntos.

Creo que esta cita es apropiada dado su escenario.

"Si dos personas están de acuerdo en todo, una de ellas es innecesaria". ~ Un viejo

Esto realmente suena como un escenario ideal para mí. Por otra parte, soy ambos desarrolladores al mismo tiempo. Me gusta redactar el "panorama general" en forma de notas que eventualmente se abren paso en un rastreador de problemas. Luego empiezo a pensar en los detalles de implementación de abajo hacia arriba. El panorama general evoluciona a medida que adquiero una mejor comprensión de cómo encajarán las piezas, y las piezas evolucionan a medida que cambian los requisitos y obtengo nuevas ideas.

Quizás sea un buen modelo para múltiples cerebros.

En mi opinión, son perfiles complementarios y pueden terminar funcionando muy bien. Tanto la codificación como el diseño son fases necesarias en la programación y no quieres terminar en un equipo donde nadie quiere hacer X, todo lo que necesitas es un poco de organización (¡mira, yo también puedo tener una palabra en negrita!)

Esto se puede hacer a través de la supervisión, como lo señalaron otros, pero aún mejor si se acuerda mutuamente un cronograma de iteración de cuándo diseñar y cuándo codificar, y evitando en general codificar lo que se está diseñando actualmente.

Bonificación: tan pronto como un proyecto se despliega en módulos más pequeños, el programador de arriba hacia abajo puede diseñar cosas en las que el programador de abajo hacia arriba no está trabajando actualmente, convirtiéndolo en una fase en la que ambos hacen lo que quieren. Sin embargo, esto implica la capacidad de ambos para hacer los ajustes necesarios cuando llegue el momento de armar todo.

Una nota: dijiste

Suponga que está trabajando en un nuevo sistema en lugar de imitar los existentes, y por lo tanto no siempre es obvio cómo debería ser el diseño final correcto.

Esto es parte del problema: a menos que esté trabajando en un pequeño proyecto para un problema ya resuelto, en realidad no hay un diseño final correcto . Hay muchos diseños posibles. Tenga en cuenta que a menos que esté haciendo esto para aumentar el ego debido a la belleza de su código, el objetivo final es una aplicación que funcione. Eso es. Cómo llegar allí es irrelevante, y la mejor manera de dejar que estos dos vayan rápido es lograr que trabajen juntos, de manera complementaria.

Como han dicho otros, ambos puntos de vista pueden ser correctos de ciertas maneras. Está lejos de ser inusual que dos desarrolladores no estén de acuerdo con las prácticas, especialmente para algo tan subjetivo como los procesos de diseño y desarrollo. Aquí hay dos personas a las que les apasiona lo que hacen y que saben cómo hacerlo: ¡acepta eso!

Aquí hay un gran potencial para permitir que ambas personas trabajen a su manera, y aun así combinar las piezas para obtener una aplicación que funcione.

1. Me gustaría que los dos se sentaran y discutieran, animándolos a verlo desde el punto de vista del otro.

2. Después de esa discusión, puede comenzar a hablar sobre la planificación: esto debe hacerse en equipo, con el entendimiento de que ninguno de los dos debe "ceder" al otro, pero será necesario llegar a compromisos. Hay muchas formas de planificar la arquitectura para una base de código que permite ampliarla con bastante facilidad más adelante, sin introducir una tonelada de código adicional.

3. Una vez que puedas lograr que lleguen a algún tipo de tregua, ¡déjalos enloquecer! Deje que el "tipo de arriba hacia abajo" conduzca la planificación de la arquitectura de alto nivel, las interfaces, las jerarquías, etc. Deje que el "tipo de abajo hacia arriba" salte y comience a escribir código una vez que haya planeado un par de módulos. Haga que acepten formalmente aceptar los métodos del otro como buenos para el proyecto general: planificar para permitir cambios futuros fáciles es bueno, pero no tiene que codificarse de esa manera de inmediato. Cree interfaces y elimine los métodos para obtener la estructura del código, y acepte que una buena parte del código para el futuro no se escribirá hasta que sea necesario.

4. Haga que revisen tanto el diseño como el código con frecuencia, juntos. Itere a través de ciclos donde se sumerge profundamente en algunos segmentos de la arquitectura, planifique con más detalle y escriba esas partes.

5. Este es probablemente el punto más importante: Facilite puntos en el ciclo en los que solo hablen del proceso, en lugar del trabajo que se está realizando. Reflexione sobre la dinámica que se está construyendo: hay cuatro preguntas que debe hacer. ¿Qué salió bien que deberíamos seguir haciendo? ¿Qué salió mal que deberíamos dejar de hacer? ¿Qué nos estamos perdiendo? ¿Qué podemos hacer sobre lo que nos falta?

Esto requerirá algo de trabajo: debe lograr que acepten trabajar juntos a su manera. Para algunas personas no es fácil admitir que no hay una sola forma correcta de hacer las cosas. Lo importante no es en qué forma trabaja, o cómo se ve el código al final; Lo importante es que estas dos personas capacitadas y conocedoras aprendan a trabajar mejor juntas. No es algo que les puedas decir; todo lo que puede hacer es guiarlos a través de un proceso de aprender cómo hacerlo ellos mismos. Al igual que no hay un diseño correcto, no hay una forma correcta para que las personas trabajen.

En general, en mi experiencia a lo largo de mi carrera, el diseño inicial es insuficiente . Y el diseño que ocurre por adelantado es de baja calidad . Esto es malo. Principalmente porque el resultado es (en mayor o menor grado) arrojar barro a la pared y ver qué se pega. La deuda técnica se acumula desde el primer momento.

De arriba hacia abajo es generalmente superior al de abajo hacia arriba. Aunque no descartaría completamente de abajo hacia arriba. La razón de esto es que de arriba hacia abajo te obliga a pensar en el problema de manera más amplia y a hacer mejores preguntas . Esto refuerza el primer punto anterior ... conduce a un diseño de mayor calidad y generalmente influye mucho en el trabajo de nivel inferior. Esto reduce un considerable retrabajo que a menudo es necesario si los componentes de nivel inferior se construyen primero.

Existe un riesgo no insignificante de que si los componentes de abajo hacia arriba se construyen primero, la presión de desarrollo intenta adaptar los requisitos comerciales a los componentes que han sido diseñados. Esto también es malo. Los requisitos comerciales deben impulsar el diseño, que debe impulsar la implementación. Cualquier cosa que vaya a la inversa llevará a resultados inferiores.

Ningún enfoque es suficiente. Parece que cada uno de ellos es lo suficientemente inteligente o experimentado como para darse cuenta de las deficiencias del otro enfoque (¿tal vez se quemaron?), Pero no pueden ver las deficiencias de su propio enfoque seleccionado ...

La verdad es que es necesario un enfoque mixto:

• es casi imposible encontrar el diseño "correcto" por adelantado; es necesario un cierto grado de experimentación para identificar los puntos de dolor, los cuellos de botella, ... (pista: nunca están donde crees que estarán)
• es casi imposible ir a cualquier parte simplemente "yendo", es más probable que termines en un lugar que no quieras o simplemente corras en círculos que cualquier otra cosa

Mezclando ambos, sin embargo, puedes:

• tener un bosquejo aproximado que dé instrucciones y un esqueleto de infraestructura
• y desarrollando componentes que se ajusten a esta visión

Debido a que no existe un sistema existente que cumpla este propósito, es importante darse cuenta por adelantado de que:

• será necesaria la experimentación / creación de prototipos
• iteración, por lo tanto, será necesaria

Por lo tanto, se debe hacer hincapié en llegar a un sistema "operativo" lo antes posible, incluso si esto significa ignorar los casos en las esquinas, etc. Este es el concepto de "corte vertical delgado": en lugar de construir los cimientos de la casa , luego las paredes, luego la estructura del techo, ... y solo obteniendo algo utilizable al final (o nunca obteniéndolo, o realmente no siendo utilizable) ... es mejor construir primero una habitación completamente equipada , como el baño Se puede usar de inmediato y se puede utilizar para recopilar comentarios.

Sin embargo, para que los comentarios sean valiosos, es mejor abordar primero una parte central.

Entonces, ¿qué haces con tus compañeros de trabajo?

Lo primero es que ambos deben comprender la necesidad de colaboración y la necesidad de ponerse de acuerdo sobre el camino a seguir: ser constantemente reprendidos, como lo son, seguramente pondrá los nervios de punta y afectará la motivación. He presentado anteriormente lo que he encontrado que funciona bien en la práctica en múltiples proyectos, puede usarlo como sugerencia.

Luego, deben ponerse de acuerdo sobre quién hace qué. Tenga en cuenta que en el enfoque de término medio subrayado anteriormente, ambos deberían realizar tareas que aprecian.

Tenga en cuenta que tanto la construcción de los esqueletos como la construcción de los ladrillos se aborda mejor de manera incremental.

1. Ambos deben obtener un bosquejo del esqueleto y luego decidir juntos en qué "corte delgado" enfocarse primero
2. El chico de abajo hacia arriba debería comenzar a trabajar en la pieza mejor entendida de "corte fino"
3. El tipo de arriba hacia abajo debería comenzar a desarrollar el esqueleto, idealmente abordando primero la mayoría de las piezas de bloqueo para completar el corte

Enjuague y repita hasta que la rebanada funcione; acumular comentarios en el camino para ajustar según sea necesario.

Cuidado: este es un prototipo, ambos deben estar listos para tirarlo y comenzar desde cero en un diseño completamente diferente.

Lo que necesita es un líder (o supervisor) que comprenda el desarrollo de software y que tome la decisión sobre qué enfoque debe usarse en el proyecto. Si es necesario, el líder dirige a los desarrolladores a trabajar de una manera particular, independientemente de sus preferencias personales.

La única solución eficiente que se me ocurre que no pierde el tiempo es dejar que cada desarrollador siga su propio estilo para el diseño.

En realidad, podría ser muy ineficiente ... porque lo más probable es que haya muchos conflictos y reprocesos. Peor aún, puede terminar con un fracaso total del proyecto.