Etiquetado: Ingeniería de software

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.

 

Algunos números sobre el curso de Ingeniería de Software de Berkeley

Ayer recibí el mail con el certificado de haber completado el curso y junto con ello, algunos datos interesantes.

  • Unos 20 mil estudiantes vieron al menos una de las clases.
  • Unos 10 mil estudiantes intentaron resulver al menos un questionario o uno de los ejericios.
  • Unos 3 mil quinientos estudiantes completaron el curso.

El curso se repetirá hacia mediados de mayo y una segunda parte  cubriendo Rails avanzado, trabajo en equipos, código légacy, performance y seguridad será ofrecida hacia finales de octubre.

Sobre el curso de Ingeniería de Software de Berkeley

Hace un tiempo comenté que estaba tomando un curso online de la Universidad de Berkeley ofrecido en la plataforma online de la Universidad de Standford. Ayer rendí el último examen y lo completé.

El curso me gustó, aprendí algunas cosas y reforcé otras, pero debo decir que esperaba algo distinto. El título del curso era “Software Engineering for SaaS” , pero de SaaS se vió muy poco. Respecto a esto algunos alumnos opinaban que el hecho de usar Ruby/Rails ya cumplia con el contenido de SaaS. Yo personalmente no comparto, creo que Ruby/Rails es un solo un framework, muy productivo sin duda, pero que implementa patrones que han estado en uso por varios años como MVC y Active Record y que pueden o no usarse para hacer aplicaciones SaaS. Al mismo tiempo, temas como escalabilidad, que resultan muy relevantes en aplicaciones SaaS, apenas fueron mencionados.

Más allá de los contenidos, me gustó mucho la dinámica y tengo ganas de hacer algo similar ofreciendo parte del contenido de la materia que estoy dictando en UNQ.