cosas que me faltaron poner de cuando hicimos la presetnacion de crystal

administracion/crystal.org

@@ -0,0 +1,115 @@
+#+title: Informe sobre la Metodología Ágil Crystal
+#+author: Federico Polidoro, Luca Troiano, Francisco Rose Cerna
+#+date: 2025-11-07
+#+language: es
+#+options: toc:t num:t
+
+* Introducción
+Crystal es una familia de metodologías ágiles desarrollada por *Alistair Cockburn* a fines de los años 90.
+A diferencia de enfoques más estructurados como *Scrum* o *Extreme Programming (XP)*, Crystal parte de una idea simple pero poderosa:
+las *personas* y sus *interacciones* son más importantes que los procesos y las herramientas.
+
+** 
+Su objetivo es *ajustar la metodología al contexto del proyecto*, en lugar de imponer una única forma de trabajo.
+En otras palabras, Crystal no es una receta, sino un *espectro de métodos* adaptables.
+
+* Filosofía y Principios
+Crystal considera que cada proyecto es único y debe gestionarse según su contexto.  
+Tres factores determinan qué variante de Crystal usar:
+
+** 
+- Tamaño del equipo.
+- Criticidad del sistema (el riesgo que implica un fallo).
+- Prioridad de entrega rápida.
+
+** 
+A partir de esto, Cockburn propone distintas variantes, por ejemplo:
+- *Crystal Clear*: para equipos pequeños (1–6 personas) y baja criticidad.
+- *Crystal Yellow / Orange / Red*: para equipos medianos o grandes, y sistemas de mayor riesgo.
+
+Cuanto más grande y crítico el proyecto, más formal y estructurado se vuelve el proceso.
+
+* Principios Fundamentales
+Los valores clave que guían Crystal son:
+
+1. Comunicación frecuente y directa.
+2. Reflexión y mejora continua.
+3. Entrega frecuente de software funcional.
+4. Seguridad personal dentro del equipo.
+5. Atención a la calidad técnica.
+6. Foco en las personas por encima del proceso.
+
+* Características Principales
+Crystal es *ligero* en procesos y documentación.  
+Algunas características típicas incluyen:
+
+** 
+- Iteraciones cortas (2 a 4 semanas).
+- Revisión frecuente con el cliente.
+- Planificación adaptativa.
+- Reuniones retrospectivas periódicas.
+- Entrega de software operativo en cada iteración.
+- Integración continua (opcional pero recomendable).
+
+Cockburn describe esto como “oscuridad progresiva”: cuanto más grande el proyecto, más *oscuro* (estructurado) se vuelve el cristal.
+
+* Ventajas
+- Alta flexibilidad y adaptabilidad.
+- Fuerte enfoque humano, mejora la moral y colaboración.
+- Ideal para proyectos pequeños o medianos.
+- Promueve la entrega continua de valor real al cliente.
+
+* Desventajas
+- Puede parecer demasiado informal para organizaciones grandes.
+- Depende mucho de la comunicación efectiva del equipo.
+- Difícil de escalar sin agregar estructura (lo que la aleja de su esencia).
+
+* Roles en Crystal
+Crystal no define roles rígidos como Scrum, pero suelen surgir de forma natural:
+
+- *Patrocinador o cliente*: define visión y prioridades.
+- *Desarrolladores, diseñadores y testers*: responsables del producto.
+- *Coordinador*: facilita la comunicación y el ritmo del equipo (similar al Scrum Master).
+
+El equipo se autogestiona y las decisiones se toman por consenso.
+
+* Documentación y Comunicación
+Crystal privilegia la comunicación oral y visual por sobre la documentación extensa.  
+Los documentos existen, pero solo cuando mejoran la comunicación o la comprensión general del proyecto.  
+
+** 
+En palabras de Cockburn:
+#+begin_quote
+“La documentación es útil solo si mejora la comunicación o la comprensión.”
+#+end_quote
+
+* Casos de Uso
+Crystal se utiliza principalmente en:
+
+- Proyectos internos de software con equipos pequeños.
+- Entornos donde se valora la autonomía y la flexibilidad.
+- Startups o empresas en crecimiento que buscan evitar la rigidez de Scrum o SAFe.
+
+* Comparación
+| Aspecto         | Crystal                      | Scrum                       | XP                     |
+|-----------------+------------------------------+-----------------------------+------------------------|
+| Enfoque         | Adaptativo según el contexto | Estructurado                | Técnico y disciplinado |
+| Roles definidos | No estrictos                 | Sí (Scrum Master, PO, Team) | Sí                     |
+
+** 
+| Documentación   | Mínima                       | Moderada                    | Mínima                 |
+| Escalabilidad   | Limitada                     | Media                       | Baja                   |
+| Prioridad       | Personas y comunicación      | Entrega por sprint          | Calidad técnica        |
+* Conclusión
+Crystal es una metodología ágil profundamente *humana* y *contextual*.  
+En lugar de imponer reglas, enseña principios: cómo pensar, más que qué hacer.
+
+Su mayor fortaleza es también su debilidad: la libertad.  
+Si el equipo es maduro y comunicativo, Crystal permite moverse rápido y con mínima burocracia.  
+Si no lo es, puede caer fácilmente en el caos.
+
+** En resumen:
+#+begin_quote
+Crystal es la metodología ágil que confía más en las personas que en el proceso.
+#+end_quote
+ 

administracion/informe-crystal.html

@@ -0,0 +1,422 @@
+<!DOCTYPE html>
+<html lang="es">
+<head>
+  <meta charset="utf-8">
+  <meta name="generator" content="pandoc">
+  <meta name="author" content="Federico Polidoro, Luca Troiano, Francisco Rose Cerna">
+  <meta name="dcterms.date" content="2025-11-07">
+  <title>Informe sobre la Metodología Ágil Crystal</title>
+  <meta name="apple-mobile-web-app-capable" content="yes">
+  <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui">
+  <link rel="stylesheet" href="https://unpkg.com/reveal.js@5/dist/reset.css">
+  <link rel="stylesheet" href="https://unpkg.com/reveal.js@5/dist/reveal.css">
+  <style>
+    .reveal .sourceCode {  /* see #7635 */
+      overflow: visible;
+    }
+    code{white-space: pre-wrap;}
+    span.smallcaps{font-variant: small-caps;}
+    div.columns{display: flex; gap: min(4vw, 1.5em);}
+    div.column{flex: auto; overflow-x: auto;}
+    div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
+    /* The extra [class] is a hack that increases specificity enough to
+       override a similar rule in reveal.js */
+    ul.task-list[class]{list-style: none;}
+    ul.task-list li input[type="checkbox"] {
+      font-size: inherit;
+      width: 0.8em;
+      margin: 0 0.8em 0.2em -1.6em;
+      vertical-align: middle;
+    }
+    .display.math{display: block; text-align: center; margin: 0.5rem auto;}
+  </style>
+  <link rel="stylesheet" href="https://unpkg.com/reveal.js@5/dist/theme/black.css" id="theme">
+</head>
+<body>
+  <div class="reveal">
+    <div class="slides">
+
+<section id="title-slide">
+  <h1 class="title">Informe sobre la Metodología Ágil Crystal</h1>
+  <p class="author">Federico Polidoro, Luca Troiano, Francisco Rose
+Cerna</p>
+  <p class="date">2025-11-07</p>
+</section>
+
+<section>
+<section id="introducción" class="title-slide slide level1">
+<h1>Introducción</h1>
+<p>Crystal es una familia de metodologías ágiles desarrollada por
+<strong>Alistair Cockburn</strong> a fines de los años 90. A diferencia
+de enfoques más estructurados como <strong>Scrum</strong> o
+<strong>Extreme Programming (XP)</strong>, Crystal parte de una idea
+simple pero poderosa: las <strong>personas</strong> y sus
+<strong>interacciones</strong> son más importantes que los procesos y
+las herramientas.</p>
+</section>
+<section id="section" class="slide level2">
+<h2></h2>
+<p>Su objetivo es <strong>ajustar la metodología al contexto del
+proyecto</strong>, en lugar de imponer una única forma de trabajo. En
+otras palabras, Crystal no es una receta, sino un <strong>espectro de
+métodos</strong> adaptables.</p>
+</section></section>
+<section>
+<section id="filosofía-y-principios" class="title-slide slide level1">
+<h1>Filosofía y Principios</h1>
+<p>Crystal considera que cada proyecto es único y debe gestionarse según
+su contexto. Tres factores determinan qué variante de Crystal usar:</p>
+</section>
+<section id="section-1" class="slide level2">
+<h2></h2>
+<ul>
+<li>Tamaño del equipo.</li>
+<li>Criticidad del sistema (el riesgo que implica un fallo).</li>
+<li>Prioridad de entrega rápida.</li>
+</ul>
+</section>
+<section id="section-2" class="slide level2">
+<h2></h2>
+<p>A partir de esto, Cockburn propone distintas variantes, por
+ejemplo:</p>
+<ul>
+<li><strong>Crystal Clear</strong>: para equipos pequeños (1–6 personas)
+y baja criticidad.</li>
+<li><strong>Crystal Yellow / Orange / Red</strong>: para equipos
+medianos o grandes, y sistemas de mayor riesgo.</li>
+</ul>
+<p>Cuanto más grande y crítico el proyecto, más formal y estructurado se
+vuelve el proceso.</p>
+</section></section>
+<section id="principios-fundamentales" class="title-slide slide level1">
+<h1>Principios Fundamentales</h1>
+<p>Los valores clave que guían Crystal son:</p>
+<ol>
+<li>Comunicación frecuente y directa.</li>
+<li>Reflexión y mejora continua.</li>
+<li>Entrega frecuente de software funcional.</li>
+<li>Seguridad personal dentro del equipo.</li>
+<li>Atención a la calidad técnica.</li>
+<li>Foco en las personas por encima del proceso.</li>
+</ol>
+</section>
+
+<section>
+<section id="características-principales"
+class="title-slide slide level1">
+<h1>Características Principales</h1>
+<p>Crystal es <strong>ligero</strong> en procesos y documentación.
+Algunas características típicas incluyen:</p>
+</section>
+<section id="section-3" class="slide level2">
+<h2></h2>
+<ul>
+<li>Iteraciones cortas (2 a 4 semanas).</li>
+<li>Revisión frecuente con el cliente.</li>
+<li>Planificación adaptativa.</li>
+<li>Reuniones retrospectivas periódicas.</li>
+<li>Entrega de software operativo en cada iteración.</li>
+<li>Integración continua (opcional pero recomendable).</li>
+</ul>
+<p>Cockburn describe esto como “oscuridad progresiva”: cuanto más grande
+el proyecto, más <strong>oscuro</strong> (estructurado) se vuelve el
+cristal.</p>
+</section></section>
+<section id="ventajas" class="title-slide slide level1">
+<h1>Ventajas</h1>
+<ul>
+<li>Alta flexibilidad y adaptabilidad.</li>
+<li>Fuerte enfoque humano, mejora la moral y colaboración.</li>
+<li>Ideal para proyectos pequeños o medianos.</li>
+<li>Promueve la entrega continua de valor real al cliente.</li>
+</ul>
+</section>
+
+<section id="desventajas" class="title-slide slide level1">
+<h1>Desventajas</h1>
+<ul>
+<li>Puede parecer demasiado informal para organizaciones grandes.</li>
+<li>Depende mucho de la comunicación efectiva del equipo.</li>
+<li>Difícil de escalar sin agregar estructura (lo que la aleja de su
+esencia).</li>
+</ul>
+</section>
+
+<section id="roles-en-crystal" class="title-slide slide level1">
+<h1>Roles en Crystal</h1>
+<p>Crystal no define roles rígidos como Scrum, pero suelen surgir de
+forma natural:</p>
+<ul>
+<li><strong>Patrocinador o cliente</strong>: define visión y
+prioridades.</li>
+<li><strong>Desarrolladores, diseñadores y testers</strong>:
+responsables del producto.</li>
+<li><strong>Coordinador</strong>: facilita la comunicación y el ritmo
+del equipo (similar al Scrum Master).</li>
+</ul>
+<p>El equipo se autogestiona y las decisiones se toman por consenso.</p>
+</section>
+
+<section>
+<section id="documentación-y-comunicación"
+class="title-slide slide level1">
+<h1>Documentación y Comunicación</h1>
+<p>Crystal privilegia la comunicación oral y visual por sobre la
+documentación extensa. Los documentos existen, pero solo cuando mejoran
+la comunicación o la comprensión general del proyecto.</p>
+</section>
+<section id="section-4" class="slide level2">
+<h2></h2>
+<p>En palabras de Cockburn:</p>
+<blockquote>
+<p>“La documentación es útil solo si mejora la comunicación o la
+comprensión.”</p>
+</blockquote>
+</section></section>
+<section id="casos-de-uso" class="title-slide slide level1">
+<h1>Casos de Uso</h1>
+<p>Crystal se utiliza principalmente en:</p>
+<ul>
+<li>Proyectos internos de software con equipos pequeños.</li>
+<li>Entornos donde se valora la autonomía y la flexibilidad.</li>
+<li>Startups o empresas en crecimiento que buscan evitar la rigidez de
+Scrum o SAFe.</li>
+</ul>
+</section>
+
+<section>
+<section id="comparación" class="title-slide slide level1">
+<h1>Comparación</h1>
+<table>
+<thead>
+<tr>
+<th>Aspecto</th>
+<th>Crystal</th>
+<th>Scrum</th>
+<th>XP</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>Enfoque</td>
+<td>Adaptativo según el contexto</td>
+<td>Estructurado</td>
+<td>Técnico y disciplinado</td>
+</tr>
+<tr>
+<td>Roles definidos</td>
+<td>No estrictos</td>
+<td>Sí (Scrum Master, PO, Team)</td>
+<td>Sí</td>
+</tr>
+</tbody>
+</table>
+</section>
+<section id="section-5" class="slide level2">
+<h2></h2>
+<table>
+<tbody>
+<tr>
+<td>Documentación</td>
+<td>Mínima</td>
+<td>Moderada</td>
+<td>Mínima</td>
+</tr>
+<tr>
+<td>Escalabilidad</td>
+<td>Limitada</td>
+<td>Media</td>
+<td>Baja</td>
+</tr>
+<tr>
+<td>Prioridad</td>
+<td>Personas y comunicación</td>
+<td>Entrega por sprint</td>
+<td>Calidad técnica</td>
+</tr>
+</tbody>
+</table>
+</section></section>
+<section>
+<section id="conclusión" class="title-slide slide level1">
+<h1>Conclusión</h1>
+<p>Crystal es una metodología ágil profundamente <strong>humana</strong>
+y <strong>contextual</strong>. En lugar de imponer reglas, enseña
+principios: cómo pensar, más que qué hacer.</p>
+<p>Su mayor fortaleza es también su debilidad: la libertad. Si el equipo
+es maduro y comunicativo, Crystal permite moverse rápido y con mínima
+burocracia. Si no lo es, puede caer fácilmente en el caos.</p>
+</section>
+<section id="en-resumen" class="slide level2">
+<h2>En resumen:</h2>
+<blockquote>
+<p>Crystal es la metodología ágil que confía más en las personas que en
+el proceso.</p>
+</blockquote>
+</section></section>
+    </div>
+  </div>
+
+  <script src="https://unpkg.com/reveal.js@5/dist/reveal.js"></script>
+
+  <!-- reveal.js plugins -->
+  <script src="https://unpkg.com/reveal.js@5/plugin/notes/notes.js"></script>
+  <script src="https://unpkg.com/reveal.js@5/plugin/search/search.js"></script>
+  <script src="https://unpkg.com/reveal.js@5/plugin/zoom/zoom.js"></script>
+
+  <script>
+
+      // Full list of configuration options available at:
+      // https://revealjs.com/config/
+      Reveal.initialize({
+        // Display controls in the bottom right corner
+        controls: true,
+
+        // Help the user learn the controls by providing hints, for example by
+        // bouncing the down arrow when they first encounter a vertical slide
+        controlsTutorial: true,
+
+        // Determines where controls appear, "edges" or "bottom-right"
+        controlsLayout: 'bottom-right',
+
+        // Visibility rule for backwards navigation arrows; "faded", "hidden"
+        // or "visible"
+        controlsBackArrows: 'faded',
+
+        // Display a presentation progress bar
+        progress: true,
+
+        // Display the page number of the current slide
+        slideNumber: false,
+
+        // 'all', 'print', or 'speaker'
+        showSlideNumber: 'all',
+
+        // Add the current slide number to the URL hash so that reloading the
+        // page/copying the URL will return you to the same slide
+        hash: true,
+
+        // Start with 1 for the hash rather than 0
+        hashOneBasedIndex: false,
+
+        // Flags if we should monitor the hash and change slides accordingly
+        respondToHashChanges: true,
+
+        // Push each slide change to the browser history
+        history: false,
+
+        // Enable keyboard shortcuts for navigation
+        keyboard: true,
+
+        // Enable the slide overview mode
+        overview: true,
+
+        // Disables the default reveal.js slide layout (scaling and centering)
+        // so that you can use custom CSS layout
+        disableLayout: false,
+
+        // Vertical centering of slides
+        center: true,
+
+        // Enables touch navigation on devices with touch input
+        touch: true,
+
+        // Loop the presentation
+        loop: false,
+
+        // Change the presentation direction to be RTL
+        rtl: false,
+
+        // see https://revealjs.com/vertical-slides/#navigation-mode
+        navigationMode: 'default',
+
+        // Randomizes the order of slides each time the presentation loads
+        shuffle: false,
+
+        // Turns fragments on and off globally
+        fragments: true,
+
+        // Flags whether to include the current fragment in the URL,
+        // so that reloading brings you to the same fragment position
+        fragmentInURL: true,
+
+        // Flags if the presentation is running in an embedded mode,
+        // i.e. contained within a limited portion of the screen
+        embedded: false,
+
+        // Flags if we should show a help overlay when the questionmark
+        // key is pressed
+        help: true,
+
+        // Flags if it should be possible to pause the presentation (blackout)
+        pause: true,
+
+        // Flags if speaker notes should be visible to all viewers
+        showNotes: false,
+
+        // Global override for autoplaying embedded media (null/true/false)
+        autoPlayMedia: null,
+
+        // Global override for preloading lazy-loaded iframes (null/true/false)
+        preloadIframes: null,
+
+        // Number of milliseconds between automatically proceeding to the
+        // next slide, disabled when set to 0, this value can be overwritten
+        // by using a data-autoslide attribute on your slides
+        autoSlide: 0,
+
+        // Stop auto-sliding after user input
+        autoSlideStoppable: true,
+
+        // Use this method for navigation when auto-sliding
+        autoSlideMethod: null,
+
+        // Specify the average time in seconds that you think you will spend
+        // presenting each slide. This is used to show a pacing timer in the
+        // speaker view
+        defaultTiming: null,
+
+        // Enable slide navigation via mouse wheel
+        mouseWheel: false,
+
+        // The display mode that will be used to show slides
+        display: 'block',
+
+        // Hide cursor if inactive
+        hideInactiveCursor: true,
+
+        // Time before the cursor is hidden (in ms)
+        hideCursorTime: 5000,
+
+        // Opens links in an iframe preview overlay
+        previewLinks: false,
+
+        // Transition style (none/fade/slide/convex/concave/zoom)
+        transition: 'slide',
+
+        // Transition speed (default/fast/slow)
+        transitionSpeed: 'default',
+
+        // Transition style for full page slide backgrounds
+        // (none/fade/slide/convex/concave/zoom)
+        backgroundTransition: 'fade',
+
+        // Number of slides away from the current that are visible
+        viewDistance: 3,
+
+        // Number of slides away from the current that are visible on mobile
+        // devices. It is advisable to set this to a lower number than
+        // viewDistance in order to save resources.
+        mobileViewDistance: 2,
+
+        // reveal.js plugins
+        plugins: [
+          RevealNotes,
+          RevealSearch,
+          RevealZoom
+        ]
+      });
+    </script>
+    </body>
+</html>

administracion/scrumxp.md

@@ -0,0 +1,102 @@
+# Qué es ScrumXP (resumen corto)
+
+**ScrumXP** no es un nuevo framework mágico: es usar **Scrum** como marco de trabajo para organizar el equipo y la cadencia (sprints, eventos, roles, backlog) y complementar eso con **prácticas técnicas** de eXtreme Programming (XP) — tests automáticos, integración continua, pair programming, refactor, diseño simple, releases frecuentes — para que lo que Scrum planifica termine siendo software de calidad y sostenible. En otras palabras: Scrum da la estructura; XP da la disciplina técnica. ([Scrum.org][1])
+
+# Por qué combinarlas (beneficios principales)
+
+* Acelera entrega de valor real y desactiva la deuda técnica (porque XP obliga a tests y refactor).
+* Reduce riesgo: releases pequeñas + integración continua hacen que los errores se detecten temprano.
+* Mejora predicibilidad: sprint tras sprint con feedback técnico constante.
+* Aumenta colaboración: pair programming + revisión continua elevan el conocimiento del equipo.
+* Mantiene enfoque en la calidad sin sacrificar velocidad. ([Scrum.org][1])
+
+# Prácticas XP que debes conocer (lo esencial)
+
+(implementa la que puedas, pero prioriza **TDD** + **CI/CD** + **pair programming**)
+
+* **Test-Driven Development (TDD)** — escribir tests primero, código después.
+* **Pair Programming** — dos devs en la misma tarea (driver + navigator).
+* **Continuous Integration / Continuous Delivery (CI/CD)** — integra y despliega pequeñas porciones frecuentemente.
+* **Refactor** continuo — mejorar el diseño sin cambiar comportamiento.
+* **Simple Design** — el diseño más simple que funcione hoy.
+* **Collective Code Ownership** — cualquiera puede tocar cualquier parte del código.
+* **Small Releases / Frequent Integration** — acortar el tiempo entre idea y producción.
+* **Coding Standards** — reglas compartidas para legibilidad y consistencia. ([Scrum.org][1])
+
+# Cómo encaja cada cosa con Scrum (práctico)
+
+* **Sprint Planning**: prioriza ítems que tengan en cuenta la capacidad de hacer TDD/automatización.
+* **Daily**: además del impedimento, usa el daily para sincronizar prácticas técnicas (p.ej. pairing necesario hoy).
+* **Sprint Review**: muestra valor realmente testeado y desplegable.
+* **Sprint Retrospective**: usa retro para ajustar prácticas XP (¿más pair? ¿mejor CI?).
+* **Definition of Done (DoD)**: incluye criterios XP — por ejemplo "unit tests + integración verde + revisión de código". Esto hace que “done” signifique **entregable y mantenible**. ([Scrum.org][1])
+
+# Roadmap de adopción (pasos concretos)
+
+1. **Alineá el equipo en la idea**: Scrum es el marco, XP las prácticas. Hacé una sesión corta para acordar objetivos de calidad.
+2. **Definí DoD que incluya prácticas XP** (tests, CI, build verde).
+3. **Instalá CI básico** (pipeline que corre tests en cada push).
+4. **Empieza con TDD en una feature pequeña** (prueba y aprende).
+5. **Promové pair programming en tareas críticas** (no hace falta 100% del tiempo).
+6. **Automatizá releases** — un pipeline que pueda desplegar al menos a staging con un click.
+7. **Mide, retroalimenta y ajusta**: velocidad, tasa de fallos en producción, tiempo de recuperación.
+   Hazlo iterativo: no intentes imponer TDD + pairing + cambios de arquitectura en una semana; ve sumando prácticas cada sprint. ([Scrum.org][1])
+
+# Métricas útiles (no te vuelvas esclavo)
+
+* **Lead time / Cycle time** (idea → producción).
+* **% de builds verdes** y **fallos en CI**.
+* **Cobertura de tests** (útil como indicador, no como dios absoluto).
+* **Defects en producción** y **MTTR** (tiempo medio de reparación).
+* **Velocidad del equipo** (pero priorizá calidad, no solo bajar números).
+
+# Riesgos y trampas comunes (y cómo evitarlos)
+
+* *Trampa:* “hacemos TDD pero escribimos tests inútiles”. → Priorizar tests que aporten valor (integración + unit).
+* *Trampa:* usar pair programming todo el tiempo sin rotación → fatiga; rotá pares.
+* *Trampa:* DoD vacío = falso progreso. → Hacela real: build verde + tests + deployable.
+* *Trampa:* querer automatizar todo de golpe → empezar por lo mínimo viable (pipeline + tests PR).
+* *Trampa:* management espera entregas rápidas sin invertir en prácticas técnicas → educar stakeholders y mostrar ROI (menos bugs, despliegues más confiables). ([Scrum.org][1])
+
+# Ejemplo de sprint (flujo integrado Scrum + XP)
+
+1. **Sprint Planning** — definir 3 historias pequeñas, cada una con criterios de aceptación y DoD que incluye tests y despliegue a staging.
+2. **Desarrollo** — TDD para la lógica crítica; pair programming en la primera implementación; commits pequeños.
+3. **CI** — cada PR dispara pipeline: lint → tests → build.
+4. **Review & Merge** — code review + aprobación.
+5. **Deploy** — despliegue automático a staging; demo en Review.
+6. **Retro** — ajustar prácticas (p.ej. hacer más pair o mejorar flujos de test).
+
+# Herramientas recomendadas (rápido)
+
+* **CI/CD**: GitHub Actions, GitLab CI, Jenkins, CircleCI.
+* **TEST**: frameworks de unit/integration según stack (JUnit, NUnit, pytest, jest...).
+* **Code review**: PRs en GitHub/GitLab + linters.
+* **Observability**: Sentry, Prometheus, Grafana para errores y métricas.
+
+# 10) Checklist rápido para el equipo (usa esto cada sprint)
+
+* [ ] ¿La DoD incluye tests y build verde?
+* [ ] ¿Cada PR tiene pipeline que pasa?
+* [ ] ¿Se aplicó TDD en al menos una story crítica?
+* [ ] ¿Se usó pair programming en una tarea para transferir conocimiento?
+* [ ] ¿Se deployó a staging y se hizo demo en review?
+* [ ] ¿La retro definió al menos 1 acción para mejorar prácticas técnicas?
+
+# 11) Mi opinión honesta (fuerte, como pediste)
+
+Si tu equipo tiene problemas de calidad o deuda técnica, **Scrum sin XP es humo bonito**: entregás rápido pero con trompazos. XP te obliga a hacer el trabajo técnico que evita la bancarrota del código. La mejor estrategia es pura: **Scrum para organizar → XP para construir**. Si no vas a invertir tiempo en automatizar tests y CI, no esperes acelerar sin romper cosas. Punto. ([Scrum.org][1])
+
+---
+
+Si querés, te lo convierto en:
+
+* Un **one-pager** imprimible (resumen ejecutivo + checklist).
+* Un **plan de 3 sprints** con tareas concretas para implantar TDD + CI.
+* O un **script** con comandos para pipeline CI básico en GitHub Actions (si me decís el stack: Node/.NET/Java/Python).
+
+Te dejo la fuente principal que revisé (explica cómo Scrum y XP se complementan y por qué aplicar prácticas XP dentro de Scrum tiene sentido). ([Scrum.org][1])
+
+Listo. ¿Querés que arme el plan de 3 sprints para tu equipo y lo deje ready-to-run? Te lo hago en modo guerrilla: práctico y sin paja.
+
+[1]: https://www.scrum.org/resources/blog/scrum-and-extreme-programming-xp "Scrum And eXtreme Programming (XP) | Scrum.org"

finales1.ics

@@ -0,0 +1,47 @@
+BEGIN:VCALENDAR
+VERSION:2.0
+X-WR-CALNAME:finales1
+PRODID:-//Federico Polidoro//Emacs with Org mode//EN
+X-WR-TIMEZONE:-03
+X-WR-CALDESC:finales1
+CALSCALE:GREGORIAN
+BEGIN:VEVENT
+DTSTAMP:20251202T160130Z
+UID:TS1-eea8836a-5df0-4f2a-9a68-a1d455effcc7
+DTSTART:20251211T080000
+DTEND:20251211T100000
+SUMMARY:Desarrollo Y Arquitecturas Web
+DESCRIPTION:<2025-12-11 jue 08:00> Tengo hecho todo y ya le presente al pro
+ fe\nnomás necesito que me ponga la nota y defender el buscaminas
+CATEGORIES:finales1
+END:VEVENT
+BEGIN:VEVENT
+DTSTAMP:20251202T160130Z
+UID:TS1-6c97258b-61fc-4085-99d0-2e706577e2b7
+DTSTART:20251218T080000
+DTEND:20251218T100000
+SUMMARY:ELECTROMAGNETISMO I
+DESCRIPTION:<2025-12-18 jue 08:00> por las dudas voy a estudiar RLC y kirch
+ noff\n(kircho)
+CATEGORIES:finales1
+END:VEVENT
+BEGIN:VEVENT
+DTSTAMP:20251202T160130Z
+UID:TS1-6e85e80d-d7cb-4757-82c1-0d401e967dcc
+DTSTART:20251213T080000
+DTEND:20251213T100000
+SUMMARY:INTELIGENCIA ARTIFICIAL
+DESCRIPTION:<2025-12-13 sáb 08:00> Ya tenemos la nota tengo entendido
+CATEGORIES:finales1
+END:VEVENT
+BEGIN:VEVENT
+DTSTAMP:20251202T160130Z
+UID:TS1-516ead5a-56e8-48ce-a8e5-c7955ad194fa
+DTSTART:20251210T080000
+DTEND:20251210T100000
+SUMMARY:ADMINISTRACIÓN DE PROYECTOS
+DESCRIPTION:<2025-12-10 mié 08:00> Hay que ir a defender el tp que alguno t
+ iene\nque imprimir
+CATEGORIES:finales1
+END:VEVENT
+END:VCALENDAR

finales1.org

@@ -0,0 +1,18 @@
+#+title: finales1
+#+author: Federico Polidoro
+
+* Desarrollo Y Arquitecturas Web
+<2025-12-11 jue 08:00>
+Tengo hecho todo y ya le presente al profe nomás necesito que me ponga la nota y defender el buscaminas
+
+* ELECTROMAGNETISMO I
+<2025-12-18 jue 08:00>
+por las dudas voy a estudiar RLC y kirchnoff (kircho)
+
+* INTELIGENCIA ARTIFICIAL
+<2025-12-13 sáb 08:00>
+Ya tenemos la nota tengo entendido
+
+* ADMINISTRACIÓN DE PROYECTOS
+<2025-12-10 mié 08:00>
+Hay que ir a defender el tp que alguno tiene que imprimir