¿Si utilizamos TDD cuanto tiempo adicional me supone conseguir una cobertura de X%?

[PEDRO BALLESTEROS HERRANZ]

¿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

---

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Juanma Gómez]

Bajo mi experiencia con TDD, esta técnica sólo puede llegar a aumentar el tiempo de desarrollo si:

• Se están dando los primeros pasos con TDD y hay que aprender
• No se definen bien los tests
• El desarrollador es tan bueno que lo que escribe funciona a la primera y es óptimo

Sólo por el tiempo que nos ahorramos en no pasar pruebas manuales con cada línea de código que escribimos / modificamos ya merece la pena. La mejor prueba que puedes hacer es que un compañero tuyo desarrolle una funcionalidad completa sin TDD y tú con TDD, entendiendo que el compañero elegido sea de tu nivel, y de ahí sí que puedes sacar algún dato. 

Aún así, ya no es sólo el tiempo de menos que se destina al desarrollo cuando la técnica está pulida, sino el ahorro en coste de mantenimiento, una auténtica brutalidad, por tener un montón de pruebas automatizadas. Y sí, aún no he hablado de lo que se gana en calidad de producto y todo lo que eso conlleva...

--

Juanma Gómez.

Twitter - LinkedIn - Blog

--
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.
 
 

[Jesús Jiménez Ballano]

Cuánto tiempo te ahorra? Dile una cifra al azar, 25% y ya está. Si alguien te pregunta eso es que no entiende nada, y por lo tanto entenderá lo mismo la respuesta que le des. Tampoco tendrá forma de medirlo con lo que nunca te podrá decir que es incorrecto ese valor.

TDD puede (y no estoy seguro) aumentarte los tiempos del desarrollo al principio del proyecto, cuando estás creando el walking skeleton. Una vez ya lo has montado, te empieza a ahorrar tiempo seguro. Y si te vas a medio plazo (la app tiene ya una cierta cantidad de líneas de código) la seguridad que te da TDD de que no estás rompiendo nada ya es una cantidad de tiempo que te ahorras en busca de por qué ha dejado de funcionar esa otra cosa...

Esto vale también para desarrollar haciendo los tests después, te ahorran también bastante tiempo. Simplemente que con TDD consigo tener menos líneas en el código de producción, no me olvido de probar nada, y hago sólo lo estrictamente necesario.

Y si trabajar con jboss o cosas así, en vez de 25% le puedes decir un 50% tranquilamente, porque sólo con el tiempo que te ahorras en tirar y levantar el servidor de aplicaciones ya te da para hacer todo el TDD que quieras.

De todas formas, habría que ver por qué el manager tiene que decirme si desarrollo con TDD o no. 

[uzi mamani]

Hola mi granito de arena.

Sobre la Cobertura:

Si desarrollas desde el principio con TDD tu cobertura deberia estar entre 90-100 % porque como dice el Tio Bob no escribes ni una linea de codigo de produccion a menos que hayas escrito un test que falle.
Ahora si no lo hiciste desde el principio pues la cobertura dependera de que tanto se hizo con TDD y que tantos test tendras que escribir para aumentar la cobertura. Pero todo depende de los criterios de aceptacion de las Historias de usuario, que es son de ahi de donde se diseñan los test.

sobre el tiempo o costo de desarrollo, no se puede de negar que es mas trabajo ya que se debe dar mantenimiento al codigo de pruebas y al de producción, y esto requiere de mucha disciplina y responsabilidad, al comienzo pues si talves se avance lento (pero seguro) luego ya la velocidad se incrementara conforme el equipo agarre experiencia.

Pero hay un diferencia que en mi experiencia cuando lo empezamos aplicar se noto pero asi brutalmente:

Antes.
PM: Como va el avance?
TEam: Bueno estamos al 60% - 65%, estimando los avanzado (codificado hasta ese momento). como decimos aqui a ojo de buen cubero.

Ahora:
PO: Cuantos historias de usuario tenemos?
Team: 6 Historias de Usuario, un total de 165 escenarios(test) tenemos 3 Historias Terminadas (64 escenarios)  y 21 terminados todos con los test que estan en Verde osea: 51% pero esto es real y las pruebas lo prueban valga la redundancia.
incluso hasta la pregunta cambio, ademas lo puede ver en el servidor CI y en el Task board.

un plus adicional que se consiguio:
1. Calidad del producto.
2. reduccion tiempo de entrega porque el equipo de QA ahora se toma menos tiempo en revisar, ya que orientan sus pruebas a UX, Performance
3. el equipo tiene un animo muchisimo mejor que antes, ahora trabajamos de Lunes a viernes, no hay horas extras...


--
Saludos

Uzi Mamani Fernández

About me

2012/7/23 Jesús Jiménez Ballano <jjba...@gmail.com>

[Alfredo Casado]

Puedes responder lo que el maestro testivus (si no lo habéis leido leerlo que es genial aqui esta entero)

El manager es como el tercer alumno, sólo quiere respuestas simples y además tampoco importa mucho lo que le digas porque el va a seguir haciendo lo que le de la gana. Así que la respuesta es sencilla, dile lo que quiere oir.

Sobre el tiempo de más, pues eso dependerá de vuestra experiencia con TDD, al principio esta claro que hay una curva de aprendizaje, a algunos les cuesta más superarla a otros menos. Una vez superada esta curva llegas a escribir código y test de forma fluida, en este punto se va como minimo igual de deprisa que antes, simplemente ha cambiado tu forma de programar y enfocar los problemas, pero sigues siendo tu el que programa.

[Leo Antoli]

Medir la calidad del código por la cobertura es como medir la productividad por el número de líneas.

La cobertura simplemente indica que pasas por el código, no que estés probando nada interesante, de hecho puedes no estar probando nada.

Tener baja cobertura es malo, pero tenerla alta no es necesariamente bueno.

A cualquiera que le vayan a medir por la cobertura, seguramente hará trampas y se centrará en subirla aún sin pruebas significativas.

Saludos,

Leo

2012/7/23 PEDRO BALLESTEROS HERRANZ <pm...@tid.es>

--

[Alejandro Pérez García]

Tener un velocimetro en el coche que me mide la velocidad del mismo, por supuesto que no indica si soy buen conductor o no, pero igual si me ayuda a que no me pongan una multa   ;)

Con esto quiero decir que por supuesto la cobertura no es un indicador de la calidad del código porque puedo tener una cobertura del 100% pero el código ser una basura porque ni siquiera hace lo que tiene que hacer  (si acaso sería un indicador de la calidad de los test ;)

Pero la cobertura es medible objetivamente y esto puede ser muy importante en determinados entornos, por ejemplos en entornos como el que describe Pedro, donde tenemos un manager que lo único que quieres son cifras, sin ni siquiera querer entender lo que significan.

Si hoy tenemos 60% y mañana 61% nuestro manager estará súper contento porque hemos subido, se lo podrá vender a sus jefes, le pondrán muchas medallas y a ti te dejaran tranquilo con tu TDD. Pero si no eres capaz de "vender" tu juguete en ese entorno "hostil", te lo acabarán quitando ;)

En cuanto a que contestar al manager, no puedo estar mas de acuerdo con Alfredo, a tope con Testivus !!!

Y en cuanto al tema de "hacer trampas", bueno, el que es tramposo es tramposo siempre, por lo que da igual lo que quieras hacer implantar o medir que te la va jugar (o se la va jugar a si mismo, porque no hay más tontería que mentirse a uno mismo). Pero bueno, presupongo que en este entorno estamos entre caballeros y sobre todo entre profesionales  ;)

Saludos a todos !

[Joserra Díaz]

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! :)

Sobre la pregunta concreta, tambien creo que es imposible medir semejante cosa como un % de tiempo por usar TDD. Pero mide la calidad, en defectos, problemas con el cliente, vueltas atrás, etc. Ahí sí tendrás datos para hablar de mejoras de un equipo, a los que un TDD bien hecho va a mejorar sustancialmente. Y en realidad, probablemente podrías sacar una métrica indirecta de tiempo no-perdido.

 Un saludo

   Joserra

2012/7/23 Alejandro Pérez García <alejandr...@gmail.com>

[Enrique Amodeo]

Hola, creo que la pregunta correcta es: ¿si usamos TDD cuanto tiempo
nos ahorramos depurando y manteniendo el código? Realmente TDD te va a
ahorrar mucho tiempo en eso. Vamos, que a la pregunta contestaría con
otra.

Ahora bien, si la organización para la que trabajas vive de facturar
las horas de mantenimiento, y no importa echar unas horitas en una
buena sesión de debugging mientras se facturen, entonces olvídate del
TDD. Ojo, que no digo que sea tu caso, pero haberlas las hay, que las
he visto.

Siempre hay que tener en mente el modelo de negocio de la empresa en
la que trabajas.

Salud !

2012/7/23 Joserra Díaz <jrr...@gmail.com>:

[PEDRO BALLESTEROS HERRANZ]

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.
 
 

[xav...@gmail.com]

¿Si utilizamos TDD cuanto tiempo adicional me supone conseguir una
cobertura de X%?

Esta es una pregunta a la que no podemos ni debemos dar crédito,
podemos entender la preocupación del manager pero es nuestro deber
explicarle que no hay una relación navegable ni medible entre el
tiempo dedicado y la cobertura, que es lo que esta preguntando, nada
que ver con TDD.

¿Si me como una manzana cuanto dinero me va a costar correr los 100
metros en menos de 10 segundos?
Parece la pregunta de un loco no?
Pues eso

Xavi

[Harringer]

Discrepo de dar un numero al azar, dado que refleja un menosprecio al companero que pide esta informacion y dado que es la escusa perfecta para no reflexionar sobre el sentido o no sentido de introducir tecnologia o concepto nuevo.

Relativo a estuerzo adicional por usar TDD lo que opino es que el coste total de poner en marcha una funcionalidad debe de ser inferior con TDD que sin TDD, dado que calidad por diseno provoca menos incidencias al final del proceso.

Veria poco serio dar numeros de ahora porque depende mucho de la situacion concreta y no conozco ningun estudio empirico que haya medido eso. Lo que haria es medir bugs, incidencias, el coste total del software entregado, cumplimento de fechas, satisfaccion del usuario en comparacion con el pasado, aunque suele funcionar bien por ausencia de datos del pasado.

Por fin hay algo de movimiento en la lista. Escse agradecer que alguien haga preguntas como esta.

Un saludo,

Harald

[Harringer]

Es decir que todos los managers son iguales (malos) y todos los programdores tambien (buenos). Creo que no es asi.

Un saludo,

Harald

[Fernando Perez]

Yo estoy con Joserra,� prefiero tener un peque�o debate/discusi�n con mi manager o, haciendo de manager, prefiero que los desarrolladores me expliquen su punto de vista a que me digan, "si abuelo, si"......� Es el modo de ir dando peque�os pasos para que los managers vayan cambiando.

Pedro ha redefinido su pregunta, saliendo de la cobertura del c�digo:
"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."

Y mi respuesta a esta, es que TDD te fuerza a desarrollar _solo_ el c�digo necesario.� Te fuerza a entender el objetivo antes de empezar a construir el medio de llegar a ese objetivo y te fuerza a tener un sistema "medible" del avance del esfuerzo realizado.

Por no hablar de la seguridad, "confiabilidad" y calidad del c�digo obtenido.� Que aunque tambi�n puede obtenerse con los test-after (no son de tomar copas a altas horas, sino los que hacemos despu�s de codificar), puedes acabar testando un c�digo que nadie te ha pedido y que nadie va a usar.

En mi caso, cuando no uso TDD -que no es f�cil y a�n estoy en ello-, a veces me sorprendo "tirando c�digo" (en el m�s amplio sentido de la expresi�n) que no es/era necesario y que yo cre�a, difusamente, que si que lo era.

En definitiva.� Es posible que se codifiquen m�s l�neas absolutas de c�digo, pero el beneficio es doble.� Testeas tu c�digo construido en base a unas premisas y comprensi�n mayor que sin TDD y desarrollas solo aquello que realmente necesitas.

My 2�

El 23/07/2012 22:17, Joserra D�az escribi�:

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! :)

[Aitor Alzola]

Yo creo que no se puede medir con una regla el tiempo que ahorras. Yo sé (y lo sé porque me ha pasado) que una prueba hoy me puede ahorrar dias de depuración dentro de seis meses, pero creo que es complicado de transmitir. 

Discutir esto en un plano teórico tienes muchos problemas, como "lo normal es que no cometamos esos errores", "no deberíamos de tener esos problemas"... un tanto absurdos porque todos sabemos que pasan. De todas maneras cualquiera que ha mantenido un software años (o incluso sin haberlo hecho) se da cuenta de que una buena batería de pruebas ahorra no tiempo, sino mucho tiempo en cuestiones (que tarde o temprano llegan) como cambios de versión de servidores, plataforma, versión del framework que usamos... aunque las pruebas tampoco lo garantizan, depende de como estén hechas y del problema concreto.

Lo absurdo de la pregunta creo que está en ese "tiempo de más de desarrollo". Eso ¿qué significa? ¿que diferenciamos tiempo de desarrollo y tiempo de pruebas? Entonces si que estamos acabados, porque no creo que se pueda separar, haciendo TDD o no. La pregunta bajo mi punto de vista debería ser si tardamos más o menos en total, y la respuesta debería ser que SI, que con TDD tardamos menos. Si no es así ¿para qué lo hacemos? 

(Vale, igual si estamos aprendiendo se puede admitir cierta caída en la productividad, no me refiero a eso)

Por otro lado, coincido con la locura que supone asociar cobertura con "tiempo de desarrollo", si es lo que se pretendía.

El 23 de julio de 2012 15:52, PEDRO BALLESTEROS HERRANZ <pm...@tid.es> escribió:

--

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.
 
 

--
Aitor Alzola

[Carlos Ble]

Hola!

He aprendido de las respuestas hasta ahora, genial el hilo. Enfoques que yo le veo:

- Si TDD es parte de tu forma de programar, entonces nadie tiene que meter las narices en cómo trabajas. Hago TDD porque es como construyo

el software y no permito que un no-desarrollador me diga cómo debo hacer mi trabajo. Mi obligacion profesional es entregar un software que resuelve problemas y que tiene CERO defectos y quien sabe cómo hacer eso soy yo.

- Si no sabes hacer TDD, entonces no aprendas a hacerlo con el dinero de tu cliente. Ponte en el lugar del cliente. Quiere un software

sin fallos y que haga lo que necesita. No te paga por aprender. Si no sabes hacer TDD logicamente vas a tardar mas y lo vas a hacer mal.

No hagas TDD. Puedes usar metaforas para explicarlo: "Siempre he programado en Java y me piden ahora una app con Ruby on rails"

¿Tardare mas? Claro que si, y ademas lo hare mal. ¿Debe pagar el cliente por ello? Me parece que no.

No podemos cargarle al TDD la falta de profesionalidad ni la falta de inversion que las empresas tienen que hacer en sus personas, ni

la inversion que cada profesional tiene que hacer en si mismo.

Piensa siempre en terminos de ser el cliente que paga por el software y eso te disipara muchas dudas.

Si en tu equipo eres el unico que hace TDD regularmente, dile al manager que se olvide de TDD, que el unico que lo va a hacer eres tu.

Que se pongan las pilas para el proximo proyecto. Es mi forma de verlo ahora mismo.

Gracias por el hilo :-)

[Joserra Díaz]

Hola,

 Bastante de acuerdo con Carlos en ver la formación como una inversión, pero hay una cuestión... siempre lo paga el cliente!! De hecho es el único sitio del que saca dinero una empresa, de sus clientes :) Así que la cuestión no es tanto si el cliente debe pagarte la formación o no (puesto que lo va a hacer siempre), si no saber si eres capaz de afrontar un proyecto con garantías de éxito basadas en una opinión profesional. 

 Si necesitas invertir dinero para aprender TDD (y ya deberíais estar todos pensando que va a ser una inversión rentable ;) ) luego buscarás recuperarla, y será con el dinero de tus clientes.

 Salu2

2012/7/24 Carlos Ble <ble.j...@gmail.com>

--

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.

[Joserra Díaz]

Aunque dándole otra vuelta a mi argumento. Probablemente a los clientes les saldrá más baratos tus proyectos por que tengan menor índice de errores, menor tiempo de desarrollo end-to-end, mejor mantenimiento, etc. ¿parece contradictorio con lo anterior? ;)

2012/7/24 Joserra Díaz <jrr...@gmail.com>

[Juan Mari Huarte]

Sobre este tema yo creo que el fundamento es si es RENTABLE usar TDD y cómo explicarlo a un manager.

Un Manager maneja presupuestos, de la misma manera que nosotros cuando compramos una lavadora.

Por lo tanto, ante cualquier novedad o añadido siempre nos pregunaremos si ese añadido nos resuta interesante o rentable.

Os juro que no entiendo de lavadoras, y no se si es más interante pagar más por una de "clase A" o no. Pero el tipo que me vendió la lavadora (de clase A, por cierto) supo explicarme de mil maneras que, aunque a priori gastase más dinero, a la larga me era más rentable. Quizás otro no lo hubiese hecho.

Y os aseguro que no tuve que aprenderme ningún plano, ni tablas comparativas ni otras vainas,.. al final compré calidad.

A dónde voy es que efectivamente tenemos un problema de saber explicar la rentabilidad de nuestros artilugios. Estamos convencidos de que somos muho más eficaces y rentables haciendo agilismo y utilizando cosas como el TDD y muchas más,... pero en muchas ocasiones no podemos explicarlo.

Sin tener el argumento preparado puede que un camino sea el pensar en calidad de forma global... pensar en que TDD incrementa netamente la calidad (errores y prducto orientado a necesidades), y eso redunda en una calidad neta del producto, que se transforma fácilmente en una satisfacción del cliente, quien en mundo tan arriesgado como el software es posible que te sea más fiel e incluso que esté dispuesto a pagar más.

La industria en general ya tiene asumido que la calidad abarata el proceso productivo y que es la clave de la competitividad y futuro de las empresas.
Aprovechemos eso.

Si hay consenso en que "TDD = Mayor calidad" (cosa que a veces no parece claro) divulguémolos así. Probablemente es lo único que necesite un manager para decidirse, sin necesidad de cifras concretas. Quizás haya que matizar cuándo y cómo es razonable utilizarlo y cuándo no,... pero la idea puede ser esa.

Anexo: Ojo,... que de alguna manera también estamos diciendo que los profesionales que no saben o aplican TDD,... pues eso,...que les falta un punto de calidad ???? Je, je, je,,,..

[Israel Alcázar]

Creo que hilos como este nos ayudan a todos a crear ese discurso que nos hace falta cuando nos pregunten. Por otro lado a la frase de Juan Mari:

"La industria en general ya tiene asumido que la calidad abarata el proceso productivo y que es la clave de la competitividad y futuro de las empresas. 
Aprovechemos eso."

No lo tengo nada claro. Por lo menos en los proyectos en los que me he movido no he visto ni un solo test automático (ni unitario, ni de integración ni na de na)...así que eso de que en la industria se tiene asumida la calidad, permitidme que discrepe :D...pero bueno, no es este hilo para hablar de eso :-)

Gracias a tod@s por las aportaciones tan interesantes!

--

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 obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Israel Alcázar Rodríguez
israel...@gmail.com
http://www.farmerdev.com

http://www.mavencharts.com
http://www.twitter.com/ialcazar

[Alfredo Casado]

Por poner una comparación para explicarlo, imaginar que hace 15 o 20 años un manager te viniera a preguntar ¿Cuanto tiempo ahorramos con esto nuevo de la programación orientada a objetos?. Los "managers" de todo el mundo se han gastado mucha pasta en formación en orientación a objetos, en cambios tecnológicos hacia la orientación a objetos, y no creo que nadie me pueda dar una medida de exactamente "cuanto tiempo ahorro con OO frente a programar estructurado". Pues TDD en mi opinión esta en el mismo capitulo, es más un cambio de paradigma que una tecnica adicional que añadas a lo que ya estas haciendo, que es como se suele entender de primeras, por eso parece logico pensar: "lo que hacia antes + test = más tiempo".

Juan Mari.

que de alguna manera también estamos diciendo que los profesionales que no saben o aplican TDD,... pues eso,...que les falta un punto de calidad 

Si claro, no nos rasguemos las vestiduras por decir lo que uno piensa, siguiendo con la analogía, si en 2012 un programador te dice que no conoce la orientación a objetos ¿que pensarías de el?. Quien en 2012 con conozca TDD, lo haya intentado usar y se haya preocupado por aprender la tecnica, pues sencillamente no es un buen profesional. Otra cosa es que alguien lo pruebe y decida que la tecnica no le gusta, no encaja con su forma de enfocar en desarrollo de software o conoce otras formas mejores de desarrollar, no tenemos la verdad absoluta los que hacemos TDD ni mucho menos, pero desde luego si que creo que es una tecnica con el suficiente peso como para que cualquier profesional que se precie la conozca. 

Ya que estamos con esto, hablamos de convencer a los managers, pero a veces es tarea más difícil convencer a los propios desarrolladores, a esos les podemos hablar en lenguaje técnico y no debería resultar tan difícil convencerles, pero luego en la practica yo al menos es donde más barreras me he encontrado con mucha diferencia.

[Harald Messemer]

Creo la industria en cuestión es más de caracter general como describe este articulo:

http://www.elergonomista.com/relacioneslaborales/rl53.html

En mi opinión la referencia a Deming es muy acertada y expresa por que dedicar esfuerzo en tareas de evitan fallos (calidad by design) es mejor que tareas que corrigen fallos (calidad by pruebas posteriores y corrección).

Igualmente está claro que muchos equipos de desarrollo aún prefieren corregir fallos en vez de evitarlos. El argumento, muy a mi pesar, suele ser "No tenemos tiempo para probar durante el desarrollo" o, más sofisticado "Queríamos hacerlo, pero al final no hubo tiempo y teníamos que terminar".

En mi opinión la única salida de este circulo vicioso es tener paciencia, leer libros, explicar las cosas, tener paciencia y esperar que el dinero se agota antes de tener resultados :-)

Un saludo,
Harald

2012/7/24 Israel Alcázar <israel...@gmail.com>

[Juan Mari Huarte]

Por matizar la frase, y creo que estaremos de acuerdo.

Yo creo que sí se tiene asumida la calidad,.. el problema es definir que entra en la palabra "calidad".

Y el asunto es que no se asocia calidad con tener TDD, con tener buenas arquitecturas, formación, profesionalidad, agilismo si es el caso, etc,..

Lo curioso es que no pasa en todos los aspectos. Por ejemplo, hace muchos años no se asociaba calidad con tener una gestión de configuración, y sin embargo, ahora, si no hay un control de versiones prácticamente no entras en un contrato importante por "chapucero".

La calidad en el desarrollo de software yo creo que se asocia en muchas empresas, tanto desarrolladoras como clientes, en tener una metodología  que siga unos estándares, o quizás a que la recogida de requisitos sea muy minuciosa, o tal vez los informes, o CMMi, etc,..,.. y eso es lo que se "entiende" por proyectos de calidad a día de hoy, según me parece percibir.

En definitiva, y desgraciadamente, yo creo que no se percibe que TDD aporte calidad aunque lo haga (ni siquiera las pruebas unitarias, lo que ya es para llorar,...). A mi entender es una asignatura pendiente de revelarse y también, por qué no, de venderse.

,

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 obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Carlos Ble]

Hola!

Que el dinero salga de los clientes es lo normal, pero eso no significa que paguen directamente por el aprendizaje :-)

 Salu2

2012/7/24 Carlos Ble <ble.j...@gmail.com>

Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain+unsubscribe@googlegroups.com

[jorge baez]

retomando el hilo... tienes alguna métrica del proyecto y de otros para evaluar?

si no lo puedes medir, es como si no existiese, más allá del mundo de las sensaciones, creo yo ;(

 Salu2

2012/7/24 Carlos Ble <ble.j...@gmail.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.

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/-/y7afjRQ7aj4J.

[Juan Quijano - The troll]

Buenos días,

Interesante discusión que me ha señalado de forma clara las terribles insuficiencias de conocimiento empresarial de algunos desarrolladores. Y me explico:

Si un manager hace una pregunta sobre cobertura o sobre esfuerzos, no lo hace para colgarse medallas y machacar al desarrollador. 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 tecnología" 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 desarrollador piensa que el "código 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.

En relación con ello, me refuerzo en la visión de que los desarrolladores hacen TDD en un acto de fe. Nadie, de todos lo que han contestado en este foro, habla de cifras. Todos hablan de sensaciones, de que se supone que es mejor y se pierden en disertaciones sobre la calidad. Pero no aportan ni una sola prueba científica de las ventajas de utilizar TDD. Ni una sola alegoría que sea difícil de desmontar. 

En mi opinión, hacemos TDD porque gente a la que respetamos, dicen que está bien. Y repetimos lo que ellos hacen/dicen.

También se parte de la base de que TDD es "una bala de plata" que vale para hacer cualquier desarrollo y que si no se realiza así es mal código. Y eso es falso. De hecho, las empresas que realizan TDD son minoría. Y, no está para nada demostrado que sea beneficioso en la generalidad de los casos. Por ejemplo, hacer TDD en una aplicación web comercial de 15/20 días no sale rentable, o utilizar TDD para aplicaciones con una compleja lógica de negocio, tampoco es la aproximación que yo utilizaría.

Sobre lo de que" nadie puede decirme como debo construir el software porque soy quien sabe hacerlo", estaría de acuerdo si no fuera por ser una aseveración un tanto lejana a la realidad. En España, la mayoría de los desarrolladores no saben utilizar correctamente la POO, no han hecho un test unitario en su vida, no saben los patrones básicos, ni mucho menos los avanzados. De hecho, las poquísimas personas que tiene el nivel suficiente, se convierten en "gurus". Indicando de forma clara que el nivel es bajo y que las decisiones de la forma de construir el software, que impactan directamente en la viabilidad de la empresa, tiene un inasumimible grado de incertidumbre dado el nivel de conocimiento más bien bajo de nuestros desarrolladores. Otra señal de lo que afirmo, es la endogamia constante de los eventos de desarrollo. Las mismas caras, las mismas personas y (lo que es peor aún) los mismos "gurus". Lo que señala que la evolución está siendo muy lenta. 

Y ahora que he opinado sobre las opiniones de otros, muestro las mías, 

TDD es caro en el proceso de producción. Multiplica los tiempos de desarrollo, al menos x 3. Pero, en los proyectos en los que se puede utilizar, dependiendo de la criticidad y coste de los errores en producción (si existe mantenimiento en el futuro y la criticidad de su coste) puede ser una opción que puede ahorrar costes en el total del negocio.

Es decir, asumes que vas a tener un gran número de errores, y los corriges antes de que aparezcan. Si este número de errores es mayor del que preveias, bien, porque ganas dinero. Si es menor, has trabajado en balde para corregir los errores que nunca han aparecido. El TDD es partir de la base que toda linea de código va a fallar, lo cual es tan cierto como decir que ninguna lo va a hacer. 

Yo hago TDD en algunos casos, y test unitarios en todos los que puedo. En el primero no creo, a pesar de estar rodeado de gente que si lo hace. En el segundo, no entiendo el código sin test, aunque a veces tampoco lo puedo utilizar.

Con respecto a la cobertura, deberías sentarte con tu manager y explicarle que la cobertura a nivel de test unitario no es un valor especialmente útil. Si estuviéramos hablando de cobertura en test funcionales o de BDD, entonces si tendría más sentido. Pero, sin olvidar (como programadores), que hay contratos (y no pocos) que tiene un nivel mínimo de cobertura como parte de la SLA, y que hay que cubrirlo para poder licitar o cubrir sus requisitos y así ganarnos el sueldo (que no es solo programar). Y que el cliente no se merece que le mintamos haciendo una cobertura falsa o inconsistente. Y sin olvidar que la construcción de esa cobertura tiene un coste que hay que imputar en la etapa de desarrollo.

Para no alargar más esta disertación, te respondo:

 ¿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.

[Enrique Amodeo]

A mi lo que dice Juan Quijano me parece acertado. Pero entrando un
poco más al tema personal: me molesta mucho que se dude del TDD y no
de otras prácticas arraigadas en las consultoras. Que se dude y se
pidan pruebas me parece bastante racional y no veo nada malo en ello.
El problema es el agravio comparativo. Algunas preguntas que a veces
me han dado por pensar y no me atreví a preguntar:
a) ¿Cuántos euros se ahorra la empresa por cada euro gastado en el
departamento de QA? ¿Algunas métricas del mundo real sobre esto?¿Algún
estudio?
b) ¿Cuántos euros se ahorra la empresa por cada euro gastado en la
implantación y mantenimiento de ITIL (o CMMI) nivel X? ¿Algunas
métricas del mundo real sobre esto?¿Algún estudio?
c) ¿Cuántos euros se ahorra la empresa por cada euro gastado en el
sueldo de un "manager"? ¿ROI de un "manager"?¿Algunas métricas del
mundo real sobre esto?¿Algún estudio?
d) ¿Cuál es el ROI de un programador de bajo nivel comparado con el
ROI de un programador profesional?
e) ¿Cuántos euros se ahorra la empresa por cada euro gastado en el uso
de UML? ¿Algunas métricas del mundo real sobre esto?¿Algún estudio?
f) ¿Cuántos euros se ahorra la empresa por cada euro gastado en
licencias del IDE último modelo de la famosa empresa XXX? ¿Algunas
métricas del mundo real sobre esto?¿Algún estudio?
Puedo seguir y lanzar muchas preguntas más. El único estudio que
recuerdo es el CHAOS report, que dice que hasta el momento hemos hecho
software como el culo en esta industria. Supongo que es un aliciente
para probar cosas nuevas, ¿no?

Ahora bien, sobre TDD en concreto, tengo que repetirme: ¿cómo gana
dinero la empresa?. Si el responsable del desarrollo del proyecto no
es el mismo responsable del mantenimiento del mismo, el primero no
tiene ningún incentivo para hacer TDD. En cualquier caso si el
mantenimiento se cobra por horas y no a precio cerrado o por
objetivos, tampoco hay incentivo para hacer TDD.

Salud !

2012/7/26 Juan Quijano - The troll <juancarl...@gmail.com>:

> --
> 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/-/l8N44wTypsUJ.

[Daniel Ceillan]

El 23 de julio de 2012 10:52, PEDRO BALLESTEROS HERRANZ <pm...@tid.es> escribió:

¿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?

Primera posible respuesta: "nos ha costado la quinta parte de lo que hubiéramos perdido si no lo hiciéramos"

Segunda: la que te dijeron por ahi del 25%... cuando algo no se puede medir, ponle un número... y lo dejas tranquilo. 

Sobre la cobertura, es un gran depende... si te enfocas en hacer tests productivos y estratégicos, con un 30% de cobertura estarás genial. 

Saludos. 

--
Daniel Ceillan

Blog: www.agile-patterns.com

[Jesús Jiménez Ballano]

Criticas que los que hacemos TDD y hemos contestado antes no damos números.

El 26 de julio de 2012 12:56, Juan Quijano - The troll <juancarl...@gmail.com> escribió:

TDD es caro en el proceso de producción. Multiplica los tiempos de desarrollo, al menos x 3. 

Me gustaría que de una forma empírica, me demostraras este dato. Y me refiero a gente que sepa TDD, que lo haya practicado lo suficiente como para ponerlo en práctica, no alguien que ha hecho 2 katas y como tarda más tiempo de lo que tardaría sin hacer TDD decide no seguir practicando. 

[Harald Messemer]

Relativo a los números. En primer lugar creo que la hipotesis de Demina que evitar fallos es más barato que corregir fallos ya ha sido demostrado cientificamente. No tengo la referencia a mano, pero tiene pinta de no ser tan dificil de demostrar.

A partir de allí, la cuestión es como se mide. Como ya he dicho anteriormente me parece inaceptable de mentir si alguien, aunque fuera un manager, al respecto o de inventarse números.

Desde la perspectiva de Manager una respuesta que me parecería razonable sería plantear lo siguiente:

• Estudiemos algunos de los proyectos pasados y medimos los esfuerzos que se han dedicado despues de finalizar el desarrollo y despues de poner en marcha en producción hasta dar como consolidado el desarrollo. (será relativamente fácil, dado que las imputaciones de horas suelen hacerse en muchas empresas. tal vez no se sabrá con exactitud a que concepto corresponden, pero se podria mirar en el calendario).
• Haremos un par de proyectos con TDD y sacamos las mismas métricas.
• Ajustaría los números de los proyectos de TDD para tener en cuenta el esfuerzo en aprendizaje y soporte externo
  
• Comparamos las dos mediciones y sacaremos conclusiones.

No tengo ninguna duda que los números serán favorable para TDD, pero esto ya da igual por que tienes una base con la cual puedes observar a partir de este momento, si tus intentos de mejorar la calidad / productividad dan resultados.

Un saludo,
Harald

2012/7/26 Jesús Jiménez Ballano <jjba...@gmail.com>

--

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

[Marcin Gryszko]

en el parrafo sobre la relacion desarrollador-gerente Juan asume que 'gerente sabe lo que necesita la empresa, el desarrollador no mira mas alla de su punta de nariz'.

Y si cogemos tu texto y cambiamos desarrollador por gerente y TDD por GTD (Getting Things Done)? Vamos a ver que sale...

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.

Resumiendo: no me meto en tu manera de trabajar como manager. Tu no influyas en mi manera de trabajar. Si no te gusta que haga TDD, me despides o me voy yo o mas probablemente nunca voy a trabajar contigo.

[Harald Messemer]

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

2012/7/26 Marcin Gryszko <mar...@grysz.com>

--

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

[Luis Fraile]

Totalmente de acuerdo con Harald, ¿Acaso hemos olvidado el people over processes and tools?

No se, la ultima vez que vi sobre agile, el respeto a TODOS, tenía mucho que decir sobre todo esto ... Creo ...

Un saludo,

Luis Fraile 

Enviado desde dispositivo móvil.

[uzi mamani]

Todo esto de que El manager es malo, el dev es malo,... me sabe a the blame game..

La decision de utilizar una tecnica de desarrollo es una decision de equipo y si han pensado en TDD es tal ves porque han leido y escuchado que los errores de desarrollo (programacion) disminuyen desarrollando con TDD, pero eso es solo una pequeña parte, falta UX, comportamiento, performance, escalabilidad, etc... hay un monton de factores que se podrian utilizar para decir que un producto de software es de alta calidad, TDD te podria ayudar en ello, y digo que sólo podría porque depende de ti, de como lo hagas, porque no es solo escribir un test que falle y luego escribir codigo que pase el test por solo hecho de hacerlo, tiene que haber un valor un objetivo que cumplir que basicamente es cubrir las necesidades del negocio las cuales estan en constante cambio.

Si han pensado que TDD te va solucionar la existencia, sólo te dara una manito nada mas, hay muchas otras cosas mas en juego y depende de las PERSONAS. Ahora los resultados no los vas a ver mañana, ni pasado... se veran en un futuro que podria ser en el siguiente sprint,release o tal ves en el mantenimiento despues de ponerlo en produccion, cuando haya que hacer un cambio, cuando escribas un test que verifica el cambio, luego escribas el codigo de produccion, y veas que otros test se caen (regression test)  y tengas que hacer las modificaciones ya sea en los test o en codigo, que tal ves sin los test tendrias que volver a probar todo a mano y te tome 1 o 2 semanas, pero gracias a que desarrollaste aplicando TDD lo hiciste en 1 o 2 dias.


estas cosas no dan resultados de la noche a la mañana, es un largo camino por andar y TDD es solo una estacion una villa en ese camino, y bueno es que a medida que avanzas el paisaje se ve mas bonito...


Saludos cordiales

Uzi Mamani Fernández

About me

2012/7/26 Luis Fraile <lfr...@gmail.com>

[Daniel Ceillan]

El 26 de julio de 2012 17:45, Harald Messemer <harr...@gmail.com> escribió:

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

Exacto!!! excelente!... nunca nos tenemos que olvidar de desarrollar interacciones ganar/ganar... dialogar, escuchar, decir las cosas...

Pero no alcanza con la voluntad de una sola de las partes. Y cuando no se cumple la voluntad, entonces hay que aplicar más metodologías que nunca... amen de tratar de armar los equipos con gente madura que hable y escuche.

Desde la faz tecnica, como manager me preocuparía muchísimo si mi equipo no tiene una estrategia de testeo, sea cual fuere la que le gusta. (a mi me gusta TDD, pero hay otras)

Me significaría muchísimo riesgo afrontar un sistema que va a escalar, y no esta apoyado en testing... me parece una burrada metodológica, y el beneficio del testing no se mide por cuanto costo implementarlo, sino por todo el tiempo que te ahorra, de problemas, debugs, y estar tranquilo de que una modificación no rompió otra parte del sistema. Cosa que si no esta cubierta por tests, lo descubrirá el usuario final cuando tenga el producto en la mano.

Saludetes!

[Carlos Ble]

Claro que tengo métricas, llevo años practicando TDD la mayor parte del tiempo y hablo desde mi experiencia empirica. No de sensaciones.

La metrica es no necesitar bugtracker y ser capaces de hacer cambios seguros y rapidos. 

En el proyecto que hicimos completo desde cero con TDD, sin nada de código legado,

nunca hizo falta bugtracker. Saliamos a produccion sin defectos. De vez en cuando aparecia alguno por casos que no

habiamos pensado y que descubriamos con testing exploratorio. Lo corregiamos en cuestion de minutos con un test 

que lo evidenciaba y el bug nunca reaparecia. Creo que tuvimos 5 o 6 defectos en un año (aunque deberiamos haber tenido cero)

y ninguno estuvo abierto mas de un dia.

Cambiar el comportamiento de la aplicacion se hacia en minutos y con total seguridad. 

La diferencia con cualquier otra forma de programar que yo haya probado es aplastante, sin comparacion.

En el proyecto actual, donde una parte es legacy y otra es nueva con TDD, la tonica es la misma. La parte

TDD no presenta bugs y los cambios sobre el codigo se hacen rapido y con seguridad.

La mayoria de los argumentos que escucho contra TDD, incluido eso de que se tarda mas, vienen de personas

que realmente no llevan mucho tiempo practicandolo o que lo hacen mal. Por eso no me enfrasco mucho

en estas discusiones. Prefiero discutir mas con quien habla desde su experiencia, para que yo pueda aprender

y compartir. 

Tardar 3 veces mas en desarrollar por hacer TDD, significa en mi opinion que se esta haciendo mal, o que

en esa estadistica no se está contemplando el tiempo que se tarda en corregir bugs ni los problemas

que derivados de que sea el cliente quien encuentre los bugs, y que le peten cosas que antes le

funcionaban y todas esas cosas.

Fuera de España es muy común que las empresas cuando no conocen una técnica o tecnologia contraten

un consultor o mentor para que les suavice la curva de aprendizaje. En España lo veo poco y todo el

mundo tropieza mil veces en la misma piedra. Contar con ayuda externa podria solucionarnos muchas

veces los contratiempos de los inicios. Seria mas barato sin duda.

Con respecto a la relación con la gerencia, el hecho de que no me pregunten cómo hago mi trabajo

es percibido por mi como un voto de confianza. Que quieran saber todo el tiempo cómo trabajo

me 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 metan

en 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.

Saludos ;-)

 Salu2

2012/7/24 Carlos Ble <ble.j...@gmail.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.

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

[Harald Messemer]

Buena aportacion. Saber utilizar una tecnica es importante para sacar conclusiones sobre su valor. Aleman no es idioma malo por ser complicado de aprender.

Un saludo,

Harald

 Salu2

2012/7/24 Carlos Ble <ble.j...@gmail.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.

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/-/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.

[Leo Antoli]

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

[Harringer]

Este tema da para tiempo. 

No creo que Quijano haya dicho o que queria decir que los managers deben tomar decisiones tecnicas.

Lo que pasa es que equipos donde los managers son ingenieros y los ingenieros que programan tienen menos experiencia que los ingenieros managers. En estos equipos  papel de arquitecto suele estar indefinido y discutido entre ambas partes.

Sin rompes en estos casos el dialogo, dejas de sacar provecho de la experiencia global de este equipo.

Un saludo,

Harald

[German DZ]

En algunos casos no es cuestión de cuanto tiempo cuesta (si más o menos) sino de cuando deberás "gastarte" ese tiempo. Durante el diseño/desarrollo de algo (aun no está en producción) tardar 5 o 10hs más o 10 días más tal vez me cueste eso… 10 días más que serían algo así como uno 5000€.

Ahora bien, ¿como justifico 5000€ más de coste?, calculando cuanto me costará ajustar/corregir/cambiar algo de ese software luego de que esté en producción, porque en ese momento 15minutos, 2hs o 10 días significan cosas muy distintas, y ahí seguramente el account manager te pueda decir en pocos segundos si esos 5000€ lo valen o no.

Digamos que la empresa cliente en cuestión factura unos 10.000.000€ anuales (menos que eso probablemente no contrate a una consultora para hacer software a medida).

Supongamos que el software funcionando mal implique re-hacer un proceso y en eso se pierdan 3 minutos por operación por casa "administrativo", con 3 administrativos en la empresa haciendo eso 10 veces al día son algo así como 90 minutos de operación perdidos al día (, a un coste de 40000€ año de cada administrativo perdiendo el 6% de su tiempo, estás perdiendo 2400€ al año. No creo que convenga gastar dinero en optimizar eso. Excepto que eso te obligue a contratar un 4º administrativo porque con 3 perdiendo ese tiempo ya no puedas llevar tu negocio.

Pero ahora supongamos que el software está fallando en producción y te impide vender telefónicamente y eso es el 25% de tu facturación… eso serán unos 8000€ / día; entonces ahí supongo que te compensará tener todo bien diseñado y probado porque cada minuto que ahorres durante la corrección y asegurarte que no vas a romper nada más se verá bien compensado.

El famoso "espere unos minutos mientras consultamos su caso en el sistema" o el "no se ha registrado en el sistema" ¿cuánto le cuestan a la empresa? porque muchas veces para mantener el SLA de atención en 5 minutos a cada cliente con estas cosas son más difíciles de lograr o si necesitas atender 800 de estos casos al día significará tener 2 o 3 personas más en el call center.

¿En serio creéis que TDD es algo que debamos medir los programadores o los managers? Yo creo que hace falta que seamos profesionales y podamos hablar con los que llevan el negocio de una manera clara y al mismo nivel, para que la toma de decisión se haga responsablemente.

2012/7/28 Harringer <harr...@gmail.com>

[Daniel Ceillan]

El 27 de julio de 2012 21:58, Carlos Ble <ble.j...@gmail.com> escribió:

Con respecto a la relación con la gerencia, el hecho de que no me pregunten cómo hago mi trabajo

es percibido por mi como un voto de confianza. Que quieran saber todo el tiempo cómo trabajo

me 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 metan

en 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.

Genial! aplausos!!!  :D

Por otro lado me parece que se esta perdiendo un poco el foco.

TDD es una técnica de desarrollo, no de testeo.

Cuesta:
+ quizás un 10 a 20% mas de tiempo, que hacer las cosas directamente y sin tests.

Genera:
+ cobertura de testeo.
+ hace fácil el desarrollo complejo.
+ seguridad a la hora de ir a producción.
+ evita que el avance del proyecto sea cada vez más lento.
+ documentación viva y actualizada en forma de tests.
+ facilita el reemplazo de desarrolladores en el equipo.
+ constituye una tranquilidad para el developer, al saber que sus cambios no estan rompiendo otras partes del sistema.

De todas maneras:

Es una técnica, no es la única, ni la última. Si es muy ágil. Pero no se aplicaría a todos los proyectos, y quizás tampoco al 100% de un proyecto. Puedes aplicar TDD a cierto módulo crítico del sistema y al resto no.

Es una herramienta, nada mas. Puede que cueste un poco mas en tiempos, pero ahorra mucho por otras áreas. La herramienta no va a ser ágil si la usa una mente no-ágil.

Si a un director de esclavos le sacas el látigo y le entregas una varita mágica, y le explicas porqué la varita mágica va a ser mas ágil y podrá dirigir a sus hombres como una orquesta... lo más probable es que al otro día este golpeando a los esclavos con la varita.

Necesitamos pensar diferente.

[Alfredo Casado]

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

[Daniel Ceillan]

El 28 de julio de 2012 16:00, Alfredo Casado <casado....@gmail.com> escribió:

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.

Exacto, aunque este demostrado científicamente, no significa que a ti te funcione. No todo son números, hay personas involucradas, que son las que hacen la diferencia.
 

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.

Como técnica es una estrategia, y puedo decidir implementarla en partes del sistema, que involucran mucho valor de negocio, y que tienen complejidad de desarrollo. En ese caso pueden ser reglas de negocio complejas y relacionadas.
 

   - 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.

Bueno las he definido en el párrafo anterior.  Existen prioridades, y riesgos. Y la estrategia es el arte de ver la diferencia que existe. No todo es igual, y no todo se solucionará con la misma herramienta.

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. Que haya dicho que algunas partes no se hagan con TDD, no significa que no esten cubiertas por tests.

Saludos!

[Harringer]

Estando de acuerdo con Alfredo, matizaria:

-una buena idea (hacer TDD) es una buena idea, aunque la tenga el manager

-el manager maneja tiempo, dinero, calidad, satisfaccion usuario y alcance (se ha hecho lo que se debia hacer o el cliente acepta lo que se ha hecho)

-se puede medir de forma indirecta si TDD funciona comparando los costes de proyectos pasados derivado de problemas de calidad con proyectos hechos con TDD (claro hay que apuntarse esto y si el resultado no es satisfactorio no necesariamente se debe a que TDD no funciona)

Un saludo,

Harald

[Juan Quijano - The troll]

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.

http://mattberther.com/2004/04/19/tdd-metrics 

Y una bastante más completa y compleja:

http://www.rodhilton.com/files/tdd_thesis.pdf 

Que cada cual saque sus conclusiones.

[Juanma Gómez]

Hola gente.

El hilo ha generado un debate muy rico. Por favor, no entremos en descalificaciones personales y profesionales.

Debemos opinar siempre desde el máximo respeto a quien no piensa como uno mismo.

Os ruego mantengamos el debate sano y vivo, como adultos que somos. Y si es necesario, quedamos a tomar unas cervezas y lo seguimos en los bares.

Un saludo!

--

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.
 
 

--

--

Juanma Gómez.

Twitter - LinkedIn - Blog

[Harringer]

Hola Juan,

Tal vez quitandote el apodo "Troll" habria menos polemica, pero por otro lado algo de vidilla tampoco esta mal.

Relativo el blog de Matt opino que son mediciones del bienestar del programador que aportan poco valor objetivo, sino confirman la posicion de cada cual.

El segundo, viendo el indice y asumiendo que las metricas salen favorable a TDD, parece mas interesante. Las metricas no son nuevas, sino ya se conocen y describen la calidad intrinseca del codigo programado. 

Alli esta el punto de interes. Haciendo tests a posteriori identificas y corriges fallos. En este momento el hecho que las metricas salgan bien o no ya es irrelevante (hay que corregir errores y sacar el producto), aunque si lo es para el resto de la vida util del software.

Con TDD es diferente, la calidad del codigo a traves de estas metricas puede ser mejor a priori y se consigue un quality by design.

Evidentemente no demuestras que TDD sea mejor que otros metodos, pero el origen del debate era como demostrar que TDD es util.

En mi opinion la utilidad de TDD consiste que consigues una mayor calidad del codigo de forma natural en vez de desarrollar para que las metricas tecnicas salen bien.

De todos modos, para mi las unicas metricas que valen son las que demuestran que el software funciona directamente y contar bugs y esfuerzo dedicado a identificar y corregirlos, por lo menos en un equipo normal, me parece efectivo.

Un saludo,

Harald

--

[Alfredo Casado]

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.

--

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

[Carlos Ble]

Hola Leo,

Mas allá de que este de acuerdo o no con tu email, creo que en esta lista no debemos atacar a nadie personalmente aunque ya se haya hecho en todas las direcciones otras veces. Confieso que NO he leido los hilos donde se insultaban unos a otros pero en este que he participado me sabe mal que usemos este tono. 

Hay ya muchos problemas en el mundo para que creemos más donde no tiene sentido que los haya. 

Un abrazo ;-)

 Salu2

2012/7/24 Carlos Ble <ble.j...@gmail.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.

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/-/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

[Jose Diaz]

Hola, si que los post estan cargados de mucha energía.

Bueno yo le voy al TDD pero no preocupandome en tener una cobertura del 100%.

He tenido proyectos desarrollados desde hace muchos años y he venido a la fecha dandoles mantenimiento.
El tema es que antes de TDD cuando se presentaba un problema, teníamos que buscar en el log, reproducir el error consultando al usuario o revisando el mail con copia a todos los gerentes sobre el problema. Al igual que un personaje de video juego nuestra reputacion con el cliente va disminuyendo porque va perdiendo la paciencia con cada hora que transcurre hasta encontrar el problema. Ademas no se si les ha pasado no se acuerdan de los "goles" metidos anteriormente, el tema es que esto lo quiere YA.

Cuando conocimos TDD tambien tuvimos la asunción de que era doble esfuerzo. Aplicabamos la formula:

codifico + prueba  = horas de desarrollo + horas de prueba (mas tiempo, mas problemas para convencer al cliente de que ahora por eso necesitamos poner mas horas).

Pero, cuando entendimos que era una tecnica de diseño, en la que la prueba resulta en el codigo probando comportamiento. La formula cambio a   prueba = codigo + delta. Donde el delta es el arte de plasmar un comportamiento a probar (porque tambien hay que poner algo de sapiencia en la prueba/escenario/ejemplo a desarrollar).

En fin, nos costo, asi que tuvimos que ir colocando TDD en el codigo que constantemente presentaba problemas para
tener cubierto distintos comportamientos y validarlos con lo que se pedía en los casos de uso y ver si estaba todo contemplado. No hablo de historias por que no empezamos asi tampoco.

Hoy en la actualidad. Tratamos de iniciar TDD si el proyecto vemos que luego va a ser mantenido por nosotros. Porque no saben lo bueno que resulta poder estar conciente de todos los comportamientos que se han desarrollado con esta tecnica y validados con los criterios de aceptación de cada historia.

Por ahora no probamos todo. Creo que estamos en una curva en el cual vemos que podemos hacer bien y que nos da valor. Por ejemplo, aun no testeamos todo el javascript que usamos.

Estamos en un paso a paso. Claro esta que al cliente, no se si esta mal, no le decimos hacemos TDD, la verdad al menos los clientes que tenemos no tienen ni idea. Es mas como miembro del team algo que si me interesa para poder hacer un trabajo profesional.

Espero que les sirva en algo esta experiencia. Al menos no he perdido aun ningun cliente. Y tenemos mas motivos para ver el codigo con los compañeros para refactorizar, cuando hacen pull request, cuando vemos si la nube de jenkis no esta con truenos jajaja Nos falta un chuck norris al que si le funciona todo.

Feliz Domingo.

Jose

2012/7/29 Carlos Ble <ble.j...@gmail.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.

[Miguel Ángel Fernández]

Me esta pareciendo interesante este hilo, tanto que me ha hecho reflexionar y ver en perspectiva los proyectos en que he participado. Para dar la replica a que TDD cuesta 3x, os cuento mis anecdotal evidences, proyectos en los que participé.

Proyecto #1. 2 meses para construir. Proyecto puro de consultora tradicional, es decir, un papelito firmado con fechas y funcionalidades y un manager a cargo. Equipo de 3 seniors. Resultado: 2 meses de construccion + 1 semana de estabilizacion + 2 semanas de modificaciones + los bugs que van goteando y te sorprenden de vez en cuando.

Proyecto #2. 2 meses para construir. Proyecto para startup, requisitos cambiantes, riesgo tecnológico tirando a alto. Equipo de 3 seniors, sin manager. Resultado: 2 meses de construcción. No hubo periodo de estabilización ni de cambios y no hay bugs tampoco. En este proyecto no solo se aplicó TDD, se aplicó todo el stack ágil de ingenieria y gestión de proyectos. Cierto que los miembros del equipo estaban entrenados en las tecnicas, no estaban en "el valle".
De este caso mi sensación es que a partir de la semana 4, el diseño conseguido con TDD paga hasta un 20% de rendimiento por iteración (¿quiero decir que construimos más software? efectivamente). Como el rendimiento es dificilmente medible esto es solo una sensación. El software es más mantenible conforme pasa el tiempo, al contrario que con el proyecto #1
No medimos la cobertura porque no es una necesidad contractual, pero sospecho que será alta.

Por último, solo recalcar lo que anota Alfredo: "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."
Mi opinión es que hacer una comparación objetiva es imposible, nunca se realizará el mismo proyecto, con las mismas personas y bajo las mismas condiciones, solo cambiando que hay que hacer tal o cual práctica, así que dejemonos de dar crédito a las métricas porque todas mienten.



Un saludo a todos!

 



El sábado, 28 de julio de 2012 22:51:10 UTC+2, alfredo casado escribió:

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.

http://mattberther.com/2004/04/19/tdd-metrics 

Y una bastante más completa y compleja:

http://www.rodhilton.com/files/tdd_thesis.pdf 

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

[Omar del Valle]

Yo creo que el "problema" de TDD radica en el tiempo que ocupan los test al inicio del desarrollo. Este tiempo da la sensación de que el proyecto se demora más porque al inicio cuesta mostrar resultados.

 

Si nos imaginamos dos gráficas de desarrollo (Y) contra tiempo (X), una con TDD y otra sin TDD, en la primera tendríamos una curva ascendente de froma brusca en desarrollo contra tiempo, pero esta curva siempre tiene un límite superior en el tiempo, por lo que a partir de ahí los desarrollos disminuyen tendiendo casi a 0 mientras se avanza en el tiempo.

 

En la segunda gráfica tendríamos la misma curva ascendente pero menos prolongada, por lo que da la sensación de que se trabaja más rápido. El problema aquí es que no existe un límite superior por lo que la curva se hace mayor a medida que avanza el tiempo.

 

A un cliente le explicas esto y posiblemente ni te responda :-( El solo quiere ver resultados y tú con TDD "no" se los puedes dar de manera inmediata.

 

¿Soluciones?

 

Rapid prototype, sprints cortos... Separar el diseño de la lógica es un factor importante. Puedes mostrarle cosas al cliente en muy corto espacio de tiempo aunque no estén atados a lógica alguna. Mientras se hace esto, se va desarrollando toda la lógica de la aplicación usando TDD. A medida que avance el proyecto empiezas a unir User Interface con casos de uso y tienes prototipos con tiempos de desarrollos muy cortos.

 

Esta es mi opinión, y se basa en los desarrollos realizados hasta ahora...

 

Salu2

 

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/-/N2DyPEasDOYJ.

[Masa K Maeda]

Es importante tomar en cuenta que debemos modificar la manera en la que medimos y también lo que medimos.

Si bien es cierto que TDD incrementa el tiempo total de desarrollo se obtiene un beneficio económico con respecto a la alternativa de pruebas reactivas.

• El tiempo y costo de pruebas reactivas y de identificación/corrección de defectos es mucho mas alto que el tiempo extra requerido por TDD
• La calidad de la característica implementa se incrementa significativamente no tan solo por el hecho de hacer pruebas de manera proactiva sino también porque al hacer eso el desarrollador obtiene un mejor y mayor entendimiento de la característica misma
• La productiviad del equipo de prueba se incrementa porque se pueden enfocar mejor en las pruebas que tienen que ver con el complemento del conjunto de pruebas con respecto a unit testing. Es decir, TDD se enfoca en las pruebas funcionales positivas de la característica mientras que las pruebas del equipo de testing hace pruebas negativas, de frontera, ejecución, seguridad, compatibilidad, etc. 
• TDD reduce en mucho hacer multitareas, lo cual es un gran consumidor de tiempo que también afecta calidad
• El costo de integración continua se reduce pues los estados amarillos y rojos son menos frecuentes

Existen otros argumentos pero espero que esto haga claro que lo que hay que medir no es tan solo la economía de la fase de desarrollo sino la economía de todo el sistema para ver el gran beneficio que TDD ofrece.

Saludos

Masa K Maeda