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