Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Adesis Netlife: adaptación Ágil.

1 comment
Adesis Netlife: adaptación Ágil.

Esta vez le toca compartir experiencia Agil a Manuel Lavin  , Director  de Adesis, que  ha sido muy  amable al  compartir sus experiencias en la aplicación del modelo Ágil en los proyectos que realizan. Adesis es una compañia que defiende tres principios fundamentales : Flexibilidad, Rentabilidad y Compromiso, tal y como podréis ver en su página Web. Por lo que veo revisando su site, además del desarrollo web se dedican a otras facetas que tienen que ver con Usabilidad, Posicionamiento en Buscadores, Comunicación y Marketing , etc.

Son ya un poco más de 10 años, los que Adesis está “ON” , los mismos años que tiene el Manifiesto Ágil, que también acaba de cumplir hace bien poco un lustro de existencia.

Adesis, como PYME del sector, sabe muy bien que para aportar valor a sus clientes, ha de hacer valer los tres principios y por ello ha apostado por aplicar el modelo Ágil de desarrollo siempre que puede. En algunos casos los clientes se lo piden , en otros ellos mismos “evangelizan” , y por lo que nos cuenta Manuel en algunos casos de grandes corporaciones, la aplicación de modelos disruptivos con las metodologías empleadas es más compleja.

 P.Manuel, tengo una serie de preguntas para ti , para que nos cuentes cual es la experiencia de Adesis en el empleo de metodologías Ágiles.

R.- Encantado de responderte. Espero que con estas respuestas ayudemos a demostrar  que hay otra manera de hacer las cosas que reporta beneficios a quien lo emplea.

P.- ¿Desde qué fecha empleas un modelo Ágil de desarrollo de SW en tus proyectos?

R.- Empezamos en 2008. Primero de una forma un tanto personalizada y poco estandar. De hecho empezamos con una metodología de gestión Agil sin saber que era “Agile”. Luego luego lo fuimos implementando de forma más ortodóxa poco a poco

P- ¿Cuál fue la razón que te impulsó o impulsó a tu compañía a usar un modelo Ágil en tus proyectos?

R- La principal razón fueron las exigencias de los proyectos en los que estabamos inmersos. Eran proyectos muy vivos que cambiaban de forma rápida y a los que teníamos que adaptarnos ágilmente por requisitos de cliente y de la tecnología

P.- ¿Cuáles son las barreras de entrada más importantes que te has encontrado al aplicar un modelo Ágil en los proyectos?

R.-Las barreras fueron de dos tipos. Técnológica la primera, al trabajar con un modelo muy ágil que nos permitía aplicar cambios funcionales en los desarrollos, necesitábamos una base de desarrollo tecnológico que nos permitiera soportar todos estos cambios con un máximo de seguridad. Eso lo conseguimos montado ecosistemas de integración continua, con procesos automáticos de pruebas unitarias y de control de calidad de SW. La segunda barrera fue más la humana, tando desde el punto de vista de los equipos de desarrollo como del cliente. Al final la aplicación de estas metodologias no son más que un paradigma de gestión de personas y de necesidades. Por parte de los equipos de desarrollo la adaptación fue muy rápida, ya que les facilitaba mucho el trabajo y les permitía sentir los proyectos más suyos. Del lado del cliente, la aceptación fue un poco más lenta pero muy positiva. Al final todo cliente de una gran corporacion tiene su propia metodologia y cualquier cambio es más complicado.

P.-¿Qué modelo / metodología estás usando?

R.- Estamos utilizando SCRUM para la gestión de equipos y para la parte pura de desarrollo empleamos TDD bajo un ecosistema de integración continua y control de calidad. Esta era la única que nos aseguraba el poder hacer cambios funcionales rápidos sin tener grandes roturas en los códigos desarrollados

P.- ¿En cuántos proyectos se está usando el modelo y de qué manera?

R.- Actualmente lo estamos utilizando en varios proyectos de 3 clientes en un total de más de 10 proyectos. En dos de ellos la implementación es muy profunda, eso quiere decir que todos los eslabones están muy integrados: por una lado los clientes son muy proactivos en cuanto a su utilización, la infraestructura tecnológica (basada en integración continua) está bien asentada y los equipos de desarrollo conocen y practican muy bien la metodología. En otro cliente, la fase es mucho más incipiente y estamos en una etapa de más evangelización que de puesta en práctica

P.- ¿Cuántos equipos lo usan y cuantas personas de media los forman?. ¿son equipos internos, externos, mixtos ?

R.-En la actualidad hay unos 14 proyectos gestionados con metodologías ágiles. La media suele ser de unas 4-5 personas. En todos los proyectos procuramos que sean equipos mixtos de personal propio y del cliente, ya que sin la participación activa del cliente no es viable

P.- ¿Usas tablero físico de tareas , virtual , los dos?. ¿Qué herramientas usas?

R.-Usamos los dos tipos de tableros de tareas, los físicos funcionan mucho mejor con los equipos de trabajo y los virtuales mejor para jefes de proyectos y personas de gestión, sobre todo si no están físicamente en el lugar de trabajo de los equipos. Cómo herramientas de gestión de tareas virtuales utilizamos Greenhoper de Atlassian.

P.- ¿Qué prácticas/procesos de la metodología que usas encuentras más útiles y son más aceptadas por el equipo?

R.-Yo creo que las dos prácticas  más aceptadas son las de reuniones de definición y planificación de SPRINT, ya que el equipo ve una mayor involucración por su parte y las retrospectivas por que son las que te permiten tener una mejora continua que es una de las piedras angulares de cualquier metodología ágil.

P.- Para el seguimiento del grado de avance de los proyectos: ¿qué técnica empleas?.

R.-Estamos utilizando JIRA, para la gestión de tareas si bien en los SPRINTs la evolución la vemos más en los tableros, pero para la dirección nos manejamos con JIRA

P.- ¿Qué cosas crees que han mejorado desde que estás usando el modelo Ágil?.

R.- Sobre todo la comunicación entre los equipos y con el cliente

P.- Si tuvieras que lanzar más proyectos : ¿seguirías haciéndolo así?. ¿Crees que hay proyectos que no se adaptan al modelo Ágil?. ¿Porqué?

R.- Por nuestra experiencia si que seguiríamos utilizando metodologías agiles, no hemos encontrado ningún proyecto en el que no se puedan aplicar.

P.- ¿Cuál es la frecuencia de las iteraciones que realizas?. Tras cada una, realizas una retrospectiva?

R.- La frecuencia varía, pero siempre nos movemos entre las 2 y 3 semanas nunca más. Si que tenemos un proyecto que tiene iteraciones semanales pero es debido a su corta duración y que el seguimiento se hace desde la dirección general y lo quieren tener muy controlado. No en todos los casos hacemos retrospectiva pero si que lo intentamos. Yo considero que es una de las partes más importantes de estas metodologías

P.- ¿Haces seguimiento de las mejoras o acciones que se derivan de las retrospectivas de manera regular?

R.- Pues no tanto como nos gustaría, esta es una de las asignaturas pendientes. No suele quedar mucho tiempo y es una de las primeras tareas que suele caer

P.- ¿Cuándo lanzas un nuevo proyecto, consultas los aspectos de mejora de las retrospectivas anteriores para asegurarte que no cometes los mismos errores?.

R.- Si que lo hemos hecho, sobre todo en varios proyectos de características similares que tenemos y hemos aplicado mejores prácticas aprendidas de unos a otros

P.- En cuanto a la actitud del equipo: ¿crees que ha cambiado la actitud ante los proyectos por el hecho de usar este ,modelo?. Destaca los puntos clave que han motivado este cambio.

R.- Si, si que ha cambiado. Los equipos se involucran mucho más y se responsabilizan mucho más de las tareas que se les han asignado. Los equipos tiene una mayor conciencia de propiedad en las tareas que se acometen. Por otro lado, el seguimiento de tareas al ser mucho mas visible hace que los miembros del equipo se retraten y a nadie le gusta salir mal en la foto

P.- ¿Quien desempeña el papel de Product Owner ? ¿Se le ha formado en su cometido de alguna manera? – ¿Cómo se realiza la definición de las historias de usuario?. ¿empleas alguna herramienta para su definición, seguimiento y control?

R.- En los casos donde mejor ha funcionado es en aquellos en los que el Product Owner es el cliente final del entregable. En otros casos, el producto owner lo suele asumir un miembro del equipo de desarrollo del cliente, el cual hace de proxy con los clientes de negocio

P.- ¿Hay Jefe de Proyecto en estos proyectos o se ha sustituido por un Scrum Master? (si es que usas Scrum). Define brevemente que cosas hace el Jefe de Proyecto en un proyecto Ágil de los que conozcas.

R.- En la mayoria de los proyectos sigue habiendo un jefe de proyecto, pero más de cara a la gestión y coordinación administrativa del mismo. La gestión de tareas y necesidades propias del proyecto se gestionan más a nivel de SCRUM master

Muchas gracias de nuevo a Manuel Lavin por su amable colaboración al conocimiento de la realidad de las empresas que hacen Software de manera Ágil. Espero desde estas líneas que continuen aplicando el modelo cada vez en más proyectos ,lo cual será un síntoma claro de que las metodologías Ágiles van avanzando en este país, algo que desde empresas como Adesis están consiguiendo con sus aportaciones.

  1. Manuel,

    Como sabes, una de las dificultades principales de Scrum es hacer entender a nuestros mayores la metodología, así como poder proporcionar estimaciones, aunque sean aproximadas, del trabajo que queda por realizar. Por si fuera poca dificultad, Las herramientas que mencionas, a mi entender, están muy lejos de ser realmente útiles en cuanto a reporting. Jira es un buen gestor de tickets de incidencias al que han metido a martillazos algo llamado Greenhopper para decir que es una herramienta de gestión Scrum. Sin embargo no va mucho más allá de pintar los burndown del sprint en curso. No ofrece ninguna facilidad para agrupar historias (para mi fundamental a la hora de hacer reporting) ni realiza cálculos tan simples como la velocidad necesaria para comerte las historias pendientes en X tiempo, o considerar los cambios de capacidad a futuro (incrementos o decrementos de equipos o recursos).

    Mi gran duda es si lo que sucede es que le pido a la herramienta conceptos propios de una metodología tradicional waterfall, lo cual no tiene sentido. Pero lo cierto es que lo que da lo podría hacer con un spreadsheet y un par de fórmulas.

    ¿Cómo resolvéis el tema del reporting en proyectos de cierta entidad? ¿Cómo administráis el mensaje “no sé cuándo voy a acabar”? ¿Es siquiera posible hacerlo?

    ¿Hay alternativas a Jira+Greenhopper que hayáis testado?

    Gracias
    CV

Trackbacks/Pingbacks

  1. Echando la vista atrás y mirando al futuro | GestiondeProyectosIT - [...] colaboración al conocimiento del mundo Ágil “made in Spain” , a Manuel Lavin de Adesis y  Miquel Mora de…

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*