cosas que me faltaron poner de cuando hicimos la presetnacion de crystal
This commit is contained in:
BIN
administracion/Crystal.odt
Normal file
BIN
administracion/Crystal.odt
Normal file
Binary file not shown.
115
administracion/crystal.org
Normal file
115
administracion/crystal.org
Normal file
@@ -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
|
||||||
|
|
||||||
BIN
administracion/crystal.pdf
Normal file
BIN
administracion/crystal.pdf
Normal file
Binary file not shown.
422
administracion/informe-crystal.html
Normal file
422
administracion/informe-crystal.html
Normal file
@@ -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>
|
||||||
BIN
administracion/parcial2/1.jpg
Normal file
BIN
administracion/parcial2/1.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
BIN
administracion/parcial2/2.jpg
Normal file
BIN
administracion/parcial2/2.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
BIN
administracion/parcial2/3.jpg
Normal file
BIN
administracion/parcial2/3.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
BIN
administracion/parcial2/4.jpg
Normal file
BIN
administracion/parcial2/4.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
102
administracion/scrumxp.md
Normal file
102
administracion/scrumxp.md
Normal file
@@ -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"
|
||||||
BIN
administracion/scrumxp.pdf
Normal file
BIN
administracion/scrumxp.pdf
Normal file
Binary file not shown.
Reference in New Issue
Block a user