¿Qué responderíais si un Manager os hace esa pregunta?
Me lo plantearon así:
- ¿Qué cobertura de test unitarios habéis alcanzado usando TDD? - Actualmente es del 60% en la parte Java.
- ¿Y cuanto estimas de tiempo de más de desarrollo que os ha costado?
La verdad es que estoy ya tan acostumbrado a escribir test unitarios que esto ya ni me lo planteaba, y me dejaron un poco pillado. A mi se me ha quedado la idea de que los tiempos de desarrollo usando TDD incluso se reducen. Pero es cierto que cuando desarrollas usando TDD escribes mucho, pero mucho más código.
¿Cómo se lo explicas a un manager? Es más ¿Y si el manager no quiere explicaciones? ¿Y si lo único que quieren es un %? ¿0%? ¿-5%? ¿?
Soy de la misma opinión que la Wikipedia: “While it is true that more code is required with TDD than without TDD because of the unit test code, total code implementation time is typically shorter.”
¿Estais de acuerdo o pensais que usar TDD aumenta los tiempos de desarrollo?
¿Si tuvierais que estimar un porcentaje en el incremento o decremento de los tiempos de desarrollo que os implica conseguir cierta cobertura? ¿Sabríais dar una cifra?
Saludos,
Pedro
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
--
Una aclaración. Con este email pretendía centrarme en la opinión de si TDD supone un sacrificio en los incrementos del tiempo de desarrollo. No pretendía debatir sobre el tema de la cobertura.
La percepción para el neófito es que usar TDD le va a suponer escribir mucho más código. Si ahora que no tengo que programar test tardo una semana, usando TDD voy a tardar 2 semanas. De hecho hay programadores que luchan contra TDD argumentando que les va a suponer más trabajo y van a tardar más en terminar la aplicación. Es normal que existan managers que se pregunten ¿y cuanto más vas a tardar? ¿si asumo ese sacrificio que gano a cambio? ¿compensa?.
Es muy habitual confundir el TDD con el tema de la automatización de tests (QA). Sabemos que TDD es mucho más que eso. De hecho programar usando TDD no implica que podamos quitar a la gente de QA y que no sea necesario invertir recursos en testing (manual o automático). La gente de QA debería estar programando sus propios test de integración, sistema, aceptación, etc., al margen de si yo uso TDD para programar o no.
El que no conoce TDD, se piensa que es tan sólo una forma de automatizar el testing que realizan los testers de QA. El testing es bueno para la calidad de su producto. Pero es un trabajo extra que supone recursos extra, ¿merece la pena automatizarlo? ¿Cuánto tiempo adicional requerirá?
Es difícil explicarles que TDD no es testing, que es en primer lugar una técnica de programación cuyo objetivo principal es diseñar desde el código (a la par de que se consigue una cobertura unitaria beneficiosa).
Desde ese punto de vista nuestro 60% de cobertura puede ser bueno para unos y malo para otros. El equipo de desarrollo está orgulloso de mantener su código con un 60% de cobertura unitaria. Pero al manager esa medida le puede causar preocupación. ¿Cuanto tiempo extra has invertido en esos tests?. Está muy bien automatizar tests, ¿pero compensa el tiempo extra invertido?
Existe una tendencia a pensar que TDD aumenta el tiempo de desarrollo de los productos, que ese tiempo es directamente proporcional al porcentaje de cobertura conseguido. Si conseguir una cobertura del 50% lleva un mes adicional, conseguir 100% me llevará el doble.
En mi opinión todas esas deducciones son completamente erróneas, indican que no se entiende lo que es TDD, que no se entiende la diferencia que existe entre un programador usando una técnica de programación dirigida por test unitarios y un equipo de QA dedicado a codificar test de alto nivel (ya sea antes o después del código).
Saludos,
Pedro
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a
agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a
agile-spain...@googlegroups.com
Para obtener más opciones, visita
https://groups.google.com/groups/opt_out.
Francamente, creo que el objetivo debe ser cambiar de una vez a los managers, no intentar enga�arlos para que "nos dejen en paz". �Vamos todos en el mismo barco! :)
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/jIGVD24QuzkJ.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/Bs9eEhIE074J.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/Bs9eEhIE074J.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/jIGVD24QuzkJ.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/y7afjRQ7aj4J.
¿Qué cobertura de test unitarios habéis alcanzado usando TDD?
Si haces TDD puro, deberías tener una cobertura del 100% o casi.
¿Y cuanto estimas de tiempo de más de desarrollo que os ha costado?
Nosotros pensamos que utilizar TDD incrementa los costes de la fase de desarrollo por tres. Posiblemente reduzca los tiempos de implantación y mantenimiento por diez. Si es suficiente con pruebas unitarias, le damos un 30% más de coste a la fase de desarrollo. Los tiempo de implantación y mantenimiento se pueden reducir prácticamente lo mismo.
¿Qué responderíais si un Manager os hace esa pregunta?
Me lo plantearon así:
- ¿Qué cobertura de test unitarios habéis alcanzado usando TDD? - Actualmente es del 60% en la parte Java.
- ¿Y cuanto estimas de tiempo de más de desarrollo que os ha costado?
TDD es caro en el proceso de producción. Multiplica los tiempos de desarrollo, al menos x 3.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Interesante discusión que me ha señalado de forma clara las terribles insuficiencias de conocimiento empresarial de algunos managers. Y me explico:Si un desarrollador hace una pregunta sobre si utiliza o no la metodologia GTD, no lo hace para colgarse medallas y machacar al manager. Lo hace por causas de productividad, para poder tomar decisiones para que la empresa (todos) funcione. Porque no es ni la primera, ni la segunda ni la décima vez en donde una "nueva metodologia de organizacion personal" hace perder dinero a mansalva. Los que abogan por contestar una mentira o con un "eso a ti no te importa", demuestran el enorme problema que se produce cuando el manager piensa que la "organizacion personal es el centro" y se olvida que para ganar un sueldo toda la empresa debe funcionar y obtener beneficios. Y demuestra un inapropiado desprecio a todo aquello que desconoce, y que desconoce casi todo lo que representa una empresa.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Interesante observación, pero la conclusión que sacas no es la única posible. Evidentemente el Manager debe explicar tambíen sus decisiones. Si no lo hace es igual de malo que un desarrollado que no contesta preguntas.
Todo esto solamente funciona si hay respeto y confianza bidireccional. Si no se cumple esta principio no habrá comunicación eficaz y el resultado, como muy buena que sean los individuos, no será satisfactorio.
Un saludo,
Harald
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/jIGVD24QuzkJ.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/jIGVD24QuzkJ.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/y7afjRQ7aj4J.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/LPe0qjjWZhcJ.
Gracias Carlos,
Me parecen muy sensatas tus palabras.
Me ha extrañado las palabras de Quijano que justifica que los managers son los que tienen que tomar las decisiones técnicas porque casi todos los desarrolladores son muy malos y nunca han hecho tests, no saben oo, etc
Supongo que managers como Quijano que reconocía en esta lista que no es capaz de entender un código de 4 líneas para convertir a números romanos son los más capacitados para hacer estas decisiones.
Que cada uno haga su trabajo, el del manager no es hacer microgestion sino facilitar que los demás hagan su trabajo.
Y sobre tdd, como decía uncle Bob, no es una religión sino una práctica.
No creo que sea bueno imponerla o prohibirla a todos los miembros de un equipo, lo veo más como una opción personal, igual que usar patrones de diseño, dedicar tiempo a poner buenos nombres, etc. Es un estilo de programación.
Por supuesto hay muy buen sw hecho sin tdd y muy malo hecho con tdd. Yo personalmente uso tdd aunque entiendo que haya gente que prefiera no usarlo. No veo problema en que en un proyecto haya gente que lo use y gente que no. De hecho en los proyectos que he estado casi nadie usaba tdd pero eso no quita que yo lo usara.
Enlazando con la pregunta original del hilo, yo no intentaría convencer de usar tdd al manager. Si a ti te parece buena idea, habla con tus compañeros, informales, diles de que va, etc, y que ellos decidan si quieren probar. Pero no obligueis a hacer tdd porque la curva de aprendizaje es alta, y si lo hacen por obligación en vez de convicción seguramente os vaya mal.
Saludos,
Leo
Con respecto a la relación con la gerencia, el hecho de que no me pregunten cómo hago mi trabajoes percibido por mi como un voto de confianza. Que quieran saber todo el tiempo cómo trabajome parece justo lo contrario. Yo no les pregunto cómo hacen su trabajo constantemente.La colaboración entre los distintos roles del equipo no tiene que ver con que unos se metanen el trabajo de los otros sino que tiene que ver con el respeto.Si el gerente de mi proyecto no me dejase hacer TDD, para mi significaria que no me respeta.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Sobre el tema "métricas". Por supuesto que no tenemos una demostración cientifica de que TDD ahorra tiempo, si la tuviéramos toda esta discusión no tendría sentido. Como no tenemos estas métricas, ni para TDD ni para ninguna otra práctica de desarrollo de software, entonces nos basamos en eso que tan bien definia el señor fowler como anecdotal evidence. Seria un desperdicio no aprovecharse de la experiencia de otros y descartar el uso de la técnica X por no disponer de "pruebas cientificas", si en software esperásemos a esas pruebas para adoptar nuevas técnicas seguiríamos programando en ensamblador.
Cada cual sabra de que experiencias se fia, y esto dependerá de una cuestión de confianza en quien cuenta su experiencia y de afinidad con el tipo de proyectos o de entorno. Hay gente que dice que TDD no cuesta tiempo extra (yo lo digo) y hay gente que dice que cuesta 3 veces más, ¿quien dice la verdad?, pues seguramente todos dicen su verdad, que cada cual decida de que verdad esta más cerca o cual es el objetivo que persigue y en función a esto que elija sus técnicas.Sobre si TDD es decisión del "manager" o no, pues si cuesta más tiempo o se necesita una etapa de aprendizaje financiada por la empresa entonces si, si no añade tiempo al desarrollo entonces no. Los "managers" manejan cosas como tiempo y dinero, si la decisión de usar o no TDD afecta a algunos de estos factores el manager debería estar enterado, si por el contrario el equipo sabe hacer TDD y no añade más tiempo al desarrollo pues entonces el manager tiene poco que decir sobre el asunto.daniel:Puedes aplicar TDD a cierto módulo crítico del sistema y al resto no.Lo de usar TDD "sólo en las partes criticas" no suele funcionar muy bien, por dos motivos:- Quien hace TDD bien lo hace siempre, es una forma de trabajar no un añadido.
- Que significa ¿"modulos críticos"?. Para mi "criticas" son sólo aquellas partes del proyecto que quiero que funcionen, esas son criticas y las demás no. Lo que puede ocurrir cuando se usa este planteamiento es que los modulos que en principio se consideran "poco críticos" se terminan convirtiendo en "muy críticos" porque son los que están peor echos y por tanto los que generan más tiempo de mantenimiento.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/kDi6bICvCZwJ.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
--
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/jIGVD24QuzkJ.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/y7afjRQ7aj4J.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/LPe0qjjWZhcJ.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/6Uv1LyB7clcJ.
Ojo, yo no he dicho que no existan métricas, cada cual puede tomar las suyas, no es tan difícil. Pero de métricas ha demostraciones o hechos va un trecho muy grande. Esas métricas se han tomado en contextos determinados, con equipos determinados y en proyectos determinados, no se pueden extrapolar al caso general ni constituyen una demostración de nada. Me leido tropecientos estudios sobre lo adecuado o no del uso de TDD, y todos son parecidos, o en otras palabras, son simplemente anecdotal evidence bien argumentada, ni más ni menos. (que no es poco, menos da una piedra).El planteo nunca es trabajar mal, de ser asi, es recomendable no hacer nada. Es obvio que uno se sienta a hacer bien el trabajo, y TDD no es la única forma de hacerlo.La diferencia de opinión es porque para mi TDD es una técnica que siempre aporta en positivo y no me cuesta más tiempo, no tengo que hacer análisis sobre cuando usarla y cuando no, siempre la uso porque es la forma en la que mejor (y mejor incluye más rapido) hago mi trabajo.una buena idea (hacer TDD) es una buena idea, aunque la tenga el manager
Si no sale del equipo es complicado. Será una buena idea, pero si el equipo no esta preparado o no tiene el nivel adecuado puede resultar en desastre. Por eso la idea de hacer TDD tiene que salir del equipo, ellos son los únicos que saben si están preparados o no para hacer que funcione.
El 28 de julio de 2012 22:19, Juan Quijano - The troll escribió:
Buenas,Vaya, sigo viendo que en esta lista como no estés de acuerdo o seas del lado "contrario", tiran con posta. Pero bueno.Yo no creo en TDD, pero esa no es la base de este debate. No lo crítico, ni lo he criticado de forma negativa, ni lo considero una mala técnica de desarrollo. De hecho, creo que es muy buena, y gente que respeto mucho la utiliza a diario. A ver si dejamos de poner en mi boca cosas que yo no he dicho.A pesar de que Leo se haya expresado por lo contrario de una forma que pone en justa medida su calidad personal y profesional, soy un buen gestor de equipos. Y tengo bastante experiencia y conocimiento en las diferentes formas de gestionar y de hacer software. Y digo hacer, porque sigo picando casi todos los días.Por ello creo que los que hacen TDD, creo que deberían huir de argumentaciones tales como que no hay métricas (si las hay, solo hay que hacerlas o buscarlas), solo pueden opinar los que hagan TDD "bien" o, aún mejor, dejar de atacar en un lista de Agilismo a todo aquel que se atreva a no creer en TDD. Este tipo de argumentaciones hacen saltar las alarmas de cualquier gestor o manager, a menos que sea técnico y se haya pegado la paliza de aprender de qué se trata.Sobre el debate, con una búsqueda de 5 segundos he encontrado una página con métricas, Si, las que han argumentado y asegurado QUE NO EXISTEN. En el mundo real, casi todos los procesos tienen métricas que se van actualizando año a año.Y una bastante más completa y compleja:Que cada cual saque sus conclusiones.
--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.comPara ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/N2DyPEasDOYJ.