Las dos cuestiones más desafiantes del desarrollo de software

Desarrollamos software para aportar valor a un negocio/organización. En ese sentido el desarrollo de software tiene dos cuestiones centrales que son la fuente de sus mayores complejidades: determinar lo que hay que construir y manejar de forma eficiente las necesidades de cambio. Si bien yo he enumerado estos dos temas como cuestiones disjuntas la realidad es que tienen una íntima relación. Determinar lo que hay que construir debe gran parte de su complejidad al hecho de que una vez determinado lo que se debe construir, lo mismo suele cambiar. De todas todas vayamos por parte.

Determinar lo que hay que construir

Este es un tema que se ha tratado bastante, a punto tal que se ha generado un disciplina alrededor del tema: Ingeniería de requerimientos. Hoy por hoy, luego de haber leido, reflexionado y experimentado creo que el tema puede simplificarse a dos escenarios:

1) requerimientos conocidos y estables
2) requerimientos no-conocidos y/o no estables

Nunca en 15 años de trabajo en la industria me encontré con el caso (1), pero curiosamente creo que gran parte de la bibliografía, técnicas y conocimientos de la ingeniería de requerimientos está enfocada en este tipo de escenarios. Se me ocurre que en estos escenarios puede ameritarse hacer un trabajo intenso sobre los requerimientos antes de comenzar con el desarrollo (digo esto sin estar muy convencido).

Todos mis proyectos se enmarcan en escenarios del tipo (2), en algunos casos me ha tocado desarrollar software sin tener requerimientos conocidos, simplemente teniendo una visión y un objetivo de negocio y debiendo “experimentar sobre los requerimientos”. En la gran mayoría de los proyectos en los que he participado me he encontrado con un conjunto de requerimientos cambiantes a satisfacer y ha sido precisamente esa propiedad “cambiante” la fuente de las principales fricciones del proyecto.
Para estos escenarios del tipo 2, no considero que sea útil, ni conveniente realizar un trabajo intenso sobre los requerimientos antes de comenzar el desarrollo. Al contrario, creo que la cuestión pasa por “probar” de una forma sistemática siguiendo 4 premisas:

  • Trabajo iterativo
  • Involucramiento del usuario
  • Entrega frecuente
  • Feedback continuo

Manejar de forma eficiente las necesidades de cambio

A mi parecer este solo punto justifica la gran mayoría de las prácticas técnicas de la ingeniería de software (arquitectura, diseño OO, automatización, integración continua, etc). Si uno tuviera la certeza de poder escribir una pieza de código y nunca más modificarla podría no preocuparse por escribir código claro, mantenible y testeable. Curiosamente creo que en la formación académica se hace foco en la enseñanza de las prácticas técnicas pero sin hacer suficiente foco en el por qué de su importancia. Al construir software buscamos cumplir ciertas propiedades para facilitar la evolución/cambios que el software deberá soportar. El no cumplir con dichas propiedades suele generar diversos tipos de perjuicios para el negocio.

Obviamente más allá de estas dos cuestiones hay otras miles que también son relevantes (trabajo en equipo, planificación, etc), pero a mi parecer estas dos son las que están en los primeros puestos de complejidad.

Reflexiones sobre la Enseñanza de la Ingeniería de software

En mi actividad profesional cotidiana me desempeño como ingeniero de software ocupando distintos roles y realizando distintas tareas dependiendo de las particularidades del proyecto de turno. Por ello cuando en 2011 tomé a mi cargo la materia Elementos de Ingeniería de Software en la Universidad Nacional de Quilmes busqué una dinámica de dictado de la materia que efectivamente pudiera preparar a los alumnos para desempeñarse profesionalmente en esta disciplina.

Personalmente considero que la ingeniería de software es una actividad naturalmente industrial, y en este sentido me parece fundamental que su enseñanza tenga un enfoque práctico puesto que la ingeniería de software teórica resulta insuficiente para el ejercicio profesional de la disciplina.

Curiosamente mi formación  en Fiuba no tuvo este enfoque. Como alumno tuve un conjunto de materias de índole más bien teórica y  tiempo después otras materias de tipo taller donde se suponía ponía en práctica la teoría aprendida tiempo atrás. Esto me parece perjudicial para el alumno, pues a la hora de estudiar la teoría, la misma se aprende “en el aire” sin ponerla en práctica. Luego, tiempo más tarde se cursa un taller, pero al llegar al taller uno ya se olvidó de la teoría “supuestamente aprendida”. Exactamente esto me pasó con el tema de estimación: en una materia me enseñaron los diversos métodos de estimación pero nunca me pidieron estimar, simplemente me pidieron describirlos en un examen escrito. Tiempo después cuando cursé el taller y tuve que estimar, tuve que volver a estudiar los métodos y fue ahí, a la hora de aplicarlos, que me surgieron mil dudas. Algo similar me ocurrió con las cuestiones de testing y calidad.

Otra curiosidad de mi carrera (y que también se repite en otras casas de estudio) es que cursé en primera instancia una materia de análisis y luego una de diseño, como si fueran dos actividades disjuntas (un punto sin duda debatible). Hasta ese momento carecía de una visión general del proceso de desarrollo de software, cosa que aprendí tiempo más tarde en la materia de gestión. Creo que resulta muy dificil (y poco conveniente) enseñar técnicas de análisis y diseño sin contar con el marco general de un proceso de desarrollo. En este sentido me parece interesante el enfoque de la Universidad Nacional de Quilmes, donde primero se ofrece una materia introductoria a la Ingeniería de Software que brinda al alumno una visión general de la disciplina, con un enfoque muy práctico y luego en siguientes cuatrimestres se ofrecen materias específicas para cada actividad: Ingeniería de requerimientos, Gestión de proyectos, Arquitectura de software, etc, etc.

Respecto del enfoque práctico, en concreto creo que es necesario hacer el ejercicio de construir/extender un pieza de software de cara a poner en práctica toda la teoría y técnicas enseñadas, tengo la sensación que enseñar ingeniería de software a partir de lecturas, cuestionarios y ejercicios conceptuales es insuficiente para formar profesionales de la informática y como dije antes el hacer estas actividades en materias separadas no me parece apropiado.

Creo que algunas de estas cuestiones han sido consideradas en el nuevo plan de la Licenciatura en Sistemas de la FIUBA (aunque no estoy seguro de hasta que punto). Espero también que estas cuestiones sean consideradas en el próximo plan de estudios de la carrera de Ingeniería Informática de FIUBA.

 

 

 

Cierre de cuatrimestre en UNQ (2015-2)

Un nueva cursada a ha terminado. Más allá de algún accionable menor surgido del feedback del cuatrimestre anterior no hicimos cambios relevantes este cuatrimestre.

Tuvimos 15 inscriptos (entre ellos 1 recursante) de los cuales 2 abandonaron la materia mientras que los otros 13 restante completaron la materia y aprobaron.

La nota promedio de aprobación fue 8.4/10 y el grado de conformidad de los alumnos con la nota obtenido fue 4.2/5.

La evaluación general de los alumnos según la encuesta anónima de cierre de la materia fue de 8.9.

A diferencia de cuatrimestres anteriores, en la retrospectiva de cierre de la materia no surgieron puntos relevantes (tal vez sea porque utilizamos una dinámica de retrospectiva nueva). Más aún algunos de los pocos puntos que surgieron, tuvieron opiniones distintas, o sea: algunos alumnos los consideraron como cosas a cambiar mientras que otros los consideraron como puntos importantes a mantener. Entre los pocos puntos que tomamos para mejorar/probar están:

  • Mejorar el feedback de las katas
  • Programar alguna kata en clase
  • Hacer alguna review online durante el desarrollo del TP final

Personalmente confirmo una vez más mi sensación de que realmente hemos logrado una muy buena materia en el sentido de que me hemos logrado una dinámica que nos ha permitido ayudar a los alumnos a incorporar nuevos conceptos y herramientas para su desarrollo profesional y académico.

Comparto aquí la foto de cierre y algunos de los videos de los TP finales:

eis_unq_20152

 

Cierre de cuatrimestre en UNQ (2015-1)

Terminó el cuatrimestre y hemos marcado un record en la materia: 16 inscriptos y 16 aprobados. Si bien ya habíamos alcanzado esa cantidad de inscriptos, algunos habían abandonado la materia en el camino.

Este cuatrimestre tuvimos un cambio en el equipo, por motivos personales Ingrid no pudo estar este cuatrimestre pero tuvimos la incorporación Damián Cravacuore.

En lo referente al trabajo práctico final, este cuatrimestre todos los equipos trabajaron sobre aplicaciones existentes lo cual permitió que se pudieran enfocar en cuestiones de gestión y prácticas técnicas como especificación con ejemplos, TDD e integración continua.

Mantuvimos la dinámica de katas pero como hicimos algunos ajustes de último momento surgieron algunos issues técnicos. Una innovación que agregamos en relación a este punto fue el uso de integración continua desde el comienzo.

La encuesta anónima de fin de curso nos arrojó una evaluación general de la materia de 8.6/10 y un nivel de conformidad con la nota final de 4.66/5. La nota promedio de aprobación fue 8.

Entre los puntos destacados de la retrospectiva de fin de curso surgieron:

  • Mejorar la publicación de las consignas de los trabajos prácticos
  • Ser más explícitos respecto de los plazos de entrega
  • Cuidar más la forma de dar feedback  sobre los trabajos
  • Mantener la dinámica de katas
  • Mantener las clases interactivas
  • Mantener las tecnologías y herramientas utilizadas
  • Intentar sacar mayor provecho del campus

Comparto aquí algunas fotos de la retrospectiva y un par de videos de los trabajos finales realizados:

 

unq_retro_2015-1a unq_retro_2015-1b

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