Cierre de cuatrimestre en UNQ (2014-2)

Un nuevo cuatrimestre ha pasado y seguimos batiendo records, este cuatrimestre tuvimos 15 alumnos. Lamentablemente no todos aprobaron, en concreto tuvimos:

  • 11 aprobados
  • 2 abandonos
  • 1 desaprobado
  • 1 pendiente de aprobación

Otra novedad de este cuatrimestre fue la incorporación como colaboradora de Ingrid Calderón, una ex-alumna de la materia.

Básicamente mantuvimos la misma estructura y dinámicas que el cuatrimestre anterior con la incorporación de algunas innovaciones y mejoras surgidas de la retrospectiva del primer cuatrimestre. Entre las innovaciones, incorporamos en forma temprana mini TPs que denominamos Katas y que tenían como objetivo:

  • que los alumnos se familiarizaran con ciertas herramientas (ruby, rspec, cucumber, etc) y técnicas (tdd y bdd)
  • que se habituaran a estimar y planificar tareas
  • que se acostumbren a dar visibilidad sobre todo en caso de no poder cumplir con fechas comprometidas

En cuanto a los TPs, mantuvimos la misma estrategia (equipos de 3 personas trabajando sobre aplicaciones Ruby/Padrino) pero con una pequeña innovación: la formación de los equipos estuvo condicionada por el desempeño de los alumnos al momento de inicio del TP. O sea, si un alumno no habia completado todas las tareas anteriores al momento de inicio del TP, entonces no podía conformar equipo con alguien que sí las había completado. La motivación detrás de esto es: dado que las tareas son relativamente simples, quien no las completa es en general por falta de compromiso/interés en la materia, entonces procuramos que todos los equipos cuenten con gente con el mismo nivel de compromiso/interés.

En cuanto a visitas de la industria, este cuatrimestre tuvimos a:

Al igual que el cuatrimestre pasado hicimos una encuesta complementaria a la retrospectiva y según la misma, la evaluación general de la materia por parte de los alumnos fue de 8,8.

De la retrospectiva y la encuesta destacamos algunos puntos en los que trabajaremos el cuatrimestre próximo:

  • Explicar desde el comienzo los criterios de evaluación de la materia y del TP final
  • Reorganizar las katas de forma de incluir alguna con Padrino y Travis
  • Hacer más prácticas de programación en clase (dojos)
  • Publicar todos los recursos técnicos de forma temprana para que cada uno pueda organizarse mejor (en general los punblicamos a medida que vamos avanzando en la materia).
  • Reevaluar la estrategia para la formación de equipo para el TP final

unq_2014_2

Finalmente, este cuatrimestre les pedimos a los alumnos que graben una breve demo de las aplicaciones desarrolladas:

Tenemos un video más pero al no estar publicado en YouTuve no he logrado embeberlo aquí.

ASSE 2014, ya casi estamos

El programa del simposio ya está listo. Por un lado tendremos las actividades tradicionales del simposio: presentación de trabajos y conferencistas y por otro lado tendremos algunas actividades nuevas.

En lo que respecta a presentación de trabajos, tendremos 19 presentaciones de trabajos originales y 8 comunicaciones orales de trabajos que han sido presentados en otros simposios internacionales.

En lo que respecta a las conferencias tendremos 2 de sponsors (Red Hat y Pragma) y 3 más de invitados especiales. En este sentido contaremos con Esteban Feuerstein (Fund. Sadosky) quien hablará sobre Big Data, Alvaro Ruiz de Mendarozqueta y Juan Gabardini quienes hablarán sobre Métodos ágiles. La descripción de estas conferencias está publicada en la página del simposio.

Adicionalmente a la clásicas actividades mencionadas, tendremos dos novedades.

La primer novedad es un taller de Arquitectura emergente dictado por Diego Fontdevila (requiere inscripción aparte pues tiene cupos limitados). Pueden encontrar más detalles de este taller aquí.

La segunda novedad es un espacio de debate sobre Enseñanza de la ingeniería de software. Este espacio tendrá lugar el Jueves 4 de Septiembre a partir de las 16.30 hs. La dinámica de este espacio estará dividida en dos actividades y Luciana y yo seremos los facilitadores. En primer lugar tendremos sesiones en formato Lightning talks, la idea es que cada participante que lo desee pueda presentar en 5 minutos su enfoque para la enseñanza de ingeniería de software y las dificultades que suele afrontar (puede que el tiempo de presentación varie un poquito dependendiendo de la cantidad de interesados en presentar). Luego de estas presentaciones, pasaremos a un debate con formato Fishbowl.

El detalle completo del programa está disponible en la página del evento.

Software Engineer in Test

Uno de los libros que leí este verano fue “How Google Test Software“, el cual describe entre otras cosas la estructura de equipo y roles usada por Google. Entre los roles mencionados hay 3 que captaron principalmente mi atención.

Software Engineer, también llamado en el libro feature developer, es quien construye la funcionalidad deseada por el usuario. Escribe el código de las funcionalidad junto con sus correspondientes pruebas unitarias.

Test Engineer, también llamado en el libro user developer, es el responsable desde la perspectiva del usuario de todas aquellas cuestiones relacionadas a la calidad. Se encarga de la automatización de los escenarios del uso.

Software Engineer in Test, también llamado en el libro test developer, es el responsable de asistir al Software Engineer en la escritura de los test proveyendo herramientas y frameworks de soporte que faciliten la escritura de los mismos y permitan cumplir con las diversas cuestiones de calidad.

Por si la descripción de los roles no es clara: el software engineer es responsable de construir las  funcionalidades y probarlas, el Software Engineer in Test, lo ayuda en estas tareas proveyendo herramientas y incluso escribiendo algunos tests más grandes (no unitarios). El Test Engineer prueba las funcionalidades desde una óptica más general, viendo más el bosque (sistema como un todo) que el árbol (funcionalidades particulares).

Es este último rol, Software Engineer in Test, el que más llamó mi atención, creo que en parte por el hecho de que me gustaría contar con alguien así cuando me desempeño como Software Engineer/Feature developer.

Casualmente por esas vueltas que tiene la vida, la semana pasada empecé a trabajar en un nuevo proyecto ocupando un rol que bien podría definir como Software Engineer in Test. En el proyecto hay un conjunto de analistas que escriben/describen/especifican la funcionalidad del sistema utilizanzo lenguaje Gherkin y yo me encargo de escribir el denominado “glue code” para que esas descripciones/especificaciones pueden ejecutarse de forma automatizada. Para esto básicamente escribo código Java usando Cucumber-JVM. Dado que estoy trabajando part-time en este proyecto, aún es muy poco lo que he hecho, pero estoy muy entusiasmado.

Cierro este artículo con una de las frases que más me gustó del libro:

“Test is just another feature of the application, and SETs are the owner of the testing feature.”

 

ASSE 2014: Simposio Argentino de Ingeniería de Software

Este tradicional simposio que forma parte de las Jornadas Argentinas de Informática organizadas por SADIO se llevará a cabo este año en las instalaciones de la Universidad de Palermo, los días 4 y 5 de Septiembre.

Los chairs de esta edición del simposio somos Luciana Roldán y quien escribe. Luciana es investigadora del CONICET  y docente de UTN Santa Fe y en lo que a mi respecta, fui invitado por ser miembro de la División Ágiles de SADIO.

Esta semana abrimos la convocatoria para la presentación de trabajos y estamos trabajando activamente en su difusión. Pueden encontrar información más detallada en la página del simposio.

Un defecto en producción, ¿que harías tu?

A partir de ciertos problemas de calidad en sus aplicaciones, al área de sistemas de una organización decide invertir en la adopción de ciertas prácticas. Trabaja durante un año adoptando prácticas y principios tales como integración continua, control de configuración, mejora continua, planificación adaptativa, automatización de pruebas, etc. Todo esto a la par de un cambio en el proceso de desarrollo y despliegue de las aplicaciones.

Luego de un arduo trabajo de un año todos los equipos de desarrollo de la organización han adoptado (en mayor o menor medida) la nueva forma de trabajo y las prácticas asociadas.

Un día llega un defecto crítico a producción: ¿qué es lo que debería hacerse?

  • Opción A: arreglar el defecto y ya, no importa el proceso ni las prácticas
  • Opción B: seguir el procedimiento correspondiente para este tipo de situaciones.
  • Opción C:  intentar seguir el correspondiente procedimiento pero si este retrasa/dificulta la solución del problema, intentar una solución sin apartarse de los principios que se han venido trabajando y revisando/ajustando el procedimiento una vez resuelto el problema.

¿que opinas tu?

Cliente no es un buen término

Es común al trabajar en proyectos hablar de “el cliente” como un rol. Yo mismo lo hago todo el tiempo, pero no me parece apropiado y tengo algunos argumentos al respecto.

Desde el punto de vista humano me parece muy frió: “el cliente y el proveedor”, siento que genera un división muy fuerte y que en cierto modo denota un conflicto de intereses. Personalmente me  gusta ver a mis clientes como socios, pues al fin y al cabo ambos sabemos que para lograr un proyecto realmente exitoso tenemos que lograr una situación ganar-ganar.

Desde el punto de vista técnico el término cliente me resulta ambiguo. ¿quien es el cliente? ¿es quien paga por el proyecto? ¿o es quien conoce los detalles de la problemática a resolver?  Para evitar este tipo de ambigüedades es que prefiero utilizar otros términos más específicos, sobre todo al comienzo de los proyecto para dejar bien en claro las responsabilidades de cada involucrado.

En primer lugar todo proyecto tiene un sponsor que es quien está pagando por el proyecto y que también suele representar la parte política del proyecto frente al resto de la organización.

Por otro lado tenemos al experto de negocio que es quien tiene el conocimiento de la problemática a resolver.

Finalmente tenemos al usuario que es quien utilizará la solución de software provista.

Puede que estos tres roles terminen ocupados por la misma persona o no, eso suele depender del contexto del proyecto. En mi experiencia, en organizaciones grandes es muy común que estos roles sean ocupados por distintas personas. Tomando como ejemplo el caso de la petrolera que compartí hace un tiempo, el gerente general ocupaba el rol de sponsor, el responsable de compras era el experto de negocio y los analistas del área de compras eran los usuarios.

Cierre de cuatrimestre en UNQ, cuarta promoción

Terminó el cuatrimestre y se fue la cuarta promoción de Elementos de Ingeniería de software desde que la materia está a mi cargo. Este cuatrimestre la materia tuvo un enfoque mucho más práctico. El primer mes de clase fue más o menos igual que siempre, pero luego nos fuimos enfocando mucho más en cuestiones cercanas al código. Para ello trabajamos con Ruby+Padrino, GitHub, Travis y Heroku. Lás últimas 5 semanas los alumnos trabajaron en grupo en el desarrollo de distintas aplicaciones. La aplicaciones en sí no fueron más que una excusa para poner en práctica los temas de ingeniería abordados durante la materia: estimación, planificación, comunicación, gestión de alcance y cambios, etc, etc.

Otro cambio que tuvimos este cuatrimestre fue que usamos un sitio basado en Jekill para llevar la bitácora de clase.

Para cerrar la materia cada grupo de alumnos grabó un screencast contando el trabajo realizado, les dejo los links a los videos:

Al igual que el cuatrimestre pasado, conté con la colaboración de Natalia, una ex-alumna de la materia (¡gracias Nati!)

Algunos números frios:

  • Alumnos anotados: 10
  • Alumnos aprobados: 8 (2 alumnos abandonaron la materia en el primer mes de clase)
  • Nota final promedio: 8,25
  • Fueron un total de 28 clases
  • Tuvimos otra vez la visita de un profesional de la industria (¡gracias Emilio!)

Estoy muy contento con como salió la materia y según lo hablado en la restrospectiva, los alumnos también quedaron contentos. Una cosa en particular que me puso muy contento, es que logré mejorar la forma en que doy feedback, algo que había salido de la restrospectiva anterior.

eis2013-1

Nota: el ícono representa un alumno que estuvo ausente el día de la retrospectiva.

eis-2013-1b

Cierre de cuatrimestre en UNQ, tercera promoción

El lunes pasado tuvimos la última clase de Elementos de Ingeniería de Software la cual como de costumbre estuvo dedicada a la retrospectiva. Pero antes de entrar en las conclusiones de la retrospectiva, les comparto algunos números:

  • Alumnos anotados: 8
  • Alumnos aprobados: 7
  • Alumnos pendientes de aprobación: 1
  • Nota final promedio: 8,14
  • Fueron un total de 27 clases
  • Tuvimos la visita de un profesional de la industria (¡gracias Emilio!)
  • Trabajamos exhaustivamente con Ruby, Sinatra y Cucumber
  • Desarrollamos varias aplicaciones, las cuales publicamos en heroku y algunas incluso con dominio propio

Personalmente estoy muy conforme con como resultó el curso. A diferencia de cuatrimestres anteriores, puse mucho menos foco en cuestiones de arquitectura/diseño y más énfasis en cuestiones de análisis y especificación (Visual Story Mapping, BDD, etc).

 Respecto de la retrospectiva, los puntos destacados fueron:
  • Mantener:
    • Dinámica de las clases
    • Lecturas
    • Resumenes
    • Herramientas
    • Invitados
    • Clase remota
  • Probar/incrementar:
    • Actividades de relación previas al comienzo de la clase
    • Clases al aire libre
  • Mejorar:
    • La forma de feedback >> Action Item: ser más explicíto al setear expectativas de los entregables y ser  más cuidados con el tono

Para cerrar el post, quiero agradecer a Natalia, una ex-alumna de la materia que colaboró conmigo durante todo el cuatrimestre.

unq-promocion3

Nota: el ícono representa una alumna que estuvo ausente el día de la retrospectiva.

 

Mi enfoque hacia la arquitectura de software

Cuando me tocó estudiar este tema formalmente como alumno, recuerdo que lo hice desde la perspectiva del proceso unificado. Luego por iniciativa propia estudié el tema desde otras perspectivas/fuentes. Pero creo que lo que realmente me hizo entender el tema fue poner manos a la obra. Con esto en mente, hace unos dias me senté a preparar mis clases sobre este tema para mi materia de UNQ. Revisé algunas fuentes tradicionales, notas personales  y algunas fuentes más recientes y pensé algunos ejercicios para hacer con lo alumnos de cara a intentar bajar a concreto algunas cosas que pueden llegar a resultar abstractas.

Como mencioné en un post anterior, decidí encarar el tema presentando un problema, el cual nos fue guiando por los atributos de calidad hacia la arquitectura como disciplina. Luego en una segunda clase, vimos algunas definiciones formales y estilos de arquitectura con algunos ejemplos concretos razonando sobre código las implicancias de cada estilo. La tercer clase la decicamos a ver algunas técnicas concretas para atacar la definición de arquitectura de una aplicación. Finalmente en una cuarta clase, los alumnos realizaron presentaciones de ciertos estilos de arquitectura utilizando el mismo enfoque que habiamos utilizando previamente para presentar otros estilos.

Como material de estudio complementario a lo visto en clase elegí:

En algunas clases posteriores volveremos sobre algunas temas de arquitectura (por ejemplo para analizarla en el contexto de distintas metodologias de desarrollo), pero ya como cuestión colateral y no como tema central de una clase.

Nueva edición del curso de Ingeniería de Software de Berkeley

Hoy comienza una nueva edición del curso  online de Berkely sobre el que estuve escribiendo tiempo atras: Software Engineering for Software as a Service. En esta ocasiónvoy a ser parte del staff del curso: puntualmente voy a estar colaborando en los foros y en el armado de los exámenes. Para esta nueva edición hay varias mejoras: nuevos videos, más ejercicios y bug fixes entre otros.
Los interesados pueden inscribirse gratuitamente en https://class.coursera.org/saas.