Etiqueta: agile

Interesante curso de Ingenieria de Software

La semana pasada empecé un curso online ofrecido por la Universidad de Standford en forma gratuita. El nombre del curso es Software Engineering for Software as a Service. El mismo tiene una duración de 5 semanas y es dictado por dos profesores de Berkeley: Armando Fox y Dave Patterson. El curso tiene foco en métodos agiles y la parte técnica está basada en Ruby on Rails.

La dinámica del curso consiste en clases teóricas en formato de video de 10 minutos de duración en promedio.  Al mismo tiempo hay un libro (pago, cuesta unos 10 dólares) escrito por los profesores del curso. La plataforma onlien también cuenta varios foros de discusión. En cuanto al aspecto práctico, hay 4 tareas de programación con un timeframe de 1 semana y por otro lado tambien hay 3 Quiz a lo largo de todo el curso.Según los profesores, alumnos anteriores han reportado una carga de trabajo semanal de entre 5 y 10 horas para completar el curso.

Luego de completar la primer semana, estoy muy entusiasmado, hasta el momento nada nuevo para mi, pero a pesar de ello me gusta la forma en que estan presentados los temas.

No estoy seguro si aún es posible sumarse al curso, pero de todas formas los video son de acceso público.

Les dejo el link al curso: https://www.coursera.org/saas.

¡Que lo disfruten!

Agilistas: BASTA de tomarle la leche al gato

Hoy comencé a tomar un curso sobre ingeniería de software y una vez más me encontré con Agile vs. Waterfall. Basta por favor, como dice El Diego esto es como tomarle la leche al gato o robarle la limosna al ciego. Ojo, hacer la comparacion no está mal, lo que me parece mal es que se pretenda explicar agile comparandolo contra waterfall. Y le pegan a waterfall, una y otra vez y otra vez. ¿Porque no hacer una comparación de Agile vs Métodos orientados al plan? ¿Será que la gente aún no lo tiene claro? No sé, no entiendo, pero a esta altura escuchar gente hablando mal de waterfall me empieza a sonar molesto.

Hago un pedido a los agilista: por favor, cuando quieran presentar agile busquen algún otro mecanismo que no sea pegarle a waterfall.

¿Y si tu sueldo dependiera de la cobertura de tu código?

Definitivamente algunos meses habría pasado hambre  y  creo que algunos otros no habrían cobrado ni un solo peso, ja!

Más allá de lo chistoso (o lo triste) del título, este post es una continuación  de otro que escribí hace un par de dias sobre esta misma temática. En dicho post compartí algo de teoría junto con algunos links interesantes (el de artículo de Marrick es excelente) y en los cuales he encontrado justificación para algunas de las ideas que compartiré a continuación. Durante las últimas semanas he estado dedicando la mitad de mi tiempo en entrenar gente y la otra mitad al desarrollo de una aplicación y en ambos casos he puesto bastante foco en el tema de la cobertura de código lo cual me ha llevado a una reflexión profunda sobre el tema.

Si desarrollamos nuestra aplicación siguiendo un enfoque TDD extremo, siempre mantendremos un alto grado de cobertura, pues solo agregaremos código cuando haya una prueba que lo ejercite.

Si procuramos seguir las buenas prácticas de diseño la relación entre nuestros componentes será por medio de interfaces, lo cual nos permitirá utilizar mocking y asi superar la infantil excusa «No lo puedo testear porque tiene dependencias».

Si nuestros métodos son cohesivos y hacen usa sola cosa, entonces será más simple testearlos.

Si hechamos mano del polimorfirmo, seguramente podamos evitar algunos «if» en nuestro código lo cual también ayudará con la cobertura.

Para cerrar este post, les comparto una situación que viví hace unos dias. Resulta que una de las personas que estuve capacitando durante la semana pasada hizo una demo de la aplicación que desarrolló como parte de la capacitación. La demo venia bien y en un momento le pedimos que mostrara una funcionalidad particular que no habia sido mostrada. Resulta que cuando la va a mostrar, la aplicación ¡pincha!, ja!  a lo que le pregunto: ¿y los tests? adivinen….no había tests para esa funcionalidad. Y cuando pregunto por el porcentaje de cobertura de la aplicación, resulta que no superaba el 40%. ¡Que mejor forma de ilustrar la importancia de estas cuestiones! Espero que este colega haya aprendido la lección.

Por último quiero agradecer a David Frassoni quien la semana pasada me dió la idea de escribir este post.

El siguiente post de esta serie lo dedicaré a analizar las implicancias/consecuencias de tener una alta cobertura y de definir un shipping criteria en base al mismo.

Continuará…

Code Coverage

Durante las últimas semanas he estado dedicando la mitad de mi tiempo en entrenar gente y la otra mitad al desarrollo de una aplicación y en ambos casos he puesto bastante foco en la cobertura de código. Esto me ha motivado a compartir algunas ideas sobre este tema y para setear el contexto y las expectativas, voy comenzar este post compartiendo algunos conceptos básicos y luego en otro post voy a volcar algunas ideas/experiencias personales.

¿Qué es la cobertura de código?

La cobertura código es la cantidad de código (medida porcentualmente) que está siento cubierto por las pruebas. O sea, ejecuto las pruebas de mi aplicación y si hay alguna línea de mi código que nunca fue ejecutada en el contexto de las pruebas, entonces dicha línea no está cubierta. Si mi código consta te 100 líneas y solo 50 líneas están siendo ejecutadas al correr las pruebas, entonces mi cobertura es del 50%. La pregunta que viene a continuación es:

¿Qué beneficio tiene medir la cobertura? y más específicamente ¿que beneficios tiene tener una alta cobertura?.

Una respuesta genérica podría ser que aumenta la calidad de mi aplicación. Siendo más concreto podría decir que si tengo una alta cobertura, significa que gran parte me mi código está siendo probado y por consiguiente podria tener cierta certeza sobre el correcto funcionamiento de mi aplicación. Al mismo tiempo medir la cobertura podria ayudarme a detectar código innecesario en mi aplicación, ya que no se ejecuta.

La pregunta que surge a continuación es:

¿Qué porcentaje de cobertura es suficiente?

La respuesta no es única, existen distintos criterios y pueden resultar bastante polémicos por eso voy a tratarlos en otro post. Pero por ahora solo diré que para SimpleCov, lo idea es de al menos 90% y en Southworks soliamos perseguir el 80%.

¿Una cobertura del 100% asegura que mi código no tiene bugs?

De ninguna manera, una cobertura del 100% solo nos dice que todo nuestro código está siendo cubierto por pruebas, pero puede que las pruebas no esten contemplando algunas situaciones, o sea, me falta pruebas.

¿Qué necesito para poder medir la cobertura?

En primer lugar  es necesario escribir pruebas y en segundo lugar contar con alguna herramienta que permita medir la cobertura.En la actualidad los lenguajes más populares cuentan con herramientas para medir la cobertura. Si trabajamos con C# y escribimos nuestras pruebas con MSTest, entonces el Visual Studio nos ofrece la posibilidad de habilitar la medición de cobertura de código. Si en cambio trabajamos con Ruby, podríamos utilizar RSpec para escribir nuestras pruebas y SimpleCov para medir la cobertura.

Esto es todo por ahora, les algunos links interesantes sobre el tema:

En el siguiente post voy hacer algunos comentarios sobre estos artículos.

Recta final del 2011

He estado ausente mucho más de lo que me gusta, pero han sido unas semanas muy movidas. La recta final de año siempre me tiene bastante atareado. Ya pasó la Smalltalks, la jornada de arquitectura organizada por el MUG, la RubyConf  y Expoeva, con lo cual, en lo referente a eventos, ya queda poco y nada.

Personalmente, en mi agenda solo figuran estos items:

  1. En primer lugar, el encuentro de la comunidad agiles@baires del próximo martes 15, en el cual DiegoF va a facilitar una sesión titulada: «Ecosistemas Sociotécnicos: Idilios y desencuentros entre arquitecturas y organizaciones», ¡fua! ¡que título!, suena muy prometedor.
  2. Los 5K por la industria nacional, una carrera de 5 kilómetros organizada por la secretaría de extensión de Fiuba y que se realizará el próximo 20 de noviembre. Puede que 5K parezcan poco, pero no olviden que si bien la convocatoria es abierta, el grueso de los participantes es de la comunidad de ingenieros.
  3. En segundo lugar un Open Space, también en Buenos Aires, con la idea de repasar algunas de las sesiones de Agiles2011. Si bien no está confirmada la fecha, todo parece indicar que se realizaría el 16 de diciembre.

Ya en un ámbito más privado, tengo pendientes el trabajo final de psicología cognitiva, el evento de fin de año de Southworks, el cierre de Ing-Soft, Algo3,  Tda1 y la definición del campeonato de Viva Plomer.

Movidito se viene el fin de año.

Práctica de estimación en UNQ

(parte 5 de la serie: Ingeniería de Software en UNQ)

El jueves pasado en Ing. Soft, hicimos un ejercicio de estimación basado en la dinámica de fábrica de aviones (no voy a entrar en como es la dinámica pues si un futuro alumno lo lee, va a perder «punch»). Hicimos 3 iteraciones y en la última metimos algunas variaciones (rotación de gente, nuevos requerimientos, etc) para representar algunas situaciones comunes proyectos reales.
Creo que todos nos divertimos y me parece que algo aprendieron. De todas formas, estimación es un tema que vamos a seguir trabajando. Les dejo algunas fotos de la actividad.

Agiles 2011: Colaboración Académica Internacional

Esta fue una de las sesiones que propuse en el Open Space de Agiles 2011 y aquí voy intentar resumir en un par de líneas lo que se habló en dicha sesión.

Yo dicto Ingeniería de Software en la Universidad Nacional de Quilmes (Argentina) y la propuesta de esta sesión surgió a partir de una necesidad mía en dicho contexto. Dado que el trabajo en equipos distribuidos es algo cada vez más común, me parece importante que mis alumnos realicen una experiencia de desarrollo distribuido durante mi materia. Para eso pensé que sería interesante hacerlo trabajando en conjunto con alumnos de otras instituciones. Las formas de colaboración pueden ser diversas pero es un punto que no voy a desarrollar ahora.

Hablando de la sesión, la misma comenzó con la introducción del párrafo anterior y luego sentados en ronda nos fuimos presentando.

Luego de la presentación quedó evidencia que algunos de los asistentes se habían acercado con una inquietud diferente a la planteada por mí, que era “Cómo enseñar métodos ágiles en ámbitos académicos”. Es por esto dividimos la sesión en dos sub sesiones: una (sub)sesión centrada en mi planteo inicial y otra centrada en “Cómo enseñar métodos ágiles en ámbitos académicos”.

Al mismo tiempo en la (sub) sesión de colaboración (la planteada originalmente) surgieron tres formas distintas de posible colaboración:

  1. En el contexto de un semestre alumnos de dos (o más) instituciones trabajan en el desarrollo de proyecto que comienza y termina dentro de un semestre.
  2. En el contexto de trabajos finales de carrera (o tesis) alumnos de una institución co-dirigidos por un docente de otra institución. O bien alumnos de distintas instituciones trabajando juntos en un trabajo final.
  3. Alumnos de distintas instituciones trabajando en el desarrollo de un sistema “grande” a lo largo de varios cuatrimestres, implementando en cada materia un par de funcionalidades por cuatrimestre.

En particular (3) absolutamente integrable con (1) y (2) y tal vez sea la más simple de implementar.

Respecto a la otra (sub) sesión, desconozco como se desarrolló, pero me consta de varios casos, yo mismo sin ir más lejos estoy enseño métodos ágiles, pero cómo lo hago será tema de otro post.

Ya mandé un mail a todos los participantes de la reunión, ahora veremos cómo gira la rueda.

Agiles 2011: día 3

Este día fue para muchos lo mejor de la conferencia. A excepción del keynote final, todo le día fue en formato open space, lo cual fue todo un desafío debido a la gran cantidad de participantes. La facilitación estuvo a cargo de DiegoF e Ingrid. Durante el marketplace hubo más de 50 propuestas, pero creo que finalmente solo se realizaron unas 30.

Yo hice dos propuestas y ambas fueron votadas.

La primera fue sobre Colaboración académica internacional. La cuestión es que tenia la intención de contactar con docentes de otras univesidades/países que estuvieran dictando materias relacionadas a ingeniería de software para ver de hacer trabajos prácticos con forma colaborativa entre mis alumnos y los suyos de cara a que los alumnos puedan experimentar el trabajo en equipos distribuidos. Hubo alrededor de 25 personas de Argentina, Chile y Perú. Me gustó como salió la sesión y me quedé con muchos contactos (aún tengo pendiente enviarlos a todos los participantes de la sesión).

La segunda sesión fue «Show me your practice», que en realidad en el momento que la presenté le dí otro nombre menos cool. La idea era compartir prácticas no tradicionales de trabajo. La sesión fue en formato Lightening talks. Al comenzar la sesión tomamos nota de todos los presentes interesados en compartir sus prácticas. Luego dividimos el tiempo restante de la sesión por la cantidad de interesados y asignamos un tiempo time-boxed a cada uno que terminó siendo de 6 minutos si mal no recuerdo. Algunas de las prácticas fueron posteadas en twiteer, las pueden encontrar buscando por #showmeyourpractice. En un post futuro, voy a hablar un poco más sobre estas prácticas.

Por la tarde participé de una sesión propuesta por JuanG sobre comunidad ágil, Juan prometió  compartir sus notas así que esten atentos a su blog.

La ultima sesión que participé fue de un muchacho de Version One llamado Mike algo, que trató sobre optimización organizacional y que me pareció muy interesante.

Ya hacia las 5 de la tarde, volvimos al espacio central donde JuanG dío su keynote. Simplemente impecable. No voy a entrar en detalle, pues en breve está disponible la filmación.

Luego del keynote, hubo una breves palabras muy apropiadas de Esteban Di Tada, decano de la facultad de Ingeniería de la UP y finalmente el cierre a cargo de MartinA y Ale Alfonso, presidentes de la conferencia. Como era de esperarse, hubo agredecimientos varios, anuncios parroquiales, la convocatoria a propuesta de ciudades candidatas para la conferencia del próximo año y la invitación a todos los asistentes a participar de la retrospectiva del evento.

El evento terminó con un evento de camaradería en Logia Ortiz en que los sponsors realizaron algunos sorteos. También ahí realizamos la retrospectiva del evento y tuvmios muy buenos resultados.

Aún tengo muchas cosas más por compartir de este evento, pues ha sido muy enriquecedor, con lo cual, les dejo links a algunos álbumes de fotos y les prometo más post hablando sobre la organización de la conferencia y el contenido de las sesiones.

http://digitalleague.com.ar/agiles2011.php

https://picasaweb.google.com/116354004329511510805/Agiles2011Picasa?authkey=Gv1sRgCI7W1rv8xZypCA

https://picasaweb.google.com/106951431145173789918/Agiles2011?authuser=0&feat=directlink

Continuará…

Agiles 2011: día 2

En este segundo día la registración ya fue mucho más liviana y por eso no fue necesaria tanta gente en la mesa de registración.

A nivel de sesiones mi dia comenzó con el keynote de James Shore: Agile, Past and Future. Sin duda la frase de la sesión fue «Agile es como el sexo adolescente, todos hablan de el, pero nadie lo practica«.

La sesión que asistí fue la de Israel: Agile Project chartering…,. El enfoque presentado estaba basado en  técnicas de Sistemas reactivos. Interesante enfoque, tomé nota de algunas cosas para probar.

Ya por la tarde asistí a la sesion Agile Testing – Beyond the Easy Contexts, en la cual no encontré cosas demasiado novedosas y varias de ellas intuitivas en un punto, pero que curiosamente aún no logramos implementar en el lugar que trabajo, ups!. A continuación y en la misma sala, presencié la sesión de Mike Beedle (uno de los autores del manifiesto agile). En primer lugar debo decir que me mató el acento mexicano de Beedle, excelente y muy pegadizo. Durante la sesión Beedle, repasó un poco de historia, contó algunas curiosidades de la mítica reunión del manifesto y compartido algunas lecciones aprendidas a 10 años de la firma manifiesto.

La última sesión que asistí fue Optimizing Organizational / Team Collaboration & Transparency Even With Distributed Teams, la cual fue a mi entender de menor a mayor. Al comienzo, no pintaba para nada prometedora, pero que con el correr del tiempo fue resultando cada vez más interesante a punto tal que he dedico dedicarle un post para explicar algunas de los cosas habladas.

Ya una vez finalizadas la sesiones nos reunimos en el SUM para ajustar algunos detalles pendientes del Open Space de mañana. Personalmente tengo muchas expectativas en el open space, será que luego de haber participado el  varios evento con este formato, estoy convencido que siempre salen sesiones interesantes.

Mi día termino con Esteban, Julian y Jesica en calle Corrientes disfrutando de Stella (Artois), Pizza y Fainá en la tradicional pizzeria «Las Cuartetas«.

Bien amigos, esto es todo por hoy, a dormir.