Estoy seguro de que ya has visto mis comentarios y mi otra publicación, así que no voy a fingir que realmente sé la respuesta. Lo mejor que puedo ofrecer es un resumen de lo que he escuchado / leído de otros y agregar algo de mi propia experiencia a la mezcla.
Primero, quiero decir que hace poco encontré un blog que pertenece a uno de nuestros propios miembros de Programmers SE, Martin Blore e IMO. Esta publicación específica sobre la autorrealización de TDD es muy precisa. TDD es el último nivel más alto que une todo, pero sin los niveles anteriores, especialmente el más grande, los principios y las prácticas para producir código claro y legible, será muy difícil, si no imposible, hacer que TDD funcione.
En mi empresa, la administración nos impuso tanto Agile como TDD, y al principio simplemente los hicimos porque nos dijeron (que es lo contrario de ágil). Hemos probado TDD dos veces y, aunque soy un gran defensor del uso de pruebas automatizadas, personalmente he descartado todas las que el equipo unió en la última versión. Eran frágiles, gigantescos, copiaban / pegaban el wazoo y estaban plagados de declaraciones de sueño que los hacían correr de manera muy lenta e impredecible. Mi consejo para su equipo: NO HAGA TDD ... todavía.
No sé cuál es su situación porque mencionó que ha estado en la empresa durante solo 6 meses y que es un contratista. ¿Sus objetivos a largo plazo son quedarse con esta empresa o se va a acabar el contrato? Le pregunto porque, incluso si hace algo, podría llevar bastante tiempo ver los resultados.
Además, cuando te unes a un equipo, generalmente toma tiempo antes de obtener suficiente credibilidad y respeto de tu equipo, donde ellos (desarrolladores y administración) considerarían cualquier cosa que propongas. En mi experiencia, ayuda si apaga algunos incendios y demuestra que tiene habilidades y conocimientos de los que otros pueden depender. No estoy seguro si 6 meses es suficiente. Con mucha frecuencia, una persona nueva y ambiciosa se uniría al equipo, luego publicaría aquí preguntando cómo pueden cambiar el mundo. La triste realidad es que simplemente no pueden.
Asumiendo que tienes el respeto y la atención de tu equipo. ¿Ahora que?
Primero, tanto la administración como los desarrolladores deben ser conscientes de que hay un problema. La gestión mide los resultados en términos de trabajo entregado. Si están contentos con la cantidad actual y la calidad de las características, entonces la triste realidad es que no escucharán. Como otros han señalado, sin el apoyo de la gerencia, será extremadamente difícil introducir cualquier tipo de cambio.
Una vez que obtenga soporte de administración, el siguiente paso es profundizar e identificar las causas fundamentales de por qué el equipo opera de la manera que lo hace. El siguiente tema es algo que ha sido una búsqueda personal mía desde hace un tiempo. Hasta ahora este ha sido mi viaje:
- Una vez que tenga el apoyo de la gerencia. Puede comenzar a introducir muchas prácticas / procesos dictados centralmente que MainMa sugirió en respuesta a mi pregunta . Hemos hecho muchos de ellos (excepto la programación emparejada) y definitivamente ve beneficios. Las revisiones de código ayudaron especialmente a estandarizar el estilo, la documentación y también nos permitieron compartir conocimientos / técnicas entre el equipo. A pesar de que se dictaron las revisiones de código, al equipo realmente le gustan y revisamos cada pieza de funcionalidad que se registra. Sin embargo ...
- Notará que el código que generalmente se escribe todavía está demasiado acoplado, el diseño es malo o carece por completo. Las revisiones de código captan algo de esto, pero hay muchas cosas que puedes reescribir. ¿Por qué el diseño es malo en primer lugar? - A muchos desarrolladores nunca se les presentaron buenas prácticas y nunca se les enseñó formalmente OOD en primer lugar. Mucha gente "simplemente codificó" cualquier tarea que se les asignó.
- Con el apoyo de la gerencia, puede introducir más procesos, como discutir el diseño antes de que se realice la codificación. Pero solo eres una persona y parece que tan pronto como no prestas atención, el equipo vuelve a lo que siempre ha hecho. ¿Por qué?
- ¿Se pueden introducir y enseñar mejores prácticas o hábitos para que no tenga que monitorear constantemente? - Resulta que esta parte no es tan fácil.
- ¿Por qué otros miembros del equipo son reacios a aprender y aprender nuevas prácticas y por qué son tan resistentes a SÓLIDO o SECO cuando se ha escrito tanto en la literatura moderna sobre metodología de software? Con todos los cambios positivos que hemos tenido en mi equipo, hace 2 semanas tuve una discusión en la que refacturé 2 funciones que tenían 15 líneas de código idénticas y el revisor lo llamó heroico, esfuerzo innecesario porque no hay nada de malo en copiar / pegar solo 15 líneas Estoy totalmente en desacuerdo con tales puntos de vista, pero por ahora hemos decidido aceptar estar en desacuerdo. -- ¿Y ahora que? Ahora hemos llegado al tema de mi otra publicación .
- Como maple_shaft y nikie señalaron en sus respuestas (lo siento, MainMa , obtuviste la mayor cantidad de votos, pero estás a 5 pasos de distancia :)), has llegado a una etapa en la que el "proceso" ya no puede ayudarte a ti ni a nadie en este foro puede decirle cuál es la "solución". El siguiente paso es acercarse a las personas, tal vez uno a uno, tal vez como un equipo, probablemente ambos en un momento u otro y hablar con ellos. Pregúnteles qué funciona y qué no. La única forma de identificar la causa raíz de lo que los impulsa ahora es hablar con ellos individualmente y descubrirlo. Como parte de este paso, recientemente me encontré con un problema de equipo completamente diferente, pero creo que la respuesta de Joel aquí, que es muy detallado y perspicaz, también se aplicaría a este caso. En resumen, si bien el uso de la administración como "correa corta" es un posible enfoque para casi cualquier cosa, debemos recordar que estamos tratando con humanos para entender realmente las motivaciones que tenemos que cruzar más en el psicoanálisis que la administración pura o el liderazgo técnico.
- Entonces, ¿estás hablando con tus compañeros de equipo? Que les preguntas No estoy seguro de esta próxima parte porque nunca he estado aquí. Aquí hay un posible escenario: P: ¿Cómo es que no hay SÓLIDO? A: no lo necesito. P: Podría ayudar. A: Lo hago bien como está. - de alguna manera, necesita generar una serie de sonidos que salgan de su boca y hagan que el oyente reconozca que las cosas podrían mejorar si le dan una oportunidad a lo que usted está vendiendo. Si fallas aquí, nunca se convencerán de que lo que sea que "haga el proceso" realmente tiene algún valor. Por otro lado, si supera este punto, probablemente encontrará que ya ni siquiera necesita "el proceso".
- OMI desde la raíz, tus compañeros de equipo no aprenderán si no ven nada malo en sus hábitos / prácticas actuales. Entonces, quizás el siguiente paso en todo esto es encontrar una manera de ilustrar, resaltar los problemas y hacerlos obvios. Después de todo, no estamos escribiendo código legible, utilizando principios SOLID / DRY o manteniendo documentación solo porque nos da una sensación cálida y difusa. Lo hacemos porque produce un código de mejor calidad y, francamente, nos hace codificar más rápido. ¿Se puede medir eso? ¿Quizás aquí es donde entran las métricas de software?
- Aquí hay una idea loca y no tengo idea de si realmente funcionaría (podría ser una práctica estándar de la industria, o tal vez sea completamente inválida. Lo inventé en las últimas 24 horas), pero estoy muy tentado de traerla. a la mesa tan pronto como comience el próximo año:
- Contra las opiniones de muchos otros , presente la idea de Autor / Propietario para todos los archivos fuente. Como sugiere The Pragmatic Programmer, esto le dará un sentido de propiedad y responsabilidad a una sola persona que será responsable de un código fuente. No significa que otras personas no puedan modificar el código, todos estamos trabajando en equipo, pero al final del día, la persona que posee el código es responsable de revisar los cambios.
- Cree un activador de repositorio de origen que supervise todos los registros y busque específicamente aquellos que son correcciones de errores. Conviértalo en un proceso para que cada corrección de errores tenga un identificador de referencia directamente en la descripción del check-in. Ahora escriba un script que analice una lista de archivos que fueron modificados y elimine el "Autor" del bloque de comentarios del encabezado del archivo. Cree una base de datos SQL que rastree el número de defectos registrados por archivo / por proyecto / por autor.
- Una vez que tenga suficientes estadísticas, con suerte notará que su código tiene menos defectos / cambios que algunos de los otros códigos. Estos son datos duros que puedes usar. Si un solo proyecto tiene una tasa de defectos significativamente superior al promedio, créelo como candidato para el próximo esfuerzo de limpieza / refactorización para pagar parte de la deuda técnica.
- Si un proyecto o archivo tiene una tasa de defectos significativamente superior al promedio y tiene un propietario, hable uno a uno con esa persona. Pregúnteles, muy cortésmente, sin confrontaciones, qué pueden hacer para abordar esto. Dado que son los propietarios, deben impulsar el cambio, pero ofrecer cualquier ayuda de su parte. Con suerte, el propietario rastreará muchas de las causas de su propio código de espagueti y tan pronto como pidan ayuda, es cuando entra en acción y coloca algo de SÓLIDO.