FDV Metodología

Trabajamos con proyectos tanto Fix Price como Time & Materials. La planificación de todo el proyecto puede llegar a ser diferente en cada caso, pero los siguientes documentos serán siempre utilizados:

1) NDA que garantice el compromiso con mantener la confidencialidad sobre código, clientes y personal involucrado en el proyecto.

2) Propuesta o Contrato según la formalidad del acuerdo, siempre aclarando responsabilidades, calendario, alcance, precio, plan de pagos junto con la tecnología y la metodología a utilizar.

3) Plan de Comunicaciones del proyecto en donde se defina explícitamente los roles y las responsabilidades, inclusive comerciales (account manager) y de pagos por parte del cliente.

Fix Price
Los proyectos que se trabajan dentro de esta modalidad deberán siempre contemplar un riesgo funcional, ya que inevitablemente y por mas que se defina con anterioridad el proceso de administración de cambios, existen riesgos inherentes a la construcción de software.

Todos los proyectos contratados en esta modalidad deberán tener horas para los roles de coordinación, definiciones funcionales y control de la calidad además del desarrollo. FDV no trabaja con equipos incompletos en esta modalidad.

El plan de aprobaciones debe estar definido a la hora de firmar el contrato o al menos validado entre las partes y escrito parcialmente en el contrato/propuesta.

Time & Materials
FDV garantiza a través de procesos definidos y claramente documentados los mecanismos para dar visibilidad al cliente de la utilización del tiempo de parte del equipo.

El cliente recibe un informe diario con las asignaciones y la utilización de las horas por parte de su equipo de trabajo garantizando la transparencia y el compromiso con el correcto uso de cada minuto invertido por parte del cliente.

Ejecución del proyecto
Durante la ejecución el proyecto se llevará adelante como cualquier otro proyecto Scrum remoto. El equipo de trabajo acordará el horario para las Daily Meetings y las de planificación de Sprints. Si es necesario también se pueden acordar reuniones de tipo Scrum of Scrums para la interacción con otros equipos de trabajo.

Las reuniones semanales o de cierre de Sprints (review o retrospective meetings) pueden realizarse en forma presencial ya sea en las oficinas del cliente (es lo recomendable) o en FDV, según se acuerde durante la ejecución.

Una de las actividades fundamentales que deben tenerse en cuenta entre Sprints es el bugfixing. Para ello se propone entre Sprints realizar la evaluación y estimación de bugs que se encuentran en el sistema, lo cual se incluye como una actividad más
del siguiente Sprint.

Por otro lado, dado que el Backlog puede estar abierto a cambios de alcance o features incluidos, se propone una gestión de cambios dinámica. En este caso el Backlog inicial utilizado para armar el contrato fue sólo un marco de referencia para comprometer el presupuesto inicial. A medida que el proyecto avanza, el Backlog cambia, se incluyen y quitan features.
El único control estricto contra el contrato será el no excederse del presupuesto acordado, independientemente de los features incluidos. De esta forma el control de cambios queda totalmente abierto y se evitan los procesos complejos de gestión de cambios.

Se propone la utilización de la reunión de planificación de Sprints como punto de chequeo sobre la performance del equipo de desarrollo, el equipo del negocio o la interacción con otros equipos. Así se podrá tomar las acciones correctivas correspondientes en forma temprana.

Aceptación de entregas
Cada Sprint tendrá incluida una actividad de testing funcional y bugfixing. Ello se piensa con Sprints de 3 semanas donde parte de la última se utiliza para hacer el testing funcional y bugfixing. A su vez, los releases deberían estar sujetos a pruebas de regresión y ser revisados y aceptados por los líderes funcionales (Producto Owner). Estas actividades pueden planificarse en paralelo al desarrollo de otros Sprints para que no se vea perjudicada la velocidad de desarrollo de nuevas funcionalidades.

Cierre del contrato
Finalizados los Sprints acordados inicialmente y una vez realizados los delivery correspondientes, se procederá a dar por cerrado el contrato. Se realizará una evaluación de resultados y del proceso en general. Se revisará el estado del Backlog y se plantearán los próximos pasos impulsando nuevos proyectos de desarrollo con esta misma metodología.

Consideraciones Generales

- Discovery
En caso que en una primera instancia no se tenga claro el Backlog inicial, se puede llevar a cabo una etapa de Discovery. Durante ella, un analista funcional de FDV trabajará en conjunto con el Product Owner y los Key Users en la definición de features iniciales con el objetivo de establecer una primera definición del producto a construir.

- Catch-up
Es razonable que durante los primeros Sprints o incluso antes de comenzar el desarrollo, haya que considerar actividades de capacitación de todos los involucrados en aspectos tecnológicos o de negocio particulares al cliente.

En este caso y siempre apostando a las relaciones a largo plazo, tomamos una postura de costo compartido: FDV se compromete a poner a disposición los recursos necesarios para tomar cursos o jornadas de capacitación formales previos al comienzo del trabajo, mientras que el cliente aceptará que existe una curva de aprendizaje y rendimiento de los recursos que afectará a los primeros Sprints.

Durante este periodo de catch-up, el cliente pondrá a disposición de FDV los recursos tanto técnicos como funcionales necesarios para resolver cualquier inquietud o inconveniente de modo eficiente.

Análisis funcional
Si bien las metodologías ágiles hacen foco en la proximidad física de los integrantes del equipo, incluyendo a los Key Users o cualquier otro representante funcional, somos consientes que en muchos casos, especialmente en los proyectos de tercerización, ello es muy difícil de cumplir de forma permanente.

Para cubrir este gap, se propone incluir actividades de análisis funcional específicas a lo largo del proyecto y que serán cubiertas por algún integrante del equipo. Estas actividades idealmente, deberían estar un Sprint desfasados de las de desarrollo, y así asegurar que se encuentre la mayor cantidad de información disponible para el desarrollador al momento de construir una funcionalidad.

Estas especificaciones se podrán documentar en forma de User Stories, MockUps o el formato que se crea más conveniente.

Herramientas de desarrollo y soporte al proceso
En FDV actualmente se utilizan herramientas las cuales son propuestas como base tecnológica de cualquier desarrollo. Igualmente la decisión final de la utilización de estas u otras herramientas correrá por parte del cliente de acuerdo a sus necesidades particulares.

IDE de trabajo
Se trabajará con Eclipse o IntelliJ Idea que son dos de los entornos integrados de desarrollo más populares y eficaces del mercado.

Herramienta de build
Los proyectos se desarrollan de manera agnóstica a las herramientas de desarrollo/Guild, de modo de que el código fuente no queda atado a ellas asegurando la portabilidad del proyecto a otros posibles equipos de trabajo que utilicen otras herramientas.

La herramienta elegida por FDVS es Apache Maven 2 la cual se utiliza para realizar los builds de la aplicación, manejo de dependencias e incluso para auto-documentación.

Versionado
Se utiliza Subversion como herramienta de versionado (SCM) y desarrollo colaborativo, lo cual permite tener un control sobre el código fuente, documentación y cualquier otro artefacto, asegurando el seguimiento y control de versiones.

Base de conocimiento
Es fundamental contar con una base de conocimiento donde el equipo de desarrollo pueda plasmar la información que se genere como cualquier otro tipo de documentación técnica, funcional, etc. que ayude a la documentación del proyecto y a la colaboración entre pares. Para tal motivo FDVS cuenta con la herramienta Confluence (la wiki de Atlassian) y la integra con su solución Project Guide (link) de forma tal de optimizar la generación y difusión del conocimiento.

Registro de incidencias interno
El manejo de incidencias durante la vida de un proyecto se hace mediante JIRA. Esta herramienta permite hacer el seguimiento de cualquier tipo de actividad (tarea de desarrollo, bugs, mejoras, etc.). A su vez, para los proyectos ágiles cuenta con GrassHopper, un plugin que incluye características particulares de un proyecto Scrum (Epics, Stories, un Planning Board y gráficos de BurnOut entre otras características).

Integración continua
La integración continua es una práctica que ayuda a detectar en forma temprana posibles problemas en el código fuente almacenado en Subversion, ya que periódicamente, la herramienta de integración descarga las actualizaciones, ejecuta una compilación del código y la ejecución de los tests unitarios que se encuentren disponibles. Si algo de todo esto falla, se notifica al equipo de trabajo a fin de que pueda tomar una acción correctiva. El mismo, podrá identificar y corregir los problemas que surjan en un menor tiempo que si fueran detectados en etapas posteriores del proceso de desarrollo.

Esta práctica también colabora en mejorar la calidad del producto final.
La integración continua se realiza utilizando la herramienta Bamboo (de Atlassian). El mismo se integra con Maven2 y con Sonar aportando un interesante valor agregado al proceso de desarrollo, ya que permite ejecutar tareas de análisis de código fuente que aseguran los estándares definidos por el cliente.

Análisis de calidad del código
Esta es una práctica que se encarga de reforzar buenas prácticas de programación y algunas de diseño software. Ayuda a reforzar el seguimiento de las “coding conventions” y otras tantas reglas y verificaciones que de no seguirse, podrían generar futuros bugs en la aplicación y que al respetarse, no sólo favorecen la calidad del producto final, sino que simplifican los procesos de inducción de nuevos miembros al equipo y las modificaciones de código en forma cruzada.
Utilizamos Apache Sonar para realizar esta tarea, el cual se integra con Maven2 y con Bamboo siendo éste el que coordina su ejecución durante el proceso de build.

Tests de regresión
Desde FDV se impulsa la utilización de tests de regresión automáticos. Para estos desarrollos proponemos utilizar Cacique recientemente adoptada, la cual estamos haciendo poco a poco extensiva a todos los desarrollos web llevados adelante por FDV. Esta herramienta fue desarrollada por personal de MercadoLibre (cliente de FDV) y recientemente fue liberada en forma Open Source.

Time Tracking
En FDV hemos desarrollado Project Guide, con el fin de optimizar el seguimiento de nuestros equipos de trabajo, conociendo sus esfuerzos diarios, midiendo el clima laboral de cada equipo y proyecto, además de fortalecer la carga de conocimientos adquiridos.

Mediante la utilización de un asistente virtual vía GTalk, la recolección de la información se realiza diariamente en forma oportuna. A su vez, no sólo nos permite registrar el seguimiento de horas, sino que hemos incorporado elementos de Knowledge Management y Mood Management.