Revisión Metodología Septiembre 2011¶

• Revisión Metodología Septiembre 2011
  • 1 Descripcion.
    • 1.1 El enfoque
  • 2 Metodología actual. Particularidades.
  • 3 Propuesta de modificación de la metodología.
    • 3.1 Análisis
    • 3.2 Tickets
    • 3.3 Testing
    • 3.4 Incorporación de evaluaciones
    • 3.5 Reuniones de trabajo con los usuarios y reuniones de seguimiento.
    • 3.6 ¿Donde está el Backlog (y el Sprintlog)?
    • 3.7 ¿Como queda el proceso de planificacion de un sprint?
    • 3.8 Tablón (desastre) de comentarios (pre-funcional).
  • 4 Correccion de errores en producción.
  • 5 Red.es y mantenimiento de documentación.

Dudas actuales a la definición planteada:

# Duración del ciclo #
Parece que nos decantamos por sprint de 3 semanas + 1. (Osea 4 semanas)

# Como hacer para la corrección de errores que esta en producción #
Parece que nos decantamos por hacer una versión una versión previa al fin del sprint, con los errores corregidos, y alguna nueva funcionalidad.
Es decir, no abrir un branch basándonos en la versión en producción y corregir sobre ella. 

1 Descripcion.¶

Este documento supone una revision de la metodologia utilizada para GONG 2.X.

El modo de operar que se propone se basa en: Borrar, y ser sintéticos. Es algo que tenemos que leer, comprender, y acordar (en primer lugar) nosotros mismos. Asi es que: no nos contemos rollos que sabemos.

1.1 El enfoque¶

La filosofia de esta revision se basa en:

1. Recoger lo que hacemos. Es decir: ser muy conservadores en las propuestas respecto a procesos (es siempre lo mas complejo a nivel organizativo). Haz lo que funciona. Recoge lo que haces que te gusta. Y ve cambiando las cosas que no te funcionan.
2. Asegurar 2 elementos claves:
   • Relación con los usuarios. Intensificar y mejorar comunicación, comprensión, implicación.
   • Producir software de calidad. Como solución adecuada a la necesidad (remitirse al punto anterior) y como software robusto.

2 Metodología actual. Particularidades.¶

Este documento supone una revision de la metodologia utilizada para GONG 2.x. Es en esencia la misma con la que hemos estado trabajando:

Metodología de desarrollo

Y que esta mas extensamente recogida en la oferta presentada a Red.es y de la que se adjunta los epigrafes que hacen referencia a la misma (Metodologia de analisis y Metodologia de Desarrollo, Desarrollo evolutivo/correctivo). NOTA: Estos documentos suponen una actualización de la metodología actual, pero sin ninguna concrecion que no vaya a ser recogida en este documento.

Respecto a una metodologia scrum:

¿Que tiene de particular nuestra metodología?

Lo particular se da en nuestro usuario, y en los espacios y las formas para interactuar con el. No tenemos product owner. Por lo tanto no participa directamente de la planificación (planificación de sprint). En cambio tenemos un grupo de usuario validadores de la herramiento, y nos relacionamos con ellos a través de:

• Acompañemiento. Percepción y trato cercano. Procesamos necesidades, para las que ofrecemos soluciones en otro ámbito.
• Reuniones de seguimiento. Espacio diverso y flexible donde se sincronizan visiones, se plantean propuestas, se da un visión general.

Pese a las muchas bondades de nuestro modelo. ¿Cuales son las limitaciones y problemas?

• Distancias con el usuario: falta de dirección del desarrollo por los usuario, solución inventada y propuesta por los técnicos, falta de un visión general del proceso.
• Y en el sentido inverso (y al no tener testing) el técnico no sabe como esta la aplicación, o como la percibe.

NOTA: No se entra en mas detalle, de las bondades y problemas para no alargar.

3 Propuesta de modificación de la metodología.¶

La base de la propuesta es integrar mejor los diferentes momentos del ciclo de desarrollo. Para esto la idea es aclarar y definir los formatos y las herramientas/documentos que se van a utilizar a lo largo del ciclo de trabajo. Aunque quede algo mas engorroso, la estandarizacion está pensada para permitir el seguimiento externo (usuario o red.es), y por aumentar la incorporacion de su vision a la solución. El siguiente grafico recoge los documentos mas importantes:

IMPORTANTE: Aunque el gráfico incluye un listado de historias de usuario no supone ninguna documentación adicional. Los propios tickets recogerán las historias de usuario. En este momento no se ve importante introducir un nivel mas de documentacion con las historias de usuario.

3.1 Análisis¶

Documentar y formatear adecuadamente todo el proceso de análisis. Hacer que se pueda dar seguimiento desde arriba a abajo, desde las funcionalidades pendientes a los tickets. Esto implica:

• Formatear el listado de funcionaldiades. Formato funcionalidades pendientes
• Formatear las herramientas de analisis y relacionarlas con las funcionalidades.
  • Formatear cuestionarios (cabecera que las vincule con la funcionalidad y vinculo aa documento desde la propia funcionalidad). Formato funcionalidades pendientes
  • Formatear documentos de análisis (cabecera que las vincule con la funcionalidad y vinculo aa documento desde la propia funcionalidad). Formato documentos de analisis

3.2 Tickets¶

A nivel de la gestion de los tickets o incidencias: Formatear y tipificar los tickets. Hacer que se pueda dar seguimiento de abajo a arriba al proceso de desarrollo, desde los tickets a las funcionalidades que están asociadas. Esto implica:

• Definir un formato para los tickets. Formato tickets
• Tipificar los tickets en (puede haber subdivisiones a esta tipificacion):
  • Tareas. Historias de usuario.
  • Correcciones ó Mejoras. Historias de usuario.
  • Errores.
• Aumentar y establecer una regla para el flujo de estados de los mismos:
  • Borrador
  • Definido.
  • Dimensionado.
  • Planificado (esta en una version).
  • En proceso.
  • Realizado.
  • Revisado.
  • Cerrado.

3.3 Testing¶

Se incorpora BDD o una modificacion de BDD.

NOTA: Previsiblemente se monta solo la capa mas alta del testintg: implementación de los tests de comportamiento (via cucumber)

Metodologia de Testing

3.4 Incorporación de evaluaciones¶

• Se crea un checklist de los usuarios para el final de cada sprint. Formato checklist de versión para usuarios
  • Checklist a nivel de tickets.
  • Checklist a nivel de funcionalidades (son mas importantes).

• Evaluaciones general de sprint los técnicos. Formato evaluación de los técnicos

3.5 Reuniones de trabajo con los usuarios y reuniones de seguimiento.¶

• Listado de reuniones de trabajo o entrevistas. Formato reuniones de trabajo
• Actas de las reuniones de seguimiento. Formato actas reuniones de seguimiento

3.6 ¿Donde está el Backlog (y el Sprintlog)?¶

El backlog esta compuesto de 2 partes:

• El listado de funcionalidades pendientes. Alto nivel.
• El listado de tickets pendientes. Bajo nivel.

El SprintLog se verá en el roadmap de cada version. Contendrá los tickets correspondientes y las funcionalides de la versión.

3.7 ¿Como queda el proceso de planificacion de un sprint?¶

2 pasos:

1. Recoger las correcciones y mejoras que se van a incluir y dimensionarlos. Estos se encuentran en forma de tickets.
2. El tiempo que sobra se incluye nuevas funcionalidades.

3.8 Tablón (desastre) de comentarios (pre-funcional).¶

Existen comentarios, posibles funcionalidades, posibles mejoras, posibles errores... etc que se producen en diferentes momentos y procesos del ciclo de trabajo.

La idea es crear un tablon de comentarios (prefuncional), con un formato minimo, que permite recoger estos "comentarios". La principal fuente de este tablón serán:

• Los comentarios de la evaluaciones.
• Los comentarioes de las sesiones de trabajo con las ONGs (acompañamiento)

Formato tablon comentarios o anotaciones

Los comentarios serán procesados (se incuiran en funcionalidades, correcciones o mejoras) y borrados del tablon. Previsiblemente el momento para esto serán las reuniones de planifiación de sprint.

4 Correccion de errores en producción.¶

El grafico presentado recoge un proceso diferente para los ciclos ordinarios del sprint y para la corrección de errores. El planteamiento actual implica que NO existirán tickets de tipo error en los ciclos del sprint, dado que los errores tienen que ser tratados como pequeños ciclos internos al sprint. Estas versiones al ser correcciones no supondrán subir la numeración de la versión si no incorporar una numero mas a la versión en producción.

Como propuesta y dependiendo del dialogo con Red.se se podría plantear una frecuencia semanal para las versiones de corrección de errores. Esto quiere decir que dentro de un sprint de 5 semanas pueden llegar a salir hasta 4 versiones previas de corrección de errores con la numeración de la versión en producción mas un numero mas.

5 Red.es y mantenimiento de documentación.¶

Aparte de lo anteriormente comentado, es interesante incluir en el proceso el matenimiento la documentación general de la aplicacion.

Para este mantenimiento se dedicará un momento en la metodología coincidiendo con la semana de la reunion de seguimiento:

• 4 semanas de sprint.
• 1 semana reunión seguimiento, puesta en producción, actualización de la documentación general.

El listado de la documentacion a manetener es:

• Casos de uso (o historias de usuario, o ambas)
• Manual de usuario.
• Manual de instalación.