Glosario Agile
| Término | Traducción | Definición |
|---|---|---|
| Regression testing | Pruebas de Regresión | Asegurar que el software previamente desarrollado y probado aún funcione después de un cambio. |
| GQM (Goal, Question, Metrics) | Meta, Pregunta, Métrica | Herramienta de toma de decisiones basada en esos tres principios. |
| Dashboards | Tableros | Compendio de indicadores clave que permitan tomar acciones preventivas y correctivas. |
| Squads | Escuadrones | Grupo de ingenieros que trabajan cercanamente en un área específica del producto. Están diseñados para ser autónomos y tienen amplios objetivos de negocio para lanzar al mercado apenas estén listos. Modelo de Tribus de Spotify. |
| Tribes | Tribus | Colección de escuadrones agrupados por un enfoque común. Por ejemplo, una tribu para Spotify para la versión móvil. |
| BDD (Behavior-Driven Development) | Desarrollo Manejado por Comportamiento | Modelo de gestión de requerimientos: (as a _ / I want _ / so that _ | given _ / when _ / then _ ) |
| Technical Debt | Deuda Técnica | Costo implicado de trabajo adicional causado por elegir el camino fácil en lugar de no mejor que time más tiempo. Ejes: (Deliberated, Inadvertent | Reckless, Prudent) |
| Epics | Épica | Gran porción de trabajo con un objetivo común que puede ser partido en historias de usuario. |
| Test driven development (TDD) | Desarrollo Manejado por Pruebas | Programar solo en base a un conjunto de pruebas, incluye refactoring. |
| Acceptance Test-Driven Development (ATDD) | Desarrollo Manejado por Pruebas de Aceptación | Enfoque desde el punto de vista del usuario (given _ / when _ / then _ ) |
| Generalizing Specialists | Especialistas Generales | Alguien que: (a) Tiene una o más especialidades técnicas (e.g. Java, Project Management, Database Administration, …) (b) Tiene un conocimiento general de desarrollo de software. (c) También de dominio de negocio donde trabaja (d) Busca activamente ganar nuevas habilidades en sus especialidades o en otras áreas, técnicas o de dominio. |
| Taskboards | Tablero de Tareas | Se utilizan para diagramar las tareas de grupos distribuidos, e.g., (“To Do”, “In Progress”, “Done”) |
| Onsite customer | Usuario en Sitio | Enfoque donde el usuario presencialmente se encuentra con el programador. |
| Guilds | Gremios | Comunidad de miembros con intereses comunes, conocimiento, herramientas de código y prácticas. Tiene un co-coordinador. Ej.: web technology guild, test automation guild , agile coaching guild. |
| Scrum | Scrum (jugada de Rigby) | Un proyecto que dura un sprint (pique), uno o varios releases por cada uno. El proyecto no falla, sólo genera un inaceptable ROI |
| User Stories | Historias de Usuario | Descripción de especificaciones que cumplen un objetivo de proyecto y siguen la forma (as a _ / I want _ / so that _) |
| Product Owners | Dueños de Producto | Rol que condensa todos los requerimientos y es responsable de su ciclo de vida en un proyecto ágil. |
| Backlogs | Reservas | Porción de trabajo que se va a planificar realizar en un sprint determinado. |
| Daily standups | Reuniones diarias de pie | Reunión de muy corta duración solo para responder (¿Qué hice ayer, qué haré hoy, qué impedimentos tengo?) |
| Burndowns | Quemadura tendiente hacia abajo | Se refiere a un diagrama para trabajo remanente por día mientras dura el sprint |
| Burnups | Quemadura tendiente hacia arriba | Lo mismo que el Burndown Chart pero en lugar del remanente, el completado. (Aquí se contempla alcance añadido y removido) |
| Continous Integration | Integración continua | Unir las partes y compilar periódicamente como un todo, probar localmente. |
| Split testing | Prueba dividida | bucket testing | split-run testing | A/B Testing. Probar dos alternativas |
| Pair Programming | Programación en pares | Programación de un mismo módulo por dos programadores. |
| Shift right | Arrimar a la derecha (del tiempo -después) | Botar las pruebas para más tarde y concentrarse en desarrollar |
| Shift left | Arribar a la izquierda (del tiempo -antes) | Realizar las pruebas lo más pronto posible a medida que se desarrolla en todo momento |
| Program Increments (PIs) | Incrementos de Programa | Backlog completado en un sprint + el valor de los PIs en todos los sprints anteriores. |
| Architecture Owners | Dueños de Arquitectura | Arquitecto de solución que se nfoca en facilitar la evolución de la arquitectura de la solución a través del tiempo en lugar de formular la arquitectura detallada y desde inicios del ciclo de vida y dictarla al resto del equipo. |
| Automated tests | Pruebas automatizadas | Uso de software separado del que se va a testearpara controlar la ejecución de las pruebas y para comparar los resultados actuales como los predichos. |
| Active stakeholder participation | Participación activa de interesados | Involucramiento desde etapas tempranas del proyecto hasta el final de los interesados. |
| Mob programming | Programación en multitud | Lo mismo que pair programming pero con todo el equipo. |
| User experience | Experiencia de usuario | Emociones y actitudes de una persona usando un producto en particular. |
| Dynamic analysis | Análisis Dinámico | Testeo y evaluación de un programa por medio de datos de ejecución en tiempo real. El objetivo es encontrar errores mientras se ejecuta, en lugar de examinar repetidamente el código apagado. |
| Maslach Burnout Inventory (MBIs) | Inventario de “Quemados” Maslach | Tiene 5 formas validadas compuesta de 16-22 ítems a medir la experiencia de un individuo de “quemarse”. Escalas: Emotional Exhaustion (EE), Depersonalization (DP), Personal Accomplishment (PA), Cynicism, Professional Efficacy |
| Exploratory Testing | Pruebas Exploratorias | Testeo exploratorio que busca averiguar cómo trabaja el sofware, y hacer preguntas de cómo manejar casos fáciles y difíciles. |
| DevOps | Desarrollo y Operaciones | Conjunto de prácticas que combinan desarrollo de software (Dev) y operaciones de TI (Ops) que apunta a acortar el ciclo de vida de desarrollo de software y provee entrega continua con calidad de software (Codificación, Construcción, Pruebas, Empaquetado, Liberación, Configuración, Monitoreo) |
| Continous Deployment | Despliegue continuo | Frecuentemente a través de despliegues automatizados (e.g. microservicios) que contrasta con entrega continua, potencialmente capáz de ser desplegada pero en realidad no desplegada. |
| Design | Diseño | Proceso por el que un agente crea una especificación de un artefacto de software, pensado para cumplir objetivos. |
| Refactoring | Refactorización | Reestructurar un código interno descomponiéndolo nuevamente sin afectar el comportamiento externo. |
| Minimum Viable Product (MVPs) | Producto Mínimo Viable | Versión de un producto con solo las características suficientes para satisfacer a los consumidores ávidos y proveer retroalimentación para el futuro. |
| Acceptance Tests | Pruebas de Aceptación | Test conducido para determinar los requerimientos conducidos para determinar si los requerimientos contractuales se cumplen. |
| Static analysis | Análisis Estático | Contraste del Análisis Dinámico, en que se evalúa el efecto de un cambio en el corto plazo y no largo plazo. |
| Net Promoter Score (NPS) | Puntaje de Promotores de Red | Respuestas a una pregunta: ¿Cuán probable (1..10) es que recomiende nuestra compañia/producto/servicio a un amigo o colega? (9 – 10 Promotoress, 0 – 6 Detractores, 7 – 8 Pasivos) |
| Database Refactoring | Refactorización de BD | Cambio simple a un esquema de base de datos que mejora su diseño mientras retiene su semántica de comportamiento y de información. |
| Objectives and Key Results (OKRs) | Objetivos y Resultados Clave | Marco de trabajo para definir y rastrear objetivos y sus resultados. |
| Canary Testing | Pruebas de Canario | Pruebas de que todo lo que frecuentemente dependan las pruebas están OK: conectividad, espacio en disco, ambiente, etc. |
| Open Space | Espacio Abierto | Reunión para equipos complejos autoorganizados, responsables y apasionados, donde un facilitador coloca un tablero donde los demás postean y se hacen responsables por los temas a discutir (y sus conclusiones) y un micrófono donde cada uno sale a dar sus ideas. |
| Release Planning | Planificación de Liberación | Planear sprints iterativos a través de liberaciones incrementales. |
| Business Canvas | Lienzo de Negocios | Diagrama visual con elementos que describen la proposición de valor de una empresa o producto, infraestructura, consumidores, y finanzas. |
| Spikes | Púas | Una historia de usuario demasiado compleja para estimarla. Se deben tomar acciones, formato: Para (tal objetivo) (tal persona o sistema) necesita (tal acción). |
… un largo etcétera.
MSIG Ing. Roger Salinas-Robalino, PMP (Roger.T800)
Máster en Sistemas de Información Gerencial de la Escuela Superior Politécnica del Litoral (ESPOL). Project Management Professional (PMP®). Miembro activo del Project Management Institute (PMI®), Capítulo Ecuador, desde el mismo año. Tiene más de 10 años de experiencia en el Sector Financiero y Banca, en el área de Tecnología de Información y Comunicaciones y Desarrollo de Aplicaciones y Sistemas, y más de 6 años en Administración Estratégica de Proyectos Institucionales. Ha trabajado desde el 2006 en dos de los mayores bancos de la ciudad de Guayaquil como Director de Proyectos. Ha liderado y culminado diversos proyectos, entre otros: Migración de Contact Centers, físicamente y actualización de su infraestructura tecnológica, Implementación de módulos completos de ERPs para varios departamentos, con su correspondiente adaptación y entrenamiento. Lanzamiento de nuevos canales financieros y Corresponsales No Bancarios. Nuevos productos para personas naturales y jurídicas. Actualización y optimización de la plataforma de Interaction Voice Response (IVR). Otros de complejidad similar. Ha dictado clases de Project Management y el uso de Microsoft Project Professional 2013, entrenamiento y formación profesional en Centros de Educación Continua en todo el país.