033 Metodologias Aplicadas A Proyectos Utilizando Genexus

Notas del editor

• #3: Buenas tardes, mi nombre es Sebastian Bertone, trabajo en AccionPoint Argentina. Accionpoint es una empresa con casi 2 decadas trabajando en Genexus y especializada en la implementación y configuración de Soluciones Tecnológicas. Somos además a través de Toolnology distribuidores oficiales de Genexus en la Argentina. El objetivo de esta charla es compartir con ustedes el proceso de mejora llevando a cabo en mi empresa durante los últimos años. En Accionpoint estamos convencidos que el enfoque metodológico en los procesos y las buenas practicas en la fabricación de software son imprescindibles para brindar un producto de calidad y por consiguiente la satisfacción de nuestros clientes.
• #4: Nuestros móviles para comenzar el camino de mejora estaban clasificados en 3 grandes grupos: • Certificar ISO : Obtener los beneficios de la Ley de Software , que nos permitirían costear la implementación. Conseguir un respaldo a nivel internacional de nuestro proceso productivo. Este aspecto abrió nuevos negocios. En su momento sabíamos que había un mercado potencial y lo comprobamos al tratar con clientes internacionales cuando nos solicitaron nuestro certificado. • Satisfacción del cliente: Era complicado cumplir con los tiempos pactados. Esto en muchos casos atrasaba los pagos. Normalmente el cliente no obtenía el producto que esperaba a nivel de requerimientos. Cantidad de Bugs que llegaban al cliente era critica. • Organización Interna El bajo nivel de organización. incrementaba los costos de producción y complicaba la gestion. El Know How era de los recursos y no de la organización . Por ej un AF se enfermaba era imposible que otra persona pudiera continuar con la labor debido a que no contaba con la información necesaria para hacerlo. No estaban claras las responsabilidades . Dependía de tus superiores y de las ganas de la persona para llevar a cabo su trabajo. No estaban claras las jerarquías . El área funcional tenia la idea errónea que lideraba al área técnica, esto generaba solapamiento de tareas con constantes cambios de prioridades (dependiendo de la necesidad del AF y no del proyecto) que normalmente entorpecían el trabajo de los desarrolladores y generaban atrasos en el trabajo.
• #5: Teniendo en cuenta la magnitud del cambio que nos estamos proponiendo afrontar era de vital importancia contar con el apoyo de la gerencia. Es fundamental su apoyo cuando: El proceso de mejora entra en los momentos difíciles. “A partir de ahora se trabaja así” Para llevar los cambios adelante. Para avalar el cumplimiento de los procesos aun en los momentos en que las necesidades se hacen mas fuertes. “Momentos previos a una implementacion” Solventar el costo de la calidad, sobre todo en los inicios.   El cambio lo comenzamos pensando la empresa como la interacción de tres aspectos claves ( (Personas, Metodologias, Herramientas).
• #6: Redefinimos el Organigrama de la organización . Creamos una estructura que refleja la nueva forma de trabajo de la organización. En nuestro caso el organigrama se construyo con el objetivo de fortalecer la autonomía de las áreas (Consultoría, Factoría y Comercial). Nuestro mayor problema en este aspecto eran las relaciones de autoridad informales que existían. Necesitábamos clarificar las relaciones de Autoridad en todos los niveles. Debíamos detener la inercia en las relaciones de autoridad que se desarrollaron de manera informal. (ej: analista funcional como "superior" de los desarrolladores). En este aspecto se trabajo también en el fortalecimiento de 2 roles para nosotros claves, el LT y LC. Ambos son los encargados de las células técnicas y de consultoría. Teníamos que formalizar las interacciones entre personas para agilizar los procesos. Redefinimos roles y responsabilidades : Debimos definir los roles y sus responsabilidades para soportar los procesos implementados. Primero se definieron todos los procesos necesarios, la autoridad de cada rol se definió basándonos en las responsabilidades definidas en los procesos. Estos puntos fueron en algunos aspectos motivos de rechazo, tengamos en cuenta que algunos roles perdieron poder. Otros Roles en cambio al clarificarse sus responsabilidades debieron enfocar todo su trabajo solo a lo que les corresponde. Rompimos con los vicios adquiridos: Esta situación se dio sobre todo en el personal con más años en la empresa. Este aspecto se trabajo con capacitaciones y un riguroso control de QA sobre el proceso de construcción. El sentido de los controles no es de castigo sino de encausar y capacitar al personal. Los controles realizados sobre los procesos en ningún caso interfieren con la ejecución en tiempo y forma de los procesos, se utilizan para detectar debilidades, fortalezas, y adoptar acciones de mejora. Cambiamos de una visión particular de los participantes a una visión global de procesos . Fue un aspecto que se trato con capacitaciones. Es muy importante que todos los participantes puedan entender la globalidad del proceso y su objetivo final que es entregar un producto de calidad al cliente. Vencimos la resistencia al cambio Este aspecto se abordó demostrando a los participantes las posibilidades de mejora que estábamos planteando. “Evangelizamos” mediante capacitaciones y reuniones. Involucramos a todos los recursos en el proceso de mejora. Muchos tomaron la mejora como algo personal y se hicieron fuertes aliados. Cabe destacar que todas las auditorias realizadas la mayor fortaleza encontrada en la organización fue en compromiso de la gente (gerencia y personal en general) con el modelo de trabajo implementado.
• #7: Si bien nuestro objetivo fue certificar ISO, no utilizamos solo lo que la norma nos exigía, hay muchas buenas practicas que tomamos del modelo CMMi .La idea es tomar de cada uno lo que realmente necesitamos y que además se adapta a las necesidades de la organización. Definimos un proceso de construcción basado en el modelo y buenas practicas de CMMi . Debimos homogeneizar la manera de trabajar de una amplia gama de proyectos . Dependía de los lideres la forma de llevar a cabo el proyecto. Se trabajo mucho en definir un proceso que no atente con la cultura organizacional. Para esto se llevaron a cabo reuniones con todos los involucrados. Para mejorar la calidad del producto debíamos cumplir con nuestros tiempos pactados . Las buenas practicas de CMMi aportaban la planificación como parte del proceso de construcción no solo en las entregas sino tambien para gestionar la célula de trabajo. La planificación se realiza basada en GxPoints. Esta planilla se realizo en base a la experiencia de los lideres y permite dependiendo de la complejidad de los objetos obtener una estimación precisa en horas del trabajo a realizar. Debíamos especificar nuestros requerimientos . Era fundamental volcar las necesidades del cliente en un documento que sirva para realizar el desarrollo de la solución. Este documento además es la base del proceso constructivo. Sobre el se aprueba, se estima y se construye la solución. Comenzamos a utilizar un documento de especificación con todos los campos necesarios para realizar un requerimiento. Este documento se trato durante varias reuniones con los lideres. D ebíamos controlar los cambios . Otro problema que teníamos es que al no formalizarse el requerimiento al realizarse cambios no se re-estimaban. En nuestro proceso los cambios a los requerimientos deben seguir el mismo circuito de especificación, aprobación, estimación y construcción que el requerimiento original. Debíamos testear nuestros productos previa entrega al cliente para asegurarnos de no entregar bugs . Incluimos las plantillas de pruebas en la especificación del requerimiento y la hicimos de uso obligatorio por cada funcionalidad que se este especificando. La calidad de los casos de prueba es motivo de aprobación o rechazo del requerimiento por parte de los lideres técnicos. Creemos que es muy importante que el desarrollador conozca la manera en que se va a testear su producto antes de hacerlo, esto evita entregas con errores y por consiguientes idas y vueltas que derivan en atrasos. Definimos un modelo organizacional basado en ISO Por el tamaño de nuestra organización, por el mercado al cual apuntamos, por el tiempo que disponíamos para realizar la implementación del SGC cumpliendo con la ley de software y por la cantidad de evidencia con la que contábamos decidimos que certificarnos en la Norma ISO era lo mas indicado. ISO tiene la ventaja que no exige grandes cantidades de evidencia en una etapa inicial, solo se debe demostrar que se esta comenzando el camino de mejora y que se implemento en la organización. Luego en las sucesivas auditorias los auditores van exigiendo mas y mas evidencia que respalde la mejora continua y la calidad en los productos. De ISO utilizamos (Mejora continua, Definición de procesos, Control de los registros, Auditorías periódicas (internas y externas) , área de aseguramiento de la calidad , Indicadores) • Llevamos nuestra metodología al cliente. Debíamos lograr que el cliente valore el proceso de mejora, comprenda la nueva metodología de trabajo y si es posible "evangelizarlo". Necesitábamos que el cliente trabaje con nosotros para lograr entregarle un producto que satisfaga sus expectativas. En los proyectos de Factoría en los cuales no los clientes nos envían las especificaciones, necesitábamos que cumplan con nuestras exigencias (especificaciones, casos de prueba, aprobaciones), por lo que hubo que capacitar a los clientes para que trabajaran bajo nuestra metodología. Esta nueva forma de interacción con el cliente genero un gran desafío, no fue fácil en muchas ocasiones que los clientes acostumbrados a otra manera de trabajo tengan que adaptarse a esta nueva realidad. Pero una vez superada esta etapa nos ofreció la posibilidad de trabajar en conjunto y realmente brindar un servicio de las características que el cliente necesita.
• #8: Una vez que definimos la metodología y analizando la realidad de la organización pudimos delinear la forma que debía tener nuestra herramienta de soporte: El proceso presenta una forma de trabajar nueva con la cual la gente no estaba familiarizada. Por lo tanto una herramienta que guiara a los participantes seria de gran ayuda a la hora de implementar. Debíamos volcar nuestro proceso tal cual estaba en la herramienta. Además esta debía permitirnos definir los niveles de autorización mediante roles. Los equipos de trabajo están distribuidos geográficamente. Necesitábamos una herramienta de acceso Web. El cliente debe realizar aprobaciones y subir documentos de especificación. El cliente debía ser incluido en el uso de la herramienta, por lo que debía ser simple y permitir subir documentos. Las células de trabajo son autónomas, pueden abarcar uno o varios proyectos y su gestión es compleja. Se debía gestionar el equipo de trabajo y las asignaciones a las tareas a través de la herramienta. La comunicación entre los equipos es crítica. La herramienta debía en cierto punto gestionar la comunicación de los grupos. Tenia que informar a todos los interesados acerca de los estados del requerimiento, su informacion de entrega, sus aprobaciones, etc. Debíamos asegurarnos el cumplimiento de algunos puntos críticos del proceso. Por ejemplo las aprobaciones de los requerimientos y los casos de prueba. Que se realicen las estimaciones y que se respeten las fechas de entrega pactadas. Debíamos tener un repositorio de todos los documentos (evidencias) que se irían completando a lo largo del proceso y que además toda esta información se versionara.
• #9: Herramientas con las que trabajamos GADeS (Proceso productivo y de calidad) GXManager (Gestión distribuida de KB) SVN (Herramienta de versionado, la utilizamos para almacenar todos nuestros registros  
• #10: El éxito de nuestra implementación dependió pura y exclusivamente de la personas, los procesos y las herramientas que elij imos, fueron analizados en conjunto y fueron tenidos en cuenta en ca da una de las etapas de la implementación . Emprender el camino de mejora nos dio satisfacciones en muchos aspectos Tenemos fuertes convicciones que nos permiten continuar el comino de mejora en el tiempo.
• #11: Nuestros Objetivos : Proceso ágiles . Analizando la cantidad de cambios que surgen por requerimientos detectamos la necesidad de comenzar a trabajar en metodologías ágiles (SCRUM) para tratar el cambio como parte del proceso de construcción y no penalizarlo. No es aplicable a todos los tipos de proyectos que tenemos, pero existen muchos proyectos en los cuales la incertidumbre obligan a utilizar metodologías incrementales en las cuales el cambio de los requerimientos fortalezca el proceso de construcción. Ampliar el mercado . La agilidad lograda en nuestros procesos permiten adaptarnos a cualquier tipo de proyectos y mantener la calidad de nuestros productos. Esto nos permite encontrar nuevas oportunidades de negocios antes inaccesibles. Mayor participación del cliente en el proceso de construcción . Continuamos aumentando la participación del cliente en nuestro proceso de mejora. Detectamos que en algunos casos la falta de una correcta priorización de los requerimientos por parte de nuestros clientes generaba demoras en las entregas. Es importante que los clientes tengan una bandeja de entrada donde puedan priorizar los requerimientos y realizar un seguimiento de las entregas de forma unificada. Mejorar nuestra herramienta de gestión : Ante la evolución del procedimiento y las metodologías de trabajo fuimos comprendiendo la necesidad de unificar y mejorar todas las herramientas que estamos utilizando actualmente.  Los puntos críticos fueron: Mayor flexibilidad al flujo de trabajo. Necesidad de trabajar con un workflow y una bandeja de entradas unificada. Unificar todo el proceso en una sola herramienta (reducir la complejidad). Gestión de KB. Gestión de Documentos. Obtención de información mediante datawarehousing. (GxPlorer)  Mayor facilidad de uso . Desde el inicio del año estamos trabajando en una nueva versión de GADeS basada en Genexus X en la cual incorporamos todas las mejoras antes nombradas y esperamos estar implementándola a la brevedad