Índice
T1. AGILE Methodologies . 2
Waterfall Process . 2
Predictivo vs. Adaptativo . 3
Evolutive Process . 4
Introduction to Agile . 4
T2. SCRUM Methodology 6
Step 1: Product Backlog . 7
Step 2: Sprint Planning . 8
T3. User Stories 11
Product Backlog . 11
User Stories . 11
T4. Planning 14
Planning Poker . 14
Business Value . 15
Agile Planning . 15
T.5 KANBAN 17
T.6 CI/CD 21
Continuous Integration (CI) . 21
Continuous Delivery/Deployment (CD) . 21
T.7 Code Review 23
Code Review . 23
Static Code Analysis . 23
Dynamic Code Analysis . 24
T8. Time Management 25
T1. AGILE Methodologies .
---link diapos---
Habitualmente entendemos que el desarrollo del software es un proceso basado en
codificar y corregir.
PERO
⇒ Poca planificación y diseño
⇒ El diseño es un proceso cambiante
SOLO adecuado para pequeños proyectos.
La ⭐ ingeniería de software⭐ proporciona un proceso más estructurado y disciplinado.
⇨ Evita muchos bugs e ineficiencias las primeras etapas del desarrollo del proyecto.:)
⇨ Fuerte énfasis en la planificación. :)
⇨ La principal crítica es que hace que todo sea más burocrático. :(
CLASSIC ENGINEERING PROJECTS SOFTWARE DEVELOPMENT PROJECTS
✿ El diseño es el 15% del proceso ✿ Todo el esfuerzo está en el diseño
✿ El diseño y la construcción están (código fuente) y la construcción es muy
claramente diferenciados barata (compilador).
✿ El diseño es un proceso creativo y la ✿ El diseño de software es difícil de
construcción es menos intelectual y más planear.
manual. ✿ Incluso si usamos documentación
✿ El diseño puede ser validado para el diseño, solo se puede validar
matemáticamente. revisando el código.
Waterfall Process .
Enfoque sistemático y secuencial para el desarrollo de software.
Comienza a nivel de sistema y avanza a través del análisis, diseño, código y testing.
⇨ Fase de planificación detallada. Producto final cuidadosamente diseñado y
documentado en gran detalle.
⇨ El trabajo se organiza mediante herramientas como diagramas de Gantt y
aplicaciones como MSProyecto.
⇨ Las partes interesadas revisan el plan y siempre que lo aprueben, el equipo comienza
a trabajar.
⇨ Los miembros del equipo completan su parte especializada del trabajo.
⇨ Cuando se completa el trabajo, se entrega a la testing organization (Quality Assurance).
⇨ Durante el proceso, se colocan controles estrictos sobre las desviaciones del plan.
💪FORTALEZA: Es lógico, metódico, sigue un plan y mantiene todo organizado lo
💔DEBILIDAD: Los humanos están involucrados.
máximo posible.
RESUMEN: Antes de programar: mucho texto.
Real Life Problems using Waterfall .
➔ Los proyectos reales rara vez siguen el flujo secuencial, ya que siempre son
iterativos.
➔ Requiere que los requisitos se escriban explícitamente al principio, que suele ser
difícil.
➔ No hay un modelo funcional disponible hasta una fase avanzada del proyecto.
➔ Se hace gran énfasis en escribir para comunicar información crítica (en la realidad los
documentos de requisitos de 50 páginas altamente detallados no se suelen leer).
➔ La primera vez que usas el producto inmediatamente piensas en 20 formas en las
que podrías haberlo hecho mejor.
➔ Los humanos no son capaces de predecir el futuro o proponer planes de riesgo.
Predictivo vs. Adaptativo .
PROBLEMA: El desarrollo de software depende de requisitos. Si no puedes obtener
requisitos estables, no puedes obtener un plan predecible.
Si la situación no es predecible, la mayoría de los métodos para gestionar
proyectos son propensos al fracaso.
¿CÓMO MANEJAR SITUACIONES IMPREDECIBLES?
Lo más difícil es saber en qué punto se encuentra el proyecto.
Solución: metodologías evolutivas (que pueden adaptarse a nuevos cambios):
➢ Se harán versiones funcionales del proyecto final que tendrán un subconjunto de
funcionalidades en cada iteración.
➢ Estas versiones deben estar completamente integradas y tan cuidadosamente
testeadas como el proyecto final.
Evolutive Process .
Basado en la idea de desarrollar una primera implementación e ir perfeccionándola.
⇒ No es necesario un conocimiento profundo de los requisitos.
⇒ Se basa en el feedback del cliente.
⇒ El proyecto se divide en "builds"
⇒ El producto se muestra a los clientes muy pronto.
PROTOTIPO:
❑ Comienza con un requisito conocido
hasta este momento
❑ Se produce un diseño rápido
❑ El diseño rápido conduce a la
construcción del prototipo
❑ El prototipo es evaluado por el cliente
❑ Los requisitos se refinan
❑ El prototipo se ajusta para satisfacer las
necesidades del cliente
✓pros ✓ El prototipo se utiliza para identificar requisitos y se desarrolla muy rápido.
✗contras✗ Uso de algoritmo ineficiente y mucha prisa por hacer funcionar el
proyecto. La calidad general o el mantenimiento a largo plazo se pasan por alto.
Introduction to Agile .
Agile intenta simplificar los procesos de ingeniería de software, haciendo que estén
menos orientados a documentos y más al código.
Diferencias:
⇨ ✓adaptativos ✓ en lugar de ✗predictivos✗
💩
Los planes basados en la predicción son rígidos frente a los cambios (caca ). Los
cambios son una mecánica fundamental en las tecnologías ágiles.
⇨ ✓ orientados a personas ✓ en lugar de a ✗procesadores✗
En lugar de encontrar un buen método independientemente del equipo de trabajo, los
métodos ágiles intentan apoyar a los equipos actuales.
TRADITIONAL METHODOLOGIES AGILE METHODOLOGIES
✿ Las personas son partes reemplazables ✿ Los desarrolladores son profesionales
✿ Solo existen roles responsables:
✿ Hacen TODAS las decisiones técnicas
En un proceso predecible se ✿ Calculan el tiempo.
necesitan unidades predecibles, pero ✿ Managers y desarrolladores al mismo
las personas no son predecibles nivel de rol (los cambios tecnológicos son tan
y nos olvidamos de la creatividad rápidos que los managers apenas pueden hacerse
de cada individuo. (?xd) cargo y deben confiar en los desarrolladores).
Agile Methodologies .
SCRUM
⇒ Trabajo en equipo colaborativo.
⇒ Trabajo organizado en pequeños sprints con el objetivo de construir software
funcional utilizando equipos con experiencia cruzada.
eXtreme Programming (XP)
⇒ Trabajo en equipo organizado en parejas.
⇒ TDD (Test Driven Development). El testing impulsa el proyecto.
KANBAN
⇒ Transparencia del trabajo y comunicación en tiempo real.
⇒ Tablero Kanban: el trabajo del equipo gira en torno a él, dónde se visualiza y
optimiza el flujo del trabajo (y es reconocido como la única fuente verdadera).
LEAN
⇒ Lean Manufacturing. Conjunto de principios para lograr calidad, rapidez y
alineación al cliente.
⇒ Eliminar todo lo que no agregue valor y trabajar con lo que sea realmente necesario
en el momento.
Los Principios Ágiles Destacan:
⇨ Creación de software funcional accesible a la gente rápidamente (menos documentos
iniciales)
⇨ Centrado en equipos multifuncionales con poder para tomar decisiones.
⇨ Sin jerarquías y compartimentación por función.
⇨ Se centra en iteraciones rápidas con constante interacción con el cliente.
T2. SCRUM Methodology
---link diapos---
Metodología ágil
donde los productos
se construyen en una
serie de iteraciones.
4 pilares:
Planificación
Sprints, Stand Ups
(reuniones diarias),
Sprints y Retrospectivas.
Características:
😎
❑ Práctica ágil que desarrolla software hacia los clientes de forma más rápida, mejor y más
molona
❑ Apoya un enfoque creativo para el desarrollo
❑ Funciona para cualquier tipo de complejidad e innovación
❑ Escala linealmente a grandes números de desarrolladores
Es importante inspeccionar (el producto y la eficacia de las prácticas actuales) y
adaptar (los objetivos del producto y las prácticas del proceso).
Sprints .
❑ Son cortos y se llevan a cabo uno tras otro sin pausa.
❑ Tienen fecha límite.
❑ Cada Sprint se centra en los requisitos del cliente a partir de una lista de
prioridades.
❑ El equipo se compromete a completar los elementos al final del Sprint.
❑ Durante el Sprint, los elementos elegidos no cambian.
❑ Todos los días el equipo se reúne brevemente para inspeccionar su progreso y
ajustar los siguientes pasos.
❑ Al final del Sprint, el equipo revisa los elementos incluídos y demuestra lo que ha
construido.
❑ Feedback a tener en cuenta en el próximo Sprint.
Roles .
PRODUCT OWNER (PO)
Objetivo: maximizar el retorno de la inversión (ROI) identificando las características del
producto.
Medios: traducir los objetivos en una lista de prioridades.
Cómo: decide qué elementos deben estar en la parte superior de la lista para el
siguiente Sprint, y continuamente va repriorizándolos y refinando la lista.
En Scrum hay una y solo una persona con este rol y es el responsable del trabajo.
EQUIPO
Incluye análisis, diseño, codificación, pruebas, documentación para la entrega del
producto en cada Sprint.
Autogestión con un grado muy alto de autonomía y responsabilidad.
Cómo: el equipo decide con qué comprometerse y cuál es la mejor manera de hacerlo.
El tamaño del equipo es de siete (+-2)
SCRUM MASTER
Objetivo: ayudar al equipo y al PO.
Medios: Facilitar el proceso, apoyando al Equipo en su organización y autogestión.
No es el manager del equipo ni del proyecto.
ScrumMaster NO le dice a la gente qué, cómo hacer o asignar tareas.
Step 1: Product Backlog .
LA VISIÓN DEL PRODUCTO por parte del Product Owner
Evoluciona hacia una lista refinada y priorizada de funcionalidades llamada backlog.
❑ Existe (y evoluciona) durante la vida útil del producto.
❑ Es la hoja de ruta del producto.
❑ En cualquier momento es “Todo lo que puede hacer el equipo, en orden de prioridad”.
❑ Es una lista única.
Incluye:
➔ Funciones para el cliente ("permitir que todos los usuarios coloquen un libro en el carrito de la
compra")
➔ Metas de mejora de ingeniería (“reelaborar el procesamiento de transacciones para hacerlo
escalable")
➔ Trabajo exploratorio o de investigación (“investigar soluciones para acelerar la validación de la
tarjeta de crédito ")
➔ Defectos conocidos ("diagnosticar y corregir los errores del script de procesamiento de pedidos")
El subconjunto de funcionalidades que está destinado a la actual versión se conoce
como Release Backlog y es el enfoque principal del Product Owner.
Step 2: Sprint Planning .
Part 1 .
actores: Product Owner, Team & Scrum Master
Acciones:
1. Revisar los elementos de alta prioridad que al PO le interesa implementar.
2. Discutir los objetivos y revisar la “Definition of DONE” (generalmente codificado, revisado e
implementado con desarrollo impulsado por unit-test, testeado con 100% de automatización y
documentado).
Part 2 .
actores: Team
Acciones:
1. El equipo selecciona los elementos del Product Backlog que se compromete a
completar al final del Sprint.
2. Planificación de tareas detallada sobre cómo implementar los elementos.
3. El equipo decide cuánto trabajo se comprometerá a completar, en lugar de tenerlo
asignado.
*No incluye descansitos.
La parte 1 a menudo comienza con una discusión de diseño en una pizarra. En la parte 2,
el equipo comienza con el primer ítem del backlog y se van desglosando en tareas
individuales, que son registradas en un documento llamado Sprint Backlog.
Normalmente las tareas se clasifican en “In progress”, “Completed” y “Not yet started”.
During the Sprint .
Daily Scrum
❑ 5-15 min, todos los días a la hora señalada.
❑ Todos asisten, sin excepciones.
❑ Reunión de pie (no sentado 😉🤙
)
Cada miembro informa 3 cosas:
1. Qué se ha hecho desde la última reunión.
2. Qué planean hacer para la próxima reunión.
3. Cualquier impedimento o bloqueo en el camino.
Observaciones:
Dado que no hay un líder de equipo solo es una reunión de sincronización, no se
discuten ni informan de otros temas. Si hay algo que resolver, la gente puede organizar una
reunión después en la que el resto del equipo no es obligatorio que asista.
Updating Sprint Backlog
Cada día, se actualiza el Sprint Backlog con la cantidad estimada de tiempo restante.
Burndown Chart
Es la representación gráfica del
esfuerzo de cada día.
Idealmente ha de ir en descenso para
tener un esfuerzo restante de 0. No
muestra cuánto tiempo ha pasado el
equipo en el proyecto, pero sí cuánto
falta en el futuro.
Ending the Sprint
Regla: La duración NUNCA se extiende
Esto significa que en los primeros sprints el equipo no logra cumplir los compromisos.
Entonces eso se compensa seleccionando un número mucho menor de elementos.
Sprint Review
players: Product Owner, Scrum Master & Team
objetivo: Similar a una "demo" pero la idea es inspeccionar y adaptar. Conversación
entre PO y Team. ScrumMaster asegura que todos conozcan la “Definition of DONE” .
observaciones: Las tareas que no se realizan correctamente vuelven al Product
Backlog.
Sprint Retrospective
players: Scrum Master & Team
objetivo: Inspeccionar y adaptar el proceso.
observaciones: Documentar lo que está funcionando bien y qué podría funcionar mejor.
Ponerse de acuerdo en las causas y proponer cambios.
The New Sprint
La suma de todo el esfuerzo para el Release Backlog nos permite crear un Release Burndown
Chart.
"Todo está completamente terminado en cada Sprint" código, test, documentación…
T3. User Stories
---link diapos---
Product Backlog .
❑ Lista priorizada de todas las funciones y funcionalidades necesarias para completar
un proyecto.
❑ Incluye todo el trabajo que el proyecto requerirá y evolucionará con el tiempo
(también contiene bug fixes e investigación).
❑ Responde a las preguntas “¿qué estamos construyendo?” y “¿por qué lo estamos construyendo?” y
se captura en ítems de trabajo.
❑ Al principio, no suelen estar bien definidas y suelen haber muy pocas
funcionalidades especificadas.
User Stories .
Escribir historias (no tareas) sobre cuáles son las necesidades de la empresa y cómo
pueden cumplirse con el software.
Las 3 C’s .
CARD
Las historias se escriben tradicionalmente en tarjetas de notas (cards).
As a <role>
I want <goal>
So that <benefit>
Acceptance criteria: …
objetivo:
➔ Iniciar una conversación entre técnicos y gente de negocios desde un punto de vista
común.
➔ No es una especificación sobre la implementación.
CONFIRMATION
Los acceptance tests confirman si la historia se codificó correctamente a expectativas
del PO.
CONVERSATION
Los detalles detrás de las historias surgen durante las conversaciones con el PO.
INVEST .
Las User Stories deberían ser:
Independientes de manera que se puedan priorizar
Negociables el resultado debe ser la colaboración entre cliente y desarrollador, no un
contrato que seguir al pie de la letra
Valiosas So that <benefit(value)>
Estimable debe poder estimarse para que se pueda definir su prioridad (si es muy larga
igual tiene menos prioridad). Si no se puede estimar entonces se tiene que dividir en US
más claras.
Small Se sugiere 3-4 días de trabajo para cada US.
Testable Hacen falta criterios de aceptación para comprobarla.
*Epic: USs no tan definidas
Ciertas necesidades no se pueden expresar como una US:
➔ Una solicitud de cambio
➔ Una restricción: rendimiento requerido, base de datos a usar...
➔ Un requisito técnico: protocolo de comunicación, cumplimiento estándar de
seguridad...
🤢 MALAS USs 🤢
❍ Indicar guardado automático
❍ Agregar sugerencias y recordatorios de la funcionalidad de la interfaz de usuario.
❍ Corregir error # 127
❍ Disminuir el tiempo de carga *Son cosas técnicas que no tendría que pensar el usuario.
⚞ ✦ TIPS PARA BUENAS UserStories ✦ ⚟
⇨ Considerar los objetivos de cada rol de usuario al usar el sistema.
⇨ Al dividir una US, crear USs que atraviesen todas las capas de la aplicación.
⇨ Escribir USs más pequeñas para la funcionalidad más cercana y más largas para las
lejanas.
⇨ Mantener la interfaz de usuario fuera de las historias durante el mayor tiempo
posible.
⇨ Escribir historias para un solo usuario.
⇨ Hacer que el cliente, en lugar del desarrollador, escriba la historia.
⇨ Iniciar la conversación lo antes posible.
Case Study in Data Science .
➔ El proyecto es iterativo, ya que algunas decisiones deben ser tomadas en función de
los resultados (como las características o clasificadores escogidos).
➔ Las USs del backlog también se ven afectadas por el proceso de aprendizaje. Algunas
historias deben corresponder a la construcción de las funcionalidades (USs no orientadas
al usuario final).
➔ “The backlog even at epic level cannot be completed at the beginning of the project
as the number of machine learning improvement sprints to be executed is not known
when the project starts.”
➔ Las historias basadas en procesos de negocios pueden ser reemplazadas por
historias basadas en el proceso de aprendizaje automático.
🔨 Starting Product Backlog 🔧
1. Elegir un proyecto de ciencia de datos (theme)
2. Empezar con los epics
3. Descomponerlos en USs
T4. Planning
---link diapos---
Estimate User Stories .
actores: Team, PO.
No somos buenos midiendo el tiempo, pero sí comparando; los story points nos pueden
ayudar en la estimación.
no podemos decir la medida de cada pelota pero sí compararlas con las otras
Story Points .
Reflejan la grandeza de una US (su dificultad, su riesgo y cantidad), los valores relativos
importan, no tienen unidad e incluyen puntos de incertidumbre.
Estimation Techniques .
⇨ Expert opinion
⇨ Analogy
⇨ Planning Poker
Planning Poker .
Cada persona recibe una baraja de cartas del
1 al 20 (siguiendo la serie de Fibonacci) más ?
(inseguro), ∞(no se puede hacer) y pausa para el café
(que es lo mismo que decir 10 minutos).
1. Se lee la tarea a estimar.
2. Se piden aclaraciones sobre la tarea.
3. Cada persona elige una carta y la pone boca
abajo sobre la mesa.
4. Cuando todos lo hayan hecho, se dan la vuelta.
5. Si las estimaciones no coinciden, se debate y se vuelve al 3.
6. Cuando todos eligen la misma puntuación, se pasa a la siguiente tarea.
De este modo se evita la influencia de los otros participantes y se fuerza a la gente a
pensar de forma independiente. Además:
⇨ Quienes hacen el trabajo lo estiman. ⇨ Pensado para una discusión abierta.
😂 😂👍
⇨ Enfatiza la estimación relativa. ⇨ Fuerza el pensamiento.
⇨ Se escucha la opinión de todos. ⇨ ¡Es divertido!
Business Value .
⇨ Lo que puedes implementar con éxito y de forma sostenible.
⇨ Lo que tus clientes quieren y comprarán (incluso si aún no lo saben).
⇨ Lo que a tu equipo le entusiasma crear.
Estimate Business Value .
actores: Stakeholders & PO
Es el valor agregado que la story aporta al negocio. Debería ser lo mismo que los story
points, ya que se estima su valor en relación con los otros, y se resume en un número.
⚞ ✦ TIPS ✦ ⚟
⇨ Estima a nivel épico en vez de a nivel de US.
⇨ Coordínate con tu Departamento de Finanzas (ellos ya tienen una visión de production
function y métricas del ROI y les hará ilu que te involucres con ellos)
ROI (Return of Investment) .
AKA BusinessValue/StoryPoints
Es la relación entre el business value y la complejidad de una User Story.
😱 ¡EL PLANNING TRADICIONAL FALLA! 😱
❍ No es adaptativo.
❍ Se enfoca en actividades en vez de en
funcionalidades (nunca acaba pronto y genera dependencias).
❍ No tiene prioridades
❍ No tiene en cuenta que los clientes pueden cambiar
de opinión.
❍ Las estimaciones se convierten en compromisos.
Agile Planning .
⇨ La planificación es continua, no una fase independiente.
⇨ Se centra en las prioridades comerciales.
⇨ Se entrega algo en cada iteración.
⇨ Se esperan cambios por parte de los clientes.
⇨ Los planes se pueden corregir fácilmente.
⇨ Se planifica por función, no por actividad.
⇨ Definición clara de progreso (50% significa 50% de funcionalidades completadas)
Sprint Backlog .
1. Hacer el Product Backlog
2. Agregar valor
3. Estimar
4. Evaluar el riesgo
5. Priorizar por ROI (+ valor con - esfuerzo)
6. Tener en cuenta la velocidad del equipo al
seleccionar la cantidad de historias para el
siguiente sprint.
*Primero se hace la US con ROI 1, después la 2...
Velocidad:
Es la cantidad de puntos que completa el equipo en una iteración.
⇨ Fácil de medir después de la primera iteración.
Primera iteración: 1/3 del tiempo disponible (miembros del equipo x días)
⇨ Corrige errores de estimaciones.
⇨ Refleja fácilmente el estado del proyecto.
⇨ Parámetro principal en la planificación.
Burndown Charts (Gráficos de Evolución) .
⇨ Aumenta la visibilidad
⇨ Fácil de entender
⇨ Se actualiza inmediatamente
Task Planning .
Descomposición de las User Stories seleccionadas en tareas.
Para seguir el proceso: SCRUM + KANBAN = SCRUMBAN
T.5 KANBAN
---link diapos---
Kanban es una técnica para "tirar" del trabajo a lo largo de todo su ciclo de vida, lo
que hace que fluya más suave y un ritmo más rápido.
También arroja luz sobre las actividades que se suelen ocultar. Esta visibilidad
funciona a dos niveles, por actividades individuales y también durante el ciclo de vida.
La palabra "Kanban" es japonesa y significa "Tarjeta Visual".
Tarjeta Visual
🌸 KANBAN 🌸
The role of Kanban .
Kanban trata de mejorar la agilidad empresarial:
❍ ¿Con qué frecuencia se habla de los clientes?
❍ ¿Con qué frecuencia se necesita hacer algo una vez nos hemos comprometido?
❍ ¿Con qué frecuencia podemos implementar una nueva funcionalidad?
Kanban nos da algunas herramientas: cadencia de reposición, plazo de entrega, cadencia
de entrega (replenishment cadence, lead time, delivery cadence).
Goals of Kanban .
⇨ Minimizar los retrasos
⇨ Mejorar la calidad
⇨ Entregar pronto y frecuentemente
⇨ Equilibrar la demanda-rendimiento
⇨ Mejorar la previsibilidad
⇨ Priorizar los resultados
Principles of Kanban .
⇨ Visualizar el trabajo.
⇨ Limitar el Work in Progress.
⇨ Hacer explícitas las políticas.
⇨ Medir y administrar el flujo de trabajo.
Kanban Lanes (carriles) .
El primer paso para visualizar el flujo de trabajo es comprender su proceso actual:
¿Dónde está ahora?
➔ Estoy trabajando en ello, así que diría "está en desarrollo".
➔ Estoy terminado pero aún no se ha testeado, así que diría “está esperando a ser
testeado”
¿A dónde irá?
➔ Cuando termine, estará listo para los tests.
➔ Una vez se testee estará listo para la integración.
¿Dónde estaba antes?
➔ El analista de negocios lo tiene ante mí pero yo no he comenzado con él todavía, así
que diría que está analizado o listo para desarrollo.
❑ Los lanes (carriles) describen acciones
❑ Las cards describen cosas que tienen valor y que los equipos cumplen (US, Tareas)
Cualquier proyecto se puede reducir en:
Y se pueden añadir carriles para test u otros.
Kanban Wall .
Para cada tarea, escribimos la respuesta a la siguientes preguntas:
❍ ¿Qué tipo de trabajo es?
❍ ¿Dónde está ahora?
❍ ¿Dónde estaba antes de que lo tomara?
❍ ¿A dónde irá una vez que termine mi trabajo?
¡¡Limita tu Work In Progress!!
Kanban se trata de mantener el flujo, hace falta poner límites al trabajo que no
podremos realizar.
Don’t push, pull instead
Usamos un sistema de pull, para que no haya roces entre equipos. El problema es que
cuando hay varios equipos interdependientes, el equipo más lento puede bloquear todo
el proceso. Por eso es necesario usar colas(queues) con una capacidad máxima.
Task Assignment .
Si alguien acaba una tasca, podemos asistir a otro miembro del equipo si es necesario y
directamente hacer pull. Si acabamos, volvemos al equipo general a hacer enjambre.
Regla: Centrarse en el ítem de más a la derecha.
Si hay un bug y la tarea no se puede dar por acabada tenemos 2 opciones:
A) Redefinir el control de calidad como prueba y corrección de errores.
=> ENJAMBRE EN EL ERROR
B) Poner un nuevo ítem en TODO como “bug” (!= mover el ítem al principio)
Makes Policies Explicit .
Hacer políticas explícitas define el proceso de garantía de calidad (QA).
En Kanban, esto se hace agregando una descripción de la política de calidad para seguir
siempre que una tarea transicione a una determinada etapa:
Cuando se introduce una tarea, se le escribe la fecha. A medida que se extrae un
elemento a WIP también, y finalmente, cuando un elemento en DONE.
¡MIDE EL FLUJO DE TRABAJO!
Diagrama de flujo acumulativo: cada día marca cuántas tareas hay en cada columna.
Verticalmente, un punto en el gráfico nos
informa sobre el trabajo en progreso.
Horizontalmente nos informa sobre la
duración de las tareas. Se definen dos
conceptos:
PLAZO DE APLICACIÓN: tiempo entre la
iniciación y la entrega de un artículo (lo que
los clientes ven).
TIEMPO DEL CICLO: Hora entre el inicio y
la finalización de un artículo. Una medida
de real de la capacidad del proceso
También podemos medir el rendimiento (ÍTEMS / TIEMPO).
Conclusion .
Escoger una mezcla entre SCRUM y KANBAN (¡SCRUMBAN!)
❍ SCRUM iteraciones y artefactos: Backlogs, Sprint, Daily meetings, Revision y
Retrospective
❍ tablero KANBAN: Para visualizar y llevar el progreso durante los sprints y limitar el
trabajo en progreso.
T.6 CI/CD
---link diapos---
Continuous Design .
Se basa en crear y modificar el diseño de un sistema a medida que se desarrolla.
Implica el uso de TDD (Test Driven Development) y Refactoring.
Continuous Testing .
Es el proceso de ejecución de tests automatizados como parte de la metodología
Agile. Proporciona feedback rápido y continuo.
⇨ Requisitos Funcionales: tests unitarios, API testing, Integration Testing, System
Testing…
⇨ Requisitos NO funcionales: static code analysis, security testing, performance
testing…
Testing Common Practices .
❍ El Testing debe ser una colaboración con el Desarrollo, QA (Control de Calidad) y
Operations
❍ Los tests deben ser lógicos, incrementales y repetibles. Los resultados deben ser
deterministas y significativos.
❍ Todos los tests deben ejecutarse en algún momento del proceso de compilación,
pero no es necesario que se ejecuten todos todo el tiempo.
❍ Hay que eliminar los datos generados por los tests y las limitaciones del entorno
para que los tests se puedan ejecutar de forma constante y coherente en ambientes de
producción.
❍ Los equipos deben enfatizar el API testing sobre el GUI testing.
Continuous Integration (CI) .
Es la práctica de fusionar todas las copias de trabajo de los desarrolladores en un
línea de código de "devel" compartida varias veces al día.
Flujo de trabajo:
⇒ Ejecutar tests localmente (ejecutar y pasar tests unitarios)
⇒ Compilar código en CI (después de cada commit compilar en el build server)
⇒ Ejecutar tests en CI (ejecutar tests unitarios, de integración… en el build server )
⇒ Ready to Deploy un artefacto del CI (el código del builder server está listo para el CD)
Continuous Delivery/Deployment (CD) .
Continuous Delivery: se asegura de que el software registrado en la línea "dev"
siempre esté en estado de deploy.
Continuous Deployment: hace el proceso de deployment completamente automático.
CI/CD Best Practices .
⇨ Mantener un repositorio de código
⇨ Automatizar el build
⇨ Realizar el self-testing del build
⇨ Todo el mundo commitea a la baseline cada día
⇨ Cada commit (a baseline) debe ser buildeado
⇨ Cada bug-fix commit debe ir con un test case
⇨ Mantener un build rápido
⇨ Testear en un clon del entorno de producción
⇨ Facilitar la obtención de los últimos deliveries
⇨ Todos pueden ver los resultados del último build
⇨ Automatizar el deployment
Cloud Services for CI/CD .
SaaS: Software as a Service
PaaS: Platform as a Service
SaaS y PaaS para CI/CD: Github + Travis + Heroku
T.7 Code Review
---link diapos---
Static Code Review:
⇨ Code Review
⇨ Static Code Analysis
Code Review .
AKA Peer Review (by humans)
Una o varias personas revisan un programa viendo y leyendo partes del código, sin
ejecutarlo. Los revisores no son los autores del código.
⇨ Mejor calidad del código
⇨ Encontrar defectos
⇨ Transferencia de aprendizaje/conocimiento
⇨ Incrementar el sentido de responsabilidad mútua
⇨ Encontrar mejores soluciones
⇨ Cumplir las pautas del control de calidad (obligatorio en algunos contextos)
Static Code Analysis .
by QA software tools
Code Review hecho por herramientas automatizadas:
⇨ Destaca posibles errores del código
⇨ Métodos formales que demuestran propiedades de un programa
Niveles de Análisis de Software:
❍ UNIT LEVEL. sin un programa o rutina específica, sin conectarse al contexto.
❍ TECHNOLOGY LEVEL. tiene en cuenta las interacciones entre programas unitarios.
❍ SYSTEM LEVEL. tiene en cuenta las interacciones entre programas unitarios pero sin
estar limitado a una tecnología específica o lenguaje de programación.
❍ MISSION/BUSINESS LEVEL. tiene en cuenta los términos de la capa de
misión/negocio.
Dynamic Code Analysis .
Análisis hecho en programas mientras se ejecutan.
⇨ Cobertura del código: cuánto código fuente se ejecuta mediante el código de prueba.
⇨ Detección de errores de memoria
⇨ Análisis de seguridad
⇨ Errores de Concurrencia
⇨ Análisis de rendimiento: mide la complejidad de espacio o tiempo del programa, el
uso de particulares instrucciones o la frecuencia y duración de las llamadas a funciones.
T8. Time Management
---link diapos---
⚞ ✦ TIPS ✦ ⚟
❑ Fijar Objetivos: ✩da significado a tu trabajo✩
❑ Ser proactivo: céntrate en una cosa a la vez
❑ Evita el estrés de la fecha límite: haz un buen planning
🧐
❑ Timeboxing:
😴
☛ Seguimiento del tiempo
😡
☛ Desconecta
☛ Evita distracciones
📊 Análisis PARETO 📊
objetivo: priorizar tareas que son más efectivas para resolver problemas.
⇒ Haz una lista de los problemas a los que te estás enfrentando.
⇒ Identifica la raíz de la causa de cada problema.
⇒ Asigna una puntuación a cada problema (mayor puntuación, mayor importancia)
⇒ Agrupa los problemas según su causa
⇒ Añade una puntuación a cada grupo
⇒ ¡Actúa!
🍅Técnica del POMODORO 🍅
1. Escoge una tarea
2. Pon una alarma en 25 minutos
3. Trabaja hasta que acabe el tiempo (¡SIN DISTRACCIONES!)
4. Descansito de 5 mins
5. Cada 4 pomodoros → descansito de 15-30 mins
🎛️ Matriz de EISENHOWER 🎛️
⇒ Organiza tus tareas en 4 cuadrantes:
Urgentes: necesitan completarse inmediatamente
Importantes: contribuyen a los objetivos a largo
plazo.
Solo se debería trabajar en las tareas de los 2
cuadrantes superiores.
📜 Ley de PARKINSON 📜
“work expands so as to fill the time available for its completion.”
😜
⇒ Intenta trabajar sin el cargador del ordenador (¡te forzará a terminar el trabajo antes de
que tu ordenador se muera! A menos que tu batería dure unas 12h, que entonces gg)
⇒ ¡Acabalo rápido! en vez de acabar algo a medianoche, acabalo al anochecer.
⇒ Fija una fecha límite.
⇒ Limita el tiempo para las tareas.
⏱️ Método Time-Blocking ⏱️
Desde que te levantas, asigna cada ¿¿¿bloque de tiempo de tu día??? en una tarea.
⇒ 2 columnas: a la izquierda, escribe cada hora del día en bloques de 1 o media hora.
⇒ Estima el tiempo que vas a tardar en completar cada tarea y encajalo en los bloques.
⇒ Añade tiempo extra entre cada bloque para tener permitir reajustes.
✅ Método GTD (Getting Things Done) ✅
⇒ Captura las acciones que llaman tu atención.
⇒ Especifica qué significan. decide si son importantes o no.
⇒ Organiza las acciones. prioriza las acciones que necesitas que se hagan.
⇒ Reflexiona. revisa tu lista de acciones frecuentemente para determinar cuál será tu
siguiente prioridad. Tacha las acciones que ya has cumplido.
⇒ Comprométete. toma acciones que puedas cumplir justo ahora
⚱️ La teoría de la Pickle Jar ⚱️
esto no es un bote de pepinillos. esto sí es.
Sand: interrupciones en el día
Pebbles: tareas que no son urgentes o las puede hacer otra persona
Rocks: tareas importantes y urgentes
Haz una lista empezando con las rocas y acabando con la arena. Incluye una estimación
del tiempo al lado. Intenta no planear más de 6-8h de trabajo diario.
🐸 Eat That Frog 🐸
“Eat a live frog the first thing in the morning and nothing worse will happen to you the rest of the
day.” - Mark Twain
⇒ Sé claro en un objetivo.
⇒ Escríbelo.
⇒ Fija una fecha límite.
⇒ Haz una lista de todas las cosas que debes hacer para cumplirlo.
⇒ Organiza la lista en orden de prioridad. Las tareas más importantes serán
probablemente las más difíciles: tus ranas.
⇒ Actúa. Si tienes más de una rana en el plato cómete la más asquerosa. (bro que cojones) (la
idea es hacer lo más jodido lo primero para que pienses que el resto del día ha sido sencillito)
⇒ Repite el ciclo cada día para así estar siempre haciendo algo que te impulse a tu
objetivo.
Un claro ejemplo de éxito de esta técnica está en el joven famoso Tom Holland, que, gracias a un
seguimiento estricto de Eat That Frog ha logrado protagonizar un total de 32 películas a sus 25 años.
☀ ¿Quieres saber cuál de las técnicas anteriores te ayudará más ☀
❀ según tu personalidad? ❀
⚞ ¡Mira la tabla de abajo para descubrirlo! ⚟
