Seminario de Postgrado en Software Delivery

Seminario de Postgrado en Software Delivery

Desde el grupo de investigación en Prácticas y Procesos de Desarrollo de Software de la Universidad Nacional de Tres de Febrero estamos planificando un seminario de postgrado en Software Delivery.

Venimos hablamos de esta idea desde el año pasado pero recién en Marzo comenzamos a trabajar en la preparación. De hecho el título del seminario aún no es definitivo. Estamos apuntando a una modalidad blended: encuentros presenciales + encuentros remotos + trabajos para realizar entre encuentros.

Respecto de la audicencia, es un seminario de posgrado, con lo cual esperamos egresados de carreras de grado en el área de informática/computación/sistemas, con experiencia en delivery de sistemas software-intensive.

Recién empezamos a trabajar en el contenido, sabemos que habrá algo de diseño/descubrimiento de producto, algo de trabajo en equipo y bastante de arquitectura, calidad y operaciones.

La idea también es que los participantes no vengan simplemente en modo alumno a escuchar. Sino que pretendemos también traigan sus propias experiencias y que el equipo docente actué más como guia/facilitador a lo largo de todo el seminario.

No tenemos idea de cuantos interesados en participar podrá haber, pero dada la dinámica que tenemos en mente, necesitamos al menos 6 participantes y posiblemente no más de 15.

Adivinanza: el proyecto con calidad

Advertencia: aunque el siguiente relato parezca ficción, juro es está basado en hecho reales.

Érase una vez una eṕoca en la que me toco trabjar en 2 proyectos en simultáneo. Pertenecian a organizaciones distintas. Ambos estaban construidos con la misma tecnología y ambos llevaban aproximadamente el mismo tiempo de desarrollo al momento que yo me sumé. Pero tenían algunas diferencias radicales.

A)
Un proyecto llevaba ya varios releases productivos y de hecho realizaba releases en forma frecuente. El otro proyecto tenía apenas un release que había ocurrido luego de casi 1 año de desarrollo.

B)
Un proyecto tenía pruebas automatizadas de distinto tipo que sumaban varios cientos: pruebas unitarias, de integración, de aceptación hasta incluso de performace. El otro proyecto no tenía más de 20 pruebas unitarias automatizadas, tenía muchos casos de prueba de ejecución manual pero que obviamente no se ejecutaban todo el tiempo.

C)
En un proyecto usaban trunk-based development y escribían todo el código haciendo pair-programming. En el otro proyecto usaban feature branches y merge-request/code-reviews.

D)
En un proyecto trabajaban a lo Extreme Programming. En el otro proyecto dicían hacer Scrum.

E)
En un proyecto el cliente estaba contento con los resultados y con la marcha del proyecto. En el otro proyecto el cliente no estaba contento con los resultado ni tampoco con como marchaba el proyecto.

En un proyecto me pidieron que los ayude a estabilizar el build y optimizar el tiempo que este tardaba en correr que solía rondar los 50 minutos. En el otro proyecto me pidieron dar una mano para mejorar la dinámica de trabjo en un sentido amplio.

Uno era el proyecto A y el otro era el proyecto B. Adivinen cual es cual.

Continuará…

Trabajos finales en UNTreF Computación

Algunas carreras de grado requieren que los alumnos realicen un trabajo final para completar su formación. Dependiendo de la carrera y la institución ese trabajo final recibe distintos nombres: tesis, tesina, trabajo final integrador, etc, etc.

En la carrera de Ingeniería en Computación de UNTreF los alumnos tienen que hacer un trabajo final integrador. Como parte del plan de estudios hay una materia en la que se orienta/prepara al alumno para realizar dicho trabajo, pero la realización del trabajo no es parte de esta materia. En el mejor de los casos, al finalizar la materia los alumnos tienen planteada la propuesta formal para realizar el trabajo final. La realización del trabajo requiere de la dirección de un profesor. Una vez terminado el trabajo un jurado de 3 profesores evalúan lo realizado.

Tiempo atrás tuve el honor el de ser parte de jurado de la primera camada de egresados de la mencionada carrera de UNTreF. Recientemente recibí un par de consultas de alumnos por la posibilidad de ser su director. Ello me disparó la idea de escribir este post para compartir algunas generalidades de mi visión y estrategia para la realización de trabajos finales.

En primer lugar y en términos reglamentarios el trabajo final debe representar una carga de unas ~200 horas. Esto es equivalente a una materia intensa: (6 horas semanales de cursada + 6 horas de estudio extra-clase) * 16 semanas. Lo cual significa que trabajando de forma ordenada y constante, el trabajo puede completarse en 1 cuatrimestre. Al mismo tiempo para que esto sea factible, el trabajo debería ser planteado en términos de esfuerzo/calendario fijo, dejando el alcance con cierto grado de variabilidad.

Se espera que en el desarrollo de este trabajo el alumno aplique de forma integral los conocimientos obtenidos durante la carrera. El tema debe ser acordado entre el alumno y el director. Yo personalmente tengo ciertas restricciones de temas, o sea, no dirijo trabajos de cualquier temática y al mismo tiempo siempre algunas ideas de posibles temas que me gustaría dirigir.

Adicionalmente, espero que los alumnos que hagan su trabajo final bajo mi dirección lo presenten en una conferencia académica como JAIIO-EST o CONAIISI.

Aplicaciones varias para Desktops Linux

Aplicaciones varias para Desktops Linux

La semana pasada mi computadora con MacOS me dejó a pata y tuve que saltar a una máquina de backup con Linux. Podría haber sido Windows, pero no, preferí que sea un Linux. En particular elegí Linux Mint, un linux de la familia Debian.

Una vez instalado el sistema de base procedí a la instalación de herramientas varias.

En primer lugar instalé Terminator, una aplicación para manejar múltiples terminales.

Luego instalé un clásico: un clon Norton Commander, hay varios dando vueltas

Libro de Desarrollo Ágil de Software by 10 Pines

Fede Zuppa junto a otros colegas de 10 Pines están escribiendo un libro sobre desarrollo ágil de software. El libro está aún en proceso de escritura pero periódicamente Fede publica versiones preliminares. Tuve la oportunidad de leer una de esas versiones y a pesar de ya estar familiarizado con los temas abordados me pareció un material muy valioso.

Las explicaciones son claras y los distintos temas están presentados desde la experiencia práctica de 10Pines. Aquellos que gusten darle una leída las versiones preliminares pueden encontrarlas aquí.

Shell Script: amor y odio

Shell Script: amor y odio

Escribir scripts de shell no es una cuestión fancy. El lenguaje es bastante duro para quienes estamos acostumbrados a programar con lenguajes de objetos. Esto hace que a la hora de elegir una herramienta de scripting yo tienda a inclinarme por otras opciones como ruby o python. Pero a pesar de esto, me encuentro recurrentemente escribiendo scripts de shell. ¿Por qué? Básicamente porque funcionan en cualquier sistema Linux sin necesidad de instalar paquetes adicionales. Es por esto que siempre recomiendo a la gente que trabaja en automatización que aprenda shell scripting. Comparto algunos recursos que me han resultado muy útiles para este fin:

Mis notas del Campus-Party UY – día 2

Algunos datos de contexto general para empezar. El espacio del evento estaba dividido en zonas. La sala principal tenia stands en el centro, tres escenarios para charlas magistrales, la zona de workshops, dos espacio de trabajo (con tomas y cables de red) y la zona de prensa. En otro salón estaba la zona de comidas y finalmente en un tercer salón la zona de carpas.

A las 10.00 comencé con mi workshop de Extreme Programming en el que participaron de forma continua unas 14 personas (mas algunas otras que fueron y vieron) pero luego en la segunda parte, cuando pasamos al código, solo quedaron. Personalmente quedé muy conforme con como salio. Fue interesante el rango de edad y experiencia de los partipantes: hubo gente en sus primeros 20 años y otros llegando a sus 40. Al final del taller sorteamos algunos ejemplares de Construccion de Software y de los libros del AOC.

Ya por la tarde, luego del almuerzo, di mi charla “La ultima milla”, estimo que por momentos la audiencia llegó a 100 personas. Hablé unos 45 minutos y luego di espacio para preguntas. Me sorprendió la gran cantidad de preguntas. Una vez finalicé la charla se me aceraron varias personas para seguir hablando. Parecé que dí en la tecla con un tema de interés.

Al terminar mi charla escuché la presentación de Neil Harbisson. Me resultó muy interesante como logro extender sus sentidos a partir de implantes cibernéticos. Creo que esta fue la charla con mayor audiencia que ví en toda la conferencia.