Practicas tu kungfu? CodeKatas

Los practicantes de kungfu, y los de cualquier actividad física, tienen que entrenar, tienen que repetir las acciones hasta que les salen naturales, sin pensar.

La repetición es uno de los procesos de aprendizaje reconocidos, en base a repetir cierta actividad, el cerebro pasa a responder a la orden de ejecutar esa actividad desde una zona diferente. Es el momento en el que hemos ‘interiorizado’ la actividad y ya no es necesaria una actuación tan consciente para llevarla a cabo.

Este mecanismo de aprendizaje no es exclusivo de las actividades físicas. ¿cómo nos aprendimos las tablas de multiplicar? ¿los axiomas matemáticos? ¿la tabla periódica? ¿las valencias?…  diciéndolo en voz alta, copiándolo en un papel n-veces… en definitiva, repitiéndolo.

Y qué pasa cuando acabamos de repetirlo… que lo olvidamos. Tardamos más, incluso años, para olvidarlo completamente y que el cerebro sobreescriba esa zona. Durante ese tiempo sin práctica, vamos perdiendo fluidez en la actividad. Frases como “el que tuvo retuvo” “vivir de las rentas”… muestran esa misma idea… hay un camino en el monte, pero poco a poco se va tapando y cuanto más tardemos en volver a pasar…más nos costará la vuelta.

¿Recuerdas cuando aprendiste a programar?

Hacíamos itoa y atoi sin inmutarnos, reordenar arrays, fibonacci, las torres de hanoi, algoritmos de ordenación… ¿y ahora? Ahora nos sonreimos porque no nos acordamos y lo buscamos en internet. Porque “ya no hace falta saberse las cosas de memoria” ¿verdad? ]:)

Pero, a que es satisfactorio cuando haces las cosas a la primera? a que cuándo haces una algoritmo algo complicado de los que antes ‘te salian solos’? sonries…  Y nada que decir de esa persona a la que admiramos en este contexto, le salen las líneas solas, ´fluido y encima le compila a la primera.

Todos estamos de acuerdo en que desarrollar tiene su punto de arte, un espacio de creatividad dentro de la ingeniería.

Además de por trabajo, los pintores pintan por hobby, practican sus trazos. Los deportistas también practican, y los cirujanos, los pilotos,… muchos profesionales practican para su profesion. Bien porque la profesión se presta o bien porque les gusta su trabajo 😉

¿Tu practicas tu código?

No me refiero a formar parte de un proyecto Open Source, eso puede indicar un nivel de compromiso que no estamos dispuestos a asumir. Me refiero a practicar por nuestra cuenta, a hacer un fibonacci de vez en cuando…

La mayoría no lo hacemos.

En las artes marciales, para facilitar el aprendizaje y perfeccionamiento los movimientos se agrupan en secuencias. El practicante, en lugar de hacer movimientos aislados, repite las secuencias. Ésto le ayuda a mantener su nivel, perfeccionar y reforzar las conexiones en el cerebro. Dependiendo del arte marcial, estas secuencias tienen un nombre: Katas (Karate), Pumses(Tae-Kwon-do), formas (Kung-fu), etcétera…

Pues bien, hace años (personalmente lo descubrí hace poco)  se creo la figura de los CodeKatas. Ejercicios de complejidad creciente donde podemos practicar nuestro código.

Original. http://codekata.pragprog.com/   Tiene publicados 21 CodeKatas.

Referencia y enlaces extra. http://en.wikipedia.org/wiki/Code_Kata

Siendo una persona a la que me encantan los típicos puzles para programadores,  os podéis imaginar que me encantó la idea. De vez en cuando me hacía un puzle, algo reactivo, normalmente no lo buscaba, me lo encontraba y lo hacía.

Pero la idea de resolver un problema cada cierto tiempo, de practicarlo… nunca lo había contemplado. De hecho, en algunos CodeKatas el reto está en resolverlos de diferentes formas (por ejemplo… nada de if’s) y así darle otra vuelta a la tuerca.

Los codekatas me parecen una muy buena forma tanto de aprender como de perfeccionar y entretenerse. Desde que lo conocí procuro hacer alguno de vez en cuando.

También descubrí que alrededor de los codeKatas se había creado un ecosistema de entusiastas, y algunas actividades/agrupaciones específicas ( con unos nombres horribles ]:) )

CodingDojos: Los dojos son los lugares de aprendizaje en las artes marciales, de modo que el CodingDojo se convierte en el lugar donde se practica en grupo los codekatas. Llamémoslo grupo de usuarios.

Coderetreats: Eventos  prácticos. Tienen unas reglas determinadas, como trabajar en parejas, 0 slides, una experiencia inmersiva (varias horas).

Seguro que me dejo algún otro…

Llámalo kata, dojo, retreat o como te de la gana, pero las ideas que hay detrás son interesantes. Algunas son nuevas, algunas no, pero todas interesantes :)

Empezando a terminar, señalar que la repetición ayuda a aprender/mejorar, pero sobre todo si se acompaña de motivación. La motivación es clave para anclar cuanto antes los movimientos en el cerebro. Pero entiendo que si hacemos un codekata a las tantas al volver de trabajar… será porque estamos motivados, no? porque a nuestra edad …ya es difícil que nos obliguen :)

 

happy hacking

 

~ds

 

PD 01–> Los nombres me parecen una aberración porque he practicado artes marciales y deportes de contacto durante más de 20 años… no me gusta que se reutilicen conceptos, para mi es un mundo muy especial. Pero queése le va a hacer.. codekata… pues codekata :_)

PD10-> oxigeno, azufre, selenio, teluro. Fluor cloro bromo yodo

PD11-> 12 * 12 144 13*13 169 14*14 196 …

PD100-> post 2 días seguidos… estoy in flames! ^^

Si pruebas, repites – unit testing 101

Cuando ejecutamos nuestros desarrollos para ver cómo funcionan, ver si cascan, ver si todo se comporta como se espera, si esa nueva funcionalidad devuelve lo que debe… estamos probando nuestro código.

De hecho solemos ir más alla, porque solemos incluir cierto código de vez en cuando para ver que funciona todo, ¿no?. Podíamos decir que tenemos cierto nivel de automatización.

Por ejemplo, digamos que tengo un método que normaliza un string en base a ciertas reglas a nivel de negocio (referencias, caracteres especiales…) Ya sea en ese proyecto u otro, antes de acabar la aplicación, nos creamos algunas líneas de código para probar el método y ver el resultado en pantalla, así vemos que funciona como debe. En ese momento tenemos una prueba, un elemento que nos puede ayudar a hacer un desarrollo iterativo asegurándonos la consistencia de lo que ya tenemos y avisandonos de si introducimos algún problema… pero LO BORRAMOS!! 

Ahora, si en el futuro incluimos algo de código que rompa esa conversión, tendremos que investigar a ver qué parte se ha roto prácticamente desde cero. Porque con el sistema crecido, puede que no veamos el error de conversión, si no, un fallo en un control de la interfaz, al consumir un servicio web, en un XML… hala… a perder el tiempo :_)

Pruebas de andar por casa, que sirven perfectamente

Imaginad que hubiesemos guardado ese código. Algo simple, olvidad los frameworks de testing y demás vainas. Simplemente añadir un proyecto nuevo a la solución que se llame pruebas. Que tenga una clase con un método que se llame probar y dentro de ese método vamos validando nuestro código…

 

image

Cada vez que vamos generando nuevo código, borrando o refactorizando, ejecutamos ese proyecto para ver si todo lo que funcionaba SIGUE funcionando.

¿No crees que sería una forma ÓPTIMA de desarrollar? dicho de otro modo, ¿no crees que es una forma genial de asegurarnos de que nada nuevo rompe nada de lo que hay hecho? Nos evitaríamos un montón de bugs tontos!! 

En una segunda vuelta, se nos podría ocurrir generar pruebas para asegurar que el código falla cuando tiene que fallar ¿no? Saber qué la aplicación solo se comporta como debe, cuando debe, también es importante. Además de que el hecho de que los errores y las excepciones  sean los esperados en cada caso es importante. También son parte del funcionamiento del sistema y deberíamos asegurarnos de que funcionen cómo y cuando deben :)

Las pruebas no son la bala de plata contra los bugs, por mucho que las hagamos los bugs aparecen, en menor medida, pero aparecen. ¿Qué debemos hacer cuando aparece un bug? Podemos corregirlo sin más, pero para seguir manteniendo la consistencia, lo primero que deberíamos hacer es el test correspondiente al fallo, la prueba que demuestra que es un bug. A partir de ese momento, cuando este corregido, será una prueba más que nos asegura la consistencia del sistema. Tendremos ese escenario y los adyacentes mejor asegurados para el futuro.

Los frameworks de testing

Muchos hacéis las pruebas como hemos dicho en el apartado anterior, es hora de que déis el salto!! Un framework de testing nos ayuda a hacer las pruebas de una forma más sencilla y nos proporciona información sobre el código probado. Por ejemplo, automatiza las llamadas a los métodos de prueba, genera informes de resultados integrados en el propio entorno de desarrollo, dan mayor granularidad porque permiten lanzar solo ciertas pruebas, etcétera…

Hay numerosos frameworks, normalmente, si sabes uno, cambias algo la sintaxis y sabes todos, no hay grandes cambios. Personalmente utilizo el MSTest porque viene integrado con Visual Studio.

Para poner un ejemplo, partiendo de la idea de antes, podríamos agregar un nuevo proyecto de testing a la solución con un código como el siguiente:

 

image

Es prácticamente lo mismo que teníamos, pero con una mejor organización, decorado con atributos y teniendo un informe de resultado de la ejecución de las pruebas cada vez que queramos tener feedback, cosa que habría que ir haciendo cada MUY poco tiempo. Porque cuanto antes descubramos el fallo, más fácil será corregirlo y menos impacto tendremos en el resto del sistema.

 

image

Probar te hará mejor profesional

Sin duda!! El hecho de probar tu código va a requerir que tengas que refactorizar, que simplifiques tus clases para que solo tengan el código que DEBEN tener, que en determinados escenarios aprendas cosas como mocking, la necesidad de la inyección de dependencias y la consecuente mejora en el diseño,… además SOLID, YAGNI y demás acrónimos serán parte de tu vocabulario sin que te des cuenta de ello 😉

 

Cómo empiezo a probar

Una vez estás convencid@ de que probar merece la pena y te ahorra tiempo, lo primero que te recomiendo es que escojas un framework de testing. Si no quieres demasiadas complicaciones al principio, utiliza el que traiga tu entorno de desarrollo por defecto. Según  vayas experimentando y acostumbrándote…prueba otros. Puede que encuentres matices que te resulten más útiles en tu contexto. Lo mismo es aplicable a los mocks… cuando empieces con ellos :)

Aqui te dejo enlaces a los más utilizados aparte del que viene integrado con VS.

Testing: xunit, nunit

Y un enlace a un video (12min) en Channel 9 de mi compañero Aurelio Porras con una intro a testing en Visual Studio 2010.

 

image

 

Happy hacking!

~ds

 

PD –> Frameworks de mocks: moq, rhinomocks, moles

PD2-> Frameworks de inyección de dependencias: Unity, Ninject, Castle Windsor

PD3 –> Una herramienta interesante y relacionada es Microsoft Pex… te genera tests para tu código

PD4 –> Vamos a jugar ^^ …. piensa por un segundo que en lugar de hacer el código y luego probarlo, primero haces la prueba ideal que debería pasar el código cuando funcione… y luego haces el código que haga que la prueba funcione… bienvenido a TDD 😉

El 0 day de asp.net… modo de evitarlo? y referencias

Buenas…

En la ekoparty de Argentina, Juliano Rizzo y Thai Duong, mostraron un 0 day sobre ASP.NET. A quitarse el sombrero.. donde hay talento lo hay… pero.. hay un pero y muy gordo. Me parece aberrante su decisión de hacerlo público en una conferencia sin avisar a la empresa en cuestión previamente y más el entregar algunos pen drives con el código fuente del exploit.

Volviendo al asunto… un 0 day es una vulnerabilidad nueva, nadie teóricamente sabe que existe y no se puede estar preparado para ella.

He estado leyendo bastante sobre cuál es la parte vulnerable y como se explota. Pero por ahora no hay demasiada documentación de este caso en concreto y mucho son conjeturas de expertos en seguridad y expertos en .NET

Por si os interesa leer sobre ello, personalmente las mejores lecturas que he encontrado sobre el tema son:

http://www.reddit.com/r/programming/comments/dfhnz/think_the_aspnet_padding_oracle_exploit_is_no_big/  (Importante leer los comentarios)

http://threatpost.com/en_us/blogs/new-crypto-attack-affects-millions-aspnet-apps-091310?page=1

http://visualstudiomagazine.com/articles/2010/09/14/aspnet-security-hack.aspx

http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf

Y la respuesta de MS a día 19/09

http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

Hay que mirarlo con un poco de ojo crítico… muchas personas opinan sin saber, muchos intentan hacer astillas solo por ser Microsoft, etcétera… no le quito importancia en absoluto. Pero permanezco cauto hasta que encuentre un documento o el código fuente o algo más que opiniones e hilos de discusión.

En resumen… explota una vulnerabilidad relacionada con el algoritmo de cifrado que se utiliza en la autenticación por Forms. Va probando diferentes entradas y detectando la diferencia de respuesta de la aplicación para aprender y finalmente dar con una clave que da acceso.

Hay muchas teorías de que: Habilita Custom errors ya una misma página y ya está… ó  eso pasa por no usar SSL ó que cambies de AES a 3DES ó que si tienes una red mínimamente securizada, va a parecer un DoS y se va a bloquear la IP…  personalmente aún no tengo una opinión 100% formada.

Pero teniendo en cuenta que es un ataque Padding Oracle… se basa en aprender y recabar información en base a respuestas diferentes resultado de peticiones mal formadas. De modo que la recomendación que hace MS Corporación a través del blog de Scottgu, me parece más que razonable… misma página de error para todo, no demos pistas de nada hasta que esto se aclare un poco más y veamos dónde hay que tocar para arreglarlo.

Happy hacking!

~ds

PD –> Las actividades que más me han gustado y atraido de nuestro mundillo son las de la seguridad y el análisis postmortem. De hecho los ratos más satisfactorios desde que tengo un PC siempre los recuerdo en esos ámbitos :)  En seguridad tenía la necesidad de tener que estar siempre al día de todo, tBBDD, fwrks, desarrollo, SO… y además algo de picardía para buscar huecos o hacer algo de ingeniería social. En análisis postmortem tienes que tener muy bien unidos todos los puntos para entender qué esta pasando. Conocer de verdad lo que tienes delante, pq el problema está ahi y sólo dependes de tu capacidad para encontrarlo. Ambas disciplinas me aportaron las mismas sensaciones… la realización cuando das en el clavo y encuentras el hueco, cuando funciona el rootkit o encuentras el problema en el dump.

Ese es el momento álgido y no otro. El momento en el que lo logras. Sonries porque eres un crack, avisas a quién ha hecho el juguete defectuoso y te vas a tomar algo con el resto de geeks con los que currabas en esto.  Personalmente dudo que tirar 4 pendrives en una charla, cargarte el fin de semana de muchos admins/developers, dejar daños colaterales a algunos usuarios y ser el chulo de la conferencia cause el mismo subidón que haberlo logrado. IMHO estas acciónes muestran una absoluta falta de ética.

Hay que organizarse!!

Ya lo decía le chiste… “Hay que organizarse!!”  Y cuanta razón tenía… como no te organices bien….  ^^’

Como muchos sabréis, hay numerosos métodos de organización, productividad personal, seguimiento de proyectos,… que proponen una serie de acciones que ‘se supone’ te hacen ser más productivo. Por mi trabajo o por mi falta de organización, he tenido la oportunidad de experimentar varios de estos métodos y ver como algunos se estrellaban contra la realidad de mi inbox y otros contra mi falta de disciplina. Obviamente no todo ha sido malo, el hecho de experimentar me ha valido  para crear mi propio batiburrillo de técnicas / prácticas que me ayudan para organizarme y no perderme en el día a día.

Quería compartir alguna de estas ‘ayudas’ por si estáis en la misma situación que yo y os pueden servir de referencia.

Proyectos, historias y tareas

He dividido mi trabajo en proyectos ( grandes bloques ), cada uno de estos proyectos en historias ( las diferentes partes del proyecto que tienen que llevarse a cabo ) y cada historia en tareas.

Una tarea es una acción… y como tal, estimo el esfuerzo que me va a requerir ( S, M ó XL ), la prioridad, pongo la fecha límite para empezarla, mantengo actualizado el estado y registro el ‘accountability’ de la acción.

Todo esto lo llevo en una hoja de excel, donde semanalmente decido las tareas a las que me voy a dedicar esa semana. ( pocas de nivel XL, algunas de M y algunas más de S).

Según las voy acabando o van apareciendo, las tareas de la lista cambian dinámicamente. Lo de mirarlas una vez  a la semana es para ver el global, en que proyecto avanzo, en cuales no, los stoppers, etcétera…

Planear el unplanned

Los fuegos y las urgencias son un hecho, hay que acometerlas y resolverlas cuanto antes, en mi caso lo fundamental es… no perder de vista los objetivos iniciales y acordarme de registrar esas acciones unplanned. Así, cuando veo que no he acabado una tarea planeada, al menos tengo la justificación de qué otras cosas han acabado mi tiempo.

Es importane ser realista en cuanto a las acciones que se planean para una semana… miro las reuniones, los compromisos, el volumen de mail, los marrones que sobrevuelan… Prefiero quedarme corto y añadir nuevas tareas que sentir siempre que no acabo nada.

A primera hora… lo que más cuesta

Las 2 o 3 primeras horas del día las dedico a la tarea más importante en base al peso y la por prioridad, cuando puedo uso intervalos de 25 minutos para centrarme (pomodoro) y ser más productivo. Cuando he dedicado ese tiempo, cambio el tercio y me dedico a otras tareas.

Es difícil dedicarte tanto rato a una tarea y normalmente, a no ser que se trabaje desde casa es casi imposible evitar las interrupciones… sobre todo por parte de los perfiles no-técnicos ( hay mucha gente que no entiende porqué los perfiles técnicos podemos necesitar concentración y ratos sin interrupciones )

un segundo, tienes 5 minutos, oye no me funciona nosequé, puedes mirarmelo?…

…intento no desesperarme, hay que vivir con ello, intento emplazar las interrupciones para otro momento, pedir que me lo envien por mail, pero como hemos dicho… plan the unplanned!

El mail, el twitter, … las interrupciones

Cerrado. Lo abro durante 5-10 minutos cada X tiempo y lo vuelvo a cerrar. SI no no avanzo. No se si os pasará, pero personalmente he llegado a un punto en el que se me hace mucho más dificil cerrar el twitter que el mail.

Las reuniones las considero interrupciones. Son necesarias, pero creo que con un tercio de las que tenemos sería suficiente. A las reuniones se llega preparado, con un tema a tratar trabajado previamente, se discute, se toman acciones y vuelta al trabajo. Con ese formato se consideran acciones, si son el tipico rato de 50 minutos donde los participantes miran el mail, no se sabe muy bien que se va a tratar, hay muchos ratos muertos… planteate que igual deberías estar discutiendo en la máquina de café o en la comida en lugar de en una sala de reuiones :)

El inbox … la falsa lista de tareas pendientes

Mis tareas están en el excel, no en el inbox. Ver tanto mail te hace llegar a pensar que tienes que tomar acciones en todo, y nada más lejos de la realidad.

Mi regla de oro… si voy en el To… el correo cambia de color. Si no… en los ratos que abro el mail lo voy procesando. Archivando en carpetas por proyecto, respondiendo lo inmediato o creando una tarea unplanned para lo que me va a llevar más de 2 minutos tiempo.

Luego claro que tengo otras reglas… mails de los managers a una carpeta, del equipo a otro, de las listas de distribución a otra… así de una pasada veo donde tengo acciones pendientes.

 

Personalmente, con estos 4 puntos alcanzo un nivel de productividad con el que me siento contento, me voy a casa satisfecho con el trabajo. Y en cierta manera… se pueden asimilar al desarrollo de software: declara, prioriza, ejecuta, espera el cambio e itera

Happy hacking!

~ds

PD1 –> Al final va a pasar lo mismo con el “things done” que con el “Driven Design”, solo tienes que ponerle una letra cualquiera delante para crear tu marca y diferenciarte :)

madriagil. Quedada 1/9/10. Contratos ágiles y TDD

Hoy ha sido mi segunda quedada en Madriagil ^^^

Parece que todos hemos tenido cierto mono en vacaciones, porque nos hemos juntado unos cuantos más que la última vez ( quedada para refactorizar ). Creo que he contado 19. A través de la lista de correo se había acordado centrar la discusión entorno a dos temas. Contratos ágiles y cómo vender TDD a la gestión/management.  Hemos dedicado X tiempo a cada tema e intentado sacar algunas conclusiones en claro. Voy a hacer un pequeño resumen de lo ocurrido para quién le interese… agradeceré que cualquier asistente me corrija o complemente el resumen con alguna otra observación 😉

He llegado con el tema de los contratos ágiles empezado, de modo que no se como hemos iniciado la discusión…pero ahí algunos puntos donde nos hemos parado y algunas notas que he tomado en torno a ellos… y mi opinión personal e intrasferible.

Contratos ágiles

Partimos de la base de que queremos un contrato ágil y hemos tenido en cuenta las dos orillas del rio. Desde el punto de vista del contratante ¿Cómo podemos tener seguridad de que estamos contratando un equipo ágil? y desde el punto de vista del contratado ¿cómo puedo exponer el valor de mi equipo a través de un contrato?

Para entrar en materia hemos empezado trabajado entorno a una licitación pública de la de la junta de andalucia donde solicitan que el pliego técnico sea realizado empleando SCRUM. Luego hemos coincidido en que el hecho de que sea de la administración hace que gran parte de los beneficios que pueden venir por parte de tener un equipo ágil se pueden perder por la burocracia del trabajo con la administración. Por ejemplo… Si a la segunda iteración, no me gusta la empresa y quiero deshacerme de ese proveedor y contratar otra.. puedo tener una muerte por trámites :)

Talking points:

El pliego tiene techo pero también debería tener suelo. Deberían asegurarse una serie mínima de de iteraciones, si no lo hacemos podríamos encontrarnos en una situación en la que invirtamos en montar/contratar el equipo para el proyecto y se caiga antes de empezar.

¿Cómo comparamos proveedores en una licitación ágil? Obviamente podemos usar un portfolio o experiencias en anteriores proyectos, pero ¿Podemos medir a los proveedores en base a su velocidad? o ¿podemos establecer un estándar de puntos de esfuerzo para todos los proveedores? En MI opinión, estos son medidas PARA el equipo, internas, no creo que valgan en una oferta.  Otra opción era reunirse con los proveedores para que nos propusiesen un release plan y que valorasemos en torno a eso… siempre con cuidado de no caer en un Gannt y perder la agilidad por el camino. Tambien se han planteado las certificaciones… podemos confiar en el nivel de certificación en SCRUM/AGILIDAD del proveedor? o certificarlos nosotros? Si bien es una falsa seguridad, en mi opinión…algo es algo…

¿Es el contrato ágil un nuevo tipo de contrato? La mayoría pensabamos que no… que se puede enmarcar dentro de un modelo tradicional, ya sea de contrato por servicio o por obra.

Todos hemos coincidido en que la naturaleza de un contrato ágil nos debe permitir cambiar de dirección en las iteraciones. Bien  sea para parar, continuar o cambiar de proveedor.

 

TDD

Cuando ha sonado el gong ( a la segunda o tercera vez 😛 ) hemos cambiado de tercio y hemos pasado a ver cómo podíamos vender TDD a la gerencia. Al final nos hemos liado la manta a la cabeza y además de ver como vendérselo a la gerencia, nos hemos autoconvencido, se lo hemos vendido al equipo, entre equipos, hemos discutido de si TDD merece la pena, etcétera… vamos, que nos ha quedado completito el rato dedicado a TDD :)

Cabe destacar que NO todo el mundo de la reunión hace TDD, había personas que lo habían descartado por ahora y preferían quedarse con el enfoque tradicional de testing para sus proyectos. En lo que SI estabamos todos de acuerdo es que HAY QUE PROBAR el código 😉

y OJO que TDD no exime de hacer otras pruebas o de utilizar herramientas como PEX para asegurar la consistencia del código.

Talking Points

Cómo vender el valor de TDD a la gerencia. En realidad hemos visto que la gerencia que tiene un perfil de negocio no es problema. No esta capacitado para tomar esas decisiones y va a tener que fiarse de algún técnico. El problema esta en si TDD afecta demasiado al rendimiento en las fases iniciales y esto impacta a la productividad. Estabamos de acuerdo en que TDD como proceso tiene su tiempo de adopción y su curva deaprendizaje, y una vez implantado, hay que meter tiempo en ello… si un gerente comercial se queja, siempre podemos enseñarle un diagrama donde se vea que el número de bugs disminuye o uno donde se vea que aumenta la cobertura de código.

De acuerdo…cobertura de código no tiene porqué implicar calidad…. pero como hemos dicho antes…algo es algo. Y recordemos que estamos hablando con un gerente comercial.

TDD desde el equipo de desarrollo. Otra posibilidad es que los individuos comiencen a hacer TDD, por su cuenta, sin que tenga que venir impuesto por el gerente. El equipo puede ser el iniciador del cambio. Hemos pensado en algunos motivos que esgrimir cuando queremos convencer a alguien a que haga TDD:

TDD mantiene el diseño a prueba constantemente

TDD nos permite avanzar con seguridad en el contexto de un dominio desconocido

TDD ayuda a detectar antes los posibles fallos

Es más fácil empezar a hacer TDD si hacemos pair programming

TDD es una herramienta efectiva para la gestión del cambio

TDD implica mejorar como desarrollador porque a base de usarlo vas a reconocer patrones, refactorizar, detectar bugs…

TDD es un acto de fé… prueba y verás como te engancha

Cómo empezar con TDD. Una vez el equipo se decide… ¿Cuál es la mejor manera de empezar a hacer TDD? ¿Dónde lo aplicamos? En estos puntos han surgido también varias ideas:

Podemos enfocarlo como diseñar orientado a ejemplos. Escribimos el ejempo de como ha de quedar y luego el código que lo resuelve.

En lugar de empezar directamente con TDD, podemos emprezar con unit testing tradicional y cuando el equipo se sienta cómodo probando y refactorizando…dar el paso de empezar con los tests en lugar de con el código.

Los tests de aceptación pueden ser también un acelerador de la adopción de TDD. Si tenemos requisitos de negocio escritos como pruebas nos va a resultar mucho más natural escribir los requisitos funcionales también como pruebas.

Podemos restringir el uso de TDD a la parte del proyecto que tenga un dominio más desconocido.

 

Conclusión

Al igual que el primer dia, me lo he pasado bien y he aprendido un montón en base a la experiencia del resto de compañeros. Nada de lo que tratamos ni ninguna de las conclusiones en un axioma que nadie deba memorizar. De hecho, reina la divergencia de opiniónes en las reuniones, pero creo que hay temas en los que estamos TODOS de acuerdo. Para mi hoy han sido los beneficios que aporta el trabajo iterativo de los equipos de desarrollo y la importancia de las pruebas a la hora de construir software robusto.

Como he destacado, ninguna de las opiniones es ley, pero si no haces alguna de esas dos cosas tal vez podrías probar… nosotros 19 estábamos de acuerdo en que a nosotros nos funcionan 😉

 

Próxima quedada.

Nos hemos propuesto vernos el 23/9 (lugar por determinar) para hablar sobre:

Mejores prácticas de branching

Cómo repartir tareas dentro de un equipo en SCRUM

Si quieres venirte estate atento a la lista o a la web para cuando anunciemos el sitio.

 

Recursos

Web de madriagil

Madriagil es uno de los grupos de personas interesadas en metodologías ágiles… pero hay más!  Mira en este enlace  http://www.agile-spain.com/ y anímate

 

Happy hacking!!

~ds

PD –> No pongo nombres de los asistentes pq no me los sé todos aun y no quiero poner unos sí y otros no. O todos o ninguno.