Planning Poker Card… Juguemos a estimar!

En el desarrollo de software, con un equipo medio-grande, muchas veces la estimación de tareas para producir un producto tecnológico, puede llegar a ser confuso y agotador (obviamente también dependiendo de las historias de producto o alcances del mismo).

Para ésto, si se está trabajando con alguna metodología ágil (XP,Scrum, o alguna otra), es posible hacer de éste importante paso algo más entretenido, participativo y quizá hasta motivante con tu equipo de desarrollo; el uso de Planning Poker Cards. (La verdad nunca me he atrevido a realizar planning card acompañado de metodologías predictivas, sólo porque la naturaleza de las mismas prefieren una carta gantt o un pert… pero ustedes saben, aqui solo hay que inventar, comprobar y adaptar nuevas formas… las cosas no siempre funcionan bien como están establecidas en un libro, también hay que probar, para poder recomprobar uno mismo, y asi tener una opinión mas válida, apoyada por la investigación de otros y las propias 🙂 IMHO).

El planning poker card es una técnica de estimación de tiempo, para un desarrollo de software, en breves palabras. Aquí, cada integrante es dotado de un pequeño mazo de cartas (Basadas en la secuencia de Fibonacci u otras progresiones aritméticas) que contienen ciertas ilustraciones como:

Fibonacci:

0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 + ? (cuando no saben como estimarla) + taza de café (para marcar una pausa).Éstas dos últimas opcionales, pero recomendadas.

Comercial:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100+ ? (cuando no saben como estimarla) + taza de café (para marcar una pausa).

Como “jugar”:

– En una reunión de equipo, el participante más experimentado del mismo, describirá parte de la historia que se debe cumplir para desarrollar el software, mientras el Gestor o Coach está atento de registrar y moderar el intercambio de ideas (para controlar el tiempo del juego) y de las conclusiones finales para compenzar con la estimación de tiempos para cada actividad (reflejada en un futuro en su tablero X).

– Una vez explicada la historia o parte que se debe cumplir, cada integrante del equipo elige alguna carta de su mazo, con el tiempo (Dias, puntos de historia, tiempos ideales, tiempos castigados, etc) o imagen que estimó , pero boca abajo!

– Una vez que todos los integrantes ya han cumplido con esta labor, voltean de manera simultánea la carta escogida, se comparten los resultados y el coach, da tiempo para justificar y discutir el tiempo (cantidad y unidad) definitivo de cada historia.

– Se llega a concenso finalmente, y se repite el proceso hasta recorrer la totalidad de historias de cada liberación (para no desmotivar, yo lo hago en base a cada entrega, así “cuido” que éste entretenido método no se ensucie de rutina o algo asi).

Los beneficios de ésta práctica además de motivación, evita la confunción de tiempos estimados (ya que todos participaron del proceso) y en cierto porcentaje, evita los retrazos en el desarrollo de cada actividad, ya que se queda con cierta responsabilidad de terminar en el tiempo que se estimó.

Existen diversas aplicaciones para hacer planning poker card (lo he probado con varios teléfonos móviles, pero la desventaja más fuerte es que no todos los integrantes podran adquirir un Iphone o un móvil con Android). Para jugar quizá lo clásico… Cartas Físicas :).

Ahora subiré un mazo que encontré hace un tiempo por la web: Cartas de Planning Poker

Trabajo en real equipo…

Trabajar con un equipo multidisciplinario, es placer y fortuna de algunos. Siempre conocer de todo un poco, en la informática, es conveniente, pero siempre habrá, mínimo, un área que despierte tu interés y es lógico seguirle los pasos desde cerca, para lograr una fortaleza o competencia y así poder sobrevivir con algo más de éxito en éste mercado que puede llegar a ser cruel.

Bueno, si logras tener una especialidad, no importando mucho si está o no certificada (aunque, en la teoría, una competencia no está completa si no está certificada por un tercero (institución educacional, muchas veces)), ser parte de un equipo con similares características (especialistas), podría llegar a ser una muy buena carta, para desarrollarse en conjunto.

Pues bien, imaginemos que existe un grupo de ingenieros y técnicos en informática, con ciertas especialidades, muy competentes para trabajar en equipo (no grupo) para un proyecto de desarrollo informático, bajo una metedología propia basada en kanban. Para lograrlo, separan el proyecto en varias fases (Requerimientos (R), Análisis (A), Diseño (D), Programación (P), Validación (V), Pruebas (T) y Producción (D) ). Expertos hay para cada una de las áreas mencionadas  y mantienen una muy buena relación, como equipo con el cliente.

Entonces, comienza cada uno a realizar sus partes, identificando sus deberes y a exponer todo su talento y conocimiento.  Comienza el equipo R, luego A y D, consecutivamente y sin nigún problema, dejando como resultado, todos los antecedentes listos para que el equipo P haga lo suyo, pero se topan con varios inconvenientes (no sólo acerca de programación). Imaginando que V, T y D ya han preparado su terreno, para hacer lo que les compete, ¿Qué debieran hacer para lograr mantener el proyecto éxitoso?

Considerando que son expertos en sus áreas, sus tareas desarrolladas están más que revisadas y comprobadas (sería delíto perder tiempo en revisarlas una vez más ), siento que ha dos maneras para lograr que el proyecto siga dentro de los límites del éxito… O los ponemos a desarrollar, con el fin de apurar la causa… o bien, le decimos que “despejen” inconvenientes que no tengan relación en la programación. (ambas propuestas, considerando los equipos R, A y D, también en la colaboración).

La primera opción, quizá sea la mejor… pero, ¿todos están al mismo nivel de desarrollo?… o quizá, ¿retrasarán el proceso si interceden?; Obviamente, el equipo que éste en mejores condiciones en programación, debería ayudar, pero ¿y el resto?

Sin pensarlo mucho, está claro que deben ir tras los inconvenientes no técnicos (por decirle de alguna manera), para lograr un proyecto en éxito y mantenerlos a todos activos y compartiendo más experiencia colectiva, afiatando mucho más al equipo completo.

Eso es crecer como equipo! muchas veces los inconvenientes te desmoronan la proyección, pero veamos lo positivo que deja si se sabe aprovechar!

Salu2!

 

Estaré equivocado? GNU/Linux y Agilidad de la mano?

Más de alguna vez me he quedado pensando largo tiempo en ello… el desarrollo en GNU/Linux debiera funcionar bajo atisbos del manisfesto ágil de desarrollo de software?

Pues bien, una vez tuve la oportunidad de ir a un encuentro Linux en Chile, ciudad de Talca, y además de los contenidos técnicos que caracterizan a éste tipo de encuentros, nunca he visto una ponencia sobre agilidad + GNU/Linux. Cada año, aunque no pueda asistir, reviso los expositores del encuentro, y junto con ello, cada una de sus fortalezas, y jamás he visto la palabra Scrum, Kanban,Agile, DSDM, Crystal, Extremme Programming en ni siquiera una de todas las descripciones, y pues bien ahi nace mi duda; ¿Los desarrollos directos de GNU/Linux (no desarrollos usando esta plataforma para privados), utilizan algún tipo de metodología o marco referencia de trabajo para lograr una entrega significativa y de real aporte a un proyecto OpenSource?

Me llama mucho la atención, y no me imagino que un grupo de asiduos desarrolladores usen un cascada o alguna metedología predictiva como PMI, o que logren niveles de madurez (CMMI – tema complicado- ) ¿Alguien podría orientarme y/o liberarme de la duda?

Salu2!

 

Cuando el Sprint Cero muestra su importancia…

¿Qué era lo que queríamos evitar de la Cascada? Entre otras cosas, queremos evitar los momentos de transición! Se pierde mucha información cuando se la transfiere a otra persona.

Otra cosa que queremos evitar es crear un orden estricto en las cosas, porque lleva a una flexibilidad limitada. Igualmente, el Sprint Cero es una práctica bastante común, y parecería que ocurre antes que todas las otras cosas, ¿no?. Entonces, ¿cómo hacemos un Sprint de la manera más util?

Principios:

•El Sprint Cero no debería durar más de 1 semana.

•Gastar la mitad del tiempo del Sprint Cero en capacitación y conformación del equipo alcanza.

 •Hacer más de lo estrictamente necesario para empezar el primer sprint es demasiado.

•El resultado del Sprint Cero es empezar directamente con el Sprint Uno.

 ¡SI! Es importante mantener un ritmo parejo de duración en los sprints. Pero el Sprint Cero es la excepción. Mientras más corto, mejor. Sería completamente aceptable empezar un Sprint Cero el miércoles y comenzar el Sprint Uno el próximo lunes.

¡SI! El entregable de cada sprint es código con calidad productiva. Pero el Sprint Cero es la excepción. El Sprint Cero se usa para conocernos. Conformar un equipo, antes de empezar a construir software. Obviamente que no se puede conformar un equipo en 5 días, pero es un buen inicio. Este inicio puede hacer la diferencia entre llegar a ser un Equipo o ser un grupo de personas.

¡SI! Debemos tener la meta final en mente. Pero no pospongamos el inicio hasta comprender el final. Inspección y Adaptación. Sea que sea lo que hagamos, la meta va a cambiar por todo lo que aprenderemos en el camino. Puede ser muy importante tener un Sprint Cero efectivo. La mayoría de los involucrados seguramente habrán leído algo de Scrum, y lo que recordarán es que Scrum es Ágil y que los equipos autogestionados enfocados entregan software. Tener un Sprint Cero de 3 semanas va a matar el entusiasmo y la esperanza en cualquier principio de Scrum o de Ágil. Ágil establece que se valora a los individuos y sus interacciones por sobre los procesos y las herramientas. ¡Es verdad! Podemos inventar cualquier tipo de proceso con cualquier cantidad de herramientas, y sin las personas correctas interactuando, el proceso nunca funcionará y las herramientas no servirán de nada. De la misma forma, un grupo de individuos no es la fórmula ganadora; necesitamos crear un Equipo de todos estos campeones y allí está la diferencia. Debemos hacernos tiempo para conformar un equipo en el Sprint Cero, porque más tarde corremos el riesgo de no tener tiempo. La arquitectura y las herramientas son bienes importantes para los equipos que entregan software de manera exitosa. Sin embargo, es más importante construir software y aprender de ello. Recordemos que si no podemos imaginar la arquitectura en 2 días, la cosa no va a cambiar mucho después de 2 semanas. Mientras desarrollamos y exploramos las historias, va a emerger la mejor arquitectura posible.

Opiniones!

Salu2!

¿Quien dijo que scrum solo sirve para el desarrollo de software?

Si bien en cierto esta metodología nacio para resolver el problema que se puedan tener en el desarrollo de software, es necesario mencionar que no es una metodología excluyente a otro tipo de proyectos… Sirve para todo!!!

Scrum es la solución a los problemas de requerimientos y pérdida de recursos del desarrollo de software, ya que por naturaleza son proyectos de alto riesgo y scrum tiene como regla de oro que los requerimientos son cambiantes!

Asi que atrevamonos a realizar los nuevos proyectos bajo ésta excelente y comoda metodología de trabajo en proyecto.

Pero primero a leer como hacerlo 😉

1.- Scrum y Xp desde las tricheras (http://www.mediafire.com/?tr8nwaq08s3ro1o)

2.- Flexibilidad con Scrum (http://www.mediafire.com/?x21zj1eel9q6zl5)

Salu2!

PMBoK… no puede faltar en su biblioteca

Buenos dias, estimados… Hoy he querido compartir con ustedes un librito bastante escaso, el cual siempre se sugiere leer cuando estas trabajando con proyectos, y más aun, si formas parte importante de ellos.

Es por este motivo, que dejo a su disposición el ejemplar del PMBoK Cuarta edición en Español, compendio de las buenas practicas en lo que respecta a proyectos, impulsado por PMI (Project Managemente Institute).

Link: http://www.mediafire.com/?lmchm4cat498scg

Salu2!

Programación y productividad… cuando no pueden conversar

Algunas veces, es complicado mezclar ambos términos ya que me ha tocado lidear con afanosos desarrolladores, los cuales intentan realizar todo a mano y está más que claro que es una pérdida de tiempo.

En mi experiencia, siempre me encuentro con que algunos proyectos casi siempre son “para ayer”, y que por causas de fluctuaciones externas aleatorias, a veces se deben dejar stand by por al menos un tiempo, y eres presionado a cumplir plazos que no son plenamente decentes. Lo cual lo único que logran es sentar a desarrolladores a solamente programar, y es sabido que eso solo apuntará al fracaso.

No todo en la vida es desarrollar y dejar unas cuantas sonrisas en la cara del cliente, pues… ¿Se ha considerado un pleno análisis aunque este sea breve?,¿Se ha considerado mantención en el sistema?, o algo más grave aún… ¿Y si alguien del equipo se va o se enferma por un tiempo extenso?

Son preguntas que muchas veces debes hacerte si tienes la labor de coordinar un equipo de desarrollo de software.

El éxito en un desarrollo de software dependerá del equipo entero. Algunas veces cuando tienes desarrolladores que se “casan” con un lenguaje de programación determinado y están obligados a cambiar de plataforma, comienza a aparecer la tan nombrada “resistencia al cambio” y lo peor de todo es que es dentro de tu propio equipo (pensando que casi siempre este fenómeno se da en la parte del cliente!). Muchas veces te envian/contratan un desarrollador artesanal y definitivamente es lo peor.

Aunque evangelices sobre la productividad del desarrollo de software, con frecuencia sientes que hablas al viento. Concuerdo que todos, como desarrolladores o más bien dicho como programadores, pasamos por una etapa de artesano, ya que nada puede describir lo exitante que es ver el propio resultado de la mano del hombre y la máquina trabajando en conjunto pero… ¿Es esto productivo para el desarrollo de una aplicación o sistema que esta contra el tiempo?

Definitivamente no. Es por esto que existen lineamientos que seguir y herramientas que pueden hacer el trabajo “artesanal” de una manera ágil, y con menos probabilidad de errores. Siendo así… ¿Por qué la resistencia al cambio hacia lo productivo, siendo que es una tremenda ventaja para que el software tenga éxito?

Pues tengo mis teorias al respecto. Considero que la mayoria de los desarrolladores quieren ser idolatrados por sus logros independientes o sus capacidades de “hacerlo a mano” logrando ser reconocidos como “desarrolladores héroes” pero… creo que eso no hacen bien para la vida de un proyecto informático, ya que este es un resultado de un trabajo en equipo, en el cual si se triunfa o se fracasa (aunque esta palabra no la considero dentro de mi léxico) se le debe atribuir al equipo completo.

Se debe ser productivo y completar a cabalidad los requisitos que son pedidos por los clientes, pero recordemos que no somos magos.

Opiniones?

Salu2!