Tag Archives: scrum

Nueva vida: día 2

by

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

Jugar a mejorar

by
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

Cuidado, soy un tipo peligroso

by
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