Desarrollo Agil. Introduccion a desarrollo agil. Periodo: Inicio: Ago 14, 2012 Termino: Nov 27, 2012

Transcripción

1 Desarrollo Agil Introduccion a desarrollo agil Periodo: Inicio: Ago 14, 2012 Termino: Nov 27, 2012

2 Agenda Origenes Propiedades de los sistemas kanban en el mundo real. Propiedades de los sistemas kanban virtuales. Introduccion al metodo de kanban Caso de Estudio «Microsoft» Implementando Kanban Tarea Bibliografía

3 Kanban en la Manufactura El flujo del proceso permite extraer partes cuando se necesite, y provee instrucciones de producción.

4 Ejemplo

5 Reglas en la manufactura Secuencia (Downstream) (Cliente) El consumo debe estar especificado por kanban. Upstream (Proveedor) La producción debe estar especificada por kanban Ningún producto es hecho o movido sin un kanban Kanban debería estar asociado a cada producto en todo momento. El numero de kanbans es minimizado.

6 Propiedades de Kanban en la manufactura. Ajustable (Attached) Kaizen (Mejora Continua). Fisico Visual Señales (Refleja estatus) Auto Dirigido (Evita micro administracion) Jalar (Pull) Limitar WIP Flujo Continuo

7 Propiedades de Kanban en desarrollo de software Visuales? Fisicos? Adjuntables?

8 Peticiones de trabajo:

9 Ejemplo: Ready (2) Story Story Develop (2) Accept (3) Story Story Deploy

10 El metodo kanban Visualizar el flujo de trabajo Limitar el trabajo en el proceso Medir y administrar el flujo Hacer las politicas del proceso explicitas. Hacer uso de los modelos para reconocer oportunidades de mejora.

11 Receta para el éxito:

12 Enfoque en la calidad

13 Reduccion de trabajo = Mejora de calidad.

14 Entregas Constantes El manifiesto de desarrollo agil indica «Entregar software funcional frecuentemente» Reducir el trabajo del proceso (WIP) en ciclos de tiempo mas cortos. Ciclos de tiempo mas cortos permiten liberaciones mas frecuentes. Liberaciones frecuentes producen confianza. «Entregar liberaciones pequeñas, frecuentes, con alta calidad crea mayor confianza con los involucrados en el equipo a diferencia de liberaciones grandes y menos frecuentes» - David J. Anderson

15 Balancear demandas contra las salidas. Regular la demanda entrante Igualar la demanda entrante a el trabajo entregado. La efectividad de esto dara una medida para el WIP Solo trabajar en los pendientes que demanda el sistema. Las actividades de cuello de botella se volveran visibles. Algunas areas se volveran algo flojas. Esto permite hacer uso de «kaizen» (Mejora Continua) Recordar, Optimizar el sistema por flujo, no por el 100% de la utilizacion del recurso.

16 Que hemos hecho? La Calidad es mejor El equipo se encuentra trabajando en caracteristicas de mayor valor agregado. Mejor la confianza de los clientes. WIP es limitado, los ciclos de tiempo son mas cortos Los clientes esta viendo el valor mas pronto. Los desarrolladores tienen reatroalimentacion mas rapido. Entregas mas frecuentes. Tambien mejora la confianza.

17 Asignación de Prioridades y Planeación Las prioridades actuales típicamente se encuentran fuera del control del equipo de desarrollo. El equipo puede influir sobre las prioridades, pero esto requiere de confianza. Deben asignarse las prioridades por valor de negocio. Requiere madurez organizacional. Requiere de un equipo de desarrollo maduro y de marcha suave.

18 Atacar las fuentes de variabilidad. La variabilidad es el resultado de WIP s y ciclos de tiempo largos. Muchas de las fuentes son bien conocidas. El tamaño de la historia Prioridades Algunas políticas producen variabilidad innecesaria. Ejemplo: Las pilas están organizadas El hacer las políticas de forma explicita puede revelar estos efectos. Cambiar políticas puede reducir la variabilidad NO toda la variabilidad es desperdicio. «No podemos agregar valor son agregar variabilidad, pero podemos agregar variabilidad sin agregar valor» - Donal Reinertson

19 Caso de Estudio (Microsoft) Pequeño grupo de 3 desarrolladores y 3 testers. SDLC (System Development Life Cycle) era el utilizado por la administración; cambiarlo no era una opción. Desarrollo de actualizaciones y Bug-Fix para 80 aplicaciones funcionales a lo largo de Microsoft. El equipo produjo lo que se le solicito, generalmente con buena calidad. Una tarea de ciclo de tiempo de 5 meses, creciendo incontroladamente.

20 Visualización del flujo de trabajo. Administradores Backlog 3 Desarrolladores 3 Testers UAT Cerca de 7 nuevas peticiones por mes. El backlog se mantuvo con una pila de 80 peticiones. Una vez al mes el backlog era priorizado. En promedio las peticiones tomaban 11 días de esfuerzo.

21 Política de estimación Las nuevas peticiones deben ser estimadas por el equipo en un plazo de 48 horas.

22 Bibliografía Personal Kanban Mapping Work Navigating Life Jim Benson, Tonianne DeMaria Barry Feb 2011 Kanban Successful Evolutionary Change for Your Technology Business David J. Anderson, Donald G. Reinertsen. Apr 2010