Crónicas de una Aplicación en Agilidad

La Retrospectiva (Imagen: nearsoft) Hace tiempo que no escribo una nueva crónica, pero es que ha transcurrido mucho tiempo desde que no he aplicado alguna herramienta de facilitación en el ámbito laboral. La cuento a continuación. Acababa el mes en mi centro de trabajo, y una de las nuevas implementaciones de parte del supervisor era realizar una reunión de "Lecciones Aprendidas", en donde se analizaba junto a todo el equipo el resumen de las actividades realizadas durante el mes. Cuando escuché respecto a esta reunión, pensé: "esta reunión es para aprender las lecciones aprendidas, ¿no es una suerte de Retrospectiva?". En ese momento, fui a conversar con el líder del equipo: era una oportunidad para realizar una sesión de retrospectiva dentro de mi centro de trabajo, y no la quería dejar pasar. Si bien nuestro equipo no realiza practicas ágiles, eso no era (ni es) impedimento para adaptar esa reunión de "Lecciones Aprendidas" a una sesión d

Exposición del Proyecto - 2016 LOS SPRINTS Empezamos con un detalle a tomar: yo trabajando en una empresa y el equipo todavía en clases. No teníamos un lugar propio para trabajar ni tampoco íbamos a trabajar juntos. Un gran inconveniente si queríamos trabajo bajo Scrum. Entonces, ¿qué decidimos?  Para nuestro backlog utilizamos Trello. Me encargué de agregar las historias de usuario dentro de la herramienta y todos teníamos la visualización necesaria. Nuestras "reuniones diarias" la trabajamos en horas de la noche a través de Hangouts. Realizábamos una videollamada de 15 minutos y nos poníamos todos alineados. Cuando por alguna razón no se podía realizar, Slack fue nuestra herramienta de apoyo para poder realizar nuestros daily meetings. Anotábamos las respuestas a las 3 preguntas a través de un mensaje y así manteníamos la transparencia en la medida que lo podíamos mantener. SPRINT REVIEW Y RETROSPECTIVA El Sprint Review resultó, en palabras del equip

Equipo Codephilia de la UNT Hace poco unos estudiantes de la escuela de Informática de la Universidad Nacional de Trujillo conversaron conmigo para que les ayudara con su proyecto para un concurso de proyectos, que se realizaría en la escuela. Les explique en que manera iba a poder ayudarlos, y mas que una persona que les ordenaría que hacer, iba a ser una persona que les ayudaría a que ellos mismos encontraran su camino y su forma de trabajar. EL INICIO En un principio les sonó un poco extraño, pero aceptaron y decidimos empezar. Comencé conociéndolos un poco mas y saber de primera mano quienes eran. A partir de ahí hicimos lo que les escribo a continuación: Product Vision Board: Tomado desde la pagina de Roman Pichler. Esta plantilla nos dio una visión general del producto que querían construir, basándose en 5 puntos: VISION: La visión de tu idea, resumida en una oración. TARGET GROUP: Usuarios, clientes o segmento de mercado en donde aplicaría tu idea. NEE

Foto: The Internship (Pasantes Fuera de Linea - 2013) En mi vida como deportista, he compartido con muchos compañeros, muchos entrenadores, muchas ideas, etc. Muchas de esta experiencias no fueron tan agradables y satisfactorias; muchas de ellas tenían un factor en común, ya sea para el éxito o fracaso de la campaña: La formación del equipo. Lo mismo sucede en un proyecto de software. En los pocos proyectos en los que he participado, me he topado  jefes de proyectos, miembros de equipo, analistas, gerentes... y todas esas experiencias han sido satisfactorias como de fracaso. Y en muchas de ellas, el equipo tuvo un papel importante.  ¿Y qué es lo que hace que un equipo sea parte del fracaso? Muchas veces, las circunstancias no te permiten desenvolverte adecuadamente (burocracia everywhere, clientes que no saben que pedirte, y que al final "si pidió hacerlo"). En algunas ocasiones, los retos son demasiados para los skills de un miembro del equipo. Esto muchas v

Neurocapital Humano "TRABAJO COLABORATIVO CON EL CLIENTE sobre una negociación contractual" Este es uno de los puntos del Manifiesto Ágil que a mi parecer es uno de los mas difíciles de adoptar. No solo porque la mayoría de los clientes están acostumbrados  a "encontrarse con los desarrolladores al inicio y al final de los proyectos", sino que ademas cada cliente es diferente, y uno debe aprender a entablar una relación laboral  de acuerdo a su forma de pensar. Hace unos meses, trabajamos en un proyecto para un comercio electronico. Al inicio del proyecto, se trabajo con ellos (dos personas de la empresa que tenían involucramiento directo con el proyecto) la Incepción Ágil , se mapeo todas las funcionalidades y se dio el visto bueno para el proyecto. Hasta ese punto, y antes de de finalizar el primer Sprint, todo estaba marchando de manera fluida y muy eficaz. Sin embargo, todo cambio a partir del primer Sprint Review. El Sprint Review se real

Desde que empece a desarrollarme como Scrum Master, la mayoria de las veces me topé con muchos incovenientes que causaban cierto malestar en el medio de un proyecto: - ¿Qué estamos desarrollando realmente? - ¿Todo el equipo sabe el por que del proyecto? - ¿El cliente realmente esta seguro que se desarrollará lo que desea? Hubieron ocasiones que los tiempos no cuadraron, que el equipo de desarrollo no sabia exactamente que hacer y, un caso muy particular, el precio era muy poco para lo que estuvimos desarrollando. Entonces se te viene a la mente ¿qué manera habrá para poder evitar estos incovenientes? Todas estas preguntas terminan siendo resueltas con la Incepcion Ágil. Desarrollado por Jonathan Rasmusson en su libro The Agile Samurai, estas 10 dinamicas tienen el objetivo de alinear, tanto al cliente como el equipo de desarrollo, en todo el proyecto. Hace poco llevé un curso de Incepcion Agil online, en el cual pude obtener nuevas formas y tecnicas que me ayudaro