Módulo 1

Vamos a presentarnos

Las tareas no muestran relación entre sí

​

​

​1920. Diagrama de Gantt

​

Este ciclo fue creado por Walter A. Shewart en la década de 1920. 

​

El ciclo pasó de “Planificar – Hacer – Ver” a “Planificar – Hacer – Verificar – Actuar”, que​

​

1930. Círculo Virtuoso de Deming

​

1969. Winston Royce

​

​Trabajó en proyectos aeroespaciales.

​

En 1985, el Departamento de Defensa de los Estados Unidos publicó el Estándar 2167 (DoD-STS-2167)

Este estándar se basó en un paper llamado “Managing the Development of Large Software Systems”, escrito en 1970 por Winston Royce.​

​

“Creo en este concepto, pero la implementación descrita anteriormente es arriesgada e invita al fracaso" Royce. ​

​

“Él siempre fue un defensor del desarrollo iterativo, incremental, evolutivo. Su artículo describe la cascada como la descripción más simple, pero eso no funcionaría para todos los proyectos, excepto aquellos más sencillos Hijo de Royce. ​

​

​

​1986. Hirotaka Takeuchi y Ikujiro Nonaki. El nuevo juego en el desarrollo de productos ​

​

​A mediados de la década de los 80’s, empresas como Canon, Fuji-Xerox, Honda y Epson, entre otras, necesitaban desarrollar productos exitosos a partir de procesos que les permitieran lograrlo en el menor tiempo posible. ​

​

Takeuchi y Nonaka compararon el trabajo de los equipos de desarrollo con un equipo de rugby, el cual trabaja en conjunto, pasando el balón hacia atrás y hacia adelante a medida que se desplaza en unidad por el campo. ​

​

En rugby, existe una formación denominada Scrum, en la cual se produce un enfrentamiento por parte de equipos unidos y en posición agachada, que buscan empujar al equipo contrario con el objetivo de obtener el balón que se encuentra en medio de ellos, sin tocarlo con las manos. ​ ​ ​

​

Así pues, los autores propusieron que el desarrollo de productos debía dejar de ser como una carrera de relevos secuencial, en las cuales los equipos se turnan para realizar actividades, y ser en cambio análogo al juego de rugby, con equipos capaces de trabajar como unidad, pasando el balón hacia atrás y adelante para lograr el objetivo.

​

Aunque esta forma de trabajo surgió en empresas de productos tecnológicos, es apropiada para cualquier tipo de proyecto con requisitos inestables y para los que requieren rapidez y flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software.

​

​1994. The Chaos Report

​

Solo el 16% de los proyectos analizados se consideraban exitosos.​

​

Las principales causas de que el 84% de proyectos restantes fueran cancelados o desafiantes, eran requerimientos cambiantes y falta de involucramiento de los usuarios del sistema.

​

​

​1995. Marco de trabajo Scrum

​

Ken Schwaber y Jeff Sutherland desarrollaron el concepto de Scrum durante una presentación en la Conferencia internacional sobre programación, lenguajes y aplicaciones orientadas a objetos (Object-Oriented Programming, Systems, Languages & Applications, o OOPSLA) en Austin, Texas.

​

Ambos autores crearon el marco de trabajo de Scrum para ser utilizado en procesos de desarrollo de software. Utilizaron el análisis desarrollado por Takeuchi y Nonaka, y lo complementaron con conceptos como control de procesos empírico y desarrollo iterativo

​

​

​

​1999. Extreme Programming

​

Primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999-Ken Beck).

​

Pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.

​

• cliente bien definido;

• los requisitos pueden (y van a) cambiar;

• grupo pequeño y muy integrado (máximo 12 personas);

• equipo con formación elevada y capacidad de aprender.

​

​

2001. Agile Manifesto

​

Documento redactado en 2001 por 17 expertos en programación que supuso un cambio radical en la forma de desarrollar 'software'. Frente a los modelos tradicionales —excesivamente rígidos y alejados de las necesidades de los clientes—, estos gurús propusieron cuatro valores que inspiran las diferentes metodologías ágiles que han surgido desde entonces. Aunque nació en el mundo del 'software', la filosofía que promueve este manifiesto es extensible al desarrollo de cualquier otro producto.

​

​

Schwaber y Sutherland estaban entre los 17 expertos. Este evento causó la creación de la Agile Alliance, también en 2001.​

​

​

​

​

2003. Certificación de Scrum Master

​

Scrum fue atrayendo interesados y Ken Schwaber creó el curso Certified Scrum Master para formar a los primeros Scrum Masters desde 2001. La Scrum Alliance se fundó en 2002 por Ken Schwaber, Mike Cohn y Esther Derby, y la entidad distribuyó la posibilidad de dar cursos Certified Scrum Master a los miembros que hubieran cursado el curso CSM.​

​

​

​

​

2008. Certificación de Producto Owner

​

El primer Product Owner ​

Para elegir al Product Owner, se basaron en el Jefe de Ingeniería de Toyota. Esta figura se dedicaba a fabricar coches, interactuando con muchas secciones, pero sin ser jefe del equipo mediante coerción. Además, necesitaban a alguien que fuera capaz de ponerse en los zapatos del cliente final, que entendiera sus necesidades. Así fue como eligieron a Don Rodner, del departamento de Marketing. ¡El primer Product Owner de la historia!​

​

​

​

​2010. Guía oficial de Scrum

​Más detalles de la línea del tiempo de Scrum en:

​

https://www.agilealliance.org/agile101/practices-timeline/

​

• Permite flexibilidad

• No se guía por pasos. Propone "encontrar el camino"

• Permite creatividad ​

​Marco de trabajo

-Es sistemático y sigue procedimientos

- Prescriptivo

-Conocimiento de procedimientos sistemáticos

​

​

​

Metodología

Complejidad

Simple: fácil de operar. Casus y efectos obvias. Solución indiscutible. Ej: producción en serie de un producto.

​

Complicado: perfiles expertos. Varias soluciones para mismo problema. Ej: la sincronización de semáforos en un cruce de tres avenidas. El rendimiento de un software.

​

Complejo: no hay soluciones evidentes. Probamos resultados y nos adaptamos. Requiere creatividad, innovación. No existe lo mejor o lo peor. Ej: desarrollo de nuevos productos.

​

Caos: situaciones críticas, requieren respuesta inmediata. Improvisación de alguien que tome el mando para salir del caos. Ej: un sistema de tráfico aéreo deja de funcionar.

​

Desorden: ​no sabemos dónde estamos. Ej. ¿?

​

​

​

​

Ejercicios de complejidad

En la hoja compartida de Google.​

Scrum = Dominio complejo

​

Conexto vulnerable, incierto, complejo y volátil ​

​

Requiere soluciones innovadoras con impacto de fallos manejables​

​

Actividad de cambio de contexto

​

-Buscar una hoja

​

-Dibujar/separar 3 columnas y colocar título a cada una: Número, Letra, Romano

​

-Tener cronómetro

​

-Actividad 1. Cambio de contexto

-Actividad 2. Cambio de contexto

​

​Actividad 1. Completar cada columna (hasta el 10)

​

Número-Letra-Romano (1-A-I)

​

Actividad 2.

​

Primero comple​tar columna número, luego letra, luego romano.

​