Ir al contenido principal

Que pasa ahora! Cascada o Ágil?


En esta entrada es con fines académicos por favor así que los que tengan la super experiencias se que comentaran muchas aristas para debatir lo expuesto. Aclarado el asunto, iniciemos lo fácil para saber que sucede actualmente:

Comencemos hablar de los problemas básicos:

  • Cambios a cada momento.
  • Aparece las demoras y quien se sacrifica "el tiempo de las pruebas".
  • Quien planifico el trabajo, pues no fue muy bueno.
  • Cliente solo paga, no se involucra quiere su entregable.
  • El equipo solo avanza por avanzar, no se comunican.
  • Horarios, Objetivos y Liderazgo, o sea flexibilidad.
  • Finalmente el resultado no es el esperado por el cliente, esto es muy frecuenta.
De los problemas descritos, para los académicos podemos ver que hay bastante responsabilidad de todos los involucrados pues tenemos un cliente insatisfecho y un equipo desmotivado, para los que dicen ya se pero soy gerente no me interesa eso - a ya! - pues en otros términos seria tiempo y dinero perdido que afectan a tu retorno de inversión y lastimosamente a tu reputación como líder.

Ahora hablemos un poco del versus que hay entre un desarrollo en cascada y ágil:
  • Cascado es poco flexible y no hay marcha atrás, es estricto y demanda errores, te llena de documentación y no se entrega valor hasta el final.
  • Ágil es mejor que Cascada. Pero porque? Entrega valor y permite ser flexible en la atención y adaptación al cambio. Ah, y no tienes documentación inservible.
Estos argumentos son validos, siempre y cuando hablemos de la voluntad de cada equipo porque si tenemos un equipo calificado el resultado para ambos casos sera el mismos. El éxito esta en las personas. Por ahí dirán, oye pero falta el feedback que es ventaja del scrum, espera un ratito! ambos hacen feedback solo que uno lo ha puesto como pilar de su forma de trabajo, cascada también hace feedback.

Ahora, porque hablamos mal de cascada si hemos aprendido a desarrollar en cascada, mi generación y muchas más ha estado aplicando cascada y nos ha resultado útil cuando los procedimientos están claros. Por supuesto! Yo también lo creo así, cascada es lo máximo bien gestionado, organizado y sobre todo planificado para llegar a buen destino, pero esa palabra mágica: la velocidad! es un factor que nos exige esta mundo globalizado y ágil lo hace fácil porque ya tiene como requisito personal altamente calificado y entrega de valor oportuna a través de las historias de usuarios. Pero esto lo sabe mucho más un superviviente de cascada y que ha transformado su manera a ágil tuve la suerte de conocer a muchos que pasaron por ese proceso, mis respetos.

Pero nada es perfecto, hablemos de los enemigos frontales que tenemos, sea cascada o ágil:
  • Cambios de Funcionalidad: Típico!
  • Cambios de Tecnología: Increíble!
Ahora materialicemos un poco lo descrito como típico e increíble, aquí viene lo bueno, porque sucede esto en ambos:
  • No medir correctamente el avance: o sea tener un avance poco serio, mal informado y sobre todo sin cálculos que te permitan sustentar tu rendimiento. El valor ganado es una buena técnica.
  • Añadir más personal calificado, suponiendo que más da velocidad: Pues no necesariamente si tienes clara tu gestión sabes que sumar personas no es proporcional al avance, por ende o inclusive puede disminuir hasta alcanzar sobre costos. Nuevamente hay que medir bien los topes, no digo que no sumen gente sino que sea lo adecuado.
  • No tomar en serio la calidad desde el inicio: El aseguramiento es un factor importante y que no se debe tomar a la broma o desmerecer en un equipo, no tener un asegurador de la calidad no te va dar la seguridad que necesita tu valor entregado. Ahora el equipo tiene que ser multidisciplinario por ende cada uno debería tener el concepto de calidad bien definido.
  • Suponer que lo que haces es la maravilla: La humildad es parte del éxito y ayuda a sincerar con tu cliente cada paso que das, por que creen que scrum involucra al cliente desde el inicio? Porque aseguran que la entrega tiene su cuota de valor, así el producto tiene firma garantizada. Pero cascada haces eso no! Si, pero para scrum es un requisito no una negociación.
  • No tener una visión global: Si tu equipo esta haciendo un producto que va sumar valor y que te va permitir sumar rentabilidad a tu cliente, pues debes ver hasta donde llega esa rentabilidad o sea tienes que ir más allá de tu cuota de valor, sino solo te quedaras con el producto y no la visión que necesita.
  • Poco involucramiento del cliente: Esto es un clásico que todo profesional conoce, buscar que el cliente se comprometa y este con el equipo nos brinda seguridad pero hay que entender que el cliente tiene que hacer su trabajo dentro de su estructura funcional, respeta mi tiempo pero también el de ellos.
  • Estimaciones poco técnicas: Tiene que estimar el que sabe del asunto no el que dice que es líder o jefe, hablar de estimación puede ser sencillo para scrum porque tiene su evento de planificación donde esta el mismo dueño del producto contribuyendo con el equipo. Es una gran ventaja.
Hay más, pero son más técnicas: Pedida del foco, no decir no y no tener herramientas que permitan medir ese valor. Espero les haya ayudado por mi lado iré documentando mayor información, como periodista del camino del Perú a la transformación digital.

Gracias!







Comentarios

Entradas populares de este blog

Arquitectura de Tres Capas a Microservicios

Arquitectura Tres Capas a Microservicios Introducción: Todo gestor debe conocer aspectos técnicos y funcionales del negocio que tiene a su cargo, el no saber o desconocer estos temas resta a la disrupción que busca en incrementar valor y aperturar nuevas líneas  de su negocio. La Arquitectura es fundamental saber interpretarla y más debatirlo porque es esa frontera donde la gestión no pisa fuerte pero que debe estar preparado para saber discutir unos temas de tendencia que interesa no a las áreas sino a la empresa que rinde servicio. Marco Conceptual: En la última década, se sabe que la tendencia en esos años era la arquitectura de tres niveles , usadas en ASP.NET y Java EE. Sin embargo, e stos formato de arquitectura viene desde finales de los años 90 como un medio para entregar aplicaciones web pero  el gobierno de IT exige una estrategia para establecer una arquitectura de aplicaciones que brinde más que una aplicación web.  Los clientes ahora exigen acceso a través de múltipl

Pura Vida y Nada UX

Estimados espero les vaya bien a todos, hoy hablemos del boom que tenemos a la fecha, si del roche Leche Pura Vida que reventó en redes sociales a través del estudio que "es o no leche". No hablare de si es leche o que si el director se disculpo o que si la gente poner "I love Gloria" no nada de eso, hablare de la cara digital y experiencia que brindan a sus usuarios nuestros amigos de Gloria. Comencemos: Primero entramos a la pagina corporativa www.grupogloria.com y vemos una presentación nada agradable para una primera experiencia de conocer la marca. Me dije, bueno no importa revisare la información y comencé a ver las pequeñas letras y cada vez que presionaba me adentraba a un sitio donde el diseño era el mismo ¿Estándar? no nada que ver era una "Plantilla". Entre a la sección donde dice Gloria S.A. entonces ingrese a su link www.gloria.com.pe y que sorpresa desde hace mucho no veía una pagina en "flash", cogí mi celular al toque y r

Sugerencias de Arquitectura de MicroServicios para comenzar a ser Bimodal

Qué hacer para pasar a Microservicios Conversamos sobre la arquitectura de tres niveles ( post ) y cómo debería evolucionar a una arquitectura de microservicios. Ahora veremos unas sugerencias para poder tener una buena transición de tres niveles a servicios. Establecer un programa de innovación que permita a todo el equipo de arquitectura comenzar a experimentar con Arquitectura de Microservicios. (Permiso) Investigación para desarrollar las habilidades necesarias para desplegar soluciones con la nueva infraestructura que pueda soportar "Entrega Continua" y Microservicios. Ya se conocen empresas que han desplegado soluciones con código abierto. (Inversión) Debe iniciar con una aplicación existente en tres niveles y buscar refactorizar para lograr tener multiniveles de adaptación a otros entornos o aplicaciones. (Piloto) Se recomienda comenzar con una aplicación de bajo riesgo y que no bloquee algún proceso de negocio crítico en su negocio. (Criterio) Con el cambio en