Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

DoNewTech: ser ágil vale totalmente la pena.

0 comments
DoNewTech: ser ágil vale totalmente la pena.

Esta vez, ha sido Luis Artola de la empresa Donewtech Solutions ,quien responde a la entrevista sobre adopción ágil en su empresa. Donewtech es una compañía ubicada en Donostia, que se dedica a Consultoría y desarrollo de SW, contando con importantes clientes como Siemens, Kutxa , CAF y Eroski entre otros, a los cuales provee servicios de Tecnologías de la Información. Muy amablemente Luis nos responde a las preguntas de rigor , las cuales aqui os dejo para vuestra lectura.

De la entrevista, extraigo algunos mensajes :

“De entrada los principios y metodologías que ofrece el desarrollo ágil son de sentido común.”

“El agilismo implica un cambio en la forma de relacionarse con el cliente. Una forma que necesita de desarrollar una confianza muy grande. A muchos clientes les cuesta entender el por qué del desarrollo iterativo, o de los presupuestos no cerrados.”

“La transición superficial hacia el modelo ágil es difícil. La transición profunda aún más difícil.”

Estoy bastante de acuerdo con estos tres mensajes, y además creo que una de la grandes barreras que existen en la actualidad para que este modelo cale más profundamente en el desarrollo de SW “Made in Spain” es la dificultad para que los clientes entiendan los “Contratos Ágiles” , ya que estamos acostumbrados a contratos de precio cerrado, que encajan mal con el desarrollo iterativo y el proceso adaptativo de los modelos Ágiles. Es común por eso, que se den implementaciones de “WaterScrumFall“, en las que una parte del proceso se rige por los principios de las metodologías predictivas ( plan- alcance -presupuesto) , y otra, la que tiene que ver con el desarrollo del producto, se apliquen las técnicas y prácticas que dictan los postulados ágiles. No estoy ni a favor ni en contra de WaterScrumFall. Algunos pueden verlo como una “corrupción del modelo”, pero si aplicar Scrum en las etapas técnicas del proyecto (Diseño, Programación, Pruebas) supone una mejora de la calidad, una mejora para las personas que llevan a cabo el proyecto y una mejora para los resultados del proyecto en general, solo tengo que decir que bienvenido sea. Los teóricos de las metodologías, sean Ágiles o no, son generalmente partidarios de su aplicación de principio a fin, y es verdad que aunque cuando (como dice Luis en alguna de las respuestas ) se aplican en su conjunto todas las prácticas se obtienen mejores resultados, cada equipo y cada proyecto debería aplicar aquello que mejor se adapte para conseguir los objetivos. Adaptación es una de las pautas clave de los modelos ágiles.

Paso ya a trasladar las respuestas a las preguntas por parte de Luis Artola y antes de nada darle las gracias por su colaboración en esta sección de Historias Ágiles.

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

R.- Es difícil determinar una fecha exacta. DoNewTech está ahora mismo en un proceso de transformación profundo, reorganizándose para ser más ágil. Sin embargo, hace ya al menos dos años que empezamos a introducir prácticas agilistas tanto en la gestión de proyectos como en el desarrollo del propio software.

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- Probablemente el mayor acierto del movimiento ágil es el acertado diagnóstico que hace de los problemas clásicos al desarrollar software: requisitos cambiantes, problemas de comunicación, etc. Lo primero que nos atrajo fue la coincidencia entre el diagnóstico que hacíamos nosotros mismos de nuestros problemas, y los que hacía el propio movimiento.

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

R.- De entrada los principios y metodologías que ofrece el desarrollo ágil son de sentido común. Cosas bastante lógicas. Sin embargo, si uno pretende profundizar realmente en la implantación de agilismo tiene dos barreras básicas. Por un lado una barrera técnica, relacionada con el propio desarrollo de software y la aplicación de técnicas como TDD, integración contínua, etc. Sin cierto nivel técnico, las técnicas de management se quedarán cojas. Y por otro lado, la implantación de una cultura distinta en el cliente. El agilismo implica un cambio en la forma de relacionarse con el cliente. Una forma que necesita de desarrollar una confianza muy grande. A muchos clientes les cuesta entender el por qué del desarrollo iterativo, o de los presupestos no cerrados.

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

R.- En general, usamos una metodología Scrumban. Nos gustan las iteraciones de tamaño fijo y el acance cerrado de los sprints, pero nuestra realidad implica tener un buffer en cada iteración para imprevistos.

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

R.- Las técnicas ágiles se aplican en mayor o menor medida en todos los proyectos. En los más nuevos, se empieza ya con todo el ciclo de scrum. En proyectos que se iniciaron hace mucho tiempo, se aplican las diferentes técnicas en la medida de lo posible. A nivel interno, en todos los proyectos se aplican técnicas de comunicación (daily, retro, demo…) y visualización (paneles, etc.).

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

R.- Caminamos hacia equipos de tres o cuatro personas. Y nos movemos entre cinco o seis equipos. Los equipos son básicamente internos y si tenemos gente externa intentamos integrarla en el equipo como si fueran uno más.

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

R.- Tablero físico multiproyecto para cada equipo. Atlassian Jira para la visión completa del tablero de producto, el acceso por parte del cliente y la trazabilidad del proyecto.

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

R.- Hemos notado que las prácticas funcionan mejor cuando consigues aplicarlas todas. Se producen muchas sinergias entre ellas. Las retrospectivas y la gestión de impedimentos son muy agradecidas por el equipo, ya que permiten eliminar o al menos poner en común las frustraciones. A nivel técnico, la aplicación de TDD aporta mucha confianza al desarrollo del producto.

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

R.- Nosotros incluimos a la dirección en nuestras reuniones de producto, así que reciben la información de primera mano. Además, usamos el reporting de Jira para controlar el % de producto terminado, control de costes, etc.

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

R.- En nuestro caso, la gerencia de DoNewTech está totalmente implicada en el cambio de la organización hacia el modelo ágil. Nos queda muchísimo camino por recorrer, pero empezamos a ser mucho más rápidos a la hora de detectar desvios respecto a lo que estimamos, y somos capaces de entregar valor antes y con menos errores. En general, somos capaces de hacer a los clientes más felices.

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.- El agilismo ofrece un framework, un marco de trabajo. Si es verdad que habrá proyectos donde no puedas aplicar los métodos y técnicas exactamente, pero siempre podrás retroceder hasta los principios y aplicarlos. Es importante no perder de vista nunca los principios ágiles cuando te encuentras en un escenario de aplicación difícil.

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

R.- Depende del proyecto. Tenemos bastante variedad. Hay un proyecto con iteraciones de una semana, pero en general suelen ser o de dos o de tres semanas. Retrospectivas se hacen siempre, de manera más o menos formal.

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

R.- Las acciones se ponen en el panel, para que todo el equipo pueda verlas y las tenga siempre presentes. Al final de la iteración se reflexiona sobre si se han realizado las acciones o no.

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.- Las mejoras de las retrospectivas se dan sobre todo en las costumbres de los equipos. Si los equipos han mejorado, su capacidad para generar buenos productos habrá mejorado. Pero sí que antes de empezar un proyecto se intenta aprovechar toda la experiencia anterior, claro.

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.- En equipos autoorganizados, al tomar ellos mismos las decisiones, se sienten más responsables de ellas. Además, cada desarrollador consigue con mayor facilidad la información que necesita para realizar su trabajo, conoce mejor el estado del proyecto, y tiene un vehículo para expresar qué le preocupa o qué le impide trabajar correctamente.

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.- Actualmente no usamos la figura del Product Owner propiamente dicha, porque en la realidad de los proyectos que nosotros realizamos, no podemos podemos integrar completamente al cliente en el equipo. Usamos la figura de Product Proxy, una persona encargada de ordenar las ideas que vienen del cliente, y transformaras en colaboración con el equipo en historias de usuario. Las historias de usuario se controlan en los paneles físicos de equipo (post-it) y en Atlassian Jira.

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.- enemos Scrum Masters para vigilar el proceso ágil. Product Proxies para ordenar la relación con el cliente, y un responsable general de todos los proyectos, que vigila el business y ayuda a priorizar a los equipos entre los diferentes proyectos.

P.- Miguel, comentanos cualquier otra cosa que te interese o una vivencia personal que hayas tenido al aplicar el modelo Ágile en el desarrollo de proyectos.

R.- La transición superficial hacia el modelo ágil es difícil. La transición profunda aún más difícil. Hay que combinar metodologías de gestión con técnicas de programación (reglas XP) porque sino lo aplicarás de manera “flácida”. Las técnicas funcionan de verdad combinadas entre sí. Vale totalmente la pena.

Una de las claves de éxito de Donewtech es , como dice Luis, la total implicación de la Gerencia con el modelo ágil y su convencimiento de que aplicando este modelo consiguen hacer a sus clientes “más felices”. Sin duda una de las claves para que un negocio funcione.

Enhorabuena y gracias de nuevo por contarnos vuestras experiencias.

Como punto y final de esta entrevista, lanzo desde aqui un nuevo llamamiento para que si alguien está interesado en contar su experiencia desde estas páginas, se anime a ello. Cuanto más difundamos el modelo, mediante experiencias reales , más convencimiento habrá de sus bondades y más y más empresas se decidirán a iniciar el camino. Podéis contactar conmigo a través del formulario de contacto del Blog, y enseguida me pondré en contacto con vosotros.

Hasta pronto.

Leave a Reply

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


*