Chess - antoniomartel.com

Archivos por Etiqueta: Ágil

Céntrate en lo importante. Es ahí donde se marca la diferencia

Nos pasa a todos en todas partes. Nos devanamos los sesos pensando en cada pequeño detalle y, mientras, las cosas quedan sin hacer. En nutrición se discute y se discute sobre si el brócoli tiene más antioxidantes que la lechuga o si las lentejas tienen o no más hierro que las espinacas, en lugar de dedicar nuestro tiempo y esfuerzos en tener una dieta rica y variada en general sin preocuparnos de que en ella esté el alimento perfecto.

Lo mismo pasaría a los estudiantes de alfarería que mencionaba hace algunas semanas en este blog. Pueden discutir y discutir durante semanas sobre cuál es la mejor técnica de todas para hacer el jarrón perfecto pero solo harán buenos jarrones cuando se hayan cansado de practicar haciendo un jarrón tras otro.

Me pasa a mí también, que puedo quedarme horas pensando si el post es lo suficientemente bueno o no o si ya he revisado bastante o aún quedan faltas de ortografía. Me pasaba también al publicar el libro. Pasaba mucho tiempo decidiendo si usaba esta portada o la otra, si incluyo este capítulo o no, si es mejor Arial que Times New Roman ¡Publica! Otros libros se están vendiendo mientras tanto.

La fuente de letras no va a conseguirme muchos lectores más y, en cuanto a la portada, realmente no sabía cuál de ellas iba a funcionar mejor. Sólo sé cuál de ellas me parece un poco más bonita que la otra. Nunca lo sabría hasta que no la expusiera al público, mientras, sólo voy a darle vueltas hasta auto-convencerme de que una opción es mejor que la otra y que no me voy a equivocar. Esto nos puede llevar a la parálisis del perfeccionismo y a un excesivo miedo a equivocarse.

¿Y en el software? Claro, también nos pasa. Horas y horas para decidir si usamos este patrón de diseño o el otro. Cada uno tendrá sus ventajas e inconvenientes. Una vez comparados los dos, apostamos por uno después de haber sopesado los pros y los contras y continuamos con el trabajo. Sólo después de unos meses sabremos si era la mejor solución o no (en realidad tampoco podremos estar seguros porque solemos tender a dar más peso a los aspectos negativos de las decisiones que tomamos en lugar de a los positivos).

Haz cien jarrones, corrige 100 bugs, escribe 100 clases, haz 100 entregas. Sólo eso te hará saber qué es lo mejor para el proyecto. Entrégalo y que los usuarios vean mediante su uso qué es lo más práctico.

De cada 100 clases habrán 5, 10 o 15 errores. Todos, sin excepciones, cometemos fallos, es inevitable pero de la tolerancia a errores y de la tranquilidad del equipo para probar lo que cree que es mejor o, como se diría en inglés, no need for C.Y.A, hablaremos en otro post.

Implementar Scrum y cómo sobrevivir para contarlo

Pocas cosas hay más de moda ahora en el mundo IT que Scrum y otras técnicas ágiles. Muchas empresas están adoptando Scrum en sus proyectos pero no todas tienen éxito. Muchas fallan miserablemente al primer intento y deciden no volver a probar. Comentan ‘Scrum no es para nosotros, ya lo intentamos y no sirve para nuestros proyectos‘ o ‘Al cliente no le gustó. Quería volver a sus diagramas de Gantt y sus entregas a final de año‘.

No suele ser debido a nuestro tipo de proyecto o lo especial de nuestros requerimientos. Tendemos a pensar que nuestros proyectos son muy particulares o más complejos que ningún otro pero la mayoría de nosotros no trabaja en proyectos tan poco comunes. Adoptar técnicas como Scrum no es fácil. Suponen un cambio importante en la forma de trabajar y cuando algunas cosas empiezan a no ir bien algunos señalarán con el dedo al Scrum Master y a esas técnicas raras que no les están llevando por buen camino.

Si aún así decides apostar por esta metodología y te planteas llevar tu próximo proyecto con Scrum aquí tienes algunos de los posibles problemas con los que te encontrarás:

Clientes: esto es una cosas de frikies

No todos tus clientes habrán oído hablar de estas técnicas ágiles y quizás no les importe demasiado la forma en que tú y tu equipo se organicen. Quieren los resultados por los que te han contratado y para ello supervisarán tu trabajo y te exigirán unas fechas y unos compromisos. No estaba en sus planes oírte hablar usando terminología rara.
En la reunión de arranque de uno de los primeros proyectos en los que empecé a utilizar Scrum quise explicar la metodología que íbamos a usar y cuál iba a ser nuestro funcionamiento. Comencé hablando de deliverables, sprints o scrum masters para continuar después con daily meetings y gráficas burndown. Pronto vi que me miraban atónitos así que me salté el resto de puntos pendientes y fui directamente a la conclusión. Nadie se dio cuenta ni hizo ninguna pregunta al respecto.
Desde entonces no entro en gran detalle sobre nuestros procedimientos y desde luego tampoco uso términos que puedan sonar raros a alguien que no conozca esta metodología. Para mi sorpresa algunos clientes terminan preguntándome un tiempo después cómo se llama esta forma de trabajar y adaptándose rápidamente a los tiempos de los sprints y los spikes.

Directores: Scrum es anarquía

La máxima preocupación del director de una compañía IT suele ser que desarrolles un buen producto pero que lo hagas dentro del plazo y presupuesto previsto. Si no puedes cumplirlo puedes dejar un enorme agujero en las cuentas de la empresa y encima puedes perder un posible cliente contento. Demasiado riesgo para dejarlo en manos de nuevas metodologías.
Puede sonar más tranquilizador oír hablar al jefe de proyecto de calendarios, seguimiento de costes y de ocupación en lugar de entregas frecuentes y software funcionando. No dudo que los primeros puntos sean también importantes pero sirven de poco si el cliente no tiene un software con el que pueda ir trabajando. El jefe de proyectos tendrá que ir haciendo malabares con su tiempo para entregar los informes de facturación, el registro de horas empleadas o hacer estimaciones pero, sobre todo, no debe olvidar que su principal trabajo es entregar software que funcione.
Pueden haber muchos otros inconvenientes a la hora de implantar Scrum en tus proyectos. Iré desgranando algunos de ellos en mis próximos posts. En cualquier caso, si no quieres esperar, puedes echarle un ojo a esta presentación en prezi en la que cuento Cómo sobrevivir a la adopción de Scrum. Espero que te guste.

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría

Construir lo correcto, construirlo correctamente o construirlo rápido

Siempre que desarrollamos un producto, nos demos cuenta o no, estamos haciendo un balance entre construir lo correcto (la funcionalidad exacta que necesita nuestro cliente), construirla correctamente (siguiendo la mejor arquitectura o los mejores estándares), o construirla de la forma más rápida posible.

Por supuesto, todos queremos estar en el punto del centro de la imagen y conseguir los tres aspectos al mismo pero es muy difícil lograr el equilibrio perfecto, cuando no imposible. A menudo debemos ir hacia uno de los lados de la figura para sacar la mejor versión de nuestro producto adelante.

Si nos movemos hacia el punto 1, en la intersección entre construir lo correcto y construirlo correctamente tendremos un producto perfecto con una arquitectura también perfecta pero podemos haber tardado demasiado en construirlo y no tenerlo disponible cuando el cliente la necesita o cuando el mercado lo demanda. Construir un Whatsapp con interfaz web puede estar muy bien justo ahora y hacerse muy popular y hacerse muy popular en poco tiempo pero podría ser demasiado tarde si lo entregamos dentro de un año.

En cambio, si tendemos hacia la intersección del punto 2, crearemos muy rápido el producto correcto partiendo quizás de un prototipo evolucionado pero que podría llevarnos a arrastrar una deuda técnica muy grande. Esta deuda técnica podría hacer que termine siendo inabordable cada vez que queramos construir nuevas cosas sobre una arquitectura base tan pobre.

En la tercera y última de las opciones podríamos construir muy rápidamente un vehículo con una bonita línea deportiva y un gran motor pero olvidamos construir lo correcto: nuestro cliente en realidad necesitaba un producto con algo de capacidad de carga para su trabajo diario.

Según sea nuestro papel en el proyecto todos tenemos cierto sesgo hacia alguno de los círculos. Los dueños del producto, es decir nuestros clientes, tienden a poner todo el foco en construir lo correcto. A su vez los miembros del equipo de desarrollo tienden en cambio hacia construir correctamente, centrándose en las cuestiones de diseño de la arquitectura y de la solución técnica. Por último el Scrum Master tiende habitualmente hacia construir el producto de la forma más rápida posible.

Ese es el papel que suelo tener yo, el de Scrum Master o jefe de proyectos, que solemos andar preocupados por el tiempo en el que vamos a entregar las cosas. En nuestro descargo debo decir que la velocidad es siempre un aspecto importante. Iterar y entregar nuevas funcionalidades más pronto nos va a permitir aprender antes qué es lo más importante a construir ahora y cómo construirlo técnicamente de la mejor forma posible.

Todo esto que comento aquí lo puedes encontrar de forma muy condensada en el vídeo sobre Product Ownership de Henrik Kniberg. No sólo habla de este dilema entre construir lo correcto, construirlo rápido o de la mejor forma posible sino de muchos otros aspectos relevantes para los dueños del producto y directores de proyecto en el cliente. Échale un vistazo, es muy bueno.

Los artistas de verdad entregan su trabajo (Real artists ship!)

A veces, y no pocas veces, retrasamos entregar nuestro trabajo porque creemos que todavía no está listo, que aún hay que mejorar o corregir cosas, que aún tenemos que seguir trabajando en él. En realidad suele ser miedo a fracasar, a que nuestro producto salga al mercado y que nadie lo compre porque no es perfecto o porque no da la talla. Puede ser también miedo a recibir críticas porque nuestro producto, nuestro libro, nuestro software tiene aún algún error gramatical o un pequeño bug: ‘Sólo publicaré la nueva entrada en el blog cuando nadie pueda ponerle ningún pero‘. Otras veces se trata simplemente de la parálisis del perfeccionismo.

Cierto profesor de alfarería en una escuela de arte dividió a sus alumnos en dos grupos y les dijo lo que tenían que hacer para obtener un 10 en su asignatura. Al primer grupo les dijo que tenían que hacer 100 jarrones para obtener la máxima calificación pero al segundo grupo les dijo que si querían obtener ese diez deberían hacer el mejor jarrón. Este último grupo dedicó todo el tiempo a teorizar y a leer sobre las mejores técnicas para hacer jarrones pero en realidad los mejores jarrones los hizo el primer grupo. Habían dedicado su tiempo a practicar y practicar haciendo 100 jarrones mejorando así su técnica. Lo mismo pasa con tu blog, con tu aplicación o con ese diseño al que llevas tiempo dándole vueltas. Deja que se encuentren con los verdaderos usuarios y que ellos den el visto bueno.

El mundo del software está llena de productos que se desarrollaron durante años hasta tener todas las funcionalidades que el cliente pudiera imaginar, diseñados tal como fueron concebidos por sus creadores. Lamentablemente cuando salieron al mercado éste tenía sus propias ideas y necesidades. Muy poca gente usaba todas las características de la aplicación. Otras en cambio eran muy demandadas pero nadie había pensado en ellas cuando se diseñó.

Ya se sabe, lo perfecto es enemigo de lo bueno. Cuando tengas un producto pequeño pero que ya puede ser útil, lánzalo al mercado (ship), exponlo al público, gánate tus primeros clientes. Ellos te dirán lo que echan en falta. Aprende de eso, lanza luego una segunda versión, luego una tercera. Si con la primera versión no consigues hacerte con una pequeña cartera de clientes, quizás no sea el momento o lugar para tu producto. Por lo menos aprenderás un montón de cosas que antes no sabías y no habrás perdido meses y meses de tu trabajo.

Más vale pedir perdón que pedir permiso

Cuando comencé mi primer trabajo el único consejo que me dio mi padre fue ‘No te pases el día preguntándole a tu jefe qué hago ahora. Echa un vistazo y tú mismo verás un montón de cosas por hacer‘. He intentado seguir este consejo en todos los trabajos que he tenido hasta ahora y quizás sea el que mejor me haya funcionado. Siempre es mejor contestar a tu jefe que ya has terminado lo que nos encargó y que has comenzado otra tarea que quedarnos esperando porque Pérez está de vacaciones o porque nadie nos dijo que podíamos comenzar ya.

En cada organización y en cada trabajo tenemos que tomar muchas pequeñas decisiones en las que otro tiene las competencias, ese otro es el que siempre ha hecho estas cosas o es el que más sabe del asunto. Pero ahora no está y tenemos que seguir trabajando. Podemos pasar a otra tarea pero pronto volveremos a toparnos con una decisión que nos impide seguir avanzando. Como resultado todo está comenzado y nada acabado. Volver a esas tareas pendientes unas horas, días o semanas después tiene un coste adicional que nos mantiene en nuestro pequeño caos diario.

Uno de los gurús en técnicas de gestión ágiles y el rediseño de organizaciones explicaba en una de sus charlas una analogía que muy bien puede servir para lo que quiero explicar en esta entrada: Si somos parte de un equipo de rugby y durante el juego la pelota pasa rodando delante de nosotros ¿vamos a pararnos y esperar a que el pateador (kicker) venga y le dé una patada hacia delante? Él es el que mejor golpea la pelota. Por supuesto que no, vamos a correr hacia ella a intentar darle la mejor patada que hayamos dado en nuestra vida. Por mal que lo hagamos la pelota siempre estará un poco más cerca del campo contrario.

Podemos pararnos a esperar a que el pateador patee, a que el diseñador diseñe, a que el de la ventanilla de al lado resuelva el problema o a que la señora de la limpieza quite la mancha del suelo. Hagámoslo nosotros mismos, resolvamos el asunto lo mejor que podamos. Los perfiles profesionales son cada vez más borrosos y todos debemos aprender a hacer de todo. Si lo hacemos así, las cosas empezarán a funcionar un poco más deprisa y, cuando menos, habremos adquirido algo más experiencia y un montón de puntos de vista diferentes.

¿Cómo saber cuándo es algo que podemos resolver nosotros mismos o realmente debemos esperar por alguien? Si cometemos un error y puede arreglarse con un simple ‘Lo siento, me equivoqué‘, no hay duda, adelante, hazlo. Es cierto que siempre hay un riesgo de meter la pata pero ¿qué ganamos cruzándonos de brazos?

Esta entrada apareció por primera vez en desencadenado.com como post invitado.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad