Descargar para leer sin conexión
Subido porAndrés Grosso
Esemap
Este documento presenta ESEMAP, una metodología y proceso de ingeniería de software desarrollado por Engee IT S.R.L. Explica conceptos clave como predictivo vs adaptativo, valores y principios ágiles, roles, gestión del backlog, planificación iterativa e incremental, tareas visuales, reuniones y revisiones. El objetivo es integrar lo mejor de metodologías como SCRUM, RUP y XP para adaptarse a diferentes contextos de proyectos.
Esemap
- 1. Engee IT S.R.L. ESEMAP EngeeSoftware Engineering Methodology and Process
- 2.
- 3. ¿Por qué? Shu HaRi • Shu: aprender técnicas o Fundamentos o Aprender y ejecutar lo que indica el “maestro” • Ha: coleccionar técnicas o Dominar el método, ver más allá de lo básico o Aprender otras técnicas • Ri: mezclar técnicas o Aprender de uno mismo o Crear tu propio estilo adaptado a tu contexto
- 4. Procesos y Metodologías ¿Qué es un proceso? ¿Qué es una metodología? ¿Por qué ESEMAP es un proceso y también una metodología?
- 5. Predictivo vs Adaptativo •Predictivo o Waterfall, UP, PMBOK, ISO, etc. o Pesado o Análisis detallado o Planificación a largo plazo o Objetivos y requerimientos claros o Certezas • Adaptativo o SCRUM, XP, Kanban, etc. o Ágil o Análisis general o Planificación a corto plazo o Objetivos y requerimientos imprecisos o Incertidumbres
- 6. Valores (ágiles) Individuos e interacciones Colaboracióncon el cliente Software que funciona Responder ante el cambio procesos y herramientas documentación exhaustiva negociación de contratos seguimiento de un plansobre sobre sobre sobre
- 7. Principios • Feedback tempranoy frecuente • Valor de negocio • Colaboración • Compromiso • Software funcionando, primer medida de progreso • Predecir y adaptarse lo posible • Simplicidad • Calidad en el trabajo • Motivación equipo • Las personas son lo primero, pero no lo único • Arquitectura base • Control de la calidad • Kaizen (Mejora continúa) • Potenciar al equipo
- 8. Reglas (12) 1. Roles 2.Project Backlog 3. Iterativo e incremental 4. Planificación 5. Taskboard 6. Backlog Refinement 7. FIMs / RFIs 8. Demo 9. Retrospectiva 10. Code Review 11. Integración continua 12. QC
- 9. Roles Obligatorios • PO • PM •TR • Desarrolladores • Testers Opcionales • Arquitecto • Líder de equipo • Líder de testing • Analista • Etc. • Interesados/observadores
- 10.
- 11.
- 12. Iterativo e incremental Iteración 2-6semanas Objetivo de la Iteración Alcance de la iteración Incremento del producto Project Backlog 24 horas
- 13. Planificación • Participantes o Obligatorios:PM, TR, Devs, Testers o Opcionales: PO se recomienda su participación • Iteración de 1-8 semanas • Objetivo iteración • Solo PWIs con DoR
- 14. Planificación 1. Preparación 2. Definirlos objetivos de la iteración 3. Estimación detallada 4. Revisión de la estimación 5. Slicing 6. Armar tablero visual 7. Agregar indicadores visuales 8. Identificar riesgos 9. Identificar Walking Skeleton & MVP 10. Visual Story Mapping 11. Calendarizar
- 15. Taskboard • Kanban • Obligatorias oPendiente o En progreso o Finalizado • Opcionales o Testing o Release o Otras • Ordenar por prioridad • Fecha fin sprint • Marcar PWI impedidas • Marcar dependencias • Indicadores visuales
- 16.
- 17. Backlog Refinement • RefinarPWIs existentes • Sacar PWIs no necesarias • Agregar nuevas PWIs necesarias • Re priorizar • Participantes o Obligatorios: PO, PM o Opcionales: el equipo • Se recomienda reunión presencial no obligatorio
- 18. FIM • Frecuencia o Definidapor líder o Mínimo: 2 veces por semana • Parados, informal, timebox • Cada integrante equipo responde o ¿Qué hiciste desde la última FIM? o ¿Qué vas a hacer hasta la próxima FIM? o ¿Tenes algún impedimento? o ¿Hay algún desvío?
- 19. Demo • Duración máxima:4 horas • El equipo se presenta lo realizado en la iteración o Cada integrante muestra sus IWIs • Se buscan impresiones, sugerencias de cambio y mejoras • Antes de testing • De ser posible que participe el PO
- 20. Retrospectiva • Duración máxima:30 minutos • Al finalizar cada iteración • Todo el equipo participa • Se responden dos preguntas o ¿Qué cosas fueron bien en el último sprint? o ¿Qué cosas se podrían mejorar? • Lessons learned • El PM documenta la retro • El equipo prioriza las mejoras posibles
- 21. Value meeting Reuniones formalescon el objetivo de generar valor Debe participar todo el equipo La perioricidad es definida por el equipo Se debe analizar características de una aplicación si dan valor Se debe relevar necesidades del cliente como dar valor Estructura de una value meeting 1. Follow Up (10’) 2. Picking information (10’) 3. Brainstorming (20’) 4. Refinement (10’) 5. Plan (10’)
- 22. Code Reviews • Identificaciónde code smells • Lineamientos y buenas prácticas • Las realiza el TR • Refactorización • Test • PM y RT definen sobre qué hacer Code Review
- 23. Integración continua • Sourcecontrol • Automatizar la construcción del proyecto • Automatizar el despliegue • Check In Early, Check In Often • Código incompleto != Código roto • Branching patterns
- 24. QC • Quien desarrollano prueba • Estimación & planificación • Profesionales calificados o Experiencia o Registro de bugs o Criticidad • Issue tracker • Ambiente de test • Automatización recomendada (no obligatoria) o Smoke test o Regresión
- 25.
Notas del editor
- #2 Engee es una empresa de calidad, desarrollo y consultoría de software.
- #4 Proviene de Aikido, la trajo al software Alistair Cockburn http://martinfowler.com/bliki/ShuHaRi.html http://alistair.cockburn.us/Shu+Ha+Ri
- #5 Un proceso se refiere a un conjunto de actividades que se realizan para un fin determinado. En este caso, el fin sería producir Software. Una metodología es el conjunto de reglas, procedimientos, técnicas y pasos a seguir para llegar a un fin determinado.
- #7 Los mismos que expone el mafiniesto agile
- #9 FIMs / RFIs: Reuniones Frecuentes Informales, aka dailys, reuniones de estado frecuentes. Frequently Informal Meetings
- #10 Obligatorios Project Owner (PO): Debe haber un responsable por parte del cliente, quien debe priorizar, aceptar las entregas, gestionar las expectativas de los stakeholders (en conjunto al LP), y darle una visión y misión al proyecto. Project Manager (PM): Puede ser líder de proyecto, PM, etc. Alguien que sea responsable del proyecto, que gestione al equipo de trabajo, ayude al DP a gestionar las expectativas de los stakeholders, que sea responsable de promover la cultura de ESEMAP y velar por la correcta implementación de los procesos. Technical Referent (TR): Puede ser el mismo líder, el arquitecto o un desarrollador con experiencia. Debe haber alguien que sea la referencia técnica del proyecto. Desarrolladores: Las personas que se encargan de implementar la solución Testers: Las personas responsables de realizar el control de calidad sobre el proyecto / producto. Opcionales Cualquier rol se puede agregar, siempre y cuando se encuentren los obligatorios. Los roles opcionales los puede definir el equipo, el líder, la organización o el mismo cliente.
- #11 PWI: Requerimiento que agregue valor al negocio, no importa el formato de documentación, puede ser un CU, una historia de usuario, etc. Diferencias con Product Backlog (SCRUM): no entran bugs, ni tareas técnicas (a menos que den valor directo al negocio). Épicas: Si la unidad de medida para las estimaciones son horas, un pwi épico es cuando supera las 40hs. Si la unidad de medida adoptada por el equipo es diferente a la de horas (story point, story counts, manzanas, etc) debe definir el concepto de “épico” para dicha unidad de medida.
- #12 Se toman las disciplinas y fases del Proceso Unificado (UP)
- #14 Objetivo iteración: Se debe definir un objetivo para la iteración. 2 oraciones como mucho.
- #16 Opcionales – Otras: Cualquiera que el equipo / líder / organización determine Ordenar por prioridad: Marcar PWI impedidas: Como defina el equipo / líder / organización. Se recomienda con un sticker rojo con la letra ‘X’. Marcar dependencias: Como defina el equipo / líder / organización. Se recomienda solaparlas, situando de adelante hacia atrás la más prioritaria. Indicadores visuales: Los que defina el equipo / líder / organización y aporten valor. Ej: color por tipo tarea, etc.
- #18 Se recomienda reunión presencial: Si no es presencial, el PM debe realizar el refinamiento de forma constante
- #19 Frecuencia: Depende el proyecto, organización, disponibilidad de los recursos, etc. La frecuencia recomendada es 3 veces por semana. Timebox: 3’ máximo por integrante
- #20 Participación PO: Si el PO no puede participar, la demo se realiza igual. El objetivo es que el equipo se la auto-presente, donde cada integrante verá como se implementó cada IWI y podrá opinar si es como comprendió esa IWI o si cree que la misma está terminada.
- #21 Al finalizar cada iteración: Preferentemente después de las pruebas de usuario, sino después del testing. Se responden dos preguntas: Se revisa la retrospectiva anterior Se puede utilizar la técnica de retrospectiva que el líder / equipo / organización considere siempre y cuando realice los ítems especificados.
- #23 ESEMAP no impone una técnica, el líder / equipo / organización la decide. PM y RT definen sobre qué hacer Code Review: Esto puede depende de varios factores, se priorizan funcionalidades criticas, importantes, con mucha probabilidad de cambio, inestables, etc. También se tiene que considerar rotar las revisiones entre los integrantes del equipo
- #24 Check In Early, Check In Often: Mínimo una vez por día, siempre se debe subir funcionalidad que no afecte otras funcionalidades y que muestren avance. Código incompleto != Código roto Branching patterns: Se recomienda Release branching, se puede utilizar el que se determine como el más apropiado para el proyecto
- #25 Estimación & planificación: Se estima y planifica el testing de cada iteración. Profesionales calificados: Se debe prestar mucho énfasis en la calidad de registro de bugs y selección de criticidad. Mientras mejor y más completos estén los registros de bugs, más rápido resolverá el desarrollador el error. Mientras mejor seleccionada esté la criticidad, mejor podrá priorizar el PO y PM.