Principalmente, para aquellos que nos les termina de gustar la gestión ágil, no entienden muy bien el tema, buscan ponerle pegas, etc., hay como dos especie de mitos, dos frases hechas, que poco a poco, de tanto repetirlas, se han ido haciendo más populares en ciertos entornos:
- En agilidad no se sabe cuándo se termina (o la variante de en agilidad no hay fechas).
- Agilidad es hacerlo lo más rápido.
A la segunda ya le dediqué en su día un post, te dejo aquí el enlace, y sólo te resumo que no, que el modelo de trabajo más rápido a corto plazo no es el ágil, es el caótico, por ello, si ya estás en modo caótico pasar a ágil es más lento (a corto plazo, repito), el problema es que el caótico acumula tal cantidad de deuda técnica que pasado un tiempo se ha cargado la productividad de los equipos y eso ya no lo vas a resolver, fácilmente, ni intentando ahora trabajar de manera ágil.
Vamos con ahora con la primera.
“En agilidad no se sabe cuando se termina» (o la variante de que en agilidad no hay fechas)
Quien suele decir esto es que tiene inmerso en su cabeza el modo trabajo por proyectos: fecha inicio, fecha fin y requisitos de entrada (bien sea en modo de trabajo cascada o en caótico). Tampoco necesariamente en este modelo se sabe cuando se termina, bueno, se sabe cuando se termina el proyecto… pero no con qué, cual será el final… y si ese producto le valdrá a a alguien.
Recuerda que no es lo mismo terminar con lo previsto que con lo necesario.
Derivado de lo anterior. Los proyectos se sabe cuando se terminan (en teoría, que algunos no terminan nunca o se retrasan años) los productos software y los desarrollos sobre los mismos… no termian nunca (o no se sabe cuándo terminarán). Ojo con esto, que es un concepto de base, importnte y básico. Si un software apoya a un negocio, el software no se termina salvo que muera el negocio, siempre hay algo que evolucionar o corregir o sustituir (¿o se ha quedado tu organización sin desarrolladores, o empresas subcontratadas, en algún momento?) .
Esto es así, trabajes en ágil o como quieras, el software termina cuando muere el negocio que soporta, mientras… está en constante evolución (ya lo dijo Lehman en el 74, más en Las leyes de la evolución del software). Esta es la visión de producto frente a proyecto y es una de las razones que hacen que “los proyectos” encajen tan mal en organizaciones de base tecnológica.
Las obras de albañilería se terminan (la mayoría), el software no.
Si los trabajos sobre el software no terminan, son continuos (¿o se ha quedado tu organización sin desarrolladores trabajando en algún momento?) los métodos de trabajo que acompañan a dicha evolución constante (proyectos, cascadas, caos o agilidad) tampoco terminan (evolucionan, cambian o se sustituyen).
Los proyectos, termina uno, empieza otro, por medio hay bolsas de horas, etc., porque siempre hay gente trabajando sobre el software.
Dicho lo anterior, el concepto “cuándo se termina” tiene poco sentido y habría que reformularlo con lo que realmente hay detrás de esa expresión: en cascada o con proyectos ponía una fecha y unos requisitos y en agilidad no.
Cuando en tus proyectos ponías fechas y para ello requisitos podía pasar: a) que se cumpliera todo perfecto, b) que no se cumpliera c) que se cumpliera la fecha y te entregaran algo que no sirve para nada ni a nadie (pero cumple los requisitos).
¿Qué pasa con la agilidad? Que los “requisitos” (que no habría no que llamarlos así, pero bueno, no lo liemos más) pueden cambiar, y cambiarán, o se irán descubriendo, para asegurar que lo que se entregue sirve.
Las fechas sí las hay, al final de cada Sprint (si es Scrum tu caso), por ejemplo, debieras tener un producto potencialmente entregable, así que si se sabe cuando se entrega algo, si que hay fechas. Otra cosa es si con mucho tiempo de anticipación y con mucho nivel de detalle quieres saber qué se entregará en esa fecha.
No obstante, puedes no saber con exactitud qué se entregará (que funcionalidad, por ejemplo) pero sí “cuánto se entregará”, porque puedes hacer uso de la velocidad que sirve, entre otros, para hacer una estimación sensata y empírica.
Hasta este punto, el único pero que le puedes poner al asunto es la incertidumbre de qué funcionalidades habrá en la entrega de la fecha x (qué no tanto cuantas, resumiendo y sin entrar en más detalle de puntos historia. etc.). El resto… solo veo ventajas, tienes productos antes, mucho antes, tanteas el mundo real antes, tienes estimaciones de base empírica, sabes a largo plazo CUANTO y puedes cambiar y adaptarte.
La duda única duda es qué, y esa duda no la trae la agilidad, al trae el mundo, la vida y la innovación y las carencias adivinatorias para saber lo que le gusta y quieren comprar los clientes.
¿Que aún así no te gusta? Antes de tirarte a la zona de confort de los proyectos siempre te queda una opción: cierra “requisitos”, tus 200 requisitos de siempre, y empieza el desarrollo ágil. Puede que con el tiempo veas que fue una perdida de tiempo, que todos han cambiado, en cualquier caso te llevas esa posible perdida de tiempo y todas las otras ventajas: posibilidad de cambiar, estimación empírica, productos desde las primeras semanas.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Javier, por favor tu ayuda en ISO 20000, trabajo en una empresa donde hay un area de Tecnologias de la Informacion, esta se subdivide en 3 subares (area de Infraestructura tecnologica, area de Gobierno TI y el area de Sistemas de Informacion), trabajo en el area de Sistemas de Informacion donde se desarrolla un software que da servicios de informacion envio de dinero (como wester union, pero para empresas) a 3mil empresas, el software es lento porque esta en ambiente cliente servidor, se esta haciendo los cambios para que sea en ambiente web, pero todo es lento por malas coordinaciones, fuja de talento, cambios de jefes, etc, me han encargado la tarea de cambiar los procesos implementado ISO 20000, es conveniente usar ISO 20000 para cambiar los procesos de como se envia la informacion ya que el software es antiguo, y la solucion es cambiarlo y cambiar los procesos desde el analisis, el desarrollo, la implementacion, calidada y el soporte del software.¿EL Iso certifica a los procesos o al area?Gracias por tu respuesta
Por lo que yo se la 20000 certifica… un catálogo de servicios
No nos engañemos, a los responsables TIC no quieren o directamente no les dejan deshacerse de los proyectos para poder subcontratar lo más barato que haya dentro de los proveedores que se presenten a las ofertas. Con agilidad no puedes cerrar requisitos, presupuesto y fecha, con cascada sí porque puedes mentir sin problemas.