Skip to content

Lecturas complementarias — Bloque I

Esta ruta no pretende que leas todo lo que existe sobre Agile, Scrum o desarrollo de software: establece una biblioteca de referencia para este bloque, con la Scrum Guide como fuente principal. Cuando una explicación externa difiera de la Scrum Guide, para definir Scrum en esta materia se toma la Scrum Guide como fuente principal.

Todo estudiante debe conocer, al terminar el bloque: el Manifiesto Ágil y sus 12 principios, la Scrum Guide 2020 completa, los conceptos fundamentales del SBOK, la documentación básica de Laravel para los laboratorios, y los siguientes términos: Product Goal, Product Backlog, Sprint Goal, Sprint, Sprint Backlog, Increment, Definition of Done, los tres roles de Scrum, los cinco eventos de Scrum, historias de usuario y criterios de aceptación.

Autores: Ken Schwaber y Jeff Sutherland. Tipo: Fuente principal.

Es un documento breve. Se recomienda leerlo completo. Presta especial atención a: definición y teoría de Scrum, transparencia/inspección/ adaptación, valores de Scrum, los tres roles (Scrum Team, Developers, Product Owner, Scrum Master), los cinco eventos, y los tres artefactos con sus compromisos (Product Goal, Sprint Goal, Definition of Done).

Manifiesto por el Desarrollo Ágil de Software (2001)

Section titled “Manifiesto por el Desarrollo Ágil de Software (2001)”

Autores: Beck et al. Tipo: Fuente principal.

Lee los 4 valores y los 12 principios del desarrollo ágil.

Pregunta orientadora. ¿Qué principios del Manifiesto Ágil se reflejan en la forma en que trabajarás tu proyecto integrador?

Organización: SCRUMstudy. Tipo: Referencia complementaria — no sustituye a la Scrum Guide.

Lectura recomendada para este bloque:

  • Capítulo 1 — introducción, para contextualizar Scrum, Agile y proyectos.
  • Capítulo 2 — principios de Scrum: control empírico de procesos, autoorganización, colaboración, priorización basada en valor, time-boxing, desarrollo iterativo.
  • Capítulo 3 — organización: Scrum Team, Product Owner, Scrum Master, Developers.
  • Capítulo 4 — justificación del negocio, como complemento para entender valor y justificación del proyecto.

Los capítulos 5 a 7 (calidad, cambio y riesgo) solo requieren una revisión selectiva en este bloque.

Autores: Andrew Hunt y David Thomas. Año: 2019. Editorial: Addison-Wesley.

Complementa la visión de desarrollo profesional: responsabilidad técnica, calidad, comunicación, aprendizaje continuo, colaboración, mantenimiento del software y actitud profesional. No es necesario leer el libro completo — se recomienda usarlo como lectura complementaria, seleccionando fragmentos relacionados con profesionalismo, responsabilidad, comunicación y calidad.

Prioridad: obligatoria para los laboratorios.

Temas que debes revisar: instalación y primer proyecto, estructura del proyecto (app, database, public, resources, routes, etc.), desarrollo básico (routing, controllers, requests/responses, views, Blade, validation), persistencia (database, migrations, Eloquent ORM, models) y Artisan.

La versión de Laravel utilizada en el proyecto es la definida por el curso. Consulta la documentación en la versión correspondiente.

Historias de usuario y Definition of Done (Scrum.org)

Section titled “Historias de usuario y Definition of Done (Scrum.org)”

Recursos complementarios usados en el Laboratorio 3: las historias de usuario no son un elemento obligatorio definido por Scrum, sino una práctica complementaria para expresar necesidades desde la perspectiva del usuario. Formato usado en el curso: “Como [tipo de usuario], quiero [acción o necesidad], para [beneficio].”

Los videos no sustituyen la lectura de la Scrum Guide. Refuerzan conceptos y sirven de apoyo para discusión en clase.

Para quienes les interese la investigación o el desarrollo profesional en mayor profundidad — estos artículos no son requisito de memorización, muestran que Agile, Scrum, los equipos y la ingeniería de requisitos también se estudian mediante investigación científica:

  • Dybå, T. y Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50, 833–859. DOI: 10.1016/j.infsof.2008.01.006
  • Moe, N. B., Dingsøyr, T. y Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52(5), 480–491. DOI: 10.1016/j.infsof.2009.11.004 — especialmente pertinente para organización de equipos, autoorganización, coordinación y confianza.
  • Inayat, I. et al. A systematic literature review on agile requirements engineering practices and challenges. DOI: 10.1016/j.chb.2014.10.030

Este bloque establece las bases del proyecto. No es necesario adelantar en profundidad: patrones de diseño, Clean Architecture, microservicios, Docker, CI/CD, observabilidad, seguridad avanzada, escalabilidad técnica, arquitectura distribuida, Kubernetes ni infraestructura cloud. Estos contenidos pertenecen a bloques posteriores del taller.

Al terminar las lecturas principales, deberías poder responder:

Agile. ¿Qué problema buscaba atender el movimiento Agile? ¿Qué diferencia existe entre valorar individuos e interacciones sobre procesos y herramientas? ¿Qué significa entregar software funcional frecuentemente?

Scrum. ¿Qué es Scrum? ¿Por qué se considera un framework? ¿Cuáles son sus pilares y sus valores? ¿Cuáles son las tres accountabilities? ¿Cuáles son los tres artefactos y qué compromiso corresponde a cada uno? ¿Qué propósito tiene cada evento? ¿Qué diferencia existe entre Product Goal y Sprint Goal? ¿Qué significa que un Increment esté Done?

Proyecto integrador. ¿Cuál es el problema que intenta resolver tu proyecto? ¿Quién recibe valor? ¿Qué queda dentro del alcance y qué queda fuera? ¿Qué elementos forman tu Product Backlog inicial? ¿Cómo sabes que una necesidad está suficientemente clara para comenzar a desarrollarla? ¿Qué significa que tu primer Increment esté realmente terminado?

Historias de usuario. ¿Una historia de usuario es obligatoria en Scrum? ¿Qué información aporta? ¿Qué diferencia existe entre una historia de usuario y un criterio de aceptación? ¿Y entre criterio de aceptación y Definition of Done?

Laravel. ¿Qué función cumple Laravel dentro del proyecto? ¿Qué función tienen las rutas, controladores, vistas y modelos? ¿Por qué la documentación oficial debe ser la primera fuente de consulta técnica?

Al terminar, debes ser capaz de explicar y aplicar la cadena completa:

problema → usuarios/stakeholders → valor → alcance → Product Goal
→ Product Backlog → historias de usuario → criterios de aceptación
→ Sprint → Increment → Definition of Done

Esta cadena es la base para los bloques posteriores del proyecto integrador.