FORO. ROLES DE SCRUM

Buenas tardes.

En la formación, en general, se define qué es el equipo de desarrollo y se da por sentado que se conocen sus integrantes.

Pero, ¿quién decide y con qué procedimiento quién debe formar parte del equipo de desarrollo?

Gracias,

Pascual

RESPUESTA

Pues en una organización deciden a este respecto las personas que tienen el poder y la autoridad para hacerlo. Me gusta pensar que según se vayan seleccionando a personas dentro del equipo se las hará partícipes en el proceso de selección de estas personas considerando su opinión como una opinión mas en el proceso y validando que existe un encaje entre todos inicial.

Read More

FORO. INTRODUCCIÓN A SCRUM

Buenas noches. Deseo acercar algunas preguntas que me surgen luego de abordar el Modúlo 3.

- Sobre los Stakeholders, como se define el alcance( es decir cuantos y quienes serán considerados como tal??) Quien es el encargado de hacer esta definición? que parametros se tienen en cuenta?? ( mas allá de los mencionados en el apunte).

-Sobre la Pila de Producto: Quien o quienes son los responsables de recopliar y dar orden de prioridad a la misma?? el Dueño del Producto junto a los stakeholders??...se suma también al Scrum Master?

-Sobre la Pila de Sprint: una vez definida, como y quién define la secuencia de actividades y determina asignación de roles?, es una actividad que se puede delegar al propio Equipo de Construcción??

-Sobre el Equipo de Construcción: al entender que el mismo ha de ser multidisciplinario, que parametros han de ser considerados para definir quienes lo deben integrar??

-Por último, en cuanto a vuestra experiencia, que competencias de índole genéricas (no técnicas sino aquellas que son útiles y aplicables indistintamente  del ámbito de proyecto que se realiza) son aconsejables que posean los roles de Dueño del Producto y Scrum Master??

Bueno, estas por ahora son las 1ras inquietudes que me van surgiendo, desde ya agradezco sus aportes y respuestas.

RESPUESTAS

Te cuento mi visión sobre las cuestiones que planteas:

- Stakeholders. Una buena idea en general es hacer un Inception antes de arrancar. Parte de ese ejercicio es un mapa de Stakeholders, planteando impacto e influencia. Mi preferencia es, dentro de un orden, pecar por exceso que por defecto. Es decir, si dudo en un SH porque creo que sólo "nos tocaremos" con él/élla en un par de ocasiones, les incluyo. Luego habrá tiempo para que se diluya un poco la intervención... luego suele costar un poco más subir a bordo a quien no sabe nada sobre el producto en el que trabajamos.

- Pila de Producto. Ya sabes que, aunque el producto es de todos, es el PO quien recoge, cuida, prioriza y mantiene viva el Product Backlog. Eso sí, siempre en constante relación y colaboración con el Equipo de Construcción, los SH y, claro que sí, el SM.

- Pila del Sprint. Estamos ante un equipo autoorganizado. Es el propio Equipo de Construcción quien se asigna y trabaja en las historias y tareas que estiman que podrán acometer durante la iteración... evitando que alguien "asigne tareas a recursos", fomentamos la autoorganización y la madurez del Equipo.

- Equipo de Construcción. Es una buena cuestión a tratar en un Inception, antes de comenzar... recuerda que, idealmente, el equipo será estable (aunque, claro, siempre pueden surgir cuestiones imprevistas). En cuanto a las características o habilidades, procuraría que el Equipo recogiera todas las necesarias para poder construir el producto ellos solos (claro, habrá cosas que trabajar con Arquitectura u otras áreas, pero estos serían parte de la constelación de colaboradores).

- Competencias genéricas de un PO y SM. Para ambos, el trabajo en equipo, el mindset Agile y un conocimiento del ámbito de negocio y cliente. Para el PO, más conocimiento de negocio (idealmente sería alguien, de hecho, de negocio), capacidad de negociación, interacción a varios niveles, resiliencia y creatividad. Para el SM, que "viva" los valores y principios, capacidad de negociación, empatía, adaptabilidad, influencia, coraje... sería una larga lista.

- Inception: Es una labor que recomendamos mucho. Se trata de una serie de sesiones que se realiza antes de comenzar y donde se trata, entre otras cosas, de ver qué es el producto. Analizar las necesidades, plantear la comunidad de producto/proyecto, qué cosas nos preocupan, gestión de riesgos, métricas, modelo de colaboración y comunicación, los primeros Mínimos Productos Viables... 

- Constelación de colaboradores: Es una forma de nombrar la "Comunidad de proyecto", por decirlo de algún modo. Es el conjunto de áreas y personas con las que el Equipo Scrum se va a relacionar a lo largo de la construcción del producto (y no sólo los Stakeholders)... pueden ser otras áreas técnicas, funcionales, etc.

- Mindset Agile: Aquí me refiero a que Agile es, para mí, un modo de pensar, de posicionarte en la gestión del producto; no es una metodología, un método o una herramienta... es más bien una forma de pensar.

Read More

FORO. MANIFIESTO AGIL

Hola Noemí

Uno de los valores del Manifiesto Ágil consiste en entregar una funcionalidad del software terminado antes de enfocarse en la documentación exhaustiva, mi pregunta es la siguiente:

¿Se puede tener una metodología híbrida entre una ágil y una tradicional, para contar con la documentación necesaria que es imprescindible en auditorías?

Los que trabajamos en el sector público, siempre estamos expuestos a auditorías constantes por entidades externas que nos solicitan muchos documentos técnicos y funcionales, que en el caso de no contar con toda la documentación solicitada podemos incluso obtener alguna sanción.

Respuesta:

El manifiesto ágil lo que dice es que VALORAMOS mas el software funcionando que la documentación exhaustiva, esto quiere decir que ambas son importantes pero que lo que realmente importa es que el software funcione y haga lo que tiene que hacer. 

Dicho esto, toda documentación que sea necesaria habrá que generarla. El manifiesto ágil nunca dijo que no hubiera que trabajar con documentación solo que nuestro foco no sea ese principalmente si no hacer software.

Read More

PRIMEROS SERVICIOS

Ahora vamos a ver un pequeño recorrido que podemos 

realizar bajo para implementarlo: 

1. (1)  Crear espacio para la colaboración del equipo.  
2. (2) Controlar y evitar la sobrecarga.
3. (3) Ser transparente sobre el estado del proyecto (disminuye el riesgo)
4. (4)  Mejorar la priorización y entrega de valor.
5. (5)  Dar visibilidad al flujo de trabajo.
6. (6)  Anticiparnos a los posibles cuellos de botella.
7. (7)  Identificar desperdicios del proceso.

Vamos a generar un espacio donde el equipo comienza a colaborar, para ellos la utilización de tableros y el uso de políticas explícitas nos servirán de gran ayuda para generar este contexto colaborativo una vez que hemos visualizado y gestionado el flujo de trabajo deberemos controlar los cuellos de botella para evitar la sobrecarga de nuestro equipo, aquí podemos utilizar las teorías de restricciones como herramienta para gestionar y maximizar estos cuellos de botella, uno de los efectos colaterales que conlleva el uso de es que todo el trabajo en curso se encuentra representado y visualizado en un solo punto, esto hace que aumente la transparencia y por tanto el correspondiente aumento de la confianza tanto dentro como hacia fuera del equipo, muchas veces nos pasa que no somos capaces de saber lo que aportan valor a nuestros clientes, para poder priorizar de la mejor manera con KanBa conseguimos aclarar ciertas dudas en la priorización de los tipos de tareas que contengan el tablero, si para cada tarjeta aplicamos una política explícita diferente de priorización conseguiremos tener claro con menor carga de gestión por parte de los implicados, ya hemos visto que este es el beneficio inicial que nos encontramos al usar Kanban, conseguiremos dar visibilidad a gran parte de las tareas que realizamos pero que todavía no son visibles para el resto de compañeros, esta manera daremos esa visibilidad a todo este trabajo con el uso de Kanban, ni una correcta visualización de las tareas en curso nos permitirá desde su observación, anticiparnos a los posibles cuellos de botella, que pudiera ver en el momento que observamos una anomála  acumulación de tarea en uno de los estados será un indicador de un posible cuello de botella, también podremos recurrir a la teoría de restricciones para tratar de maximizar o eliminar estos cuellos de botella al poder visualizar todo el flujo podremos detectar todo esos desperdicios, entendido desperdicio como la tarea que nos aporta valor directo al usuario, por tanto disminuyendo todos estos desperdicios o incluso eliminándolos todos, conseguiremos un aumento de la eficiencia del proceso, no olvidemos que la mejora continua es el eje principal del Kamban al implementar todos los pasos anteriores estableciendo ese proceso de mejora lo que repercutirá en beneficio a todo el equipo y la organización con el paso del tiempo. 

Read More

CLASES DE SERVICIO

Las clases de servicio nos indican los tipos diferentes de tareas que vamos a ser capaces de gestionar en nuestro tablero. Tenemos que tener presente que pueden aparecer diferentes tipos de tareas dentro de nuestro tablero. Cada uno de estos tipos de tarea tendrán generalmente una gestión diferente.

Algo muy importante que tenemos que tener presente cuando estamos implementando Kanba son las clases de servicio, una vez que hemos tenido en cuenta las cinco prácticas, lo siguiente qué debemos pensar es en qué clases de servicio tenemos.  ¿Qué es una clase Servicio? al final es una agrupación de diferentes tareas en función del tratamiento que le vamos a dar a cada una de ellas, en este caso yo dibujado tres clases de servicios que podría ser tres tipos de tarea:

·       clase de servicio urgente

·       clase de servicio normal

·       clase de servicio con tiempo fijo o tiempo definido

Estas tres clases una prioridad diferente y por tanto tendrán un tratamiento diferente dentro de nuestros tablero, en este caso por ejemplo para el tratamiento de la clase de servicio urgente hemos decidido en el tablero generar una nueva columna, una nueva fila en la parte superior con un tratamiento especial de tal manera que lo que nos interesa es que cuando se genere una tarea de tipo urgente en esta fila y vaya lo más rápido posible para cada clase de servicio por tanto deberemos establecer políticas explícitas para cada una de ellas de tal manera que en este caso decidimos que la tarea urgente va a ser manejada e inmediatamente se produzca por la gente del equipo, otros tipos de política que por ejemplo podemos tener con las tareas con las clases de servicio de tiempo definido es que lo vamos a poner a trabajar, por ejemplo, mínimo una semana antes del tiempo fijado que tienen de finalización eso podría ser una política explícita que como hemos visto antes en los principios y las prácticas debería ser visible y que tuviera explícitamente indicada en algún sitio.  Por recapitular, cuando tengas nuestro tablero al pensar a nivel de clase de servicio, lo que vamos a tener que pensar, es que (1) tipología de tarea vamos a tener; (2) qué tratamiento le queremos dar a cada tipo de tarea a cada clase de servicio; y (3) con qué prioridad la vamos a manejar y (4) que políticas explícita vamos a asociar a cada una de ellas; esas políticas tendrán o no reflejo a la hora de gestionar esas tareas dentro de nuestro tablero.  

Read More

PRINCIPIOS Y PRÁCTICAS

El método Kanban está basado en una serie de principios o valores, así como una serie de prácticas de uso.

Los tres principios

·       Empiece donde esta

·       Cambio incremental y evolutivo

·       Respeto por los roles actuales

Kanban va por un cambio poco a poco. Cambio progresivo, donde quién está es un buen momento para empezar.

Scrum = cambio de rols

Kanban eso que hace es respeto por lo que tenemos en la actualidad y a partir de allí mediante el cambio incremental y evolutivo, iremos trabajando en estos roles para ir consiguiendo este cambio.

Las cinco prácticas

·       Visualizar flujo de trabajo. Nos obliga a pensar. Fases de las tareas, limites de las tareas, personas implicadas con las tareas.

·   

    Limitar WINB (Word in progress). Trabajo en progreso.      Cuánto más trabajo tenemos en proceso más cosas tenemos realziandose en forma.

·       Gestionar el flujo

·       Políticas explicitas

·       Mejoras colaborativas. Adaptarnos. Cambio organizacional / cultural.

·       Evolución empírica.

Read More

BREVE HISTORIA DE KANBAN

Sistema de Producción Toyota

Es en el 2003 con el libro desarrollo de software link donde Tom y Mary poppendieck popularizan el término lean aplicado al mundo del desarrollo web, y su asociación al mundo ágil. Tome y Mary hacen hincapié en su libro en los siguientes puntos: (1) eliminación de burocracia en desarrollo de productos; (2)fomentar el aprendizaje mediante ciclos cortos y frecuentes; (3) interacciones rápidas para conseguir entrega de valor a los clientes  rápidamente de esta manera conseguiremos obtener un feedback que tire (pull) de los productos; (4) en lugar de documentos de requisitos y planes rígidos que empujen (push) el trabajo de desarrollo.

En este libro destaca  los siguientes principios de desarrollo lean:

·       Optimizar el todo

·       Eliminar desperdicios

·       Calidad en la construcción

·       Aprender constantemente

·       Entregar rápido

·       Involucrar a todo el mundo

·       Seguir mejorando

David Anderson implementa el primer sistema Kanban para la creación de software en Microsoft aparece como metodología de mejora de procesos en general y no sólo como un sistema para visualizar los flujos de trabajo en base a sus experimentaciones de Kanban como proceso de mejora continua David Anderson  presenta kanban como un enfoque para el cambio organizacional en la conferencia ágiles de Washington de campaña hasta la actualidad ha dado lugar a que ya no sea una técnica específica sólo del mundo de desarrollo de software o la industria manufacturera sino que su aplicación es bastante amplia ya que tiene como objetivo fundamental el de gestionar de manera general como se va completando las tareas con el andas en un seminario una manera de utilizar kanban junto con scrum en lo bautizaría como Scrumban mezclando lo mejor de ambos enfoques.

Read More