Merge branch 'master' into dates-on-deliveries

Conflicts:
	entregables/site/Docs/Manual-de-Usuario/Administracion-de-almuerzos.markdown
	entregables/site/Docs/Manual-de-Usuario/Administracion/Migraciones.markdown

entregables/site/Docs/Manual-de-Usuario/Administracion-de-almuerzos.markdown

@@ -0,0 +1,80 @@
+# Seleccion de almuerzos
+
+La funcionalidad denominada *MyMenu* dentro de CommonJobs permite la administración de almuerzos dentro de la empresa, teniendo en cuenta que existen varias opciones para ofrecer a los empleados, varias oficinas que realizan estos pedidos, y un horario restringido de posible elección para poder realizar los pedidos.
+
+El acceso a *MyMenu* está cercanamente ligado a la identificación de los usuarios, y por tanto, es necesario que cada empleado que vaya a utilizarlo tenga cargado en su perfil la dirección de correo corporativo, y un usuario de dominio. De esta forma, el login podrá realizarse para dicho empleado con la cuenta de correo (gracias a la autenticación de Google) y el empleado podrá administrar los menúes por cuenta propia.
+
+## Configuración
+
+Una vez ingresado a la funcionalidad de *MyMenu*, lo primero que el empleado verá será la sección de configuración, que por el momento le permite configurar una oficina por defecto en la cual serán pedidos sus almuerzos. El empleado puede cambiar esta selección, y en el futuro esta pantalla dará más opciones de configuración.
+
+![Configuración](Images/Administracion-de-almuerzos/01-configuracion.png)
+
+## Días específicos
+
+La opción de días específicos permite incluir excepciones particulares para las cuales el menú debe ser cambiado (contrario a la selección por defecto que el empleado haya realizado), y así indicar cambios específicos que deben realizarse, como el cambio de un menú por otro o la cancelación de un almuerzo para un día particular.
+
+![Días específicos](Images/Administracion-de-almuerzos/02-dias-especificos.png)
+
+## Menúes por semana
+
+Las siguientes opciones disponibles en la aplicación permitirán al empleado configurar su elección por defecto según las semanas en las cuales los menúes se encuentran disponibles. Se asume que estos menúes cumplen un ciclo de determinadas semanas tras el cual vuelven a repetirse. En la imagen más abajo, se puede ver una configuración de un ciclo de 5 semanas, actualmente visualizando la semana 2.
+
+![Configuración por semanas](Images/Administracion-de-almuerzos/03-semanas.png)
+
+## Guardar cambios
+
+Por supuesto, tras realizar la configuración, el empleado tiene la opción de descartar sus cambios si es que no está satisfecho con ellos, o guardarlos. Para esto puede utilizar los dos botones de acción que se encuentran disponibles en la sección superior derecha de la pantalla.
+
+![Botones de acción](Images/Administracion-de-almuerzos/04-botones-de-accion.png)
+
+# Administración de almuerzos
+
+Por otro lado, los usuarios administrativos de la sección de *MyMenu* tendrán acceso a funcionalidad extra que les permitirá cambiar los almuerzos disponibles, a la vez de efectuar los pedidos correspondiente a cada día, basándose en las elecciones de cada uno de los empleados.
+
+## Pedido del día
+
+La primera de las nuevas funcionalidades disponibles es la visualización del pedido a efectuar cada día, que se calcula en base a las distintas elecciones de los empleados.
+
+![Pedido del día](Images/Administracion-de-almuerzos/05-pedido-del-dia.png)
+
+En la pantalla del pedido del día se puede observar:
+
+- La fecha seleccionada del pedido. Es posible moverse días hacia adelante o hacia atrás para ver pedidos históricos o pedidos futuros en base a la selección actual de datos de los empleados.
+- Si el pedido ha sido realizado o no: este dato se calcula automáticamente en base a la configuración de horarios de pedido. Esto permite generar un horario de corte a partir del cual los pedidos no pueden ser modificados.
+- El pedido a efectuar: una versión sumarizada por oficina de la cantidad de menús a pedir y cuál es el contenido de cada menú.
+- El detalle por empleado de los pedidos efectuados para el día y cualquier excepción o comentario que los empleados hayan hecho disponibles.
+
+El listado puede ser también filtrado por oficina utilizando las pestañas con su nombre, permitiendo imprimir versiones independientes para cada una de ellas.
+
+Igual que en otras partes del sistema, el listado puede ser filtrado con un criterio de búsqueda, ordenado con múltiples criterios, exportado a PDF o Excel, impreso individualmente o copiado al portapapeles.
+
+## Definición de los menúes
+
+Por supuesto, las distintas opciones de elección para los empleados debe ser cargada antes de que estas puedan ser seleccionadas. También es posible alterar los menúes con el tiempo si es que la empresa proveedora de menúes cambia sus opciones o cualquier otra razón pertinente.
+
+Para estos casos la sección disponible para el administrador llamada *Definición de los menúes* permitirá configurar estos aspectos.
+
+Para cada día de la semana (Lunes a Viernes), cada una de las semanas disponibles en el ciclo y cada uno de los posibles menúes, se puede cargar el contenido de este menú en particular.
+
+Por ejemplo, en la imagen de más abajo podemos observar un menú cargado para una configuración de cinco semanas, y tres menúes disponibles.
+
+![Definición de los menúes](Images/Administracion-de-almuerzos/06-definicion-de-los-menues.png)
+
+## Configuración
+
+Por último, es necesario poder configurar los parámetros mencionados en las secciones anteriores, por lo que se provee la sección de configuración entre las opciones de definición de los menúes. Las siguientes son:
+
+![Configuración](Images/Administracion-de-almuerzos/07-configuracion.png)
+
+- Título del menú
+- Fecha de comienzo de este menú
+- Fecha de finalización de este menú
+- Fecha de último envío del pedido
+- Horario hasta el cual es editable en cada día (hora de cierre de pedidos)
+- Semana que comenzará el ciclo de pedidos
+- La cantidad de semanas presentes en un ciclo de pedidos según el menú disponible
+- Las distintas opciones (menús) disponibles
+- Las distintas oficinas o localizaciones en las cuales los empleados pueden pedir sus menús
+
+Tras guardados los cambios en estas configuraciones, se aplicarán inmediatamente en el resto del sistema.

entregables/site/Docs/Manual-de-Usuario/Administracion/Migraciones.markdown

@@ -0,0 +1,35 @@
+# Migraciones
+
+La sección de migraciones permitirá administrar las actualizaciones graduales a la estructura de la base de datos que requieran distintas actualizaciones de la aplicación. De esta forma, siempre se puede actualizar el sistema preservando los datos y se puede volver a versiones anteriores con una pérdida de datos mínima.
+
+## Acceder al área de migraciones
+
+A diferencia de otras áreas de la aplicación, el área de migraciones no se encuentra disponible desde los menúes de la aplicación. Para acceder a él, hace falta ingresar manualmente la ruta `/Migrations` luego de la ruta base a través del la cual se pueda acceder a la aplicación.
+
+Es necesario estar autenticado como un administrador para poder acceder al área de migraciones.
+
+## Listado de migraciones
+
+La pantalla de migraciones mostrará un listado de las migraciones disponibles en el sistema. Para obtener nuevas migraciones es necesario instalar versiones más actualizadas del código en el servidor que se encuentra ejecutando esta aplicación.
+
+![Listado de migraciones](Images/Migraciones/01-listado.png)
+
+El listado de migraciones muestra la siguiente información para cada una de las migraciones disponibles:
+
+- **Key:** clave identificadora de la migración. Por convención del equipo se ha decidido hacer a esta la fecha de implementación de dicha migración.
+- **Class:** nombre de la clase que implementa los cambios de esta migración. Esta es la clase que tiene la lógica necesaria para aplicar los cambios en la estructura de los datos, tanto para instalar como para desinstalar la migración.
+- **Description:** Una descripción breve de los cambios que esta migración incluye.
+- **Status:** Estado según ha sido detectado en la estructura de datos actual, permitiendo identificar si la migración ha sido instalada o no.
+- **Action:** Listado de acciones posibles según el estado actual de la migración.
+
+## Aplicar cambios de migraciones
+
+Para aplicar cambios de las migraciones, sólo hace falta seleccionar la acción correspondiente (*Install* / *Reinstall*) en el listado de acciones disponibles y hacer click en el botón de *Submit* de abajo.
+
+De la misma forma, elegir la acción *Uninstall* de una migración aplicará los cambios reversos para remover los cambios introducidos por una migración.
+
+## Ver información de errores
+
+En el caso particular en el que una migración haya fallado, su estado será indicado como tal y se podrá ver un icono cercano a su estado indicando la razón del fallo de aplicación de la migración. Colocando el puntero sobre este icono permitirá ver detalles de por qué falló la migración para poder resolver el problema.
+
+![Información de error](Images/Migraciones/02-error.png)

entregables/site/Docs/Proyecto/Retrospectiva/Retrospectiva-de-horas.markdown

@@ -0,0 +1,81 @@
+# Retrospectiva de horas
+
+A lo largo del proyecto hemos mantenido una bitácora de horas utilizadas en distintas actividades. Hemos además planificado cada sprint según la cantidad de horas que creíamos que podríamos dedicar según las necesidades de los objetivos del nuevo sprint y según nuestra disponibilidad personal.
+
+Tras terminar el proyecto, hemos puesto los números juntos para evaluar el resultado de dichas dedicaciones. A continuación pueden leerse las conclusiones obtenidas.
+
+## Horas planeadas vs. dedicadas
+
+![Horas planeadas vs dedicadas](Horas-planeadas-vs-dedicadas.png)
+
+### Errores de estimacion
+
+El gráfico demuestra claramente que hemos estimado más tiempo disponible que la cantidad de horas que realmente podríamos dedicar a un determinado sprint. Creemos que esto se debe a la situación de planificar horas fuera de nuestro horario laboral, en donde por lo general es el tiempo que es ocupado por imprevistos de tipo personal, académico o incluso laboral. Si bien siempre hubo intenciones de dedicar un tiempo grande al proyecto, no siempre resultó posible.
+
+### Ajustes de planificación
+
+A medida que este patrón se hizo más y más evidente, nuestras estimaciones de tiempo disponible se hacían más y más conservadoras. Sin embargo, siempre quisimos mantener nuestro tiempo a dedicar lo más alto posible, ya que a la vez se trataba de un compromiso con el resto del equipo y con el avance del proyecto. Es por esto que las horas estimadas siempre se mantienen un poco por encima de las horas realmente dedicadas pero a la vez las estimaciones se vuelven más conservadoras con el tiempo.
+
+## Horas por actividad
+
+![Horas por actividad](Horas-por-actividad.png)
+
+### Aprendizaje y desarrollo
+
+Notamos que una gran porción del tiempo dedicado se trata de tareas de aprendizaje, investigación y desarrollo. La última es obvia: tratándose de un proyecto de software, la implementación del mismo debería tomar un tiempo considerable.
+
+Las primeras dos, por otro lado, no son tan evidentes en primer lugar. Esto se debe a que el proyecto fue planteado también como una oportunidad para los integrantes del aprendizaje de nuevas tecnologías para ellos, como han sido git, el flujo de GitHub, RavenDB, el trabajo SCRUM remoto, y el dominio mismo de la aplicación: RRHH y los flujos involucrados.
+
+### Instalación y configuración
+
+Hemos notado también una presencia importante de las tareas de instalación y configuración. Esto se debe a la prioridad que le hemos asignado a mantener el sistema vivo en un entorno en el que el cliente pudiera darle uso real día a día, y en donde pudiera ver un avance sprint a sprint de las nueva funcionalides disponibles. Esto ha permitido tener una retroalimentación basada en hechos de las necesidades actuales en base a cómo se ajustaba el sistema a las necesidades del cliente en cada momento.
+
+### Documentación
+
+Notamos también una presencia de tareas de documentación. Tratándose de un proyecto académico, consideramos que la documentación del mismo es importante para la longevidad de las decisiones tomadas y para la correcta justificación de las mismas en una situación futura de defensa del proyecto.
+
+## Horas por actividad por sprint
+
+![Horas por actividad por sprint](Horas-por-actividad-por-sprint.png)
+
+### Aprendizaje e investigación
+
+De la misma forma que hemos notado más arriba, también se hace obvio aquí que el aprendizaje y la investigación de las tecnologías ha sido vital para el avance correcto del proyecto y la determinación de las mejores estrategias. Es por esto que las tareas tienen un rol importante al comienzo del proyecto, y lentamente declinan pero nunca desaparecen completamente.
+
+### Análisis
+
+Notamos que las tareas de análisis tienen una importancia considerablemente más grande a partir del Sprint 9. Esto concuerda con las decisiones tomadas a lo largo del proyecto, ya que fue a partir de ese sprint que se adquirió una nueva estrategia para la definición de requerimientos y el relevamiento de datos.
+
+### Desarrollo
+
+Obviamente, tratándose de un proyecto que genera un producto de software, el desarrollo es una parte importante del mismo. En todo sprint ha sido importante generar una salida como parte del producto, con lo que el desarrollo es una actividad visible a lo largo del todo el proyecto.
+
+### Documentación y pruebas
+
+Las tareas de documentación y pruebas comenzaron a tomar fuerza en las últimas partes del proyecto. Esto tiene sentido ya que son las tareas que tomaron prioridad como necesidad para dar un cierre al proyecto y asegurar la correcta calidad del producto hasta este momento, a la vez de la generación de manuales, y documentación de proyecto dada la naturaleza académica del mismo.
+
+### Reuniones
+
+Los primeros sprints tuvieron una presencia importante de reuniones, que lentamente fue disminuyendo. El equipo lentamente aprendió a manejar la propia dinámica de la comunicación entre los entregantes y las etapas importantes que requerían de reuniones, pero las que eran innecesarias se dejaron naturalmente de lado. Esto permitió que dicho tiempo se dedicara a tareas más vitales para el avance del proyecto.
+
+## Horas por persona por actividad
+
+![Horas por persona por actividad](Horas-por-persona-por-actividad.png)
+
+Este gráfico demuestra la forma en la que el equipo naturalmente se acomodó con los talentos multidisciplinarios que cada uno de los integrantes poseía. Cada uno de los siguientes es un ejemplo de cómo el equipo naturalmente cubrió necesidades de la forma más natural:
+
+- En su mayoría, las tareas de análisis han sido cubiertas por Andrés y JD, quiénes mantuvieron una mirada muy cercan al backlog y a las tareas a seguir, importante para plantear el correcto diseño del sistema y las estrategias para resolver los problemas que los requerimientos planteaban.
+
+- El aprendizaje y la investigación fueron en su mayor parte realizado por Andrés y Matías, quienes mantuvieron una mirada crítica sobre los procesos, decisiones y tecnologías a elegir, en base a los requerimientos académicos, a la comunicación con el cliente y a las necesidades planteadas.
+
+- El desarrollo fue mayoritariamente abordado por Andrés y JD, quiénes han tomado decisiones sobre los detalles de implementación y funcionamiento del sistema.
+
+- El diseño del sistema fue en su mayor parte resuelto por Andrés, de quién se desprendieron muchas estrategias como soluciones que el sistema provee a las problemáticas planteadas.
+
+- La documentación fue realizada en su mayor parte por Matías, gracias a quién se posee la mayor parte de la documentación actualizada sprint a sprint y la documentación de proyecto para cada entrega en particular.
+
+- Las formalidades académicas han sido en general abordadas por Andrés y Matías, dada la naturaleza de trabajo remoto de JD.
+
+- Andrés, teniendo contacto cercano con los administradores de sistemas de la empresa cliente, mantuvo una mirada de cerca a la instalación y la configuración del sistema en ese entorno real, participando en gran parte en la implantación sprint a sprint.
+
+- Las planificaciones y reuniones han sido realizadas por el equipo en partes prácticamente iguales. Todos los miembros del equipo participaban de estas reuniones de proceso y de toma de decisiones.