Luis Baigorria – Software Developer

Acquire Wisdom and Live with Passion

Archive for septiembre 2011

Scrum – Proceso Ágil de desarrollo de Software

with one comment

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!

Written by Luis Alberto

30/09/2011 at 2:12 AM

Publicado en Artículos, Importante

Informe Final del Proyecto Social CRM

with one comment

Saludos.

A solicitud de algunas personas,  a continuación les comparto la documentación final del proyecto Social CRM.

View this document on Scribd

Que les sea de utilidad.

Hasta pronto!

Written by Luis Alberto

12/09/2011 at 12:37 AM

Publicado en Software Libre, UAGRM

BitBucket: Servicio de alojamiento de proyectos basado en Web

leave a comment »

Saludos.

Hace unas semanas en el curso de diplomado, el docente mostró la importancia de manejar y administrar los proyectos de Software mediante un Sistema de Control de Versiones. La facilidad para compartir el codigo y controlar las diferentes versiones con el equipo de desarrollo es de mucha importancia durante el proceso de desarrollo de Software. Si bien, para algunos era un termino nuevo, todos comenzaron a aprender y a investigar.

No hace mucho que vengo explorando Google Code, la integración que tiene con muchos Sistemas de Control de Versiones hace de éste un lugar ideal para compartir repositorios. Sin embargo, existen otras alternativas más específicas el cual seria interesante ir conociendo y explorando.

BitBucket, es un servicio de alojamiento basado en web, para los proyectos que utilizan el sistema de control de versiones Mercurial. El servicio está escrito en Python.

GitHub es una forja para alojar proyectos utilizando el sistema de control de versiones Git. Está escrito utilizando el framework Ruby on Rails por GitHub, Inc. (anteriormente conocida como Logical Awesome).

Recientemente estoy probando BitBucket. La gran comunidad de usuarios y su amplia lista de repositorios me ha llevado a registrarme y compartir algunos proyectos académicos desarrollados en la universidad:

Mi lista de repositorios

uisocialcrm:

El proyecto “uisocialcrm” trata de un Sistema de Información Web para gestionar envíos de campañas publicitarias para pequeñas y medianas empresas desde un enfoque de Social CRM (Customer Relationship Management), presentado en la Universidad en la materia de Taller de Grado I. El sistema está desarrollado en PHP con MySQL, con librerias Smarty, jquery, ajax, ADOdb, haciendo uso de API’s para publicar contenidos en Twitter por medio del protocolo abierto OAuth. El proyecto no está finalizado en su totalidad, dejo abierto a la comunidad para futuros cambios. Para ingresar al sistema: Usuario: uialberto Password: 12345

Documentación: http://goo.gl/PqjnL

uiecompras:

El proyecto “uiecompras” trata de un pequeño y sencillo ejemplo de una tienda virtual, fué presentado en la Universidad en la materia de Sistemas Distribuidos. El propósito del proyecto fué aprender RMI en Java y Remoting en .NET, de tal manera que el cliente pueda efectuar compras al crédito por medio de objetos remotos implementados en diferentes tecnologías, la instanciación de los objetos sería en .NET utilizando (ActiveX) y en Java (Applets). El sistema está desarrollado en PHP con MySQL, con librerias Smarty y ADOdb. El IDE utilizado es NetBeans! Se ha adjuntado el script de la base de datos. Todos los usuarios del sistema ingresan con el password: 12345.

uicalculadora:

El proyecto “uiCalculadora” es un Evaluador de Expresiones Aritméticas, permite evaluar expresiones aritméticas básicas en una sola línea, respetando prioridad de operadores. Este trabajo fué presentado en la Universidad para la materia de Estructuras de Datos II. Para la resolución del problema se utilizó un árbol de expresión. Desarrollado en el lenguaje Java bajo la plataforma J2SE – IDE Netbeans 6.8.

Que les sea de utilidad.

Hasta pronto.

 

Written by Luis Alberto

04/09/2011 at 11:55 PM

A %d blogueros les gusta esto: