Scrum – Gráfico Burndown Charts

Saludos amigos!

En el anterior post  “Scrum Proceso Ágil de Desarrollo de Software”  habíamos presentado una introducción sobre la definición del proceso del modelo Scrum, los artefactos y los roles del modelo, la forma y las características en la que se desarrolla el proceso, lo cual nos sirvió como una introducción sobre lo que trata el modelo en sí, las muchas ventajas que podemos obtener al aplicarlo en nuestros equipos y gran velocidad para desarrollar producto de Software; en menor tiempo, costo y esfuerzo, y sobre todo, de gran satisfacción para el cliente. Así también, sabemos que una de las tareas principales cuando desarrollamos Software es la estimación, sí,  estimar y/o medir el tiempo que vamos a tardar en desarrollar el producto.  Para lograr este objetivo, Scrum propone los siguientes gráficos:

Gráfico Burndown Charts
Gráfico Burndown Charts

Este tipo de gráfico permite realizar diversas simulaciones: ver cómo se aplazan las fechas de entrega si se le añaden requisitos, ver cómo se avanzan si se le quitan requisitos o se añade otro equipo, etc.

Proyectos Ágiles - Sprint Burndown Chart
Proyectos Ágiles - Sprint Burndown Chart

Datos en el gráfico de Burndown

El gráfico se traza para cada sprint. Se estima el tiempo que se puede o quiere tardar en realizar una serie de características. Al comenzar, el primer sprint, no se sabe la velocidad del grupo, realmente, por lo que se puede comenzar sin estimación precisa. Esto se va ajustando con el tiempo.

En principio, se comienza el trabajo, se comienzan a realizar tareas.

Al día siguiente, se hace revisión de las tareas acabadas y se apunta en el gráfico el día anterior y los puntos que se avanzó. El gráfico, al crearlo, se suele trazar una línea que cubre la diagonal de la esquina superior izquierda hasta la esquina inferior derecha. Si los puntos van cayendo sobre la línea, ya sabemos lo que se va a ir tardando en realizar el proyecto.

En caso de que los puntos vayan cayendo en el rectángulo superior, eso será indicio de que hay que eliminar historias. Si se mantiene siempre en el bloque inferior, se pueden agregar más historias.

Saludos mis amigos!

🙂

Scrum – Proceso Ágil de desarrollo de Software

Saludos Amigos!

Muchas veces me he preguntado cuál es el mejor proceso o forma de organizar a nuestro equipo de desarrollo de Software. Púes bien, en esta oportunidad quiero presentarles un nuevo modelo que acabo de conocer. Scrum, una Metodología Ágil de Gestión de Trabajo. Con los conocimiento que voy adquiriendo en clases, cada vez me siento más convencido de la importancia de aplicar esta Metodología Ágil! La simplicidad para explicar y entender el proceso fué uno de los factores por el cuál se ha logrado mi aceptación.

Veamos un poco de que trata el proceso.

El proceso de Scrum

Esta gráfica resumen bastante bien el proceso de Scrum.

Modelo Scrum
Proceso de Desarrollo del modelo Scrum

El Product Backlog

Es la lista de historias de usuario que se van a incluir en el producto. No es necesario que todas las historias estén escritas antes de comenzar un desarrollo, basta con escribir al principio las más importantes, a tener algo con lo que empezar. El product backlog es una lista viva según avanza el proyecto se van incluyendo nuevas historias, esto es parte importante del espiritu de una metodología ágil, no hay que dedicar excesivo tiempo a un análisis inicial desgranando hasta la ultima funcionalidad imaginable del sistema, la idea es empezar pronto con las tareas más importantes, las que si o si tienen que hacerse como parte del producto, y posteriormente a través del feedback que recibamos del cliente y los distintos stakeholders del proyecto ir añadiendo/modificando/eliminando items de esta lista.

El sprint backlog y la planificación de sprint

Una vez que tenemos un product backlog con algunas historias se realiza la planificación del Sprint. En esta planificación tomamos las historias que estimamos se van a poder desarrollar dentro de un Sprint y con estas se construye el Sprint backlog. Cuando pasan al sprint backlog estas historias se subdividen en tareas , si por ejemplo tenemos una historia tipo Presentar informes de estadisticas de uso de la aplicación, la podríamos dividir en varias tareas como:

  • Diseñar y crear tabla en la bd para almacenamiento de estadísticas.
  • Crear clase para acceso a tabla de datos estadísticos.
  • Pintar información de estadísticas en el gui mediante un gráfico de barras
Este es el trabajo “duro” de la planificación de sprint, subdividir las historias en tareas y llevarlas al terreno de lo real, tanto los responsables del producto como los miembros del equipo tienen que salir con las ideas claras respecto a lo que se va a implementar, cuanto más cortas y concisas sean estas tareas mejor para todos.

La Reunión diaria de Scrum

A diario se realiza una reunión de Scrum, el famoso daily scrum. Todo el equipo tiene que participar en esta reunión que no debería durar mucho más de 15 minutos. En esta reunión cada miembro del equipo tiene que responder a 3 preguntas simples:

  • ¿Que hiciste ayer?
  • ¿Que vas ha hacer hoy?
  • ¿Tienes algún impedimento para seguir avanzando en tu tarea?

Una vez terminada esta reunión se intentan resolver los impedimentos que se han encontrado y se actualiza la gráfica de burndown con el avance que se haya producido. Una cosa muy importante es que el tiempo no se mide en cuando llevamos trabajado, que en realidad es irrelevante, sino en cuanto falta para terminar que es lo que realmente importa. Con esto tenemos una re estimación diaria que nos permite saber en cada momento cual es el estado del proyecto, lo bueno de esto es que con datos actualizados se pueden tomar decisiones y corregir situaciones y problemas desde el momento en el que se presentan. La idea es no vivir en un engaño durante, por ejemplo, los dos primeros meses del proyecto y pegarse la bofetada justo al final, luego vienen las prisas, los sudores fríos y las llamadas al telepizza a las 10 de la noche en la oficina, y en muchas ocasiones por temas que se podian haber evitado de contar con la información necesaria en su momento.

Fin del Sprint: Demo y Retrospectiva

Una vez terminado un sprint llega el día fatídico de la demo de sprint, ese día es el que toca enseñar a todos lo interesados en el proyecto el avance que se ha producido, y claro para poder enseñárselo a alguien hay que tener un producto terminado al final de cada sprint. El resultado de cada sprint debe ser un software funcional, que sólo incluya las historias acordadas para el sprint, pero que funcione!, es decir, no vale aquello de: “si, si la historia X esta terminada pero hasta que no tengamos también la Y y la Z no te la puedo enseñar”. El objetivo es ir construyendo versiones perfectamente funcionales en las que poco a poco se vayan añadiendo características, pero es fundamental que estas versiones sean funcionales para poder enseñarlas y recibir el feedback de los interesados, que en definitiva es lo que nos va a guiar para los sucesivos pasos que se den en el proyecto.

Después de sudar la gota gorda en la demo viene el momento de la utocritica, la retrospectiva del sprint, en esta reunión se tratan de poner sobre la mesa todas aquellas cosas que no han funcionado durante el sprint, el objetivo es que todo el mundo de su visión y para el siguiente sprint se intenten resolver estos problemas, algunos ejemplos:

  • Planificamos mal porque no tenemos en cuenta el tiempo que se lleva hacer la documentación.
  • Hay que revisar la política de control de versiones porque perdemos muchos tiempo resolviendo conflictos.
  • Tenemos que preparar mejor las demos para que se entienda el funcionamiento del Software.

La idea es que estos problemas no se perpetúen y se les trate de poner remedio para ir mejorando continuamente nuestra forma de trabajo.

Una vez terminada la retrospectiva ya os lo podéis imaginar, pues a volver otra vez desde el principio!, se realiza la planificación del siguiente sprint y así sucesivamente mientras los clientes paguen :P.

Roles Principales

Product Owner: Es típicamente alguien que desempeña un rol en Marketing o un “key user” en desarrollos internos. S encarga de priorizar el Product Backlog.

Scrum Master: Es el responsable de asegurar que el Scrum Team se conduzca bajo los valores y prácticas de Scrum. También proteje al equipo asegurando que no se sobre compromentan en lo que puedan llevar a cabo durante unSprint. Además facilita el Dialy Scrum y se encarga de resolver los problemas que son planteados por el por el equipo durante la reunión. El rol de Scrum Master es típicamente cubierto por un Product Manager o un Technical Team Leader pero puede ser cualquiera.

Scrum Team: No incluye ninguno de los roles tradicionales de la ingeniería del software como programadores, diseñadores, testers o arquitectos. Cada integrante trabaja en conjunto para completar las tareas que fueron comprometidas en conjunto para ser desarrolladas durante el Sprint. El equipo desarrolla una profunda forma de camaradería y un sentimiento de “estamos todos juntos en ésto”. El número típico de integrantes de un Scrum Team va desde 6 a 10 personas, pero esta cantidad puede escalarse haciendo lo que se llama “Scrums de Scrums”.

Te invito a que puedas participar y aportar con tus conocimientos a la Comunidad Scrum Bolivia.

Saludos y hasta pronto!

Integrar TortoiseSVN con repositorio de Google Code

Saludos amigos.

Mediante este post quiero mostrar como podemos integrar el cliente subversión TortoiseSVN con un repositorio creado en Google Code, así poder establecer un equipo de trabajo online y convertirnos en gestores de proyectos* :), eso sí, con mucho trabajo y esfuerzo.

¿Qué es Google Code?

Es el espacio donde Google comparte con todos los usuarios parte del código de programación que se utiliza dentro de la compañía, una plataforma gratuita para desarrolladores interesados en el código abierto, permitiendo alojar proyectos de Open Source y compartirlos con nuestra comunidad.

Nota: Todos los archivos que subas y compartas deben ser OPEN SOURCE, de código abierto, caso contrario, si descubren que alojaste un archivo privativo (Mp3’s, .wma, .swf, etc) podrián cerrar tu cuenta.

Además, debes conocer que Google ofrece diferentes servicios de alojamiento de archivos, de los cuales puedes utilizar en la realización de tus proyectos, como es el caso de: Google Docs, Picasa Web, Google Ajax y más. Con todo esto de computación en las nubes o Cloud Computing y los servicios de alojamientos de ficheros gratuitos no está mal sacar provecho de éstos, eso sí, tomando muy en cuenta el contenido de la información que compartimos.

Bien comencemos con el tutorial.

Lo que necesitamos

Para la realización del tutorial necesitamos lo siguiente:

-Instalador de TortoiseSVN que puedes descargarlo de la página principal de TortoiseSVN

– Cuenta de correo en Gmail.

1. Crear el proyecto en Google Code Hosting

– Nos dirigimos a la siguiente página  code.google.com/hosting , iniciamos sesión con nuestra cuenta de correo electrónico.

Iniciamos Sesión en Google Code

– Creamos el Proyecto pulsando en el enlace Create a new Project lo que vendría a ser nuestro repositorio e ingresamos los datos que nos solicitan:

– Project name: Un nombre válido y disponible.
Projectt summary: Un breve resumen de lo que trata el proyecto.
– Projectt description: Realizamos una pequeña descripción del proyecto.
Version Control System: Para el Sistema de Control de Versiones seleccionamos: Subversion
-Source Code License:
 Seleccionamos el que mejor se ajuste a nuestra necesidades. (GNU GPL v3)
Project Label’s: Agregamos las etiquetas que hagan referencia a nuestro proyecto.

Tienda Virtual en Google Code

– Ingresamos a la pestaña Source para obtener la dirección URL de nuestro proyecto y así poder conectarnos mediante TortoiseSVN. Copiamos los datos de recuadro 3. Generamos el password (recuadro 4) para conectarnos al proyecto (repositorio), esta clave es única para cada usuario participante del proyecto.

Proyecto Google Code Tienda Virtual

– Generamos el password para conectarnos por TortoiseSVN. Este código es único para cada usuario del proyecto.

Generar Password del Proyecto

Con esto ya tenemos listo nuestro repositorio para conectarnos por medio de TortoiseSVN y poder hacer el control de versiones. Continuemos.

2. Instalamos TortoiseSVN 1.6

– Una vez descargado TortoiseSVN procedemos a realizar la instalación, en mi caso ocupe la versión TortoiseSVN-1.6.15.21042-x64-svn-1.6.16. 

TortoiseSVN 1.6

– Una vez instalado nos pedirá reiniciar la máquina, pulsamos Ok. Luego procedemos a crear el directorio en el cual descargaremos nuestro repositorio de Google Code. En mi caso, la carpeta se llama: ui-tiendavirtual. Damos Click derecho y veremos una serie de opciones nuevas en el menú despegable. Seleccionamos: TortoiseSVN->Import.

TortoiseSVN Import

– Nos aparecerá el siguiente cuadro de diálogo donde vamos a necesitar copiar el URL generado por el Google Code Repository haciendo referencia a nuestro proyecto, si le da un mensaje para recordar nuestro cambio, pulsamos Ok.

TortoiseSVN 1.6

– Nos pide autenticación. Entonces nuestro USERNAME es el usuario que usamos en nuestra cuenta de GMAIL, y el PASWORD es el que nos asignaron anteriormente (el que generamos) para el proyecto. Marcamos SAVE AUTHENTICATION, ya que en cada proceso de importación nos los pedirá.

Import TortoiseSVN

– Se inicia el proceso sincronización e importación de nuestro repositorio.

TortoiseSVN Import

– El siguiente paso es realizar el proceso CkeckOut para obtener los archivos del repositorio, según nuestra cuenta de usuario y password asignado para el acceso al proyecto. Pulsamos click derecho sobre la misma carpeta que realizamos el proceso de sincronización e importación como se muestra en la imagen:

TortoiseSVN CkeckOut

– Verificamos que los datos sean los correctos; tenemos que revisar la URL del repositorio (dada por Google Code Repository) y el directorio CheckOut (donde se almacena internamente el proyecto).

CheckOut TortoiseSVN

– Se inicia el proceso de CkeckOut. Una vez finalizado el proceso veremos que se marca con un símbolo de Ok y de color verde, además, crea una estructrua de directorio, esto indica que nuestra carpeta local se encuentra sincronizada y actualizada con Google Code Repository.

TortoiseSVN CheckOut

Estructura de directorio después del CheckOut con TortoiseSVN

– A partir de ahora todo documento que guardemos dentro de esta carpeta se podrá subir al repositorio y trabajarlo en paralelo por cada usuario que pertenece al proyecto y tiene privilegios de hacer cambios a los documentos. Como vemos a continuación, yo tengo un documento en el cual estoy trabajado en Enterprise Architect 7.5.

Diagrama Tienda Virtual

– Con SVN Commit podemos subir los cambios efectuados localmente al repositorio actualizando el archivo en el repositorio (Google Code Repository) con los datos de quien hizo el cambio.

TortoiseSVN Commit

– Con SVN Update podemos bajar los cambios efectuados en el repositorio.

SVN Update

Como observamos a continuación ya tenemos el archivo que estamos trabajando localmente en nuestro Google Code Repository. A partir de ahora, solo trabajamos con los procesos SVN Commit (Subir los cambios) y SVN Update (Actualizar el repositorio).

Tienda Virtual

Espero el tutorial sea de mucha utilidad.

Saludos.

Wayra:Un futuro Silicon Valley para Latinoamérica

Navegando por mi Google Reader me encuentro con este innovador proyecto, muy interesante y que apunta en grande.

“Un viento de innovación sopla en Latinoamérica”

En esta oportunidad Telefónica Latinoamérica ha decido apostar por el talento y la innovación, apoyando a los emprendedores latinoaméricanos.

Wayra, que significa “viento” en quechua. Este proyecto pretende ayudar a los emprendedores, dotándolos de tecnología, herramientas y financiación, para que desarrollen sus proyectos TIC sobre las plataformas de la propia Telefónica y en su tierra natal.

 

José María Álvarez-Pallete, presidente de Telefónica Latinoamérica, lo define como el embrión de un futuro Silicon Valley para Latinoamérica y que estaría basado en tres pilares:

  1. Detección del talento a través de la Red Innova y la Campus Party, de manera que se puedan identificar aquellas personas que tienen una buena idea que puede desarrollarse en el ámbito de las TIC sin tener que marcharse de su país y puedan, por tanto, generar riqueza en su región.
  2. Prometea que consistirá en unos espacios de innovación, algo así como una tecnoincubadora en la que las personas, con ideas y potencial, puedan interactuar y desarrollarse a través de los medios disponibles: tecnología proporcionada por Telefónica combinada con coaching y mentoring para que estos emprendedores aprendan a crear una startup, a crear un plan de negocio o gestionar una empresa. Además, durante un año, Telefónica financiará su idea.
  3. Amerigo, un fondo de capital-desarrollo para que las mejores compañías crezcan para que puedan exportar sus ideas y abrir nuevos mercados sin tener que marcharse.

Todo esto es Wayra, un proyecto muy interesante y una gran oportunidad para que todas esas grandes ideas que hay en Latinoamérica se materialicen en forma de empresas que fomenten la innovación y el desarrollo tecnológico.

Fuente: AL1040