Se hace camino al andar…

Experiencias de un informático vocacional buscando la calidad y sus efectos colaterales.

Posts Tagged scrum

eXtreme Coaching

Oct 11

Posted by jmbeas in Agile | 7 Comments

No, no se trata de este tipo de coaching…

La semana pasada estuve en Altea (Alicante) porque DreamStarCash me pidió que les diera un taller de TDD con PHP. Lo cierto es que yo no he programado nada serio en PHP y me parecía estar fuera de mi zona de confort, aunque estoy tan bien rodeado que así no es posible acomodarse. ¿Verdad Luis? ;)

Para poneros un poco en contexto, DreamStarCash es una muy exitosa compañía que desarrolla software de gestión de contenidos para adultos. Traducido al castellano (y simplificando): se dedican al porno. Pero ojo, no os quedéis en eso simplemente porque os estaréis perdiendo un mundo muy interesante desde el punto de vista del negocio del software. Tienen millones de visitas diarias, que además de mucho dinero (que tienen que repartir con los proveedores de contenidos, los estudios) significa que tienen problemas de escalabilidad, seguridad, trazabilidad legal de los contenidos, calidad de servicio… Es un negocio con mucha competencia y no toda cumpliendo con la legalidad. Rodney, su director de operaciones (COO) y Steve (CEO y fundador) son tipos muy inteligentes y quieren construir una organización capaz de aprovechar las oportunidades de negocio y adaptarse más rápidamente a todos los cambios que se producen en el sector (nuevas leyes, nuevas tecnologías, nuevos competidores…). Por eso se pusieron en contacto con Xavi Gost (beCodeMyFriend) y, a través de él, conmigo. Entre otras cosas, querían consejo para hacer posible este cambio en la organización. Están siempre contratando porque no cubren puestos sino que buscan talento (si estás interesado, habla directamente con Rodney), apuestan por el agilismo, la mejora continua y hasta han salido en el blog de 37signals. Por cierto, si vas a estar por la PHPConference en Barcelona aprovecha y salúdalos.

Bueno, el caso es que al llegar a DreamStarCash (tras un más que agradable chapuzón en la playa) me reuní con Steve (CEO y fundador), Rodney (COO) y Damian (CTO) para explicarles cómo iba a ser el taller y charlar un rato sobre cómo trabajaban ellos normalmente. Fue una conversación muy honesta y eso siempre es de agradecer. Me gusta muchísimo el ambiente de startup (aunque ya no se puede decir que DreamStarCash lo sean) porque tienen esa esencia de “garaje”, de reducción de jerarquías, de buen rollo… vamos, de todo lo contrario al ambiente “enterprise”. En estas empresas puedes meter el cuchillo hasta el corazón porque sabes que tienes muchas probabilidades de ayudar realmente, en cambio, en las grandes corporaciones, la energía se disuelve entre las “politics” y los miedos al cambio.

De resultas de esta charla nos dimos cuenta de que lo que realmente necesitaban (y con urgencia) no era tanto un taller de TDD sino un cambio en su cultura. Ellos ya habían asistido a un curso de certificación en Scrum impartido por Tobias Mayer hace varios años. Con el devenir del tiempo y la búsqueda de la eficiciencia se encontraban en un escenario desgraciadamente muy habitual: una gran deuda técnica y defectos acumulados en su software y una cultura incapaz de buscar la mejora continua. Se estaban arrinconando en el típico enfrentamiento: ellos vs nosotros. “El equipo no se implica con los objetivos” o “los requisitos no son suficientemente detallados”. Y para colmo no hacían retrospectivas regulares ni la mayoría de los rituales de Scrum. Ni tan siquiera estaban haciendo Scrum en apariencia. Estaban haciendo “Scrum In Name Only” ( gratias). :)

Estuvimos dándole vueltas a la posibilidad de cambiar de planes y hacer algo diferente. Realmente los managers se habían dado cuenta de que, efectivamente, tenían un problema muy serio en la cultura de la empresa en cuanto al desarrollo del software se refería y que tenían que hacer algo. Tras una brevísima retrospectiva, propusimos al equipo hacer durante la semana un proyecto muy pequeño pero haciendo Scrum con iteraciones de 1 día. SÍ, DE UN DÍA. En realidad apenas nos daba tiempo a hacer una preparación del backlog y 3 iteraciones, pero al estresar tanto el proceso yo quería provocar que aquellos “bad ticks” que tenían afloraran con más rapidez y fuerza que en un coaching más “relajado”. Por otro lado, los ciclos de feedback iban a ser mucho más frecuentes, lo cuál nos daría muchas más oportunidades para ver qué pasa en un proyecto normal y cómo reaccionar ante ellos.

Ha sido una de las mejores experiencias de mi vida profesional. Realmente espectacular ver cómo reaccionan las personas ante este tipo de retos. Al final de la semana les di muchísima caña. Los “golpes en las rodillas” (figurado) fueron muchos y algunos seguramente no cayeron demasiado bien. Pero hubo para todos: para el equipo de desarrollo y también para los managers. (Incluso para Steve) :) Pero cuando las personas son autoexigentes valoran mucho la honestidad. En la retrospectiva final había muchas más opiniones positivas que negativas. Y las negativas estaban identificadas claramente como aspectos que querían mejorar. Ése es justamente el espíritu que trato de transmitir, y ellos lo habían entendido perfectamente. Estoy deseando poder anunciar el resultado de este pequeño proyecto, donde el equipo aprendió a escribir su backlog, historias de usuario, orientarse a construir producto incrementalmente, manejar las tareas y los conflictos durante el sprint, planificar junto al dueño de producto, decidir acciones tras las retrospectivas… vamos, a hacer agilismo del bueno. Claro, como podréis suponer, será [Adults only].

Tags: , ,

Medir o no medir, ésa es la cuestión

Jul 17

Posted by jmbeas in Agile | 6 Comments

En estos días estoy en un proyecto muy bonito ayudándoles a desarrollarlo con un enfoque ágil que luego puedan asumir como propio en otros proyectos. Es tan bonito que el nombre que hemos dado al proyecto de coaching es “Proyecto Bonito”. Un equipo como éste es toda una garantía de éxito: motivado, autoexigente, con muchas ganas de aprender y hacer las cosas mejor (ya las hacían bien, pero quieren hacerlas aún mejor). Este proyecto es tan bonito que incluso tenemos dueño de producto (dos: a falta de uno, dos). Son proxies del cliente, pero está plenamente justificado porque nuestro cliente está a muchos miles de kilómetros de distancia. Y está justificado el tener más de uno por eso de tener un respaldo durante las vacaciones… Yo, además, contento porque así es mucho más rico el backlog grooming que vamos haciendo. :-)

Hay retos, claro, si no no sería tan bonito… Tenemos que lidiar con la dispersión geográfica de sus miembros, con las dichosas vacaciones (¡quién las habrá inventado! :-P ) e incluso con retos técnicos como el uso de ExtJS. No son grandes retos, pero suficientes para sacar buenas conclusiones y no poner en riesgo ninguno de los objetivos, tanto el económico de tener éxito con el proyecto para nuestro cliente como el interno de interiorizar buenas prácticas ágiles y, además, tener cierto margen para ir obteniendo artefactos de arquitectura que luego puedan quedarse en la casa para abordar otros proyectos.

Pues bien, en este contexto nos van saliendo conversaciones interesantes que voy a intentar ir sacando en este blog poco a poco en la medida que pueda garantizar la debida confidencialidad. La primera de ellas que me gustaría sacar tiene que ver con la estimación de tareas.

Antes que nada:

¿Para qué estimamos las historias de usuario?

Yo no sé vosotros, pero a mi me gusta saber si el proyecto que tengo entre manos va bien, va mal, le queda mucho para acabar, seré capaz de entregar tal o cuál funcionalidad el mes que viene o dentro de tres meses… será mi pasado oscuro como jefe de proyecto o que es una pregunta muy normal cuando es tu responsabilidad manejar un presupuesto. Así que yo estimo historias y trato de responder a esas preguntas con un “si seguimos a este ritmo parece que sí” o “para ser posible tiene pinta de que tendríamos que hacer algo”. Otro día hablamos sobre cómo ayudo a responder a estas preguntas… :-)

Pues bien, en la primera reunión de planificación surgió lo típico: estimar en horas las tareas.

Y llegamos a la siguiente pregunta (a la que yo realmente quería llegar hoy):

¿Para qué estimamos las tareas?

A mi, personalmente, lo que realmente me interesa es tener un medio de provocar conversaciones que nos permitan reducir las diferencias de expectativas e ideas preconcebidas entre los diferentes miembros del equipo y el dueño del producto a la hora de abordar la historia de usuario en su conjunto y cada una de las tareas en particular. Y consigo este efecto pidiendo que se estimen las tareas… y cuidando de facilitar esas conversaciones, por supuesto.

Así que, al final, yo llego a la conclusión de que no es relevante si la estimación la hacemos en horas, en puntos o en lo que sea. Lo relevante es que salgamos todos alineados y con una conversación lo más rica posible alrededor de cada historia de usuario en el tablón.

LA FOTO: Un guiño a los seguidores de Dr. Who. Ayer vi dos episodios seguidos con niño1 y he terminado hablando con él sobre el continuo espacio-tiempo. :)

Tags: , ,

Nueva vida: días 3 y 4

Oct 1

Posted by jmbeas in Nueva Vida | 9 Comments

Buff, 4 días y ya tengo troll y todo. :)

Bueno, al lío. Tengo la garganta hecha polvo por la sequedad del ambiente. Tengo que hidratarme más. Además, estoy pillando un catarro o algo así. No estoy haciendo pomodoros y eso se nota en mi productividad: mucho. No encuentro tiempo ni para tuitear.

Finalmente me decidí por hacer scrum con todos. Enrique Comba me advirtió del peligro de que un equipo se viera ninguneado por el jefe de proyecto. Hacer que los dos hicieran scrum por separado iba a ser peor aún porque hay demasiadas interdependencias entre ellos. Es mejor buscar la colaboración dentro del equipo: un producto en común, un objetivo en común. Va a ser complicado porque somos muchos. Ya hemos hecho una reunión diaria y ha durado más de media hora. Demasiado. No quiero ser autoindulgente. Sé que es la primera pero tenemos que mejorar esto.

Mi tablón es, provisionalmente, un papel de embalaje en la pared de un despacho. No está a la vista de todo el equipo y fácilmente accesible. Pero bueno. Así tampoco se ven las cosas que estoy haciendo mal. Ooops! Me falta por hacer el “product backlog”. No tengo perdón, pero es lo que hay. Soy consciente de que debo hacerlo lo antes posible. Es mi gran objetivo para mañana. SIN FALTA.

Estoy intentando que el equipo se enfoque en poner en producción cuanto antes y en la reunión de planificación (me resisto a llamarle sprint planning porque no he hablado aún de sprint) salieron muchas tareas y casi no tuve que manipular para que la gente se autoasignara. Tampoco estimamos. No me pareció útil porque necesito ganarme su confianza y permitirles que ellos mismos ganen en autoconfianza. No quise liarles en aquel momento con estimaciones; me pareció mejor simplemente pedirles que se pusieran a trabajar y que tardaran lo que fuera necesario para conseguir el objetivo. La reacción ha sido extraordinaria. A continuación en incluso al día siguiente  por la mañana me encontré a prácticamente todo el equipo totalmente enchufado. Un cambio brutal en comparación con los días anteriores en los que, en vez de trabajar, estaban cuchicheando entre ellos acerca de correos y comentarios que ponían en entredicho su profesionalidad.

Ya tenemos Hudson funcionando y desplegando automáticamente en dos entornos gracias a uno de los miembros del equipo más quemados. Me alegra mucho que esté recuperando la ilusión por venir a trabajar. Mañana por la mañana tenemos que afinarlo y ponerme al corriente. He delegado esto pero es demasiado importante como para no saber los detalles sobre cómo ha quedado.

Nuestro maestro en ecosistemas, Guido, ha instalado incluso Sonar. Tengo miedo a mirar los informes. De momento tenemos tests de un proyecto anterior que se han dejado ahí después de un copipega que se hizo al principio. Lógicamente fallan todos. Hay mucho que limpiar. Pero no ahora mismo. El objetivo es poner en producción lo antes posible y liberar presión que hay sobre mucha gente (a todos los niveles). ¿Será el lunes? Tengo poco tiempo para decidir porque hay que pedir a QA (no es un departamento sino unos usuarios del cliente) que nos validen lo que puede pasar a producción y reservar la ventana de cambio para hacer el paso a producción.

Aún no tengo ni idea de en qué consisten todas las funcionalidades que se esperan que estén listas para el día 20. Cuando veo el Mantis y reviso las incidencias que hay allí me suena a chino (bueno, a italiano porque tenemos el italispanglish como lingua franca). Afortunadamente el equipo es consciente de que ahí me tienen que ayudar y se están portando genial conmigo. De hecho, he manipulado un poco para que surgiera el tema en la primera reunión diaria. Creo que ha ayudado a rebajar algunas preocupaciones y a demostrar que el estilo de dirección es sensiblemente diferente.

Todos los días tenemos muchas interrupciones debidas a incidencias o tareas que vienen directamente de la aplicación en PRODUCCIÓN. Es muy difícil manerjar esto si encima no tienes criterio suficiente siquiera para ver si son urgentes o no. De nuevo, el equipo se está encargando de esto. Se autoorganizan. Pero voy a tener que darle la razón a mi jefa de que vamos a tener que destinar a dos o tres personas para este tipo de actuaciones manuales. Ya lo hemos visto hoy en la primera reunión diaria. Mañana lo afinaremos, pero la idea es que estas personas estén todo el tiempo trabajando entareas muy manuales y laboriosas (más propias de un operador que de un programador) pero que nos va a permitir por un lado proteger al resto del equipo de muchas interrupciones y por otro lado identificar tareas que se pueden automatizar y, potencialmente, incluso ir automatizándolas.

Mañana hablaremos tras la reunión diaria de vacaciones y de autoorganización. Difícil y sensible tema. Pero la realidad es que a base de no conceder vacaciones al equipo ahora tengo menos disponibilidad. ¿Cómo llamamos a eso? ¿Deuda de gestión?

Mañana por la noche tengo una cena con gente superinteresante. Voy a poder escuchar a Luismi Cavallé intercambiando opiniones e ideas sobre la artesanía del software con Enrique Comba y Xavi Gost. Y además Alejandro Pérez y Roberto Canales no tendrán, como otras veces, que pagar la cena. :)

Ahora. A dormir. Que hay que conseguir un ritmo sostenible. ;)

Tags: , , , , , ,

Nueva vida: día 2

Sep 28

Posted by jmbeas in Nueva Vida | 9 Comments

Buff, el segundo día ha empezado cargado de tensión. La jefa ha llegado de Milán con muchas noticias. Algunas son buenas, como que el cliente, que anda algo más que mosqueado con la falta de calidad de lo que se le está entregando, ha aceptado postergar algo más de una semana una puesta en producción que estaba prevista para dentro de dos.

También ha traído una lista de cambios. Si yo fuera un güaterfolista, estaría como ella, fastidiado porque “he tenido que ceder”. Pero como soy un agilista, estoy igual o incluso contento. El cliente ha pedido que se resuelvan defectos graves que incluso están en producción. Ya sé… eso no es para estar contento… claro. Pero el cliente, sin saberlo, está ayudando al equipo a enfocarse. Está haciendo mi trabajo. Un trabajo que, lógicamente, como llevo apenas dos días, no puedo hacer porque no tengo apenas criterio.

Me he traído a casa dos o tres documentos con incidencias, peticiones de cambio y listas de los Reyes Magos, que me van a permitir llevar mañana un medio backlog. Tengo mucho trabajo. Buenas noches. :)

Quiero plantear desde ya que los lunes vamos a hacer un pase a producción y todos los días al entorno de demo. El cliente está muy mosqueado. Y el cliente del cliente ni te cuento. Así que cuanto antes vean que las cosas se mueven, mejor.

Idem para el equipo. Quiero que vean avance desde YA. El mayor inconveniente es que tengo dos equipos en uno. Un equipo para el front-end y otro para el back-end. Ya he vivido esto, pero nunca en estas condiciones de falta de comunicación. El equipo del front-end (javeros), está fastidiado porque es el que se lleva las bofetadas: es lo que está más cerca del cliente. El equipo del back-end tiene un líder técnico muy fuerte, que actúa como cuello de botella en muchas tareas y que, para colmo, me parece reacio a aceptar cambios. Me estoy pensando muy seriamente si hacer scrum con todo el equipo: back-end y front-end. Lo más seguro es que haga scrum con el equipo de desarrollo del front-end y trate al equipo del back-end separadamente (sin scrum formalmente, sino “sufriendo” que “los javeros” van a ser más exigentes en cuanto a tiempos de respuesta e interacción de lo que han sido hasta ahora).

Por cierto, hoy he charlado con Nacho González, el CTO de Kotasoft, y me ha comentado que un tal Joaquín Engelmo se unía al barco en Cáceres. ¿De qué me sonará ese nombre? ;-)

Me voy a tomar algo calentito para cuidar la garganta. No sé qué tienen los que diseñan los espacios de trabajo para desarrolladores que los hacen siempre tan insalubres: sin ventilación, sin espacio físico -es difícil trabajar en pareja sin molestar a tu vecino-, un calor sofocante, pésima iluminación…  :(

Bueno, que no me quiero autodesmoralizar. :-D

Tags: , ,

Jugar a mejorar

Sep 28

Posted by jmbeas in Agile, Del viejo blog | 4 Comments

Estaba leyendo un artículo publicado por Xavi Albaladejo en su ProyectosAgiles.org sobre un juego de simulación para enseñar Scrum y me ha venido la idea de hacer un pequeño recopilatorio de artículos que he ido leyendo en los últimos meses y que puede servir para aquellos que queráis venir al Agile Open Spain 2009 con algo visto y, quién sabe, con algo incluso probado.

Empezaré por recomendar una introducción de Scrum en 10 minutos (realmente 7:59). Lo siento, está en inglés, pero merece la pena. Sería genial que algún voluntario le pusiera subtítulos en español, ¿verdad? ;-)

Lógicamente, luego os recomendaría leer la explicación un poco más extensa que hace Xavi en ProyectosAgiles.org. Simplemente pulsad en la pestaña “Qué es Scrum”, pero no os quedéis en leer sólo esa página, profundizad en los hipervínculos a medida que vayáis aumentando vuestro interés. Merece la pena.

Si os ha picado la curiosidad, hace unos meses Xavi Albaladejo, Xavier Quesada y un servidor grabamos un podcast para JavaHispano, donde no hablamos exactamente de Scrum, pero sí hacemos un repaso bastante completo a los fundamentos ágiles en general, que lógicamente son compartidos por Scrum. Creo que merece la pena también, modestia aparte, que echéis un vistazo a la presentación que hice no hace mucho titulada “Los principios ágiles” y que hace un recorrido del Manifiesto Ágil y sus Principios. He adjuntado también mis notas porque sin ellas os podéis quedar un poco perplejos.

Radiadores de información

La vida de un equipo que hace Scrum está muy vinculada al tablón donde se publica la información que produce el propio equipo de manera completamente transparente, entre otras cosas para evitar interferencias por parte de los gestores con la típica preguntita impertinente “¡Qué, chaval! ¿Cómo lo llevas?” (que en realidad quiere decir “¿te falta mucho para acabar?”). Por eso os recomendaría también visitar el blog titulado “Visual Management” (desgraciadamente en inglés) donde Xavier Quesada nos enseña cómo mejorar la gestión del proyecto mediante un mejor uso de los elementos visuales que empleamos para “radiar la información” (es decir, las pizarras, los post-its, etc) y nuestra relación con ellos. Por ejemplo, podemos elegir un tipo de rotulador u otro para escribir en nuestros post-its. Si escribimos con un “boli medio gastado” y con una letra garabateada, estaremos disminuyendo la eficacia de nuestro tablón. Estoy seguro de que si muchos le pedís a Xavier que traduzca su blog, él estará encantado. No en vano es el primer CSC (Certified Scrum Coach) de habla hispana.

Pero si nos quedamos sólo con el tablón, los post-its, las pizarras y las reuniones diarias, probablemente nos estaremos quedando en la parte más cercana al folklore.

Historias de usuario

El trabajo en Scrum se reparte en forma de historias de usuario, que se estiman y priorizan para formar parte de una pila de producto (o “product backlog” en inglés). La mejor referencia para este tema es, sin duda, esta presentación de Mike Cohn, aunque preferiría que os leyérais su libro “User Stories Applied” porque es excelente (y cortito). En cualquier caso, creo que también os podría valer este artículo en español del compañero de Viçenc García.

A mi, todo este tema de las historias de usuario me parece básico, porque si no escribimos bien lo que queremos hacer, ¿cómo vamos a poder hacerlo después? Por eso me interesa tanto todo lo relacionado con las pruebas de aceptación, que algunos preferimos llamar “especificaciones ejecutables” para hacer más énfasis en el hecho de que se escriben antes y no después de la construcción del software. Pero esto ya quedaría fuera de lo que es Scrum (estrictamente hablando).

Si ya habéis llegado hasta aquí, creo que estaréis en la mejor de las disposiciones para aprovechar al máximo el curso gratuito de “Introducción a Scrum” que ofrecieron hace ya unos meses Agustín Yagüe y Juan Gutiérrez en las instalaciones que Autentia nos prestó.

Literatura (en español)

Libros sobre Scrum (y agilismo en general) hay muchos, pero en español hay muchos menos. Yo me atrevo a recomendaros la lectura de dos (elegid vosotros mismos):

Formación

Y si queréis más, podéis ir echando un vistazo al calendario de cursos de Scrum que desde Agile Spain tratamos de mantener actualizado. Si quieres ofrecerte como voluntario para ser tú el que lo mantenga actualizado… no tienes más que ofrecerte. :-) O mejor aún, puedes intentar arrancar un grupo local de Agile Spain. Hay uno en Barcelona y otro en Madrid. Para esto no tienes más que buscarte un lugar donde hacer la primera reunión (tu oficina, la oficina de un amigo, un bar, una escuela… cualquier sitio es bueno para empezar) y avisar por todos los medios que se te ocurran (tienes la lista de correo de Agile Spain a tu entera disposición y a todos nosotros para echarte una mano). Lo demás depende de lo que se os vaya ocurriendo y las ganas que tengáis.

<publicidad>
Yo estoy estudiando seriamente dedicarme a dar formación y coaching ágil en breve, aunque tengo cierto reparo al leer comentarios en contra de los que desgastan el término ágil para su aprovechamiento mercantil. Sea como sea, si alguien está interesado, que se ponga en contacto conmigo y quizás sirva para decidirme definitivamente.
</publicidad>

Por supuesto, tenéis las listas de Agile Spain (la comunidad ágil española) y Ágiles (la comunidad ágil latinoamericana) para cualquier duda o sugerencia que se os ocurra.

Corolario

En cualquier caso, implementar Scrum no os va a garantizar nada más que, si tenéis éxito o fracaso, lo sabréis cuanto antes. Pero no va a reemplazar el que tengáis que tener unas buenas prácticas de ingeniería y una actitud profesional frente al trabajo. Si tenéis inútiles y vagos en vuestros equipos, Scrum sólo os ayudará a identificar que tenéis este problema (ni siquiera os permitirá identificar quién es el más inutil y vago del equipo). Eso sí, si conseguís armar un equipo con ganas de mejorar y capaces de adoptar una alta dosis de autodisciplina, con un poco de paciencia veréis que podréis ir mejorando en las prácticas de ingeniería y, finalmente, consiguiendo éxitos para vuestros clientes, es decir, también para vosotros. Citando a  Alfredo Casado en un hilo de la lista de Agile Spain: “sin excelencia técnica no hay agilismo, sólo post-it pegados por las paredes”.

Como habréis podido comprobar, la mayoría de los recursos que he ido citando en este resumen tiene un cierto tono informal. Incluso los cursos y talleres incluyen juegos (como el que me servía de excusa para arrancar el artículo). Y no es casualidad. Desde el primer momento el agilismo ha estado relacionado con la idea de cambiar la forma de ver el lugar de trabajo como un sitio donde se va a sufrir por otro donde, a cambio de hacernos responsables de nuestro trabajo, nos lo podemos pasar bien.

Nos vemos en el Agile Open Spain 2009. No olvides tu cámara. ;-)

[La foto es una reliquia familiar (aclaro que de alguien que yo no conozco en absoluto) y representa a un grupo de chavales jugando a la pelota. Me pareció que destilaba una cierta ternura y por eso la elegí.]

http://jmbeas.blogspot.com

Tags: , , , ,

Cuidado, soy un tipo peligroso

Sep 28

Posted by jmbeas in Agile, Del viejo blog, Profesión | Comments off

Mientras estoy terminando el artículo sobre Scrum que dentro de un ratito publicaré, me he topado, gracias a un amigo en twitter, con este otro artículo que, por una parte me ha parecido muy acertado, sobre todo recordando que los métodos ágiles no son balas de plata, es decir, que no siempre son la mejor solución. Pero por otra parte me ha hecho plantearme si es correcta la imagen que transmito de mí mismo al declararme “evangelizador agilista” (“agile evangelist” si echáis un vistazo a mi perfil en LinkedIn).

Después de pensarlo bien y echar mano de mi ejemplar de “Fearless Change”, he llegado a la conclusión de que sí, de que es correcta. Es más, es la que quiero tener en este momento. Porque tengo una pasión y me gustaría poder transmitirla. Esta pasión es el desarrollo de software.

He descubierto que hay formas mejores de desarrollar software y me gustaría que fueran las que se usaran mayoritariamente en las empresas de desarrollo de software de nuestro país. No quiero parecer un “talibán”, alguien que dogmáticamente, sin reflexión alguna, trata de imponer su criterio a todos los demás. Por eso no me autodenomino “Emperador de lo ágil” ni nada por el estilo. Y es que no creo que tener una pasión sea malo, ni tratar de que los demás compartan tu pasión (sin imponerla ni ponerse muy “pesao”) sea malo. Así que creo que, aunque es cierto que hay que empezar a tener cuidado con los que recién llegan a aprovecharse de la marca “agile” y de los que quizás han creado marcas a partir de estos conceptos para “monetizarlos”, también creo que no debemos descartar directamente a aquellos que te tratan de mostrar su pasión simplemente porque se ha convertido en una “buzzword”.

Bueno, lo dejo que no me quiero poner “pesao”. :-)

[La foto es una obra de Warhol que está expuesta en el MOMA de Nueva York y que representa una infinidad de latas de sopa de una misma marca, con lo que no es fácil distinguir una sopa de otra. ¿Moraleja o simplemente arte?]

http://jmbeas.blogspot.com

Tags: , ,

Productividad vs agilismo

May 20

Posted by jmbeas in Agile, Del viejo blog, Profesión | 15 Comments

Estaba escribiendo una respuesta en la lista de Agile Spain a mi compañero Leo, y me he ido liando, liando… y al final me ha salido un alegato contra la falta de productividad. Y como queda un poco “off-topic” he decidido sacarlo al blog.

Pues bien, el caso es que el próximo día 3 de Junio, Ángel Medinilla dará una charla sobre Contratos ágiles subtitulada muy acertadamente “Vendiendo Scrum a tus clientes”. Lo que pasa es, y esa era la razón por la que comencé a responder a Leo, que creo que Ángel puede encontrarse con preguntas chungas del tipo “en España eso no se puede hacer”, “no veas cómo son mis clientes” y similares. No hace mucho unos amigos me dijeron justamente esto. Y lo peor de todo es que yo al menos no tengo argumentos suficientes para rebatirles.

Ayer estuve charlando con Xavi Albaladejo también sobre esto mismo y creo que ahora estoy mejor “armado”, puesto que puedo explicar que es posible plantear dos relaciones comerciales con los clientes: una basada en el clásico “fixed price and time” (precio y fecha cerrados) y otra basada en el contrato ágil, es decir, “time and materials” (horas x hombre cerrados) con alguna matización. A este último hay que conseguir quitarle ese “tufillo a charcutería prestación de servicios sin valor añadido” que algunos le encuentran porque no se lo explicamos bien, pero creo que esto es un problema menor.

Pero yo soy un “creyente” y sospecho que la lucha por convencer a los “no creyentes” puede ser muy dura cuando lleguemos a los argumentos fatalistas de “en España eso no se puede hacer”. Sobre todo porque muchos se escudan en ese fatalismo para no afrontar la realidad de su falta de productividad. Yo opino que el mayor problema que tenemos en nuestro sector no es que los clientes no nos quieran comprar proyectos ágiles (que no digo que no sea difícil) sino que no tenemos equipos productivos y capaces de adoptar una cultura ágil, donde todos debemos ser responsables y buscar la excelencia. Tengo la extraña sensación de que muchos equipos de desarrollo no son conscientes de que (hagan agilismo o no) no trabajan para su jefe (el que les paga las nóminas) sino para sus clientes (los que pagan las facturas y que sólo lo hacen de manera continuada si quedan satisfechos). Vale, también los continúan por razones “extra-comerciales”: sólo tengo 3 proveedores y este contrato le toca a fulanito -aunque siempre me entrega los proyectos tarde y con una calidad demencial-, o la fase X del proyecto ha sido una porquería, pero no me queda más remedio que dar la fase X+1 a los mismos porque ningún otro podría entender lo que hay hecho… Pero estas razones son muy tristes, ¿verdad?

Lo siento si alguien se molesta, pero sinceramente es lo que pienso. ¡Ah! Y no me vale que me digan que en el extranjero es igual que en España. A mi lo que me importa es que la productividad en España viene descendiendo de manera continuada desde el año 1995 y que parecemos estar cómodos con ello. La noticia es de 2006 pero no creo que hayamos mejorado significativamente desde entonces. Además, hay otros artículos más recientes (todos pre-crisis) que argumentan con más datos esto que digo.

Claro, si nuestros equipos son poco productivos porque el proceso de desarrollo es mejorable, la respuesta es fácil: mejora el proceso de desarrollo y aumentarás la productividad. Pero qué pasa si el problema es de actitud. Si cuando pides que de iteración a iteración mejoren la productividad y desde el becario hasta el jefe de proyecto, pasando por todos los seniors, ninguno asume su responsabilidad y trata de hacer mejor su trabajo y el de su equipo. He dicho mejor, no bien. Y lo digo sobre todo porque, como yo lo veo, esto del agilismo va de ir mejorando de manera continuada. Y aportar valor al cliente, no a tu jefe, sino al cliente.

Toda esta reflexión “en voz alta” me ha recordado lo que decía Ken Schwaber (uno de los autores de Scrum) pero entonces llegamos a otro tema peliagudo: la meritocracia (léase “¿son capaces nuestros gerentes de despedir a los vagos y a los inútiles?”). Glub, mejor no sigo. :-)

Bueno, Ángel, prepárate para la charla del día 3, porque si nadie te pregunta esto ya te lo preguntaré yo. (Si no me pierdo otra vez para llegar, claro)  :-D

http://jmbeas.blogspot.com

Tags: , , , ,

Salvando las distancias

May 13

Posted by jmbeas in Agile, Del viejo blog, libros | Comments off

Voy en metro, ilusionado, camino del segundo día del curso de Scrum de Medinilla. Y me he pillado el libro de Gojko Adzic “Bridging the Communication Gap” porque ayer surgió el tema de las especificaciones ejecutables y los roles dentro del equipo. Pero estoy un poco desentrenado porque hace mucho que no voy en metro con tiempo para leer, y el iPod lo tengo vacío de podcasts por escuchar, así que me he puesto la “música aleatoria” y mientras escucho de lo más variado (desde la deliciosa Joy Denalane hasta M-Clan, que no veas cómo me animan) he pensado en tomar notas para cumplir con una “cierta obligación”: explicar lo que me ha parecido el libro.

Gojko Adzic es un tipo que habla en inglés con un acento balcánico realmente difícil de seguir (al menos para mi), así que pensé que era buena idea comprar el libro para entender a qué se refiere cuando habla de talleres de especificaciones y de pruebas de aceptación ejecutables en entornos ágiles. Además, Gojko Adzic también imparte cursos sobre Domain-Driven Design y esa relación entre DDD y pruebas de aceptación es algo que me interesa bastante.

Voy a ser sincero, también compré el libro porque es el primero en el que se habla de Concordion, la herramienta open source en la que modestamente colaboro. Pero son apenas unas páginas y el valor del libro es mucho más que eso.

Adzic explica la importancia de que “la gente del negocio” hable el mismo idioma que “la gente técnica”. Esto muchos lo entienden como obligar a clientes y usuarios a que hablen en términos tecnológicos como “altas, bajas, modificaciones y listados (CRUD en inglés)”, o peor aún, de tablas, campos y relaciones.

En DDD hablamos de un lenguaje ubícuo, o único en todo el proyecto, y que es el que usan tanto técnicos como usuarios. Esto permite reducir los defectos producidos por malentendidos y tiende puentes entre ambos mundos, abriendo la posibilidad a una verdadera colaboración.

Un inciso melancólico. Voy ahora mismo montado (mientras escribo estas notas en mi moleskine) en el metro ligero y me he acordado de ese par de meses intensos que viví y trabajé (sobre todo lo primero) en Melbourne (Australia). Allí fui usuario del “tram” y he de decir que me parece un medio de transporte público de lo más interesante porque es a la vez rápido, cómodo y silencioso.

Pero sigamos con el libro. El grueso del mismo se basa en hablar del “agile acceptance testing” y de cómo buscamos ponernos de acuerdo en qué es lo que hay y lo que no hay que desarrollar. Para esto usamos ejemplos realistas en vez de requisitos abstractos. “Los ejemplos demuestran cómo debería actuar el sistema y cómo debería ayudar a los usuarios a hacer su trabajo”. Adzic propone que estos ejemplos sean creados por todo el equipo de implementación, no sólo por un “experto del dominio” (también conocido como “analista de negocio”) como en modelos de desarrollo más tradicionales. “Usamos los ejemplos para discutir el dominio y asegurarnos de que no hay malentendidos”.

Según Adzic, el uso de ejemplos realistas obliga a pensar más acerca de los problemas. De hecho, comenta cómo se producen muchas discusiones entre los expertos cuando se plantean ejemplos para casos extremos; discusiones que incluso les hacen a veces revisar sus propios procesos de negocio. ¡Vaya! Si resulta que podemos ayudar a nuestros clientes en vez de simplemente observar su comportamiento “desde fuera”, como si fueramos “supernanis con corbata”.

Damned! ¡Me he saltado una parada! Estaba tan concentrado… Menos mal que la frecuencia del metro ligero éste es alta y he podido llegar sólo un par de minutos tarde. Buff…

De vuelta del estupendo curso de Ángel Medinilla, sigo con el resumen del libro y me fijo en que no he explicado esto de los ejemplos. Vamos, que no he puesto ejemplos de ejemplos. :-) Adzic pone un ejemplo en la página 45 de una regla de negocio relacionada con el descuento que le podemos ofrecer a un cliente, pero a mi me gusta más el que explica David Peterson en la web de Concordion. Es bastante más completo porque nos lleva desde la historia de usuario (el requisito) hasta la prueba de aceptación automatizada (en forma de ejemplos). Es interesante cómo David hace mucho hincapié siempre en que debemos especificar con ejemplos que expliquen comportamientos muy elementales y dejar para otras especificaciones todo aquello que quedaría fuera. Son los “Further details” en el ejemplo. También Adzic habla de esto en su libro, pero menos; y yo creo que es importante esta anotación al margen para aquellos que queráis “tomar este camino” para hacer pruebas de aceptación.

En “Bridging the communication gap” también se explica cómo conducir estas reuniones (talleres de especificación) e incluso aconseja sobre algunas herramientas. Pero creo que es interesante explicar cómo pueden encajar estos talleres en nuestro calendario semanal (ágil).

Adzic sugiere lo siguiente:

Release es todo aquello que hacemos después de la demo para dejar bien cerrado el sprint. Etiquetamos en subversion, hacemos copias de seguridad, ponemos las versiones del nuevo sprint en los pom.xml (si usamos Maven y si es que tenemos que cambiar de versión), limpiamos las pizarras… y mientras esto lo pueden ir haciendo algunos desarrolladores (típicamente los becarios, je, je) pues el resto puede estar preparando el sprint primero revisando el backlog y luego, ya con los becarios incorporados, estimando las historias y decidiendo lo que se podrá hacer razonablemente en el sprint (las próximas dos semanas).

Ojo, es una manera de organizar el trabajo durante un sprint, pero lo importante de esto es que el dueño del producto (también conocido como jefe de proyecto, analista de negocio, o incluso tester, según vuestro “mapeo” preferido) se encarga de trabajar las historias de usuario (redacción y priorización) y de los ejemplos (criterios de aceptación) antes de los talleres de especificación, pero realmente es el equipo en su totalidad quien acuerda lo esencial de los criterios de aceptación mediante la discusión que se ofrece en esta reunión. Para los que ya estéis algo picados con esto del agilismo, me permito recordar “las tres Ces” (card, conversation, confirmation). Éste es el momento ideal para la conversación, aunque ya se haya tenido una conversación previa cuando se han estimado las historias de usuario en el Sprint Planning Meeting (usando terminología Scrum).

Bueno, y hasta aquí hemos llegado. Espero que os resulte útil. Y si alguien más se ha leido este libro y quiere contrastar aquí su opinión, estaré encantado de poder charlar con vosotros porque mi intención es preparar una presentación (o un taller, ya veré) sobre este tema y exponerla bajo el “paraguas” de Agile Spain.

http://jmbeas.blogspot.com

Tags: , , , , , ,

Gestionar proyectos

May 12

Posted by jmbeas in Agile, Del viejo blog, Profesión | Comments off

Hoy he terminado el curso de Scrum que imparte Angel Medinilla y que tuve que dejar a medias en octubre porque me pilló el nacimiento de mi segundo querubín.

Vale que yo iba bastante motivado, pero en la retrospectiva que ha planteado Ángel al final del curso mis compañeros lo han calificado como “completo” y “ameno”. Lo cierto es que no puede ser de otra manera. Ameno porque hemos jugado a pasarnos pelotas a ritmo de Jamiroquai o hemos visto videos como éste. Y completo porque no sólo hemos aprendido cómo se hace Scrum sino también sus principios y por qué es rentable para una empresa implantar esta metodología de gestión de proyectos.

Y además de todo esto, que es el objetivo estricto del curso, Ángel habla de muchas otras cosas y comparte su experiencia con los asistentes. Y favorece también que este intercambio de experiencias sea recíproco, con lo que todos nos enriquecemos muchísimo.

Pero yo no quería escribir para hacerle una cuña publicitaria (gratuita) a Ángel (bueno, quizás se la cobre más adelante… ya se me ocurrirá algo… je, je). Yo en realidad quería explicar que este curso de Scrum es también un curso de gestión de proyectos encubierto y, para qué engañarnos, es muy necesario formar a nuestros jefes de proyectos y líderes técnicos en lo que significa gestionar un proyecto y su relación con la rentabilidad si realmente queremos que nuestro sector sea competitivo (especialmente en estos tiempos de crisis y “cambios de modelos productivos”).

Ojalá hubiera muchas empresas en España que se dieran cuenta de que sólo es posible mejorar nuestra competitividad mediante incrementos significativos de nuestra productividad y que, como bien se ve en uno de los ejercicios que hemos hecho hoy con Ángel, no es posible producir incrementos significativos de la productividad simplemente confiando en que con el paso del tiempo tenemos más experiencia o en que “vamos a echarle más ganas”. Esperar que algo cambie sin hacer nada diferente es la definición de locura según Einstein.

http://jmbeas.blogspot.com

Tags: , , ,

Iniciarse en Scrum

May 12

Posted by jmbeas in Agile, Del viejo blog | Comments off

Hoy estoy en medio de un curso de Scrum de dos días que imparte Angel Medinilla. Acabo de leer un artículo de “El Raúl” titulado “No sé nada de Scrum. ¿Qué hago primero?” y no he podido evitar bloguearlo porque me parece un índice de recursos muy conciso, porque da un estupendo consejo (“Estudia”) y porque me da la excusa perfecta para meter la “cuña publicitaria” de Agile Spain.

Agile Spain es la comunidad virtual donde nos encontramos muchos de los que estamos interesados en que en España haya un cambio en la manera de gestionar proyectos y se comiencen a implantar metodologías ágiles como Scrum. Creo que es el mejor lugar para comenzar a compartir vuestras dudas y para informaros de cuándo y dónde se celebran charlas, conferencias, cursos, etc. Echad un vistazo a la lista de correo y si luego os interesa, suscribíos y participad.

http://jmbeas.blogspot.com

Tags: , ,