Trabajar con TDD no es ir lento
El eterno dilema por la costumbre de obtener resultados a corto plazo en el inicio de un proyecto, en comparación a iniciarlo aplicando TDD. Es obvio que el gestor del proyecto velará por los resultados, y siempre verá la primera vez que el equipo sugiera aplicar TDD en el proyecto una perdida de tiempo debido a que los resultados tardarán al inicio más en ser visibles. Aquí nos vamos a encontrar la famosa curva de aprendizaje, de experiencia que tendrá que soportar el proyecto para que el equipo pueda enfrentarse al desarrollo con una técnica diferente.
También tenemos que ser conscientes cuando queremos aplicar TDD por primera vez en nuestro desarrollo, que es el momento adecuado y el proyecto correcto. No... no me linchen por este comentario, simplemente también tenemos que tratar de ser objetivos y pensar que trabajamos para hacer dinero y a veces las casuísticas del proyecto no es la adecuada para enfrentarnos a poner en práctica esta técnica.
El lado técnico siempre deseará mejorar su calidad de vida intentando aportar la mayor calidad posible y por el contrario la parte gestora exigirá resultados para ser rentable. Esto no debería suceder de esta manera, tanto el lado técnico y el gestor deberían estar de acuerdo en la toma de decisiones que mejoren la calidad del desarrollo. Aunque me estoy desviando al tema de la calidad, no quiero entrar en este debate ^_^ hay eruditos en la materia que podrán explicar la mejor manera de abordar estas situaciones.
Entonces os preguntareis... ¿qué nos está contando este...? Pues bien, es mi experiencia reciente y me gustaría dejar constancia de la productividad que tiene el abordar proyectos con TDD
Recientemente he tenido la oportunidad de incorporarme a un equipo en el que tenemos un proyecto en marcha con un 95% de cobertura.
1.- Se que es lo que tiene que hacer la clase gracias al test.
2.- He podido realizar cambios en varias clases gracias a la cobertura de test.
3.- He podido aportar al proyecto en mis primeros días de incorporación.
4.- El equipo respira tranquilidad por los cambios del novato, gracias a la cobertura.
Realmente ha sido muy gratificante, encontrar una situación así. La "guerra" por utilizar TDD ya estaba ganada, y la barrera de crear la arquitectura del proyecto ya estaba muy atrás.
¿Qué quiero decir con esto?
Todos en nuestra etapa laboral hemos tenido incorporaciones en equipos con producto/desarrollo en curso y empaparnos para ponernos las pilas tiene una labor y una repercusión. A mi por ahora me está resultado "blanda" esta barrera inicial gracias a que el equipo está haciendo bien las cosas.
Y que narices, me está resultado mucho más divertido!!
Desde luego, sería muy interesante que explicara como me enfrenté por primera vez a un proyecto para poder aplicar TDD, y analizar las situaciones por las que tuve que enfrentarme. Por lo que la conclusión, es que la rentabilidad y la seguridad de la incorporación a un proyecto de un nuevo activo en el equipo es más cómoda, más segura y rentable para la empresa.