Mostrando las entradas con la etiqueta Comparación entre Tradicional y Agil. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Comparación entre Tradicional y Agil. Mostrar todas las entradas

martes, noviembre 12, 2024

Renové mi licencia como PMP

a la/s No hay comentarios.:
Etiquetas: , , , ,

martes, octubre 25, 2022

RespuestasAgiles ¿Cómo construir un proyecto TRADICIONAL y ejecutarlo en ÁGIL? (Usando Scrum)

a la/s No hay comentarios.:
Etiquetas: , , , , , , ,

jueves, octubre 06, 2022

El peligroso espejismo de la "Metodología Híbrida" en el mundo del software


Hola a todos

Hace poco tuve tres momentos en donde la metodología o enfoque híbridos de trabajo me los he topado y considero que es valioso escribir y aclarar sobre ellos:

Primer Momento: hablando a cerca del Lean Business Agility Model (LBAM) con el PMI Antioquia, me preguntaban mi opinión sobre el modelo híbrido, en esencia mi respuesta fue:

"Si lo que se está pensando es llevar prácticas de lo tradicional al mundo ágil, esto NO es exitoso, lo contrario sí puede serlo"

Segundo Momento: en varios clientes para los cuales trabajo me están comenzando a decir: "No, no somos ágiles, tenemos una metodología híbrida" y cuando voy a ver, están haciendo proyectos a alcance, tiempo y costo fijo por sprints, sobre lo cual hablaré más adelante.

Tercer Momento: en el reporte de Certiprof Anual - clic aquí -, el cual recomiendo ampliamente pues la mayoría de quienes lo respondemos somos latinos, y cuenta con interesantes hallazgos para nuestra cultura y región; Lucho Salazar y yo opinábamos sobre la aproximación híbrida en la ejecución de proyectos:

CertiProf Agile Adoption Report 2022

"Muchas organizaciones en su acercamiento a la hacia la agilidad han adoptado marcos híbridos, es decir, combinan prácticas ágiles y tradicionales; lo cual es ilustrado en la gráfica. Aunque este enfoque no es la mejor práctica, es un inicio que invita a seguir cambiando, pero si se continua allí puede constituirse en un riesgo a largo plazo, debido a que quienes abrazan la agilidad completamente logran aumentar entre tres a cuatro veces su productividad, tomando una ventaja creciente sobre las híbridas" - Jorge H. Abad L.

---

“Cada día un mayor número de organizaciones están trabajando con un enfoque Agile y Lean. El hecho de que la mitad del estudio los participantes respondieron que usar un enfoque híbrido es natural, dado que la mayoría de las empresas se encuentran actualmente en un proceso de cambiar de las prácticas tradicionales de gestión y ejecución a los basados ​​en el pensamiento ágil. Este es un proceso lento que puede llevar años. Las organizaciones no pueden y no debe comprometerse con un gran cambio o un cambio de "todo o nada", porque primero deben aprender a lidiar con los impactos del cambio y es mejor empezar poco a poco, con una o dos iniciativas. A partir de ahí, a medida que aprenden de las reacciones del entorno, pueden agregar nuevos equipos y áreas de la empresa al proceso. El hecho de que una de cada tres empresas ya esté utilizando un enfoque Agile es consistente con el trabajo que se ha estado haciendo desde la década pasada. Estas empresas han recorrido un largo camino para entender, internalizar, practicar y promover una cultura de colaboración y innovación, pilares esenciales de las organizaciones exitosas de hoy”. - Lucho Salazar

Pero vamos por partes, entendamos el por qué del título de este artículo.


¿Qué es una metodología híbrida?

Inspirado en la "Figure 2-7. Development Approaches del PMBoK 7.0

Un enfoque híbrido, está definido por: "Un enfoque de desarrollo híbrido es una combinación de enfoques adaptativos y predictivos. Esto significa que se utilizan algunos elementos de un enfoque predictivo y otros de un enfoque adaptativo. Este enfoque de desarrollo es útil cuando existe incertidumbre o riesgo en torno a los requisitos. Híbrido también es útil cuando los entregables se pueden modularizar, o cuando hay entregables que pueden ser desarrollados por diferentes equipos de proyecto. Un enfoque híbrido es más adaptativo que un enfoque predictivo, pero menos que un enfoque puramente adaptativo." (1).

Por lo tanto, no es un enfoque donde nos estamos preguntando y validando constantemente "si lo que se está construyendo o entregando es la solución correcta", como ocurre en el mundo del desarrollo de software, pero tampoco se tiene completa certidumbre sobre el resultado final, un ejemplo podría ser el despliegue de un nuevo proceso organizacional, que implique construcción de instalaciones, capacitaciones, desarrollo de software (este software se debe desarrollar con una aproximación ágil) y construcción de máquinas; son varios frentes que se pueden modularizar para entregar valor de forma incremental.

Alguien dirá: ¿Pero en el desarrollo de una solución de software sabemos que módulos vamos a tener? Posiblemente sí, pero el enfoque ágil (adaptativo) te garantiza que no construyas software de desperdicio, y la constante repriorización y refinamiento del backlog, sumado al despliegue continuo de la solución (que te permite su validación) puede significar que se halló valor mucho antes implicando que los supuestos iniciales quedaron obsoletos, pero logrando economias mayores 60% debido a su enfoque basado en Pareto (2).


¿Por qué es un espejismo peligroso en el mundo del desarrollo de software?

Por las siguientes razones:

  • Es una zona cómoda: he observado que se denomina híbrido a trabajar en cascada en grandes corporaciones, de forma que ya no es necesario tener al usuario con el equipo, ni es requerido que validen las soluciones. es decir,
el mismo desperdicio de siempre,

requerimientos al inicio, esfuerzo del proveedor, controles de cambio y quejas del cliente porque no entregaron lo que se pidió. Por lo tanto,

 Híbrido es el nombre de la nueva cascada corporativa

Observo que son organizaciones que no aprendieron a trabajar de forma ágil, no saben como hacer ahorros con este enfoque (aún siguen diciendo que ágil es costoso, lo cual es falso), pero para no verse muy anticuadas llamando a su metodología tradicional o cascada, le llaman híbrida, la cual es un desperdicio de tiempo, dinero, y oportunidad de generar valor por donde quiera que se le mire.

  • Están poniendo reglas de cascada a proyectos ágiles:  he visto que se llama metodología híbrida al ponerle al desarrollo ágil las reglas de cascada, es decir, alcance, tiempo y costo fijo, pero eso sí, hecho en sprints, pero sin retrospectivas porque no es necesario aprender más ¡Plop! - recomiendo leer la referencia (3)-.
  • Se está perdiendo oportunidad de generar y atrapar más valor: las organizaciones al casarse con este modelo híbrido (insisto no veo problema con que sea algo temporal, lo que veo peligroso es que de allí no se evolucione), están perdiendo oportunidad de capturar valor y de generarlo a sus clientes y más temprano que tarde, organizaciones que realmente si ejecuten ágil de forma disciplinada les tomarán una ventaja exponencial, debido a que la agilidad bien practicada cuadruplica la generación de valor y la eficiencia de los equipos.

¿Cómo evitar el espejismo?

Hay varias estrategias que pueden ayudar en evitar el espejismo:

  • Comprender en que consiste la mentalidad lean-agile (3).
  • Comprometerse a ejecutar los proyectos ágiles (y por ende de desarrollo de software) con las reglas de ágil, de forma que se generen ahorros y altos impactos.
  • Si se tiene un proyecto tradicional y quiere volverlo híbrido, identifique posibles módulos, formas de generar valor temprano y retroalimentación valiosa en caso de que aplique; de manera que logre adaptaciones en caso de ser posible.
  • No lleve prácticas tradicionales al mundo ágil, es decir, planeación predictiva para el mundo del software, pues estas no van a servir.


Para cerrar, algunas ideas ágiles para el mundo tradicional

Como se ha argumentado en el artículo, llevar prácticas tradicionales al mundo ágil es desperdicio y fricción, pero existen prácticas ágiles que pueden mejorar el mundo tradicional, a continuación, algunas ideas:

  • tener dailys de sincronización del equipo de trabajo
  • hacer retrospectivas o sesiones de mejora con cadencia de al menos de una vez al mes.
  • usar backlogs y priorizarlos constantemente si la naturaleza del proyecto lo permite.
  • preguntar y preguntarse constantemente ¿si lo que se hace está generando valor? y corregir en caso de que no.
  • Identificar mínimos productos viables y liberarlos incrementalmente: 
    • Ejemplo 1: Una casa de campo de forma incremental y adaptativa (pues no se posee todo el dinero), un posible plan de releases puede ser:
      • Release 1 o MVP (PMV - Producto mínimo viable): La cocina, el baño, y una habitación para dormir.
      • Release 2: otro cuarto
      • Release 3: la sala
      • Release 4: la piscina
      • Release 5, etc, etc.
    • Ejemplo 2: Una unidad residencial de 12 torres
      • Release 1: torre 1 y 2 
      • Release 2: torres 2 y 3
      • Release 3: la piscina y el salon social
      • Release 4: no se realizó debido a cambios económicos del entorno.

a la/s No hay comentarios.:
Etiquetas: , , , , , , , , , ,

miércoles, agosto 22, 2018

MiniManual para la Gestión por Valor

a la/s No hay comentarios.:
Etiquetas: , , , , , , ,

martes, julio 31, 2018

Datos, Hechos y Beneficios de Agile+DevOps en una Empresa Pública de Colombia

Hola a todos

Aunque cada vez es menos frecuente la incredulidad hacia Agile, siempre es bueno contar con casos de éxito y en especial con una colección de métricas capturadas en un entorno empresarial, para compartirlas con personas y empresas que se están acercando al concepto.

A continuación les comparto este Tweet de Claudia Toscano quien trabaja en área de TI de Empresas Públicas de Medellín (empresa con sede en Medellín - Colombia), con una hermosa colección de métricas como resultado de aplicar Agile y DevOps en su entorno.

Aunque parece obvio, importante resaltar que corresponden a datos de una Empresa Pública.






Nota Importante: Si como empleado público (o empleado privado) insistes en contratar proyectos de desarrollo de software en cascada (waterfall, o tradicional, es decir: una fase larga de levantamiento de requisitos, luego otra de desarrollo, luego una tortuosa de pruebas y por fin una entrega tardía y un contrato con alcance, tiempo y costo fijo) es muy probable que estés incurriendo en algo que en Colombia le llamamos Detrimento Patrimonial - es decir, estas haciendo mal uso de los recursos del Estado - o de tu organización - y estas probablemente derrochando probablemente un valor cercano al 50% del valor del contrato-, pues existen numerosos estudios que demuestran que hacer proyectos en cascada genera desperdicios en funcionalidades que no serán usadas cercanos al 50%. Anexo resultados de un estudio muy conocido "el Manifiesto del Caos  del 2013(ver Página 6)":

Te comparto algunos links que aun funcionan:

Saludos ágiles
Jorge Abad



a la/s No hay comentarios.:
Etiquetas: , , , , , , , , ,

martes, abril 17, 2018

Tweet: Agile no gestionar por alcance sino por valor

a la/s No hay comentarios.:
Etiquetas: , , , , , ,

martes, agosto 29, 2017

Datos reales comparativos entre un proyecto construido en Cascada y otro con Scrum

Hola a todos

Uno de los datos que más carecemos en nuestra industria es datos comparativos entre Cascada y Scrum basados en el mismo proyecto, tal vez por que transparentan ineficiencias de un modo de trabajo que por años defendimos todos (yo el primero) y que va de salida en el mundo del desarrollo de software a la medida.

A continuación les comparto datos de un proyecto real, correspondiente a una empresa radicada en Colombia, espero poder en un futuro cercano contar con las autorizaciones poder publicar las referencias exactas.


Espero les sea de utilidad.


Saludos ágiles

Jorge Abad
a la/s 2 comentarios:
Etiquetas: , ,

sábado, julio 29, 2017

Noticia Falsa: En cascada no existía deuda técnica




Hola a todos, hace poco compartía con un compañero el cual trabajó durante mucho tiempo en cascada y ahora esta comenzando a trabajar con scrum y esta viéndose en unos retos bien importante, el cual me argumentaba que:

- en cascada los problemas no teníamos los problemas de deuda técnica que existen en ágil. En cascada siempre entregabamos...

no les niego que mi cara fue similar a esta.



Vamos primero a aclarar términos:

Ver más sobre deuda técnica en (1)
La verdad parece que se nos olvida que en proyectos construidos en cascada de más de 6 meses (2) pasan las siguientes disfuncionalidades respecto a la parte técnica:
  1. Nos comprometemos a una fecha y no la cumplimos
  2. Las pruebas las empezamos 2 o 3 meses después de la fecha de finalización del proyecto (si es que tenemos suerte)
  3. Nos quedamos en ciclos interminables de pruebas (4, 5 o  hasta más) para poder entregar el sistema.
  4. El cliente nos acepta el producto después de dós o más ciclos de pruebas
  5. Salimos a producción muertos de miedo y estabilizando el sistema por más de 6 meses (muchas de las condiciones de aceptación de un producto en cascada dice cuando por 2 meses no aparezcan problemas en producción).
Estas disfuncionalidades son mayormente creadas por la pobre calidad técnica y lo que estamos tratando de hacer es entregar el proyecto con fuerza bruta.



¿Y en Agile como es?

La verdad es que, si tenemos excelencia técnica (buenas prácticas ágiles, buena ingeniería, buena arquitectura),  esto no se presentará (o al menos se reducirá enormemente su impacto) y la imagen de arriba hará honor a lo que profesamos:
  • Entregamos software de valor frecuentemente
  • Y la medida de progreso es software funcionando
Pero la realidad no es así, los equipos en general caen en "Agilidad Cosmética" que tiene como síntomas:
  • Solo se centra en el proceso scrum (o como sea que lo llamen) y no en las personas.
  • Los equipos no mejoran sus prácticas técnicas.
  • Los scrum masters solo se enfocan en mejorar la comunicación del equipo cuando hay muchos aspectos a mejorar.
  • Las retrospectivas son las mismas hace 5 sprints.
  • Los equipos no son retados técnicamente por el scrum master (ver más acá Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo).
  • No se gestiona la deuda técnica.
  • No hay una preocupación seria por parte del equipo de la excelencia técnica.
Y debido a la entrega frecuente hace que la pésima calidad del software evidencie más rápido nuestras falencias técnicas como equipo de desarrollo.

Algunos tweets

Para terminar quisiera compartirles algunos tweets relacionados con la deuda técnica y la excelencia técnica tanto en cascada como en ágil.















Comentarios, Aclaraciones, Notas y Referencias

  1. Presentación sobre deuda técnica (clic aquí)
  2. En proyectos más pequeños de tamaño (5 meses o menos) las disfunciones técnicas que tiene cascada para desarrollo de software no se evidencian tan fácilmente como en proyectos grandes, pues en últimas el mal código siempre generará impacto tipo de impacto en el tiempo, costo y satisfacción del cliente independiente del tamaño del proyecto (Gracias Luis Mulato @LuisMulato por el feeback y correciones respecto a este último punto y al post)
a la/s No hay comentarios.:
Etiquetas: , , , , , , , , , ,

miércoles, julio 26, 2017

Un tweet sobre #Agile

a la/s No hay comentarios.:
Etiquetas: , , , ,

lunes, enero 30, 2017

La Ilusión del Control o ¿Cómo Hago para Controlar un Proyecto Ágil?






Hola a todos

Dentro de las muchas ocasiones en las que comparto con clientes, equipos, product owners, scrum masters o personas que van a comenzar a trabajar en Agile una pregunta recurrente es:

¿Cómo hago para que el proyecto no se salga de control?


Vamos por partes entonces:

¿Qué se quiere decir con la pregunta?

La Rae define control como (Ver definición - clic aquí):


y cuando un cliente o gerente, lider funcional, product owner, o gerente de proyecto pregunta esto se refiere típicamente a esto:

¿Cómo hago para que el proyecto no cueste más, no se demore más, se construya realmente lo que se requiere o no se quede eternamente consumiendo recursos(1)?

Poniendo este tema en blanco y negro, comencemos.

No es que exista mucho control con los proyectos en cascada 

En el informe del caos los proyectos en cascada no salen muy bien librados versus los ágiles, los cuales muestran un resultado más satisfactorio en cuanto tiempo y costo.(https://www.infoq.com/articles/standish-chaos-2015 )



Dado esto:
  • La probabilidad de cumplir estas expectativas es más alta en Ágil que en Cascada, ahora respecto a que el proyecto se vaya a desbordar el problema existe en cualquiera de los dos enfoques, el problema radica en el mecanismo para estar informados si vamos a lograr o no la meta propuesta y reaccionar a tiempo.
  • Los proyectos en cascada cuando se salen de control - de tiempo o costo- (el alcance lo tienen garantizado, tal vez se construya lo que NO se necesita - como ocurre en muchos casos - pero esta garantizado el "qué") o costarán más o nos demoraremos más (ambas son dinero para alguien), el punto clave es que tan diestro es el proveedor para gestionar los cambios:
    • si el proveedor es experimentado o tiene un buen gerente de proyectos el sobrecosto lo asume el cliente, sino 
    • el sobrecosto lo asume el proveedor, caso más común.
  • En cascada (y muchos lo hemos vivido) el proyecto y el cronograma va bien hasta la parte de análisis (como diría un conocido mío: "el papel aguanta todo", todo se complica cuando comienzan las fases de desarrollo, la fase de pruebas con informes de avance que del 90% luego a las tres semanas 90.3% , a las 4 semanas 90.38% y el proyecto se demora un 90% del tiempo cerrando el 10% faltante del alcance (fruto de la procrastinación o postergación del proceso en cascada) y si logramos entregar el proyecto terminamos entregando el producto tardíamente a nuestros clientes o al mercado, tal vez cuando ya no lo necesitan o cuando las condiciones iniciales que dieron origen al proyecto cambiaron.
La verdad, a lo anterior yo no llamaría control


Cómo se "controlaría" un proyecto en ágil

Ahora respecto a la comprobación, inspección, fiscalización, intervención. del cual habla la RAE, se tienen varias soluciones:

1. La Transparencia

En ágile nos enfocamos en valernos de radiadores de información que nos permitan tomar decisiones informadas y todos conocer como está el proyecto y producto en cualquier momento:

  • Burndown chart del Sprint
  • Burndown o burn up release (clic aquí)
  • Flujo Acumulativo
  • Velocidad
  • entre otros

2. La brújula de la agilidad es la simplicidad

Comencemos recordando el décimo principio del manifiesto ágil:

la simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial

Decifrando este juego de palabras podemos parafrasearlo diciendo

Nuestra mayor prioridad es NO generar ni software ni trabajo de desperdicio (o hacer algo que terminará siendo inutil)


3. En Scrum existen tres roles que te pueden ayudar a tener "control" de tu proyecto / producto, en cuanto tiempo, costo y alcance.

Product Owner (PO)
En primer lugar el PO es quien esta encargado dentro de sus funciones de dos aspectos claves:

  • ROI (Return On Investment): Preocupado por salir a producción con la menor cantidad de software posible que solucione el problema de negocio
  • DECIR NO (5): El PO al negociar con los stakeholders (interesados) les debe decir para ciertas funcionalidades:
    • eso no se puede hacer aún, 
    • necesitamos generar valor con lo mínimo posible
    • eso va para otra versión o release
    • eso aun no tiene prioridad
    • entre otras.
Es decir la misión del PO es mantener el Backlog de cada release lo mas pequeño posible de forma que se genere valor con la menor cantidad de software.

Scrum Master (SM)
El otro rol es el Scrum Master, este es el coach del PO y estará atento a que quien esta ejecutando este rol lo haga bien y este preocupado sanamente por mantener un product backlog refinado y priorizado.

El Equipo Desarrollador (Development team, o equipo solucionador)
Y por si fuera poco, es una buena practica que cada Relase tenga un objetivo (3)(4), por lo tanto cuando el PO este "corrompiendo el alcance" - como dicen el el mundo PMBoK - por añadir lo que no es clave para el proyecto, tanto SM como Equipo Desarrollador se lo harán ver.

Adicionalmente existe el Review
Cada sprint (ciclo de trabajo entre 2 y 4 semanas) el equipo Scrum - PO, SM y Equipo Desarrollador -  más los Stakeholders del proyecto se reúnen a ver el demo del sprint -a ver software funcionando cumpliendo la definición de terminado- , ha realizar inspección y adaptación sobre el producto y a decidir como seguir avanzando sobre el mismo, de manera que no hay sorpresas y el progreso o no progreso es evidente para todos.

Y si es que lo anterior no funciona
Ahora si ves que el proyecto no lo va a lograr..
  1. Desde las primeras dos semanas tuviste software funcionando 
  2. Suspende el proyecto y fin de la historia.

Cerrando

Los proyectos y productos que son construidos con el enfoque ágil pueden darnos suficiente información sobre su estado y nos permitirán tomar decisiones informadas sobre el éxito y fracaso de los mismos,  depende de nosotros emplearlos o no. En cascada si decides interrumpir el proyecto es probable que no tengas al final ni siquiera software funcionando pues depende mucho de la fase en que se interrumpa o finalice abruptamente el proyecto

Hasta acá esta pequeña reflexión, espero sea útil.

Bienvenido el feedback y sus comentarios

Saludos ágiles

Jorge Abad

Referencias, Comentarios, Notas y Aclaraciones

  1. Entendiendo recursos como dinero y tiempo invertido por las personas o empresas
  2. http://agilemanifesto.org/iso/es/principles.html
  3. La "Zona de Valor de Negocio". Una reflexión sobre ¿cuándo termina un release en un proyecto Ágil / Scrum?-  http://www.lecciones-aprendidas.info/2016/04/la-zona-del-valor-de-negocio-una.html 
  4. Go Product Map -  http://www.romanpichler.com/tools/product-roadmap/
  5. Este post está altamente relacionado con este: El valioso "NO" del Product Owner



a la/s No hay comentarios.:
Etiquetas: , , , , ,

jueves, enero 05, 2017

Mi punto de vista: ¿Bimodal un punto medio entre la agilidad y la predictibilidad?


En la actualidad la Banca, los Seguros (y hace algún tiempo el Transporte, La Hotelería) entre otras industrias están sufriendo grandes cambios debido a la fuerte disrupción digital (1), la velocidad a la que está avanzando la tecnología, la economía, las comunicaciones es tal, que "estos negocios cambian o se convertirán en otro caso de estudio" (ver tweet).

Como medio de apalancamiento las organizaciones han decido abrazar la agilidad como herramienta para enfrentar el cambio, pues en sus fundamentos y pilares están los factores de éxito de los negocios que están cambiando las reglas de juego. Por lo tanto, no se adopta la agilidad como una evolución natural hacia la generación de valor en periodos cortos con equipos multifuncionales y felices (cosa impensable y que no estaba en el core de sus intereses), sino que se llega a ella como salida hacia la supervivencia, razón por la cual muchas organizaciones quieren comprar la agilidad por kilos, sin comprender que se requieren esfuerzos para transformar la cultura para lograr ser exitoso en este enfoque.

Debido a esto - es mi observación -  es común ver como organizaciones al hablarles de Agile, preguntan más sobre bimodal,
"Bimodal is the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration. Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory, experimenting to solve new problems and  optimized for areas of uncertainty. These initiatives often begin with a hypothesis that is tested and adapted during a process involving short iterations, potentially adopting a minimum viable product (MVP)  approach. Both modes are essential to create substantial value and drive significant organizational change, and neither is static. Marrying a more predictable evolution of products and technologies (Mode 1) with the new and innovative (Mode 2) is the essence of an enterprise bimodal capability. Both play an essential role in the digital transformation."  http://www.gartner.com/it-glossary/bimodal/

pues no quieren soltar el esquema tradicional y quieren poner un "if o condicional" para determinar cuando adoptar el uno o el otro, pues no entienden los beneficios entre Ser Ágil y Hacer Ágil. (obvio para eso estamos los de este mundo para ayudar a comprender esta diferencia)



¿Por qué entonces trabajar en Agile?

Existen varias razones

  1. La ley de la incertidumbre de los requisitos: “Para un nuevo sistema de software, los requisitos no serán completamente conocidos hasta después de que los usuarios hayan usado el sistema" Watts S. Humphrey” (3)
  2. La incertidumbre inherente en productos y procesos de software "“La incertidumbre es inherente e inevitable en los procesos y productos del desarrollo de software”(3)
  3. La cantidad de software de desperdicio que se construye en cascada (4)
  4. La inestabilidad de los requisitos y su volatilidad convirtiéndolos casi en material radioactivo que se degrada con el tiempo. Actualmente el tiempo promedio de vida de un requisito está en 6 meses- o tal vez o menos -.(5)
  5. La velocidad de cambio en el mundo de los negocios (1)
  6. La posibilidad de ver el producto funcionando en dos semanas o menos y poder redireccionar y repriorizar hacia el problema que quiere resolver el producto de software que vamos a construir.



Para complementar comparto algunos links a post comparativos:

  • Por qué los Equipos Scrum son más “rápidos” que los tradicionales. Un enfoque desde Lean Software Development (clic aquí)
  • Waterfall vs Agile (clic aquí)
  • Gráficas Ágil vs Tradicional (clic aquí)
  • El Lego y la plasticidad del software (clic aquí)


En que proyectos se recomienda cascada

Gráfica de Henrik Kniberg
Sugiero se cumplan ciertas premisas
  • El cliente sabe exactamente que es lo que quiere
  • Los desarrolladores son conocedores del negocio y de la tecnología
  • No haya incertidumbre, se sabe exactamente lo que se quiere
  • El tiempo transcurrido desde que el proyecto comienza el tramite para su aprobación y la finalización de su desarrollo es inferior a seis meses, de forma que se evite la corrupción de requisitos por el tiempo de levantamiento o identificación de la necesidad superior a seis meses(5)
  • Yo sugiero proyectos de máximo tres meses cuyos requisitos no tengan más de 3 meses de haber sido levantados.

Además recordemos que:



Concluyendo


Dado lo anterior, la inestabilidad de requisitos, el entorno cambiante, la incertidumbre reinante, y la sugerencia de realizar proyectos en cascada para periodos menores a tres meses, observo que:
  • El enfoque bimodal es más una herramienta de transición entre modelo tradicional o cascada al modelo ágil, que un "if-condicional" para clasificar diferentes tipos de proyectos, pues por un tiempo, ambos modelos convivirán- ágil y cascada- (6), y llegará el momento en que la organización concluya por sus propios medios si es conveniente que sigan ambos o desaparezca uno de los dos.
  • El modelo bimodal no es sostenible en el tiempo, pues la evolución los sistemas existentes requerirá de repriorizaciónes de backlog en los cuales ágil es mucho más eficiente.
  • Para que el modelo bimodal sea exitoso requeire de  procesos ágiles de priorización y aprobación de proyectos, sino cuando se construyan ya sea los proyectos tradicionales o ágiles será tarde para el negocio o el mercado.
  • Es importante hacerse acompañar por quienes tengan experiencia en ágil para no fallar y realizar malas transformaciones y adopciones, y que por ende se lleguen a conclusiones y resultados erróneos que no reportarán todo el beneficio de Agile.
  • Cada organización debe encontrar su ritmo, su cadencia, su mejor forma de transformarse a Agile, que le permita aprender de si misma, de su cambio cultural para realizar procesos de cambio exitosos
Bienvenidos los comentarios y apreciaciones


Saludos Ágiles
Jorge Abad


Notas, Comentarios, Aclaraciones y Referencias

  1. Empresas tradicionales: llegó la hora de desprenderse del pasado o desaparecer. Revista Dinero (clic aquí).
  2. Manifiesto Ágil (clic aquí)
  3. Post: Principios de Incertidumbre de Requisitos, Procesos y Productos de Software (clic aquí)
  4. http://versionone.com/assets/img/files/ChaosManifesto2013.pdf: "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. " 
  5. Post: Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software (clic aquí)
  6. Es mejor realizar una transformación guiada por pilotos y casos de éxito en los cuales la organización encuentre su mejor forma de SER ÁGIL, que una transformación big-bang que trae consigo una gran entropía al sistema y requiere de una gran cantidad de energía (Coaches, Scrum Masters, Agentes de Cambio) para estabilzarlo




a la/s No hay comentarios.:
Etiquetas: , , , , ,

domingo, diciembre 18, 2016

Tan cerca, Tan lejos. Una Comparación entre el Agile Inception y el Acta de Constitución del Proyecto (Project Charter) del PMBok



Hola a todos
Desde hace un tiempo me debía a mí mismo y a ustedes la escritura de este post, pues en numerosas ocasiones durante los entrenamientos de Scrum o Gerencia de Ágil de Proyectos he hecho esta comparación, y es bueno dejarla plasmada para ayudar mejor a la ilustración de lo que quiero decir.

Los Dos Mundos, el Predictivo y el Ágil

Dentro de los 47 procesos de la gerencia de proyectos del PMBoK (versión 5) existe el primer proceso llamado “4.1 Desarrollar el Acta de Constitución del Proyecto” (este proceso pertenece a los procesos de inicio) que cuenta básicamente con los siguientes aspectos
·         Objetivo
o   “Es el proceso de desarrollar un documento que autoriza formalmente la existencia de un proyecto y confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto”(1)
·         Entradas
o   Enunciado del trabajo del proyecto
o   Caso de Negocio
o   Acuerdos
o   Factores ambientales de la empresa
o   Activos de los procesos de la organización
·         Herramientas y Técnicas
o   Juicio de Expertos
o   Técnicas de Facilitación(2)
·         Salidas
o   Acta de constitución del proyecto
Y sugiere documentar los siguientes aspectos (1):
·         El propósito o la justificación del proyecto,
·         Los objetivos medibles del proyecto y los criterios de éxito asociados,
·         Los requisitos de alto nivel,
·         Los supuestos y las restricciones,
·         La descripción de alto nivel del proyecto y sus límites,
·         Los riesgos de alto nivel,
·         El resumen del cronograma de hitos,
·         El resumen del presupuesto,
·         La lista de interesados,
·         Los requisitos de aprobación del proyecto (es decir, en qué consiste el éxito del proyecto, quién decide si el proyecto tiene éxito y quién firma la aprobación del proyecto),
·         El director del proyecto asignado, su responsabilidad y su nivel de autoridad
·         El nombre y el nivel de autoridad del patrocinador o de quienes autorizan el acta de constitución del proyecto.
Para mayor ilustración sugiero leer este articulo del PMI Colombia (Acta de Constitución del Proyecto) y este excelente ejemplo (Ejemplo Acta de inicio del Proyecto)
Ahora, si realizamos los talleres de Agile Inception (Inicio Ágil – en español) como los sugieren:
·         The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers) de Jonathan Rasmussone (clic aquí)
·         Inceptions. Starting a Software Project de Enrique Comba Riepenhausen (clic aquí)
Encontramos que sugieren en un taller de 2 a 3 días obtener lo siguiente
·         Quién está en el Salón o Taller
·         Las reglas de Juego del taller
·         Por qué estamos aquí (en este taller)
·         Crear el Elevator Pitch
·         Diseñar la caja de producto
·         Crear el Product Backlog Board(3)(4)
·         Crear la lista de No
·         Encontrar tu comunidad
·         Que te mantiene despierto en la noche
·         Muestra la solución
·         Darle una personalidad a la solución
·         Mostrar el flujo
·         Story Mapping (Plan de Releases)
·         Qué vamos a obtener (Restricciones, Prioridades, Beneficios)
·         Cuánto va a costar y cuánto nos va a tomar

Y si comparamos ambos
Realizando la comparación de ambos, se tienen muchas coincidencias:
Agile Inception
Acta de Constitución del Proyecto (PMBoK)
·         Quién está en el Salón o Taller
·         Las reglas de Juego del taller
·         Aplica parcialmente, no siempre es un taller.
·         Por qué estamos aquí (en este taller)
·         Crear el Elevator Pitch
·         El propósito o la justificación del proyecto,
·         Diseñar la caja de producto
·         Product Backlog Board
·         Los objetivos medibles del proyecto y los criterios de éxito asociados,
·         Los requisitos de alto nivel,
·         Los requisitos de aprobación del proyecto (es decir, en qué consiste el éxito del proyecto, quién decide si el proyecto tiene éxito y quién firma la aprobación del proyecto -  esta última parte no corresponde a un inception - ),
·         Crear la lista de No
·         Los supuestos y las restricciones,
·         La descripción de alto nivel del proyecto y sus límites,
·         Encontrar tu comunidad
·         La lista de interesados,
·         Que te mantiene despierto en la noche
·         Los riesgos de alto nivel
·         Muestra la solución
·         Darle una personalidad a la solución
·         Mostrar el flujo
·         La descripción de alto nivel del proyecto y sus límites,
·         Story Mapping (Plan de Releases)
·         El resumen del cronograma de hitos,
·         Que vamos a obtener (Restricciones, Prioridades)
·         Los supuestos y las restricciones,

·         Cuánto va a costar y cuánto nos va a tomar (estos valores son aproximados, nunca cerrados)
·         El resumen del presupuesto,
·         No aplica
·         El director del proyecto asignado, su responsabilidad y su nivel de autoridad
·         No aplica
·         El nombre y el nivel de autoridad del patrocinador o de quienes autorizan el acta de constitución del proyecto.


¿Entonces en dónde radica la diferencia?

En esencia, se observa que es lo mismo para ambos tipos de iniciativas (predictiva o ágil), aún más el PMBoK sugiere que sean talleres facilitados y no dudo que algunos gerentes de proyecto lo hagan así, pero lo que si es cierto es que en Agile es necesario (por no decir obligatorio) que sea un taller y que se maximice la comunicación cara a cara como lo sugiere el manifiesto ágil y sus principios (5) para garantizar el éxito de lo que se va a realizar.
Adicional en proyectos tradicionales (en los cuales la planeación predictiva es ideal):
-          Construcción de edificios
-          Construcción de puentes
-          Construcción de carreteras
-          Ampliaciones de fábricas
-          Construcción de barcos
Se hace hasta lo imposible por cerrar el alcance y no dejar lugar a la incertidumbre, pues el costo de los cambios es altísimo (¿o no creen que un dos nuevos carriles en la carretera o 2 pisos más en el edificio, fuera de afectarán gravemente los planes, cambiará el diseño de temas importantes?), cosa muy distinta en desarrollo ágil donde el software es más maleable y  donde somos tenemos una arquitectura base sobre la que podemos evolucionar.
Para cerrar esta pequeña comparación, les comparto esta tabla en donde presento las principales diferencias de ambos enfoques:

Agile Inception
Acta de Constitución del Proyecto (PMBoK)
Propósito principal

No es el objetivo del Inception, esto debe ser resuelto antes.
Autoriza formalmente la existencia de un proyecto
No tiene como objetivo entregar Autoridad.


confiere al director del proyecto la autoridad para asignar los recursos de la organización a las actividades del proyecto
Es un taller que permite a los interesados y al posible Product Owner(PO):
·         Entender la idea que se tiene a un nivel más profundo
·         Identificar las posibles dificultades del proyecto
·         Decidir si se continuará o no con el mismo
·         Proporciona al PO y a sus Interesados información suficiente para guiar al equipo de desarrollo en la construcción del producto
No corresponde a su objetivo primordial
Respecto al alcance
Se busca tener una primera versión u hoja de ruta sobre las cuales realizaremos la construcción del producto mínimo viable (MVP - http://www.lecciones-aprendidas.info/search/label/mvp ) y seguiremos creciendo incrementalmente hasta que construyamos el producto que requiere el negocio.
Se centra en esbozar el alcance va a detallar y gestionar en las siguientes grupos procesos de la gerencia de proyectos:
·         Planeación
·         Ejecución
·         seguimiento y control
·         y cierre
Transparencia
Esta información queda disponible al lado del equipo del proyecto para que sirva como radiador de información y le sirva para tomar decisiones
Muchas veces no es un taller, se comparte con el equipo y los interesados del proyecto, pero no se garantiza que todos la conozcan aunque se sugiere que todos la dominen.

Hasta acá esta corta comparación, los invito a profundizar en estos links
-          Webinar- Agile Inceptions - http://www.lecciones-aprendidas.info/2016/08/inceptions-con-lucho-salazar.html
-          Story Mapping - http://www.lecciones-aprendidas.info/2016/06/user-story-map-mapas-de-historias-de.html
-          EDT Ágil - http://www.lecciones-aprendidas.info/2016/07/hola-todos-cuando-desde-la-gerencia-de.html
-          Sprint Cero o Agile Inception
o   http://www.lecciones-aprendidas.info/search/label/inception
o   http://www.lecciones-aprendidas.info/search/label/sprint%20cero
-          Colección de entregables generados en un Inception
o   http://www.lecciones-aprendidas.info/search/label/product%20backlog%20board

Bienvenidos sus comentarios y feedback.

Saludos Ágiles, 

Jorge Abad        


Notas, aclaraciones, referencias

1.       Guía de los Fundamentos para la Dirección de Proyectos. Guía del PMBoK Quinta Edición.
2.       Se enumeran entre varias posibles actividades: la tormenta de ideas, resolución de conflictos, gestión de reuniones para realizar la obtención de este entregable.
3.       Aunque no Corresponde a una propuesta de Agile Samurai o Inceptions, es ampliamente usado y recomendable para este proceso
4.       Ejemplos del Product Backlog Board - http://www.lecciones-aprendidas.info/search/label/product%20backlog%20board
5.       http://agilemanifesto.org/iso/es/principles.html - “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.”,  “El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.”
a la/s 1 comentario:
Etiquetas: , , , , , , , , , ,
Suscribirse a: Entradas (Atom)