Nosotros

¿QUIÉN ES JARABESOFT?

Nacemos como división especializada en desarrollo de software de Escucho y Aprendo.

Establecidos en MIND - México Innovación y Diseño

Nos dedicamos a construir software web y aplicaciones móviles con metodologías de desarrollo ágil, las últimas tecnologías y los más altos estándares de calidad

CASO DE ÉXITO 2015

Elegidos por el Consejo Estatal de Ciencia y Tecnología

Así Brillamos

Respuesta ágil

Procesos enfocados en comunicar lo más claro y pronto posible

Just enough, Just in time

Nos enfocamos en entregar el mayor valor agregado con el menor esfuerzo y en el menor tiempo

Escalabilidad

Un flujo de personal capacitado constante nos permite generar equipos de desarrollo a demanda

Situación Actual

Qué observamos

Un equipo que trabaja constantemente topado en capacidad.
Un área de campo que recibe requerimientos y que una vez que suben a laboratorio se convierten en un misterio.
Una visión ambiciosa de crecimiento.
Un proyecto de software de gran tamaño, complejidad y edad. Y que además no está documentado.
Una metodología que es la correcta, pero que no se acepta ni se sigue.

Exploración

¿Qué se está haciendo actualmente?
¿Cómo se está haciendo?
¿Por qué se está haciendo de esa forma?
¿Qué se ha identificado ya como área de mejora?

Medición

Definir puntos con mayor área de oportunidad.
Definir puntos de menor esfuerzo de implementación.
Definir puntos con más impacto en el retorno de inversión.
Medir la frecuencia en la que se presentan las situaciones

Reporte

Enlistar los puntos identificados de área de mejora.
Cómo se compara con la situación ideal.
Opiniones y acuerdos de acciones a implementar en Corto, Mediano y Largo Plazo conforme aplique.
Los puntos estarán priorizados según su nivel de impacto y dificultad de implementación.
- Los más sencillos con mayor impacto primero.
- Los más complejos con menor impacto al final.

Áreas de Mejora Principales

Y orden de implementación

Carga de Trabajo
- Nuevos Recursos
- Aumentar productividad a los recursos actuales
Comunicación
- Definir métricas
- Hacia las diferentes áreas
Mantenibilidad
Metodología

Carga de Trabajo

Eficientar Recursos

Separar Mantenimiento de Desarrollo

(Mantenimiento podría llamarse "Mejora Continua")

Eficientar los tiempos en juntas
Cada equipo tendrá más margen y libertad de moldear los procesos que mejor se ajusten
Las cabezas de cada equipo tendrán mayor claridad del avance de su área

Beneficios Esperados

Cada equipo debe de contar con líder de equipo
Cada equipo debe de contar con Kanban separado
- Las juntas diarias deben ser separados
Cada equipo debe contar con una visión definida independiente
El Product Owner puede ser compartido entre los dos equipos

Subcontratación para proyectos nuevos

Y re-dirigir esfuerzos internos a mantenimiento

Agilidad en la integración de nuevos elementos
Poder modular la cantidad de recursos en producción de manera flexible
Facilidad de proyección de tiempos y esfuerzos

Beneficios Esperados

Comunicación

Y Métricas

Implementar Figura de Product Owner

O figura similar a la definición de PO en Agile

Representa a las partes interesadas del producto y la voz del cliente, es responsable de la cartera de pedidos y de maximizar el valor que el equipo entrega.

El propietario del producto define el producto en términos centrados en el cliente (típicamente historias de usuarios), los añade a la cartera de productos y los prioriza en función de su importancia y dependencias.

Definición de P.O.

Implementar Sistema Help Desk

Adicional o complementario al que existe en soporte

Consta de dos principales componentes

La Base de Conocimientos (Knowledge Base) y el Sistema de Tickets.

Help Desk

Un solo canal despersonalizado
El cliente podría resolver su duda antes de contactar
No distraer al equipo de software por interrupciones de temas externos
Retroalimentación constante a los clientes
Satisfacción de los clientes al saber que lo que están solicitando ya lo han hecho antes y que la empresa se está haciendo cargo al respecto

Beneficios Esperados

Definir KPI's y Chartering

Y comunicarlos al resto de la empresa

(Tiempo estimado / Número estimado de tareas) realizadas por período.
Tiempo extra de tareas solicitadas (justificadas) por período.
Tiempo de extra de tareas solicitadas (injustificadas) por período.
Issues que entran contra issues que salen de producción
Puntuación media de revisión de código por período.
Desviación de estimación
Velocidad (Puntos o tareas por periodo)
Porcentaje de Issues que rechazados por pruebas
- Diferentes escalones (Pruebas interno, campo, cliente)

Standup Meetings Eficientes

Algunas Recomendaciones de AGILE

Acordar tiempo límite
Usar temporizador
Acordar lugar y hora
Seguir la agenda recomendada
- - ¿Qué hice ayer?
  - ¿Qué tendré listo para mañana?
  - ¿Hay algo que me detenga?
Definir el maestro de ceremonia (Opcional, pero recomendado
Los problemas o situaciones que se comuniquen en la junta se dejan para despué
Al sonar la campana todos pueden retirarse

Rendición de Cuentas

Y Retrospectiva

Crear cultura donde los resultados hablen y sean el único argumento válido
Crear cultura de alto rendimiento y sentido de urgencia
Cortes constantes de resultados para tener una visión clara
Que todos los interesados estén enterados de los avances
Que la expectativa constantemente se esté alineando al resultado real

Beneficios Esperados

Rendición de cuentas semanal con Product Owner
Rendición de cuentas quincenal con área comercial o de soporte
Rendición de cuentas mensual con Dirección

Estructura Recomendada

Objetivo principal
Descripción
Tareas u Objetivos Secundarios LOGRADOS
- Personas asignada por tarea
Tareas u Objetivos Secundarios NO LOGRADOS
- Personas asignadas por tarea
Reportes visuales.
DEMOSTRACIÓN (Muy importante)
- Demostrar en el momento de la ceremonia cada uno de los objetivos cumplidos
- En la medida de lo posible directamente sobre una versión de pruebas o si no a través de evidencia (fotos, videos, etc)
- Todo lo demás (gráficas, reportes, etc) pierde el sentido si los resultados no son demostrables.
Revisar proyección de siguiente rendición:
- Objetivo principal y tareas proyectadas
Documentar Retroalimentación y Nuevos acuerdos
- Separar cuáles entrarán en la siguiente iteración y cuáles no (Programar acuerdos)
El formato se firma o se manda por correo y cada quien responde por enterado

Estructura de Junta

Definition of Done

Y Criterios de Aceptación

El equipo acuerda, y muestra de forma prominente en algún lugar de la sala del equipo, una lista de criterios que deben cumplirse antes de que un incremento de producto "a menudo una historia de usuario" se considere "hecho".

Definition Of Done

Código completo
Pasa las pruebas Unitarias
Pasa las pruebas de Integración
Pasa prueba de usabilidad
Se revisó la ortografía
El código usa las convenciones de programación
Se documentó en el código lo que hace las funciones

Ejemplo

Los criterios de aceptación es una lista de expectativa que el cliente (interno o externo) tiene respecto a un requisito al equipo de desarrollo; la lista la puede redactar él directamente o el Product Owner en representación de sus intereses.

Criterio de Aceptación

Se definen junto con el cliente y el Product Owner
Todo el equipo debe entender
Plantilla
- Expectativa de navegación
- Algunos Casos de uso
- Etc
Evaluar que se cumpla antes de entregar

Mejorar Mantenibilidad

Los comentarios es parte del código
- Debería ser requisito para la aceptación y parte de la cultura
- Si el código cambia, el comentario cambia
Comentar no sustituye la correcta estructuración
- Seguir convenciones de “Naming”
Generar FAQ, Wiki, API Spec, Bugs Reconocidos, README, ChangeLog
Seguir un Coding Style
- Similar a PSR-2
Crear un proyecto de refactoring y Documentación general
- Con sus objetivos y metas con fechas
- milestones etc
- Resaltar las diferencias entre las versiones y ponerlas a la par
SMED