Mostrando las entradas con la etiqueta Lesa Agilidad. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Lesa Agilidad. Mostrar todas las entradas

jueves, noviembre 02, 2023

Presentación: Los puntos ciegos del Scrum Master - Actualización 2023

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

miércoles, noviembre 01, 2023

El lado oscuro de la agilidad - Frase

_




"El lado oscuro de la agilidad no es medir, es no mejorar" - Jorge Rafael Aristizabal - Agile Coach



_ 

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

martes, julio 12, 2022

Allí, la agilidad ha muerto

 Algo lamentable que estoy viendo pasar en muchas latitudes e industrias con los equipos ágiles, y sus análisis desde las áreas de gestión y PMO, es un dialogo similar a este:


- Ok, ok, muy bien, ya lograron el alto desempeño del equipo, lograron duplicar o hasta cuadruplicar la "productividad" de los equipos con #Agile y #DevOps. Entonces, ahora sí, volvamos al micromanagement, equipos multiproyectos y a las estimaciones "exactas".


Una y otra vez estoy viendo suceder esto, destruyendo los resultados obtenidos.


Allí, la agilidad ha muerto.

---


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

sábado, septiembre 12, 2020

Serie: Lesa Agilidad

-Mucho gusto soy el Product Owner
-¿Y vas a estar con el equipo?
- No, ya escribí todas las hu, solo vendré a los review a recibir el producto y ver el progreso
a la/s No hay comentarios.:
Etiquetas: , , , , ,

sábado, febrero 29, 2020

Agile Apesta | Ágil Apesta | Agile Sucks

¡Que bueno, atrapé tu atención! Al parecer varios estudios han demostrado nuestra preferencia por las noticias malas y todo aquello escrito en tono negativo es fuente de observación inmediata de nuestra mente, ya sea por instinto de supervivencia o por morbo, es una de las razones por las cuales las redes sociales y los periódicos tienden a volverse más tóxicos -les recomiendo ver las referencias (1)-.

Quiero aprovechar este comportamiento que todos poseemos para compartirte que Agile Apesta o Ágil Apesta o Agile Sucks bajo muchas circunstancias endógenas y exógenas, pues se volvió un objeto de deseo, mas eso no implica que se esté haciendo bien, se asemeja más a un jabón resbaloso que solo se deja atrapar junto a la esquina de la ducha, que a un concepto claramente entendido y dominado por todos.

Ágil según la propuesta de Alistair Cockburn (uno de los firmantes del Manifiesto Ágil) podría resumirse en 4 pilares (que él denomina el Corazon de Ágil - https://heartofagile.com ), todos trabajando a la vez, ninguno más importante que otro, complementándose y ayudándose:
  • Entrega de Valor (entiéndase como lo que el cliente quiere y con calidad)
  • Reflexión (Inspección y Adaptación)
  • Mejora Continua
  • Colaboración

Corazón de Ágil por Alistair Cockburn (2)

Cuando alguno de estos elementos falta o está mal concebido, lo que llamamos ágil, apesta y generará más problemas que soluciones.

A continuación te comparto un breve listado que he identificado cuándo Ágil Apesta y mucho.

Ágil apesta cuando:
  • Exógenas a los equipos ágiles
    • cuando es contratado con alcance tiempo y costo fijo (clic aquí)
    • la PMO hace seguimiento tradicional a un enfoque ágil 
    • a la empresa no le gusta la transparencia y "mata" al mensajero que trae las malas noticias, de que las cosas no funcionan
    • la empresa dice que no necesita acompañamiento y cree que con dos días de entrenamiento de sus gerentes de proyecto es suficiente
    • la empresa cree que es solo ponerle a los Gerentes de proyecto el rol de Scrum Masters, y a los Business Analyst el rol de Product Owners.
    • la empresa cree que será ágil en 3 meses y exige un plan para hacerlo 
    • cuando la alta dirección no está involucrada y delega el cambio 
    • a las personas les siguen diciendo recursos 
    • no se exige excelencia técnica, ni internamente ni a proveedores
    • no se remueve la deuda técnica.
    • tenemos a los equipos bajo presión y les imponemos lo que deben entregar y cuándo deben hacerlo 
    • cuando creemos que sabemos más que el Agile Coach o el Scrum Master con experiencia y no se siguen sus recomendaciones
    • cuando no dejamos madurar los pilotos ágiles (al parecer 6 meses es una buena métrica para empezar)
    • Cuando mi jefe dice que es ágil pero no le puedo dar feedback, ni le puedo sugerir cosas.
  • Endógenas a equipos ágiles
    • no se entrega valor al cliente de forma temprana y continua
    • no existe excelencia técnica 
    • el alcance está fijo 
    • no se reflexiona, es decir, no se hace inspección y adaptación.
    • cuando tienes soluciones ahogadas en deuda técnica
    • cuando no usas DevOps
    • cuando la mejora continua se enfoca únicamente en los procesos y las personas y no se enfoca en resolver los problemas técnicos (clic aquí)
  • Endógenas a Scrum 
    • el 50% de los equipos Scrum apestan (se lo vi decir a Jeff Sutherland, pues no son capaces de generar valor y de lograr un desempeño del 400% - promesa cumplida por Scrum una y otra vez) 
    • las historias de usuario demoran dos o más sprints en ser construidas y nos olvidamos que a lo sumo deben tomarnos entre 2 a 4 días en construirse totalmente, es decir, con pruebas y despliegue incluido.
    • se tienen Scrum Masters (SM) con 3 equipos (lo mejor, es un SM por equipo, lo menos peor es un SM con 2 equipos, la pésima práctica un SM con 3 o más equipos, pues no alcanza a mejorar nada, solo corre de un lado para otro haciendo reuniones) 
    • se tienen Product Owners con 2 equipos (la verdad, debería ser a lo sumo uno solo, 2 es demasiado riesgoso, y le resta foco en el producto que construye) 
    • el SM solo se dedica a agendar reuniones 
    • cuando el PO no va a los eventos
    •  el PO no hace refinamiento y se convierte en un PO reactivo que solo trabaja para el siguiente sprint, debiendo estar avanzando en 2 a 3 sprints adelante
    • el SM no enseña Scrum al PO o al Equipo y como hacerlo cada vez mejor
    • el PO no se deja enseñar por el SM
    • cuando creemos que 5 sprints mejorarán técnicamente a un equipo de inexpertos (nunca pasará)
    • no hay retrospectivas, porque no agregan valor
    • las retrospectivas no abordan temas técnicos (clic aquí)
    • no hay dailys 
    • no hay planning, solo trabajo impuesto a realizar por el equipo de forma cíclica
    • tienes un equipo con varios proyectos (multitasking) y lo llamas equipo 
    • existen equipos que los llaman células y son unicelulares (equipos de una persona - OMG, lo he visto varias veces)
    • las pruebas son hechas por otro equipo diferente al que construye el producto, y en el sprint subsiguiente (casca-agile)
    • el equipo no es multidisciplinario 
    • el Product Backlog no está priorizado por valor 
    • existe un product Backlog con un solo release y un MVP, o sea, sino se sale a producción con todo el sistema o producto, este no sirve 
    • el PO no tiene autoridad sobre el producto 
    • el PO es el jefe del equipo y no se le puede dar feedback 
    • el SM es el jefe del equipo y no se le puede dar feedback 
    • dentro del equipo hay subequipos 
    • no existe incremento de valor potencialmente entregable al final de cada sprint
    • dentro del equipo hay rangos y jerarquías (cosa que va en contra de la guía de Scrum)
    • ni el SM, ni el PO, y el Team son orientados a resultados
    • el SM no reta al equipo, ni le ayuda en su proceso de mejora continua
    • no hay verdaderos profesionales haciendo parte del equipo Scrum
  • En la comunidad ágil
    • cuando los líderes de la propia comunidad lo atacan, en vez de avanzar de forma propositiva 
    • cuando las conferencias se quedan sin feedback, y la falta de validación de expertos hace que se acepte todo, que todo valga, pero la verdad no todo vale, y algunas conferencias terminan perdiendo valor. 
    • cuando dejamos que otros se hagan cargo, y solo caemos en el terreno de la crítica y no construimos responsablemente 
    • cuando no vemos en la crítica de los otros una oportunidad de mejora 
    • cuando dejamos que los líderes tóxicos prosperen y no compartimos los éxitos y las buenas prácticas
    • cuando criticamos los eventos y los speakers, pero no vamos, ni nos proponemos como speakers
    • cuando alguien que recibe un entrenamiento de 2 a 4 días es nombrado Master, Consultant, Coach y no hay validación de la práctica. 
    • cuando quienes toman los entrenamientos creen que pueden dictarlo al día después 
    • cuando como miembro un equipo ágil dejas de estudiar y aprender y buscar tu propia excelencia y reinvención.
    • cuando no te conectas con la comunidad
    • cuando es más importante la foto y llenar las redes sociales del entrenamiento, que la generacion de valor en el cliente y en el equipo
    • cuando nos atacamos en vez de construir 
  • cuando los que no entienden los marcos ágiles
    • los critican sin conocerlos o haberlos usado
    • cuando critican la forma (ej: los posit o dinámicas), pero no validan el fondo
    • juzgan por las fotos, pero realmente no saben toda la movilización y cambios que están ocurriendo al interior del equipo o de la organización
  • cuando los que creen entender los marcos ágiles
    • empapelan de posit a la organización pero no generan valor 
    • leen un libro o un post salen a vender entrenamientos sin entender, comprender y validar lo leído 
    • instalan Jira pero no generan valor
    • tienen un pipeline de DevOps pero el negocio no prioriza por valor, ni valida las hipótesis de los incrementos o releases que va lanzando al mercado, haciendo desperdicio ágil.
    • confunden felicidad con esoterismo o chamanismo 
    • confunden compromiso con explotación 
    • comparten información que no está respaldada por datos o experiencias (al menos propias)
    • ponen primero la felicidad que la generación de valor, el mensaje es diferente, los equipos felices o que tienen bienestar son más productivos.(https://hbr.org/2011/06/the-happiness-dividend) (aporte de Fabian Schwartz)
    • comparten jubilosamente fracasos ágiles, pero no comparten el contexto y se les olvida que en cascada el factor de falla es mucho más alto. Pero para ser claros, es muy probable que dentro de las causa raíz de esos fracasos se encuentren algunos de los elementos enunciados en este post.  
  • cuando cualquiera del ecosistema ágil, personas como usted o como yo, no elevamos o exigimos el estándar, no compartimos el riesgo o consecuencias de las malas implementaciones y somos complacientes con esas personas que desde su paradigma no lo entienden, o desde su esquema de poder no quieren que sea exitoso, y permitimos el FrAgile, Anti-frágil, FrÁgil, o Ágil Flácido.
Bien dice Sutherland, el peor enemigo de Scrum es un mal Scrum

Referencia (3)
parafraseánndolo un poco,




El peor enemigo de Ágil es un mal Ágil

o si lo desean

El peor enemigo de Agile es un mal Agile

o también

Agile's worst enemy is a bad Agile


Hagámonos cargo 

  • No llamemos Ágil a lo que no lo es.
  • No llamemos Scrum a lo que no lo es.
  • Exijamos excelencia técnica de los equipos de desarrollo (tanto internos como de proveedores)
  • Midamos y ataquemos la deuda técnica
  • Si vamos a criticar un marco o framework ágil, hagámoslo desde la experiencia o desde el minucioso estudio.
  • Valida lo que dice el autor, o entrenador que te acompaña, pídele datos y referencias.
  • En las redes sociales no promuevas gente tóxica, por la razón que: "de vez en cuando dice algo bueno", pues terminarás aprobando su discurso tóxico, poco constructivo y poco empoderado.
  • No confundas posición crítica, con una posición tóxica, la primera llama a la acción, la segunda destila veneno, señala lo malo y no propone acciones. 
  • Hazte acompañar de expertos.
  • Si vas a hacer Scrum al menos sigue la guía oficial de Scrum (el SBOK no es Scrum) 
  • No caigas en el "borregismo", es decir, seguir a alguien sin objetar lo que dice (como borregos, o un cardúmen), todos erramos y todos tenemos oportunidades de mejora 
  • Criticas porque otros critican, pero no compruebas nada de lo que afirman
  • No te quedes con lo que te dicen, investiga, valida, busca datos
  • Ten una actitud de continuo aprendizaje
  • No seas complaciente con el FrAgile, Anti-frágil, FrÁgil, o Ágil Flácido, identifica disfunciones, corrígelas y exígelas.

Hasta acá este desahogo o diatriba.

Vamos juntos, vamos por más.

Bienvenidos sus comentarios y observaciones.

Saludos ágiles


Jorge Abad

Aclaraciones, Comentarios, Referencias y Notas 


a la/s 3 comentarios:
Etiquetas: , , , , , , , ,

jueves, enero 16, 2020

Diatriba: "by the book" una frase que me produce escozor




Hola a todos

Como algunos de ustedes saben, la mayoría de post los escribo tienen como objeto de dejar registro de mis experiencias y luego remitir a mis compañeros, jefes, estudiantes, y amigos,  a mi blog con miras a hacer reutilización del conocimiento,  gastar menos energía y de paso hacer un aporte a la comunidad.

Hoy quiero desahogarme, hacer un poco de catarsis, respecto a esta frase "BY THE BOOK",que me he encontrado en varias latitudes en este ejercicio de acompañar equipos y organizaciones. Por lo general, sson variaciones de las frases que han antepuesto a "by de book", veamos:

  • tus scrum masters son "by the book"
  • los equipos de transformación de ustedes son"by the book"
  • lo que ustedes me estan proponiendo es"by the book"
  • ese aseguramiento o assessment es "by the book"
  • tus agile coaches son "by the book"
  • tus consultores son "by the book"
y en el sentido estricto de la palabra voy a indagar,  el comentario no tiene nada de constructivo ni realista, la mayoría de las veces:
  • su mensaje principal respecto a nostoros "no sabemos que estamos haciendo", o "sabemos muy poco" (ese mensaje por lo general lo da la competencia)
  • su intención de plano es destructiva
  • busca garantizar de que no se hagan cambios o el "statu quo" (sí, es sin la "s" al final de statu)
  • su intención en la mayoria de los casos es :
    • mostrar desconfianza, 
    • generar descofianza, 
    • destruir y desacreditar cualquier observación que se haga
    • atacarme o atacar a "mi gente" por parte de la competencia:
      • que no entiende el proceso 
      • o que si lo entiende pero no le conviene que se hagan observaciones sobre su trabajo

Hagamos precisiones

Respecto a “saber poco”: cuando esto ocurre, somos profesionales y se lo aclaramos al cliente y conjuntamente decidimos acoger el riesgo. En tecnología siempre hay conocimiento nuevo. Sin embargo, cuando se va a indagar o a validar algo relacionado con las prácticas ágiles que lleva un equipo interno o externo, cosa a todas luces necesaria pues siempre queremos saber qué tan “correcto” lo estamos haciendo, lo primero que se pregunta es:

¿qué marco de trabajo siguen?

o ¿qué marco le han dicho al cliente que siguen?

y desde esa luz que los equipos mismos dan, se comienza a identificar si realmente eso que dicen ejecutar lo están haciendo y en qué nivel de "shu-ha-ri"(ver imagen) se encuentran.


"
Un ejemplo del "ataque" que comunmente recibimos, son de las personas, equipos u organizaciones que hacen el "scrumbut"(3):
  • hacemos scrum pero no hacemos retrospectiva
  • hacemos scrum pero no tenemos definition of done
  • hacemos scrum pero no hacemos pruebas
  • hacemos scrum pero el sprint backlog no esta definido
  • hacemos scrum pero no hacemos planning
  • hacemos scrum pero no tenemos review
todos esos scrumbut, o scrum pero, realmente implica que NO se está haciendo haciendo scrum, con razon dice la frase, que aparece en la misma guía oficial:

"scrum es liviano, fácil de entender, dificil de dominar"(2)
para terminar los dejo con dos interesantes recursos:
  • la lista de chequeo de scrum elaborada por Henrik Kniberg (3) y traducida por migran amigo Lucho Salazar (4) (que justo comienza validando con lo esencial - validando si se está en nivel "ha" o "ri", que es entregar software de valor de manera frecuente y tener u proceso de mejora continua y luego se va a la validación de marco)

  • y la leyes de Compartamiento Organizacional de Larman(5) traducidas por Hiroshi Hiromoto(6)


1. Las organizaciones están implícitamente optimizadas para evitar el cambio del statu quo de las posiciones y estructuras de poder de los mandos medios y de primera línea y de “especialistas”.
2. Como corolario de (1), cualquier iniciativa de cambio será reducida a redefinir o sobrecargar la nueva terminología para que signifique básicamente lo mismo que el statu quo.
3. Como corolario de (1), cualquier iniciativa de cambio será ridiculizada como “purista”, “teórica”, “revolucionaria”, “religión”,"BY THE BOOK"(7), y “necesitada de una customización pragmática para preocupaciones locales” — que desvía de atender las debilidades y el statu quo del manager/especialista.
4. Como corolario de (1), si luego del cambiar el cambio algunos managers o especialistas son desplazados, ellos se convierten en “coaches/entrenadores” para el cambio, frecuentemente reforzando (2) y (3).
5. La cultura sigue a la estructura (Culture follows structure)


Por lo tanto, si eres cliente, o proveedor y alguien se te acerca con el 

"BY THE BOOK"

en su discurso, te sugiero revises:
  • si es un sesgo cognitivo (o prejuicio que llamábamos hace un tiempo)
  • realmente no se tiene conocimiento y es una primera aproximación (esto se resuelve validando experiencias previas en otras organizaciones y contextos)
  • realmente estan evaluando el nivel  "SHU" o aprendiz de algo o alguien, y lo primero que se valida es si sigue las reglas minimas
  • o es una maniobra de "alguien" para destruir la confianza en la estrategia o en una persona, equipo u empresa y salvar su propio pellejo.

Hasta aca esta diatriba, y desahogo

saludos ágiles
Jorge Abad

Notas, aclaraciones, comentarios

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

lunes, marzo 26, 2018

Un tweet de un grande - R.I.P. Mike Beedle - Ágil no Cura la Incompetencia

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

viernes, noviembre 03, 2017

Un Horrendo y Horroroso Scrum



Hola a todos

Reciente pasamos el Hallowen y quisiera compartir algo que me asusta de muchas implementaciones y adopciones de Scrum.

Comencemos

Durante mucho tiempo en mis entrenamientos de Fundamentos de Scrum comparto el siguiente texto de Tobias Mayer (https://agileanarchy.wordpress.com/scrum-a-new-way-of-thinking/) con los asistentes:



"Imaginen si nuestros días en el trabajo estuviesen llenos de sonrisas y sentimientos de compañerismo y llenos de emoción. Imaginen un espacio de trabajo que se remontan a patios de la infancia, donde la invención  y la innovación eran una parte natural de cada interacción. Imaginen que es responsable de su propio entorno, su propio ritmo y su propia carga de trabajo.  E imaginen entregar con frecuencia un trabajo de calidad con  a unos clientes encantados y relajados. Se puede convertir esa imaginación en realidad. Existe un mecanismo simple y bien entendido para ir desde donde estás ahora a donde le gustaría estar, y no, ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes." Tobias Mayer

Y la verdad cuando lo comenzamos a leerlo, todos creemos que vamos a terminar diciendo "sí, si es Scrum, es la bala de plata que siempre habías buscado y que va a solucionar todos tus problemas" y el texto termina muy clara y contundentemente "ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes."

Y somos nosotros y no el framework los encargados de cambiar nuestra forma de trabajo, el framework ayuda, pero podemos aún teniendo Scrum como forma de trabajo situaciones que dan espanto:
  • Product Owners o Scrum Masters que son los jefes de los equipos y los presionan y exprimen y los tratan como "recursos"
  • Scrum Master que solo se preocupan de agendar reuniones y no se ocupan de la mejora continua de su equipo, ni de su PO
  • Equipos en los que no se entienden (para ser sincero, realmente no son equipos)
  • Equipos con deuda técnica creciente y sin herramientas adecuadas
  • Equipos que no tienen buenas herramientas y no están orientados a la excelencia técnica
  • Equipos con muchos sprints encima y sin salir a producción
  • Equipos sin retrospectivas
  • Equipos con dailys de seguimiento estricto y no de sincronización
  • Equipos Scrum donde se gestionan las horas y las estimaciones y en los que "toca reponer el tiempo si se falla una estimación"
  • Equipos Scrum trabajando bajo un contrato de alcance fijo, tiempo fijo y costo fijo (todo fijo)
  • Metricas de cascada aplicadas a proyectos ágiles
  • Product Backlog al cual se le hacen frecuentes controles de cambio
  • Planning asignadas previamente por el PO (y posiblemente un líder técnico)  y no estimadas por el equipo
  • y muchas más
Lo anterior muy coincidente con la frase de Ken Schawber
“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura.(1) ” Ken Schawber




Da pavor ver estas situaciones, y es nuestra labor como Scrum Masters como Agile Coaches trabajar con la organización y los equipos para generar entornos de trabajo diferentes, y cierro como dice Tobias "ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes." 

Bienvenido el feedback, los comentarios y las historias de terror.


Saludos Ágiles

Jorge Abad

Notas

1. Creo que Ken hubiera querido terminar esta frase con una palabra más contundente

a la/s 1 comentario:
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: , , , , , , , , , ,

sábado, septiembre 05, 2015

Errores de "Lesa Agilidad"

Hola a todos

Les comparto unos tweets y pensamientos sobre como fallamos al agilismo #LesaAgilidad

un abrazo

--









a la/s No hay comentarios.:
Etiquetas: , , ,
Suscribirse a: Entradas (Atom)