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.

Ingenieria de software: ¿existe tal cosa?

¡Que pregunta! Se podrán imaginar que siendo profesor de una materia con este nombre mi respuesta es sí.

Pero no todo el mundo piensa lo mismo. Una de las personas que cuestiona la existencia de dicha disciplina no es más ni menos que David Parnas, quien el pasado octubre publicó un artículo titulado: «Software Engineering – Missing in Action: A Personal Perspective». En dicho artículo Parnas repasa brevemente el surgimiento del término ingeniería de software y expone ciertas razones por la cuales duda de que el desarrollo de software tenga el caracter de ingenieria. El artículo me resultó por demás interesante, ya que también toca a la pasada cuestiones como ingenieria vs. ciencia, la estructura de la profesión y la educación del profesional del software.

Sumando a este argumento, mi colega Gabriel Falcone me compartió hace un tiempo este video de la conferencia Scotland Ruby, donde disertante afirma:

«Software engineering as it is taught in universities simply does not work. It does not produce software systems of high quality, and it does not produce them for low cost. Sometimes, even when practiced rigorously, it does not produce systems at all. That is odd, because in every other field, the term engineering  is reserved for methods that work.»

¡uffff! Duro, pero bastante realista. En realidad si uno mira el video completo (unos 45 minutos), se encuentra que en realidad el punto de este individuo es que lo que realmente funciona para construir software son los métodos ágiles y que mucha gente tilda a los métodos ágiles como «anti-ingenieriles». A pesar de no compartir algunos de los puntos expuestos en este video, la sesión me gustó y la recomiendo (de hecho he sacado algunos bullets para mis clases).

Personalmente creo que existe la ingenieria de software como disciplina, pero con una concepción distinta a la que le dan muchas universidades (en general a nivel académico hay cierta «creencia» de que por llamarse ingenieria debe tener una fuerte carga de ciencia básica,cosa que no comparto). Al mismo tiempo creo que es aún una disciplina joven ya que las prácticas/métodos que aumentan la probalidad de éxito de los proyectos – y que por ende podrian poner a la ingenieria de software a la altura de las otras ingenierias- recien se han comenzado a popularizar en los últimos 5 años.

Planificando Ing. de Software 2012

En base a la experiencia del último cuatrimestre, el feedback de los alumnos y algunas ideas que vengo trabajando desde hace ya un tiempo, este primer cuatrimestre de 2012 viene con varios cambios.

En primer lugar voy a dar un enfoque más práctico, o sea, vamos a programar, aunque aún no decido si Java, Smalltalk o Ruby (creo que es algo que puedo dejar decidir a los alumnos).

En segundo lugar voy a hacer algunos cambios en la profundidad de los contenidos: más agile, más calidad/testing y menos UP. De hecho no quiero dedicar más de 3 clases a UP y posiblemente algún trabajo individual (un questionario posiblemente).

En tercer lugar, pero no por ello menos importante, voy a dictar la materia en forma iterativa. Esto es un tema que he hablado con colegas en reiteradas ocaciones: bien probado está que el desarrollo iterativo es una de las prácticas de ingeniería de software más aceptadas y utilizadas en la actualidad, pero sin embargo la ingeniería de software sigue enseñanadose en forma secuencial. Entonces mi idea es dividir la materia en iteraciones, entre 4 y 6. Cada una de ellas time-boxed, con un entregable concreto. En cada iteración veremos todas las actividades del proceso de desarrollo, profundizando un poco más en cada iteración, al final de cada iteración tendremos un entregable de valor.

La excepción será primer iteración, que será más corta y en la que nos centraremos (al igual que el cuatrimestre pasado) en entender las particularidades de la disciplina. El entregable de esta primer iteración será el setup del portfolio individual (en futuros post voy a desarrollar este punto).

Cada una de las siguientes iteraciones tendrá un ejecutable de código con sus correspondientes pruebas, algunas de las cuales serán especificadas como parte de la consigna y otras deberán ser diseñadas por los alumnos.

Adicionalmente a la entrega de final de iteración, tendremos también algunas entregas intermedias.

Otro de los cambios será la utilización de un build server para verificación de los entregables.

También tengo la intención de utilizar una plataforma virtual, la cual espero nos permita tener una mejor dinámica de intercambio en el curso. Ya realicé el pedido al departamento con lo cual solo me queda esperar que acepten la petición, pues en general la plataforma virtual está solo disponible para la materias de las carreras virtuales.

Otro agregado de color que pienso hacer el tema «ejercicio profesional». Con este nombre pretendo englobar varios consejos para el desempeño profesional como por ejemplo: como armar un CV, como prepararse para una entrevista laboral, etc, etc.

Al mismo tiempo quiero mantener varias de las prácticas del cuatrimestre anterior como por ejemplo el envio de mail de resumen después de cada clase, la planificación y estimación de las tareas por parte de los alumnos y visibilidad contínua sobre las asistencia a clase. Este última  práctica tiene que ver con que si un alumno piensa faltar a clase, debe comunicarlo previamente, el obejtivo de esto es que se acostumbren a dar visiblidad a su equipo. También voy a repetir la experiencia de invitar a profesionales de la industria a contar sus experiencias (para este cuatrimestre ya tengo el compromiso de Manuel Trejo de Kinetia)

Por último estoy evaluando distintas alternativas tecnológicas para intentar grabar las clases, pero no estoy seguro que pueda implementar esto.

Si algún futuro alumno lee esto puede que se pregunte ¿pero cuanto voy a tener que trabajar para aprobar esta materia? Recuerdo que una vez un profesor me dijo que para hacer una carrera univesitaria hay que dedicar al menos la misma cantidad de horas de estudio que la cantidad de horas de clase. Yo no creo que para esta materia sea necesario tanto. Considerando que tenemos entre aproximadamente 5 horas netas de clase, estimo que con dedicar unas 3 horas semanales extra clase, deberia ser suficiente. Pero ojo, hablo de 3 horas netas, podes parate para ir al baño, tomar un vaso de agua o preparar el mate, pero nada de mail, ni chat, ni SMS, ni facebook, son 3 horas estudio posta.

Las clases empiezan en dos semanas y tengo muchas expectativas. Ya les iré contando más a medida que avance.