Archivo

Archivo para la categoría ‘ágil’

Trabajo en equipo

sábado, 31 de enero de 2009

Pregúntale a cualquier directivo cuál es el más importante de sus recursos. Contestará sin dudarlo

1971-toon-humbug-scrooge
    — ¡Las personas!

 

Y quizá sea ese el problema. Que contesta sin dudarlo, automáticamente. Es una respuesta aprendida, porque si dice “el tiempo”, o “el dinero”, o “mi sistema de electrogeneradores en caso de una pérdida de tensión”, pues lo mismo queda mal, y todo el mundo le dice que no cuida “sus recursos humanos”. Es lo que ha leído en los librillos que dan con las páginas salmón, lo que le dicen sus colegas en conferencias y workshops., lo que le dicen en las reuniones con sus superiores, en la semana de retiro empresarial allá en esa casa rural tan chula.

Sin embargo, creo que el tema no está en saber que los recursos humanos son los más importantes, o si son más o menos importantes que otro tipo de recursos. Es más, en algunos casos, los recursos humanos no son el recurso más importante: son el único recurso. Como decía, creo que el tema no está en saberlo, está en sentirlo.

Es difícil transmitir un sentimiento, sobre todo si sólo se hace con palabras, o leyéndolo en un libro. Creo que por eso existe la música. Y la imagen…

Balance
Wolfgang Lauenstein

¿Comentarios?

PS: No estoy diciendo que todos los directivos sean como el Sr. Scrooge 😉

ágil, en busca de mis valores, profesión , ,

Contratiempos en Scrum

lunes, 1 de diciembre de 2008

Hace unos días mi jefe tuvo su demo con algunos de los esféricos implicados más o menos directamente en el sistema del que os he hablado álguna vez, sin que el equipo haya estado presente.

La verdad es que ésta es la última irregularidad de las que han sucedido en el último sprint. Desde que se cometió la primera de ellas, en el equipo nos hemos sentido como esos corredores que tras un pequeño tropiezo, con cada paso se desequilibran más y con cada paso intentan recuperar el equilibrio de nuevo.

resize.php

Así por resumir, ésta es la lista de pasos tropezantes re-equilibrantes:

  • Tras finalizar el segundo sprint, la demo se retrasó cerca de una semana (la demo debe celebrarse justo el día después del final del sprint).
  • Aprovechando que había una semana de por medio, el product owner (el representante del usuario  en el proyecto) incluyó funcionalidad por motivos esencialmente políticos (o sociológicos, como dirían DeMarco y Lister), y no por el valor añadido al producto. El esfuerzo empleado en ello no ha sido visible ni en la estimación, ni en el burndown chart.
  • La fecha de la demo cambió dos veces en el transcurso de cinco días, lo que influyó aún más en la desorientación del equipo.
  • La demo se llevó a cabo por la tarde, lo que impidió realizar el retrospective a continuación (el retrospective debe realizarse justo después de la demo).
  • Como consecuencia del punto anterior, el retrospective se tuvo que dividir en dos sesiones de una hora y media cada una (más descoloque).
  • El sprint planning meeting se celebró un viernes, lo que redujo en tres horas el tiempo disponible para la estimación. El cuarto sprint empezó el lunes siguiente, pero sin tener todas las historias estimadas (hubo que hacerlo ese mismo lunes).
  • La duración del tercer sprint (el que hemos acabado de terminar) se fijó en siete días laborales. Este tiempo, fijado una vez más por motivos político-sociológicos, nos ha resultado muy incómodo.

El caso es que con Scrum, hay que tener una cosa muy clara (y ahí estoy totalmente de acuerdo con Jeff Sutherland): el método es muy sencillo, con pocas normas para nada complicadas; pero si quieres hacer Scrum, debes seguirlas estrictamente. Mientras esto sucedió en nuestro proyecto, las cosas fueron estupendamente. El incumplimiento de una norma un día y las que vinieron después provocó que las cosas fueran empeorando. Seguir Scrum a medias no es hacer Scrum.

— Ok, Wil, pero seguro que hay algo positivo…

¡Por supuesto! Lo positivo es que:

  • Todos esos asuntos aparecieron en el retrospective (como ya comenté) así que somos conscientes de ellos y estamos tomando las medidas para corregirlos.
  • A pesar de las dificultades, seguimos fieles al método. Incluso la funcionalidad que fue inyectada fuera del sprint se trató como si hubiera estado incluida, llevando a cabo los daily scrum, estimando cada tarea, etc. Todos los miembros del equipo sentimos (y sabemos) que Scrum funciona, y luchamos por que continúe funcionando.
  • Hemos aprendido que nuestra duración óptima de sprint se encuentra alrededor de las tres semanas (antes aprendimos que los sprints más largos son mejores al principio, para estabilizar el proyecto).

¡Estamos más animados que nunca! Buscando remedio a los problemas, enfocados en hacer avanzar el trabajo, pero de forma ordenada, no de cualquier forma.

ágil, profesión

El retrospective del segundo sprint

jueves, 13 de noviembre de 2008

En el proyecto en el que estamos trabajando, una herramienta de planificación y evaluación de rendimiento de una serie de profesionales, no hacemos el programa de una vez y lo entregamos al cliente cuando todo ha terminado. En vez de eso, construimos el sistema poco a poco, de forma incremental, y se lo vamos mostrando al usuario de forma periódica. De esa forma conseguimos del usuario una valiosa información que nos permite valorar la adecuación del producto que se va construyendo, aparte de hacer visibles muy temprano en el proyecto fallos de concepto, de funcionalidad, de usabilidad, etc. y poder corregirlos a tiempo. Al fin y al cabo, los que mejor conocen el dominio del problema y los que en definitiva van a usar el programa son esos mismos usuarios.

DSC01710 Cada uno de estos periodos de tiempo, en los que aumentamos la funcionalidad del sistema, recibe el nombre de sprint, y las reuniones periódicas reciben el nombre de sprint review meetings, aunque nosotros las llamamos demos.

Detrás de cada demo, los miembros del equipo y el Scrum Master (o sea, el que suscribe) llevamos a cabo otra reunión en la que analizamos qué fue lo que hicimos bien (y alegrarnos), qué fue lo que no se hizo tan bien (observad el sutil efecto impersonal) y qué medidas vamos a tomar para corregirlas. A estas reuniones se les llama sprint retrospective meeting.

¿Bueno, pues hoy hemos tenido nuestro segundo retrospective. Y hemos salido muy contentos. Por lo pronto, es toda una novedad que echemos la vista atrás para poder analizar qué se hace mal y poner remedio cada tres semanas, que es nuestra longitud de sprint. Pero hacerlo dos veces, es un milagro ;-). Respecto al anterior retrospective, he notado que somos mucho más equipo, que nos conocemos mejor. Nos enriquecemos mutuamente con el intercambio de ideas, de sugerencias, de puntos de vista y de reflexiones. Para decidir qué medidas correctoras íbamos a aplicar durante nuestro tercer sprint, hemos escrito en PostIts de los grandes cada uno de los aspectos negativos. En una sesión de brainstorming, hemos ido apuntando en cada PostIt las posibles soluciones, mientras que íbamos agrupando las que estaban relacionadas (pruebas, estimación, método…). Luego, cada uno ha dado sus nominaciones: tres votos a repartir entre un máximo de tres aspectos negativos a resolver.

ScrumLargeLabelled

Pero ha sido la agrupación de los PostIts y la lista de los nominados lo que me ha hecho pensar. Le hemos dado muchísima más importancia a los temas relacionados con las pruebas que con la estimación. Por lo visto, preferimos asegurar la calidad del código frente a la calidad de la estimación. También es verdad que en la primera retrospective ya se acometió una mejora sustancial: las estimaciones ahora se hacen mucho más precisas, descomponiendo inicialmente las historias del usuario (las características que le aportan valor) en tareas más pequeñas antes de empezar el sprint, y no después. Y lo que ya me ha dejado descolocado es que una de los aspectos negativos que hemos detectado es que no hemos cumplido bien las normas del scrum. Y ahí soy yo el principal responsable, porque esa es una de mis responsabilidades… Sin embargo, estoy satisfecho. Está claro que el equipo cree en este método, si no fuera así, no le importaría que las normas hubieran sido vulneradas.

Ahora falta que la Dirección también acabe igual de convencida como nosotros. Creo que vamos por buen camino.

Imagen cortesía de Mountain Goat Software.

ágil, diseño, profesión

All is full of love

lunes, 3 de noviembre de 2008
Comentarios desactivados en All is full of love

Lo bueno: Hoy hemos tenido una demo inesperada. Nuestro jefe nos ha dicho con una antelación de dos minutos que un esférico venía a ver la aplicación. Le he avisado de las consecuencias que puede tener una cosa así, improvisada. Lo bueno, es que el trabajo en equipo, reflejado en el esfuerzo diario de los deploys (la construcción e instalación de la aplicación en un servidor de preproducción, todos los días), ha dado sus frutos, y la demo ha ido sin (demasiados) problemas. We did it!! 🙂

Lo mejor: Los libros tienen consecuencias inesperadas. De ellos pueden nacer jardines verticales, eternas charlas con la excusa de un café, ríos de música digital, o viajes al Madrid de 1808. Amistad, en definitiva.

El tema de hoy es All is full of love, de Björk (de la que he posteado muy poco, pero que cada vez me gusta más). Me crucé con ella casi por casualidad en blip. El vídeo me encanta, y la composición es genial (para mí, claro, que no me canso de escucharla). Otro tema es la letra, pero dejémoslo ahí…

 

 

You’ll be given love, you’ll be taken care of, you’ll be given love, you have to trust it, maybe not from the sources you have poured yours, maybe not from the directions you are staring at, trust your head around, it’s all around you.

all is full of love, all around you
all is full of love, you just ain’t receiving
all is full of love, your phone is off the hook
all is full of love, your doors are all shut
all is full of love!
all is full of love…

All is full of love,
Homogenic (Björk)

Si quieres, también puedes ver y escuchar los motivos detrás de este magnífico tema, y por qué se hizo así (YouTube, en inglés).

ágil, un amigo es un tesoro, videoclips

Día doscientos noventa y seis

miércoles, 22 de octubre de 2008

266861797_8d01c8889f Lo bueno: A pesar de haber dormido más de lo habitual (que ya es decir), empecé el día de un empanado que asustaba, de hecho me ha salido el peor scrum de todos (el daily scrum o melé diaria es la reunión de 15 minutos que mis compis de proyecto y yo hacemos al empezar el día para contarnos qué hemos hecho, qué dificultades tuvimos para hacerlo, y qué vamos a hacer). Como encima llegué tarde, la hucha del proyecto ya tiene un euro más. Lo bueno es que el empanamiento derivó en buen rollo hacia la mitad del día, y se mantuvo (se mantiene).

Lo mejor: Que mi plan de esta tarde falló, también falló el de una buena amiga, y todo el mundo sabe que fallo x fallo = acierto, así que nos hemos pasado una buena tarde de risas a las que luego se unieron esféricos académicos, que también aportaron lo suyo 🙂

El tema del día: Entré en el trabajo tarareando esta canción. Ignoro el motivo, y tampoco lo voy a buscar.

Dulce condena
Los Rodríguez

Bonus: Es tonto, pero no he dejado de reírme todo el día a su costa. Se levanta el telón y aparece un duende saltando encima del hombro de un tipo normal, y el duende no deja de decir: "¡es un tío guay!, ¡es un tío guay!…" ¿Cómo se llama la película?

La respuesta en los comentarios.

La foto, Un día cualquiera, es de quieroserunaameba.

ágil, es bueno echarse unas risas, ocio, un amigo es un tesoro, videoclips

Sacudidas neuronales

martes, 21 de octubre de 2008

Esta semana pasada ha sido una semana especialmente intensa. Ha sido intensa sobre todo en temas "sociales". Ya empezó el tema con un post pidiendo por favor que tuviera a bien el adoptar una de esas criaturitas que duermen sabiendo mucho y nunca se cansan de contártelo. Basta con abrir sus páginas, con paciencia. El elegido fue "Lo peor de cada casa", de…

— Tenía yo ganas de leer a Wolfe, que me han dicho que La Hoguera de las Vanidades es muy bueno.

— Es que…  no es Wolfe, es Sharpe.

…de Tom Sharpe. El lunes fue el día de la entrega. Aquí la prueba gráfica, junto con el título de propiedad:

loPeorDeCadaCasa tituloDePropiedad

El martes pasó sin pena ni gloria, aunque sí fue un día un tanto duro en términos laborales. Nada del otro mundo, sólo el trabajo acumulado de la semana anterior (que fue la Semana Internacional de las Demos) y que salió de forma rutinaria. Lo único a destacar es que buscando unos zapatos acabé (cómo no) en la Casa del Libro de la calle Fuencarral y saliera de ella con otros dos miembros de la familia Estantería: una antología poética de Ángel González y "Entre limones", de Chris Stewart (ex-Genesis). Y si ya no había suficientes animales en casa, llegó Kenny. Kenny es un gato de ocho años que estará en casa dos semanas (sin pagar alquiler, que tampoco es plan). Le gusta ser protagonista, así que es el de primer plano, León el que lo mira envidioso desde abajo:

DSC01633

El miércoles sí que fue un día complicado en el trabajo. Pero complicado de verdad. Porque la verdad, hablarle a las máquinas es sencillo. No se cruzan emociones, son fríamente objetivas, saben mantener la distancia con mensajes claros y definidos: "El valor que intentas guardar en la base de datos ya existe.", y no lo adornan con un "como ya deberías saber, ¡canelo!". Y son deterministas. Todas, en la misma situación, ante la misma entrada, dan exactamente la misma salida.

Pero las personas… Ay, las personas… Las personas son todas distintas. Una palabra no significa lo mismo para ti que para mí. Una de esas palabras sembrada en aquél hace crecer un olivo, y en éste una vid. Y en este otro, una vid también, pero torcida de otra forma. No sé si escogí las palabras exactas, pero sí sé que puse toda mi voluntad y todo mi interés y toda mi alma, por qué no decirlo, en mediar en un conflicto entre dos compañeros. Buscando la palabra que hiciera germinar en uno la comprensión hacia el otro, la persuasión que puesta ante los ojos del otro le hiciera ver en la persona de enfrente justo eso, la persona que era, con sus problemas y sus movidas, que son en definitiva las de todos. Nada de lo humano nos debería ser ajeno. Fue un día duro para muchos otros en el trabajo, y animado por cierta confianza obtenida en el conflicto anterior, me puse el disfraz de Don Quijote y me puse ahí a desfacer entuertos. Si a todo ello le mezclamos que justo ese día tuvimos el segundo sprint planning meeting (¡todavía no he posteado sobre ello! :-S) que es también una reunión técnica y psicológicamente exigente, el final del día vino como agua en un desierto, con una extraña mezcolanza de duda y plenitud, con la sensación de haberme enfrentado a uno de mis obstáculos y no haber salido demasiado mal parado.

DSC01621 El jueves empezó como siempre, pero terminó en el CaixaForum, buscando unas entradas para unas jornadas sobre psicología a las que me han invitado (invitado porque todavía le debo las entradas 😉 No conocía el edificio ni sus actividades, que empezaré a seguir, y aluflipé pepinillos de colores con el jardín vertical que podéis encontrar en la entrada y ver en la foto (más grande aquí). La charla con mi guía, que empezó entonces, se extendió densa y profunda unas veces, ligera y divertida en otras, y agradable en todas ellas, por las líneas de los temas más peregrinos. Cada vez me confirmo más en ello: el nosce te ipsum pasa necesariamente por conocer también a los demás, en su humanidad, y leer en ellos tus propias páginas.

DSC01605 El viernes, que en lo laboral siguió la rutina impuesta por la nueva metodología que estamos siguiendo (y que ha generado una inesperada dinámica de mentes, de emociones, de interacción, de sinergia de equipo que me ha dejado anodadado y/o estupefacto), el viernes, digo, cogí los bártulos y me fui a Salamanca a despedir la soltería del que ya es mi cuñado porque, como le dije: "como se te ocurra ahora echarte pa’trás…" 😉

Resumiré el fin de semana, que el post empieza a ser largo.

Leí muchas páginas de mucha gente que hice mías porque también hablaban de mí a su manera. Aprendí muchas cosas, vi muchas cosas, y sentí muchas cosas. Que dos besos dados en una determinada ocasión dicen mucho más de lo que pueda parecer a primeras. DSC01656Que la resistencia es una opción que ocupó un lugar, para luego dar paso al dejarse llevar, y que me permitió concentrarme en el camino. Descubrí que no soy tan viejo como creía, porque aguanté dos sesiones intensivas de casi nueve horas cada una de risas, de conversaciones filosóficas con el cerebro ofuscado e inmerso en alguna que otra copa de ron, de repetir hasta la saciedad "contigo no… bicho", de reconocer "cuánto daño que ha hecho la ESO", de hacer "retratauras", de preguntar sin ton ni son a la gente si sabían quién era Schrödinger y porque tenía un gato que no estaba ni vivo ni muerto, sino todo lo contrario.

DSC01637

Descubrí que por la noche, al contrario de lo que pensaba, también sé cantar ópera, pero de una muy particular. Que la morucha es una carne. Qué no sé tanto de cuántica como pensaba. Me confirmé en la idea de que en cada persona hay mucho más de lo que parece en una primera impresión (y por eso no creo en las primeras impresiones), que conocí mejor a personas estupendas y que por empezar a andar por uno de mis caminos, acabé recorriendo sin esperarlo el de otra persona, a la que quiero mucho: mi hermana.

Todos y cada uno de estos días tuvieron algo en común. Todos significaron una sacudida mental, un despertar, un mirar más allá. Todos me han transformado de una forma u otra. Todos me han cambiado y todos me han hecho crecer.

Y me está enganchando…

ágil, ciencia, comunicación, de la pitanza, en busca de mis valores, es bueno echarse unas risas, familia, filosofía, mens sana, un amigo es un tesoro

Presentaciones de Kniberg sobre Scrum

domingo, 10 de agosto de 2008
Comentarios desactivados en Presentaciones de Kniberg sobre Scrum

Henrik Kniberg, el autor del libro electrónico Scrum and XP from the Trenches, ha publicado en su blog tres presentaciones que ha impartido en Agile 2008, celebrado este año en Toronto. Os las enumero a continuación y aporto mis impresiones.

Bootstrapping Scrum and XP in a crisis (pdf)
La url del post da un error

Car keysPistas y consejos para arrancar Scrum y XP. Kniberg y Farhang muestran su experiencia en la implementación de Scrum por primera vez en su empresa. Deja caer varias pistas, aunque la mayoría viene ya en su libro.

Que el arranque de Scrum tenga éxito o no, creo que depende en gran medida de la cultura que sobre los defectos y la manera de tratarlos tenga la empresa. Scrum levanta ampollas porque Scrum hace muy visibles los defectos. Y hay que ser culturalmente maduro para acometer correctamente esos defectos y no disparar al mensajero.

Ten ways to screw up with Scrum and XP (aquí)

http://www.medes-salud.com.ar/media/imagenes/alimentos/huevo%20roto.jpgA la hora de acometer un proyecto, tan importante es saber qué debe hacerse, como lo que no debe hacerse. Esta presentación expone 10 formas de joderhundir un proyecto a pesar de seguir Scrum y XP.

Las diez maneras giran alrededor de conceptos clave de Scrum y XP: definición de "hecho", velocidad, retrospectivas, trabajo en equipo, deuda técnica, product backlog, product owner, y sprint backlog.

¿Mi opinión? Que todas se resumen muy bien en una regla: observa y adáptate. Mira qué cosas te funcionan y cuáles no y por qué, y trata de arreglarlas o de adaptarte a ellas. Quizá la experiencia no es conocer las reglas, sino saber cuándo se deben ignorar.

Technical debt – How not to ignore it (aquí)

http://www.subu.org.uk/files/minisites/1212/debt.jpgEl concepto de deuda técnica es una metáfora ideada por Ward Cunningham. Es el coste de arreglar algo que se hizo rápido y mal (quizá buscando un beneficio inmediato), más los intereses provocados por esa deuda (dificultades en la mantenibilidad y modificabilidad del software, por ejemplo).

Como en cualquier empresa, la deuda es un mecanismo de financiación como cualquier otro, pero a nadie se le ocurriría basarse en él y no asumir sus consecuencias, es decir, devolver el capital y pagar los intereses… Excepto en el desarrollo de software. Esta charla define el concepto de deuda técnica y ofrece sugerencias para tratar con ella desde una perspectiva Scrum/XP.

Aún siendo un término que los tecnicoles pueden entender, me temo que todavía pesa más en sus molleras el beneficio inmediato y las pérdidas futuras que el beneficio a largo plazo y pérdidas pasajeras (estos dos último síntomas propios de personas maduras —otra vez la madurez, hmmm—).


Enlace | Blog de Henrik Kniberg
Enlace | Scrum and XP from the Trenches (libro electrónico)
Enlace | Agile 2008 (Toronto, Canada)
Enlace | Ward Cunningham
Sobre deuda técnica | Martin Fowler
Sobre deuda técnica | Steve McConnell
Sobre deuda técnica | Primera aparición del concepto (OOPSLA’92)
Sobre deuda técnica | La complejidad como como deuda
Sobre deuda técnica | Deuda técnica (en WardWiki)

ágil, profesión

Implicación de los stakeholders

domingo, 27 de julio de 2008
Comentarios desactivados en Implicación de los stakeholders

El otro día estuvimos hablando el Product Owner y yo un poco sobre la demo. Lo más destacable de la charla fue que uno de los stakeholders había decidido ir ocasionalmente a ellas. y que algunos de los implicados podrían no llegar a ser ni siquiera convocados. Ignoro los motivos de tal decisión, pero creo que no es acertada. Es necesario que el equipo sienta que los interesados estén… interesados precisamente 🙂 Al fin y al cabo, esa es su labor (ya sabéis la diferencia entre los comprometidos y los implicados, ¿no?).

Sé que todavía es pronto para hablar de la demo cuando todavía no hemos llevado a cabo ni siquiera el primer Sprint Planning Meeting, pero es un punto que deberemos tener en cuenta. ¿Cómo solucionar un problema como este si no se entienden los motivos para no estar implicado?

Creo que la solución está en buscar un punto intermedio, reconocer que los stakeholders tienen sus motivos, aunque no se comprendan, y buscar, si no una implicación ideal del 100%, sí al menos un punto intermedio, algo así como una Escala Wituki de Implicación de los Implicados (EWII), entre 0 y 5 (0 significa que no está implicado para nada). Es decir, el objetivo no es obtener el 100% de implicación, el objetivo es obtener la máxima implicación posible.

Antes decía que el equipo debe sentir que los implicados lo son. El objetivo de la demo no es que vaya un "jefe" para que el equipo sienta la presión. La presión viene ya auto-impuesta desde el mismo momento en que el equipo se compromete con una pila de sprint. Por eso no vale cualquier jefe. Los asistentes deben ser precisamente los stakeholders, porque son ellos los que podrán evaluar adecuadamente si el desarrollo está tomando el rumbo que ellos necesitan, el rumbo que les da más valor. Por eso una demo con el Product Owner, el Scrum Master y el equipo no es lo ideal (aunque se puede hacer).

Lo que no quisiera es que todo ello acabe significando que estamos haciendo Scrum al 60%. Debo ser flexible con las reglas, pero debo saber en qué punto pueden dejar de romperse. Y sobre todo, lo que no me gustaría es que a base de ir saltándoselas, el resultado no sea el esperado y se llegue a pensar que Scrum no nos ha servido.

Seguiremos informando.

ágil, profesión

Presentación de Scrum

jueves, 17 de julio de 2008
Comentarios desactivados en Presentación de Scrum

Bueno, pues ya está hecho. Esta mañana he presentado a mis compañeros la metodología Scrum, que vamos a emplear en un proyecto piloto para ver sus bondades y sus maldades. La verdad es que empecé un poco trastabillado, pero luego la cosa ha ido a mejor, y de hecho me ha parecido que la gente ha salido muy ilusionada con el número método (todo gracias al método, no a mi 😉

A parte de la presentación en sí, uno de los objetivos que perseguía era ver qué dudas suscitaba el método en mis compañeros, en ese momento muchísimo menos contaminados que yo con toda esta historia.

Han salido preguntas muy interesantes:

– ¿Cuántas personas debe tener un grupo? ¿Deben tener alguna formación específica? ¿Cómo escala el método a equipos más grandes?

– ¿Sabemos de alguien que esté implementando este mismo método?

– ¿Eso significa que vamos a tener que entregar nuestras aplicaciones en 20 días? 😉

– ¿Cómo se determina realmente lo que va en el Product backlog?

– ¿Cómo se va a conjugar una aproximación iterativa orientada a la funcionalidad con el código de infraestructura necesario para darle soporte?

Los comentarios de pasillo después me han confirmado en la idea de que la gente ha salido muy ilusionada con el tema. Ven claramente que es un método que les da libertad suficiente para hacer bien aquello que saben hacer bien, que fomenta la comunicación entre los implicados en el proyecto, y que hace las cosas muy visibles. Sobre todo, parece divertido :-).

Los primeros retos con los que nos vamos a enfrentar son sin duda:

– Decidir qué va en el product backlog y de qué manera.

– Formar a la gente en procesos de estimación (aquí McConnell volverá a ser de gran ayuda).

– Aunque parezca una chorrada, encontrar un buen sitio donde celebrar los Daily Scrums, y prepararla adecuadamente el entorno para organizar otras reuniones del equipo, el Scrum Master y el Product Owner…

En fin, que queda mucho trabajo que realizar, pero estoy super-ilusionado con ello. A medida que vaya encontrando dificultades, las iré poniendo por aquí, con la solución que pueda haber encontrado o que hayamos desarrollado (para resultados buenos, la blogosfera está llena 😉

Una cosa más: el chiste del cerdo y la gallina sonará muy bien en inglés, pero en castellano el éxito ha sido cero. Menos mal que he conseguido levantarles una sonrisa al final 🙂

ágil, profesión

Formalmente ágiles

jueves, 3 de julio de 2008

Por fin somos oficialmente ágiles.

En nuestro equipo de desarrollo habíamos seguido en mayor o menor medida, aunque a veces sin mucha conciencia de ello, ciertos comportamientos ágiles, cogidos con pinzas de aquí y de allá. A pesar de todo ello, no éramos un equipo (oficialmente) ágil.

Ahora, con el apoyo de la dirección, podemos decir que oficialmente nos hemos decantado por Scrum. Lo hemos visto fácil de explicar, sencillo y muy claro. Sin embargo, somos conscientes de que, igual que en cualquier faceta técnica, llevar la teoría aunque sea poca a la práctica implicará muchas decisiones y dificultades.

Scrum probablemente no sea el método definitivo, como no lo es ninguno, pero sí que es una base sobre la que elaborar el nuestro propio. No somos racistas, así que aceptaremos de buena gana cualquier idea que sea compatible con los principios ágiles, sin embargo, en mi opinión deberán aceptarse poco a poco (los cambios bruscos, todos lo sabemos, no son buenos). Tenemos ahora lo que necesitábamos: un marco, un esqueleto sobre el que construir el método que nos vaya bien.

Probaremos el método utilizando como plataforma de pruebas un nuevo proyecto que está ahora mismo en las fases iniciales de definición. Todavía nos queda preparar unas charlas para informar al equipo de lo que pretendemos, profundizar un poco más en los principios ágiles que sustentan el método

Decía antes método, y no metodología, porque metodología es otra cosa. De la Wikipedia:

Método es el procedimiento para alcanzar los objetivos y la metodología es el estudio del método.

Voy a utilizar el blog como medio de reflexión, de registro y con vuestra colaboración, espero que también de debate. No recuerdo quién decía que la inteligencia no es patrimonio de la mente, sino de la combinación de muchas, que las buenas ideas emergen de una red pensante, no de una cabeza preclara.

Y como la situación lo merece, amig@s, nueva categoría: ágil 😉

ágil, diseño, profesión