Mi primera charla en inglés

Era principios de verano cuando mi amigo Israel (@ialcazar) y yo decidimos presentar un “regular talk”, de unos 30 minutos de duración, en la ALE 2013. Como siempre tomamos la decisión en el último momento responsable, es decir, el último día por la tarde, cuando el “call for papers” estaba apunto de expirar, así que enviamos una breve descripción de nuestra charla enfocada al Bus/Truck Factor:

The agile manifesto highlights people over the process, but to what extent its good to concentrate critical information with few individuals of teams?.
A project could fail for a lot of causes, and into these causes are the unplanned circumstances (job change, boredom or any radical change in life that makes developers abandon the project suddenly and without any warning). This is called “”bus/truck factor””, a measure of the concentration of information in a team.
To manage this factor is not easy, because the best developer (the rockstar) could be the biggest obstacle. Is there a way to manage this situation?
During this talk we will discuss the elements that can interfere with software projects and organizations structure and how bus factor could affect them.
How to know what’s our bus factor? What Practices can increase or decrease the “”bus factor”” in our projects and organizations? The intended audience of this talk is everyone who is interested in the knowledge dispersion and team building.
The talk is about:
– Knowledge about how to manage this common situation in the companies
– New ideas about how to build a better communication
– How to improve the relationships into teams
– And other topics related to team building

Pasaron los días y llegó el momento de viajar a Bucarest. Llegamos el Miércoles 28 de Agosto a Otopeni (uno de los aeropuertos de Bucarest) a las 02:00 h. hora local, en el vuelo conocimos a “Antonio”, primera persona interesante que nos íbamos a encontrar en nuestra travesía, que nos permitió ir con él en su transfer hacia el hotel, aprovecho para dar las gracias de nuevo a Antonio porque si no seguramente nos hubiera resultado muy complicado conseguir un taxi a esas horas en ese aeropuerto.

Llegamos al hotel, mientras nos dieron la habitación y deshicimos las maletas nos dieron las 04:00 h. Había que levantarse a las 07:30 h, ¡¡¡Dios mio, no vamos a dormir nada y mañana presentamos!!! Nos fuimos rápidamente a dormir para poder estar lo más frescos posible.

Después de dormir menos de lo que nos hubiera gustado, nos dirigimos a hacer el check-in de la conferencia que era en nuestro propio hotel (Radisson Blue). Acto seguido nos dirigimos a tomar un café al lounge, dónde nos encontramos a nuestro gran amigo y uno de los organizadores del evento, Saket (@saketbivalkar) y a la armada española (Jaume Jornet @jaumejornet, Antonio de la Torre @adelatorrefoss, Adrian Perreau @eidrien, Ángel Diaz-Maroto @adiazmaroto, Ángel Medinilla @angel_m, Toni Tassani @atassani y Antonio Lopez @antoniolopezg), después de charlar un rato, nos dirigimos al primer keynote, en la que Jurgen Appelo iba a hablar de como intentar ser más feliz en tu trabajo.

Después del keynote de Jurgen, nos tocaba ensayar en la habitación. Los nervios estaban apareciendo, estábamos a 45 minutos de exponernos delante de mucha gente y el ensayo fue fatal….. Era la peor noticia que podíamos recibir a esas alturas, se nos había olvidado gran parte de lo que teníamos que decir. ¿Que podíamos hacer? Valientes y decididos, fuimos hacia la planta de la conferencia dónde sabíamos, inconscientemente, que íbamos a sacar lo mejor de nosotros.

Una vez abajo, en la sala donde previamente había sido el keynote, nos dispusimos a conectar el portátil de Israel con el proyector, después de una serie de problemas técnicos conseguimos tener todo perfecto y fue el momento de mirar al público y ver quien estaba en la sala, entre ellos estaban Ángel Medinilla, Saket, Yves Hounille y el mismísimo Jurgen Appelo, lo cual generaba un poco de ansiedad, pero nada que nos despistara de nuestro objetivo, hacer una buena presentación:

2013-08-28 11.31.46

En ese momento Israel dio al play de su reproductor y empezó a sonar Vertigo de U2, una gran canción para abrir una charla titulada “The rockstar developer, a blessing or a problem?”. En ese instante empezó todo, os pongo el vídeo de la charla para que podáis verla:

Después de la charla, nuestro cuerpo se relajó como cuando tienes acumulada mucha adrenalina y te deshaces de ella. El resto del día fue muy relajado, compartimos muchas conversaciones en lounge, sobre todo con la armada española, asistimos a diversas charlas hasta las 17:00 h., hora en la que finalizaron.

El objetivo estaba conseguido, habíamos hecho algo que unos meses antes parecía imposible, y lo mejor de todo es que nos había gustado. EL AÑO QUE VIENE HAY QUE REPETIR!!!

Por último, os dejo las transparencias de la charla por si queréis echarlas un vistazo:

Nos vemos en el ALE 2014.

¿Dónde están mis historias de usuario?

No es un título de una nueva película de Hollywood ni si quiera es una nueva obra que se vaya a estrenar en el teatro Calderón de Madrid, sin embargo si es algo que yo me pregunto, el porqué cuesta tanto tener/hacer historias de usuario, a pesar de dedicarnos a mejorar la funcionalidad de nuestro producto enfocado a un negocio claro y con especialistas de dicho negocio alrededor de nosotros.

Una historia de usuario, entre otras cosas, esta formada por una información clara que hace referencia a:
  • ¿Quién pide la funcionalidad?: Es una muy buena forma de identificar a al persona que lanzó la idea inicial y que nos puede resolver todo tipo de dudas que tengamos al respecto
  • ¿Qué funcionalidad se pide?: Se debe de especificar que funcionalidad tiene que desarrollar el equipo
  • ¿Para qué se pide esa funcionalidad?: El conocer y entender la/s razón/es por la/s que se pide dicha funcionalidad ayuda mucho para poder escoger la mejor opción a la hora de hacerla realidad
  • ¿Cómo sabemos que la funcionalidad esta bien hecha?: De alguna forma el equipo debe de saber cuando la funcionalidad va a estar acabada y se comporta de la forma que se espera, para ello podemos hacer uso de los criterios de aceptación
Las recapitulación de esta información permite al equipo empezar a plantearse una serie de preguntas al respecto de la funcionalidad, para poder acabar de entender ésta y completarla con lo que sea necesario para que sus trabajo sea excelente. Al realizar este ejercicio sobre las diferentes funcionalidades que queremos desarrollar, obtendremos innumerables beneficios que nos permitirán tener el mejor producto posible lo antes que se pueda.
Sin embargo la realidad es otra, la mayoría de las empresas viven en un entorno cambiante y acelerado en el que se suelen cuidar poco los detalles, aunque a veces se intente, como se suele decir el “día a día” no permite hacerlo. Las posibles consecuencias de todo esto pueden ser:
  • Cambios de contexto continuos, pérdida de foco
  • Bugs después de la puesta en producción
  • Frustración por parte del equipo y de la persona que pidió la funcionalidad
  • Posibles retrasos en la entrega
  • Asunciones innecesarias sobre la funcionalidad, dando lugar a funcionalidades innecesarias
  • Problemas a medio plazo con funcionalidades incompletas o distintas a las requeridas
  • Retorno de inversión incierto
  • Probable pérdida de beneficios
  • ….
Conociendo los riesgos/problemas a los que nos enfrentamos, se debería de actuar para que no sucedieran pero, ¿Qué es lo que no nos esta permitiendo hacerlo?:
  • La presión indirecta del mercado
  • El coste de oportunidad de algunas tareas
  • Fechas estrictamente marcadas
  • Querer abarcar muchas cosas, primado la cantidad por encima de la calidad
  • Costumbre de trabajar en un “servicio cafetería“: yo pido y tu me sirves
  • No trabajar como un único equipo y ver a la gente del negocio como alguien ajeno a la tecnología
  • ….
Después de ver todos estos puntos, debemos de actuar para poder cambiar este contexto en el que la mayoría de las empresas nos movemos, y digo debemos porque es un trabajo en equipo (colaborativo), porque no va  a ser posible cambiarlo si no se implica todo el mundo involucrado en el producto, y no se va a poder cambiar si no todo el mundo quiere trabajar en buscar la calidad del mismo. Tenemos que romper con las tendencias cortoplacistas y ver que la oportunidad de mercado no sólo depende de la variable tiempo.
En esta situación lo que deberíamos de aplicar es el sentido común y ver que nos falta comunicación, nos falta tener un horizonte o visión hacia el que tender, nos es necesario ver que no todo lo que hagamos para mañana va a ser mejor por sacarlo antes si no que también hay que tener en cuenta la calidad del resultado, y para ellos necesitamos que todas las personas involucradas en construir las historias de usuario empleen todo su empeño, creatividad e innovación en completar la información necesaria para que los artistas del software las hagan realidad.

Code Review Checklist

Durante estos últimos días he estado hablando, con mi amigo Israel Alcazar (@ialcazar), bastante sobre el Bus Factor porque tenemos una charla pendiente que preparar para ALE2013 en Bucarest, y a parte porque a ambos nos gusta charlar de cosas relacionadas con Agile, y solemos tener conversaciones “casuales” para hablar de distintos temas.

A partir de ahí, empezamos a pensar como sería posible aumentar el Bus Factor (número de personas que deben ser atropelladas por un autobús antes de que el proyecto se vea en serio peligro), y una de las posibles ideas que surgió fue la gestión del conocimiento a partir de Pair Programming y Code Review.

Suele suceder que cuando un proyecto empieza el Bus Factor es igual a 1, por lo que rápidamente hay que empezar a gestionar ese conocimiento de una forma eficiente. Casualidades de la vida, el karma o la ley del famoso Murphy, justo cuando estamos hablando de estos temas, surge un proyecto nuevo de cierta importancia para nuestra empresa, y bueno uno de los miembros del equipo empieza a preocuparse por la prevención de bugs en producción y nos preguntó por la técnica de Code Review, ya que había estado leyendo sobre ello y le llamó la atención.
Para los que no halláis oído hablar de esta práctica, el Code Review es una técnica mediante la cual se revisa el código fuente por parte de un compañero, un grupo de personas o una herramienta. Además, nos permite asegurarnos que la calidad de nuestro código es lo suficientemente buena como para pasar el juicio y criterio de estos agentes externos al desarrollo en cuestión. Cuando se hace Code Review hay que tener claro dos puntos importantes:
  1. Debe de hacerse desde un punto de vista objetivo e imparcial
  2. No debe usarse como herramienta de castigo hacia el autor del código fuente
Las dos reglas anteriores las tenemos que tener claras antes de empezar, porque si no no podremos aplicar los criterios con objetividad a la hora de hacer Code Review manual, ya sea individual o en grupo.
A partir de que este compañero se interesó por hacer Code Review sobre código Java, decidí intentar pensar en una lista de características que debía de cumplir el código para que recibiera el visto bueno de las personas que lo revisaban. Estas características las he diferenciado en tres grandes grupos: principios, estructura del código y codificación:
  • Principios o premisas iniciales sobre las que sustentar nuestra revisión de código:
    • DRYDon’t repeat yourself: No tengas código duplicado, potencia la reutilización
    • SRPSingle Responsibility Principle: Los métodos/clases solamente deben hacer/representar una y solamente una cosa
    • KISSKeep it Simple, Stupid!: Código fuente fácilmente entendible
    • Clean Code: Código manejable y mantenible
  • A nivel estructural el código debería de tener las siguientes características:
    • Los métodos deben ser pequeños, normalmente se suele definir un número aproximado de líneas como guía
    • El diagrama de clases debe ser lo más simple posible, pero siempre cumpliendo el principio SRP
    • La estructura debe permitir cambios futuros sin problemas
    • Las clases deben estar agrupadas por funcionalidad en sus respectivos paquetes
    • Hay que evitar el acoplamiento, es decir, los módulos o paquetes pueden ser intercambiados por otras alternativas sin problemas
    • Escalabilidad: El código debe portarse perfectamente en caso de que múltiples usuarios accedan a él
    • Verificar el uso de patrones de diseño
    • Evitar la pérdida de encapsulación
    • Identificar posibles cuellos de botella
    • Puntos de escritura en logs lo más eficientes posible
    • Identificación de posible bloqueos por inherencia de recursos en las aplicaciones multithread
    • Dependencias externas, como conexiones con bases de datos o servidores, correctamente manejadas
    • Identificar posibles memory leaks. Esto será complicado de ver en algunos casos y se aconseja complementar con pruebas de stress
  • Codificación o características para el código
    • Comprobar que no existe código innecesario (death code)
    • Comprobar que no existen bucles extra y/o evitar lo máximo posible los bucles anidados
    • Optimizar las sentencias “if-else“, y si podemos prescindir del uso de la clausura “else” mejor que mejor
    • Comprobar el uso de los métodos estáticos y los bloques de inicialización, rompen con el concepto de orientación a objetos
    • Respetar las convenciones de nombrado, longitud de los métodos/clases, formatos, …
    • Revisar los modificadores de acceso por la seguridad del desarrollo
    • Comprobar si existen tests unitarios que comprueben el código, si es así revisar que estos tengan sentido
    • Identificar posibles excepciones “escondidas
    • Evitar bloques “try-catch” que engloben demasiado código
    • Mensajes de error identificativos/descriptivos
    • Evitar en la medida de lo posible los valores hardcodeados en las variables locales
    • Revisión de posibles RuntimeExceptions, como por ejemplo los NullPointerException
    • Evitar errores típicos como el uso indebido de tipos numéricos como short o int para números muy grandes
Estos son puntos importantes a tener en cuenta cuando se realiza Code Review, pero no son los únicos, y dependiendo de las funcionalidad desarrolladas algunos de ellos aplicarán y otros no, pero aún así siempre es bueno tenerlos presentes. Cada equipo debe de establecer su Code Review Cheklist y adaptarla a sus necesidades. De todas formas, lo más lógico es siempre empezar con un lista de premisas muy relajada e ir revisándola para poder tener más reglas y más estrictas, y así ir aumentando de forma progresiva la calidad del código fuente.

 Aumentar la calidad del código, evitar bugs y esparcir conocimiento entre los miembros de los equipos son los principales beneficios de hacer Code Review, ¿por qué no lo íbamos a poner en práctica?

¿Cómo identificar un buen Product Owner?

Como dije en otro post ( Entrevista: Habilidades de un Product Owner ), un buen Product Owner debe ser una persona que cumpla las siguientes características:

  • Visionario
  • Líder y jugador de equipo
  • Emprendedor
  • Negociador y comunicador
  • Comprometido y capacitado
  • Cualificado y disponible

¿Cómo podemos identificar estas características en un Product Owner?

Hay características que no podremos identificar a simple vista, y necesitaremos conocer más a esa persona, pero aún así siempre habrá algunos indicadores que nos harán ver si esa persona es la idónea para este rol:

  • Un Product Owner visionario sería capaz de:
    • Dirigir el producto mediante el seguimiento y preveer la evolución
    • Describir requisitos a medio/largo plazo
    • Preocuparse más por la visión a medio/largo plazo que a corto plazo, aunque también la considera importante
    • Comunicarse con convicción sobre situaciones futuras a las que se quiere llegar
  • Para ser un buen líder y jugador de equipo:
    • No debe de dictar sus propias decisiones
    • No debe ser indeciso
    • No debe dejar de tomar decisiones y dejar que las tomen sus “subordinados”
    • Debe ser un guía de la innovación y el producto
    • Debe aprovechar el conocimiento y creatividad del equipo
    • Debe tomar las decisiones de forma colaborativa
  • Comprobar si tiene chispa emprendedora es tan sencillo como ver si:
    • Facilita la creatividad
    • Motiva la innovación
    • Esta confortable con cambios, ambigüedad, debate, conflicto, alegría, experimentación, ….
  • Un Product Owner es un gran negociador y comunicador cuando:
    • Manda mensajes simples y comprensibles
    • Es creíble
    • Controla sus emociones y es capaz de ponerse en el lugar del otro
    • Es concreto en sus mensajes
  • Si es comprometido y capacitado evidenciará que:
    • Esta seguro de sí mismo
    • Es entusiasta
    • Es enérgico
    • Es digno de confianza o es capaz de ganársela
  • Para comprobar si esta cualificado y disponible:
    • Debe ser o querer ser product owner full-time
    • Debe estar cómodo con equipos autoorganizados
    • Debe estar cómodo con el trabajo funcional

Conseguir identificar un buen Product Owner no es más que aplicar el sentido común desde un enfoque humano y de negocio al mismo tiempo.

Entrevista: “Habilidades de un Product Owner”

ScrumTv: Hoy desde ScrumTv, queremos hablar de una de las tareas más difíciles de una transición hacia las metodologías ágiles, identificar a las personas correctas para desarrollar distintos papeles en esta nueva organización. Entre estos nuevos roles se encuentran los Product Owner de cada producto de la compañia. En muchos casos, este rol no se da dentro de la propia organización si no que es el cliente que nos ha contratado o simplemente tenemos que contratar algún experto en dicho producto para que lidere su desarrollo.
Vamos a realizar una entrevista a Raúl Plaza, entusiasta de las metodologías ágiles, sobre las características que debería de tener un Product Owner.
Buenos días Raúl, que tal estas?

Raúl: Bien, gracias, para mí es un placer poder aportar algo a ScrumTv

ScrumTv: Bien entonces empecemos con la entrevista. ¿Qué significa ser un Product Owner?

Raúl: Dependiendo de quién responda a esta pregunta la respuesta será una u otra, aunque todas muy similares. Para mí, un Product Owner es la persona responsable de la visión de producto y del product backlog, con todo lo que conlleva, y se asegura de entregar el mayor valor posible de negocio al final de cada sprint. Es el representante del negocio para el ScrumTeam, para conseguir esto, tiene que abogar por la transparencia en todo momento y para todo el mundo.

ScrumTv: Y si tuvieras que identificar o contratar a un Product Owner, ¿Qué características debería tener?

Raúl: Me alegra que me hagas esta pregunta. Más de una vez nos hemos visto involucrados en este tipo de procesos y la verdad es que no es sencillo, pero intentaré aportar un poco más de luz. Creo que para poder identificar o contratar a un buen Product Owner, debemos de tener en cuenta las siguientes características:

  • Tiene que ser un visionario, ya que debe tener una visión final del producto y tiene que comunicar dicha visión a todo el mundo. Además debe ser capaz de establecer un plan, basado en funcionalidades, para poder llegar a dicha visión.
  • Estaría bien que fuera un líder y jugador de equipo al mismo tiempo, porque debe guiar el producto hacia dónde el negocio necesite pero siempre debe estar soportado por el equipo.
  • Proporcionar una chispa emprendedora, sería interesante, porque debe querer explorar nuevos ámbitos para el producto, aunque nunca debe de hacerlo sólo, como hemos dicho antes el equipo debe de ayudarle
  • Es imprescindible ser negociador y comunicador, porque gran parte de su trabajo consiste en interaccionar con los diferentes interesados en el producto, por lo que estas características se antojan necesarias
  • Ser comprometido y capacitado, le ayudará a tener suficiente apoyo y autoridad para poder liderar el esfuerzo de desarrollo y alinear a los stakeholders
  • Y por supuesto, cualificado y disponible, ya que debe conocer en profundidad el producto y no debe estar sobrecargado de tareas, para así poder estar disponible para el equipo cuando este lo necesite

ScrumTv: Aha, una vez que conocemos las características que debe tener un buen Product Owner, ¿Cómo las identificamos?

Raúl: Otra buena pregunta. Como todos sabemos habrá características que no podremos identificar a simple vista, y necesitaremos conocer más a esa persona, pero aún así siempre habrá algunos indicadores que nos harán ver si esa persona es la idónea para este rol. Aprovecho para hacer referencia a un post que escribí sobre ello:

¿Cómo identificar un buen Product Owner?

ScrumTv: Creo que nos han quedado bastante claras las habilidades que debe de tener un buen Product Owner. Muchas gracias por tu tiempo Raúl, y esperamos poder contar contigo en próximas entrevistas.

Raúl: Gracias a vosotros y hasta la próxima

Información recopilada desde: http://www.romanpichler.com/blog/roles/desirable-characteristics-of-a-product-owner/

The new kids on the wall (CAS2013)

Nos encontramos en un periodo de cambio. Los managers más rebeldes están buscando la forma de cambiar las cosas, y han logrado su primera victoria apostando por Agile. Aunque durante la batalla, encontrarán resistencias inesperadas, es cierto que también encontraran grandes aliados.
 
Desde hace años en una oficina de Madrid, en la que convivían un grupo de personas a diario, surgió la idea de cambiar la forma de hacer las cosas. Se inició una transformación Agile desde los rincones más oscuros del management, desde los procesos más rígidos jamás vistos y desde la comunicación más burocrática existente.
 
Llega la representación de como todo eso cambio a partir del “Origen” hasta llegar a la “Entropía Agile”, desde el lado oscuro hasta la luz al final del túnel, desde las catacumbas de los procesos por encima de los recursos hasta el trato personalizado de los miembros del equipo, …. Desde el génesis hasta la estabilización de la mejora continua, como Rumbo consiguió encontrar el camino hacia una metodología Agile.
 
 
Proximamente en Bilbao CAS2013 (11-12 Octubre)
 

Día a día de un Scrum Master

Muchos se preguntan que debe de hacer un Scrum Master una vez ha sido la daily a primera hora, después de esos 15 minutos de reunión que facilita dicho Scrum Master, ¿Cuál es su trabajo?. Hay gente que lo ve como un trabajo demasiado ambiguo y poco definido, en el que apenas hay unas directrices claras de lo que se debe realizar. Sin embargo, el Scrum Master tiene por delante duras y difíciles tareas que llevar a cabo en su día a día:
Tareas que debe realizar que afectan a todos los roles:
  • Debe facilitar, dinamizar y hacer productivas todas las reuniones de Scrum (preparación, moderación y cierre)
  • Actúa de formador y mentor: enseña a cada uno a ejecutar su papel dentro del marco de Scrum (equipo, PO, stakeholder, …)
  • Evangeliza en la organización el uso de metodologías ágiles
  • Debe ser consultor sobre cualquier cuestión en lo referente a Agile, al mismo tiempo que intercambia información con otros scrum masters de la organización
  • Mantener/Incrementar la motivación
  • Tiene que asegurarse de que no falte comida y cafe cuando el equipo trabaja hasta tarde
  • Potenciar la creatividad y la humildad intelectual
Tareas que debe de realizar con el equipo:
  • En el equipo promueve prácticas ágiles, no solo relacionadas con Scrum (programación por parejas, refactorización, TDD, propiedad colectiva de código, estimación en puntos, planning poker, kanban, …)
  • Es el lider servil del equipo
  • Mantiene y ejecuta con el equipo el plan de mejora continua
  • Diagnostica problemas y propone soluciones (junto al equipo)
  • Media en los conflictos entre el equipo y el PO o cualquier otro agente externo
  • Ayuda al equipo a tomar decisiones
  • Promueve la autoorganización
  • Quitar impedimentos al equipo, siempre y cuando el equipo no pueda solucionarlos. Conseguir o perseguir a quien sea para que cualquier problema sea resuelto cuanto antes y el equipo pueda trabajar sin nada que los frene.
  • Debe ayudar al equipo a intentar ser lo más productivo posible y así pueda conseguir los objetivos marcados
  • Proteger al equipo cuando se pide mucho de ellos, que no se comprometan a más de lo que puedan hacer, y también que no se vuelvan complacientes (servicio cafeteria), esto es más complicado, ya que si el equipo no quiere dar lo mejor y apunta a menos, hay problemas graves de motivación que tienen que solucionarse.
  • Asegurarse que se cumplen los compromisos del process backlog por parte del equipo, también debe detectar otras oportunidades de mejora.
  • Tiene que escuchar a la gente y estar seguro de que todo esta bien. Tener reuniones uno a uno puede ser una buena medida
  • Tiene que asegurarse de que el equipo cumple el Definition of Done
  • Tiene que generar un ambiente de confianza, comunicación y estabilidad, es decir, una atmósfera idónea
  • Debe ayudar al equipo a reportar
  • Debe ayudar al equipo a mantener el foco
  • Debe recordar al equipo sus acuerdos
  • Ayuda al equipo a mantener sus herramientas
Tareas que debe de realizar con el PO:
  • Asegurarse que el product backlog este priorizado (push al PO) y estimado (asegurandose de que el equipo estima las user stories).
  • Asegurarse que se construyen adecuadamente las “user stories” con la información necesaria para que el equipo pueda trabajar en ellas (criteria of ready)
  • Asegurarse de que se hagan Demos mostrando las nuevas funcionalidad del producto, de forma que se reciba feedback continuo
  • Tiene que asegurarse de que se hagan las release planning meetings, de forma que se organice el product backlog en releases (al menos hasta donde este priorizado) para poder ser predecibles a medio/largo plazo
  • Debe de promover encuentros periódicos con los stakeholders
Tareas que debe de realizar con la tecnología:
  • Implantar nuevos paradigmas de programación (TDD, BDD, Pair Programing, Refactor, Clean Code, Patterns, …)
  • Herramientas monitoring tecnico
  • Trainnings
  • Eliminación dependencias en la plataforma entre algunos proyectos y nueva arquitectura en algunos casos
  • Reducción costes de compilación y despliegue
  • Mejora de estaciones de trabajo (memoria e infraestructura)
  • Mejoras proceso actualización
  • Mejorar releases
  • Buscar la mejora continua para reducir el numero de bugs
Seguramente haya muchas más tareas que tenga que llevar a cabo o que surgirán de la mejora continua, pero creo que es un buen principio para poder empezar a ser un buen Scrum Master. En definitiva, sus objetivos principales son ser el lider en la implementación de Scrum dentro del equipo, debe de ser el motivador del cambio y de la lucha por la mejora continua.
Algunos enlaces de interés relacionados con este post y sobre los que me he basado para escribir este contenido son los siguientes:

Hola Mundo!!!

Dedicándome a la tecnología no podía empezar de otra forma mi primer post.

¿Por qué “Hola Mundo”?

Cuando empecé a estudiar programación, y como a la gran mayoría de vosotros, tuve que pasar por mi primera experiencia desarrollando, y esta fue como no, implementar un programa para mostrar por pantalla “Hola Mundo!!!”.  En ese momento me resultó un poco absurdo el mensaje y me preguntaba a mi mismo, ¿por qué no ponemos Hola y nuestro nombre? o ¿por qué no ponemos Hola o Buenos días?… Al cabo de los años y de desarrollar en diferentes lenguajes y enfrentarme a diferentes retos en mi vida universitaria y profesional, entendí que esa frase siempre me va a acompañar durante toda mi vida.

Detrás de esa frase hay otras connotaciones distintas a saludar, desde mi punto de vista estas dos palabras significan:

  • Esfuerzo: porque si estamos mostrando esta frase por pantalla quiere decir que hemos trabajado duro sobre algo que no conocemos o sobre algo que nunca habíamos trabajado
  • Inquietud/Curiosidad: porque estamos trabajando en algo que no es común en nuestro día a día y aunque sea por obligación estamos intentando entender como funciona para sacarle el mayor beneficio posible.
  • Evolución: porque hacer algo distinto a lo que solemos hacer significa evolucionar e intentar explorar otros ámbitos que no son comunes a nosotros significa que tenemos ganas de mejorar/avanzar en otro ámbitos
  • Inseguridad/Incomodidad: porque estamos explorando algo desconocido para nosotros y nos sabemos si lo estamos haciendo bien
  • Perseveración: porque seguramente al estar en un contexto desconocido para nosotros no hayamos conseguido ese ansiado “Hola Mundo” en nuestro primer intento
  • Nacimiento/Reinvención: porque no estamos saludándonos a nosotros mismos y no estamos saludando por saludar, estamos dando la bienvenida a un nuevo mundo entero para nosotros, estamos empezando a dar nuestros primeros pasos (como si de bebés se tratara) en este nuevo contexto, lo cual implica muchos nuevos retos en nuestra día a día a partir de este saludo.
  • Alegría: porque después de todo hemos conseguido nuestro objetivo, que aunque sea un pequeño paso en ese nuevo mundo, para nosotros es un gran paso, como diría el mismísimo Neil Armstrong.

Anteriormente dije que esta frase me va a acompañar toda la vida, y espero que así sea, porque eso significará que sigo esforzándome gracias a ser inquieto/curioso por intentar evolucionar en otro ámbitos, y aunque me cree inseguridad/incomodidad intentar “nacer” en estos nuevos mundos, al final perseveraré hasta que consiga mi objetivo, para llevarme la gran alegría de saber que estoy creciendo como persona y profesional.

Para acabar, quería decir que he estado mucho tiempo pensando en hacerme el blog porque no sabía si iba a ser capaz de escribir cosas interesantes o pensando si iba a tener tiempo para mantenerlo o simplemente dándole menos prioridad que otras cosas, pero al final me he decidido a ponerlo en marcha y decir por mi parte un nuevo “Hola Mundo!!”