Los profesionales tenemos la misma sensación… una metodología que los desarrolladores abrazamos cual tabla de salvación, se ha convertido en un dolor más a gestionar en tu día a día.
Un poco de historia
No hay mejor ejercicio para entender el presente y posible futuro como evaluar el pasado, vamos a ello.
A finales de los 90 y en muchas empresas hasta bien entrado 2010 (sobre todo en España), los proyectos se encaraban con una metodología llamada waterfall (en cascada), a grosso modo:
Lo primero: al cliente le dabas un presupuesto cerrado para hacer algo.
Después realizabas una fase completa de diseño funcional.
Con eso hacías un diseño técnico.
Para terminar pues ya te ponías implementar y eah ! todo listo
Esto lo defendían unos señores con traje y bien seriotes que decían que era como se tenían que llevar los proyectos, es más hasta sacaban “estimation tools” que no dejaban de ser una mierda de hoja excel llena de macros para sacar números como churros que después se traducían en mentiras gordísimas: presupuestos ajustados al céntimo, hechos a base de pedradas… esto daría para otro post “Estás muy guapo con traje y corbata, pero el conocimiento no viene con la ropa”
Si te paras a pensar… esto se hace en otras ramas técnicas con “éxito”, imagínate que vas a construir un edificio (dicho a lo burro… y pidiéndole disculpas a profesionales de otros gremios ):
Primero estimas cuánto puede salir, y tiras algo tipo estudio geodésico o lo que toque
Después diseñas los planos.
Te montas la estructura.
Te pones a hacer cada piso.
¿Por qué esto no funciona en software?
Primero, en otras áreas esto parece un proceso formal, pero después hay desviaciones fuertes tanto en tiempo como en coste (todos conocemos casos de famosos arquitectos que han hecho obras faraónicas con goteras o que incluso se vienen abajo).
Segundo, el software es “plastilina”, por ejemplo: cuando diseñas un ascensor, dices “máximo 6 personas o X kilos”, … no dices, vale voy a diseñar un ascensor para 1000 personas porque no sé qué va a pasar en el futuro, ni te planteas reemplazarlo. En software, tienes que tener en cuenta factores como:
Limitaciones de coste y tiempo, que hacen que no puedas ir en modo “no hemos reparado en gastos”
Cambios repentinos de guion, algo así como un “elige tu propia aventura”, pero el que “elige” es el que va a consumir el producto, no tú.
Después, cuando tu diseñas la distribución de un piso, la dejas tal cual, en software te encuentras que ni el cliente ni tú sabéis qué va a ser lo mejor y seguramente tengas que introducir cambios para que el sistema sea usable y útil. Es más, si comparas el plan inicial con el producto final, puedes decir eso de “cualquier parecido con la realidad es pura coincidencia”.
En casos como este, si vas a precio cerrado, acabas en un infierno de dimes y diretes que lo más viejos conoceréis: la típica pelea de “Es un change request o que no hemos entendido las especificaciones”, que se traduce a “lo paga el cliente” o “lo asumes tú”.
Aquí llegó la supuesta liberación, los señores serios de traje vieron como una serie de “Hippies” (bueno, en realidad, unas personas con bastante peso en la industria), vinieron a proponer una nueva forma de trabajar, con unos axiomas muy interesantes:
Abrazar el cambio en tu día a día.
Generar valor cuanto antes e ir refutando que vamos por el camino correcto (o al menos fallar pronto).
No tomar demasiado en serio las estimaciones, sobre todo en cuanto habláramos de más de dos semanas vista.
Involucrar a todas las partes interesadas desde el principio y durante el proceso.
Al principio los “señores seriotes de traje” miraban a los “hippies” con desdén, recuerdo frases lapidarias como “en la factoría sólo se pueden contemplar proyectos gestionados”, pero aún así, poco a poco se fue colando (aunque también habían casos de scrum falso: tiempo y precio cerrado pero alcance abierto).
Hoy en día esos señores de traje, te hablan de sprints, backlog, product owners, scrum másters…. Divertido ¿verdad?
Entonces… ¿Colorín colorado este cuento se ha acabado? Me temo que esto no se ha acabado y más que un cuento, podemos decir que se ha convertido en una pesadilla :).
Qué trae de bueno
Lo primero, reconozcamos que Scrum ha sido un cambio a mejor, de hecho ha traído un cambio de mentalidad importante, temas tales como:
Asumir que los requerimientos no están escritos en piedra, los proyectos están vivos y todo puede cambiar.
Pensar a corto y obtener feedback temprano (fallar pronto).
No tomar muy en serio las estimaciones.
Implicar a todas las partes que forman el proyecto (incluido el cliente) desde el minuto cero.
Reconocer que de ciertos temas no tienes ni idea y necesitas hacer una mierda prueba (en términos scrum se le llama spike y suena muy bien) :).
Y ¿Qué ha pasado?
Pues que al final detrás de todo proyecto hay cuatro factores muy importantes:
Personas.
Producto.
Tiempo.
Coste.
Si la personas que están involucradas en los equipos de ahora tienen la misma mentalidad que la de “los tíos de los trajes seriotes” volvemos a estar en las mismas.
Si el producto que se quiere hacer no tiene un plan realista… empieza el vale todo y vamos a engañarnos generando numeritos y gráficas.
Si el equipo se centra en cumplir a rajatabla un “supuesto manual de scrum(*)” y pierde visión en lo tangible, al final estás más tiempo preocupado en sacar gráficas en verde que en trabajar.
(*) Digo supuesto manual de scrum, porque muchos gurús comentan que la primera regla es personalizarlo según tu equipo y necesidades y que te agarres al código.
Y volvemos al equipo… Si no vamos todos a una, y cada uno se enroca en su rol, mal vamos.
Sonríe si…
Has vivido alguna de estas situaciones (y deja en un comentario de alguna más que hayas sufrido y que sea curiosa :D):
De 40 horas que tiene la semana, te pasas entre 10-20 de reuniones.
Con tanta reunión, es muy fácil a los 5 minutos desconectar, porque además intentas trabajar en mitad de ellas para “hacer algo”.
Por supuesto, eso de tener dos horas seguidas para enfocarte y trabajar, es misión imposible.
Los sprints arrancan muy exigentes, y cuando queda poco para su finalización las revisiones de código y estándares se relajan y “todo vale”.
El proyecto lo arrancas con el “login” (un clásico), y conforme avanza se empieza a ir más deprisa y a lo burro, sobre todo cuando te vas comiendo el tiempo y la pasta.
Nota: ver imagen em web original,
Lo importante es que saque la “gráfica en verde”, ya la demo… bah son 10 minutos.
Las reuniones de retrospectiva post sprint parecen el día de la marmota, cada X semanas salen los mismos problemas a flote y se proponen supuestas soluciones que son “la misma mierda con distinto olor”.
Los story points y demás sistemas acaban siendo la cuenta de la vieja, conforme te los dicen ya los conviertes en días o horas de esfuerzo, cambias el collar pero tienes el mismo perro.
El backlog sufre síndrome de diógenes… Hay un cementerio de tareas, que están mal paridas, desfasadas y duplicadas.
Las user stories las tienes de todos los colores, o bien son un título escrito en una servilleta de bar, o un troncho infumable, que se ha quedado desfasado y no aporta.
Te da la sensación de estar en una secta donde tienes ceremonias y a veces te da la impresión de que van a poner a un becerro en un altar y lo van a sacrificar.
Utilizan Jira o una herramienta similar, con: épicas, tareas, subtareas, spikes, enablers, definitions of done, done del padre del hijo y del espíritu… vamos que te da hasta miedo crear una o moverla de estado.
Se habla de principios “happy flower” como “qué todo el mundo sea capaz de tocar todo”, o “cualquiera va a tardar lo mismo en hacer una tarea”
Eso es que lo has implantado mal
Es un comentario muy común cuando un desarrollador empieza a quejarse de Scrum y, probablemente sea con razón… y aquí viene otro ciclo super divertido:
Como lo hemos implantado mal, vamos a formarnos en scrum… la cosa sigue sin funcionar.
Vale vamos a tomarlo en serio, nos certificamos… anda, sigue sin funcionar.
Vamos a buscar un perfil fuerte que nos forme en scrum… vaya esto sigue sin funcionar
Ok, ahora vamos a fichar a ese perfil fuerte y que nos haga coaching…
Sabes que… sigue sin funcionar ¿Pero qué carajo pasa? Pues puede que eso sea un problema de esta metodología, que en muchos casos acaba mal implantada por mucho que lo intentes
¿No será que el problema está en la organización y no en la metodología?
¿No será que hacer un proyecto de software es complejo?
Cómo hemos acabado
Hay casos en los que terminas mirando grafiquitas, rellenando check lists, haciendo terapias de grupo y demos de 10 minutos cada dos semanas… cuando ¡ ES EL PRODUCTO LO QUE CUENTA !
¿Qué podemos hacer?
Lo primero no perder el foco
¿Por qué estamos aquí? Porque tenemos que sacar un producto adelante y tenemos unas restricciones de calidad, coste y tiempo.
Partiendo de esta premisa, lo primero que tenemos que hacer es bajarnos a lo tangible:
¿Lo que se pide es realista?
¿Tenemos “pasta” para fichar un equipo que tire con lo que se quiere hacer?
¿El marco de tiempo tiene sentido?
El problema de esto es que el código que vas a generar cabe en un pendrive de 5€, y por otro lado hacer software es carísimo, si le dices a alguien que quieres un avión y tienes 2000 € de presupuesto, tú le contestarías: muy bien campeón, cómprate una moto y a correr, … en software es complicado saber de qué magnitudes estamos hablando.
Súmale que no es fácil montar un equipo de desarrollo que tire, además de las limitaciones de presupuesto, te puedes encontrar con que:
Tienes que saber evaluar sus capacidades técnicas.
Tienes que valorar que tengan los pies en el suelo: que por un lado no tiendan a “fumársela en pipa” y por otro no sean unos chapuzas.
Tienes que ver cómo encajan con los demás compañeros y que soft skills tienen.
Tienes que montar un equipo balanceado.
Y ya si hablamos de personas que están definiendo el producto:
Qué background tienen tanto técnico como de dominio.
Cómo se organizan y cómo gestionan la relación con cliente y equipo.
Ahora viene el momento de vale listo… y ¿Tú qué propones? Pues no es nada fácil, si una metodología tan estudiada como Scrum se implanta con fallos, seguramente lo que te vaya a comentar puede que te valga o no (depende de tu situación), pero aquí van una serie de cosas que he aprendido a base de pegarme tortas durante 26 años desarrollando software y trabajando en equipos.
Vamos al lío:
Lo primero, tener claro que gran parte del éxito de un proyecto está en contar con un buen equipo humano. Características que debemos buscar en esos compañeros que van a trabajar contigo:
Que piloten (al nivel que se les contrate) y si no (niveles juniors) que tengan capacidad de aprendizaje.
Que sean conscientes de sus limitaciones y sus responsables también.
Que estén dispuestos a ayudar y pedir ayuda cuando toque, a coordinarse, a crecer profesionalmente, a aceptar feedback, y no a colgarse medallas.
Que tengan claro lo que es entregar (delivery).
Qué levanten la mano si ven algún problema.
Que se empapen del dominio del producto.
Este principio lo aprendí del gran Bruno Capuano , de esta forma tienes medio proyecto ganado, esto es complicado y es donde yo diría que el 90% de las organizaciones fallan, lo normal que te encuentras cuando se arma un equipo es que:
La selección de personal se ha hecho con prisas y sin tener un buen proceso.
Existen Seniors con más ego que un influencer de fitness con abdominales marcados
Son perfiles estancos (no colaboran ni con su gato) y dados a las peleas y reinos de taifas.
No se propicia diálogo con los juniors, ni se detecta potencial. Un pequeño recordatorio: un junior es una inversión, no un veterano de la industria.
Otro tema muy importante es que las personas de tu equipo vayan creciendo y vayan trabajando de forma autónoma y con criterio (también con capacidad para avisar y preguntar cuando haga falta), esa inversión inicial es importante: es un gustazo cuando para coordinar un proyecto, te hace falta unos minutos de charla, saber que dejas las tareas en buenas manos, y lo que es mejor que van a tirar de ti en vez de tú tirar de ellos (el principio de David Bonilla Fuertes busca personas que te hagan push y no tengas tú qué hacerles pull).
¿Qué me dices de las áreas y roles? Vas a tener perfiles especializados y algunos cross, estos aportan porque tienen la solución completa en la cabeza, pero no esperes que todos sean así, ni que produzcan lo mismo en todas las áreas
Si no consigues montar un equipo óptimo (estamos en el mundo real), lo que hay que hacer es reconocerlo y tener un plan para mejorar la situación, así como rebajar expectativas.
Seguimos para bingo, es muy importante tener visión a largo plazo ¿A dónde queremos llegar? Y a corto ¿Qué tenemos que hacer ahora? Y que esto se comparta con todo el equipo, aquí viene una frase del gran Pablo Núñez Navarro que tengo grabada a fuego “El software en barrica de roble no mejora”: cuando en un proyecto plantean la primera puesta en producción a uno o dos años vista, hay mucho riesgo de que acabe comiéndose el presupuesto y se cancele, o que en la primera release acabe como en Zorba el griego cuando intentan poner en marcha su disparatado teleférico.
¿Qué hacer aquí? Salir a producción con entregas parciales que resuelvan un problema, ponerte metas en periodos de 3 a 6 meses:
Si el proyecto es nuevo, ve troceando y aportando valor.
Si es una migración, ve reemplazando piezas y haciendo migraciones parciales
Esto no es fácil y hay proyectos en los que no se puede hacer, pero si lo consigues estás dando valor a tus clientes desde casi el día cero.
¿Y si veo que no cumplo las metas? Plantéate recortar alcance (es decir la lista de lo que tenías pensado entregar), replantear lo que estás haciendo, estudiar qué está pasando o ampliar fecha.
Pero… así voy a ir más lento… bueno más bien vas a ir ya resolviendo problemas de tu cliente y aprendiendo de ello, además es mucho más fácil cancelar un proyecto cuando no hay nada que se esté usando en producción (el momento de … “pero esto qué mierda es, llevamos un año tirando el dinero aquí, esto no va ni para atrás, y tampoco es lo que nos hace falta, vamos a parar esta sangría”).
Otro tema delicado: complejidad, la justa, hay que evaluar muy bien lo que se va a hacer y cómo va a crecer y no “fumársela en pipa”, no te van a dar un premio por hacer la solución más elaborada con el patrón o framework de moda, lo que tienes q buscar es una solución en tiempo, coste y que resuelva los problemas q tiene el cliente y en la medida de lo posible dejarla abierta a mejoras y cambios.
Otro tema bien polémico es trabajar por sprints, se supone que así estableces un compromiso a corto, una meta clara, y entregas algo tangible, lo que me he encontrado en muchos proyectos, es que al final se acaba metiendo presión para sacar mierda:
Siempre pueden salir cosas que no esperabas cuando te pones a implementar, da igual la seniority que tengas.
¿Qué pasa cuando no se llega? Que se suele buscar entregar como sea (Sí, Scrum no dice eso, pero es lo que te sueles encontrar).
También pasa al contrario, se va en modo conservador y no se aprovecha ese tiempo, y parece que añadir tareas a un sprint te hace ser menos profesional (de nuevo… seguramente pensarás: Scrum no dice eso, pero pasa :)).
Yo creo que un equipo debe ser maduro: me gusta priorizar, y trabajar en modo kanban, es decir tengo una lista de tareas bien ordenadas y una meta clara a corto, pero puede pasar que algo que yo piense que igual lo tengo listo en tres días (o pon aquí tus story points, tallas de camiseta o calzoncillos), puede que me lleve 5 o más, y si se va de madre, lo detecto y decido cómo atacar ese problema.
Hablando de equipos, mejor un equipo pequeño, potente y bien cohesionado, que empezar a meter “carne” porque sí (como dice la ley de Brooks: 'Añadir más programadores a un proyecto retrasado solo lo retrasará más.')
Con los sprints, los story points, las velocidades del equipo, la serie de fibonacci… cometemos un error de bulto, estamos resolviendo un problema aplicando mates con números que son pedradas inexactas, os pongo un ejemplo: el otro día salió en un proyecto una integración con un tercero que iba a ser “directa”, la estimación… 1 día (o X story points :)), al final resultó en 4 semanas de trabajo ¿Cuántos decimales le añado al sprint?
Otro tema que SÍ importa es: quién va a hacer la tarea, a unos les tomará más tiempo y a otros menos (lo que no quita que aunque tarde más sea buena idea que la desarrolle por diferentes motivos)... “Más decimales” ;)
Y a colación de esto, viene otro punto muy importante, los checkpoints cada 2, 3 semanas, ¿Por qué no evaluar de manera continua? Y por supuesto, si hace falta hacer un parada para ver cómo mejorar, se hace. Es importante que el equipo llegue a tener ese grado de madurez, si no, al final acabas reventado a reuniones, … que al final te sirven para perder foco, no trabajar y frustrarte.
Abrimos nuevo melón, las reuniones:
Que sean las justas y necesarias: es decir las menos posibles pero que sean de utilidad.
Uno de los problemas de la metodología son las “ceremonias”, y que al final salen roles expertos en poner reuniones.
Sobre reuniones escribí otro turra-post hace un tiempo: “Otra reunión más ¿Y yo cuando trabajo?”
¿Quiere esto decir que no hay que hacer reuniones? NO, igual en ocasiones hay que estar todo el día “pringado”, pero que esté justificado: que los que asistan estén atentos, y esa reunión, si es de cierto impacto, tenga como entrada una agenda y una preparación, y como salida un resumen y puntos de acción.
A tener en cuenta la duración: no tiene porqué ser un slot de 60 minutos, si puedes cubrir lo mismo 30, 15, 5 minutos un correo o conversación de chat sin perder efectividad, mejor que mejor.
Si por lo que sea el proyecto entra en una etapa en la que necesita muchas reuniones, resérvate un día a la semana libre de ellas, eso lo llaman el día de “Get shit done” en Atlassian.
Seguimos para bingo :), acostumbra al equipo a trabajar en asíncrono: cada uno que tenga más de una tarea en “su plato”, así, si me atranco con una o la quiero arrancar con un compañero, en vez de quedarme de brazos cruzados o interrumpir a nadie en lo que esté haciendo, le hago ping para ver cuándo vendría bien poder sentarnos / conectarnos, y si tengo que esperar, salto mientras a la otra tarea.
De esta manera:
Dejo que mi compañero se gestione su tiempo de foco y tenga un tiempo de calidad con él
Yo sigo produciendo, y aportando valor mientras trabajo en otro caso.
Por supuesto que esta regla está para romperla cuando haga falta, en nuestro caso solemos usar mucho herramientas de chat o email, pero si surge un tema urgente se contacta por la vía que haga falta, lo bueno es que son ocasiones puntuales (de hecho si pasa a menudo, es un síntoma de que el proyecto se está yendo de madre).
También hay que propiciar que los integrantes del equipo de desarrollo se empapen de conocimiento del dominio, de UX, y los que están más en la parte de definición del producto de background técnico, esos puntos de conexión son muy importantes, y es un mal que tenemos en éste país, en muchas empresas si quieres ganar más dinero tienes que dejar de programar y pasarte 100% a trabajar con hojas Excel, documentos Word, portales de gestión de tareas… y en 2 años te encuentras desconectado de la parte técnica (esto daría para otro post… “Yo soy tu padre, Darth Excel”).
Bueno, pero ¿Qué haces cuando llegas a un equipo que tiene su forma de trabajar? Acepto sus reglas, me adapto y si valoran feedback o propuestas de mejora, las sugiero.
Vamos a cerrar hablando del backlog (la lista de “cosas por hacer”) mejor tener uno reducido, bien limpio, con buenas descripciones, diagramas etc… que el estercolero que te sueles encontrar a los pocos meses de empezar un proyecto, para eso hace falta dedicarle tiempo y contar al menos con una persona con visión del producto y roadmap (si es el equipo al completo mejor que mejor)
Sumario
Muchas veces nos escudamos en metodologías como si fueran mantras que nos llevaran mágicamente a completar un proyecto con éxito, cuando el quid de la cuestión está en contar con un equipo, maduro, que tenga claro en qué poner el foco, que aporte valor cuanto antes y se integre con el cliente desde el día cero.
Las metodologías son herramientas que tenemos que adaptar a nuestras necesidades, no religiones fundamentalistas que seguir con fe ciega.
Fuentes.
Artículo: "Scrum está roto" Publicado en https://www.linkedin.com/ por Braulio Diez Botella el 20 de mayo de 2024. Consultado el 07/07/2024.
No hay comentarios:
Publicar un comentario