The GoodKnowmad conoce @PHPMx
Este es mi resumen del #meetup de hoy con el buen Israel López (@TheGoodKnowmad).
Waterfall es incremental, agile es incremental e iterativo
El que sea iterativo, significa que después de cada iteración se pueda deshacer trabajo o re hacer trabajo. Y esto creo que culturalmente o empresarialmente es algo que no es normalmente aceptado, porque queremos empezar a trabajar con todo completamente definido, queremos trabajar con todas las reglas de negocio documentadas, y cuando hay cambios en el proyecto sufren, pero piensan que agile es la solución, y no, la solución para ellos es Waterfall. Para ellos entonces Waterfall > Agile.
Agile es convertir tareas a DONE
Todos sabemos que DONE es verdecito, bueno eso nos ha enseñado Jira, y pues definitivamente cada equipo ha elegido que es lo que significa DONE, y lo hemos suavizado para sentirnos mejor, pero realmente DONE no es cumplir con el Acceptance Criteria del cliente/negocio, digo cliente/negocio, porque cliente es rol en agile, entonces a veces solo definimos el status DONE, para poder pasar la página, no para demostrar que realmente agregamos valor y resolvimos un problema del negocio.
MVP != entrega parcial
Minimum Viable Product (MVP) no es lo mismo que una entrega parcial, por más que nos hagamos brainwashing, no lo es, y entregar en sprints tampoco lo es. Las entregas parciales son algo que hacemos para poder ir avanzando y dar vuelta a la página, pero si no estamos entregando valor, no sirven, no son viables...
Requerimientos vs User Stories (historias de usuario)
Al querer todos trabajar en agile, porque es la moda, porque es lo que estudiamos, nos enfocamos en las User Stories, porque eso es lo que DEBE ser, pero las forzamos a ser realmente requerimientos, muchas veces desarrollados por equipos que no son de desarrollo, y que muchas veces, tampoco son ágiles porque se aprueban y no se deben de cambiar... vaya... completamente contra el Manifiesto, mejor digámosles requerimientos. Que no nos dé pena decir que hacemos Waterfall porque nos funciona.
Las estimaciones no deben ser para el tiempo, sino para predecir la capacidad
Híjole, esto es algo que yo subconsciente mente he hecho varias veces, y como decía Israel, puedes usar T-Shirt, Story points, lo que sea, pero estas estimaciones no son para estimar tiempos y ponerlos en un plan de trabajo, sino para poder saber la capacidad del equipo, y ver cuanto trabajo pueden entregar. Y no te deben de decir que ahora debes hacer más rápido lo que hiciste la vez pasada, porque no se trata de eso, se trata de siempre desarrollar con calidad. Aquí es otro ejemplo en donde no hacemos Agile, hacemos Waterfall, y esta bien admitirlo, no pasa nada.
No sabemos medir valor
Queremos medir valor, por índice de defectos, por cantidad de tareas en DONE, por cantidad de proyectos entregados en tiempo, eso no da valor al negocio, si todo eso no cumplió la necesidad del negocio, esas métricas no miden valor, no ayudan a mejorar el producto final, solo ayudan a entregar más rápido y mejor producto que no sirve.
Output != Outcome
Pareciera irónica que no lo consideremos constantemente, pero esto es muy similar al punto de arriba, nos enfocamos mucho en medir el Output, y no el Outcome, porque eso incluye meternos con el Acceptance Criteria, del negocio, quien muchas veces, según nosotros, no sabe lo que quiere, así que mejor no le hacemos caso, porque en IT somos superiores, si claro.
Excelencia técnica
ESTE ES EL OBJETIVO FINAL, la luz al final de camino, lo que te gradúa como equipo de alto desempeño, equipo de extrémame programming, equipo Agile Master... y esto es algo tan difícil de lograr, que mejor nos engañamos creando Agile Coaches que serán los que nos digan como trabajar, porque como equipo no pudimos seguir llegando a esto.
Claro llegar a eso NO ES FACIL.
Dejar que se auto organicen los equipos
Al final la respuesta, como cuando vas al psicólogo, esta en uno mismo, en este caso esta en el equipo que se re inventa, yo constantemente digo que los mejores líderes son los que constante se están re inventando y que siguen intentando mejorar, los que no aceptan el status quo. Si no tienes de esos líderes en tu equipo, difícilmente podrás aspirar a agile, y eso no lo va a solucionar un Agile Coach.
Customer collaboration...
En el flujo agile, el cliente esta ahi metido, metido en el equipo en la planeación definición, etc, no esta por fuera esperando que hayan entendido lo que pidió, y el cliente asume y entiende las consecuencias de las decisiones que se toman, así que no debería ser sorprenderle el resultado.
Estándares y no soluciones
Cuando queremos trabajar con equipos de arquitectura o externos, es mejor definir estándares que indiquen que son los lineamientos que deberá cumplir la solución, sin imponer la solución, porque sino no hacemos agile, sino hacemos otra cosa, cof cof waterfall.... o similar.
El problema no es la metodología son las personas
Porque bueno no es que haya una metodología buena o una mala, sino que si las personas no son las correctas, no habrá metodología que les haga trabajar correctamente, y la metodología debe de ir de acuerdo al tipo de personas, no busquemos implementar por implementar, y menos implementar porque es la moda.
...
No están ustedes para saberlo, pero no se como conocí a @TheGoodKnowmad en Twitter, en aquel tiempo tenia otro handle, que tampoco era su nombre... y se que en las redes sociales vivimos en "cámaras de eco", en donde buscamos aceptación a nuestros pensamientos, y es posible que todo lo que voy a escribir a continuación sea eso, pero pues es mi blog no?
En fin... no estoy aquí para contarles tampoco de la vez que regresando de una cena de negocios, algo happy, me atreví a enviarle un DM y nos montamos en un Skype, en donde le dije que había un wey en México que pensaba similar a él y que admiraba la forma en que decía las cosas sin tapujo, y que a mi me ayudaba el que siguiera predicando, que esperaba algún día poder hacer un entrenamiento presencial con él, y que si escribía un libro, o daba un curso, estaba yo seguro en que lo compraría, porque a través de 140 caracteres (ahora 280) era difícil poderle exprimir todo lo que yo quería saber. De eso ya ha pasado más de un año, y en el trabajo pasamos a otras prioridades y por una u otra razón no pude seguir persiguiendo eso.
Hace como 2 años que me integraron a la comunidad de PHP México que ha sido para mi un grupo de ayuda, un grupo en donde he encontrado más geeks como yo, y me han aceptado con todo y mis tamales de charales, y con mis cosas fifis, bueno así me dicen, de esto le agradezco mucho a Ricardo.
Y pues vi hace poco que @TheGoodKnowmad andaba participando en meetups en LATAM, y dije, (lease en acento español) coño, como yo no lo he hecho participar en un Meetup, de PHP Mexico o de Código Fuente, y pues la respuesta es que no sabia como venderlo... porque bueno, ustedes saben, el a veces en Twitter no es muy agradable, bueno yo tampoco, asi que, seguía con esa duda.
PERO me arme de valor, y al fin lo invité a dar un Meetup en PHP México, en donde bien buena onda, confiaron en mí y me dejaron poner el tema, el expositor, la hora y todo, y unos tipaz@s, me apoyaron en la transmisión y todo. MIL MIL GRACIAS.
Le eche los kilos al marketing... como no habiamos publicado nada... porque pues México, todo a la mera hora, y me apoye por primera vez mucho en mi networking, y les pedí RTs al evento, escribí a los directores de universidades locales, etc. para que al menos tuviéramos quorum, creo secretamente quería que todos escucharan a Israel (asi se llama @TheGoodKnowmad) y a lo mejor pudieran a través de eso conocerme un poco más.
Y pues para mí, este Meetup fue para la comunidad, pero más que nada fue para mí, porque yo, aprendí mucho.
Top comments (0)