ISO 9001:2008 y Agile. Nuestra experiencia

Transcripción

1 ISO 9001:2008 y Agile Nuestra experiencia

2 Contenidos 1. Quiénes somos 2. Por qué ISO Qué es ISO Qué es Agile 5. Estrategia 6. Diseño 7. Lecciones aprendidas

3 Quiénes somos?

4 Quiénes somos? Taller Technologies Argentina es una empresa de servicios de desarrollo de software a medida de alta calidad. Proveemos nuestros servicios a clientes globales en tres principales áreas: Desarrollo de software embebido y de tiempo real para sistemas de misión crítica y alta disponibilidad Desarrollo de software para dispositivos móviles en plataformas Android y ios Desarrollo de aplicaciones y servicios web

5 Quiénes somos? Hemos obtenido resultados exitosos tanto en exigentes entornos de calidad aplicando rigurosas prácticas de ingeniería, como en negocios de alta volatilidad donde la flexibilidad y la rapidez de entrega es crucial. Entre nuestros clientes se encuentran: Intel (EE.UU.), Manpower (EE.UU.), INVAP (Argentina), MercadoLibre (Argentina), CONAE (Agencia Espacial Argentina), Kohl's (EE.UU.) y Harley-Davidson (EE.UU.). Contamos con más de 60 empleados en nuestras oficinas en Córdoba (Argentina).

6 Quiénes somos? Utilizamos un modelo de trabajo donde priorizamos: La transparencia para que el cliente conozca con quien trabaja, cómo se realiza el trabajo y el estado de avance del proyecto La entrega frecuente del producto funcionando, para obtener feedback de manera rápida, validar ideas y determinar si el curso elegido para el proyecto o producto es el adecuado, basando las decisiones en resultados concretos La colaboración y comunicación fluida, donde el cliente y nuestros equipos trabajan juntos para lograr el mayor impacto para el negocio. Tenemos experiencia trabajando con las siguientes tecnologías: Lenguajes C y C++ sobre sistemas operativos Linux, RTEMS (sistema operativo de tiempo real) y plataformas X86 y ARM. Objetive-C para ios y Java para Android. J2EE con Spring, Hibernate, y otros frameworks para el desarrollo de aplicaciones y servicios web.

7 Por qué ISO?

8 Por qué ISO? Cumplir con requerimientos de clientes Nuevos clientes Entender y comunicar nuestros procesos Ley de software Cultura profesional Consistencia de las operaciones Mejora de la eficiencia Reconocimiento internacional

9 Por qué ISO? + calidad idad Calidad: la totalidad de las características de una entidad que le confiere la aptitud para satisfacer las necesidades establecidas e implícitas. ISO/IEC 8402

10 Qué es ISO?

11 Qué es ISO? La norma ISO 9001:2008 es una norma internacional que determina los requisitos, para establecer un sistema de gestión de la calidad de los procesos de una organización. Establece todos los elementos que debe contar el sistema de gestión, para tener un sistema efectivo que le permita administrar y mejorar la calidad de sus productos o servicios.

12 Sistema de Gestión de la Calidad Política de calidad Compras Objetivos de calidad Revisión Plan reclamo requerimientos Realización de producto satisfacción cliente Medición Mejora continua producto Infraestructura Entrenamiento Espacio de trabajo Recursos cliente

13 Sistema de Gestión de la Calidad Plan Realización de producto requerimientos V&V Requerimientos Diseño Desarrollo Mejora continua Medición Registros AUDITORÍA Provisión

14 AUDITORÍA Sistema de Gestión de la Calidad Compras Revisión requerimientos Realización de producto Infraestructura Entrenamiento Espacio de trabajo Recursos Se establecen las características de conformidad de producto y de procesos y se actúa para resolver las no conformidades (acciones correctivas). Se realizan acciones preventivas para evitar problemas potenciales de no conformidad.

15 Sistema de Gestión de la Calidad AUDITORÍA Acción correctiva Proceso A Producto no conforme Proceso requerimientos Acción correctiva Subproceso Proceso no conforme Proceso B Acción preventiva Proceso B1 Proceso B2 Revisión de gerentes. Se evalúa la calidad de los procesos y productos, el cumplimiento de los objetivos, la satisfacción de los clientes, los resultados de las auditorías, la mejora continua, los reclamos; todo ello a través del análisis de las métricas de proceso y de producto.

16 Qué es Agile?

17 Qué es Agile? ÁGIL TRADICIONAL FIJO Requerimientos BASADO EN EL PLAN ESTIMADO Recursos Calendario Recursos Calendario BASADO EN EL VALOR AGREGADO Funcionalidad Agile es, fundamentalmente, un cambio de paradigma. En el paradigma tradicional se determinan de manera exhaustiva los requerimientos del cliente al inicio del proyecto. Luego, de acuerdo al tamaño de esos requerimientos y en base a un plan, se estima el esfuerzo necesario y el calendario para el proyecto. Son muy conocidos los problemas de los proyectos al hacer mal las estimaciones. El paradigma ágil propone invertir el paradigma: se establece un equipo de proyecto y se fija la duración de los ciclos de trabajo, estimando qué funcionalidad es posible entregar, basado en el valor agregado que la misma le da al cliente.

18 Manifiesto Manifiesto por el desarrollo Ágil de software Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar...

19 Manifiesto Individuos e interacciones sobre procesos y herramientas

20 Manifiesto Software funcionando sobre documentación extensiva

21 Manifiesto Colaboración con el cliente sobre negociación contractual

22 Manifiesto Respuesta ante el cambio sobre seguir un plan

23 Manifiesto Cambios de requerimientos son bienvenidos Entregas rápidas Feedback del cliente todo el tiempo Software funcionando pronto Testing temprano

24 Estrategias

25 Estrategias Nos propusimos diseñar el sistema de gestión de abajo hacia arriba, aprovechando los procesos que estaban funcionando. De abajo hacia arriba: Los procesos muestran lo que se hace Aprovechar lo que tenemos Primera versión para probar Los procesos principales surgieron de analizar lo que se estaba haciendo. También nos propusimos diseñar una versión sencilla de los procesos y comenzar a usarlos -y a revisarlos- lo más pronto posible. Incluso, sin esperar a que estén definidos todos los procesos. Uno de los primeros procesos fue el de Reclutamiento.

26 Estrategias Evitar recetas: Uno de los problemas más usuales que tiene la implementación de un sistema de gestión de la calidad, es el de usar recetas pre establecidas. Si un diseño fue exitoso en una empresa, se trata de copiar los procesos porque ya tuvieron éxito en la certificación. Se tomó la decisión de diseñar el proceso para mejorar lo que se estaba haciendo y si bien se usaron recomendaciones, no se copiaron implementaciones en paquete.

27 Estrategias Evitar errores comunes Las empresas no son todas iguales Los proyectos no son todos iguales E1 E2 p1 p1 p2 p2 p3 p3 Además de evitar copiar lo mismo que usa otra empresa, hicimos énfasis en poder diseñar un proceso de realización de producto que fuese lo suficientemente flexible, para que se pueda usar en la mayoría de los casos. Otro error común que se comete es el de usar un único, y generalmente inflexible, proceso para todos los proyectos, independientemente de su tamaño, tipo y complejidad.

28 Estrategias Simplicidad: Los procesos se diseñaron de manera que sean lo más simples posible. El concepto fue: hacer una primera versión rápida y hacerla evolucionar a través de la mejora continua.

29 Estrategias No al paso a paso: En actividades creativas, innovadoras, que necesitan abstracción, diseño e interacción entre las personas, no es posible prescribir, paso a paso, qué hay que hacer para obtener un producto. Es un error tradicional en los procesos de desarrollo de software, escribir con mucho detalle, todas las tareas que se deben hacer. Esto, sumado a la idea de la receta, suele ser la sentencia del fracaso Los procesos se escribieron describiendo guías, elementos obligatorios y foco en qué salidas se deberían obtener en cada proceso.

30 Estrategias Peer review para auditorías: Para implementar las auditorías se diseñó un esquema de revisión entre pares, en donde algunos revisores, hacen la revisión con el punto de vista del sistema de gestión, y por ende de la ISO Se basa en el concepto de revisión entre pares con distintas perspectivas o puntos de vista. Los otros participantes revisan con otro punto de vista, por ejemplo: diseño, responsable del procesos, cliente interno de un proceso, etc.

31 Estrategias Sin papeles: En muchas de las soluciones del tipo paquete se abusa de los papeles para mostrar evidencia. Además de mito, es ineficiente, innecesario y anti ecológico.

32 Estrategias Mejorar: Queremos mejorar Hitos flexibles en función de la mejora real Revisar pronto Act Plan Check Do Dado que uno de los objetivos fue el de poder mejorar las operaciones, se hizo un plan de trabajo con hitos flexibles con foco en mostrar mejoras rápidamente y revisar de manera continua.

33 Diseño

34 Diseño Procesos simples: Pre y post condición Guía; no es paso a paso Generalista para realización de producto Agile La definición de procesos muestra los elementos que deben estar listos al inicio, los elementos que van a quedar terminados al finalizar, y una guía de ejecución del proceso que no prescribe los pasos de detalle.

35 Diseño Poco convencional: Proyecto define cómo trabaja Para los proyectos se determinó qué elementos deben estar definidos (mandatorios), pero cada proyecto debe especificar cómo lo va a hacer. Agile mindset Se redujo al mínimo el uso de minutas. Peer review para auditorías Se redujo al mínimo la redundancia de información. Muy pocas minutas Evitar redundancia

36 Diseño No hay un proceso específico de mejora Mejora continua: No es un proceso específico Todos los procesos lo hacen Agile mindset Act Plan Check Do La mejora continua, de procesos y de producto, está embebida en todos los procesos del sistema de gestión de calidad. Siguiendo la filosofía ágil, a intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

37 Diseño Kanban: Recursos humanos Administración Muchos flujos de procesos se implementan con tableros Kanban Calidad La mayoría de los proyectos usa Scrum y/o Kanban IT & Facilities Proyectos

38 Lecciones aprendidas

39 Lecciones aprendidas Política de calidad Compras Objetivos de calidad Revisión Plan reclamo requerimientos Realización de producto satisfacción cliente Medición Mejora continua producto Infraestructura Entrenamiento Espacio de trabajo Recursos VISIÓN SISTÉMICA cliente

40 Lecciones aprendidas Proyectos: Los proyectos no son todos iguales Diseñar procesos flexibles en dónde el proyecto debe definir cómo trabaja fue un acierto

41 Lecciones aprendidas Do the basics: Ingeniería del software Gestión de las configuraciones Revisión entre pares Automatización V&V Arquitectura Buenas prácticas La madurez de las prácticas de ingeniería fue clave para la estrategia que elegimos.

42 Lecciones aprendidas Simplicidad: Las versiones actuales de los procesos son más simples que las iniciales.

43 Lecciones aprendidas Revisiones: Revisión entre pares en lugar de auditorías Participar en reuniones Participar en revisiones Punto de vista SGC Consenso y debate Criterio establecido Mejora continua

44 Lecciones aprendidas Resultó muy importante contar con una revisión externa previa a la certificación

45 En Dios confiamos, los demás deben mostrar datos EDWARD DEMING

46 Plan de revisiones aplicando Kanban implementado en Trello. Contiene plan, calendario, criterio, resultados, acciones, informe, etc.

47 Desarrollo y mantenimiento del sistema de gestión de la calidad aplicando Kanban implementado en Trello.

48 Versión Versión Autor Fecha Descripción 1.0 Alvaro Ruiz de Mendarozqueta 06-Jul-2015 Primera versión