Me he dado cuenta que tanto hablar de SCRUM y lo más básico no lo hemos tratado, aquí os dejo una presentación que utilizo para introducir a SCRUM, es una traducción y adaptación de la que hay en la página web de mountain goat software.

Scrum

View more presentations from David Doctor.

|

Antes de que se forme cualquier equipo y se comiencen a planificar las diferentes tareas hay que pasar por algo ineludible: la estimación del esfuerzo y el tiempo.

En una serie de entradas del blog me gustaría tratar técnicas de estimación, desde las clásicas como COCOMO II hasta las ágiles como planning poker, comentando cómo hemos llevado a cabo estimaciones dentro de los equipos en los que he estado trabajando.

El esfuerzo en proyectos de ingeniería civil como hacer una carretera, se puede tangibilizar en los kilómetros que se tienen que construir y el tiempo se derivaría de este esfuerzo. Por ejemplo, si tenemos que hacer 1000 kilómetros con 10 personas que son capaces de realizar 12 km al día se estima que el proyecto durará aproximadamente 83 días. En proyectos software el esfuerzo se mide en persona-día que es el trabajo que una persona es capaz de realizar en un día.

Tan pronto como el comercial de tu empresa ha "mal vendido" un proyecto ya empiezan las presiones: ¿cuánto va a costar hacer esto? ¿en cuánto tiempo lo tendréis?,quiero un plan de proyecto para entregárselo al cliente... uno se queda estupefacto ante tanta prisa y cúmulo de peticiones sobre todo porque internamente piensa "cómo puedo decir el tiempo que tardaremos si ni siquiera se lo principal: ¿qué hay que hacer?" y, cuando empezamos en esto de gestionar proyectos, nos lanzamos a la piscina por eso del que dirán y contestamos: esto estará en 3,5 meses y necesitaré a 5 personas... !craso error!

Antes de empezar a hablar de técnicas y métodos para estimar hay dos reglas que, en mi opinión, son fundamentales:

1.- Estimar significa estimar. Algo tan trivial como esto no siempre parece obvio y, sobre todo, no es fácil hacerlo entender al equipo de ventas. Si a mi me preguntan: ¿cuánto tardo en viajar de Madrid a Valencia? suelo contestar que, basándome en mi experiencia en otros viajes previos, aproximadamente entre 3,5 y 4 horas. Uno nunca sabe si va a encontrar tráfico, si va a parar a tomar un café o si el coche se va a averiar en el camino. Por eso es importante siempre dar un rango en las estimaciones y no parecer que la cifra que das no tiene ninguna incertidumbre.

2.- El rango es inversamente proporcional a la información y el momento en el que se haga la estimación, esto es, si estamos en una fase temprana o disponemos de muy poca información no nos podemos negar a dar una estimación, pero si podemos dar un rango muy amplio y viceversa, si ya disponemos de mucha información el rango puede disminuir.

Siempre me gusta esta figura, el famoso cono de la incertidumbre de Boehm donde se puede ver que dependiendo de la fase en la que nos encontremos (en el caso de un desarrollo en cascada) si damos una estimación en una fase temprana esta puede variar desde un 25% hasta un 400%.



Pongamos un ejemplo: nuestro equipo de ventas nos dice "nuestro cliente quiere un portal web para gestionar sus productos, ¿cuánto vais a tardar?", nosotros intentaremos obtener toda la información posible para, usando nuestra técnica preferida, dar una estimación. Después de reunirse el equipo se estima que el proyecto durará 10 semanas y nuestra contestación sería: entre 2,5 y 40 semanas. Las reacciones, claro está, pueden ser muy diversas, la más común sería: "hombre, vaya estimación dáis, con ese rango yo no puedo vender nada" pero nuestra respuesta debería ser: "mi grado de incertidumbre es tan grande como el tuyo, tan pronto tengamos más detalles sobre el proyecto podremos afinar más". He dicho "debería ser" porque, al final, de ese rango suelen coger los números más favorables a su venta ;-)


En este post nuestra intención era introducir que es estimar proyectos software sin entrar en detalle, una vez que sabemos que el proceso era obtener información de qué hay que hacer, aplicar una técnica y ofrecer unos resultados en las siguientes entradas del blog hablaremos de tecnicas y compartiremos ejemplos. Para los que no puedan esperar aquí tenéis el conocido método "estimación de mi jefe": si nos dicen que tiene que estar en 2 días, subid a la siguiente unidad temporal y multiplicarlo por dos. Casi con total seguridad serán 4 semanas de trabajo real ;-)

|

Después de unas semanas de vacaciones en el país de las hamburguesas y los coches grandes me voy a permitir escribir una pequeña entrada en el blog acerca de la duración que deben tener cada sprint.

Como en todo, aquí tampoco hay fórmula mágica. Comenzar una iteración requiere que, si no es la primera, se haga una demostración de la funcionalidad implementada en la anterior, se reflexione sobre lo que ha ido bien o mal y las posibles mejoras en la retrospectiva y, lo que lleva más tiempo, se planifique lo que se hará en el nuevo sprint.


Si realizamos iteraciones de 4 o más semanas el equipo puede ir perdiendo agilidad, imaginad que llega una nueva funcionalidad que debe ser incluida en el siguiente sprint de forma prioritaria, el dueño del producto debería esperar a la finalización de un sprint largo y no cubrir a tiempo esa necesidad de negocio.

En iteraciones cortas, como es obvio, puede que no se entregue casi un incremento de la funcionalidad y por lo comentado anteriomente requeriría la reunión de todo el equipo con el dueño del producto muchas veces lo que, en la realidad, no siempre es factible.

Parece que dos semanas está siendo tomado como un estándar de facto y es el tiempo que en los que he participado como Scrum Master hemos venido utilizando con éxito, hay tiempo para introducir de forma rápida nuevos requisitos y para obtener un incremento de la funcionalidad.

Si la duración puede/debe variar a lo largo de un proyecto ya es una discusión que podremos tener en un post futuro ;-)

Como siempre os pregunto a vosotros, ¿cuál suele ser la duración del sprint que soléis utilizar? esperemos tener más participación esta vez :-D

|

Recientemente asistimos a un curso de CSM donde Robin Dymond nos mostró un video que merece la pena ver. ¿Será este el primer Scrum Master de la historia? juzgar vosotros mismos.

|

Leyendo lo que Roberto nos dice en su post "Preparados para ser ágiles" me ha venido a la cabeza algún que otro problemilla que hemos sufrido en proyectos cuando algún director, al finalizar un sprint, pregunta: y bien, ¿cómo va el avance del proyecto? ¿qué tal ha ido esta iteración? quiero un pequeño informe para ir tomando decisiones. Mi respuesta inicial fue: lo mejor que puedes hacer es acercarte al panel de tareas, echarle un vistazo al burndown chart y al release burndown chart, con esto podrás contestar todas tus preguntas.

Esta respuesta te puede servir por primera vez pero al final te siguen pidiendo, iteración tras iteración, alguna forma menos pesada (para ellos) de tener datos, al final yo pensaba: "ya estamos volviendo a la burrocracia innecesaria. Esto no es nada ágil, si la información está ¿por qué tenemos que reproducirla en otro formato?"

Finalmente, después de leer un buen libro (Agile estimating and planning) tome prestada una pequeña idea de Mike Cohn presentando al final de cada sprint un resumen.

Os muestro un ejemplo donde he eliminado algunos datos "confidenciales" con algún borrón que otro ;-)


La primera sección comienza con una explicación del contexto del sprint: indicamos fecha de inicio, fin, número de días laborables y el personal que ha participado.

Si os fijáis en la última tabla se ponen días planificados vs. días trabajados, mostrará si una persona estuvo al 100% asignada, si estuvo enferma, etc. esto ayudará a dar explicaciones de qué ocurrió en la iteración.





La siguiente sección mostrarán gráficos muy útiles: burn down chart y un gráfico de barras de la velocidad de las últimas iteraciones, junto con la media.


Finalmente, siempre siempre me gusta poner una valoración del sprint donde indicaremos que historias de usuario fueron incluidas y los puntos que realmente han ganado.


Si os digo la verdad este tipo de informes, que a mi me llevaban 40 minutos, ayudó a la dirección de la empresa a ver un estado del proyecto y a mi mismo para tener datos históricos del equipo que en el futuro nos ayudaría a mejorar. Y vosotros, ¿usáis algo parecido? sería muy interesante si alguien comparte su experiencia.

|

Las metodologías ágiles se postulan como una respuesta adecuada a las necesidades actuales (rápidez, adaptación al cambio, flexibilidad) en el desarrollo de software. Leyendo y revisando sobre estas metodologías, especialmente SCRUM, me ronda por la cabeza una idea que comparto en este artículo: ¿estamos preparados para ser ágiles?.

Si explicamos las bases y el funcionamiento de SCRUM a cualquier persona (recomiendo realizar el "experimento" con alguien no relacionado con la informática) su primera reacción será la de preguntarnos por qué buscamos nombres complicados ("Product Owner", "Sprint", "Backlog") a algo que parece de sentido común. El método propuesto, las figuras y roles que participan, la filosofía de trabajo y la relación entre todas las partes (clientes, equipos de trabajo, partes interesadas "stakeholders") son simples de entender. Si me apuras, diría que también son simples de aplicar. La primera vez que leí sobre SCRUM tuve la tentación de pensar que, de alguna manera, ya había aplicado algunos de sus principios a los proyectos en los que había participado.

Tenemos en nuestras manos una metodología como SCRUM que no necesita de grandes tecnicismos, que facilita la colaboración y comunicación entre clientes, ingenieros, comerciales, directivos, entonces, ¿por qué volvemos a las metodologías tradicionales, a lo ya conocido, cuando las cosas se ponen difíciles?, ¿estamos realmente preparados para aplicar las metodologías ágiles, independientemente de la situación del proyecto?. Mi opinión es que el planteamiento de las metodologías ágiles lo asumimos sin ningún esfuerzo por bueno. La estructura de una gran mayoría de las empresas cuentan con una organización (departamentos, áreas, responsables de departamento, comités de evaluación,etc) y asignación del personal en múltiples proyectos que impide la implantación de SCRUM o de cualquier otra metodología ágil. En otras ocasiones la dificultad viene de las personas que participan en el proyecto, asumir responsabilidades, disciplina, compromiso en realizar lo que he dicho públicamente que voy a hacer, parece que no es tan fácil.

Me interesa saber si, ¿realmente estamos preparados para ser ágiles?.

|

Cuando comencé a utilizar por primera vez Scrum me planteé utilizar alguna herramienta donde se pudieran ir creando historias de usuario, tareas, etc. ya que colocar un panel de control dentro de la oficina se planteaba complejo. Algunas herramientas disponibles requerian sencillamente de un servidor web, un poco de tiempo y que cada uno fuera actualizando sus tareas actualizando la herramienta.

Hay algunas gratuitas con un número limitado de usuarios como Tiny pm (http://www.tinypm.com/) que automáticamente iban actualizando el burndown chart y liberaban al Scrum Master del trabajo más "burocrático".

Finalmente decidí probar lo que parecía algo mucho más artesanal y logré que nos dejaran usar una pared en la sala donde realizabamos el daily scrum meeting , pusimos algunas cartulinas, los tipicos carteles de "para hacer, en progreso y hecho" y toda la información se actualizaba a diario, creo que si hubieramos usado alguna herramienta al final me hubiera tocado a mi ir actualizando todo a la vez que el equipo hablaba y lo mejor de todo es que todo el mundo, independientemente de si pertenecía al proyecto o no, veía el grado de avance.

Después del exito de las cartulinas, los post-it, las historias de usuario en tarjetas de cartón me decanto por seguir usando las manualidades en lugar de una herramienta, por lo menos para proyectos donde no haya equipos distribuidos, ¿y vosotros?.

Aquí os muestro algunos ejemplos de nuestro panel, decidimos usar inglés para que las etiquetas no fueran gigantescas ;-) a ver que os parece

taskboard antes de comenzar el sprint 1

etiquetas con nombres y burndown chart

|