Al terminar este bloque vas a poder

Antes de empezar

Alguna vez comenzaste un trabajo en equipo sin tener claro

qué problema estaban resolviendo

quién debía hacer qué

qué tenían que construir primero

Este bloque existe para evitar comenzar el proyecto de esa manera

Dónde estamos dentro del taller

Bloque I    Del problema al producto        ← estás aquí
Bloque II   Colaboración y arquitectura
Bloque III  Construcción del sistema
Bloque IV   Contenedores despliegue y escalabilidad
Bloque V    Integración y presentación final

El proyecto comienza a organizarse desde este bloque.

No esperaremos hasta el final del semestre para descubrir qué debemos construir.

Un sistema no es solamente código

En ambos casos el software debe responder a una necesidad real.

La diferencia importa porque cambia la forma en que pensamos su operación evolución y mantenimiento.

Producto y servicio

Tu proyecto integrador debe pensarse como una solución profesional que entrega valor.

No solamente como una aplicación que funciona en la computadora del desarrollador.

Desarrollo profesional

El desarrollo profesional implica tomar decisiones pensando más allá del código inmediato.

Referencia de contexto: Hunt y Thomas The Pragmatic Programmer 2019

Desarrollo a escala

Un sistema profesional puede crecer en

No necesitamos resolver todavía la escalabilidad técnica.

Primero necesitamos entender que nuestro sistema debe pensarse más allá del escenario de una sola computadora.

El proyecto integrador

Tu proyecto no es una tarea aislada.

Es una oportunidad para trabajar como un equipo que desarrolla una solución de software profesional.

Un ejemplo para entenderlo

Este ejemplo solamente sirve para comprender los conceptos

Tu proyecto utiliza su propio dominio

El problema no es la solución

Ejemplo

Situación actual
Los estudiantes necesitan acudir personalmente al área responsable para saber si un equipo está disponible.

Problema
No existe un medio centralizado para consultar en tiempo real qué equipos están disponibles, ocupados o en mantenimiento.

Consecuencia
Los estudiantes realizan traslados y consultas innecesarias y pueden retrasar sus actividades.

Necesidad
Contar con información actualizada sobre la disponibilidad de los equipos.

Solución posible
Un sistema web que permita consultar la disponibilidad de los equipos y enviar solicitudes de préstamo.

Primero entendemos el problema

Después definimos la solución

Problema · necesidad · solución

Usuarios y partes interesadas

Usuario

Interactúa directamente con el sistema

Parte interesada

Tiene interés en el resultado del proyecto

Identificar ambos ayuda a comprender mejor el problema

El proyecto debe tener límites

Definir límites también es una decisión profesional

Actividad A1

Diagnóstico inicial

Reflexiona individualmente

Actividad A2

Producto y servicio

Selecciona una aplicación o sistema que utilices frecuentemente

Explica

Qué hace
Quién lo utiliza
Qué necesidad atiende
Si funciona principalmente como producto o servicio
Por qué

Consulta las instrucciones completas en

Actividades del Bloque I — A2

Tu equipo ya existe

• El objetivo ahora no es formar nuevos equipos

• El objetivo es organizar profesionalmente el equipo que ya tienes

Responsabilidad individual y colectiva

La colaboración no significa que todos hagan todo

Significa que todos entienden cómo su trabajo contribuye al resultado

Cómo colaborar

Las herramientas técnicas para colaboración se trabajarán posteriormente

Actividad A3

Organización del equipo

Trabajen con el equipo que ya tienen asignado

Definan

¿Por qué Scrum?

• Un proyecto de software cambia mientras se desarrolla

• Aparecen nuevas necesidades

• Se descubren problemas

• Se obtiene retroalimentación

• Cambian las prioridades

• Scrum proporciona un marco para trabajar de manera iterativa y adaptativa

Fuente principal: Schwaber y Sutherland The Scrum Guide 2020

La idea central

Scrum en una frase

• Scrum se basa en ciclos de trabajo y aprendizaje

• No es simplemente una lista de reuniones

Fuente: The Scrum Guide 2020

Los pilares de Scrum

Estos pilares sostienen el enfoque empírico de Scrum

Fuente: The Scrum Guide 2020

Los valores de Scrum

Fuente: The Scrum Guide 2020

Los tres tipos de responsabilidades

Fuente: The Scrum Guide 2020

Product Owner

Su responsabilidad central es maximizar el valor del producto

Entre sus responsabilidades se encuentra

Fuente: The Scrum Guide 2020

Scrum Master

Su responsabilidad central es ayudar a que Scrum se establezca y sea efectivo.

El Scrum Master no es el jefe del equipo

Fuente: The Scrum Guide 2020

Scrum Team

Son las personas que crean el incremento

Fuente: The Scrum Guide 2020

Los artefactos de Scrum

Fuente: The Scrum Guide 2020

Cada artefacto tiene un compromiso

Fuente: The Scrum Guide 2020

Los eventos de Scrum

Fuente: The Scrum Guide 2020

Sprint Planning

El equipo establece

Fuente: The Scrum Guide 2020

Daily Scrum

• Es una oportunidad para que el Scrum Team inspeccionen el progreso hacia el Sprint Goal

• Debe ayudar a identificar la necesidad de adaptar el Sprint Backlog

• No es un reporte al profesor

• No es una reunión para demostrar quién trabajó más

Fuente: The Scrum Guide 2020

Sprint Review

• El equipo inspecciona el resultado del Sprint junto con las partes interesadas

• Se analiza qué se consiguió

• Se revisa qué cambió

• Se decide qué adaptar posteriormente

Fuente: The Scrum Guide 2020

Sprint Retrospective

El equipo analiza cómo trabajó

Después identifica mejoras que puede aplicar

Fuente: The Scrum Guide 2020

¿Y el Sprint 0?

Nota: “Sprint 0” se utiliza en este curso como convención académica, no como parte del marco Scrum.

Sprint 0 no significa construir todo

Historias de usuario

Una historia de usuario expresa una necesidad desde la perspectiva de quien obtiene el beneficio.

Ejemplo

• La historia de usuario no describe cómo se programará

• Describe qué necesita el usuario y para qué

Una historia debe poder verificarse

La historia debe acompañarse de criterios de aceptación

Ejemplo

El criterio permite determinar si el comportamiento esperado se cumple

Una historia no es una tarea técnica

La tarea técnica aparecerá después como parte del trabajo necesario para implementar la historia de usuario.

Priorizar historias

No todo puede construirse al mismo tiempo

La prioridad debe responder al valor y a las necesidades del producto

Estimar no significa adivinar horas

La estimación inicial permite comparar el tamaño relativo de las historias

1   muy pequeña
2   pequeña
3   media
5   grande
8   muy grande

La estimación puede cambiar conforme el equipo aprende más sobre el producto

Actividad A4

Scrum en acción

Relaciona

Roles
Artefactos
Eventos
Compromisos

Analiza cómo se conectan durante un Sprint

Tres preguntas antes de construir

Estas decisiones serán la base del Product Backlog

El alcance también dice que NO

Un proyecto profesional necesita límites

El alcance puede evolucionar

Pero debe existir una referencia inicial

El Product Backlog

El Product Backlog representa todo lo que el producto necesita para mejorar

Es

1. ordenado

2. emergente

3. visible

4. evolutivo

• No necesitamos conocer absolutamente todo desde el primer día

• Necesitamos suficiente claridad para comenzar

Fuente: The Scrum Guide 2020

Del problema al Product Backlog

Las historias de usuario y los criterios de aceptación son prácticas complementarias para trabajar los elementos del Product Backlog.

Actividad A5

Ficha de planteamiento del proyecto

Trabaja sobre el proyecto que tu equipo ya tiene asignado

Define

LAB-01

Primer contacto con Laravel desde cero

El objetivo es familiarizarte con el entorno de desarrollo

Vas a aprender a

Crear una aplicación Laravel
        ↓
Ejecutarla
        ↓
Reconocer su estructura
        ↓
Modificar una ruta
        ↓
Obtener una respuesta

No necesitas conocimientos previos de Laravel

LAB-02

Primer CRUD con Laravel desde cero

Ahora pasarás de una aplicación que responde a una aplicación que maneja
información

Ruta
 ↓
Controlador
 ↓
Modelo
 ↓
Base de datos
 ↓
Vista

El objetivo es comprender el recorrido de una operación completa

El CRUD es un ejercicio técnico

No significa que todas las funcionalidades del proyecto deban diseñarse
como CRUD

LAB-03

De la necesidad a las historias de usuario

Ahora dejamos temporalmente el código

Trabajaremos con el problema real de nuestro proyecto

Usuario
   ↓
Necesidad
   ↓
Historia de usuario
   ↓
Criterios de aceptación
   ↓
Prioridad
   ↓
Estimación

El resultado será nuestro Product Backlog inicial

LAB-04

Sprint 0

Aquí integramos lo trabajado

El objetivo es dejar el proyecto listo para comenzar los Sprints de
desarrollo

Sprint 0 — ¿Qué debemos tener?

Definition of Done inicial

Para este primer incremento utilizaremos una definición sencilla

☐ Está implementado
☐ Puede ejecutarse
☐ Cumple los criterios de aceptación
☐ No presenta errores evidentes
☐ Está incorporado al repositorio

Esta definición evolucionará conforme avance el proyecto

La conexión entre todo

Problema
   ↓
Necesidad
   ↓
Historia
   ↓
Product Backlog
   ↓
Sprint
   ↓
Trabajo del equipo
   ↓
Incremento
   ↓
Inspección
   ↓
Adaptación
   ↓
Nuevo Sprint

Esta será la dinámica general del proyecto integrador

Lo que NO haremos todavía

En este bloque no profundizaremos en

Git avanzado
Arquitectura
Patrones de diseño
APIs
Seguridad técnica
Pruebas automatizadas
Docker
CI/CD
Observabilidad
Escalabilidad técnica

Esos contenidos aparecerán progresivamente en los siguientes bloques

Una última revisión

Al terminar este bloque deberías poder explicar

El proyecto ya debe tener dirección

Antes

Tenemos un proyecto

Ahora

Tenemos un problema definido
        ↓
Tenemos usuarios identificados
        ↓
Tenemos un alcance
        ↓
Tenemos historias
        ↓
Tenemos un Product Backlog
        ↓
Tenemos un equipo organizado
        ↓
Tenemos una primera funcionalidad

Referencias principales

Scrum

Schwaber, Ken; Sutherland, Jeff

The Scrum Guide
2020

Fuente principal para

• Scrum
• Roles
• Artefactos
• Eventos
• Valores
• Pilares
• Product Backlog
• Incremento
• Definition of Done

Referencias complementarias

Desarrollo profesional

Hunt, Andrew; Thomas, David

The Pragmatic Programmer
2019

Apoya la reflexión sobre prácticas y responsabilidad profesional en el
desarrollo de software

Recurso pedagógico complementario

SCRUMstudy

SBOK Guide 5th Edition

Se utiliza como material complementario para reforzar conceptos de Scrum

No sustituye a la Scrum Guide como fuente principal

Recursos técnicos del laboratorio

Para los laboratorios se utilizará la documentación oficial de las
tecnologías seleccionadas

En este bloque Laravel se utiliza como medio para comenzar a construir

La documentación técnica no sustituye las referencias conceptuales del
bloque

Cierre

Bloque I — Del problema al producto