«Agilistas» ¿fuera de foco?

Yo: me parece que deberíamos liberar las funcionalidades a medida que las vamos completando

El Scrum Master: o sea que querés usar Kanban en lugar de Scrum

Es la tercera vez en lo que va del año que tengo este diálogo, cada vez con un Scrum Master distinto (en distintos proyectos). No soy experto en Scrum pero ¿acaso Scrum dice que hay que esperar al final del Sprint para liberar una funcionalidad? Y si así fuera ¿que problema hay? Si vemos que en nuestro contexto puede resultar más beneficioso liberar a medida que completamos cada funcionalidad ¿porque no hacerlo? ¿Simplemente porque no es lo que dice Scrum?

Mi sensación es que hay:

Gente más preocupada por hacer Scrum que por entregar valor
Gente más preocupada por decir que es ágil que por serlo
Gente más preocupada por los ritos que por la mejora continua

El camino freelance, parte 6: libros recomendados

Decidirse a comenzar el camino freelance no es fácil. A mi me llevó un buen rato, un par de años de hecho. La primera vez que lo consideré seriamente fue a fines de 2008 pero no di el paso hasta el 2012.

Allá por 2008 empecé a investigar hablando con algunos freelancers que conocía y leyendo algunos blogs, hasta que finalmente me compré un libro: The Principles of Successful Freelancing de Miles Burke. El libro valió la inversión, me ayudó a ver varias cuestiones que no estaban en mi radar en aquel momento.

Hoy, habiendo ya recorrido un par de años en el camino independiente vuelvo a recomendar el libro de Burke pero también he descubierto algunos otros que recomiendo con el mismo énfasis.

Soft Skills de John Sonmez y The Software Craftsman de Sandro Mancuso son dos libros excelentes y que recomiendo para todo programador profesional más allá de que trabaje de forma independiente o en relación de dependencia. Ser profesional es un valor que en el caso de trabajadores independientes es aún más valioso. El libro de Mancuso está enfocado en el desarrollo profesional. El libro de Sonmez también habla de desarrollo profesional pero es más profundo y llega a cubrir cuestiones concretas como técnicas de productividad, estrategias de trabajo remoto, marketing personal, la transición freelancer y cuestiones económico/financieras.

Los tres libros que mencioné hasta el momento son libros para informáticos, el cuarto libro que quiero recomendar es mucho más genérico y posiblemente también más famoso: Los 7 hábitos de la gente altamente efectiva de Stephen Covey. Este libro nada dice sobre programadores ni trabajadores independientes, sino que básicamente habla de organización personal, algo fundamental para todo trabajador independiente.

Despedida de UNQ

El mes pasado cerré una etapa en mi carrera docente, presente mi renuncia en UNQ. No fue una decisión fácil, en UNQ estuve por primera vez a cargo de una materia lo cual fue un gran paso en mi carrera. Por otro lado tuve la oportunidad de aprender y compartir muchas experiencias tanto con colegas docentes como con alumnos. También tuve la oportunidad de participar de algunos de los debates de armado de la Licenciatura en Desarrollo de Software (que luego debió renombrarse por cuestiones administrativas). Por cinco años forme parte de un equipo docente de excelencia.

En estos cinco años, participé inicialmente del dictado de Objetos 1 y luego estuve a cargo de Ingeniería de Software. En los 9 cuatrimestres que dicté esta última materia tuve un total de 105 alumnos con un porcentaje de aprobación del 89%.

Pero como mencioné tiempo atrás, este año decidí dar un nuevo paso en mi carrera y tomé un cargo de mayor dedicación en UNTREF con el objetivo de trabajar en un proyecto de investigación.

A pesar de dejar mi cargo espero poder seguir en contacto con la comunidad UNQ y poder participar de futuras actividades.

Agradezco a toda la comunidad de UNQ por las experiencias compartidas y muy especialmente a Fidel, quien me abrió las puertas de TPI y confió en mi para el dictado de Ingeniería de Software.

¡Gracias totales!

Nuevo proyecto: de regreso a .Net

Hace un par de semanas comencé un nuevo proyecto, esta vez con tecnología .Net y con un contexto interesante:

El proyecto es de desarrollo y mantenimiento evolutivo de un sistema existente
El sistema está compuesto por un conjunto de aplicaciones de distinto tipo
El sistema lleva varios años en producción y no tiene ningún tipo de pruebas automatizadas
La documentación funcional y técnica es escasa (prácticamente nula)
Varias de las bases de datos no tienen claves foráneas
El sistema escala en forma vertical y no horizontal

En este contexto voy estar colaborando en cuestiones de arquitectura, operaciones y prácticas técnicas de desarrollo.

Continuará…

SoCraTes Chile 2016

La conferencia estuvo excelente y más aún si tenemos presente que es la primera edición en Latam. Si bien es cierto que en el cono sur se vienen realizando conferencias en formato open space desde hace ya varios años, dudo mucho que alguna haya sido tan técnica como esta y al mismo tiempo con tan buen nivel.

Un punto importante para destacar es que la mayoría de las sesiones estaban preparadas con antelación, un tema que personalmente vengo insistiendo hace tiempo pues en la mayoría de los open spaces que he participado casi todas las sesiones ha sido improvisadas, lo cual generalmente ha jugado en contra de su calidad.

La conferencia se realizó en las instalaciones de la Escuela de Ingeniería de la Universidad de Chile. A diferencia de otros open spaces en los que participé, en este había un solo espacio, o sea, una única planta abierta en la cual se desarrollaron hasta 7 sesiones en paralelo. Para ser sincero debo admitir que inicialmente pensé que sería un caos, pero para mi sorpresa salió todo muy bien.

Los asistentes estaban convocados a las 9 de la mañana pero los organizadores arribaron bastante antes. Alrededor de las nueve 9.30 todos tomamos asiento y los organizadores hicieron la apertura y continuación de la misma se largo el marketplace de sesiones. De la apertura me llamaron positivamente la atención dos cuestiones: la mención explícita del código de conducta (algo que en muy pocas conferencias he visto) y ciertas instrucciones para el caso de emergencias (lo cual resulta muy lógico considerando que Santiago es una zona sísmica).

El marketplace fluyó con muy buen ritmo, algunas de las sesiones propuestas fueron (los nombres que comparto aquí no son exactos):

Continuous Delivery en Latam Airlines
Big Data en Chile
Versionado en un producto multi-cliente
Estrategias de Branching
Feature-Driven Architecture
How-to TDD en Php
Desarrollo de Microservicios con Scala y Akka
WebDrone, un framework para automatización de pruebas web
Test-Driven Problem Solving
Intro a Play Framework
Proyecto CarBack
Ser programador a las 50
Coding Dojo Proyecto Euler
Mutation Testing
Continuous Delivery a gran escala (propuesta por mi)

Entre las sesiones que participe destaco la presentación de @ferpobletea del caso de Continuous Delivery en Latam Airlines, el caso en si mismo resultó interesante y la presentación fue impecable.

Luego me pareció muy interesante la presentación de Aldrin Martoq sobre WebDrone, un DSL Ruby que provee una capa de abstracción sobre Selenium WebDriver. Me gustó mucho la dinámica, hizo una presentación breve y a continuación empezó a codear unos tests sobre FaceBook usando la herramienta en cuestión.

El coding Dojo de la tarde me pareció excelente, trabajamos sobre 2 ejercicios extraídos de Proyecto Euler. Ambos ejercicios los hice en Ruby con RSpec (haciendo TDD obviamente). El primero lo resolví sin mayores dificultades pero el segundo me resultó mucho más trabajoso. Inicialmente plateé una solución recursiva que si bien era conceptualmente correcta, tardaba una infinidad de tiempo en correr y consumía una cantidad descomunal de memoria. Esto me llevo a cambiarla por una solución iterativa que utilizaba mucho menos memoria pero igual seguía tardando mucho. Finalmente Eduardo (el facilitador del dojo) compartió un secretillo que me permitió ajustar mi algoritmo y lograr una solución mucho más óptima en términos de tiempo de ejecución y consumo de recursos. Fue interesante que todos los cambios de implementación que fui realizando en este segundo ejercicio no modificaron el contrato de mi clase con lo cual los tests siguieron siendo siempre los mismos.

Algunas otras sesiones que tuvieron muy buena convocatoria y repercusión fueron: Feature-Driven Architecture presentada por Uzi Mamani, Microservicios con Scala/Akka y Test-Driven Problem Solving facilitada por @agustinvillena (una lástima que no pude asistir porque se superpuso con mi propia sesión).

En mi sesión tuve una buena cantidad de asistentes y me gustó como salió a pesar de ser la primera vez que la hacía. La sesión se llamo «Continuous Delivery a gran escala» y básicamente estaba centrada en una serie de técnicas/patrones para cuando tenemos que implementar procesos de integración y entrega continua en contextos «corporativos» con cientos de tareas en el servidor de integración continua.

La jornada terminó alrededor de las 6 de la tarde compartiendo unas pizzas en el mismo espacio de la conferencia.

Una vez finalizada la conferencia, @agustinvillena y Marcel (su colega de cátedra) nos llevaron a mi y a Uzi a dar una pequeña vuelta turística por la ciudad para finalmente encontrarnos a compartir la cena con el equipo de organizadores.

Mis felicitaciones y agradecimientos a German, Felipe y el resto de los organizadores, el evento estuvo impecable y la pasé muy bien. ¡Ojalá se repita!

Setting up a .net build server without Visual Studio

Usually setting up a build server is a very straight forward task but not always. In case you want to build .Net applications it could be a non-trivial task because of the tight coupling of the different build tools with Visual Studio. A simplified way of dealing with this complexity is to install Visual Studio in the build server. I took that approach in the past and I didn’t want to go that way again. I don’t want Visual Studio in the build server.

In a previous post I described the approach I took to simplified the setup of the different build tools I want to integration in my build process. But that approach does not work if you don’t have Visual Studio, FxCop will not work and at the same time you will get lot of warning messages because of missing dependencies. So here is what I have to do:

Get a machine with Windows Server 2012 R2
Install .Net SDK 4.5.2
Install Microsoft Build Tools 2015
Install Windows 7 SDK and .Net 4 SDK (not the whole package but only Reference Assemblies)
Install .Net 3 assemblies (it can be installed by using the Add feature option in windows, so you don’t need any additional download)

With all this stuff installed in your server, then you can use the approach I described previously and just use your build server to trigger MSBuild to take care of running all your build tasks.

SoCraTes arrives South America

Next Friday, July 1st, the Software Craftsmanship and Testing Conference will arrive to South America. It will be hosted at Universidad de Chile.

I have just bought my ticket so in the next couple of days I will start preparing a session proposal (the agenda is full open space). I have 2 possible topics in mind:

Bringing technical excellent to legacy projects: since I started my freelancer activity the majority of the projects I have been involved were legacy projects. In that contexts my main concern was always remove technical impediments in order to enable the continuous delivery of business value. So the idea of this session is to share some patterns and practices to face this challenges.
Continuous Delivery at Scale: setup a Jenkins server and configure a couple jobs to automate integration and deployment is an «easy task», but the situation get complex when you have to manage hundred of projects and at the same time follow several organisational policies. This session is about patterns and recommendations to deal with this stuff.

I don’t have enough time to prepare both sessions, so I have to pick one. What would you prefer?

Integrating .Net Build tools: MSBuild, NuGet, FxCop, StyleCop and NUnit

These days it is very common to have a continuous build process that includes: compilation, code analysis and automated tests. The way of implementing this kind of process varies depending on the technology of the project.

I have worked with Ruby, Python, Java, JavaScript, Smalltalk and some other languages and in all cases you just need to install 3 tools:

the runtime/sdk (like ruby, jdk, cog)
a package manager (like bundle, maven, pip, metacello)
a build tool (like rake, maven, fabric)

Any other thing you may need (linter, testing framework, etc), you can get it using the package manager and make it run as part of your build script.

But in .Net the situation is more complex. First of all everything seems to be very tight to Visual Studio (the IDE). Because of this, many people just install the Visual Studio in the build server.

Additionally to this the .Net SDK does not provide a test framework. You can use NUnit (which you will have to install manually) or you can use MSTest but to use it you need to install Visual Studio.

FxCop (the linter) comes with Visual Studio but if you don’t want Visual Studio, then you have to install it manually.

So, in order to avoid several manual tasks when setting up a new dev box and also to minimize any possible difference between dev boxes and the build server box I did the following:

I downloaded all the tools I wanted to use in my build process and placed them into the same directory (c:\BuildTools).
I wrote a build script (using MSBuild and defining my own targets). This script «glues» the invocation to all of these tools: NuGet, FxCop, StyleCop and NUnit.
Finally I package all these stuff in a self-extracting .zip file so all the team members can easily replicate my setup.

In order to have the build process to run continuously I also installed this package in the Jenkins build server.

Jenkins: Jobs as Code

Una de las funcionalidades destacadas en la nueva versión de Jenkins es la posibilidad de definir los pipelines utilizando un lenguaje de dominio específico. Esto resulta muy útil cuando uno tiene que manejar una cantidad importante de jobs y al mismo tiempo facilita el control de configuración ya que permite que la definición de los jobs sea tratada como código en lo referente al almacenamiento y versionado.

Esta posibilidad de manejar los jobs como código es algo que está ahora más presente en Jenkins 2, pero la realidad es que es una funcionalidad que ya estaba disponible para las versiones anteriores de Jenkins mediante el uso de plugins y algunas otras herramientas.

En particular yo venia utilizando el Jenkins Job Builder, una herramienta de la gente de Open Stack que permite definir jobs en un archivo .yml, definiendo también relaciones «de herencia» entre los jobs. El Job build es básicamente un script python que parsea los .yml y utiliza la api de Jenkins para crear los jobs correspondientes.

Otra herramienta que provee una experiencia similar es el Job DSL Plugin. Este plugin provee la posibilidad de definir Job utilizando un DSL Groovy para la definición de Jobs. La forma de uso es: poner los scripts de definición de jobs en un repo y luego crear un job en Jenkins (típicamente llamado Seed) que monitorea el repo de scripts y que cuando detecta cambios ejecuta los scripts los cuales generan los jobs que hayamos definido.

Otras herramientas similares pero que no he probado lo suficiente son: el Build Flow Plugin y el Workflow plugin.

El camino freelance, parte 5: dos prácticas de gestión

Cuando uno es contratado para un trabajo es de esperar que uno realice su trabajo de forma correcta, o sea: si me contratan para programar entonces debería programar bien (además de asegurarme de estar programando lo que el cliente espera), pero más allá de eso creo que hay otra serie de cuestiones importantes particularmente cuando uno trabaja en un esquema time & materials. Entre todas esas cuestiones hay dos que aplico siempre porque me ayudan mucho en la ejecución de mis proyectos.

Visibilidad continua

Dado que el cliente estará pagando por el tiempo que nosotros dedicaremos al trabajo me parece una obligación dar visibilidad de las cosas que hacemos. Y cuando hablo de visibilidad no me refiero a un mail semanal con un resumen de lo que hice en las pasadas 40 horas. En algunos contextos eso puede estar bien, pero yo prefiero trabajar con una visibilidad más granular para así permitir a mi cliente accionar y corregir el plan de acción en caso de ser necesario. En ese sentido yo suelo reportar a nivel diario. Básicamente informo todos los días: que hice, en que estado está, y que voy a hacer a continuación.
Comparto aquí uno de mis mails de proyecto mostrando este tema de la visibilidad.

Hi guys,

Today I completed the OAuth integration (story#7533). Unless you have a different opinion I will move it live today 5 PM (EST).

Next Steps: I will continue with story#7536 that was reported today as urgent.

Regards,
NicoPaez

Acción por defecto

Si bien siempre es bueno tener el OK del cliente antes de avanzar con una tarea, no todos los clientes responden rápidamente lo cual puede ocasionar que uno quede bloqueado, cruzado de brazos por horas o incluso días. Si me quedo cruzado de brazos si cobrar ese tiempo, pierdo plata, pero si lo cobro el que pierde plata es mi cliente, lo cual a largo plazo también también me perjudica a mi. Para evitar esto lo que suelo hacer es pedir validación y proponer una acción defecto en un determinado tiempo límite.

Hola Ale,

Te cuento que ya tenemos todo el código y datos listos para correr las pruebas de stress (ticket#362) y estaríamos en condiciones de comenzar con su ejecución mañana mismo.

Tal como hablamos la semana pasada, para ejecutar estas pruebas necesitamos una cuenta en ABCDE. En teoría la cuenta iba a estar disponible el lunes, pero aún no lo está. Entonces si la cuenta no está para mañana lo que haremos de cara a evitar retrasos en el proyecto es correr las pruebas con mi propia cuenta y luego arreglamos entre nosotros el pago.

Saludos,
NicoPaez

Me parece importante destacar que estas prácticas pueden resultar útiles en muchísimos contextos distintos, pero creo que cobran mayor relevancia en el caso particular de contratos time&materials.

Blog de NicoPaez

Ingeniería de Software, Docencia y Programación

Autor: NicoPaez