Escribo esta líneas para potenciales alumnos de mi materia y por ello agrego un poco de contexto para los lectores ajenos a FIUBA. En FIUBA se dictan actualmente dos carreras relacionadas a sistemas/informática/computación. Por una lado está la Licenciatura en Análisis de Sistemas y por otro la Ingeniería en Informática. Son dos carreras separadas, no es que la licenciatura es un paso intermedio de la ingeniería. Son dos carreras distintas, totalmente independientes pero que comparten varias materias.
La materia que yo dicto actualmente se llama Métodos y Modelos en la Ingeniería de Software 2 (código 95.21). Comúnmente es conocida como MeMo2. Es una materia que surgió a partir de la reforma 2015 del plan de estudios de la carrera de Licenciatura en Análisis de Sistemas. En el plan anterior había dos materias de ingeniería de software, una enfocada en cuestiones de análisis (Análisis de la Información – 75.09, comúnmente conocida como AnInfo) y otra enfocada en cuestiones de diseño (Técnicas de Diseño – 75.10, comúnmente conocida como TDD). Estas dos materias eran compartidas entre ambas carreras. Con el nuevo plan de estudios de la licenciatura se actualizó la visión de la ingeniería de software y esa dos materias (75.09 y 75.10) fueron reemplazadas por dos materias nuevas (95.20-MeMo1 y 95.21-MeMo2) que apuntan a cubrir con distinto nivel de profundidad todas las actividades de la ingeniería de software. Adicionalmente también se agregaron temas de ingeniería de software a otras materias del plan. De esta forma MeMo2 quedaba exclusivamente para la Licenciatura y TDD exclusivamente para la ingeniería.
En este contexto yo armé la materia MeMo2 en base al programa de la licenciatura. Cuando comencé a dictar la materia tuve muy pocos alumnos pues el plan era nuevo. Al poco tiempo, el Departamento de Computación decidió que mi materia, MeMo2, del plan de la licenciatura, era equivalente a TDD del plan de la ingeniería, una decisión polémica a mi parecer. Esto implicó que mi materia sea formal y simultáneamente MeMo2 y TDD. Yo siempre consideré esta decisión muy polémica ya que en términos formales los programas de TDD y MeMo2 tienen muy poco en común (a simple vista no más de un 30%).
Hoy en día mi materia sigue siendo formalmente MeMo2 y TDD pero en términos reales en su contenido es MeMo2. Esto hace que en habitualmente alumnos de la ingeniería vengan a cursar mi materia con una determinada expectativa (contenidos de TDD) pero se encuentran con algo distinto (contenidos de MeMo2).
Comparto una tabla comparativa de los programas de ambas materias, resaltando en verde los temas de TDD que cubrimos en MeMo2.
Una de las dificultades que suelo encontrar al intentar enseñar Test-Driven Development a gente que ya tiene varios años de experiencia en desarrollo de software (con los principiantes es distinto), es que muchas veces no saben hacer pruebas unitarias automatizadas. Por eso, hace un par de semanas cuando decidí experimentar haciendo un curso 100% en video, no dudé en hacerlo sobre unit testing.
Ayer finalmente, luego de un par de semana de trabajo completé el curso, son 2 horas de video divididas en varios videos de no más de 10 minutos. Además de los videos, incluye varios recursos de lectura y ejecicios. Todo el código del curso está basado en C# (netCore) y NUnit, pero todo el contenido es fácilmente extrapolable a otros lenguajes/frameworks. Personalmente creo que tomar el curso completo (videos + lecturas + ejercicios) podría llevar unas 4 o 5 horas dependiendo de la experiencia de programación de la persona.
El curso está publicado con acceso gratuito en la plataforma Udemy
Terminamos nuestro segundo cuatrimestre en modalidad 100% online. Fue un cuatrimestre muy particular, porque más allá de la virtualidad, tuvimos un cuatrimestre partido: por la situación de pandemia el inicio de clases en 2020 se retrasó y eso impactó en todo el calendario quedando el segundo cuatrimestre partido en 2. La primera parte terminó a mediados de diciembre permitiendo completar 12 semanas de clase. La segunda se retomó en febrero y contempló 4 semanas de clases para así completar las correspondiente 16 semanas de clases del cuatrimestre. Este particionamiento generó ciertas incomidades tanto para alumnos como para docentes.
Por otro lado, al margen de la particulidad del calendario y la virtualidad, este cuatrimestre hicimos 2 cambios mayores en la dinámica del TP2.
En primera instancia, no escribimos una descripción detalla de consigna. Previamente solíamos darle a los alumnos una especificación funcional de la aplicación a desarrollar en forma de pruebas de aceptación, las mismas no eran completas pero daban un nivel de detalle suficiente para marcar el comportamiento y alcance esperado. Este cuatrimestre cambiamos esto pues nos parecía que en cierto modo era una situación demasiado ficticia en el sentido que esas pruebas de aceptación no son típicamente provistas por el cliente/usuario sino que se desarrollan conjuntamente (equipo de desarrollo + usuarios) a medida que «se va descubriendo» el software a construir. En línea con esto, este cuatrimestre no les dimos las pruebas de aceptación, hicimos un product discovery y luego dejamos que cada equipo haga el trabajo de descrubimiento con su Product Owner (miembro del equipo docente). Obviamente que puertas adentro, todos los product owners (o sea el equipo docente) acordamos y alineamos ciertos puntos centrales de cara a intentar asegurar que todos los grupos construyan la misma aplicación más allá de algunas diferencias en términos de reglas de negocio. Esto trajo de la mano ciertas situaciones de negociación y trabajo de más ida y vuelta entre product owner y equipos de desarrollo, lo cual fue intencional para llevar a la práctica el slicing de funcionalidades. Respecto de este cambio, nos gustó y seguiremos con esta estrategia pero somos concientes que es necesario realizar algunos ajustes en la dinámica.
El segundo cambio importante requiere explicar un poco el contexto. Típicamente el TP2 tiene 3 ejes: alcance/funcionalidad, proceso y diseño/implementación. Previamente cada equipo de alumnos tenia un docente asignado que trabaja sobre los 3 ejes, proveía definiciones funcionales (tomando un rol típicamente de Product Owner), verificaba el cumplimiento del proceso (más en onda PMO que facilitador) y finalmente hacía seguimiento/evaluación de las cuestiones de diseño/implementación. Este cuatrimestre dividimos estas responsabilidades/ejes. Por un lado cada equipo tuvo asignado un docente que se encargaba del seguimiento del proceso y jugaba el rol de product owner proveyendo definiciones funcionales y validando su aprobación. Por otro lado, otro docente (yo en este caso) se encagó de la guíar técnicamente a todos los equipos y hacer el seguimiento y correcciones de diseño e implementación. También nos gustó este cambio y por ello vamos a mantenerlo.
Algunos otros cambios de menores que hicimos fueron que recortamos algunos temas (como escalamiento de agile y performance tests) e incluimos algunos nuevos. En realidad no es que agregamos nuevos temas sino que agregamos práctica de algunos temas que solo dábamos teoricamente como infra as code y contenedores.
Por otro lado, en la retro y en la encuesta de fin de curso, detectamos algunos puntos a ajustar entre los que se destacan dos: la gran dedicación requerida para el TP2 y la forma de dar feedback del código en las correcciones del TP2. Tomamos ambas cuestiones considerando que:
En algunos casos hubo falta de foco durante el TP2 que llevó a invertir esfuerzo en funcionalidades no necesarias.
Incluso cuando haya cuestiones que no esten bien al revisar el código hay que buscarle la vuelta en la redacción del feedback para también destacar algunos puntos positivos, pues siempre hay algo positivo para destacar y es necesario destacarlo para mantener la motivación del equipo,
Un tema intersante para descatar es que el primer cuatrimestre que no tuvimos abandonos. Los 21 alumnos que asistieron la primera clase, completaron la materia.
Ya para cerrar comparto algunas estadísticas:
Evaluación general del curso: 8.6 / 10
Claridad de los docentes: 4.3 / 5
Conocimiento de los docentes: 4.9 / 5
Dinámica de clases: 4.1 / 5
Materiales de estudio: 4.1 / 5
Dedicación promedio extra clase: 9.7 hs. semanales
Conformidad con la nota de aprobación: 4.3 / 5
Cantidad de tareas individuales: 38 (incluyendo 10 cuestionarios y 7 ejercicios de programación además de lecturas y videos)
Visita de la industria: Mariano Simone (gracias totales)
Resumen: tenía andriod, me pasé a iphone y ahora volví a andriod. Aquí voy a contar brevemente la experiencia.
Mi primer teléfono en la era de los smartphones fue un Samsung que corria Andriod 2.2 y cuyo modelo exacto no recuerdo. Creo que fue allá por 2010. Luego pasé por otro teléfonos alternando entre Motorola y Samsung, siempre en Andriod y siempre con teléfonos de gama media.
A mediados de 2017 me pasé a iPhone, concretamente compré un iPhone SE motivado casi exclusivamente por la relación potencia/tamaño, era en aquel momento el teléfono con mayores capacidades técnicas con ese tamaño «pequeño». El cambio fue enorme, en parte por el salto de gama, el iPhone SE (y creo que todos los iPhones) es de gama alta y en parte por el cambio de sistema. En aquella época no utilizaba muchas aplicaciones en el télefono, apenas whatsapp, twitter y la cámara de fotos, con lo cual la migración fue muy simple. Mandé las fotos a google drive y los contactos que ya tenia sincronizados con Google, los importé fácilmente en el nuevo teléfono. Así fue que en 2 semanas ya estaba completamente acostumbrado al nuevo teléfono.
A pesar de tener una computadora MacBook, nunca exploté los beneficios de la integración/sincronización macbook-iphone-icloud. Tampoco me metí en cuestiones de desarrollo, si bien había hecho algunos experimentos programando Andriod, n unca tuve la inquietud ni la necesidad de ponerme a codear para iphone.
Por otro lado, aproveché las capacidades del nuevo teléfono y comencé a utilizar más aplicaciones: Spotify, Netflix, Mail, el navegador (antes del iphone creo que fueron contadas las veces que me puse navegar en el teléfono),. etc. En un punto algunas de las actividades que hacía exclusivamente en la computadora empecé a hacerlas con el teléfono. En este sentido algo que me resultó muy útil fue poder participar en videos llamadas (zoom, jitsi, google meet, etc) directamente desde el teléfono.
Hace un par de semanas, tuve un accedente doméstico, caí a la pileta con mi teléfono en un bolsillo. Chau iphone, probé con el arroz, lo llevé a un técnico especilizado pero no hubo caso. Así murió mi iphone al cabo de casi 4 años, sin tener ni una raya, ni golpe, estéticamente impecable pero ya no encendió más. El díagnostico del técnico fue «la placa está en corto».
Mi primera reacción fue volver a comprar el mismo modelo pero resulta que ya no se fabrica. Hay una nueva edición 2020 pero que es de mayor tamaño. El tamaño había sido determinante en la eleccíon de mi primer iPhone. Esto me llevó a analizar algunas opciones Andriod. No encontré ningún teléfono Andriod que pudiera competir en la relación potencia/tamaño con el iPhone SE 2020. Todo teléfono Andriod disponible en el mercado local es al menos 1 o 2 centímetros más grande que el iPhone SE 2020. Consulté varios colegas y finalmente, a pesar del mayor tamaño, decidí volver a Andriod. Compré un teléfono Samsung de gama media porque por lo que vi la mayor diferencia entre los de gama media y gama alta pasaba por las capacidades/cantidad de cámaras y tamaño/definición de la pantalla, dos cuestiones que no son relevantes para mi.
La transición iPhone > Andriod fue mucho más dura que lo que había sido la transición Andriod > iPhone cuatro años atrás. En lo que respecta al setup, esto se debió en parte a que mi uso actual del teléfono es mucho más importante que lo era años atrás. Tenia en el iPhone unas ~15 aplicaciones que tuve que instalar y configurar en Andriod. Mientras hacía el setup descrubrí que tanto iPhone como Android proveen un funcionalidad de migración/setup de teléfonos cuando uno se migra a otro teléfono del mismo tipo: o sea, si se pasa de un iPhone a otro iPhone, casi que con acercar los teléfonos y activar el bluetooth, todas las aplicaciones, configuraciónes y datos se «transfieren» al nuevo teléfono y en cuestión de ~20 minutos quedá listo para andar. Algo análogo ocurre con de Android a Android. Al margen de las aplicaciones, la migración de contacto fue muy simple: exportar de icloud contacts e importantar en google contacts.
Una de clas cuestiones que me encontré en Android y que me genera cierta molesta es el «doble store», o sea: mi teléfono Samsung tiene el store de Google (como todo teléfono Andriod) y el story de Samsung (como estimo que ocurre con todo teléfono Samsung). Esta situación de doble store ocurre también con algunas aplicaciones como ser contactos, navegador, etc. En el caso de iPhone hay un solo store porque tanto hardware como software son del mismos proveedor.
Otra cuestión que noté es que cuando quiero acceder funcionalidades «de hardware» (como las llamadas telefónicas y la radio) hay un pequeño delay/espera/retardo en su inicialización. Tal vez sea algo particular de mi modelo de teléfono pero en iphone nunca noté tal delay.
Un punto que aún no termino de entender es que en Andriod varias aplicaciones me envían notificaciones cuando sus respectivas versiones de iPhone no lo hacían. Tal vez sea que dichas aplicaciones están programadas de forma distinta o tal vez sea que la configuración default de notificación sea distinta a lo que tenia en el iPhone.
Al momento llevo unas 3 semanas con este nuevo Android, aún no me acostumbro, el hecho de que sea pura pantalla sin ningún boton de control (a excepción del encendido y el volumen) me resulta molesto.
Luego de todo lo contando debo decir que a pesar de no estár completamente habituado (aún), estoy conforme con la decisión, sobre todo cuando pongo en la balanza alguna cuestiones que van más allá de la usabilidad como la libertad (android es open source) y el costo (este teléfono android me costo un cuarto de lo que costaba el iPhone). De todas formas, nobleza obliga, debo decir que iPhone siempre me anduvo de 10, y tuve que cambiarlo por el accidente que mencioné, pero lo usé casi 4 años sin ningún problema. Quiero ver si este Samsung/Andrioid me dura el mismo tiempo 😉
Mi Samsung 2016, mi IPhone SE de 2017 y mi nuevo Samsung 2021
Continuando el aniversario de los 20 años del manifiesto ágil parece un buen momento para compartir algunas recomendaciones de libros.
El primero es la joya oculta de mi biblioteca: Planning Extreme Programming. Estoy seguro que mucha gente ni lo escuchó nombrar pero definitivamente vale una mirada aunque más no sea por sus autores: Kent Beck y Martin Fowler. A pesar de ser un libro de XP no es un libro de código, como su nombre lo indica es un libro de planificación que cubre también varias cuestiones de generales de gestión obviamente desde una perspectiva de XP. No es un libro reciente, es del año 2000, o sea que es previo a la publicación del manifiesto. Al igual que todos los libros la serie XP, el contenido está organizado en capítulos cortos, lo cual facilita la lectura.
Tengo dudas de incluir en este listado el libro The Art of Agile Development de Shore y Warden porque tengo la sesión que es un bastante conocido. Si bien no lo indica en el título, es un libro de XP. Fue publicado en 2007 y en estos días (marzo 2021) se está escribiendo en forma abierta la segunda edición la cual parece muy prometedora. El libro es excelente y es la referencia central de mi materia de Ingeniería de Software. Cubre muchísimas cuestiones que van desde mindset, pasando por temas de gestión y hasta cuestiones de código. Es en un libro de ingeniería de software al estilo XP.
Agile!: The Good, the Hype and the Ugly es un libro un tanto polémico para «los agilistas». Lo conocí gracias a mi amigo @dfontde. El autor del libro es Bertrand Meyer, un referente en el mundo académico de la ingeniería de software. El libro es tal cual lo que indica su título: lo bueno, lo feo y lo popular de agile. Personalmente no comparto algunas de las apreciaciones del autor y justamente por eso lo recomiendo. Resulta interesante leerlo porque Meyer es un referente que lleva muchos años en esta disciplina y que en cierto modo muchos lo asociamos a métodos más tradicionales/pre-agile. Un aporte interesante del libro es que para parte del análisis que hace de agile toma las 10 prácticas ágiles que considera más relevantes/representativas de agile.
Otro libro de un autor reconocido es More Effective Agile, este libro aún lo estoy leyendo, pero lo que llevo leído me pareció excelente. Es un libro reciente, fue publicado a mediados de 2019. Su autor es Steve McConnell, un reconocido autor de libros de ingeniería de software entre los que se encuentran Code Complete, Rapid Development y Software Estimation: Demystifying the Black Art. Hay dos cuestiones que me llevaron a leer este libro. Por un lado, ya había leído mucho material de McConnell (además de sus libros también tiene publicados muchos artículo interesantes) y quería saber su visión de agile. Por otro lado, al ser un libro reciente, me resultaba interesante averiguar qué hay para decir de agile a casi 20 años del manifiesto cuando ya se han publicado cientos de libros de agile. La visión de agile que ofrece McConnell la sentí muy afín con mis propias ideas. En esa visión McConnell desmistifica y corrige algunas falsas creencias (y argumentos de venta) de Agile.
Desde hace un par de semanas que venimos preparando esta segunda edición que viene con algunos cambios. En primer lugar hemos ajustado la frecuencia de los encuentros, en esta ocasión serán cada 2 semanas. Por otro lado también cambiamos algunas cuestiones de la dinámica general como ser el hecho de que esperamos que los participantes comiencen su trabajo final ya desde el segundo encuentro para de esa forma poder hacer desarrollos de mayor grado de profundidad e impacto. Otro de los cambios es que esperamos contar con invitados especiales que vengan a compartir sus casos de aplicación de los temas que vemos en seminario. Las fechas de los encuentros de esta edición y los detalles del programa está disponibles aquí.
La semana próxima, el miércoles 17 de marzo, a las 9:30 hs hora argentina (GMT-3) haremos una charla de presentación del seminario donde apuntamos a contar brevemente sobre el contenido, la dinámica y también contestaremos dudas de los interesados. La participación en esta charla es gratuita pero requiere registración, simplemente hay que completar este formulario y les enviaremos el link de acceso.
La semana pasada comencé a trabajar en la segunda etapa de una iniciativa «DevOps». Luego de la reunión del kick-off un colega que está trabajando conmigo en este proyecto pero que no había participado de la primera etapa me consulta: «¿qué onda esto de armar pipelines de deployment de aplicaciones sin ningún tests automatizado?»
¿Qué onda? Riesgoso. Lo hablé con el cliente y fui muy explícito:
«Por este camino más que DevOps vamos a hacer DevOoooops!».
Habiendo hecho la advertencia del caso y siendo conscientes que el término DevOps queda grande para lo que estamos haciendo, mantuve mi ética profesional. Dejé mi purismo de lado y me convertí en complice de la situación con el único objeto de lograr una mejora en el proceso de software delivery. Concretamente lo que estamos haciendo es automatizar el proceso de build y deployment.
Previo a nuestra intervención varios proyectos generaban sus binarios en la máquina de un developer y luego los hacían llegar al área encargada de deployments via un sistema de tickets. Algunos otros equipos tenían un Jenkins, pero solo para compilación. Los encargados del deployment ejecutaban entonces varias tareas manual para desplegar el binario pedido en el ambiente especificado. En este este contexto estamos buscando que:
Todo el código esté almacenado en la herramienta oficial de versionado de la organización (GitLab)
Todos los binarios se generen en un servidor (GitLab-CI) sin depender de la máquina de ningún developer
Los binarios generados sean subidos automáticamente a un repositorio de binarios (Nexus)
El proceso de deployment comience descargando el binario a desplegar desde el repositorio de binario y a continuación ejecute un script parametrizado de forma de utilizar el mismo script para despliegue a todo ambiente.
El proceso de deployment sea ejecutado por una herramienta de CI/CD (GitLab-CI)
¿Esto es hacer DevOps? Esto solo no lo es. Sin duda una estrategia DevOps debería incluir versionado y automatización, pero también muchas otras cuestiones como colaboración entre negocio-desarrollo-operaciones, entrega frecuente, manejo de infraestructura como código, integración continua y pruebas automatizadas (como bien observaba mi colega).
Personalmente suelo hacer mucho hincapié en todas esta cuestiones y las aplico en todos los proyectos en los que trabajo como team member. Sin embargo, cuando hago trabajo de consultoría, no está en mí decidir qué prácticas aplicar. Claro que sugiero (con mucho énfasis en general) pero la priorización y decisión está en manos del cliente. Lo que suele ocurrir es que dentro de todo el set de prácticas DevOps, una de las que ofrece mayor visibilidad y retorno temprano de inversión es la automatización de deployments. Entonces se suele comenzar automatizando los deployments de una aplicación y a continuación surge el dilema, ¿avanzamos en ancho o en profundidad?. O sea: ¿seguimos trabajando sobre esa aplicación para agregarle pruebas automatizadas (y demás prácticas)? o ¿nos movemos al equipo de al lado para seguir automatizando deployments? En general mis clientes suelen optar por lo segundo, avanzar en ancho y dejar en manos del cada equipo el avance en profundidad (pero esto no siempre ocurre). Obviamente que esto no es lo mismo en todos los clientes, esta descripción corresponde a una organización muy grande con cientos de equipos de equipos de desarrollo y varios cientos de aplicaciones.
En fin, esta es la vida del «consultor responsable», bailar el fino equilibro entre purismo y pragmatismo honrando siempre la ética profesional.
Blog de NicoPaez 