PDF de programación - Gestión de PFCs con Scrum

02/12/2010

Gestión de PFCs con Scrum.

Introducción

Cuando hablamos de usar metodologías agiles para la gestión de proyectos, en lo primero que pensamos es en un proyecto de

desarrollo software, con un equipo de trabajo multidisciplinar .En este artículo vamos a ver un caso diferente, en concreto, como se

pueden aplicar este tipo de metodologías para la gestión de un PFC de desarrollo, en el que el equipo es una única persona. Hasta

hace poco, la gestión de un PFC de desarrollo se realizaba mediante el modelo clásico conocido como “en cascada”. Las distintas

etapas por las que pasa un desarrollo siguiendo esta metodología son las siguientes:

 Análisis y definición de requerimientos: Se definen en detalle los servicios, restricciones y

funcionalidades en forma de especificaciones del sistema. Por lo general, estas especificaciones se mantienen invariables

hasta el final del desarrollo.

 Diseño del sistema y del software: Se diseña el sistema y se definen los requerimientos hardware y software. A nivel

hardware se establece la arquitectura del sistema. A nivel software se identifica y describe las abstracciones del sistema y

sus relaciones.







Implementación y prueba de unidades: Se programa el diseño del software como un conjunto de subsistemas de

software. Se testea cada subsistema para asegurar que se cumplen sus especificaciones.

Integración y prueba del sistema: Se integran y se prueban los subsistemas de software como un sistema completo para

asegurar que se cumplen los requerimientos del software. Después de las pruebas, el sistema software se entrega al

cliente.

Funcionamiento y mantenimiento: Se instala y se pone en funcionamiento el sistema. El mantenimiento implica

corregir errores no descubiertos en las etapas anteriores del ciclo de

vida, mejorar la implementación de las unidades del sistema e implementar nuevas características una vez que se

descubren nuevos requerimientos.

En la siguiente figura se puede ver un esquema del proceso descrito:



Por su parte, las metodologías ágiles reconocen que la indefinición y los cambios son factores

inevitables en la gestión de proyectos y que por tanto es más efectivo refinar los requisitos y diseño de los mismos a lo largo del

desarrollo, introduciendo los cambios de forma evolutiva. Es decir, siguiendo las metodologías agiles, lo que hacemos es sustituir

los ciclos de vida clásicos por un sistema iterativo en el que las mismas actividades se suceden de forma cíclica en periodos cortos

de tiempo. Por ejemplo en scrum el proceso de desarrollo esta formado por las siguientes etapas:

 Análisis del sistema: se obtiene una descripción de la arquitectura del sistema, una visión general del producto, y un

catálogo de requisitos ordenados por prioridad(product backlog).

 Diseño de los requisitos: se describen, detalladamente, las funcionalidades que debe cumplir el producto



Iteraciones de desarrollo (sprint):

o

o

implementación de requisitos, según orden de prioridad (sprint backlog)

pruebas por parte de los usuarios y despliegue. Se reportan incidencias revisando el conjunto de requisitos y

funcionalidades.

*se añade la resolución de incidencias reportadas en iteraciones anteriores



Aplicación

Ya que en cein se ha desarrollado un itinerario formativo de metodologías agiles a lo largo de 2010, nos pareció interesante aplicar

este tipo de metodologías a la gestión de los PFCs que se desarrollaron dentro de los Centros de Excelencia Software, como un

ejercicio de aproximación a las mismas. A través de este artículo, me gustaría mostrar cuales son las prácticas que resultan más

complicadas de llevar a cabo en la implementación de scrum, y las conclusiones que sacamos de ello.

1. Es más difícil, que un proyecto normal, estimar el valor de las historias de usuario. Esto se debe a que no se cuenta con un

equipo multidisciplinar de trabajo. Se cuenta con una única persona, que por lo general tiene conocimientos básicos de la tecnología

o sistemas que va a utilizar para el desarrollo del mismo.

2. No se realiza scrum diario, ya que el equipo es unipersonal. Pero aún así la persona encargada de desarrollar el proyecto debe

ser capaz de preguntarse cada día:







¿Qué he hecho desde ayer?

¿Qué voy a hacer para mañana?

¿He encontrado algún problema que no me deje avanzar con mi trabajo?

Y en función de ello debe ser constante a la hora de actualizar el scrum board, para que este sea lo más realista posible.

3. En nuestro caso, se fusionan la reunión de retrospectiva del sprint, y planificación (siguiente sprint). Además se realiza una

reunión semanal (revisión) que nos ayuda a ver y realizar los cambios necesarios que van surgiendo a lo largo del desarrollo del

proyecto, aportándonos de esta forma gran flexibilidad.

4. Los roles con los que se ha contado, son algo diferentes a los habituales:

 No hay equipo multidisciplinar –> es una única persona.







Product Owner ->tutor de la universidad

Scrum Manager –>tutor en la empresa

*Supervisor-> persona responsable de chequear el trabajo hecho y de ayudar al desarrollador

Por ejemplo, en este caso, son el Product Owner y el Scrum Manager, los que definen los requisitos que debe cumplir el producto,

cuando en realidad sólo el Product Owner es el que se encarga de esta labor.

5. La documentación (memoria del proyecto), consiste principalmente en detallar el proceso scrumque se ha utilizado:

 Objetivos –>Análisis del sistema



Plataforma (Equipos)

 Descripción –> Diseño de los requisitos + Iteraciones de desarrollo

o Definición de las historias de usuarios (funcionalidades de la aplicación)

o Definición de los Sprints:







¿que historias de usuario se han tomado en cada sprint?¿se han acabado o no?

problemas que se han encontrado

feedback (que ha ido mal, que ha ido bien, y que es mejorable)

o Conclusiones

 Bibliografía

Si actualizamos habitualmente el scrum board seremos capaces de obtener toda la información necesaria para la memoria a partir del

mismo. Por lo que el proceso de documentación se simplifica bastante.

Por último, decir que las conclusiones que hemos obtenido mediante el uso de scrum para la gestión de los PFCs, en general, son

buenas, aunque vemos que estas metodologías exigen gran disciplina y metodología de trabajo por parte del desarrollador:

- Ayuda a la organización y distribución del tiempo de la persona encargada de realizar el proyecto. Esto lleva consigo una notable

mejora de la productividad. Pero exige:

- Autocontrol: mayor responsabilidad sobre lo que se hace, en que tiempo, y gusto por el trabajo que se realiza.

- Capacidad de autosuperación: ser capaz de evaluar, analizar y mejorar las soluciones en el tiempo establecido.

- Permite ajustar los tiempos de dedicación para las distintas historias de usuario y tareas a medida que vamos viendo las necesidad

o los cambios a realizar. Pero exige:

- Compromiso: en los plazas de entrega de las sub-aplicaciones

- Calidad: las sub-aplicaciones deben cumplir todos los requisitos establecidos

- Permite ver en que estado se encuentra el proyecto en cada momento, a través del panel de scrum (Scrum Board). Esto aporta

una visión motivadora y retadora del trabajo que se esta haciendo (…o puede tener el efecto contrario). Pero para que la información

que nos da el panel sea real, es necesario ser constante en la actualización del mismo.

- Hace que “desaparezca”, o minimiza, la fase de mantenimiento. Ya que se obtienen pequeñas aplicaciones funcionales que se

pueden implementar de forma independiente. Lo que significa que conseguimos mejorar la calidad del producto y reducir los errores

al mínimo. Esto exige (o sería recomendable):

- Uso pruebas unitarias, para comprobar el correcto funcionamiento de cada una de las sub-aplicaciones. *Esto exige, a su vez, un

buen conocimiento del uso de las mismas.

En resumen, estas metodologías se pueden aplicar a la gestión de distintos tipos de proyectos, pero es necesario que tengamos en

cuenta que no todos los aspectos propios de dichas metodologías se van a poder implementar siguiendo “las normas generales”,

como hemos visto en el caso anterior. Por lo tanto debemos evaluar si es posible ajustar las metodologías a nuestros proyectos o, si

en realidad, no es posible el uso de las mismas.



Blog: http://geeks.ms/blogs/gortigosa

Twitter : http://twitter.com/goreorti

Lectura recomendada: Flexibilidad con Scrum



Expuesta a las 12:59 por Goretti Ortigosa



16/12/2010

Sincronización contactos y calendario Outlook con Windows
Phone 7

Windows Phone 7 sincroniza tanto tus contactos como tu calendario a través de una cuenta compatible con Exchange ActiveSync

(Protocolo de sincronización utilizado por Microsoft).

El problema que se me ha planteado es sincronizar contactos y calendario de Outlook con Windows Phone 7. El gestor de correo

no es compatible con los requerimientos mencionados con anterioridad.

La solución, exportar tus contactos y citas del calendario a Hotmail a través de una cuenta Windows Live ID.

Los pasos a seguir serán los siguientes:

Exportar desde Outlook



En cuanto a contactos se refiere, comenzamos accediendo a Outlook 2003,07 o 10, para realizar la exportación de los

contactos en un archivo de extensión .csv (contactos separados por comas, el más común).

 Accedemos al menú Archivo->Importar y Exportar(2003-2007).







Seguidamente hacemos clic en exportar a un archivo y, a continuación, haga clic en siguiente.

Luego presionamos sobre Valores separados por comas (Windows) y, a continuación, hacemos clic en siguiente.

En la lista de carpetas, haga clic en la carpeta de contactos y, a continuación, haga clic ensiguiente.

 Desplácese hasta la carpeta donde desea guardar los contactos como un archivo. C