Más allá del remoto: rompiendo el hielo con icebreakers

Con todo esto del trabajo en remoto estamos todos en casa o yendo a la oficina solo unos poco días. Así que de vez en cuando es necesario que todo el equipo se junte para trabajar juntos, vernos las caras y en muchos casos conocernos más allá de una pantalla y una webcam. Todos sabemos que para crear producto sofware la vertiente humana es importante. Poder conocer a las personas con las que trabajas más allá de las code reviews, las daily meetings y reuniones varias es algo que creo que aporta mucho al equipo. Continúa leyendo Más allá del remoto: rompiendo el hielo con icebreakers

Productividad: Email, calendario, notificaciones, tiempo…

En estos días de COVID-19, de teletrabajo y de una realidad un tanto incierta voy a hablar un poco sobre productividad. Estos días de confinamiento he estado ojeando infinidad de post sobre teletrabajo, mantener la comunicación ahora que estamos confinados, sobre productividad,… y un largo etcétera de temas similares. Así que me he animado a contar como organizo mi día a día en el MundoReal™ y no solo en estos días de aislamiento.

Antes de continuar, todo lo que escribo en este post me aplica a mi y a mis circunstancias, mis sesgos,… quizás no sean extrapolables a las tuyas. Sólo cuento como me organizo por si alguien puede coger ideas.

Continúa leyendo «Productividad: Email, calendario, notificaciones, tiempo…»

Anuncio publicitario

Lead Dev: no tengo ni idea de qué es eso

¿Qué es un Tech Lead? ¿Qué es un Lead Dev?¿Engineering Manager? Todos son roles que una persona puede desempeñar dentro una compañía. Hasta hay vamos bien, el problema viene cuando tenemos que definir las responsabilidades de este rol…

En cada compañía se hace de una manera. Podemos encontrar compañías en la que el career path es público y por tanto conocer cuales son las responsabilidades y/o habilidades que se suponen para dicho rol. Por ejemplo tenemos Patreon Engineering Levels donde definen las habilidades y responsabilidades de cada nivel. También tenemos Medium Engineering Growth Rubric (más visual aquí) donde ponen incluso ponen ejemplos de cada lo que debería hacer una persona dentro de un nivel. Otro ejemplo más de Monzo. En mi caso, el Lead Dev se define como el CTO de un producto encargado de definir la visión técnica para alcanzar los objetivos de negocio establecidos por el Product Owner.  La cuestión es ¿qué pasa cuando te dicen: ‘¿te gustaría ser Lead Dev de este equipo?’ o lo más habitual… a partir de X eres el Lead Dev del equipo.

Continúa leyendo «Lead Dev: no tengo ni idea de qué es eso»

¿Cuánto vas a tardar? Técnicas para estimar

  Estimar, ¿cuanto cuesta hacer esto?¿como lo estimamos? No tengo ni idea de como cuanto voy a tardar y predecir el futuro nunca ha sido lo mío. Las técnicas de estimación «ágiles» son colaborativas, todas las personas involucradas en el proceso deberían colaborar. Del mismo modo, estas técnicas están pensadas para ser rápidas y que … Continúa leyendo ¿Cuánto vas a tardar? Técnicas para estimar

Requisitos, tareas, historias, prioridades, objetivos,… distintas técnicas para priorizar un product backlog

Requisitos, tareas, historias, prioridades objetivos,… una de las cosas más difíciles a la hora de desarrollar un producto software no es la arquitectura, ni los test, ni siquiera el lenguaje de programación, los más complicado es saber que hacer en el momento adecuado. Qué tenemos que construir, por qué vamos a hacerlo, como lo haremos y que es lo que va primero.

Sí, estoy hablando de priorizar, de objetivos. Así que aquí voy a intentar descubrir algunas técnicas para priorizar un product backlog o al menos intentarlo. No vamos a entrar en detalle de como hacerlo, hay miles de recursos que seguro lo explican mucho mejor que yo, solo quiero tener una pequeña lista de técnicas y un par de pinceladas de cómo funcionan.

6350781099_18e39fc20e_z

Continúa leyendo «Requisitos, tareas, historias, prioridades, objetivos,… distintas técnicas para priorizar un product backlog»

mi experiencia con el curso y la certificación de «Professional Scrum Master I»

Hace un tiempo asistí al curso de Professional Scrum Master impartido por Jerónimo Palacios. Mi idea, en un principio era mejorar mi conocimiento sobre Scrum y afianzar ese conocimiento presentándome al examen de certificación Profesional Scrum Master I.

Aquí me gustaría contar como fue todo, como preparé el curso y la certificación y algunos consejos para el examen. Resumiendo mucho: el curso estuvo genial, aprendí un montón y me sirvió como punto de partida para estudiar a fondo la guía de Scrum. Ese conocimiento sobre Scrum, sus artefactos, roles y ceremonias, me sirvió para poder superar un examen tipo test en inglés con multi-respuesta, en el que hay 80 preguntas y hay que sacar más de un 85% de acierto, todo ello en menos de 60 minutos.

SONY DSC

Continúa leyendo «mi experiencia con el curso y la certificación de «Professional Scrum Master I»»

Estimación y medición en Kanban

Ya hemos hablado anteriormente de Kanban y de cómo mezclar lo con Scrum para implantar una cultura Agile dentro de nuestros proyectos. Uno de los objetivos de todo del manifiesto ágil es entregar software que funciona y que el cliente necesita. Por ello herramientas como Kanban nos ayudan a tener una visión global del proyecto.

Este post es una traducción libre de http://java.dzone.com/articles/estimation-and-measurement

Continúa leyendo «Estimación y medición en Kanban»

De Scrum a Lean – Kanban una gran herramienta

El otro día ya empezamos a traducir el artículo “De Scrum a Lean” publicado aquí: http://net.tutsplus.com/articles/editorials/from-scrum-to-lean/. En él se habla de los principios de Lean y de cómo con esos principios podemos adaptarlos al desarrollo de software, en este caso vamos a comentar los principios del Kanban y cómo aplicar esta técnica al desarrollo software y sobre todo cuando tenemos como base una metodología Scrum y un equipo que congenia bien.

Kanban una gran herramienta

Hay varias técnicas y herramientas para hacer el trabajo de Lean. Prefiero Kanban, una herramienta basada en tableros, similar al tablero de planificación de Scrum. Podemos imaginar kanban como un embudo doble

Continúa leyendo «De Scrum a Lean – Kanban una gran herramienta»

De Scrum a Lean – aprendiendo un poco

Aunque el objetivo principal de Scrum es la organización y la gestión de proyecto, Lean se centra más en los procesos con el fin de producir más rápidamente productos de calidad. Este modelo de gestión (Lean) puede ser útil para empezar a adoptar principios ágiles, o puede ser a lo que evolucione tu equipo cuando Scrum no es suficiente.

Esta es la historia de Parkos Csaba publicada aquí: http://net.tutsplus.com/articles/editorials/from-scrum-to-lean/, me pareció interesante traducirla y compartirla .

Un poco de historia

Lean es un conjunto de principios definidos por la industria de fabricación de automóviles de Japón en la década de 1980. El ingeniero de calidad de Toyota, John Krafcik, acuñó el término, mientras que la observaba los procesos y herramientas utilizadas para “eliminar el desperdicio” en la producción de automóviles en masa. Aunque no fue hasta 2003 cuando Mary y Tom Poppendieck introdujeron el término Lean como  un proceso de desarrollo software en su libro, Lean Software Development: An Agile Toolkit.

Considerando Scrum como un conjunto de reglas y roles, Lean es un conjunto de principios y conceptos con algunas herramientas. Ambos son considerados como técnicas ágiles, y comparten la misma ideología de entrega rápida mientras reducen defectos y errores. Siempre me gusta enfatizar la adaptación ágil, pero no podemos olvidar  que Scrum se presenta como un conjunto de reglas obligatorias. De hecho algunos fanáticos de Scrum ponen el grito en el cielo si estar reglas no se siguen al pie de la letra.

Continúa leyendo «De Scrum a Lean – aprendiendo un poco»