Fundamentación teórica

SCRUM

A lo largo de la historia del Software, muchos proyectos han fracasado y aún continúan
haciéndolo. Implementar una metodología de gestión, básicamente nos permite organizar
mejor un proyecto y obtener mejores resultados del software entregado a al cliente, evitando
los fracasos. Pero ¿por qué fracasan los proyectos? Sin dudas, los “porque” podrían llegar a ser
casi infinitos, si nos pusiéramos demasiado exigentes. Sin embargo, hay tres motivos de los
que ningún fracaso está exento:

1. El proyecto lleva más tiempo del que se había planificado;

2. El proyecto lleva más dinero del que se había pautado invertir;

3. Las funcionalidades del Software no resultan como se esperaba.

Las razones por las cuales, los tres motivos anteriores generan el fracaso, pueden resumirse
una simple frase: no se puede prever con exactitud un proyecto de desarrollo de Software.

Y ¿en qué se funda esa afirmación? Pues la respuesta está en otra pregunta: ¿en qué se
diferencia un Software de otro producto? La respuesta que primero nos viene a la mente es
que el Software es un producto no tangible que no puede conocerse hasta no estar concluido y
poder probarse.

No obstante ello, el Software tiene grandes ventajas frente a otros productos:

• No puedo construir una silla a medias para probarla ya que la necesito completa. Sin
embargo, puedo construir una determinada funcionalidad del Software para poder
probarla.
• Tirar abajo un edificio recién terminado, porque no satisface las expectativas de los
dueños, sería una gran locura, ya que requeriría invertir tres veces el costo fijado para
reconstruir el edificio. Sin embargo, desarrollando un Software con buenas prácticas de
programación, rehacer funcionalidades o desarrollar nuevas, es tan factible como
simplemente agregar cortinas a las ventanas de un edificio.

Y estas ventajas, deben ser aprovechadas. De lo contrario, insistir en gestionar un proyecto de

desarrollo de Software de manera tradicional, implicaría caer en un capricho infantil sin
fundamentos válidos. Sino, mira los siguientes números:
“En el año 2009, el Standish Group (www.standishgroup.com) elaboró un informe llamado
Chaos Report, el cual arrojó como resultado que solo el 32% de los proyectos de desarrollo de
Software han sido exitosos. El mismo informe, indica que más del 45% de las funcionalidades
del Software entregadas al usuario, jamás se utilizan”.

“En el año 2004, PricewaterhouseCoopers2 elaboró un informe mediante el cual se

investigaron a 200 empresas en 35 países, arrojando como resultado que más del 50% de los
proyectos fracasan (sobre la base de 10.640 proyectos, representando 7.000 millones de
dólares) “.

Por lo tanto, optar por una u otra metodología de gestión, no puede basarse jamás, en un
mero capricho, ya que es mucho lo que está en juego.

Como hacemos Pilas de Producto

La pila de producto es el corazón de Scrum. Es donde empieza todo. La Pila de Producto es,
básicamente, una lista priorizada de requisitos, o historias, o funcionalidades, o lo que sea.
Cosas que el cliente quiere, descritas usando la terminología del cliente. Llamamos a esto
historias, o a veces simplemente elementos de la Pila.

Nuestras historias incluyen los siguientes campos:

• ID – un identificador único, simplemente un número auto-incremental. Esto nos permite

no perder la pista a las historias cuando cambiamos su nombre.
• Nombre – una descripción corta de la historia. Por ejemplo, “Ver tu historial de
transacciones”. Suficientemente claro como para que el Dueño de Producto comprenda
aproximadamente de qué estamos hablando, y suficientemente clara como para
distinguirla de las otras historias. Normalmente, 2 a 10 palabras.
• Importancia – el ratio de importancia que el Dueño de Producto da a esta historia. Por
ejemplo, 10. O 150. Más alto = más importante. Suelo evitar el término “prioridad”
porque típicamente “1” se considera la “máxima prioridad, lo que es muy incómodo si
posteriormente decides que algo es más importante. ¿Qué prioridad le daríamos a ese
nuevo elemento? ¿Prioridad 0? ¿Prioridad -1?
• Estimación inicial – la valoración inicial del Equipo acerca de cuanto trabajo es necesario
para implementar la historia, comparada con otras historias. La unidad son “puntos de
historia” y usualmente corresponde a “días-persona ideales”. Pregunta al Equipo: “si
tuvierais el número óptimo de personas para esta historia (ni muchos ni pocos,
típicamente 2) y os encerraseis en una habitación con cantidad de comida, y trabajaseis
sin distracciones, ¿en cuántos días saldríais con una implementación terminada,
demostrable, testeada y liberable?”. Si la respuesta es “con 3 tíos encerrados en una
habitación nos llevaría 4 días”, entonces la estimación inicial son 12 puntos. Lo importante
no es que las estimaciones absolutas sean correctas (es decir, que una historia de 2
puntos deba durar 2 días), lo importante es que las estimaciones relativas sean correctas
(es decir, que una historia de 2 puntos debería durar la mitad que una historia de 4
puntos).
• Como probarlo – una descripción a alto nivel de cómo se demostrará esta historia en la
Demo al final del Sprint. Se trata, esencialmente, de una simple especificación de un test:
“Haz esto, entonces haz lo otro, y entonces debería ocurrir aquello”. Si practicáis TDD
(Test-Driven Development, desarrollo orientado a test) esta descripción puede usarse
como pseudo-código para vuestro test de aceptación.
• Notas – cualquier otra información, clarificación, referencia a otras fuentes de
información, etc. Normalmente muy breve.

Hemos experimentado con muchos otros campos, pero al final estos seis campos son los
únicos que realmente se usaban Sprint tras Sprint. Mantenemos esta tabla en un documento
Excel con “compartir” habilitado (es decir, muchos usuarios pueden editar simultáneamente la
hoja). Oficialmente, el Dueño de Producto es el propietario del documento, pero no queremos
dejar al resto de usuarios fuera. Muchas veces un desarrollador necesita abrir el documento
para clarificar algo o cambiar una estimación. Por la misma razón, no colocamos este
documento en el repositorio de control de versiones; en vez de eso, lo almacenamos en una
unidad de red compartida. Esta ha demostrado ser la manera más simple de permitir múltiples
editores diferentes sin causar problemas de bloqueo o fusión de documentos. Sin embargo,
casi todos los demás artefactos se colocan en el repositorio de control de versiones.
1.- ¿Qué es un proyecto?

Según la definición que nos proporciona PMI en su guía PMBOOK, un proyecto se podría
definir como “un servicio temporal que se lleva a cabo para crear un producto, servicio o
resultado único”.

Podemos decir entonces que un proyecto tiene un inicio y un fin, este fin se tiene que alcanzar
dentro de un tiempo fijado.

En un proyecto la consecución de los objetivos al final del mismo es la máxima deseada, pero
la mayor parte de las veces, bien por una mala planificación, o bien por una mala gestión de los
recursos, es imposible finalizar el proyecto con éxito. Aun así se da por finalizado (Figura.- 1).
Durante estas fases se realizan las siguientes actividades:

1. Se hace una toma de requerimientos al principio de nuestro proyecto y no sería necesaria

ninguna reunión más hasta la entrega final.

2. Se crea la documentación necesaria en cada fase, y se hace entrega de ella a las fases
siguientes.

3. El cliente ya tiene su producto y este se ajusta a lo indicado, por lo tanto no hay

modificaciones que realizar sobre él.

Pero desgraciadamente el desarrollo de un servicio o producto software no es tan fácil. Esto es

debido a que el entorno en el que se desarrolla (tecnología, nuevas funcionalidades, la
competencia) sufre modificaciones de forma constante, de tal manera que la idea de proyecto
inicial difiere mucho de lo que realmente se desea finalmente.

En el planteamiento para crear cualquier producto sería necesario definir los elementos que
van a participar:

Jefe de
Cliente UsuariosTiempo Coste
Proyecto

Conclusión de los libros mencionados

Aunque son los equipos de desarrollo de software los que utilizan con mayor frecuencia este
tipo de scrum, sus principios y lecciones se pueden aplicar a todo tipo de trabajo en equipo.
Esta es una de las razones por las que es tan popular. Aunque se considera a menudo un
marco de gestión de proyectos ágil, scrum incluye un conjunto de reuniones, herramientas y
funciones que, de forma coordinada, ayudan a los equipos a estructurar y gestionar su trabajo.
Haremos dado una introducción a scrum, un marco ágil que permite a tu equipo organizarse,
iterar y mejorar constantemente los proyectos o productos en los que uno pueda llegar a
trabajar.

Los grandes equipos tienen las prácticas adecuadas, los miembros adecuados y las
herramientas adecuadas. Lo que se verá es más sobre las prácticas y las personas, además de
sobre algunos de los artefactos clave de scrum.

También hay muchas herramientas que se pueden usar para gestionar esos artefactos, como
Jira y Tiga, por el momento estamos intentando tener una buena base de referencia, donde
podemos ver acerca de procesos y los protocolos, las funciones que debe tener cada equipo de
scrum y los artefactos que recopilaran en el camino.

Scrum consiste en enviar valor a los clientes continuamente, es un marco para realizar trabajo,
mientras tanto, la metodología ágil es una serie de valores y principios, toda una estrella, es
decir, que suele venir con cambios culturales significativos, uno no se pasa a la metodología
ágil sin más, ya que cuesta más cambiar la forma de pensar que cambiar la forma de trabajar.
Pero se puede usar un marco como scrum para empezar a pensar de forma más ágil y practicar
la creación de principios agiles en la comunicación y el trabajo.

Los equipos de todo tipo usan scrum: RR.HH, marketing, diseño y más, pero puede que el más
común sea el desarrollo e ingeniería de software, es el marco favorito de muchos equipos de
desarrollo por varias razones: El software es un ser que vive y respira, los requisitos cambian,
al igual que los objetivos y situaciones

Scrum adopta esos cambios, con scrum se integra un producto en una serie de iteraciones
llamadas Sprint, se descomponen proyectos grandes y complejos en trozos más pequeños, de
esta forma, se gestiona mejor, lo que permite a los equipos enviar trabajo de mayor cantidad
más rápido y con mayor frecuencia, y les proporciona más flexibilidad de adaptación y cambio.

La transparencia de scrum y el marco de iteración también ayuda a superar muchos de los

problemas recurrentes que solo encontramos en los proyectos en cascada. Las iteraciones
cortas proporcionan reducir riesgos y costes, obtener opiniones de los usuarios rápidamente,
agilizar la comercialización y ver el valor más rápido.

Los hitos, como el final del sprint, también son frecuentes y dan a los equipos la sensación de
avance tangible regular. Esto les ayuda a permanecer enfocados y animados, lo que aumenta
la participación y la satisfacción de los empleados.

Con beneficios como este, es fácil ver porque scrum es uno de los marcos favoritos de los
equipos de todo tipo.